[05:45] <didrocks> good morning
[06:58] <davidyu> Hi
[07:44] <jono> MacSlow, glad you weighed in on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/824916
[07:44] <jono> this is what I figured would be a good solution too
[07:47] <MacSlow> jono, I never understood why this wasn't done in the first place... this solution is "battle-proven" in notify-osd for some cycles now... and it would add to making things look more consistent. We'll see what Design thinks about it.
[07:48] <jono> MacSlow, totally agree
[07:48] <MacSlow> hey andyrock
[07:48] <jono> it sounds like it just needs to design sign-off
[07:48] <andyrock> hey MacSlow
[07:48] <MacSlow> jono, yup
[07:48] <jono> and someone on DX to own the bug and get the design sign-off
[07:49] <davidcalle> MacSlow, wasn't there the idea during the cycle to make notify-osd take the same color as the Dash and alt+tab?
[07:49] <MacSlow> jono, I guess that would be me (due to my nosd-legacy and having done most of the text-rendering anyway).
[07:50] <davidcalle> I remember seeing some commits about that.
[07:50] <MacSlow> davidcalle, yes... I worked on that... but it's not reviewed and there are some other things we've not made up our minds on yet.
[07:50] <davidcalle> MacSlow, ok :)
[07:51] <MacSlow> davidcalle, check http://people.canonical.com/~mmueller/notify-osd-avgerage-bg-color-1.jpg (1..7)
[07:52] <davidcalle> MacSlow, I've already seen it. Now we just need the panel to take this color ;)
[07:54] <davidcalle> Hi njpatel
[07:54] <jono> MacSlow, would you be happy to talk to the design team today to get a +1 on that and move this bug forward?
[07:58] <MacSlow> jono, generally yes... but I don't want to break the "line of organization" allocating bug-fixing time :)
[07:58] <jono> aha! ;-)
[07:59] <jono> so long as it gets fixed, whatever is easiest :-)
[07:59] <jono> fortunately it is a pretty cosmetic bug
[07:59] <jono> thanks ma
[07:59] <jono> thanks MacSlow
[07:59] <jono> I am heading to bed now :-)
[07:59] <MacSlow> jono, good night
[08:01] <andyrock> i just woke up and jono's going to go to bed :)
[08:01] <jono> andyrock, bonkers, eh? :-)
[08:01] <jono> night all!
[08:01] <jono> keep on rocking in the free world :-)
[08:16] <njpatel> davidcalle, hey
[08:20] <davidcalle> njpatel, I'm switching back to python for lens developement. Jono wants a working one before release and I don't think I'm going to make it in time with Vala, at least not with the features I want.
[08:20] <davidcalle> So, I have one question :)
[08:21] <njpatel> davidcalle, makes sense
[08:21] <njpatel> davidcalle, kamstrup is back too, so I think he can help with making the python stuff work nicely
[08:22] <davidcalle> njpatel, he just got back, I won't harass him before at least a week ;)
[08:22] <njpatel> davidcalle, no, no, it's good to harass him, he likes it
[08:22] <kamstrup> davidcalle: I'm still setting up my dev environment, but should be up to speed soon
[08:23] <davidcalle> kamstrup, great
[08:23] <kamstrup> njpatel: no, no... you "caress" not "harass"!
[08:59] <andyrock> njpatel gord, when dragging from a "not fullscreen dash" to desktop using a short and continuous mouse move
[08:59] <andyrock> it's impossible draggins something on the desktop
[08:59] <andyrock> without using an extra click
[08:59] <andyrock> *extra move
[08:59] <andyrock> the problem is more evident using a touchpad
[08:59] <njpatel> andyrock, with trunk?
[08:59] <andyrock> yes...
[09:00] <andyrock> and the problem is not due to DNDCollectionWindow
[09:00] <andyrock> I disabled it
[09:00] <andyrock> the problem is:
[09:00] <andyrock> 1) when the dash x window is moved offscreen
[09:01] <andyrock> the hovered input window doesn't became the dnd target window
[09:01] <andyrock> without an extra mouse move
[09:01] <njpatel> ah, weird
[09:01] <andyrock> we can create a fake mouse move
[09:01] <andyrock> but there is a race condition
[09:02] <andyrock> in fact what happen if the mouse il released when the dash window is still onscreen
[09:05] <andyrock> i've the same problem in DNDCollectionWindow and no idea how to solve the race condition
[09:05] <andyrock> it happens not so often, but it's not good
[09:18] <andyrock> Trevinho, around?
[11:09] <Andy80> hi guys
[11:33] <andyrock> JohnLea, https://bugs.launchpad.net/unity/+bug/764673
[11:33] <andyrock> i no longer have this bug
[11:42] <JohnLea> andyrock; just tested with the latest Oneiric, still present but now somewhat intermittent
[11:43] <JohnLea> andyrock, open 3 windows of the same app, minimise 1, select one of the other windows, and then start repeatedly clicking on that app's launcher icon
[11:44] <JohnLea> andyrock; the minimised window flickers before disappearing when leaving the spread, and after a few time of opening/leaving the spread it magically un-minimises itself
[11:45] <andyrock> JohnLea, one window disappears...
[11:45] <JohnLea> andyrock; ?
[11:46] <andyrock> open 3 windows of the same app, minimise 1, select one of the other windows, and then start repeatedly clicking on that app's launcher icon
[11:47] <JohnLea> andyrock; what should happen is that the first click should: open the spread showing all three windows.
[11:47] <JohnLea> the second click should then: close the spread and leave the two open windows displayed
[11:47] <JohnLea> the third click should be the same action as the first click
[11:48] <JohnLea> the forth the same as the second, ect...
[11:48] <JohnLea> does that make sense?
[11:48] <andyrock> JohnLea, totally... but it's a "smspillaz bug"
[11:50] <JohnLea> andyrock; I've just pinged Sam to jump on to this channel if he is about, but I think it is very very early in the morning for him now
[11:51] <JohnLea> andyrock; have you worked on this bug already, or were you just about to start?
[11:52] <andyrock> JohnLea, i've already worked on scale plugin...
[11:53] <andyrock> but right now i cannot work on it because for weird reason i can no longer build it from sources
[11:54] <andyrock> i've to fix first of all the timeout problem in scale plugin but for the above reason i cannot
[11:58] <Trevinho> andyrock: did you ask for me before?
[11:58] <andyrock> Trevinho, private chat so we can speak Italian :)
[12:02] <smspillaz> andyrock: hi
[12:03] <smspillaz> andyrock: someone asked me to poke you about https://bugs.launchpad.net/ayatana-design/+bug/764673
[12:04] <andyrock> smspillaz, JohnLea did
[12:05] <andyrock> well first of all when I try to build scale plugin from lp:compiz-core
[12:06] <andyrock> i get a cmake error
[12:07] <andyrock> http://paste.ubuntu.com/678839/
[12:08] <andyrock> i get the same error from lp:compiz-core and apt-get source compiz...
[12:10] <smspillaz> hang on
[12:10] <smspillaz> I might not have resynced that repo
[12:10] <smspillaz> hmm actually
[12:11] <smspillaz> if you're building lp:compiz-core you shouldn't get that
[12:11] <smspillaz> are you building all of lp:compiz-core or just the scale plugin on its own?
[12:12] <smspillaz> since I don't think building the plugins within lp:compiz-core on their own is supported just yet with the release code I wrote (I need to fix that)
[12:12] <andyrock> smspillaz, just the scale plugin
[12:12] <smspillaz> in fact, I'll do that right now so that I don't forget
[12:23] <smspillaz> andyrock: ok, I'll be about 5 minutes
[12:23] <smspillaz> (in order to check if this works I actually need to install compiz temporarily)
[12:24] <andyrock> smspillaz, np...
[12:29] <smspillaz> andyrock: lp:~compiz-team/compiz-core/compiz-core.dont_require_version
[12:29] <smspillaz> (awaiting review)
[12:29] <smspillaz> https://code.launchpad.net/~compiz-team/compiz-core/compiz-core.dont_require_version/+merge/73520
[12:30] <andyrock> smspillaz, ok thx.... about minimized windows.
[12:30] <smspillaz> andyrock: yah
[12:30] <andyrock> sometimes when i minimed chromium (other apps too)
[12:30] <andyrock> it receive mouse inputs
[12:31] <smspillaz> andyrock: have you got the "keep previews of minimized windows" option enabled in the workarounds plugin ?
[12:31] <andyrock> no...
[12:31] <smspillaz> ok
[12:31] <smspillaz> I just know that one is broken and I haven't had time to fix it
[12:31] <andyrock> and i run unity --reset to be sure
[12:31] <smspillaz> I haven't been able to reproduce this myself, though if you can let me know what apps particularly trigger it then I might be able to look into it
[12:31] <smspillaz> otherwise
[12:31] <smspillaz> in unity/tests
[12:32] <smspillaz> there's a test there called test-minimize-handler
[12:32] <smspillaz> so if you go into build/tests/test-minimize-handler
[12:32] <smspillaz> and then run it with ./test-minimize-handler window_id
[12:32] <smspillaz> where window_id is the id you get from xwininfo
[12:32] <smspillaz> it will simulate what's going on
[12:32] <smspillaz> and if you can still interact with the window while its visible
[12:33] <smspillaz> then there's a problem with that app
[12:33] <smspillaz> (also try test-input-remover too)
[12:33] <smspillaz> (I knew these would come in use!)
[12:34] <andyrock> i'll do it
[12:35] <andyrock> so the window id of chrome is 0x3c00044
[12:36] <andyrock> i run the test passing this it
[12:36] <andyrock> now using 'm' and 'u' i should be able to minimize/unminimize it?
[12:38] <smspillaz> simulate minimize
[12:38] <smspillaz> so it won't actually minimize
[12:39] <andyrock> i've the problem right know
[12:39] <andyrock> chrome is minimize
[12:39] <andyrock> but if i right click on the desktop
[12:39] <andyrock> i get the chrome context menu
[12:39] <smspillaz> ok
[12:39] <smspillaz> try this one
[12:40] <smspillaz> xwininfo -tree (on the chromium window while it's unminimized)
[12:40] <smspillaz> and then xwininfo -id (the specified parent window twice)
[12:40] <smspillaz> that will get you the frame window
[12:40] <smspillaz> and then do  tests/test-input-remover (the frame window id)
[12:40] <smspillaz> and then do  tests/test-input-remover (the frame window id) 10 actually
[12:41] <smspillaz> since maybe chromium is changing its input shape
[12:41] <smspillaz> ah
[12:41] <smspillaz> hang on
[12:41] <smspillaz> are you using chromium's client side decorations ?
[12:41] <andyrock> yes
[12:41] <smspillaz> that would be it
[12:41] <smspillaz> yep, I can reproduce that
[12:41] <smspillaz> sweet
[12:41] <andyrock> but sometime i get the same error with geany and xchat
[12:42] <andyrock> no so ofter
[12:42] <smspillaz> can you file a bug saying that when you've got chromium's client side decorations on the window shape changes and we don't respond to that ?
[12:42] <andyrock> when it will happens i'll send you more info
[12:42] <andyrock> of course
[12:42] <smspillaz> cheers
[12:42]  * smspillaz knew there would be problems with this *sigh*
[12:43] <smspillaz> add that to the list of my 1 billion reasons why CSD is evil
[12:43] <smspillaz> though I guess it sort of doesn't count since removing input shape + inhibiting painting is also evil
[12:44] <andyrock> i read your blog post ;)
[12:44] <smspillaz> I saw
[12:45] <smspillaz> let me know when you get up and running with the scale plugin
[12:45] <smspillaz> I'm just finishing some delicious hacks on the expo plugin
[12:46] <andyrock> Using chromium's client side decorations minimizing it, it is still able to catch input event
[12:46] <andyrock> is it a good title? i really need to improve my English
[12:49] <smspillaz> sounds great
[12:51] <andyrock> https://bugs.launchpad.net/unity/+bug/838062
[12:53] <htorque> hm, i've also seen that with ccsm
[12:59] <davidcalle> Midori does it.
[13:00] <smspillaz> can you all get me steps to reproduce then ? :)
[13:07] <davidcalle> Midori : 1) Make sure every other windows are minimized. 2) Open Midori. 3) Minimize it. 4) Type. -> Midori urlbar history is displayed on the desktop.
[13:07] <davidcalle> smspillaz, ^
[13:09] <htorque> i'm not sure how to reproduce it with ccsm, i just remember that i minimized it (all other windows were minimized) and wanted to click on the desktop -> a pulldown menu from ccsm appeared
[13:13] <kenvandine> Kaleo, good morning
[13:13] <kenvandine> is unity-2d not honoring the same gsettings key for the systray whitelist?
[13:19] <Kaleo> kenvandine: good morning
[13:19] <kenvandine> Kaleo, oh... unity-2d has something for displaying a legacytray ...
[13:19] <Kaleo> kenvandine: no we don't have the whitelist
[13:20] <kenvandine> Kaleo, so we have to patch all the apps that use the systray again?
[13:20] <Kaleo> kenvandine: the legacytray is the systray
[13:20] <kenvandine> ugh... too late in the cycle to do that
[13:20] <kenvandine> there have been users complaining about getting gnome-power-manager there too
[13:20] <Kaleo> I see
[13:20] <Kaleo> I thought they were patched already from Natty
[13:20] <kenvandine> i think they have all been dropped...
[13:21] <Kaleo> kenvandine: well, that's very sad and unexpected
[13:21] <kenvandine> :(
[13:21] <Kaleo> kenvandine: if I am correct the simplest thing is to implement the whitelist in u2d right?
[13:21] <kenvandine> Kaleo, yes
[13:22] <kenvandine> i thought the plan for this cycle was to make unity-2d have more infrastructure in common with unity3d
[13:22] <kenvandine> i would expect to see the same indicators in both environments
[13:22] <Kaleo> kenvandine: the indicators are the same
[13:22] <Kaleo> kenvandine: just not the systray
[13:23] <Kaleo> kenvandine: task logged as https://bugs.launchpad.net/unity-2d/+bug/707354
[13:24] <kenvandine> Kaleo, right... but i think if you are loading the same indicators as unity3d
[13:24] <kenvandine> you get the whitelist for free
[13:24]  * kenvandine could be wrong... 
[13:24] <kenvandine> didrocks, ^^
[13:25] <Andy80> was, any Natty+GoogleMusicUploader user, able to make it work? I can't see the icon in the indicator using Unity, while I see it normally in Ubuntu Classic session...
[13:25] <didrocks> the whitelist is in libunity-misc
[13:25] <didrocks> which makes the rendering IIRC, not related to the panel lservice
[13:26] <kenvandine> good
[13:26] <htorque> before i file a bug report: are file results in the dash search are supposed to show up before application results? if i hit super, type 'xchat', and hit enter, it shows me "xchat.png" rather than starting xchat
[13:26] <kenvandine> Kaleo, does that help?
[13:26] <Kaleo> kenvandine: yeah, it means that we have our own support for systray, separate from u3d
[13:27] <kenvandine> which i thought you wouldn't need to do anymore...
[13:27] <didrocks> the whitelist should simply be in the panel service, that would be easier
[13:27] <Kaleo> didrocks: it sounds a bit late for that, no?
[13:28] <kenvandine> didrocks, right... but he shouldn't need his own legacytray right?
[13:28] <didrocks> Kaleo: depends, the code for the reject is small and can be relocated/tested easily
[13:28] <kenvandine> Kaleo, it is far less intrusive than patching a bunch of apps
[13:29] <Kaleo> didrocks: it's not just the reject, AFAIK the systray items are not exposed by the unity-panel-service
[13:29] <kenvandine> Kaleo, and it would make the behavior between unity and unity-2d more consistent, which is important
[13:29] <Kaleo> kenvandine: well, definitely
[13:30] <didrocks> Kaleo: ah, in that case, sux, indeed
[13:30] <Kaleo> kenvandine: we will implement the whitelisting in our systray as per the bug
[13:30] <kenvandine> Kaleo, i guess just make it share the same gsettings key
[13:31] <Kaleo> kenvandine: exactly
[13:31] <kenvandine> Kaleo, thx
[13:39] <Andy80> new bug ( #838103 ) reported ;)
[13:39] <Andy80> (the bot is sleeping....)
[13:41] <JohnLea> Trevinho; hyia, I'm just reviewing Oneiric and I noticed your patch to bug #690143 has not yet landed.  Is there anything blocking this that I can help with?
[13:43] <JohnLea> Trevinho; I would like to test your new backlight mode in the next round of user testing ;-)
[13:44] <beevvy> are there any plans to make libindicate-qt not dependent on the glib libindicate?
[13:44] <beevvy> agateau: ^^
[13:45] <agateau> beevvy: no, there is no such plan
[13:46] <beevvy> agateau: ok, thanks
[13:47] <htorque> JohnLea: that should be in http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/1462 AFAIK
[14:10] <apw> do we expect oneiric to be able to handle external monitors plugged in ?
[14:11] <apw> i am seeing compiz crashing out
[14:11] <smspillaz> yes
[14:11] <smspillaz> apw: stacktrace ?
[14:11] <apw> smspillaz, waiting for the bug thing to do its thing
[14:11] <smspillaz> apw: I hotplug monitors all the time so this comes as a bit of surprise to me :)
[14:11] <apw> smspillaz, what h/w do you use
[14:12] <apw> i am hearing multiple reports of utter failure with intel graphics on netbooks
[14:13] <apw> smspillaz, i assume the crash report that apport takes has the stack trace in it?
[14:15] <apw> smspillaz, excellent keyboard no longer works ... luckily i can cut-n-paste in apport's bug
[14:15] <smspillaz> apw: nouveau 8800GT
[14:15] <apw> bug #838128
[14:15] <smspillaz> apw: I think in cases where you plug a monitor in where the combined resolution would be more than your maximum texture size you can expect problems
[14:16] <smspillaz> apw: I know that the maximum texture size on intel is *excessively* low
[14:16] <apw> smspillaz, what still, we reallly don't want to support netbooks do we
[14:16] <smspillaz> apw: of course we support netbooks
[14:16] <apw> smspillaz, the monitor would push us over 2048 wide which is likely the texture width indeed
[14:17] <apw> but no one output is more than the texture size
[14:17] <smspillaz> apw: it's a development version for a reason ;-) I've been discussion how to handle this problem with jaytaoko for the past week now and I've got some ideas about it, but its complicated
[14:17] <apw> smspillaz, well it worked in natty so we must have known how to fix it before
[14:18] <smspillaz> apw: in natty we weren't doing things like redirecting output into a giant fbo :)
[14:18] <smspillaz> (for real time blurs and the like)
[14:18] <apw> smspillaz, well we did for the first half of the cycle, and then we fixed it cause it broke netbooks
[14:19] <smspillaz> apw: the fbo support didn't land till quite late in the cycle actually
[14:19] <smspillaz> apw: anyways, the point being that I have some ideas on how to fix this
[14:19] <smspillaz> apw: but its complicated and I need to sit down with jay and work it out
[14:19] <smspillaz> so once I've got some other stuff on my plate, I'll get on to this, don't worry
[14:19] <smspillaz> *off my plate
[14:20] <drussell> I notice there are quite a few bugs with the unity launcher not autohiding... is there a particularly well known issue that explains what I'm seeing on a fully updated 11.10 today?
[14:20] <drussell> it's only started happening today
[14:20] <smspillaz> drussell: yes, it will be fixed tomorrow
[14:20] <drussell> smspillaz: ahh cool, do you have the bug number to hand that I should keep an eye on?
[14:20] <smspillaz> drussell: not on me, no
[14:23] <drussell> smspillaz: ok, thanks, feel free to ping it @ me ;o)
[14:23] <apw> do we know about the idle brightness being sometimes higher than the busy brightness on battery; and is gnome-setting-daemon still on the hook for such bugs?
[14:24] <smspillaz> apw: fyi, for now the workaround is to arrange your monitors so that your combined resolution doesn't exceed 2048 pixels in any direction
[14:25] <smspillaz> usually that means a top/bottom configuration rather than a left/right one
[14:25] <apw> smspillaz, while that is a reasonable request, with intel graphics it autodetects the plug and automatically puts it on the right
[14:25] <smspillaz> apw: I think there's a way to tell xrandr not to do that
[14:25] <apw> and blows you up in a heap completly without a window manager before you can do 'owt about it
[14:26] <smspillaz> apw: can't remember what it was off the top of my head though
[14:26] <apw> smspillaz, can you remind me how to ask the render width
[14:27] <smspillaz> apw: ???
[14:27] <apw> smspillaz, couldn't compiz at least not display on the right of the screen
[14:27] <apw> ie just stop short at 2k pixels when the render size is too small
[14:28] <apw> smspillaz, there is some glx command which spits out the max renderable XxY
[14:28] <Kaleo> kenvandine: the whitelist support is under review now
[14:29] <smspillaz> apw: the correct solution is to use multitexturing
[14:29] <smspillaz> err
[14:29] <smspillaz> multiple textures
[14:29] <smspillaz> multitexturing is something different
[14:29] <smspillaz> apw: compiz can already do this btws
[14:29] <smspillaz> err
[14:29] <smspillaz> *btw
[14:29] <smspillaz> fingers aren't working right today
[14:29] <smspillaz> apw: disable unity and enable the "copy to texture" plugin in ccsm and compiz should be able to handle the monitor just fine
[14:29] <apw> smspillaz, i am happy with the right soln.  i am wondering if we could bodge something to just carry on and leave the right side of my screen as not there at all, but at least not make core files and let me move the display
[14:30] <smspillaz> apw: ah
[14:30] <kenvandine> Kaleo, cool
[14:30] <smspillaz> apw: well, you could force your output dimentions before you plug in your monitor
[14:30] <smspillaz> apw: eg in ccsm -> general options -> output
[14:30] <smspillaz> just add an entry like
[14:31] <smspillaz> heightx2048+0+0
[14:31] <smspillaz> and uncheck detect outputs
[14:31] <apw> smspillaz, will give that a go in a bit
[14:33] <apw> smspillaz, is there some way to get the unity panel (erm the thing with lenses on it) to resize so i can see the little icon menu at the bottom
[14:34] <smspillaz> apw: iirc the fix for that is coming at some point, though I'm not in charge of that so I don't know
[14:52] <Trevinho> JohnLea: about the patch related to bug #690143 now it should be landed in trunk
[14:53] <Trevinho> You can test the new backlight so compiling the bzr versino
[14:53] <Trevinho> version*
[14:54] <Trevinho> however I must admit that there's still a bug that I don't think that can easily solved: if you right-click on the window decoration and you move a window to another workspace in a such way the indicator doesn't get updated... In fact we don't have a smart way to check where a window is in a such case
[14:54] <Trevinho> however I should do more tests on that
[14:58] <smspillaz> Trevinho: window->geometry () should do it
[14:59] <smspillaz> (even though the thought of that makes me sick because of how wrong compiz gets that, but this is another discussion)
[15:02] <Trevinho> smspillaz: the problem is getting the event of the vp changed
[15:02] <Trevinho> window movement should work
[15:02] <Trevinho> but I guess I'd need to add too many filters in that case
[15:06] <drussell> speaking of xrandr commands being needed because the display settings get things wrong...
[15:06] <drussell> https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/828623
[15:07] <drussell> is anyone here able to steer me in the right direction of who's best to speak to to get it at least triaged/looked at
[15:07] <drussell> (this is 11.10 again)
[15:08] <smspillaz> Trevinho: is this from within unity ?
[15:09] <Trevinho> yes
[15:09] <smspillaz> Trevinho: don't we hook into signals from the wall plugin in that case ? (start_viewport_switch and end_viewport_switch)
[15:10] <Trevinho> Of course, and I use them
[15:10] <Trevinho> but they're related to the screen
[15:10] <Trevinho> not to a window
[15:10] <Trevinho> I need that a window will say "Hey... I just moved to viewport X"
[15:11] <smspillaz> Trevinho: moveNotify with dx == screen->width () will do that
[15:11] <smspillaz> at least if the wall plugin works the way I think it does
[15:11] <Trevinho> I checked that some times ago, but it wasn't working too well
[15:11] <Trevinho> I'll recheck tonight
[15:12] <smspillaz> it's not 100% reliable
[15:13] <smspillaz> Trevinho: http://git.compiz.org/compiz/core/tree/src/window.cpp#n5050
[15:15] <smspillaz> Trevinho: if you just need to know that a window moved to another viewport, then you can check for window->invisible () on moveNotify as well
[15:16] <smspillaz> Trevinho: unfortunately, there's no such concept of "viewports owning a particular window". That's not really how largedesktop works
[15:18] <Trevinho> ok, thanks
[15:18] <Trevinho> I've to go now, but tonight I'll look into that
[15:18] <smspillaz> :)
[15:18] <smspillaz> have fun
[15:53] <jcastro> didrocks: ping
[15:53] <didrocks> jcastro: hey!
[15:53] <jcastro> howdy!
[15:54] <jcastro> I have a quicklist question for you
[15:54] <jcastro> so let's say I have update manager on my launcher
[15:54] <jcastro> I only get the "check for updates" quicklist when update-manager is running
[15:54] <jcastro> if it's not running there's nothing in the list
[15:54] <didrocks> should be a dynamic quicklist then
[15:55] <didrocks> (which depends on the component running then)
[15:55] <jcastro> so it's like, not really a quicklist at all, unless it's running, at that point why have a quicklist. when it makes me run the app and I have the button right there
[15:55] <jcastro> ok so is this a bug in update manager or is it just how quicklists work?
[15:55] <didrocks> yeah, it's maybe not really useful
[15:55] <jcastro> it has to be in u-m because like firefox keeps its quicklists when not running
[15:55] <didrocks> should maybe be a static quicklist, launching update-manger in a mode where it apt-get update?
[15:56] <jcastro> right
[15:56] <didrocks> not sure if update-manager has that TBH
[15:56] <jcastro> so I just needed to know where to file the bug
[15:56] <didrocks> (this option)
[15:56] <didrocks> oh, the quicklist is in update-manager code itself
[15:56] <didrocks> (as the .desktop file for the static quicklist)
[15:56] <didrocks> so yeah, bug update-manager :)
[15:56] <jcastro> awesome, thanks!
[17:12] <htorque_> Trevinho: have you thought about making the launcher items pulse like normal when starting (in "backlight and edge illum. toggles" mode)? right now i find it a bit difficult to see whether a program starts or not.
[17:52] <andyrock> DBO, dash has the same DNDCollectionWindow issue https://bugs.launchpad.net/unity/+bug/837968
[17:52] <andyrock> and the problem is not due to dndcollectionwindow
[17:52] <DBO> andyrock, thats due to teh nature of DND
[17:53] <DBO> im not exactly sure what can be done about it really
[17:53] <andyrock> but this problem sucks and should be fixed :)
[17:53] <DBO> the XDND protocol isn't very flexible in this manner...
[17:53] <DBO> happens to GTK also
[17:54] <Trevinho> htorque_: No I didn't think about that, but it would be a nice idea... Open a bug about that
[17:54] <htorque_> Trevinho: will do :-)
[17:55] <Trevinho> Nice, feel free to call me back about that... Now I can't do it, but I'll give a look.
[18:02] <jjohansen> is there an indicator to get crash reports that notification report and ask for you to click on the notification icon?
[18:12] <htorque_> Trevinho: bug 838283 - maybe it can be made an additional option so it can be evaluated during user testing (if that's done somehow sometime).
[18:17] <Trevinho> thanks htorque_
[18:18] <Trevinho> jjardon: apport gtk has a tray-icon, but I guess it has not ported to libappindicator yet
[18:18] <htorque_> Trevinho: thanks for being open to suggestions ;-)
[18:27] <andyrock> htorque, Trevinho is open not only to suggestions ;)
[18:30] <Trevinho> What the hell are you meaning andyrock?!?
[18:30] <andyrock> Trevinho, muahahahah
[18:30] <Trevinho> little bastard!
[18:40] <Baabelfish> hello, any idea if it's possible to do global menu applet to the panel?
[18:41] <Andy80> andyrock, Trevinho you two!!! Don't damage the name of the "italian stallions" :D
[19:46] <kamstrup> kenvandine: dee-0.5.20 is out
[19:46] <kenvandine> kamstrup, thx!
[19:46] <kamstrup> kenvandine: tell the people with the pitchforks to stand down now ;-)
[19:46] <kenvandine> :-D
[19:48] <kamstrup> kenvandine: here's the changelog https://launchpad.net/dee/+milestone/0.5.20, since we're already shipping the relevant patches it's not hugely important, otoh we also know from experience now that the patches are safe :-)
[19:49] <kenvandine> yeah :)
[19:49] <kenvandine> i'll think about updating the package after beta1 :)
[20:01] <kenvandine> kamstrup, do you think the blocking problem i have when the models are refreshing could be related to the FilterModel I am using?
[20:02] <kamstrup> kenvandine: how many rows/changes are going into the model?
[20:02] <kenvandine> when it clears and appends a couple thousand rows... I guess the filter is being reapplied on every change
[20:02] <kamstrup> the filter is applied incrementally to new rows
[20:02] <kenvandine> right
[20:02] <kenvandine> so if i have 2000 appends
[20:03] <kenvandine> right after a clear
[20:03] <kenvandine> it has to filter each row
[20:03] <kamstrup> yes
[20:03] <kamstrup> but assuming this filter is a collator filter it should be cheap
[20:03] <kenvandine> "cheap"
[20:03] <kenvandine> about 2 seconds
[20:04] <kamstrup> no, maybe 20ms worst case
[20:04] <kenvandine> how about a filter of a filter?
[20:04] <kenvandine> i filter by a column first
[20:04] <kenvandine> the collate that
[20:04] <kamstrup> kenvandine: it basically becomes a merge sort of 2k items I think
[20:05] <kenvandine> and i do that 8 filter models
[20:05] <kamstrup> hehe, i can see that the layout is not exactly trivial...
[20:05] <kenvandine> one model, filtered by a column into 8 different filtermodels
[20:05] <kenvandine> then apply the collator filter on that
[20:05] <kamstrup> ah that way
[20:06] <kamstrup> a collator on each of the 8 filter models?
[20:06] <kenvandine> yes
[20:06] <kamstrup> ok i have the picture
[20:06] <kenvandine> they are all sorted by time
[20:06] <kamstrup> still shouldn't be too bad I think
[20:06] <kenvandine> but the point of all the filters is to have one per stream
[20:07] <kamstrup> although we are talking 1 + 2*8 "row-added" signals
[20:07] <kenvandine> right
[20:07] <kamstrup> + the same amount of "row-removed" beforethat I assume
[20:07] <kenvandine> i experimented with not clearing the model first
[20:07] <kenvandine> and it got slower
[20:07] <kenvandine> because the model got bigger and bigger
[20:08] <kamstrup> if you wanna do clever updates you almost certainly need some indexes on the right columns
[20:08] <kenvandine> quickly got over 10k
[20:08] <kenvandine> i never looked at the indexes
[20:08] <kamstrup> a 10k model shouldn't be a problem as such
[20:08] <kamstrup> it all depends on how you use it
[20:09] <kamstrup> if you traverse the entire model often then sure
[20:09] <kenvandine> but i am filtering it like crazy
[20:09] <kamstrup> but if you only use limited subsections and otherwise access it via indexes
[20:09] <kamstrup> right
[20:09] <kamstrup> filtering should be efficient as well
[20:10] <kamstrup> but it sounds odd that you have to rebuild so much data
[20:10] <kenvandine> just once
[20:10] <kamstrup> ah, right
[20:10] <kenvandine> after loading from the resource manager
[20:10] <kenvandine> so you have instant data, but then i need to bring it in sync with what the service has
[20:10] <kenvandine> then i just get changes from the service
[20:11] <kenvandine> which are small
[20:12] <kamstrup> ok, and in order to take in these changes you need to rebuild the entire model - right?
[20:12] <kenvandine> yes
[20:12] <kamstrup> and that's where you take te hit
[20:12] <kenvandine> well... just on load
[20:12] <kamstrup> right
[20:12] <kenvandine> otherwise it is pretty speedy
[20:13] <kamstrup> kenvandine: any chance the service can just write directly to the resource
[20:13] <kenvandine> no
[20:13] <kamstrup> and then the view just re-reads from the RM?
[20:13] <kamstrup> bugger :-)
[20:13] <kenvandine> then i need to parse the json on the way out
[20:13] <kenvandine> and leaks like hell
[20:13] <kamstrup> hehe
[20:14] <kenvandine> there is where i plan to be at next cycle though
[20:14] <kenvandine> using a shared model managed by the service
[20:14] <kenvandine> but that requires redesign of the db schema
[20:15] <kenvandine> kamstrup, so if you start gwibber and try to scroll or click anything for the first few seconds you can't
[20:15] <kenvandine> and sometimes compiz grays it out... but not often
[20:16] <kenvandine> i've tried moving all the parsing and refreshing the model into async function
[20:16] <kenvandine> but once i start changing the model, it doesn't matter
[20:17] <kamstrup> kenvandine: I think I need to dive into the code to really come with some proper suggestions :-)
[20:18] <kamstrup> kenvandine: but it worries me a bit that shuffling json around - you should profile this
[20:18] <kenvandine> understand
[20:18] <kenvandine> we are going to get rid of the json
[20:19] <kamstrup> kenvandine: some tasty GTimers and some printfs should do fine :-)
[20:19] <kenvandine> when refresh_model gets run in libgwibber/streams.vala
[20:19] <kenvandine> that is when it blocks
[20:19] <kenvandine> until that is done
[20:28] <kamstrup> kenvandine: ok, i'll dig in when I've had some sleep
[20:28] <kenvandine> cool
[20:28] <kenvandine> thx!
[21:48] <hakermania> Hey guys, I'd like to ask about libunity, what does the UnityLauncherEntry argument inside the C code mean? What should I place there? Any C code example arounf?
[21:48] <hakermania> around*
[21:55] <hakermania> Ok, nv I found it :)