[09:54] <hrw> didrocks: can we discuss few moments about bug 897697?
[09:55] <didrocks> hrw: hey, sure
[09:55] <hrw> didrocks: I just wrote commend in it in which I do not agree with you and would like to get it sorted
[09:55] <hrw> commen{s/d/t}
[09:56] <didrocks> hrw: please, tell me :)
[09:56] <hrw> 2When I disable Expo plugin (Desktop Wall is enabled) and click launcher icon there is no reaction. When I enable it again it gives me desktops preview.
[09:56] <hrw> With two Chrome windows open when I press on Chrome icon in launcher I get preview of them even with Expo plugin disabled.
[09:56] <hrw> Enabling "Rotate Cube" enables "Desktop Cube" which conflicts with "Desktop Wall" which is required by "Unity" - that's what ccsm just told me.
[09:57] <didrocks> hrw: one sec, finishing a discussion first
[09:58] <hrw> sure, no rush
[09:59] <didrocks> ok, back :)
[09:59] <didrocks> so, launching ccsm
[10:00] <didrocks> hrw: if I remove desktop wall, unity wants to be removed as well
[10:01] <hrw> sure, but you wrote "the wall plugin (the one which has the button in the laucher), is an unity dependency.
[10:02] <hrw> Unity depends on a "largedesktop" feature, which is provided by both wall and cube, so both are compatible and at least one of the two should be enabled to unity to be enabled."
[10:02] <hrw> so I just tried and we can skip this part
[10:03] <didrocks> hrw: hum, that's true. This is what sam told me though
[10:03] <didrocks> hrw: I'll check with him, there is a missing piece there
[10:03] <hrw> anyway that part is not important
[10:03] <hrw> I am more interested in Expo plugin part
[10:03] <hrw> as this is what bug was about
[10:05] <didrocks> hrw: well, making it dependant? I think we should be careful as cube enters the dance into that for people wanting to enable that
[10:06] <hrw> so expo plugin itself is not compatible with cube?
[10:08] <didrocks> hrw: well, sam told me about wall
[10:08] <didrocks> not expo
[10:08] <didrocks> but when he meant wall, he meant the desktop switching expo view
[10:08] <didrocks> so, that's why we need to discuss about it
[10:09] <hrw> ok
[10:09] <hrw> btw - is there a way to get rid of this expo button from launcher?
[10:09] <hrw> also would like to drop trash
[10:09] <didrocks> hrw: apart from changing the code itself, I'm afraid you can't
[10:10] <hrw> ;(
[10:10] <hrw> will report wishlist bugs for it ok?
[10:11] <didrocks> hrw: yes please :)
[10:13] <hrw> bug 883603 exists already
[10:14] <hrw> set to wishlist, set as affecting so it is confirmed now
[10:16] <hrw> bug it may be duplicate of bug 821082
[10:22] <hrw> and both may be duplicate of bug 759724
[10:29] <hrw> marked as such
[10:29] <didrocks> hrw: yeah, do not hesitate to mark as duplicate and change status :)
[10:29] <didrocks> thanks!
[10:39] <hrw> according to Unity code Trashcan can be hidden only by changing code. Someone would have to implement code from DeviceLauncherIcon into TrashcanIcon
[10:41] <didrocks> Indeed
[10:57] <om26er> kamstrup, Hi! care to comment on this bug 888607
[10:57] <om26er> i think i might have faced the issue once in the past month
[12:40] <jo-erlend> http://askubuntu.com/questions/85309/how-to-enable-dropping-any-file-type-on-particular-or-any-unity-launcher-item <--- I'd like to know that myself. The LauncherAPI page doens't describe that at all.
[13:39] <kamstrup> mhr3: at your service https://code.launchpad.net/~kamstrup/libunity/faves-enumerator/+merge/84470
[13:40] <kamstrup> mhr3: this is a first step in https://bugs.launchpad.net/unity-lens-applications/+bug/893214
[13:41] <kamstrup> the question is whether I should add the u-l-a changes now or later - depending on the state of your ports?
[13:52] <mhr3> kamstrup, it's incomplete, right? john wants to filter out also running apps (non-pinned)
[13:53] <kamstrup> mhr3: oh
[13:53] <kamstrup> mhr3: I think the LauncherFavorites API makes sense still
[13:54] <mhr3> kamstrup, sure
[13:54] <kamstrup> mhr3: but I guess it'll be bamf work for the running apps
[13:55] <kamstrup> i have no idea about the state of the bamf vapi
[13:56] <kamstrup> meh, seems there is no such thing as vala bindings for bamf
[13:57] <kamstrup> who wants to make it easy anyway?
[14:01] <kamstrup> mhr3: I think we should just writye the bamf glue in C inside u-l-a. I wouldn't want all apps using libunity to pick up a connection to the chatty bamfdaemon and cause spurious wakeups all over the place
[14:03] <kamstrup> mhr3: also I think we're free to interpret what "in the launcher" means
[14:03] <kamstrup> honestly I think it means "favorite"
[14:04] <kamstrup> but there's room to figure out what feels "right" of course
[14:07] <mhr3> kamstrup, sure, but it's still going to be a lot of wakeups for poor ula
[14:46] <API> lamalex, hi again, did you see my comments on that merge proposal? they were a answer to your comments
[16:05] <gord> mhr3, bschaefer - so i'm thinking to fix this https://bugs.launchpad.net/unity/+bug/711199 - we need the lenses to expose a string for when there are no results, as its different for each lens. can we add api for this?
[16:08] <bschaefer> gord, so add something in the Lens.cpp in UnityCore to hold an empty results string?
[16:08] <gord> bschaefer, basically yeah, but we need the lenses to provide that, hence, mhr3 ;)
[16:09] <mhr3> gord, i'd like to hear from ayatana first
[16:09] <mhr3> do we really need special string for each lens?
[16:10] <davidcalle> mhr3, "This lens needs an internet connexion to provide results"
[16:10] <mhr3> davidcalle, good point
[16:10] <gord> mhr3, well its what design want and i don't want to hard-code this in unity ;)
[16:12] <mhr3> seems to me the design isn't complete yet
[16:13] <bschaefer> mhr3, yeah I just changed it to have john look at it again since the bug is old. Such as the home lenses is getting changed this cycle also
[16:13] <gord> mhr3, oh sorry no right, JohnLea set it to fix committed, the solution in the description is what he edited in there, its confusing i know. let me set that back to fix-commited
[16:13] <bschaefer> thumper told me to mark it as incomplete to have john look at it again is why I did that
[16:14] <mhr3> gord, but yea, i agree that it should be completely dynamic
[16:14] <gord> JohnLea, https://bugs.launchpad.net/unity/+bug/711199 <-- seem okay to you? bit of confusion
[16:22] <JohnLea> bschaefer, mhr3, gord; If you need me (or someone else in design) to look at a bug, set it's status in *unity* (or whatever the relevant project is) to "incomplete".  Don't change the ayatana-design status!  We have a script that looks for bugs with specific upstream and downstream statuses, and reports when those statuses are inconsistent with the status in ayatana-design.
[16:24] <JohnLea> bschaefer, mhr3, gord; If a bug has a status of 'fix-committed' or 'triaged' in ayatana-design it is signed off by design and ready to go ;-)
[16:24] <bschaefer> JohnLea, sorry about that, thought the one you were under was what needed to be changed to get an email sent to you!
[16:26] <JohnLea> bschaefer; no worries, to see the design view of bugs have a look at http://people.canonical.com/~platform/design/designer.html
[16:29] <gord> JohnLea, just a note, one thing that had me confused with that bug (and i think this is why this happened) you edited the description without noting in the comments that you did, so it looked like it was sebs idea not the signed off design idea :) can you just note that in future, either in the description or comments is fine, should stop confusion somewhat
[16:32] <JohnLea> gord; no prob, I'll leave a description updated comment in the future
[16:32] <gord> JohnLea, awesome :) thanks
[16:32] <gord> mhr3, so we cool to add something to the lenses to get the string?
[16:33] <mhr3> gord, lenses already return a{sv} from a search, time to add it there i guess :)
[16:34] <gord> nice
[19:56] <thumper> bschaefer: sorry about giving you incorrect info, I thought I told you right
[20:45] <cdbs> om26er: there?
[20:45] <cdbs> argh, he isn't in the channel. /me hates irssi
[23:55] <bschaefer> thumper: no worries, I could have miss read what you said also
[23:56] <bschaefer> thumper: it was all fixed, also did you take a look at what was said about the bug?
[23:59] <thumper> bschaefer: no