[03:12] <duflu> ping robert_ancell
[03:12] <robert_ancell> duflu, hi
[03:12] <duflu> robert_ancell: Hi...
[03:13] <duflu> robert_ancell: I noticed on a couple of Ubuntu systems that if I set it up to use UEFI, there is a very long period of black screen between grub and plymouth. Is that right?
[03:13] <duflu> I'm seeing it consistently on all UEFI configs
[03:13] <duflu> In fact, most of the boot process is black screen. So that's very disconcerting
[03:14] <robert_ancell> duflu, I don't know enough about the early boot sequence to know why that would be
[03:15] <duflu> robert_ancell: OK, no problem. When I have time I will have to experiment further
[03:17] <desrt> robert_ancell: hey... i was testing out u-c-c today
[03:17] <desrt> nice work getting that into main already
[03:18] <robert_ancell> desrt, thanks. Landing the patches to other packages now, then hopefully the transition will be seamless
[03:18] <desrt> robert_ancell: ah.  good.
[03:18] <desrt> i noticed that dejadup is installing two panels now, but not some others (like indicator-datetime).  was wondering what your plans were there :)
[03:18] <robert_ancell> desrt, I've posted the patches upstream, I hope people are happy to take them
[03:18] <desrt> robert_ancell: i guess they'll need to take another patch again soon
[03:19] <desrt> since g-c-c is going to stop supporting 3rd party panels entirely once we drop our patchset
[03:19] <desrt> i almost wonder if it's worthwhile to do it in two steps...
[03:19] <desrt> or just change it straight over
[03:19] <robert_ancell> desrt, actually darkxst said he wanted to keep 3rd party panels
[03:19] <desrt> ah.  interesting.
[03:19] <desrt> well, there you go :)
[03:19] <robert_ancell> desrt, I'm doing it like this because I can't batch up all the changes and sync them into the archive
[03:20] <robert_ancell> then you'd have two control centers that weren't quite right :)
[03:20] <desrt> ya... sometimes i wish we could look the other way for a few days on small issues like this...
[03:20] <desrt> it's pre-alpha, after all...
[03:20] <robert_ancell> I almost did, but then I though it is an LTS and we are focussing on quality :)
[03:21] <desrt> it's not an LTS yet :)
[03:21] <robert_ancell> I'm not sure the right way to uninstall gnome-control-center at the end though. I hope update-manager has some sort of hook to try and apt-get autoremove it
[03:23] <desrt> if i've learnt anything it's this: it's possible to use the right combination of breaks: replaces: recommends: and conflicts: to accomplish anything at all
[03:23] <robert_ancell> desrt, then you just end up with a packaging mess that's unreadable for the next maintainer :(
[03:23] <robert_ancell> we have enough of those
[03:23] <desrt> robert_ancell: i'm told it's all very logical :)
[06:43] <pitti> Good morning
[06:46] <desrt> pitti: hi!!
[06:47] <pitti> hey desrt, how are you?
[06:47] <desrt> getting a bit tired, i guess
[09:02] <Laney> g'morning
[09:05] <seb128> hey Laney
[09:05] <seb128> good morning desktopers!
[09:19] <mlankhorst> Hello, world!\n
[09:49] <seb128> larsu, hey
[09:50] <seb128> larsu, you like gedit theming issues right? ;-)
[09:50]  * larsu runs
[09:51] <seb128> hum, in fact I wonder if I created that problem
[09:51]  * seb128 test
[09:51] <seb128> if you search for something which has a match
[09:51] <seb128> the "x of y results" has a grey background
[09:51] <seb128> which makes it difficult to read/not look nice
[09:52] <larsu> ya, I see that as well
[09:53] <seb128> larsu, I was wondering if that was due to https://code.launchpad.net/~seb128/ubuntu-themes/gedit-background-color/+merge/196310 but it seems not
[09:53] <larsu> that patch _is_ setting the background to theme_base, though
[09:53] <larsu> when it should be transparent
[09:54] <larsu> ah, that's the slider itself though
[09:54] <seb128> right
[09:54] <seb128> that doesn't impact it
[09:54] <seb128> I changed to error_bg_color to see
[09:54] <seb128> that impacts on the border around the entry
[09:56] <seb128> larsu, https://git.gnome.org/browse/gnome-themes-standard/tree/themes/Adwaita/gtk-3.0/gnome-applications.css#n245 ?
[09:56]  * seb128 tries that
[09:57] <seb128> ok, that makes the grey not goes over the border but doesn't fix the color issue
[09:57] <larsu> he, I just tried the same :)
[09:58] <larsu> I think the problem is that we're still setting a background color on every widget
[09:58] <larsu> if I unset it, I get the right behaviour
[09:58] <larsu> well, except that the text is white on white now
[09:59] <larsu> so I have a fix, but I don't like it.
[09:59] <larsu> it seems like we should be doing the right thing: https://code.launchpad.net/~larsu/ubuntu-themes/dont-set-all-bgs/+merge/197234
[10:00]  * larsu needs to test that patch again, though
[10:00] <seb128> larsu, that works
[10:00] <seb128> .gedit-search-entry-occurrences-tag {
[10:00] <seb128> 	background-color: @theme_bg_color;
[10:00] <seb128>     color: @selected_bg_color;
[10:01] <seb128> but yeah
[10:01] <seb128> we need to get Cimi to review the bgs change again
[10:06] <seb128> larsu, ok, I've applied your no bg changes again, I'm going to keep an eye for rendering issues
[10:07] <seb128> larsu, but yeah, with it the gedit "n on n" hints is not visible at all
[10:08] <larsu> seb128: right, because we need to set the foreground color as well
[10:08] <seb128> larsu, right,
[10:08] <larsu> seb128: do you want me to have a look into that or wait until Cimi acks the bg thing?
[10:09] <seb128> larsu, seems those are orthogonal
[10:09] <seb128> we need something around the line of
[10:09] <seb128>  .gedit-search-entry-occurrences-tag {
[10:09] <seb128>   background-color: @theme_bg_color;
[10:09] <seb128>      color: @selected_bg_color;
[10:09] <seb128>      }
[10:09] <larsu> no, background color must be set to transparent
[10:09] <seb128> well, that works nicely here
[10:09] <larsu> (or apply my no-bg patch)
[10:10] <larsu> but I'd be fine with merging that for now
[10:10]  * larsu cooks up a patch
[10:10] <seb128> well, we need at least the
[10:10] <seb128>      color: @selected_bg_color;
[10:10] <seb128> for the text
[10:10] <larsu> @selected_bg_color is a bad choice for the forground as well
[10:10] <meetingology> larsu: Error: "selected_bg_color" is not a valid command.
[10:10] <seb128> even with your patch
[10:10] <larsu>  @selected_bg_color is a bad choice for the forground as well
[10:10] <seb128> right?
[10:10] <seb128> what do you suggest?
[10:10] <larsu> yep
[10:10] <seb128> I sort of like the hint in orange
[10:10] <seb128> (just tried that)
[10:11] <larsu> I wonder why we don't have the @theme_unfocused_fg_color
[10:11] <larsu> that fits best semantically
[10:11] <larsu> I don't like the orange, it draws too much attention
[10:11] <seb128> well, just add it to gtk-main.css if needed
[10:12] <larsu> the problem with just adding it is that I wouldn't know which color it'd have to be
[10:12] <seb128> we should ask Cimi
[10:12] <seb128> Cimi, ^^
[10:13] <seb128> Cimi, can you help us with some theme question/issues?
[10:14] <seb128> Cimi, can you also review https://code.launchpad.net/~larsu/ubuntu-themes/dont-set-all-bgs/+merge/197234 again when you have some cycles?
[10:15] <seb128> larsu, I'm booting a raring image to see what color the hints had before :p
[10:16] <seb128> hum
[10:17] <seb128> raring didn't have the hint
[10:17] <larsu> hehe
[10:18] <larsu> seb128: I think @backdrop_text_color makes most sense
[10:18] <larsu> that's the color that entries and textviews get when they're in an unfocussed window
[10:18] <larsu> the text in them, of course
[10:19] <Cimi> seb128, ok
[10:19] <seb128> seems it's standard black?
[10:19] <larsu> no, a bit lighter
[10:19] <seb128> Cimi, hey, how are you?
[10:19] <seb128> Cimi, thanks ;-)
[10:19] <Cimi> seb128, in bed sick :)
[10:19] <seb128> :-(
[10:19] <larsu> Cimi: :( get better soon!
[10:19] <seb128> Cimi, take some rest and get better!
[10:20] <seb128> larsu, my non designer eyes don't see the difference :p
[10:20] <larsu> :D
[10:20] <Cimi> was sick monday, yesterday I went to the office for a meeting... sick again :)
[10:23] <seb128> Cimi, seems like a good time to do some easy theme reviews and fixes :p
[10:24]  * larsu has to run for a bit. Will be back in ~20 min
[10:25] <Laney> don't run too fast
[10:46] <larsu> lol
[10:58]  * Laney sees mlankhorst on a totem merge changelog
[10:58] <Laney> quelle surprise
[10:59] <mlankhorst> Laney: without love, untested, and directly to the archive. :p
[10:59] <Laney> directly instead of?
[10:59] <Laney> you didn't commit it to the VCS which is how I happened to notice it
[10:59] <mlankhorst> actually testing if it did more than build locally
[10:59] <Laney> uh
[10:59] <Laney> you're proud of that?
[10:59] <Laney> that's a default application ...
[11:00] <mlankhorst> hey I didn't upload it. :P
[11:02] <mlankhorst> besides after I heard it was uploaded without further testing I did test it, because I'd feel guilty if I broke video playing for everyone ;-)
[11:03] <Laney> mmm
[11:08] <mlankhorst> but it was easy to import the debian/ into an empty git tree, and then use git merge to resolve the conflicts
[11:30] <darkxst> seb128, hi
[11:35] <seb128> darkxst, hey
[11:44] <darkxst> seb128, so I have setup a ppa to test gnome-desktop 3.10 transition,
[11:45] <darkxst> the actualy daemon I made from mutter seems to be working well
[11:45] <darkxst> g-s-d took about half a dozen backported patches
[11:49] <darkxst>  ppa:darkxst/gnome-desktop
[11:49] <darkxst> one more patch I need to push for auto-starting d-bus service but right now lp keeps rejecting me ;(
[11:58] <seb128> darkxst, shrug, gnome-desktop transition ... how much do you want that one this cycle? We already have quite some transition ongoing and I don't like the sound of the half a dozen patches to add, nor the fact that it's quite some changes for a LTS cycles
[12:01] <darkxst> seb128, its really the last one
[12:02] <darkxst> and mostly just code moving around causing minor api changes
[12:02] <darkxst> I
[12:02] <darkxst>  also working with upsteam to break out gnome-desktop deps for apps
[12:03] <darkxst> but that won't happen for trusty
[12:03] <seb128> I wouldn't call the addition of a new dbus service to handle resolutions as "minor api change"
[12:05] <darkxst> seb128, outside of gnome-desktop its just minor changes
[12:06] <seb128> right
[12:06] <seb128> it's gnome-desktop that makes me nervous though :p
[12:06] <seb128> btw did you look at the issues with the nautilus update?
[12:07] <darkxst> seb128, not yet, running at limited capacity due to heat-wave here
[12:08] <darkxst> been 40+C everyday this week ;(
[12:08] <seb128> yeah, I saw that in the news
[12:08] <seb128> quite some heat :/
[12:09] <darkxst> yeh! painful heat
[12:16] <seb128> desrt, larsu: want to review https://code.launchpad.net/~mitya57/ubuntu-themes/headerbar-fixes/+merge/200477 ?
[12:18] <larsu> seb128: will do after I finish my lunch
[12:19] <seb128> larsu, enjoy lunch ;-)
[12:22] <pitti> seb128: do you have an opinion about https://code.launchpad.net/~noskcaj/ubuntu/trusty/libgweather/3.10.1/+merge/200210 ?
[12:22] <pitti> seb128: i. e. ok to update libgweather to 3.10, or should we stay at 3.8?
[12:22] <seb128> pitti, I don't know enough about it to have an opinion, I've a quick look, they did some provider changes it seems
[12:23] <pitti> it'll require an e-d-s, gnome-clocks, gnome-panel etc. rebuilds
[12:23] <seb128> pitti, I don't think we use it anywhere important so it should be fine to update
[12:23] <seb128> (e.g it's not going to create issues for ubuntu touch or unity)
[12:24] <pitti> seb128: ok; it'll stay in -proposed for a bit anyway until the transition is done
[12:24] <seb128> ok
[12:24] <pitti> seb128: but I wasn't sure whether we have a general "stay on 3.8" for trusty
[12:24] <seb128> pitti, don't bother rebuilding e-d-s, I plan to do the minor point update today
[12:24] <pitti> seb128: merci
[12:25] <seb128> pitti, no, the rule is "don't take on updates which have potential to create issues" (e.g new GNOME style UIs, refactoring that don't bring us anything useful for the LTS)
[12:25] <pitti> *nod*
[12:25]  * pitti ← too far away from desktop business these days :/
[12:25] <seb128> e.g just good common sense in a conservative cycle
[12:26]  * seb128 hugs pitti
[12:26]  * pitti te donne une accolade en retour
[12:26] <seb128> ;-)
[13:17] <larsu> mitya57: what happens when you include minimize and maximize in GtkWindow-decoration-button-layout?
[13:17] <larsu> you write on that MR that we'll need to revisit it, but can't we just include them now?
[13:17] <larsu> gtk's default is icon:minimize,maximize,close and it doesn't seem to hurt us right now
[13:36] <mitya57> larsu: minimize and maximize didn't work for me, no effect
[13:37] <mitya57> I think 3.10 only supports clos
[13:37] <mitya57> *close
[13:37] <larsu> mitya57: right. My point was that we could include them so that we don't have to look at that again once they work (since they're also included in gtk's default css)
[13:38] <mitya57> In 3.12 we'll need a completely different approach (via gsettings), see my comment
[13:38] <larsu> mitya57: also, it doesn't work for me. gnome-calculator's close button is still on the right
[13:38] <larsu> which version have you tested with
[13:39] <mitya57> I've built gnome-calculator from git, but that shouldn't matter
[13:39] <larsu> me too
[13:39] <larsu> jhbuild to be precise
[13:39] <larsu> I guess I shouldn't link it against gtk master`
[13:39] <larsu> I'll try that in a bit
[13:40] <mitya57> Right, of course it should be using 3.10
[13:40] <larsu> because 3.12 doesn't use that css property anymore?
[13:42] <seb128> GTK compatibility story between series is great isn't it? ;-)
[13:43] <larsu> ya
[13:44] <larsu> I do like that its development has picked up again, though
[13:44] <larsu> before, everyone was complaining that it moved to slowly and didn't have enough modern features
[13:44] <larsu> now it moves to fast...
[13:45] <larsu> seb128: let's do the search occurences fix locally for now. Who knows when cimi has time to review the no-bg thing. https://code.launchpad.net/~larsu/ubuntu-themes/gedit-search-occurences/+merge/201775
[13:47] <seb128> larsu, we need to land a change for the text color in any case, having an extra line to workaround the bg doesn't hurt
[13:48] <larsu> that was my thinking as well
[13:48] <larsu> and it won't break when we merge the other branch, because that sets all bgs to transparent
[13:48]  * seb128 waits for the launchpad diff to be generated
[13:48] <larsu> mitya57: cool. works. Thanks for the patch!°
[13:48] <seb128> right
[13:49] <larsu> mitya57: we won't need the transparent fixes after Cimi acks the no-bg branch
[13:49] <larsu> but same reasoning as with my patch just now: it won't hurt, so meh
[13:55] <mitya57> larsu: Ok, let's drop the transparency fix later (or drop it when merging)
[14:11] <seb128> larsu, just as a fyi, I'm SRUing https://code.launchpad.net/~larsu/notify-osd/update-sync/+merge/194364 to precise (ara emailed me about it saying you didn't get back to her)
[14:12] <seb128> I guess we just overlooked that with all the GTK crazyness and holidays
[14:15] <Laney> New d-conf at deb http://people.canonical.com/~laney/package-junkyard ./ if anyone wants to try it
[14:15] <seb128> Laney, waouh, you even did i386 builds (for me?) ;-)
[14:15] <larsu> seb128: ok :)
[14:15] <Laney> some people are stuck in the past :P
[14:15] <seb128> going to try that once I'm done with notify-osd
[14:16] <kenvandine> seb128, you got a smart phone... next it'll be time to switch to amd64 :-p
[14:16] <seb128> Laney, rly? coming from the guy using xmonad and gnome-panel? ;-)
[14:17] <seb128> kenvandine, lol
[14:17] <Laney> ahem
[14:18] <pitti> Laney: hm, glib 2.39.1??
[14:18] <Laney> haha
[14:18] <seb128> pitti, welcome to trusty
[14:18] <Laney> DON'T LOOK INSIDE THE REPOSITORY
[14:19] <Laney> OH GOD
[14:19] <seb128> lol
[14:19] <pitti> seb128: well, trusty has 2.39.2
[14:19] <pitti> oh, sorry, these are old packages
[14:19] <pitti> seb128: I meant in Laney's link above
[14:19] <Laney> yeah I should delete those
[14:19] <seb128> pitti, oh, ok, ignore me then ;-)
[14:19] <seb128> one day Laney will discover ppas
[14:19] <seb128> :p
[14:20] <pitti> Laney: do you need testing for those?
[14:20] <Laney> pitti: for dconf
[14:20] <seb128> (I should stop trolling...)
[14:20] <Laney> I'll do glib after lunch
[14:20] <Laney> haha
[14:21] <Laney> It took me about 1 minute to build and upload that package
[14:21] <Laney> try doing that with a PPA
[14:21] <seb128> well, it takes one minutes less for you to build
[14:21] <seb128> it just takes 12 hours more waiting for launchpad to do it :p
[14:22] <pitti> ok, installed; rebooting anyway as I want to test new xkeyboard-config
[14:22] <Laney> good luck
[14:25] <seb128> Laney, seems to work fine for me (didn't restart my session but I did restart the service and tried the editor/setting some keys)
[14:26] <Laney> neat
[14:26] <Laney> not sure if I should upload things after didrocks' email
[14:26] <Laney> will look again after lunch if pitti didn't catch on fire
[14:27] <pitti> Laney: seems quite alright after a reboot (reading); I didn't try changing my config
[14:27] <pitti> although dconf-service is running, i. e. we still write config at boot
[14:29] <seb128> pitti, don't angry desrt like that
[14:30] <seb128> what was the kernel flag to enable dconf blame again?
[14:32] <desrt> >:|
[14:33] <Laney> DCONF_BLAME
[14:34] <desrt> DCONF_ASSERT_IF_STARTED_TOO_SOON
[14:34] <seb128> I just put that on the grub kernel option?
[14:34] <desrt> new option, enabled by default
[14:34] <desrt> and when i say 'option' i mean mandatory, of course
[14:34] <seb128> lol
[14:35]  * seb128 googles for "dconf blame", 3 results is "http://aseigo.blogspot.fr/2005/04/stupidity-of-dconf.html"
[14:35] <ogra_> heh
[14:35] <ogra_> usual suspects ?
[14:36] <desrt> i like aseigo
[14:36] <desrt> he's a really nice guy
[14:36] <seb128> hehe
[14:36] <desrt> always says reasonable things
[14:37] <desrt> never overtly racist or sexist or unreasonable in any way
[14:43] <mlankhorst> whew
[14:44] <seb128> desrt, where is dconf_blame outputing?
[14:46] <desrt> seb128: run the 'dconf blame' command from the commandline
[14:46] <desrt> it will contact the service to fetch the log
[14:48] <seb128> desrt, thanks
[14:48] <seb128> http://paste.ubuntu.com/6756502/
[14:48] <seb128> indicator-sound
[14:48] <seb128> larsu, hide from desrt :p
[14:48] <desrt> larsu: hey.  how are things?
[14:48] <desrt> i hear you're writing to dconf on startup
[14:48] <desrt> let's talk.... out back for uh.... privacy
[14:49]  * larsu would never do such a thing!
[14:50] <desrt> i should check the monotonic time and if it's <~20s automatically blame
[14:50] <desrt> since it's probably unlikely that the user changes a setting within 20s of machine boot
[14:50] <larsu> that's very arbitrary
[14:51] <desrt> ya.... that's why i don't like it, which is ultimately why i won't do it
[14:51] <larsu> and probably fails in many cases
[14:51] <desrt> but requiring a reboot is kind annoying too
[14:51] <larsu> what exactly is blame doing?
[14:52] <desrt> it logs all requests that the service processes along with the output of 'ps f' at the time of the request
[14:52] <larsu> the man page doesn't even mention it :-/
[14:52] <desrt> so you can find out who is responsible
[14:52] <desrt> larsu: it's a bit of an easter-egg feature
[14:52] <larsu> and it does so indefintely?
[14:52] <desrt> yes
[14:52] <desrt> you have to enable it with a kernel commandline argument...
[14:52] <larsu> right
[14:53] <larsu> what's in "parameters", the params to the dbus call?
[14:53] <desrt> junk
[14:53] <desrt> i should fix that
[14:53] <desrt> it used to show what the call was
[14:53] <larsu> so it won't contain useful information to me?
[14:53] <desrt> but then i switched to sending the change request as a gvariant blob
[14:53]  * larsu wonders why sound would write on startup
[14:53] <desrt> to avoid hacks to deal with things like () and 'm' that dbus rejects
[14:54] <larsu> ah, right
[14:54] <larsu> but I can't find out from this which key is affected?
[14:54] <desrt> you can
[14:54] <desrt> but you have to deserialise it :)
[14:54] <desrt> gimme a sec
[14:55] <seb128> larsu, btw no need to reboot, you can add DCONF_BLAME=1 in /etc/environment and start e.g a guest session
[14:56] <larsu> seb128: ah cool thanks
[14:56] <larsu> desrt: I need g_variant_new_from_python_data_structure!
[14:57] <seb128> well, guest session is probably not the best one
[14:57] <desrt> >>> GLib.Variant.new_from_bytes(GLib.VariantType.new('a{smv}'), GLib.Bytes.new([0x2f, 0x63, 0x6f, 0x6d, 0x2f, 0x63, 0x61, 0x6e, 0x6f, 0x6e, 0x69, 0x63, 0x61, 0x6c, 0x2f, 0x69, 0x6e, 0x64, 0x69, 0x63, 0x61, 0x74, 0x6f, 0x72, 0x2f, 0x73, 0x6f, 0x75, 0x6e, 0x64, 0x2f, 0x69, 0x6e, 0x74, 0x65, 0x72, 0x65, 0x73, 0x74, 0x65, 0x64, 0x2d, 0x6d, 0x65, 0x64, 0x69, 0x61, 0x2d, 0x70, 0x6c, 0x61, 0x79, 0x65, 0x72, 0x73, 0x00, 0x74, 0x6f, 0x74, 0x65, 0x6d, 0x2e, 0x
[14:57] <desrt> GLib.Variant('a{smv}', {'/com/canonical/indicator/sound/interested-media-players': <['totem.desktop']>})
[14:57] <seb128> I get a log long there
[14:57] <seb128> long
[14:57] <seb128> it's first login and some stuff like migrations and compiz profile init happen
[14:59] <larsu> desrt: thanks! It only writes to this key when an app contacts it...
[15:00] <larsu> at least, it should
[15:00] <desrt> larsu: no.
[15:00] <larsu> no?!
[15:00] <seb128> I didn't start totem for ages
[15:00] <desrt> you only write to gsettings in response to user interaction
[15:00] <desrt> not some app contacting you on an API
[15:00] <larsu> "please remove a feature because this is not how I designed this library"
[15:01] <desrt> "because you're slowing down login"
[15:01] <seb128> larsu, I didn't start any player in that session, so there is probably a bug
[15:01] <larsu> desrt: user interaction in this case is "user starts totem"
[15:01] <larsu> well, it might simply be a bug
[15:01] <larsu> seb128: right
[15:02] <seb128> larsu, it's followed by
[15:02] <seb128> GLib.Variant('a{smv}', {'/com/canonical/indicator/sound/interested-media-players': <['totem.desktop', 'rhythmbox.desktop']>})
[15:02]  * desrt is glad he shared the recipe :)
[15:03]  * desrt guesses that a gobject 'notify' signal is involved here somehow
[15:03] <larsu> bah!
[15:03] <larsu> desrt: no... but a signal
[15:04] <seb128> hum
[15:04] <seb128> next one is g-s-d
[15:04] <seb128> GLib.Variant('a{smv}', {'/org/gnome/desktop/interface/enable-animations': <true>})
[15:04] <seb128> I guess that's an upstream bug
[15:04] <desrt> ya
[15:04] <desrt> i think that's already fixed
[15:04] <desrt> https://bugzilla.gnome.org/show_bug.cgi?id=694692
[15:04] <ubot2> Gnome bug 694692 in plugins "disable animations shouldn't be toggled with gsettings" [Normal,Resolved: fixed]
[15:05] <larsu> desrt: it's the typical round trip: read from a key into a collection which notifies that it has changed...
[15:05] <desrt> larsu: oops.
[15:05] <larsu> which writes back the key
[15:05] <larsu> who wrote this shit and what was I thinking!
[15:05] <desrt> if you're using bindings then it should protect against that...
[15:05] <larsu> it's even in a separate commit :/
[15:05] <larsu> desrt: it's not a property
[15:05] <seb128> larsu, want a bug report about it?
[15:05] <desrt> larsu: ought to be :)
[15:06] <desrt> anything that changes and has a getter is prime property-making material
[15:06] <larsu> desrt: it will be if you make having a list of things as a property simple
[15:06] <larsu> seb128: nah, I'm on it already
[15:06] <seb128> larsu, thanks ;-)
[15:06] <larsu> unless it's easier for you to track later on
[15:06] <desrt> larsu: ah... not a strv, then
[15:06] <desrt> but rather a glist of objects?
[15:06] <larsu> ya, it's a pain
[15:06] <larsu> esp from vala
[15:07] <desrt> vala would make that easier, i think?
[15:07] <larsu> how does the binding stuff protect against that btw?
[15:07] <desrt> when it's changing the property it sets a flag and ignores property change notifications during that time
[15:08] <larsu> there's a race if you check against the previous value, no
[15:08] <larsu> ah, that makes sense
[15:08] <desrt> it's kinda ugly, but surprisingly effective
[15:08] <larsu> ya
[15:08] <larsu> and probably the only way?!
[15:08] <desrt> you could do the compare
[15:08] <desrt> but i consider it evil
[15:08] <desrt> after all, people only write to settings on user interaction, right?
[15:09] <desrt> also: until last cycle it was not strictly possible to do the compare
[15:09] <seb128> ok, so the login list is small, it's indicator-sound*2, compiz*2 (settings the active-profile to "default" then "unity") and g-s-d for the enable-animation key
[15:09] <desrt> because the value that you read may have been the default value and the user may have wanted to _explicitly_ set the key in their own database
[15:09] <seb128> then in my log is gedit that I ran manually, which writes a bunch of keys on start
[15:09] <desrt> with the get_user_value() stuff of last cycle, a compare is more viable without breaking semantics
[15:09] <seb128> e.g
[15:09] <seb128> GLib.Variant('a{smv}', {'/org/gnome/gedit/preferences/ui/notebook-show-tabs-mode': <'always'>})
[15:10] <desrt> seb128: let me see if the new gedit has this problem
[15:10] <desrt> because i love nagging those guys lately :)
[15:10] <seb128> ;-)
[15:10] <larsu> desrt: you still have a race when the user interacts quickly...
[15:11] <desrt> bah... i erased my jhbuild to make room for a git checkout of webkit
[15:11] <desrt> ...and i don't feel like rebuilding it
[15:11] <desrt> larsu: not really......
[15:11] <desrt> if the user submits a request that says "i want the key to have value 'X' now"
[15:11] <desrt> and i see that it already has value X...
[15:11] <desrt> request over...
[15:12] <desrt> there's another case that i already do this for, in fact: if an in-flight change is the same as the one just requested
[15:12] <desrt> i just drop the new one
[15:13] <desrt> er... not in-flight sorry... pending
[15:13] <desrt> (dconf's request management system is a bit complicated)
[15:13] <larsu> this is in dconf though, I was talking about in the app
[15:13] <desrt> same deal there, no?
[15:13] <desrt> the only thing you would have to worry about contending with is other people setting the key at the same time
[15:13] <desrt> and you'd have to worry about that anyway -- if their request came second then you'd lose your desired value anyway
[15:13] <larsu> which we don't have to worry about??
[15:14] <larsu> it's not about the desired value, it's when you read the value and then make a decision whether to write the new one based on that
[15:14]  * desrt appears confused
[15:15]  * larsu fixes the bug instead and lets desrt do the thinking about dconf races
[15:15] <desrt> i understand what you're saying... but i'm saying that the only situation in which this approach would present a problem for you is one in which you already have the problem anyway
[15:15] <desrt> which is that a second process may be writing at the same time
[15:16] <desrt> you can still lose, even if you always explicitly queue your write
[15:16] <larsu> but that's allowed, no?
[15:16] <desrt> the other guy's write just needs to come after
[15:16] <desrt> yes.  it's allowed.
[15:16] <desrt> but you're already losing
[15:16] <desrt> with or without the equal-value check
[15:16] <desrt> it makes absolutely no difference...
[15:16] <larsu> hm, makes sense
[15:41] <ochosi> larsu: ping
[15:41] <larsu> ochosi: hey
[15:42] <ochosi> larsu: hi there :) i quickly wanted to ask you about indicator merge-requests
[15:42] <larsu> go ahead :)
[15:42] <ochosi> i submitted a merge-request a while ago (quite simple) to add support for xfce4-powermanager to indicator-power
[15:42] <ochosi> i just saw that robert_ancell proposed this branch: https://code.launchpad.net/~robert-ancell/indicator-power/unity-control-center2
[15:43] <ochosi> i presume that is *very* likely to get merged
[15:43] <larsu> and yours didn't get merged?
[15:43] <ochosi> at least not yet: https://code.launchpad.net/~ochosi/indicator-power/xfce4-powermanager-settings
[15:44] <ochosi> they're overlapping functionally, though the code-style isn't the same
[15:44] <ochosi> i guess after merging robert's branch, my patch would become a 2-liner or so
[15:45] <ochosi> the main difference is that i added checking for the running session
[15:46] <ochosi> (same code is already used in indicator-sound btw)
[15:46] <larsu> ochosi: right. Sorry that we didn't approve that earlier. Since robert's seems to be on the way in, do you mind rebasing yours once it landed?
[15:46] <larsu> feel free to ping me to approve it then
[15:46] <ochosi> no, i can totally do that
[15:46] <ochosi> no worries
[15:47] <ochosi> thanks larsu
[15:49] <larsu> ochosi: ya, no problem :)
[15:50] <larsu> seb128: want to give this a whirl? https://code.launchpad.net/~larsu/indicator-sound/dont-write-settings-on-startup/+merge/201804
[16:12] <filosofixit> Suddenly all the menu items in the context menus are greyed out. A restart does not help. Anyone know a solution?
[16:15] <filosofixit> awfully quiet here.. :/
[16:18] <mitya57> filosofixit: see the topic ("For support please join #ubuntu" part)
[16:21] <filosofixit> mitya : my bad , sorry :/
[16:37] <seb128> larsu, I was out for some errands, sure I can give that a try ;-)
[16:41] <larsu> seb128: no worries, it's not urgent (but don't tell desrt ;) )
[16:41] <seb128> larsu, ;-)
[17:03]  * Laney blurgs in webkit land
[17:04] <seb128> Laney, good luck!
[17:04] <Laney> 2 days to build on arm64/qemu :(
[17:08] <desrt> ...something is not quite right there
[17:09] <desrt> webkit just massively pushes every reasonable metric of what it is to be a project
[17:09] <desrt> its git repository is 5GB and takes longer to unpack than it does to download (which is still quite long)
[17:09] <desrt> it takes 10GB to build it without debugging on freebsd
[17:09] <desrt> ...and a good deal of time
[17:10] <desrt> just madness
[17:11] <larsu> desrt: the web is a "platform" now. I don't think any other platform is in a single git repo...
[17:11] <Laney> I remember having to patch make to deal with the number of files it was specifying
[17:11] <Laney> that was great
[17:12] <larsu> imagine all of gnome in one git repo
[17:12] <desrt> larsu: until webkit starts shipping its own drivers and bootloader....
[17:12] <larsu> desrt: I didn't say operating system and put plaform in quotes so that you couldn't make that point. sigh.
[17:14] <Laney> I guess libreoffice has a lot of the same problems
[17:16] <desrt> larsu: i'd argue that firefox is more complete in every way
[17:16] <desrt> and although it's big, it's not webkit-epic-level
[17:16] <larsu> fair enough. What is webkit doing wrong then?
[17:17] <desrt> probably has a lot to do with the dialect of c++ that they speak
[18:37]  * didrocks waves good evening
[21:11] <ChrisTownsend> attente: Thanks for that Compiz fix!
[21:11] <attente> ChrisTownsend, thanks for approving :)
[21:12] <ChrisTownsend> attente: My pleasure
[22:02] <attente> ChrisTownsend, hmm. the tests pass, but the c-i is still failing :/
[22:04] <ChrisTownsend> attente: Looks like it could be some Jenkins issue.  I'll try pinging someone in a bit.
[22:05] <attente> ChrisTownsend, ok, thanks :)