[01:31] <slide> Every time I select a launched program from the unity bar that has more than 1 window open it always brings a different window to the top, but still gives the original window focus
[01:31] <slide> is there any way to fix this?
[05:23] <didrocks> good morning
[06:47] <oSoMoN> good morning
[08:29] <kamstrup> JohnLea: hey, I am just reviewing lamalex' U1 Music scope, and I was wondering whether or not it was the intention that results from the music scope should show up in the global dash search?
[08:30] <kamstrup> JohnLea: I am thinking that the results from your own collection could make sense, but the U1 store results not so. Especially because they may contain explicit names an cover art
[08:34] <JohnLea> kamstrup; yes the Dash home should display music search results.  However the Dash Home should never display results that have transaction latency from any of the lenses (see section 3.7, 2.2.2, and 2.2.1 in the "Unity Dash" spec doc)
[08:34] <JohnLea> kamstrup; this means that the dash home should not display music that is available for purchase, or apps that our available to download
[08:35] <JohnLea> kamstrup; basically, everything that appears in the Dash home should be instantly available if a user clicks on it
[08:35] <JohnLea> kamstrup; so music from spotify that is displayed in the music lens would also be displayed in the Dash home, but music available to purchase would not
[08:36] <JohnLea> kamstrup; the Dash home is focused on retrieval, the individual lenses do both retrieval and browsing
[08:36] <JohnLea> kamstrup; does that answer your question?
[08:45] <kamstrup> JohnLea: yep, that's super. Thanks
[10:23] <didrocks> kamstrup: can we make the libunity and u-l-a/u-l-f releases now? that will still be that already done and things to not cared too much about then :)
[10:33] <kamstrup> didrocks: let me check... The U1 scope has unearthed some "interesting features" in lbunity ;-)
[10:37] <kamstrup> didrocks: i'll go over any pending branches now, and hopefully release in ~30min if everything is smooth sailing
[10:38] <didrocks> kamstrup: not "if", eveyrthing *will be* smooth :-)
[10:38] <didrocks> *jedi wave*
[10:38] <didrocks> thanks :)
[10:40] <didrocks> kamstrup: wait, I have maybe a last minute fix for u-l-a
[10:42] <didrocks> kamstrup: no, that's fine ;)
[10:57] <kamstrup> didrocks: ok - so here's the stinker... :-)
[10:57] <didrocks> no stinker :-)
[10:58] <kamstrup> didrocks: *strictly* speaking there is an ABI break in libunity today. But it is in the "private parts" (pun intended)
[10:58] <kamstrup> didrocks: so it does not affect anything
[10:58] <didrocks> kamstrup: you mean, in the pimpl?
[10:58] <kamstrup> didrocks: but jusy to warn you if some of your scripts starts detecting this
[10:58] <kamstrup> didrocks: vala has the notion of "internal" functions
[10:59] <kamstrup> didrocks: they are not exposed in the public header, but still to be found as a symbol in the .so
[10:59] <didrocks> how does it implements it, it's not exposed to the application (like, in a struct or whatever)
[10:59] <didrocks> ok :)
[10:59] <kamstrup> didrocks: i needed to change the signature of some of these internal functions
[10:59] <didrocks> this is not a removed member
[11:00] <didrocks> only functions
[11:00] <didrocks> so, no "object size change"
[11:00] <kamstrup> didrocks: so maybe, some abi checker scripts will complain, but it should be "this is not the abi break you're looking for"
[11:00] <didrocks> kamstrup: sounds good, I'll tell you if my scripts complain :)
[11:00] <kamstrup> didrocks: i don't think object sizes are affected
[11:00] <didrocks> so should be good, I'll launch the old lenses with it
[11:01] <kamstrup> didrocks: i have been running with the new libunity and everything else from repos the past 30 minutes, and everything works like a charm
[11:01] <kamstrup> launcher count+progress, all lenses etc
[11:01] <didrocks> kamstrup: excellent, thanks for checking it! :-)
[11:01] <kamstrup> So thunderbird, update-manager, and lenses definitely don't cause problems
[11:01] <didrocks> yeah, ok, let's consider it's fine then :)
[11:02] <kamstrup> so that covers dl-opening in GI and dynamic linking
[11:02] <kamstrup> yes
[11:02] <kamstrup> didrocks: ok, i'' start rolling libunity now then
[11:02] <didrocks> yes! :)
[11:07] <om26er> there are alot of problems with minimized windows previews in Unity disabling it just makes things work, might be wise to turn the feature off
[11:25] <kamstrup> didrocks: https://launchpad.net/libunity/4.0.0/4.0.4 !
[11:25] <didrocks> kamstrup: thanks!
[11:25] <didrocks> hey om26er, I remember seeing some activity on bug reports about it, can you refresh what's the issue?
[11:35] <davidcalle> kamstrup, hi, do you have time for a scopes question?
[11:36] <kamstrup> didrocks: catch this! https://launchpad.net/unity-lens-applications/trunk/0.4.6
[11:36] <kamstrup> davidcalle: always dude :-)
[11:36] <davidcalle> kamstrup, thanks :-)
[11:38] <davidcalle> Kamstrup, I use a single local scope, merging local and remote sources. Each one uses its own dash category and my "on_search_changed" looks like this :
[11:39] <didrocks> kamstrup: got it! (yeah, we are very away one from each other, so time to wait for the velocity of the tarball to arrive ;))
[11:39] <davidcalle> results = scope.props.results_model; results.clear(); update_res_model (search, results, 0) (0 is the first cat); results.flush_rev_queue(); update_res_model (searc, res, 1); search_finished()
[11:40] <davidcalle> kamstrup, results.flush_rev_queue() doesn't seem to do anything.
[11:40] <kamstrup> davidcalle: what do you expect it to do?
[11:41] <davidcalle> kamstrup, to display results from cat 0 immediately as they are locals, then bother about remote sources in cat 1.
[11:41] <davidcalle> kamstrup, that's how I used it in natty, it worked.
[11:42] <kamstrup> didrocks: and the last one from me today! https://launchpad.net/unity-lens-files/trunk/0.6.6
[11:43] <didrocks> kamstrup: rock and rolled (tarballs)! thanks :)
[11:43] <kamstrup> davidcalle: ok, libdee hasn't really changed much since Natty, so there should be no change there
[11:43] <kamstrup> didrocks: and not post release version bump today
[11:43] <kamstrup> !
[11:43] <didrocks> kamstrup: I LOVE YOU! :-)
[11:44] <kamstrup> davidcalle: have you tried looking at this in dbus-monitor?
[11:44] <davidcalle> kamstrup, nope, but I will.
[11:45] <davidcalle> kamstrup, http://paste.ubuntu.com/689925/ here is the whole method, maybe you'll see a mistake.
[11:46] <kamstrup> davidcalle: since unity is *very* chatty on the bus, you might wanna run it like : dbus-monitor 'interface=com.canonical.Dee.Model'
[11:46] <kamstrup> davidcalle: this way you see only what is transmitted on the dee models, not all the noise
[11:46] <davidcalle> kamstrup, ok
[11:46] <kamstrup> davidcalle: you wanna chewck how many Commit signals they send
[11:47] <kamstrup> davidcalle: the contents of the Commit signals should correspond to a "diff" that unity should apply to its view
[11:49] <davidcalle> kamstrup, so, if I search for "mo" then "moby", the "moby dick" item shouldn't be reloaded, right. On Unity-2d it flickers like it's being reloaded.
[11:50] <kamstrup> davidcalle: it will be reloaded. the unity shell can not assume that it can simply filter the query
[11:51] <davidcalle> Ok
[11:51] <kamstrup> davidcalle: consider doing the same search on google... that would give very different results for each query
[11:51] <davidcalle> kamstrup, indeed.
[11:51] <kamstrup> davidcalle: but you can make that optimization inside your lens if you want. In fact the old apps and files lenses from way back in maverick did this if i recall correctly
[11:52] <kamstrup> but it was some tricky bok keeping
[11:52] <kamstrup> and it's buggy by design, unless you can retrieve the *entire* result set for the query "mo*" in the first run
[11:53] <kamstrup> which you rarely can for any non-trvial sized corpus
[11:53] <kamstrup> also if you have relevancy ranked sources the query "moby" and "moby dick" will sort very differently, hence simple filtering does not apply
[11:55] <davidcalle> kamstrup, what I do is applying different regex on the results before passing them to unity : I extend lists of items matching exactly the query, then matching the beginning of the forts word, the beginning of another word, etc.
[11:55] <davidcalle> first*
[12:06] <davidcalle> kamstrup, if I send flush_rev_queue after each model.append, does it should load results as soon as they are appended to the model?
[12:07] <kamstrup> davidcalle: yes, but only do that if you have at least 100ms or so between each append()
[12:07] <kamstrup> davidcalle: otherwise you'll just be spamming the bus and slowing yourself (and everyone else) down
[12:08] <davidcalle> kamstrup, ok, I'm going to test this with a sleep after append then flush_rev_queue. To see if it works.
[12:13] <kamstrup> davidcalle: really, you should insert a sleep(99999999999), then switch to dbus-monitor when it sleeps and assert that the Commit signal has hit the bus
[12:13] <kamstrup> if not, then it's a bug in libdee
[12:20] <davidcalle> kamstrup, doing model.append; model.flush_rev_q; time.sleep(1) : I see my results slowly being loaded in dbus-monitor, but nothing showing up in the dash until the whole queue has been passed to dee.
[12:21] <kamstrup> davidcalle: then the bug is in the dash - is it u2d or u3d?
[12:21] <davidcalle> kamstrup, 2d
[12:22] <kamstrup> davidcalle: if you have problems testing in u3d, I can give it a spin for you if you give me a branch
[12:22] <davidcalle> kamstrup, will test in a moment.
[12:25] <davidcalle> kamstrup, same thing in 3d.
[12:29] <davidcalle> kamstrup, my branch is here https://code.launchpad.net/~davidc3/unity-books-lens/oneiric-first-draft
[12:31] <davidcalle> kamstrup, if you happen to check it, sorry for the dirty code, I'm rather new at python. ;-)
[12:43] <didrocks> kamstrup: !!! you didn't bump the libunity build-dep on u-p-f! I trusted you even if I remarked it that you didn't use the new API :-)
[12:43] <didrocks> u-l-f, sorry
[12:44] <kamstrup> didrocks: argh! FAIL!
[12:45] <didrocks> kamstrup: I was really thinking "if kamstrup didn't bump the build-depp, there sould be a reason and it doesn't use the API, let's trust him"
[12:45] <didrocks> kamstrup: i'm sooooooooooooooooooooooooooo disppointed :)
[12:45] <didrocks> disappointed*
[15:14] <om26er> Trevinho, did you fix bug 838923 in your branch?
[15:15] <om26er> it seems sam fixed something similar in compiz bug 850985 (or was it the other end of the bug?)
[15:41] <om26er> didrocks, Hi I have assigned bug 848707 to you is that fine?
[15:41] <om26er> the fix is in comment#2
[15:41] <and471> tedg, ping
[15:44] <didrocks> om26er: you should dup it to bug #837545 where a fix should land today
[15:50] <om26er> done, thx
[15:50] <tedg> Uhg, seems I missed him.
[16:31] <nhaines> I'm having a very difficult time with Unity2D right now.  GNOME Terminal windows are behaving rather strangely.
[16:31] <nhaines> http://ubuntuone.com/69wKSZ0tVZMO2rcz7Yggxn
[16:32] <nhaines> There's no alpha transparency around the title bar, they are always on top of *everything* (right-click menus on title bar, Alt-Tab switcher in Unity, etc.).
[16:33] <nhaines> When I switch to another app, GNOME Terminal covers the app but is not active.  It can be clicked right through.
[16:33] <nhaines> This is subobtimal.  :)
[17:21] <apinheiro> didrocks, could increase the importance for this bug:
[17:21] <apinheiro> https://bugs.launchpad.net/unity/+bug/851103?
[17:21] <apinheiro> I can'¡t do that
[17:22] <didrocks> apinheiro: sure, doing
[17:23] <apinheiro> didrocks, ok, thanks
[17:23] <didrocks> apinheiro: targeted for O, thanks
[17:24] <apinheiro> didrocks, ok, I have just found a solution, and it is a two-line branch
[17:24] <apinheiro> so it shouldn't be a problem to solve it
[17:24] <apinheiro> I mean, shouldn't be a problem to merge it
[17:24] <apinheiro> didrocks, btw, what means p-series?
[17:28] <didrocks> apinheiro: next release (o -> oneiric; p -> we don't have the name yet ;))
[17:28] <didrocks> apinheiro: I just misclicked!
[17:28] <apinheiro> didrocks, ok
[18:17] <jjohansen> unity is completely broken again after todays update (say about 30 min ago)
[18:17] <jjohansen> it just dies on startup
[18:19] <didrocks> jjohansen: do you have a backtrace?
[18:19] <didrocks> jjohansen: and what did you updated last, nux is just published
[18:20] <jjohansen> didrocks: no back trace, nothing in dmesg, /var/crash or /var/log that I can see
[18:20] <didrocks> jjohansen: looks weird then, did you have to --reset ?
[18:21] <didrocks> jjohansen: or just launch first "unity" from a tty?
[18:21] <jjohansen> I am in 2D atm but once I get a couple things done will reboot and try again, it failed every time I tried though and I tried with older kernels to see if the problem was there
[18:21] <jjohansen> didrocks: not in unity,
[18:21] <jjohansen> I haven't tried launching it from a terminal yet
[18:22] <jjohansen> I need to get a few things setup before I take this machine down again
[18:22] <htorque> hm, a reboot fixed that for me today. restarting didn't work, unity just died.
[18:23] <jjohansen> didrocks: I'll have more info in say 15min, and I'll drop the bug# here
[18:24] <didrocks> jjohansen: sure (not sure to be there in 15min TBH, but do not hesitate to ping me)
[18:24] <jjohansen> didrocks: okay
[18:35] <davidcalle> gord, hi
[18:43] <andyrock> anyone has this problem?
[18:43] <andyrock> https://bugs.launchpad.net/unity/+bug/851172
[18:45] <htorque> andyrock: it's definitely lagging behind the mouse cursor here
[18:45] <htorque> let me test w/o blur
[18:45] <andyrock> htorque, thx
[18:46] <andyrock> confirm the bug please
[18:46] <htorque> static blur is fine
[18:47] <andyrock> i don't know the right person which it must be assigned
[18:47] <andyrock> jaytaoko maybe
[19:10] <davidcalle> gord, hi, should I assign this bug 851196 to you?
[20:25] <slide> Every time I select a launched program from the unity bar that has more than 1 window open it always brings a different window to the top, but still gives the original window focus
[20:25] <slide> is there any way to fix this?
[20:31] <jjohansen> slide: not that I know of
[20:32] <jjohansen> slide: what version are you running I don't think I have seen that one for awhile actually
[20:32] <jjohansen> not that I pick windows that way because it has been so broken in the past
[21:10] <andyrock> DBO, there are some issue due to the new policy of not hiding the dash when dnd starts
[21:10] <DBO> andyrock, explain? :)
[21:10] <DBO> it seems to work for me
[21:11] <andyrock> right now i'm quite busy so i've solved just some of them
[21:11] <andyrock> well the big one is that with active blur activated
[21:11] <andyrock> is really really slow
[21:11] <andyrock> the bugs i've solved is related to saturation/desaturation
[21:11] <andyrock> of the launcher
[21:13] <andyrock> DBO, i'm going to do a merge proposing right know but there are no bugs on lp
[21:14] <DBO> andyrock, you are making it saturate again when DND starts?
[21:14] <andyrock> yes....
[21:15] <andyrock> there was a bug some time ago...
[21:15] <DBO> andyrock, so the only technical issue is performance?
[21:15] <andyrock> i'm not able to find it right now
[21:15] <DBO> god I thought this was going to be more nasty ass race conditions...
[21:16] <andyrock> DBO perfomance issue right know
[21:16] <DBO> mine works fine :P
[21:16] <andyrock> without "right know" sorry
[21:16] <andyrock> i have not a Mac :)
[21:16] <DBO> im surprised there is a performance issue actually
[21:17] <andyrock> and when the dash is opened dropping a file into the launcher doesn't close the dash
[21:17] <DBO> its not supposed to
[21:17] <DBO> this way you can drag and drop several things
[21:17] <andyrock> the dash doesn't close also when the spread is triggerd
[21:17] <DBO> I want to kill that behavior...
[21:18] <DBO> I think that behavior is SO dumb...
[21:18] <andyrock> well i think that make sense do it only with app icons
[21:19] <DBO> andyrock, how is performance on alt-tab for you?
[21:19] <andyrock> DBO, it works really really fine
[21:20] <DBO> so alt-tab is fast...
[21:20] <DBO> even if you enter the spread mode?
[21:20] <andyrock> yeah
[21:20] <andyrock> spread mode in the alt-tab?
[21:20] <DBO> down arrow
[21:21] <andyrock> works fine too
[21:21] <DBO> crazy
[21:23] <andyrock> DBO https://code.launchpad.net/~andyrock/unity/dnd-dash-saturation/+merge/75641
[21:24] <DBO> andyrock, thanks
[21:24] <DBO> I am looking at the perf now
[21:24] <DBO> andyrock, want to do me a favor?
[21:24] <andyrock> DBO, of course
[21:24] <DBO> can you get me a sysprof output of the performance issue?
[21:27] <andyrock> DBO give me a second and i will do it
[21:27] <DBO> andyrock, I'll be here for quite a while still :)
[21:30] <htorque> guess this is how the multiload indicator is supposed to look now: http://img.xrmb2.net/images/553098.png ?
[21:35] <andyrock> DBO https://bugs.launchpad.net/unity/+bug/851172
[21:35] <andyrock> attached there
[21:35] <andyrock> I hope i've done it in the right way
[21:35] <andyrock> it's my fisrt time with sysprof :)
[21:36] <andyrock> *first
[21:36] <DBO> :)
[21:36] <DBO> thanks
[21:36] <andyrock> and another bug (at least i mean) https://bugs.launchpad.net/unity/+bug/851185
[21:37] <andyrock> if you confirm it's a bug (maybe it's a weird design) i can assign it to myself
[21:37] <htorque> andyrock: what should happen when you touch the left edge with the dragged item?
[21:38] <andyrock> htorque, if the dash is open nothing
[21:38] <htorque> here it saturates when i enter the launcher and desaturates when i leave it again
[21:38] <andyrock> if the dash is not open the launcher should be hidden
[21:39] <htorque> ah, i'm not using autohide !:-)
[21:39] <andyrock> htorque, saturation bug is another one (i just did a mp)
[21:39] <andyrock> htorque, you use never hide option?
[21:39] <htorque> yeah, just switched to autohide and can confirm that now
[21:40] <andyrock> htorque, it's very useful when the dash is not open
[21:40] <andyrock> but if the dash is open it makes no sense IMHO
[21:42] <andyrock> htorque, can you confirm it please?
[21:46] <andyrock> DBO, just another thing (i've to study mathematical analysis then :/). We use g_file_query_info and g_file_get_content_type to get the data of the dragging stuff
[21:47] <andyrock> sometimes (e.g. dragging firefox imgs) it takes too time (3-4 seconds) to do it
[21:47] <DBO> I dont think so? do we?
[21:47] <DBO> why would be doing that?
[21:47] <DBO> oh mimes...
[21:47] <DBO> right...
[21:47] <andyrock> to get the data type of the dragging stuff sorry
[21:47] <DBO> we need to make that async
[21:50] <elleuca> hi, could someone take a look at https://bugs.launchpad.net/ubuntu/+source/unity-lens-files/+bug/851359
[23:04] <htorque> can anyone explain, how this can be possible: the alt-tab preview of opera showed me the xchat window and doing 'killall opera' killed opera AND xchat. :-/
[23:04] <DBO> htorque, thats cool!
[23:05] <htorque> not if i cannot reproduce it ;)