[06:02] <didrocks> good morning
[06:39] <jhenke> hi any firefox involved people here?
[08:03] <Laney> hey hey!
[08:04] <seb128> hey Laney,  how are you?
[08:04] <Laney> tea, sun, #ubuntu-desktop
[08:04] <Laney> what more could anyone need?
[08:05] <Laney> you?
[08:05] <Laney> oh, and fake friday!
[08:05] <seb128> coffee, blue sky, nothing to complain about today!
[08:06] <seb128> yeah, it's between troll day and troll day
[08:08] <Laney> chpe even applied my patch
[08:08] <Laney> what a world we live in
[08:08] <didrocks> good morning Laney
[08:09] <Laney> hey didrocks
[08:09] <Laney> what's happening?
[08:10] <didrocks> Laney: normal Thursday for me ;)
[08:11] <didrocks> happy that we found the systemd autopkgtests issue and now reverted in experimental
[08:11] <Laney> oh yes, let's see if my container has network this morning ;-)
[08:19] <Laney> nope!
[09:09] <darkxst> hey laney, seb128 didrocks
[09:10] <darkxst> can someone take a look at bug 1437150, more fallout from the adwaita-icon-theme switch
[09:12] <Laney> ok
[09:12] <Laney> what package does it try to install?
[09:15] <seb128> Laney, I'm unsure about your nautilus question from yesterday, why what got used?
[09:16] <seb128> Laney, the new .desktop? because I guess that's what upstream use as an autostart or is dbus activated
[09:16] <seb128> that's not something I did/know about, you did that update iirc :-)
[09:17] <darkxst> Laney, it tries to install some part of samba for the sharing
[09:18] <Laney> yes - you've done some changes around this area recently so I thought you might know
[09:20] <seb128> well, I though we ought to use the new name
[09:20] <seb128> so I migrated the unity config, default&upgrade to use that
[09:20] <Laney> darkxst: I just wanted to know what to uninstall to reproduce this
[09:20] <seb128> which makes the launcher matching work now with the running nautilus
[09:20] <seb128> but it creates an issue still with the dash
[09:21] <seb128> unsure what to do next
[09:22] <Laney> does it work if you swap the NoDisplay?
[09:28] <darkxst> Laney, probably just uninstall samba
[09:28] <darkxst> not sure if this affects the ubuntu themes though, they may still have the legacy icons
[09:29] <seb128> Laney, I didn't try, but I guess, it would make the dash list the one used in the launcher/by nautilus
[09:30] <Laney> if so, then maybe you can make nautilus.desktop be NotShowIn=Unity and org.gnome.Nautilus.desktop be OnlyShowIn=Unity
[09:31] <Laney> which should keep compatibility with panel/xfce/whateveritwas and work with your new stuff
[09:33] <seb128> Laney, hum, right
[10:18] <Laney> hmm
[11:36] <didrocks> Laney: I'm happy to use g_clear_error(), even if it doesn't match what other part of the code is doing
[11:37] <didrocks> Laney: I'm wanting to avoid using initctl for now, as it seems those things can be slow on the bq device (that's what I was doing first, when asking people with a bq to test)
[11:40] <Laney> really?
[11:42] <didrocks> Laney: yeah, I have this issue as well when using invoke-rc.d status already
[11:42] <didrocks> and as it's dbus sync call (apparently…)
[11:42] <didrocks> Laney: I'm rebuilding with g_clear_error
[11:43] <didrocks> Laney: reuploaded
[11:44] <Laney> seems fast enough here
[11:44] <Laney> meh
[11:44] <Laney> it's really shit that we can't do correct solutions
[11:44] <didrocks> Laney: well, ask seb, he did the test
[11:44] <Laney> thanks for the other fix
[11:44] <didrocks> (on bq)
[11:44] <didrocks> Laney: TBH, the systemd one is the correct solution, and I hope the phone will switch to it soon enough
[11:45] <Laney> it's about using the best interface available for the job
[11:46] <didrocks> the best interface would have been to have a dbus one
[11:46] <didrocks> instead of grepping on tools output or reading files
[11:46] <Laney> doesn't exist though does it
[11:46] <Laney> best interface *available*
[11:46] <didrocks> I disagree that grepping on output is better than reading a file
[11:47] <Laney> if I edit this file and comment out the manual line
[11:47] <Laney> then you give the wrong answer now
[11:48] <didrocks> Laney: well, it was giving the wrong answer before as well (the fact to create the file would have given the wrong answer)
[11:48] <didrocks> and same with the enabled even before
[11:51] <Laney> I'd choose right over less wrong
[11:51] <Laney> but okay
[11:56] <larsu> Laney, the idealist
[12:09] <GunnarHj> infinity: Thanks for rescuing me yesterday. Embarrassing mistake this late in the cycle. :(
[12:15] <Laney> larsu: is there an enviornment variable to change the icon theme à la GTK_MODULES?
[12:16] <Laney> can't see anything in the docs, so I guess not
[12:36] <larsu> Laney: XDG_DATA_DIRS
[12:39] <Laney> and copy the one I want to use?
[12:40] <larsu> oh wait, I misread sorry
[12:40] <larsu> you want a different theme, not a different search path
[12:40] <larsu> that's a xsetting, no?
[12:40] <Laney> ye
[12:41] <Laney> just wanted to override it once
[12:41]  * larsu looks at the source
[12:42] <larsu> Laney: no such thing exists. You could set it in the overrides key of the xsettings g-s-d plugin
[12:43] <larsu> but then, you might as well change the icon-theme key itself
[12:43]  * Laney nods
[12:43] <Laney> I just did that
[12:43] <Laney> thanks for checking!
[12:44] <larsu> maybe it makes sense to add that?
[12:44] <larsu> I've never felt a need for it myself though
[12:44] <Laney> I use GTK_THEME from time to time
[12:44] <Laney> probably would use an icon one less frequently
[12:46] <larsu> we have kind of changed the definition of theme anyway
[12:46] <larsu> it includes icons now
[12:46] <larsu> at least in the user-facing ui
[12:47] <larsu> maybe it makes sense to formalize that and make GTK_THEME respect it?
[12:47] <Laney> you mean our UI sets both?
[12:47] <larsu> yes. It sets a lot of things
[12:47] <Laney> how does this work?
[12:47] <Laney> does the theme say what its matching icon theme is?
[12:48] <larsu> there are files somewhere in /usr/share that describe a full theme
[12:48]  * larsu tres to find them
[12:48] <Laney> ya index.theme has this
[12:49] <larsu> indeed
[12:49] <larsu> not saying we should teahc gtk about that file
[12:49] <larsu> but we could think about it
[12:50] <Laney> what does consume it now?
[12:51] <larsu> a myriad of things from xsettings, gsettings, and env variables
[13:01]  * Laney feels hungry and realises he hasn't eaten yet
[13:03] <didrocks> Laney: quick, go eating! :)
[14:08] <Laney> got to eat outside
[14:08] <Laney> SPRING!
[14:16] <ogra_> in the snow yu mean ?
[14:16] <Laney> don't curse me
[14:16] <Laney> sunny, no wind
[14:16] <Laney> it was at least 10°!
[14:16] <ogra_> nah, i cant blame you that it snows in germany since two dasys :)
[14:16] <ogra_> *days
[14:17] <Laney> you need to get yourself a jet stream
[14:18] <ogra_> heh, my house is that tall
[14:18] <ogra_> *isnt
[15:51] <Laney> seb128: do you know if https://bugzilla.gnome.org/show_bug.cgi?id=744282 got looked at further?
[15:54] <seb128> Laney, no, desrt never got back to me here
[15:57] <Laney> that guy!
[16:09] <seb128> desrt, ^ can you comment on that please?
[16:10] <desrt> interesting
[16:11] <desrt> iirc that conversation was quite old
[16:13] <desrt> seb128: i'd be interested to know if gedit is installed in ~/.local/share or ~/.config somehow
[16:13] <seb128> desrt, yeah, well it's making apport files open in gedit rather than being sent to launchpad
[16:13] <desrt> like in a mime config file
[16:13] <seb128> no it's not
[16:13] <desrt> not even in the mimeapps?
[16:13] <seb128> it's just that glib prefers a default handler for a subtype than an handler for that exact type
[16:13] <desrt> oh.
[16:14] <seb128> text/x-crash has only one handler, apport-gtk.desktop
[16:14] <seb128> but it's a subtype of text/plain
[16:14] <desrt> but it's not in defaults.list
[16:14] <seb128> which has gedit as default handler
[16:14] <seb128> no
[16:14] <desrt> right
[16:14] <desrt> okay
[16:14] <desrt> that's a different issue from what i think i was talking to teuf about
[16:14] <seb128> but it's the only handler for that exact type
[16:14] <desrt> and i'm not 100% sure i agree that the behaviour is wrong
[16:14] <seb128> I don't think so
[16:14] <seb128> so if you have 1 handler for the exact type that should not be the one used?
[16:15] <seb128> lot of types subclass text/plain
[16:15] <desrt> not if you explicitly listed a default for the less specific type
[16:15] <seb128> it seems wrong to prefer gedit rather than the "native" handler
[16:15] <desrt> well, you could just as well add the native handler to the defaults list
[16:15] <seb128> that's a workaround
[16:15] <desrt> i'd say it's the correct solution
[16:15] <desrt> but to be honest, i'm not sure
[16:15] <desrt> and i don't think the spec says one way or the other
[16:16] <seb128> so you say it's normal that .ui files open in gedit rather than glade if glade is not set default
[16:16] <seb128> or apport files in gedit rather than apport
[16:16] <seb128> that seems backward to me
[16:16] <desrt> gimme a sec.  reading the spec.
[16:16] <seb128> thanks
[16:17] <desrt> the spec is totally oblivious to inheritence and aliasing :(
[16:17] <seb128> well to me it would make sense to pick an handler for the exact type if possible, whatever the case is
[16:17] <desrt> the patch to make the spec do what you want would be smaller than the patch to make the spec do the other thing
[16:17] <desrt> so let's assume you're right :p
[16:17] <seb128> lol
[16:18] <desrt> i'll look into it today
[16:18] <seb128> thanks
[16:23] <nrosvall> Hi, I'm working on a quite big software project. Now when Unity 8 is coming and all that new stuff I'm wondering how much Unity 7 and 8 api will be different
[16:23] <nrosvall> say indicators? will indicators written for unity 7 work with unity 8?
[16:24] <nrosvall> (not sure if this is the right place to ask)
[16:32] <desrt> new favourite bug summary: " many aspects of human life have no main category. "
[16:33] <desrt> along with a bunch of other bugs advocating the creation of main categories for things like "farm management"
[16:34]  * desrt doesn't even know what a main category is, but is pretty sure 'farm management' isn't one
[17:21] <desrt> seb128: aside: how goes the migration from defaults.list?
[17:37] <seb128> desrt, we didn't do anything for that, I've it somewhere on my list of things we should look at but forgot the detauls so needs to sit down and read what we said on that topic back then
[17:39] <desrt> basically, it ought to be renamed to gnome-mimeapps.list
[17:40] <desrt> or unity-mimeapps.list, accordingly
[17:40] <desrt> ie: defaults depend on which desktop is logged in
[17:43] <seb128> desrt, oh, right, that's good, we need to do that next cycle ... or maybe while in London ;-)
[17:43] <desrt> it is also (theroetically) supported by qt
[17:43] <desrt> defaults.list has never been
[18:03] <desrt> seb128: you've thrown me into some fun territory here
[18:03] <desrt> the "consider each type separately logic" obvious logic gets non-obvious with negative results
[18:03] <desrt> like if i have an app that is listed as both text/html and text/plain
[18:04] <desrt> and someone has removed the text/html association
[18:04] <desrt> that app could still end up opening the file on the basis of the text/plain association, if that one was not also explicitly blacklisted
[18:05] <desrt> in that case, this "handle the subtype before moving up to the supertype" logic breaks down a bit
[18:07] <desrt> seems the spec will need some deeper clarifications...
[18:08] <desrt> it gets extra hard when the super-type match comes from the defaults list but the "removed" association was made via the more specific type.  the code has absolutely no way of dealing with this possibility, at present
[18:11] <larsu> desrt: do people even use all those features? Nautilus only lets you change associations, no? Not explicitley remove them
[18:11] <seb128> I don't think we have any UI that let you remove associations
[18:12] <seb128> we just have a way to set defaults
[18:12] <larsu> right
[18:12] <larsu> and that makes this whole thing *a lot* easier
[18:12] <seb128> indeed
[18:12] <seb128> in practice you just want to say "open that type of file with this software"
[18:12]  * larsu knows that desrt likes to solve the tricky problems
[18:12] <larsu> seb128: ya...
[18:16] <seb128> mitya57, thanks for sponsoring those u-s-d/gnome-desktop3 SRUs
[18:17] <desrt> you can definitely remove associations
[18:17] <seb128> desrt, how/where?
[18:17] <seb128> you can in the spec, I just don't think we have an UI for it
[18:17] <desrt> nautilus
[18:17] <desrt> right click a file, open properties
[18:17] <desrt> go to the "open with" tab
[18:17] <desrt> right click an app
[18:17] <desrt> "forget association"
[18:17] <larsu> dude, install ubuntu
[18:18] <seb128> right click doesn't do anything here
[18:18] <desrt> well, it does on upstream nautilus
[18:18] <larsu> hm/
[18:18] <desrt> (or at least nautilus as packaged by debian)
[18:18] <larsu> seb128: right click / propeerties works for me
[18:18] <seb128> new feature in 3.16?
[18:18] <seb128> larsu, I don't have a context menu on right click here?
[18:18] <larsu> desrt: in any case, that's a questionable feature
[18:18] <desrt> i don't think so
[18:19] <desrt> if a user doesn't like an app they may very well want to break an association made at the system level
[18:19] <larsu> seb128: you don't have a context menu in nautilus?! Craziness
[18:19] <desrt> larsu: i think he means on the apps in the open-with tab
[18:19] <larsu> desrt: no, more likely they'll want to set a different app
[18:19] <desrt> seb128: it doesn't work for the default app -- only the others
[18:19] <desrt> under "recommended applications"
[18:19] <larsu> oh
[18:20] <larsu> hm, it works for *some* of the others
[18:20] <desrt> anyway
[18:20] <larsu> meh, it's neither discoverable nor useful
[18:20] <desrt> i can see what you mean
[18:20] <larsu> seb128 and I didn't even know it existed
[18:20] <desrt> removing apps is a bit weird
[18:20] <desrt> but it's something that we have in the spec since prehistoric times
[18:20] <larsu> and considering that it makes the implementation considerably simpler
[18:20] <larsu> ...
[18:20] <desrt> since before it was a spec, frankly
[18:21] <larsu> nothing we can't change
[18:21] <desrt> dunno
[18:21] <desrt> the ability to remove associations is also API
[18:21] <desrt> although we could redefine that to "this is used for breaking incorrect associations that the user made themselves"
[18:21] <desrt> not for blacklisting stuff made at a different level
[18:21] <larsu> the most sacred asset we have. API. We never break or deprecate any of it!
[18:21] <desrt> ie: if you say that gedit can open jpegs
[18:21] <desrt> and later you decide that this wasn't a good idea after all
[18:22] <desrt> then you can fix it
[18:22] <desrt> but if gedit claims MimeType=image/jpeg in its desktop file, it is there forever
[18:22] <desrt> doing this would simplify things a fair bit....
[18:23] <larsu> if gedit claims it's name is GEdti in its desktop file, it is there forever
[18:23] <desrt> larsu: where were you when we were discussing this? :p
[18:23] <larsu> desrt: glad to save you some man-hours by dropping by this channel and quipping about something I have no business in
[18:23] <desrt> i guess none of us at the table, at the time, really considered just axing that part of the spec
[18:23] <larsu> desrt: not sure. When did you discuss this?
[18:24] <larsu> in NUR?
[18:24] <desrt> ya
[18:24] <desrt> (NUE, btw)
[18:24] <larsu> oh. thanks.
[18:24] <desrt> you were there :p
[18:24] <larsu> drunk maybe? Sleeping? Talking to rishi?
[18:24] <desrt> maybe
[18:24] <desrt> it was mostly david and i arguing over it
[18:24] <desrt> i guess we could say that handling of removed apps is optional
[18:25] <larsu> sounds good to me :)
[18:25]  * desrt is not yet convinced
[18:25] <larsu> I bet KDE is of a different opinion
[18:25] <desrt> :)
[18:25] <larsu> I don't know enough to convince you all the way I'm afraid
[18:25] <desrt> i'll open a bug and see if anyone says anything
[18:25] <larsu> maybe seb128 can help
[18:26] <larsu> desrt: I love how this works sometimes... I didn't even think much when typing this into here
[18:26] <larsu> was eating some bread and idly reading the last few lines of backlog
[18:29] <desrt> ya... having some outside-the-box stuff injected is often helpful
[18:29] <desrt> unfortunately i don't think it's actually helpful for today
[18:29] <desrt> since i'm certainly not making this change in glib now
[18:29] <desrt> so i'll still have to implement this mess
[18:29] <larsu> why?
[18:29] <desrt> but the one benefit is that i can tell myself that i don't have to bother trying to explain it consistently in the spec
[18:30] <desrt> because seb wants a bug fixed now, and this 'kill remove' thing is going to take some discussion
[18:30] <larsu> what's the bug?
[18:30]  * larsu does like a five-year old and asks all the whys
[18:30] <desrt> we prefer a default app for text/plain over a non-default (but available) app for a more specific type
[18:31] <desrt> like if gedit handles text/plain and we have firefox installed, but not marked as a default for text/html
[18:31] <desrt> then gedit would be picked as the default for text/html
[18:31] <desrt> since there is no "default" for text/html
[18:31] <larsu> that's a bug indeed, but I don't see how that's related
[18:31] <larsu> hm, I think I can imagine cases where you don't want this
[18:32] <larsu> ah no, should be fine
[18:32] <desrt> the problem comes when we have gedit with its association explicitly broken for text/httml, but still capable of handling text/plain
[18:32] <desrt> do we consider the text/html "removed association" as effecting gedit's ability to handle text/plain for a file that happens to be html?
[18:32] <desrt> or do we say "well, no... we didn't find anything for text/html, and it still handles text/plain... so let's do it!"
[18:33] <desrt> ie: we move towards a place where we consider each mimetype separately, in sequence, from most specific to least specific
[18:33] <larsu> hard to say
[18:33] <desrt> but it seems that there is a reason to want this process to be not-entirely-separated
[18:33] <larsu> I think if we don't have any other app, we should let gedit open it
[18:33] <larsu> but then, I think this whole removal thing is stupid
[18:33] <desrt> ya...
[18:34] <desrt> killing off remove would solve so many open questions like this
[18:34] <desrt> and you're right -- it's pretty borderline, as far as features go
[18:37] <desrt> it solves another more general annoying problem as well
[18:37] <desrt> with respect to user intent
[18:37] <desrt> if i right click on a html file and say "remove association for gedit"
[18:37] <desrt> am i intending to do that for html files, or for all text files?
[18:37] <desrt> since gedit doesn't really explicitly list text/html
[18:37] <desrt> it's sort of a random detail that the file that i used to open that dialog happened to be html
[18:38] <desrt> what if it was something even more texty, like a desktop file, but still had its own mime entry?
[18:38] <desrt> so now i have to take care to find a real 'text/plain' text file in order to do the operation i want?
[18:38] <larsu> haha yeah
[18:39] <larsu> that's a problem with mime types anyway: some of them are more "alike" than others
[18:41] <desrt> also reduces some of the complexities in dealing with mime aliases