[01:34] <Lirodon> coz_, hello again
[01:35] <coz_> Lirodon,  hey guy
[05:40] <didrocks> good morning
[07:07] <oSoMoN> good morning
[07:40] <andyrock> JohnLea, around?
[07:42] <andyrock> JohnLea, btw when you are available can you give a look to the last comment of this bug? https://bugs.launchpad.net/ubuntu/+source/unity/+bug/772445
[08:06] <htorque> andyrock: hi! can you confirm bug 856184?
[08:09] <andyrock> htorque, done
[08:09] <andyrock> i'm not sure if it's a problem in unity (ubuntu) too
[08:09] <htorque> likely, but i haven't installed that anywhere
[08:10] <htorque> andyrock: thanks anyway. now to catch the crashers - quitting apps randomly takes down unity here. :(
[08:11] <andyrock> htorque, me too...
[08:11] <andyrock> are you able to get a backtrace and open a bug?
[08:12] <andyrock> htorque, i know you are able... i mean "can you get..."
[08:12] <andyrock> :)
[08:15] <htorque> andyrock: sure will do, i just have to purge the desktop-team PPA first (contains the stacking fixing compiz). not sure if that's already in ubuntu and i'm not feeling good when doing such reports with PPAs enabled. :P
[08:16] <andyrock> htorque, ok ok thx :)
[08:18] <JohnLea> andyrock; so the issue is that it takes up to 5 sec to get the file type of very large files, and there is no way of reducing this delay?
[08:21] <andyrock> JohnLea, 5 sec is an example but 1 sec of freeze sucks too... i noticed this freeze only with browser (firefox or chrom*) images
[08:22] <JohnLea> andyrock; agree that freeze completely sucks.  You have only encountered this when dragging images from *inside* a web page?
[08:22] <andyrock> JohnLea, yes...
[08:24] <andyrock> JohnLea, also with images not so "big"
[08:25] <andyrock> e.g. unity logo on top of LP Unity page
[08:26] <andyrock> JohnLea, give me just a second... i've an idea
[08:28] <JohnLea> andyrock; cool
[08:29] <JohnLea> andyrock; from a design prospective the ideal solution is to find a way to eliminate the delay, but I know that answer doesn't help you
[08:29] <andyrock> JohnLea, maybe the problem is that the img is not taken from the browser cache
[08:30] <andyrock> but it is downloaded from the Internet
[08:30] <andyrock> let me debug... :)
[08:33] <andyrock> JohnLea, QED
[08:33] <andyrock> https://launchpadlibrarian.net/53981966/unity-logo-64.png
[08:33] <andyrock> the problem is that it takes time to download it...
[08:39] <andyrock> JohnLea, a workaround could be diabiling the icon that should be downloaded
[08:39] <andyrock> but i guess there is a better solution
[08:49] <JohnLea> andyrock; good luck, I don't think I'll be much help with this one but keep me posted.  I'll ask racarr when he get's in if he has any ideas
[08:50] <andyrock> JohnLea, ok... tell racarr that using g_file_query_info_async removes the freeze but not the delay
[08:57] <htorque> andyrock: you said you were getting the crashes too. are you using the compiz from the ubuntu-desktop PPA (stacking issues fixed)?
[08:58] <andyrock> i use the ubuntu-desktop ppa
[08:58] <andyrock> so i guess yep
[08:59] <htorque> either i've been unlucky for the past 30 minutes or it's related to that compiz version.
[08:59] <andyrock> htorque, 1:0.9.5.94+bzr20110919-0ubuntu1~ppa1
[08:59] <htorque> andyrock: thanks. will try again for a bit and then switch back to the PPA.
[08:59] <andyrock> htorque, try to get the bt using the ppa
[09:00] <htorque> i haven't seen any crashes right now.
[09:00] <htorque> andyrock: ok
[09:00] <andyrock> thx
[09:01] <htorque> andyrock: meh, this gets rid of all -dbgsym packages. :-/
[09:03] <andyrock> htorque, yeah....
[09:50] <njpatel> apinheiro, re: https://bugs.launchpad.net/unity/+bug/817691, it seems the a11y code uses unsetenv call after some threads are launched and that's not safe, do we need those calls?
[09:50] <njpatel> it seems to be okay to use them very early in the main() but not so good if we start threaded stuff (like gdbus), which calls getenv and can cause a race
[09:51] <apinheiro> njpatel, hi
[09:51] <njpatel> apinheiro, hey :)
[09:51] <apinheiro> hmm
[09:51] <apinheiro> but this is something new?
[09:51] <apinheiro> I mean, was crashing before
[09:51] <apinheiro> ?
[09:51] <njpatel> nope, it's new in O
[09:52] <njpatel> apinheiro, in panel-a11y.c, there is g_unsetenv twice, is that required?
[09:52] <njpatel> basically it's racing between the setenv and dconf starting in a thread
[09:52] <njpatel> (and doing a getenv)
[09:52] <njpatel> so, fun
[09:53] <njpatel> and gettext obviously does getenv too
[09:53] <apinheiro> njpatel, I will check it
[09:53] <apinheiro> I didn't write that code, was rodrigo
[09:53] <apinheiro> but in summary, it should be a g_unset before start the a11y stuff
[09:53] <apinheiro> and then a set to restore the status
[09:53] <njpatel> apinheiro, so, it's weird:
[09:53] <njpatel> in main, we do:
[09:54] <njpatel>   g_unsetenv("UBUNTU_MENUPROXY");
[09:54] <njpatel>   g_setenv ("NO_AT_BRIDGE", "1", TRUE);
[09:54] <njpatel>   g_unsetenv ("NO_GAIL");
[09:54] <njpatel>   panel_service_get_default();
[09:54] <njpatel>   a11y_init();
[09:54] <njpatel> and that calls the unsetenv
[09:54] <njpatel> get_default() is loading the indicators etc, so they aren't goign to be effected by the unsetenv
[09:55] <njpatel> but, yeah, please have a look. Ideally we wouldn't be doing (un)setenv's that late in the startup
[09:55] <apinheiro> well, for what it worths
[09:55] <apinheiro> we do that
[09:55] <apinheiro> in order to ensure that any child process will have the proper env
[09:56] <apinheiro> if this is not required
[09:56] <apinheiro> we could just avoid restoring the env on a11y_init
[09:57] <njpatel> I can't think it is with indicators, but if you could test that it doesn't cause regressions with the panel, I can make the change quickly in trunk
[09:57] <apinheiro> njpatel, and afaik, there isn't any panel-service child process that would require a11y support, right?
[09:57] <njpatel> nope, none that I can think of
[09:57] <apinheiro> njpatel, ok, I will move to this then
[09:57] <apinheiro> njpatel, one question
[09:57] <apinheiro> to reproduce it
[09:57] <apinheiro> it happens all the times or it is a race condition
[09:57] <apinheiro> and just crashes sometimes?
[10:04] <njpatel> apinheiro, it's a race so very hard to reproduce
[10:04] <apinheiro> njpatel, btw, could this also be a issue for unity-3d?
[10:04] <njpatel> apinheiro, at this point, I'd like to just test that there are no regressions when removing those two unsetenv calls, we can then send out a release for the people effected to test
[10:05] <njpatel> apinheiro, it could but I have yet to see one bug report. That could be due to do the different type of startup with compiz involved etc
[10:05] <apinheiro> njpatel, ok
[10:07] <apinheiro> njpatel, looking at the code in detail
[10:08] <apinheiro> we can remove   g_unsetenv ("NO_GAIL");
[10:08] <apinheiro> but
[10:08] <apinheiro> we can't just remove   g_unsetenv ("NO_AT_BRIDGE");
[10:08] <apinheiro> at panel_a11y_init
[10:08] <apinheiro> as if we don't do that
[10:08] <apinheiro> the atk bridge will prevent himself to be loaded
[10:08] <apinheiro> when we load it by hand
[10:09] <apinheiro> njpatel, one question
[10:09] <apinheiro> calling g_unsetenv is a problem if we do that
[10:09] <njpatel> maybe we can move up the panel init to be before the panel_service init?
[10:09] <apinheiro> after _get_default, right?
[10:09] <njpatel> right
[10:09] <njpatel> so can we move it to before?
[10:09] <apinheiro> well, my suggestion was similar
[10:10] <njpatel> :)
[10:10] <apinheiro> load the bridge before that call
[10:10] <apinheiro> and then, a different call to ensure that the a11y object hierarchy include the service
[10:10] <njpatel> right
[10:11] <apinheiro> I will try that and propose a branch
[10:11] <njpatel> thankd
[10:22] <apinheiro> njpatel, is there a problem if panel_a11y calls panel_service_get_default during the intialization?
[10:22] <njpatel> apinheiro, is this after the unsetenv?
[10:22] <apinheiro> njpatel, yes
[10:23] <njpatel> It should be fine
[10:23] <apinheiro> njpatel, ok, just trying to reduce the change to be as small as possible
[10:23] <apinheiro> thanks
[10:27] <apinheiro> njpatel, after a quick test with orca, it seems to keep working
[10:27] <apinheiro> and it is a small change
[10:27] <apinheiro> just move panel_a11y_init
[10:27] <apinheiro> to be called before
[10:27] <apinheiro>   service = panel_service_get_default ();
[10:27] <njpatel> apinheiro, okay, I can make that if you want, to avoid merge proposal etc etc
[10:28] <apinheiro> njpatel, ok
[10:28] <apinheiro> although for the future, it would be good add a note like this:
[10:29] <apinheiro> 	//Note: panel_a11y_init needs to be done before service_get_default,
[10:29] <apinheiro>   // to avoid a race condition with g_unsetenv. Take a look to bug 817691
[10:29] <njpatel> apinheiro, right, thanks :)
[10:30] <apinheiro> njpatel, thanks to you
[11:41] <htorque> smspillaz: hi! is https://launchpadlibrarian.net/80602060/unity_crasher_better.log the crash when closing windows that's already fix comitted?
[11:42] <htorque> bug 856305 bug 856015
[13:15] <andyrock> JohnLea, to avoid the delay what about guessing the content type using filename
[13:15] <andyrock> ?
[13:15] <JohnLea> andyrock; hyia
[13:15] <andyrock> of course only for "virtual" file
[13:16] <racarr> andyrock: Ping? JohnLea mentioned something you said about drag and drop in unity and some awkward delay?
[13:16] <andyrock> racarr, hi
[13:17] <andyrock> well in Unity we use g_file_query_info to get the content type of every single file we are dragging
[13:18] <andyrock> for locale files it works well
[13:18] <andyrock> but dragging a browser (chrom* or firefox etc.) image
[13:18] <andyrock> g_file_query_info takes too time
[13:18] <andyrock> we can use g_file_query_info to avoid the delay
[13:19] <andyrock> sorry
[13:19] <andyrock> to avoid the freeze
[13:19] <andyrock> but we can't avoid the delay
[13:19] <andyrock> using g_file_query_info
[13:19] <andyrock> this is all... :)
[13:20] <andyrock> I can easily implement this behavior:
[13:20] <racarr> Hmm. Ok. I will look in to it. (probably not this week...in london for a bit), but im doing some Dnd stuff next week
[13:20] <andyrock> 1) if the file is a locale one use g_file_query_info
[13:21] <andyrock> 2) if the file is not in locale guess the mimetype from filename
[13:22] <racarr> The thing is, firefox should be saying over XDnd what mime types the source can be...
[13:23] <andyrock> racarr, ok... we just uri/list stuff
[13:23] <andyrock> *just->get
[13:23] <racarr> so I don't think we have to use g_file_query_info at all to determine which applications can support I think
[13:25] <racarr> I can't produce any delay though actually even with a 12mb png
[13:25] <racarr> but maybe the internet here is too fast :) I will have to look in to it more later. Thanks :)
[13:25] <andyrock> racarr, will you be online for a while?
[13:26] <racarr> andyrock: For a while yes. but I am at a sprint atm, so kind of distracted from unity so can't do any too serious looking in to it right now
[13:27] <andyrock> racarr, no problem... i just want to get a test and tell you the results
[13:28] <racarr> andyrock: Ok, great, thanks :)
[13:28] <andyrock> racarr, yw
[13:41] <andyrock> racarr, dragging and image using chrom* and using nux to get the dnd data i get:
[13:41] <andyrock> http://pastebin.ubuntu.com/695120/
[13:45] <andyrock> firefox gives not (at lease using the nux interface) the type but something like x-moz-nativeimage
[13:46] <racarr> andyrock: Hmm. I will have to look in to the full code path here, I think something is definitely wrong is there is any delay...
[13:46] <racarr> if there is*
[14:30] <om26er> smspillaz, hi could you tell which crash was fixed with this branch https://code.launchpad.net/~smspillaz/compiz-core/compiz-core.fix_856015/+merge/76501 was it this crash bug 851472
[14:31] <om26er> htorque, your's is also the above crash I guess ?
[14:31] <htorque> yeah :)
[14:31] <smspillaz> who doth ping me
[14:32] <smspillaz> om26er: no
[14:32] <smspillaz> om26er: it was a crash that could happen if an application unmapped a window as withdrawn, re-mapped it, and then closed it
[14:33] <om26er> smspillaz, ok, i believe the above crash is also in compiz itself though
[14:38] <htorque> om26er: anothter thing. can you explain what you mean with the 24px in bug 835989? i've seen that report before reporting mine, but didn't quite understand the description.
[14:39] <om26er> htorque, invoke launcher from the area top-left 24px and leave it without hovering over the launcher
[14:39] <om26er> the bug has a video i think
[14:39] <smspillaz> om26er: hang on
[14:40] <smspillaz> uhhh
[14:40] <smspillaz> XNextEvent crashing?
[14:40] <om26er> htorque, i am going to make a new video for you
[14:40] <smspillaz> that's a NoCrash (tm) funciton
[14:40] <smspillaz> om26er: let me look into what might failing in xlib
[14:40] <om26er> smspillaz, oki doki ;)
[14:41] <smspillaz> om26er: uhhh, so was xlib recently updated ?
[14:41] <smspillaz> err libX11
[14:42] <om26er> smspillaz, no last update six weeks ago
[14:42] <smspillaz> :/
[14:42] <om26er> htorque, http://videobin.org/+58l/5n4.ogg
[14:43] <htorque> om26er: hm, but you didn't trigger the unhide in that area? you just left it while it was unhiding, which i suspected was the problem.
[14:45] <htorque> om26er: oh, that crasher has a lot of dupes. i probably should have turned on the update-manager service (else you don't get apport popups). ;-)
[14:45] <om26er> htorque, didnt understand what you mean?
[14:45] <om26er> htorque, ;-)
[14:47] <htorque> om26er: in the clip you added to the bug report you didn't reveal it like in the new one (more like i did in my bug: https://launchpadlibrarian.net/80589264/launcher-stuck.ogv - starting from below the top-left corner then going upwards to the panel area).
[14:48] <om26er> htorque, both seem clearly the same to me
[14:48] <om26er> and i can reproduce the both way
[14:48] <om26er> also Trevinho had some thoughts about it as well
[14:49] <htorque> me too. i'll just wait. if this is fixed and i can still make it stuck, i'll just open a new bug. :)
[14:49] <smspillaz> om26er: ok, I'm going to ask RAOF about that tomorrow. I'm suprised about: event=0x7fffa408d510) considering that its just a pointer to something on the stack
[14:50]  * smspillaz thinks maybe we should allocate an array the size of XPending
[14:50] <om26er> smspillaz, ok, thx
[14:52] <Trevinho> om26er: about that bug I've still to check what we can do
[14:53] <om26er> Trevinho, it started just after the BFB was removed
[14:53] <om26er> *from panel
[14:58] <Trevinho> om26er: ok
[14:58] <Trevinho> actually I was thinking the same thing
[14:58] <Trevinho> checking now
[15:01] <MacSlow> anybody here who knows or goes by the name Victor Eduardo ? please ping me
[15:02] <om26er> Trevinho, you might want to hold off jason assigned himself so making you aware to avoid duplicate effort
[15:04] <Trevinho> om26er: I just study the thing quickly now
[15:04] <Trevinho> if I can find something I'll change the bug infos ;)
[15:04] <om26er> okay :)
[15:22] <Trevinho> om26er: do you like: http://www.youtube.com/watch?v=3nkNjhbGwTs ?
[15:29] <shibata> Hi, all.
[15:33] <om26er> Trevinho, that looks interesting
[15:33] <om26er> Trevinho, can i haz the code for real testing?
[15:34] <shibata> Can anyone review merge request for #663776? https://code.launchpad.net/~cosmos-door/unity/fix-preedit-663776/+merge/75350
[15:34] <om26er> then i'd be sure if its a distraction or attraction :D
[15:42] <andyrock> gord, in dash keyboard navigation space key and enter should have the same behavior
[15:43] <Trevinho> om26er: the code is still on WIP, i've to push it somewhere... But it's bugged for maximized windows actually
[15:43] <Trevinho> however the animation is very fast, it shouldn't distract
[15:43] <om26er> Trevinho, oh, i'll hold off then though nice work so far
[15:44] <Trevinho> and it's somethig requested on https://bugs.launchpad.net/unity/+bug/691776
[15:44] <om26er> yes, i know that
[15:54] <Trevinho> om26er: also I guess it wouldn't be too hard to do what should be done according to the design that Mark pointed out: show the menus the more you're near to the panel
[15:54] <om26er> Trevinho, guess we can have this part sorted out nicely for the LTS then
[15:55]  * om26er thinks Trevinho is in love with the panel ;)
[15:57] <Trevinho> om26er: I don't love it so much, but it neeeds to be tuned! :)
[15:57] <Trevinho> And so, here I am.
[16:06] <andyrock> om26er, https://bugs.launchpad.net/unity/+bug/750358
[16:06] <andyrock> fix released?
[16:06] <om26er> looking
[16:06] <andyrock> om26er, thx
[16:07] <om26er> andyrock, not sure about "and gain a tint based on the average wallpaper colour."
[16:07] <om26er> from the bug report
[16:08] <om26er> i guess would be better if that screenshot could be accessed
[16:08] <andyrock> well somethink like the dash
[16:08] <andyrock> JohnLea, ^^^
[16:10] <JohnLea> andyrock; yes, basically exactly the same average background colour tinted material that is used for the Dash, Alt-Tab, etc...
[16:10] <JohnLea> om26er ^^^
[16:10] <andyrock> well now it has the same average background color
[16:12] <om26er> JohnLea, currently it looks like this http://videobin.org/+58o/5n7.ogg is that what the bug is about?
[16:12] <om26er> can we call it fixed
[16:13] <JohnLea> om26er; yes that looks fixed to me ;-)
[16:13] <om26er> andyrock, ^^
[16:13] <om26er> JohnLea, thx :)
[16:14] <andyrock> om26er, JohnLea thx one bug less... :)
[16:14] <Trevinho> om26er: try this lp:~3v1n0/unity/fading-panelmenu (not tested if compiles :P)
[16:14] <om26er> Trevinho, i'll try that now ;)
[16:16] <Trevinho> JohnLea: I've seen that the "bug" about showing the window buttons on pressing alt has been "fixed"... Is that really the designed solution?
[16:17] <JohnLea> Trevinho; can you remember the bug #?
[16:20] <JohnLea> Trevinho; you mean bug https://bugs.launchpad.net/ayatana-design/+bug/836274
[16:21] <Trevinho> JohnLea: #836274
[16:22] <Trevinho> Ah, sorry.. .:P
[16:25] <om26er> andyrock, do you have any thoughts about bug 745707 ?
[16:25] <andyrock> om26er, if i'm not wrong this was a wanted behavior... so should not be so difficult use the old behavior
[16:26] <om26er> andyrock, now its not wanted it seems
[16:26] <om26er> current behavior is really annoying
[16:26] <andyrock> om26er, i know
[16:27] <andyrock> assigned to me...
[16:28] <andyrock> i should work to an huge branch for device
[16:28] <andyrock> bug i should go now
[16:28] <om26er> andyrock, super
[16:28] <om26er> andyrock, the devices branch would probably be for LTS ?
[16:30] <Trevinho> JohnLea: I asked that since talking with njpatel he told me that it actually was a non-bug (that's why I didn't fix it before)... So I'd need to know how to consider that...
[16:32] <om26er> i dont remember using alt+f, e etc for in window menus, what happened when you pressed the letter again, for example alt+f to open the menu and pressing alt+f again, did it close the menu or nothing happen?
[16:32] <didrocks> andyrock: it is wanted
[16:32] <didrocks> om26er: ^
[16:32] <didrocks> took a lot of time to get there
[16:33] <didrocks> and it seems the behavior regressed even :/
[16:33] <om26er> didrocks, yes i added my findings to the bug report.
[16:34] <didrocks> om26er: basically, the original behavior was:
[16:34] <didrocks> om26er: put the mouse cursor in the launcher area (launcher hidden)
[16:34] <didrocks> press super to show the launcher
[16:34] <didrocks> release, the launcher should disappear
[16:35] <didrocks> if after you press super, you moved the cursor, the launcher shouldn't disappear
[16:35] <didrocks> then another use case
[16:35] <didrocks> if you press on an launcher icon, and don't move the mouse, the launcher should disappear
[16:36] <didrocks> but if you press, and in a 1s timeout, you move the mouse, the launcher shouldn't disappear
[16:36] <didrocks> (this is with a window under the launcher of course)
[16:36] <didrocks> om26er: makes sense? ^
[16:36] <didrocks> the 1st behavior regressed, I guess it's because of nux events
[16:36] <om26er> "if you press on an launcher icon, and don't move the mouse, the launcher should disappear" this is problematic for me :/
[16:37] <Cimi_> Trevinho: I would abstract your code a little bit more
[16:37] <Cimi_> Trevinho: I would create a basic animation class
[16:38] <om26er> didrocks, it was better in 11.04 for sure (but not ideal for me still)
[16:38] <Cimi_> Trevinho: that class will load callback functions on each frame, and will automatically skip frames if needed
[16:38] <Cimi_> Trevinho: I'm doing that for overlay scrollbars, for example
[16:38] <didrocks> om26er: this was like that in 11.04
[16:39] <Cimi_> Trevinho: I think it makes more sense than creating a class for Fade, a class for ... etc etc
[16:39] <didrocks> om26er: oh, and I forgot one case, if you press an icon, move the cursor outside of the launcher, there is no 1s timeout
[16:39] <om26er> didrocks, i'll email your messages to andyrock so that he is also aware of the desired behavior
[16:39] <om26er> didrocks, this last case seems not to be an issue in Oneiric
[16:40] <Cimi_> http://bazaar.launchpad.net/~ayatana-scrollbar-team/ayatana-scrollbar/trunk/view/head:/os/os-animation.c Trevinho
[16:40] <Cimi_> let me know what do you think
[16:40] <didrocks> om26er: so the only broken case from the desired behavior right now is "mouse in the launcher area with launcher hidden, press super, don't move -> should hide"
[16:40] <didrocks> om26er: thanks:)
[16:40] <didrocks> om26er: yeah, only the 1st one is broken
[16:40] <om26er> didrocks, yw :)
[16:41] <didrocks> I really bet it's nux sending a "widget enter" events when the launcher move
[16:41] <om26er> and webapps dont seem fixed to me with latest bamf, i might be doing something wrong :/
[16:42] <didrocks> om26er: only with chrome
[16:42] <didrocks> om26er: I mentionned it on the bug :)
[16:42] <om26er> didrocks, and not chromium?
[16:42] <didrocks> nope :/
[16:42] <om26er> didnt see your comment
[16:42] <didrocks> om26er: DBO will work on a patch
[16:42]  * om26er downloads chrome :D
[16:43] <Trevinho> Thanks Cimi... I was thinking that too
[16:43] <didrocks> om26er: I wasn't that extreme to check it works, I believed DBO when we discussed it and I discovered it didn't work with chromium ;)
[16:43] <Trevinho> however since my code was just a draft I didn't worked too much on the design
[16:43] <Cimi> Trevinho: basically, you could translate that class into C++
[16:43] <om26er> didrocks, i'll test as it installs ;-)
[16:44] <Cimi> Trevinho: then if you want, you could create a fadecontroller which uses the animation class and only works with opacity
[16:44] <Trevinho> Also I guess I'm moving back to g_timeout, since the nux timer seems too lazy
[16:44] <didrocks> om26er: if it doesn't work, blame him! :-)
[16:44] <Trevinho> Ok, thanks Cimi.
[16:44] <om26er> didrocks, will ;)
[16:44] <Cimi> Trevinho: I don't know how to work well with C++, you're much better than me. Albeit that animation class is pretty solid
[16:45] <Cimi> Trevinho: if you remove the objects or so, animation stops without segfaulting
[16:45] <Cimi> I'm pretty happy for that piece of code
[16:45] <Cimi> small, light and functional
[16:45] <Trevinho> ah, nice :)
[16:45] <Trevinho> I also handled that in a raw way, but it should work
[16:46] <Trevinho> However maybe an an animation class which calls an animator object with a special method for doing the requested animation should work I guess
[16:47] <Trevinho> but before writing nice APIs I've to make it work as I want :P
[16:47] <Trevinho> also C++ is not my favorite place to write, but that we must use :P
[16:48] <Cimi> 1 class to deal with timings and objects, if you want 1 class for basic and shared animations
[16:48] <Trevinho> Ok... Howver I didn't implemented that until now
[16:49] <Cimi> I know, I just want to optimize your code :-)
[16:49] <Trevinho> since jay told me he would have handled this better in nux in future
[16:49] <Cimi> definitely
[16:49] <Trevinho> yes, thanks Cimi
[16:49] <Cimi> dealing with animations in this way is pretty hackis
[16:49] <Cimi> and it's not so perfectly synced
[16:49] <Cimi> because it goes through gtk main thread
[16:50] <Trevinho> Eh, that's our problem
[16:50] <Cimi> well, glib not gtk
[16:50] <Cimi> maybe it0s better
[16:50] <Trevinho> yes, of course
[16:51] <Cimi> definitely something it's better to discuss at the UDS :-)
[16:51] <Cimi> especially as we need to plan Nux 2.0
[16:51] <Trevinho> yes, I just talked a little with Jay about this
[16:51] <Cimi> cool
[16:52] <Trevinho> However he told me that with the current Nux I have to make redraw my widget at every change in the way I've done I guess
[16:53] <Trevinho> Cimi: about the other thing (i.e. the white icons)... Do you have any idea in how we could  improve them?
[16:53] <Trevinho> The fact is that we should both manage dark and white icons with the same mask
[16:54] <Cimi> Trevinho: i'd like to see your code
[16:54] <Cimi> Trevinho: how did you make it to have it correctly rendered for the kbd icon?
[16:54] <Trevinho> Cimi: my code doesn't work correctly for themes with dark icons...
[16:54] <Cimi> oh ok...
[16:54] <Trevinho> But in that case I just applied a white mask over the icons
[16:55] <Cimi> right, got the point
[16:55] <Trevinho> using the ADD method of Nux
[16:55] <Trevinho> PLUS, sorry
[16:55] <Trevinho> however it's a GL_ONE, GL_ONE mask
[16:55] <Cimi> maybe we can do that with cairo, let me see
[16:55] <Trevinho> so I jept cairo out
[16:55] <Trevinho> kept*
[16:55] <Trevinho> yes, I guess... but I used nux to avoid to redraw the pixmap at all
[16:56] <Trevinho> we just use a mask over with nux
[16:56] <Trevinho> by the way the main issue is that if we can't catch the dominant color of an icon, we can't apply the right mask
[16:58] <Trevinho> I didn't look to this too much, since I had no time, but I guess that if we can know what kind of icon we have, then we can apply the right mask...
[16:58] <Cimi> maybe CAIRO_OPERATOR_IN
[16:58] <Trevinho> Just wondering by the way, I'm not that experienced with cairo...
[16:58] <Cimi> mmm
[16:58] <Cimi> well, I think I'm wrong
[16:58] <Trevinho> I checked, but in the current code changing just an operator is not enugh
[16:59] <Cimi> the issue is that the icon has dark points, and not points with alpha = 0
[16:59] <Cimi> so, it's a bit harder
[16:59] <Trevinho> Ok... I got a solution: ask designers to draw a mono icon :P
[16:59] <htorque> probably also difficult with the always changing multiload indicator icons?
[17:00] <Trevinho> since we ship that by default, I guess it should be handled correctly
[17:00] <Trevinho> however Cimi another issue that I underlined in my yesterday's screenshot is that you can't draw an "active" icon... Like the blue envelope at the current state
[17:01] <Cimi> yep
[17:05] <om26er> make does not work using trunk http://pastebin.ubuntu.com/695198/
[17:05] <om26er> is it complaining for nux trunk?
[17:08] <Trevinho> so it seems
[17:10] <didrocks> yeah, it needs latest nux trunk
[17:10] <didrocks> but it can run with older nux
[17:25] <Trevinho> Cimi: I've read your lib, it's nice
[17:26] <Trevinho> I guess I could do the same... Also, not to create abstract objects or depending on  function pointers I guess I could use simply signals
[17:26] <Trevinho> thank you
[17:30] <Trevinho> Cimi: another thing you could add to the anumation is to make it animate until it reaches a defined peek... Like AnimateUtil.... Of course it could be done also using the cb function and checking for the current value, but managin it in the class would make it better I guess.
[17:32] <Cimi> Trevinho: there's no need to a threshold
[17:33] <Cimi> Trevinho: you have a float from 0 to 1
[17:33] <Cimi> you can now play with it and set your own logic
[17:34] <Cimi> it's not like you say "this animation does from 0 to 0.5", it's exactly as saying from 0 to 1 with a different timing
[17:34] <Trevinho> Yes, of course... I was just saying this from an API design point of view
[17:34] <Cimi> in what my library could be improved is adding apis to control parameters, but I added just what I needed
[17:34] <Trevinho> Ok
[17:34] <Trevinho> I also would need to set a starting point....
[17:35] <Trevinho> also if.. I guess that I can manage that also on the callback
[17:35] <Cimi> especially from the API point of view you should *not* add uneeded APIs, and changing the threshold looks line something unneeded, as you can do the same in the callback functio
[17:35] <Cimi> exactly
[17:36] <Cimi> animation is simply an abstract class that calls a function periodically, given a RATE, for a defined TIME, and calls the function with a float from 0 to 1
[17:37] <Cimi> in the callback function you deal with the real stuff, leaving the animation class agnostic
[17:38] <Trevinho> Cimi: basically nux::TimerFuctor AddPeriodicTimerHandler would do the same... But I don't know why it's slower
[17:38] <Cimi> Trevinho: maybe it doesn't skip frames?
[17:38] <Trevinho> I guess it's bugged, but I didn't check the code
[17:38] <Cimi> ok
[17:38] <Trevinho> Mh, no... It seems that calls the cb too late
[18:45] <andyrock> om26er, around?
[20:29] <Trevinho> Cimi I've done my new implementation and works well ;)
[20:29] <Cimi> cool
[20:29] <Trevinho> I basically ported your lib, but using some slight differencies
[20:29] <Trevinho> for example, now i can set the starting point of an animation
[20:30] <Trevinho> to continue an animation interrupted in at a given point
[20:30] <Cimi> Trevinho: you can do the same with my code
[20:31] <Cimi> Trevinho: it's something you can handle in the callback function
[20:31] <Trevinho> Cimi: I know that...
[20:31] <Trevinho> but I want control it when starting too
[20:31] <Cimi> I think that starting an animation from a middle point does not make any sense
[20:32] <Cimi> it's like scaling an animation
[20:32] <Trevinho> Cimi it happens... Think... I'm fading out, then I need to re-fade it in....
[20:32] <Cimi> what do you want it to decrease the length for example
[20:32] <Trevinho> I must start from the previous alpha value
[20:32] <Cimi> Trevinho: doing the same in overlay scrollbars
[20:32] <Cimi> Trevinho: when you hover them in an inactive window
[20:33] <Cimi> they are grey -> orange -> grey
[20:33] <Trevinho> Cimi: decreasing the lenght is duable, but I need more computations that my animator can do
[20:33] <Cimi> try it
[20:33] <Trevinho> however wait... I push the code in bzr
[20:37] <Cimi> I need to think a little bit more about that
[20:37] <Cimi> cause you can always store the weight float from the previous animation, before starting the new one
[20:37] <Cimi> so, maybe you're right
[20:38] <Cimi> or maybe you can do the same with the callback function
[20:38] <Cimi> in any case, I don't know if it worth starting an animation from a middle point
[20:39] <Cimi> what happens to timing? imagine you set 1 second from 0 to 1, if you start from 0.5 will it take 1 second to reach 1? or 0.5?
[20:40] <Cimi> in theory I think the animation code should be agnostic
[20:40] <Cimi> and the fade callback function should handle this thing
[20:53] <Trevinho> Cimi: well... The fact is, as you say, the callback should then store the starting value and use it to check the new value at every callback.
[20:53] <Trevinho> But I'd prefer  it to do on the base class.
[20:54] <donri> hi, can i get back non-global menubar somehow?
[20:55] <Cimi> Trevinho: the base class is less abstract, then
[20:55] <donri> i recall there was some envvar during early devel?
[20:55] <Cimi> Trevinho: that's why I think it's better to keep it in the callback
[20:55] <Cimi> Trevinho: otherwise you need to store it everytime, even when it's not needed
[20:55] <Cimi> Trevinho: so, it's even less optimal
[20:56] <Cimi> donri: export UBUNTU_MENUPROXY=0
[20:57] <Trevinho> I know, but I've to do compromises :)
[20:57] <Cimi> anyway, let me see the code
[20:57] <Cimi> maybe it's nicer as you say
[20:58] <donri> thanks
[21:05] <Trevinho> Cimi: lp:~3v1n0/unity/fading-panelmenu
[21:06] <Trevinho> the code in the panel should be better, but this was just my first draft
[21:11] <Cimi> Trevinho: you're not checking for current running animations when setting rate and duration. I'm not sure wheter they should be stopped or if it's in charge of who calls those functions to stop the animation before
[21:13] <Trevinho> Cimi: you're right...
[21:13] <Cimi> Trevinho: hold on, I'm not sure
[21:13] <Trevinho> Since I wasn't using them, I just focused me on the rest and I just left there the default implementation
[21:13] <Cimi> Trevinho: I mean, could it be possible that someone wants to reduce the duration?
[21:13] <Cimi> in realtime?
[21:14] <Cimi> but then, if someone wants that, it will screw the weight
[21:14] <Trevinho> Mh, It could be possible... but also stopping the animation and restarting it with different values
[21:14] <Cimi> as the time diff will immediately change
[21:14] <Cimi> so, I'm tempted to say let's stop it
[21:14] <Trevinho> I don't remember if you were stopping them
[21:16] <Cimi> from coding style, I'd use MAX/MIN in Start()
[21:16] <Cimi> instead if progress < 0 -> progress = 0
[21:16] <Cimi> progress = MAX (0, progress)
[21:17] <Cimi> or CLAMP if you want to clamp it
[21:17] <Trevinho> Well, yes but since it's a C-ism.... I was avoidng it
[21:17] <Cimi> OH OK
[21:17] <Cimi> I am a c++ newbie
[21:17] <Trevinho> but the unity code is not completely clean
[21:17] <Trevinho> we mix everything there
[21:18] <Trevinho> Surely it's not everywhere beautiful to read, but it works :P
[21:18] <andyrock> Cimi, we know you're a c++ newbie and a python lover ;)
[21:18] <andyrock> ahahah
[21:18]  * Cimi hits andyrock
[21:19] <Cimi> Trevinho: I still think the idea of starting an animation in the middle is a bit weird :-\
[21:19] <Trevinho> About the fading timings...  I currently set...
[21:19] <Trevinho> _fade_in_animator = new Animator(200, 150);
[21:19] <Trevinho>  _fade_out_animator = new Animator(200, 400);
[21:19] <Trevinho> But maybe a change every 5ms is too high for fast animations? isn't it?
[21:20] <Cimi> 200??? °_°
[21:20] <Cimi> 30 FPS is fine man
[21:21] <Cimi> don't kill our CPUs :-)
[21:21] <Trevinho> Ohhh ok :)
[21:21] <Trevinho> I want smooth things! :D
[21:21] <Cimi> Trevinho: your monitor refreshes at 60 FPS
[21:21] <Cimi> Trevinho: 200 are useless
[21:30] <Trevinho> ok, you're right :D
[21:30] <Trevinho> Cimi: in the bug related to the fading menu entries, Mark said that the wanted design behavior is to show the menus the more you are near to the panel...
[21:31] <Trevinho> Is this still valid?
[21:31] <Cimi> I can ask him
[21:31] <Cimi> he's online
[21:31] <Cimi> Trevinho: link to bug report?
[21:31] <Trevinho> Cause I think that is doable right now...
[21:31] <Trevinho> wait
[21:32] <Trevinho> Cimi: https://bugs.launchpad.net/unity/+bug/691776
[21:34] <Cimi> Trevinho: do you have an input window near it?
[21:36] <Trevinho> Cimi: I don't but, I guess that compiz gives us the mouse position... I've to check... Anyway also maybe slower but working gdk event filter would do the job
[21:36] <Cimi> Trevinho: I know, but i'd like to avoid that
[21:37] <Cimi> Trevinho: i'm not keen on tracking mouse position
[21:39] <Trevinho> Mh, well... We don't have many other possibilities I guess. An event window that doesn't grab anything should be fine, by the way
[21:45] <Cimi> Trevinho: let's ignore it for the moment
[21:45] <Cimi> Trevinho: I'all afk a bit, quite tired...
[21:46] <Trevinho> Ok... Thank you Cimi... See ya
[21:46] <Cimi> yup ;)
[22:10] <andyrock> DBO the indicator menus should be shown at f10 pressed or f10 released?
[22:10] <DBO> released
[22:11] <Lirodon> Hello
[22:12] <andyrock> DBO, can i ask you why? :) I'm curious for no other
[22:12] <andyrock> Lirodon, hi
[22:12] <DBO> andyrock, so if you uhhhh no idea
[22:13] <andyrock> DBO btw if i keep the f10 key pressed weird things happen...
[22:13] <DBO> yeah thats weird
[22:13] <andyrock> let me give a look to it
[22:14] <Lirodon> I'm trying to get some traction going on a GRUB redesign
[22:14] <DBO> its cycling
[22:14] <DBO> its the same thing as holding aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
[22:14] <DBO> like that
[22:14] <DBO> so its just getting fuckloads of "show" calls
[22:15] <Lirodon> http://i.imgur.com/TgxQv.png i.e. this.
[22:18] <Lirodon> I was told this would be possible in GRUB2
[22:24] <andyrock> Lirodon, maybe this is not the right place to speak about this
[22:24] <Lirodon> andyrock, Isn't Ayatana related to design?
[22:24] <Lirodon> or is that just the desktop design?
[22:25] <Lirodon> Cause well, #ubuntu-artwork is inactive, and someone in #ubuntu-devel suggested I try here (even though I personally think that something like this would be a cross between artwork and devel)
[22:25] <andyrock> Lirodon, i think it is just dekstop design...
[22:26] <Lirodon> Though, since your work has helped "define" the current look of Ubuntu as a whole, getting input from here can be valuable too
[22:35] <Viper550> I'm gonna try and see if I can start making that for real, I'm downloading the 11.10 beta now