[00:08] <bobweaver> brb reboot time
[00:34] <thumper> bobweaver: some of the lenses and scopes are in vala, others in python
[00:34] <thumper> I don't believe there are any explicit tools
[00:34] <bobweaver> thanks thumper  sorry for cutting in and out I was restarting gnome-session
[00:35] <bobweaver> I am trying to hack in some new lens for ubuntu tv
[00:36] <bobweaver> by using others that are all ready there but I have to make some "templeates" (I think ) / somepartofdash.qml and was wondering if there was a easy way to make layout with out hand coding
[00:38] <bobweaver> I think that I have to make a section for what I am trying to do here http://bazaar.launchpad.net/~s-team/ubuntutv/trunk/files/head:/shell/dash/
[00:38] <bobweaver> then tie the lens scope and daemon in but I could be wrong. all in all I am learning a ton and for that I just have one more thing that I love about Ubuntu :)
[00:47] <thumper> bobweaver: you do realise that the ubuntutv is a prototype and not a product right?
[00:48] <bobweaver> thumper,  yup 100% thumper  here is a video of me using a live cd that I created yesterday http://www.youtube.com/watch?v=VbRRrJEwZ3E
[00:53] <bobweaver> thumper,  I get a box of ubuntu cd from a local coc member I gives these to stores to handout to there customers  I also give them a book of pdf's that I have gotten from a number of places. I am trying to get cardboard cut outs to hold the  pre-installed computers. But There is one store that the owner is awesome and I would like to drop off a box with Ubuntu TV (prototype) at his store but would like to make most of the launchers wor
[00:53] <bobweaver> k before I do that. Just to spread the word and to get the hype going.
[00:54] <bobweaver> more then it already is ,that is .
=== salem_ is now known as _salem
=== fenris is now known as Guest25535
=== Guest25535 is now known as ejat
=== njin is now known as njin1
=== njin1 is now known as njin2
=== njin2 is now known as njin
=== andyrock is now known as andyrock|uni
[08:16] <elky> Hi, I keep having bug# 962852 happen to me every few weeks. seb128 and I debugged it last time but with no luck, and it's just happened again. Any thoughts?
[08:16] <elky> bug 962852
[08:16] <ubot5> Launchpad bug 962852 in unity (Ubuntu) "icons stuck at top of unity dash" [Low,Incomplete] https://launchpad.net/bugs/962852
[08:17] <seb128> gord, hey, did you ever see something like that? do you have any idea what debug infos would be useful?
[08:17] <seb128> gord, https://launchpadlibrarian.net/97974155/Screenshot%20at%202012-03-23%2020%3A14%3A50.png
[08:17] <seb128> gord, screenshot of the issue
[08:18] <ais523> hmm, I wonder what happens if you just restart Unity (alt-F2 unity)
[08:19] <ais523> actually, I wonder if you can get that toolbar appearance by adding several hundred invisible icons to the launcher
[08:19] <ais523> that's the sort of thing that's within the realms of possibility that it could happen due to a bug
[08:22] <ais523> and that icon that is half-visible in the screenshot is update manager + a notification, which could explain what changed while someone was away from the computer
[08:22] <gord> woh, thats a strange one, i don't think there are easily accessible things that could be debugged out of it though. looks very tricky to debug
[08:22] <elky> ais523, the reference points to some of the lower icons stays visible, but with exaggerated spacing
[08:22] <elky> well "visible"
[08:22] <elky> accessible, i can hover over the dock and get the tooltips show, and clicking works
[08:22] <ais523> when it happens, do you get tooltips (of any sort) if you hover over apparently empty spaces on the launcher?
[08:22] <ais523> and is everything where it "ought" to be when that happens, just invisible?
[08:22] <elky> yes, that
[08:23] <elky> well, in the right order, but as i said, with exaggerated spacing
[08:23] <gord> laptop and the netbook aren't the same resolution are they?
[08:23] <elky> gord, no, this is a hp mini, with it's special snowflake resolution
[08:24] <elky> the laptop is nvidia with not-huge resolution. it's not running right now, but i could start it after dinner and check
[08:25] <ais523> my current guess at the culprit is the rendering library
[08:26] <elky> i need to go make dinner, i'll look back here after i'm finished
[08:26] <ais523> I've already caught the tooltips acting oddly with my own locally patched Unity (if you repeatedly change what a tooltip says, the text eventualy gets rendered in the wrong position on the tooltip)
[08:26] <ais523> *eventually
[08:55] <elky> ais523, any way to test your theory?
[08:56] <ais523> not that I can think of immediately
[08:56] <ais523> restarting Unity but not bamfdaemon should test whether the fault is with which icons exist or how they're being drawn, at least
[08:56] <elky> how do i do that?
[08:56] <ais523> alt-f2 then type "unity" in the box that appears
[08:57] <elky> my recollections of debugging with seb suggested it didn't help anything
[08:57] <elky> just did it however, and no change yet
[08:58] <elky> no change at all :(
[08:58] <ais523> it normally causes a pretty obvious screen redraw
[08:58] <ais523> alt-f2 can be temperamental, you can try doing it from a terminal instead
[08:58] <ais523> (although you can't then close the terminal until you log out, or you'll be left without a window manager)
[08:58] <ais523> that's actually probably worth doing anyway, as you'll see any warning or error messages from unity in the terminal
[09:00] <elky> well yes, it redrew the screen
[09:01] <elky> but not the change we wanted ;)
[09:01] <gord> elky, do you normally have enough launcher icons to fill up the launcher? ie: some of them fold
[09:02] <elky> gord, not usually
[09:02] <elky> i might have had, i can't say now
[09:02] <gord> does feel like something to do with the maths surrounding that kind of thing
[09:02] <elky> there's probably a way to check, yeah
[09:03] <elky> ais523, i actually pastebinned that last time for seb: <elky> oh, my terminal has a heap of output because i ran unity... http://paste.ubuntu.com/949268/
[09:04] <gord> nothing very useful in there i'm afraid
[09:05] <ais523> elky: and re-running unity doesn't clear up the problem?
[09:05] <ais523> I think I have another idea
[09:07] <tsdgeos> didrocks: https://code.launchpad.net/~aacid/nautilus/fix_quicklist_underscore/+merge/106760
[09:07] <didrocks> tsdgeos: great, having a look :)
[09:07] <ais523> elky: could you run the command "dbus-send --print-reply --dest=org.ayatana.bamf /org/ayatana/bamf/matcher org.ayatana.bamf.matcher.RunningApplicationsDesktopFiles" in a terminal (not the one you're using to run Unity)?
[09:07] <ais523> and tell me whether the reply looks sensible or not?
[09:07] <tsdgeos> didrocks: have to logout for 3 min, back in a moment
[09:08] <elky> ais523, http://paste.ubuntu.com/1000498/
[09:09] <elky> why does it say unity2d?
[09:09] <ais523> now, /that's/ out of place, definitely
[09:09] <elky> that's quite cute.
[09:09] <elky> silly 2d, you don't belongs there!
[09:10] <ais523> when I do that, with my working terminal, it doesn't list unity-2d-panel as running
[09:10] <elky> now, how do we figure why/when it started?
[09:10] <tsdgeos> bac
[09:10] <tsdgeos> k
[09:11] <ais523> I guess we could see if the process has a parent, although it probably doesn't
[09:11] <ais523> it's a little awkward to work out the raw dbus calls for a particular window
[09:12] <elky> melissa@lamia:~$ pstree | grep 2d    ...     |-2*[unity-2d-panel---2*[{unity-2d-panel}]]
[09:12] <ais523> ah, neat, didn't know about that; I'd probably have tried to use pgrep
[09:13] <ais523> I suppose one crazy thing to try would be killall unity-2d-panel, to see what happens
[09:13] <didrocks> tsdgeos: looks good to me, will merge and sponsor Thanks! :) (maybe I'll just change the free to a g_free() for coherence)
[09:13] <tsdgeos> didrocks: ah it's g_free
[09:13] <ais523> are free and g_free actually identical?
[09:13] <tsdgeos> i thought it was gfree :D
[09:13] <tsdgeos> but failed to compile
[09:13] <tsdgeos> and was a lazy bastard to not look for the correct naming
[09:13] <elky> ais523, anything else you want me to check before i do that, incase it leaves me needing to reboot?
[09:14] <ais523> I can't think of anything immediately, but I'll probably think of something just after it's already crashed the system :)
[09:15] <ais523> I guess we could look for windows belonging to unity-2d-panel, to figure out where they'd gone onscreen
[09:15] <ais523> but it wouldn't explain why the process was running
[09:15] <elky> ais523, alt-tab shows nothing
[09:15] <didrocks> ais523: for a gchar*, there is no difference between the 2 :)
[09:15] <ais523> what do you mean by that?
[09:16] <elky> alt-tabbing through open windows
[09:16] <ais523> didrocks: how does g_free know it's a gchar* and not some sort of object
[09:16] <ais523> elky: as in, what you expect, or nothing at all?
[09:16] <elky> there's nothing i can't attribute to something else
[09:16] <ais523> unity-2d-panel is almost certainly marked as not user-focusable
[09:16] <elky> ah ok
[09:16] <ais523> as it wouldn't make sense to put it in the alt-tab display for people who were actually running Unity 2D
[09:17] <elky> true
[09:17] <elky> ok well how can we check for it?
[09:18] <ais523> if you repeat that dbus-send command, but with RunningApplications rather than RunningApplicationsDesktopFiles, you get a list of internal names that bamf's using for the various applications
[09:18] <ais523> then you can try to figure out which is which using more dbus-sends
[09:18] <elky> ok... so i just ran unity again from alt-f2 out of curiosity. I now have another unity2d
[09:18] <ais523> two of them?
[09:18] <elky> well 3. there were 2 before
[09:18] <ais523> ah
[09:18] <elky> the *2 in pstree means 2
[09:19] <didrocks> ais523: sizeof(object), a gchar* is just an alias to a char*. g_free just handles NULL
[09:19] <ais523> didrocks: free also handles null
[09:19] <didrocks> are you sure? after so many years of glib… ;)
[09:20] <ais523> yes, it's one of the very few standard C library functions that doesn't segfault if you pass it NULL as an argument
[09:20] <ais523> (it does have a tendency to segfault when passed any other invalid input, though)
[09:21] <ais523> hmm, nothing in unity(1) implies that it tries to open unity-2d
[09:21] <ais523> it doesn't make any sense for compiz to open unity-2d, either
[09:21] <elky> ais523, ah wait. when you said alt+f2, was it supposed to do searching of apps? i have to hit alt again afterwards to get the single input bar
[09:22] <ais523> elky: the current window manager /is/ compiz, right? (you can check by seeing if a compiz process is running and if a metacity window is running)
[09:22] <ais523> and alt-f2 opens a run dialog box that is cunningly disguised as a lens
[09:23] <ais523> it's equivalent to running a one-liner in the terminal, except without the terminal, and it sometimes autocompletes in obnoxious ways
[09:23] <elky> compiz and compiz-decorator are there, no metacity
[09:23] <ais523> right, so restarting unity - which restarts compiz - is somehow loading unity-2d-panel
[09:24] <ais523> but unity(1) doesn't mention unity-2d-panel anywhere, and compiz has no reason to load unity-2d-panel because they're incompatible with each other
[09:24] <elky> ais523, just making sure. I've had the lens autocomplete in some weird ways; its filtering out "unity-2d" launchers, so perhaps those unity2d things are there by me opening them accidentally
[09:24] <ais523> I was wondering about that
[09:24] <ais523> use a terminal to restart unity to make sure (see if you get another unity-2d-panel or not)
[09:25] <ais523> hmm, maybe I'll go complain about alt-f2's behaviour someday, its autocomplete is wonky enough to make it near-unusable sometimes
[09:26] <elky> ais523, it did a very much different screen redraw just then
[09:26] <elky> and no additional unity2ds
[09:27] <elky> ais523, you have my permission to cite this chat log when you do ;)
[09:28] <elky> killed all the unity-2d-panel processes now too
=== yofel_ is now known as yofel
[09:28] <ais523> anything visible happen when you did?
[09:29] <ais523> the screen redraw from restarting unity is really noticeable, it takes several seconds on my netbook
[09:31] <elky> killing the 2ds didn't do anything visible. starting them made the top panel blink, doing `unity` made the screen go away then come back
[09:31] <seb128> elky, do you have any other unity-2d process? like launcher ones?
[09:31] <elky> (i may also have missed the panel blink when killing them)
[09:32] <elky> seb128, not in pstree
[09:32] <ais523> OK, I think the unity-2d stuff was a red herring
[09:32] <ais523> BAMF is doing its job correctly, which means that the launcher is getting sane input; it's just producing insane output
[09:32] <ais523> is the launcher still messed up?
[09:32] <ais523> even after restarting unity?
[09:32] <elky> http://paste.ubuntu.com/1000519/ is what shows for "unity"
[09:33] <elky> ais523, i agree, 2d was a red herring because alt+f2 needs to take a flying leap :)
[09:33] <ais523> that looks correct
[09:35] <elky> ok well if you're out of ideas, I can deal with stupified unity for a few days, ping me as you think of anything else
[09:35] <ais523> I'm not really out of ideas, just trying to narrow things down
[09:35] <elky> ok, cool
[09:36] <ais523> I think it's pretty clear that the problem is in unity-launcher somewhere
[09:38] <elky> is there a way I can log the output that the launcher is producing?
[09:38] <ais523> not really, I guess you could use a screen recording program and video it
[09:39] <elky> yeah i didn't phrase that well
[09:39] <ais523> I guess the next thing is to work out if all the icons are "in position"
[09:39] <ais523> you say that towards the bottom, they're really spread out?
[09:39] <ais523> is there anything "in between" them, that you can interact with with mouse hovering or clicking?
[09:40] <elky> they're spread out the whole way along. and some are not even showing, they're somewhere "above" the panel. they can scroll, but i can't see the scrolling to control it
[09:41] <elky> clicking between the tooltipped areas does nothing
[09:42] <ais523> I'm going to go look at the source for that bit
[09:42] <elky> one thing seb was going to try, was having the icons shrunk down to 32 instead of the gigantic default size
[09:42] <ais523> I use 32 as my default size
[09:42] <ais523> system settings | behaviour | look, and it's the bottom control in the dialog box
[09:43] <elky> yep i've always set my unity to that size
[09:43] <elky> even when it was experimental
[09:43] <elky> the default size is just absurd on a netbook
[09:43] <elky> especially a shallow resolution like the hp minis
[09:44] <ais523> I set it from the experimental settings before I realised it was in the regular settings too :)
[09:44] <elky> same
[09:45] <elky> i actually didn't know it was there until seb told me when we debugged last time
[09:46] <elky> other than changing what's pinned, that's really the only change i make from unity defaults
[09:47] <ais523> gah, why does this code use inconsistent names for everything everywhere
[09:49] <ais523> trying to work out what the difference between a tray and a menu view panel is, and which the launcher is
[09:49] <elky> that could well be part of the problem ;)
[09:51] <elky> Naming for all this wizzy gui stuff is confusing anyway. I still have no idea what to call the bar thingy that slides out. or what the top-of-the-screen thingy is. or what the big rectangular thingy is.
[09:51] <elky> Nobody seems to use the same words as the next person
[09:51] <elky> some even use the same word for all of them!
[09:51] <gord> top bit = panel, left bit = launcher, rectangular thingy = dash
[09:52] <ais523> sorry, IRC client just segfaulted…
[09:53] <ais523> the bar that slides out when you tap Alt is called the HUD; the big rectangular thing you get when you tap Super is the Dash (and each individual screen of it is called a Lens)
[09:53] <ais523> I don't actually know what the bar at the top of the screen is called; the bit over the right is the "indicator menu", but that doesn't seem to apply to the whole bar
[09:55] <didrocks> the top bar is the panel
[09:55] <ais523> right, thanks
[09:55] <ais523> (and that makes sense by analogy with gnome 2)
[09:57] <elky> heh
[09:57] <ais523> bleh, this program is mixing nux and two different sets of raw OpenGL calls
[09:57] <ais523> I sort-of get the feeling from Unity's source that it was written in a hurry
[09:58] <gord> no, nux was something we chose because we could mix opengl calls and nux
[09:58] <ais523> right, makes sense
[09:58] <elky> ais523, Don't go saying that too loud, the laughter might be deafening.
[09:58] <ais523> just makes the code hard to follow
[09:59] <ais523> I've been considering writing a drop-in replacement for BAMF using entirely different algorithms, just for fun really, to see how accurate I can get it
[09:59] <ais523> also because the current architecture of BAMF fails at corner cases and there's no obvious way to fix it
[09:59] <ais523> anyway, I have to /away for a while, got a seminar to attend…
[10:00] <seb128> ais523, can we encourage you to contribute fixes to the current code rather? ;-)
[10:00] <elky> ais523, i wonder, you know how you said rewriting the icon or launcher name or whatever can make it trip out if you do it too much... what about highlights in, say, irc?
[10:00] <elky> could they bank up too high and make it flip out?
[10:01] <elky> so like every time xchat gets pinged
[10:01] <didrocks> tsdgeos: FYI, avoid to edit those patch by hand
[10:01] <didrocks> tsdgeos: you didn't bump the lines number, and so the patch applies, but the package FTBFS as the file is truncated
[10:02] <tsdgeos> didrocks: i didn't apply it byhand
[10:02] <tsdgeos> i got the source and then did some quilt stuff
[10:02] <didrocks> tsdgeos: hum, weid, the line numbers didn't change, quilt would obviously change the lines
[10:02] <didrocks> @@ -0,0 +1,133 @@
[10:02] <tsdgeos> not saying i did something wrong :D
[10:02] <didrocks> your file is taking now more lines
[10:03] <tsdgeos> true
[10:03] <didrocks> was scratching my head why the file was truncated :)
[10:03] <tsdgeos> that part i hand edited, since for some reason my header was somehow different
[10:03] <tsdgeos> and took one line more
[10:04] <tsdgeos> my quilt diff didn't have the Index: nautilus-3.5.1/src/unity-bookmarks-handler.c stuff
[10:04] <tsdgeos> so i copied it back
[10:04] <tsdgeos> obviously too much
[10:04] <didrocks> if I replay your patch to the vanilla version and quilt refresh, it's fine
[10:04] <didrocks> the lines are bump
[10:04] <didrocks> bumped*
[10:04] <tsdgeos> good
[10:04] <tsdgeos> so no need for me to update my patch?
[10:06] <didrocks> no no, was just a notice :)
[10:43] <tsdgeos> didrocks: any idea why i can't change the status of https://code.launchpad.net/~aacid/nautilus/fix_quicklist_underscore to merged?
[10:43] <tsdgeos> it's *my* branch
[10:43] <tsdgeos> i should be able to change it, no?
[10:44] <didrocks> it is already merged, isn't it?
[10:44] <didrocks> (the status)
[10:44] <didrocks> tsdgeos: the credential is the destination owner one, which makes sense
[10:44] <didrocks> as you are claiming it's merged into the destination
[10:45] <tsdgeos> didrocks: status of the merge request is merged
[10:45] <tsdgeos> not status of the branch itself
[10:45] <tsdgeos> under the "Branch information" stuff
[10:45] <didrocks> what is the status of the branch?
[10:45] <didrocks> where do you see it?
[10:45] <tsdgeos> scroll down a bit
[10:45] <tsdgeos> under the "Branch information" header in https://code.launchpad.net/~aacid/nautilus/fix_quicklist_underscore
[10:45] <didrocks> ah
[10:46] <tsdgeos> can you edit that?
[10:46] <didrocks> never used that TBH after years of coding in launchpad and bzr :)
[10:46] <didrocks> no, I can't edit yours
[10:46] <tsdgeos> i usually have a yellow edit button there
[10:46] <tsdgeos> i can't edit mine either :D
[10:46] <didrocks> weird, I guess it's because you did it in the "nautilus" namespace
[10:46] <tsdgeos> the problem if that if I don't set that to "merged" it still shows in https://code.launchpad.net/~aacid
[10:46] <didrocks> which corresponds to upstream nautilus
[10:47] <tsdgeos> polluting my view of that
[10:47] <didrocks> where we both don't have the right
[10:47] <didrocks> (same for the bug, you opened it against upstream nautilus)
[10:47] <tsdgeos> i didn't open it
[10:47] <tsdgeos> i reassigned it :D
[10:47] <didrocks> ok, the guy opening it did it against the wrong component :)
[10:47] <tsdgeos> so it'll be there forever?
[10:47] <didrocks> maybe try on #launchpad, ask them to change the status?
[10:48] <tsdgeos> will do
[10:48] <tsdgeos> tx
[10:48] <didrocks> but yeah, the credential should be either project owner OR branch owner
[10:55] <tsdgeos> didrocks: i wasn't logged in ... :D
[10:56] <didrocks> tsdgeos: ok, so a sensible explanation in the end :)
[11:03] <tsdgeos> do you guys what is responsible for the "eject even if busy" dialog when trying to eject a busy device?
[11:04] <tsdgeos> it doesn't really work
[11:04] <tsdgeos> and you end up in an infinite loop
[11:04] <tsdgeos> of pressing "eject, i don't care"
[11:04] <tsdgeos> and the dialog showing up again :D
[11:18] <kwoot> Can anybody tell me how to add something globally to the launcher using a script? For a desktop post-install script, so before users are known to the system.
[11:21] <bobweaver> kwoot,  you are talking about packaging ? and postinst or preinst ?
[11:23] <kwoot> Hi alan_g, well at the moment simply a bash script to be run manually (it already adds our network printers and joins to the AD domain using likewise). I also want to add our time registration tool in the launcher (just to make it nice) and some dekstop items to shares that I try to mount using pam_mount.
[11:24] <kwoot> alan_g: if there are postinst hooks to the standard iso image (like if exist file x then exec that thing) would also be very nice
[11:24] <bobweaver> kwoot,  that is in debconf
[11:24] <kwoot> alan_g: but the most important thing right now is adding someting to the launcher.
[11:25] <bobweaver> for servers set up or not qbiquity
[11:25] <kwoot> bobweaver: what is? the launcher thing?
[11:25] <bobweaver> you can make small script run form applications
[11:25] <bobweaver>  /usr/share/applications/name.desktop
[11:26] <bobweaver> exec =  gnome-terminal -e 'bash -lc " CODE GOES HERE "';
[11:26] <kwoot> bobweaver: i found the usr/share/applications dir but adding a file there does not mean it shows up in the launcher
[11:26] <bobweaver> really ?
[11:28] <bobweaver> kwoot,  http://askubuntu.com/questions/35488/what-custom-launchers-and-unity-quicklists-are-available
[11:28] <kwoot> My postinst adds a desktop file to /usr/share/applications. Then when a user signs in he gets a fresh homedir and a desktop session, but not an extra launcher. So where is the current laucher configuration stored?
[11:28] <bobweaver> I dont know I am sorry
[11:31] <kwoot> bobweaver: the url is great, thanks! But it only works for already existing users. I will however use some of the scripts in my setup. Great stuff!
[11:33] <bobweaver> Kwoot I wonder if there is option to put in auto not sure thou
[11:49] <ais523> <seb128> ais523, can we encourage you to contribute fixes to the current code rather? ;-) <-- the problem is that the current matching algorithm of the code is almost entirely a) dependencies on things that are unsafe to depend on, and b) special cases
[11:49] <seb128> ais523, what do you consider "unsafe to depend on"? just curious
[11:49] <ais523> seb128: which desktop file was used to actually launch an application
[11:50] <seb128> ais523, I guess a lot of that has to do with experience, there is no clean way to do matching (or at least there was not at the time bamf was started, some things improved since)
[11:50] <ais523> measured by getting the window manager to add it as an X property to its window
[11:50] <ais523> this works in all the most common cases, but there are a lot of cases (multiple .desktop files for the same application, application closes its initial window and launches another, application launched from command line…) that make it fail
[11:50] <seb128> like there is lot of diffling around and hacks to support exotic setups
[11:51] <ais523> and it's quite easy to end up with multiple copies of the same command in the launcher
[11:51] <ais523> I sort-of have theories on how to do it in a cleaner way, but they're very experimental and so I wouldn't want to try to apply them to the current codebase
[11:51] <seb128> right, well experimentation is cool and maybe something great will come out of it ;-)
[11:51] <seb128> still we can probably fix some of those cases on what we have
[11:52] <seb128> like the "closes its initial window and launches another" is fixed in trunk
[11:52] <seb128> it's bug #995916
[11:52] <ubot5> Launchpad bug 995916 in unity (Ubuntu) "No launcher icon or Alt+Tab entry for Gimp windows" [High,Fix committed] https://launchpad.net/bugs/995916
[11:53] <ais523> seb128: that's not exactly the case I'm thinking of
[11:53] <ais523> with me, it happens with Wine; it'll match it to the correct Wine application on the initial window, then to the wrong Wine application on the reload
[11:54] <ais523> even with trunk bamf
[11:54] <elky> ais523, I'm still here for a short time if you have more ideas :P
[11:54] <ais523> unless I've got the wrong repo
[11:54] <ais523> elky: I'm reasonably sure it's a bug in the code that does the layout for the launcher
[11:55] <ais523> but I couldn't actually find the code in question
=== MacSlow is now known as MacSlow|lunch
[11:55] <elky> so did you see my theory earlier?
[11:55] <ais523> no
[11:56] <ais523> seb128: that said, I've /also/ seen 995916, which at least seems possible to fix with the current codebase
[11:56] <elky> http://paste.ubuntu.com/1000680/
[11:56] <seb128> ais523, it would be good if you open bugs about the buggy cases you run into, or chat about with DBO or Trevinho (they are the ones doing most of the bamf work)
[11:57] <ais523> elky: that can't be the problem by itself, but it might be what triggers it
[11:57] <ais523> as in, the bug's somewhere else, but that might be the codepath that causes the bug to expose
[11:58] <ais523> bamf really needs help from the actual applications to do everything I want it to do, sadly
[11:58] <seb128> ais523, the issue with things like "run something from the command line" is that you get virtually no info to match to an icon and proper user friendly name for the launcher entry
[11:58] <ais523> well, unless I'm allowed to run the applications at package install time to check how they behave (obviously ridiculous), or on the buildds (only slightly less ridiculous)
[11:59] <Trevinho> ais523: actually it doesn't make the difference from which desktop you run an app in BAMF...
[11:59] <ais523> seb128: well, a modification I'm already using in my local Unity is, if there's only one window of an application open, to show its title as the launcher entry tooltip rather than the name of the application
[11:59] <seb128> ais523, right, which is why toolkits got improved support
[11:59] <ais523> Trevinho: yes it does, this is very easily proved using any "run in terminal" launcher entry
[11:59] <Trevinho> it matches windows, associating them to .desktop files... This doesn't depend on which one you used
[11:59] <seb128> ais523, could you please open bugs with infos about those? that might help to discuss them and come to solutions
[11:59] <ais523> it does, because which .desktop file you used is saved as an xprop on the window
[11:59] <Trevinho> ais523: that's another case...
[12:00] <Trevinho> ais523: when using a launcheritem you're running a bamfapplication... that is currently in non-running state.
[12:00] <ais523> so bamf itself is starting the application, and remembering the desktop because of that?
[12:00] <elky> ais523, if you agree that's a possibility, we ought to be able to test the hypothesis then
[12:01] <ais523> it comes to the same thing from the user interface point of view
[12:01] <Trevinho> no ais523... the application is ran by unity, but the bamfApplication is already opened... Not newly generated by the daemon
[12:01] <ais523> elky: I guess it wouldn't be too hard to write a simple application that used dbus to spam the launcher (rather than notify-osd) with notifications, would be useful for testing generally even if it doesn't solve this problem
[12:02] <ais523> Trevinho: let me go set up a test right now
[12:02] <ais523> this would be easier if gnome-open actually matched its documentation…
[12:02] <Trevinho> however ais523 I ensure you that there are so many corner cases that it's not so easy to handle everything in the same way
[12:02] <ais523> guess I'll use nautilus instead
[12:02] <ais523> Trevinho: I agree that there are loads of corner cases
[12:02] <ais523> however, many of the ones I've seen in bamf source (the OpenOffice special cases, for instance) could be handled in a more general way than special-casing one application
[12:03] <Trevinho> ais523: not sure about OO... Not everything of that codepath can be generalized
[12:03] <Trevinho> some parts yes, but not everything
[12:04] <Trevinho> ais523: the wine case is something I'd like to work on, but I simply had other priorities before... However there I think that just having wine to generate .desktop files with StartupWMClass that matches the .exe file could be an improvement, even if I'm not sure he can do that on installation time
[12:04] <ais523> ooh, I was hoping there was something along the lines of StartupWMClass in the .desktop file format
[12:06] <ais523> Trevinho: hmm, so what I did was created three .desktop files in .local/share/applications, each of which opened a shell in a terminal, but with different names (two using the same shell, one using the third)
[12:06] <Trevinho> ais523: for example for the web-app code (chromium) I always tried to avoid to introduce too much special code only chromium-related... It worked well, but there are some cases where we can't just "think in general", so I had to accept that few codepaths depends on chromium itself, even if they're reduced to the minimum
[12:06] <ais523> I opened each of them via Nautilus, in order to avoid BAMF getting involved in the launch
[12:06] <ais523> and bamf grouped them all together, but separately from a terminal I launched via the launcher
[12:07] <ais523> and if I launch a terminal via keyboard shortcut, that one groups with the launcher terminal
[12:07] <ais523> anyway, one improvement I /would/ like to make is to recognise whether a launcher entry is a subset of another
[12:08] <Trevinho> ais523: can you give a try to this: https://code.launchpad.net/~3v1n0/bamf/better-wmclass-filter ?
[12:09] <Trevinho> ais523: they should be grouped together, unless they don't have a different startupWMClass...
[12:09] <ais523> OK, I merged your changes with the trunk I already had
=== _salem is now known as salem_
[12:11] <Trevinho> make sure you reload both unity and bamfdaemon
[12:11] <ais523> I know
[12:12] <ais523> bleh, it put everything onto the same desktop, I forgot it does that when you restart Unity (although ofc it's inevitable)
[12:12] <elky> ais523, cool. well i'm going to head to bed now, let me know how you go with the test if you make it
[12:13] <elky> I'll leave the machine in its broken state until i get totally pissed off at it, ping me with debug ideas if you need to
[12:15] <ais523> Trevinho: well, I get completely the same result as stock BAMF with respect to the terminals
[12:15] <ais523> but now I have two copies of Akregator, the pinned one and the one that's actually running
[12:16] <ais523> your patch seems to have chosen a better one than the one I had pinned
[12:16] <Trevinho> that's weird...
[12:17] <ais523> bleh, testing this would be easier if I could just open a .desktop file from the command line
[12:17] <ais523> gnome-open is meant to do it, but it opens the .desktop file in gedit rather than running the application it describes
[12:18] <ais523> (and this is with executable bit set)
[12:19] <ais523> Trevinho: OK, here's one for you; if I open test1.desktop (which is not the same BAMF application as gnome-terminal.desktop), and also gnome-terminal.desktop, then run the command gnome-terminal in each, then the terminal opened from the test1 window is part of the test1 application, and the terminal opened from the gnome-terminal window is part of the gnome-terminal application
[12:19] <ais523> and yet I ran exactly the same command in each case
[12:20]  * ais523 diffs the xprop output
[12:21] <Trevinho> well... it depends how you started them...
[12:21] <ais523> let me try running /usr/share/applications/gnome-terminal.desktop from Nautilus
[12:22] <Trevinho> have you used --disable-factory in one of them?
[12:22] <ais523> not intentionally
[12:22] <Trevinho> I mean, they're two different proceses...
[12:22] <ais523> oh, interesting: gnome-terminal.desktop groups with test1
[12:23] <Trevinho> well, if they matches the content is right...
[12:23] <Trevinho> just gnome-terminal.desktop should have an higher priority
[12:23] <Trevinho> depending on where is placed in your system and its basename
[12:24] <ais523> so test1 is in .local/share/applications, gnome-terminal is in /usr/share/applications
[12:24] <Trevinho> so test1 has an higher prio
[12:25] <ais523> now, if I close all test1 windows, then open test2 via Nautilus, it counts as a test2 window not a test1 window
[12:25] <ais523> and if I then open test1, it counts as a test2 window too
[12:26] <ais523> (this is with your BAMF)
[12:26] <ais523> and I now have way too many terminal windows, let me close some
[12:27] <ais523> priority seems to be involved in the desktop files I'm opening /somehow/, but it's unclear how BAMF is getting at that information
[12:28] <ais523> oh, must be zeitgeist, obviously
[12:28] <Trevinho> well... the idea is that if the .desktop files are pointing to the same app, then they're basically all the same from a launching point of view... The difference is that the first .desktop on the priority list is used... Until you don't pin another to the launcher
[12:28] <ais523> if I open a launcher from Nautilus, it puts it in zeitgeist, and then BAMF is looking at that to determine the highest priority…
[12:28] <ais523> does BAMF know what is and isn't pinned, by the way?
[12:29] <Trevinho> ais523: yes, it's possible that something sets the .desktop files as xproperty
[12:29] <Trevinho> yes
[12:29] <ais523> Nautilus doesn't, I checked that one
[12:29] <ais523> set an xproperty, I mean
[12:29] <Trevinho> favorite applications daemon-side are the applications on the launcher, even if not opened
[12:29] <ais523> but it does add zeitgeist entries for .desktop files it opens
[12:30] <ais523> and that must be shuffling the priorities around
[12:32] <Trevinho> ais523: need to go now... brb, feel free to report me your tests and results... If you add some debugging bits to src/bamf-matcher.c bamf_matcher_setup_window_state could help you in understanding what's going on
[12:32] <ais523> I find bamf's source pretty hard to follow, unfortunately, but I got the general gist of what it's doing
[12:33] <ais523> the algorithm I was wondering about was giving score for matching in a wide range of categories (window class, command line, window role, and even things like title and icon), and choosing the best match that way
[12:33] <Trevinho> ais523: yes, the matcher is a little bit tricky... but the main part is happening there about associating windows to applications
[12:34] <ais523> and ideally it'd be able to get a list of the URLs (files or whatever) open in each window of an application, to allow matching against a launcher that's one specific file rather than a whole application
[12:36] <Trevinho> we're mostly using win class, command line, pids... Even if the pid (and so opened files) could cause some confusions for apps like chromium that have one pid for all sub-apps...
[12:38] <ais523> I don't see how the PID could help directly, it's an arbitrary number each time
[12:38] <ais523> do you mean the procfiles for the PID?
[12:51]  * Zhenech looks over to tedg and whispers: meeeeerge ;)
=== seb128 is now known as robert_ancell
=== robert_ancell is now known as seb128
=== MacSlow|lunch is now known as MacSlow
[13:41] <mhall119> tedg: got a minute for a quick PM?
[13:51] <Trevinho> ais523: the pid helps when programs set the xproperty PID value to a window, so we can get from that the ran proc, and then the associated .desktop file
=== andyrock|uni is now known as andyrock
[14:00] <tedg> mhall119, No, calls all morning... this afternoon?
[14:04] <mhall119> tedg: sure, just let me know when you have a few minutes, it shouldn't take long
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== nhandler_ is now known as nhandler
=== dandrader is now known as dandrader|lunch
=== dandrader|lunch is now known as dandrader
=== bregma_ is now known as bregma
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== salem_ is now known as _salem