=== duflu_ is now known as duflu [03:12] ping robert_ancell [03:12] duflu, hi [03:12] robert_ancell: Hi... [03:13] 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] I'm seeing it consistently on all UEFI configs [03:13] In fact, most of the boot process is black screen. So that's very disconcerting [03:14] duflu, I don't know enough about the early boot sequence to know why that would be [03:15] robert_ancell: OK, no problem. When I have time I will have to experiment further [03:17] robert_ancell: hey... i was testing out u-c-c today [03:17] nice work getting that into main already [03:18] desrt, thanks. Landing the patches to other packages now, then hopefully the transition will be seamless [03:18] robert_ancell: ah. good. [03:18] 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] desrt, I've posted the patches upstream, I hope people are happy to take them [03:18] robert_ancell: i guess they'll need to take another patch again soon [03:19] since g-c-c is going to stop supporting 3rd party panels entirely once we drop our patchset [03:19] i almost wonder if it's worthwhile to do it in two steps... [03:19] or just change it straight over [03:19] desrt, actually darkxst said he wanted to keep 3rd party panels [03:19] ah. interesting. [03:19] well, there you go :) [03:19] desrt, I'm doing it like this because I can't batch up all the changes and sync them into the archive [03:20] then you'd have two control centers that weren't quite right :) [03:20] ya... sometimes i wish we could look the other way for a few days on small issues like this... [03:20] it's pre-alpha, after all... [03:20] I almost did, but then I though it is an LTS and we are focussing on quality :) [03:21] it's not an LTS yet :) [03:21] 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] 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] desrt, then you just end up with a packaging mess that's unreadable for the next maintainer :( [03:23] we have enough of those [03:23] robert_ancell: i'm told it's all very logical :) [06:43] Good morning [06:46] pitti: hi!! [06:47] hey desrt, how are you? [06:47] getting a bit tired, i guess [09:02] g'morning [09:05] hey Laney [09:05] good morning desktopers! [09:19] Hello, world!\n [09:49] larsu, hey [09:50] larsu, you like gedit theming issues right? ;-) [09:50] * larsu runs [09:51] hum, in fact I wonder if I created that problem [09:51] * seb128 test [09:51] if you search for something which has a match [09:51] the "x of y results" has a grey background [09:51] which makes it difficult to read/not look nice [09:52] ya, I see that as well [09:53] 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] that patch _is_ setting the background to theme_base, though [09:53] when it should be transparent [09:54] ah, that's the slider itself though [09:54] right [09:54] that doesn't impact it [09:54] I changed to error_bg_color to see [09:54] that impacts on the border around the entry [09:56] 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] ok, that makes the grey not goes over the border but doesn't fix the color issue [09:57] he, I just tried the same :) [09:58] I think the problem is that we're still setting a background color on every widget [09:58] if I unset it, I get the right behaviour [09:58] well, except that the text is white on white now [09:59] so I have a fix, but I don't like it. [09:59] 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] larsu, that works [10:00] .gedit-search-entry-occurrences-tag { [10:00] background-color: @theme_bg_color; [10:00] color: @selected_bg_color; [10:01] but yeah [10:01] we need to get Cimi to review the bgs change again [10:06] larsu, ok, I've applied your no bg changes again, I'm going to keep an eye for rendering issues [10:07] larsu, but yeah, with it the gedit "n on n" hints is not visible at all [10:08] seb128: right, because we need to set the foreground color as well [10:08] larsu, right, [10:08] seb128: do you want me to have a look into that or wait until Cimi acks the bg thing? [10:09] larsu, seems those are orthogonal [10:09] we need something around the line of [10:09] .gedit-search-entry-occurrences-tag { [10:09] background-color: @theme_bg_color; [10:09] color: @selected_bg_color; [10:09] } [10:09] no, background color must be set to transparent [10:09] well, that works nicely here [10:09] (or apply my no-bg patch) [10:10] but I'd be fine with merging that for now [10:10] * larsu cooks up a patch [10:10] well, we need at least the [10:10] color: @selected_bg_color; [10:10] for the text [10:10] @selected_bg_color is a bad choice for the forground as well [10:10] larsu: Error: "selected_bg_color" is not a valid command. [10:10] even with your patch [10:10] @selected_bg_color is a bad choice for the forground as well [10:10] right? [10:10] what do you suggest? [10:10] yep [10:10] I sort of like the hint in orange [10:10] (just tried that) [10:11] I wonder why we don't have the @theme_unfocused_fg_color [10:11] that fits best semantically [10:11] I don't like the orange, it draws too much attention [10:11] well, just add it to gtk-main.css if needed [10:12] the problem with just adding it is that I wouldn't know which color it'd have to be [10:12] we should ask Cimi [10:12] Cimi, ^^ [10:13] Cimi, can you help us with some theme question/issues? [10:14] 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] larsu, I'm booting a raring image to see what color the hints had before :p [10:16] hum [10:17] raring didn't have the hint [10:17] hehe === tsdgeos_ is now known as tsdgeos [10:18] seb128: I think @backdrop_text_color makes most sense [10:18] that's the color that entries and textviews get when they're in an unfocussed window [10:18] the text in them, of course [10:19] seb128, ok [10:19] seems it's standard black? [10:19] no, a bit lighter [10:19] Cimi, hey, how are you? [10:19] Cimi, thanks ;-) [10:19] seb128, in bed sick :) [10:19] :-( [10:19] Cimi: :( get better soon! [10:19] Cimi, take some rest and get better! [10:20] larsu, my non designer eyes don't see the difference :p [10:20] :D [10:20] was sick monday, yesterday I went to the office for a meeting... sick again :) [10:23] Cimi, seems like a good time to do some easy theme reviews and fixes :p === tkamppeter_ is now known as tkamppeter [10:24] * larsu has to run for a bit. Will be back in ~20 min [10:25] don't run too fast [10:46] lol [10:58] * Laney sees mlankhorst on a totem merge changelog [10:58] quelle surprise [10:59] Laney: without love, untested, and directly to the archive. :p [10:59] directly instead of? [10:59] you didn't commit it to the VCS which is how I happened to notice it [10:59] actually testing if it did more than build locally [10:59] uh [10:59] you're proud of that? [10:59] that's a default application ... [11:00] hey I didn't upload it. :P [11:02] 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] mmm [11:08] but it was easy to import the debian/ into an empty git tree, and then use git merge to resolve the conflicts [11:30] seb128, hi [11:35] darkxst, hey [11:44] seb128, so I have setup a ppa to test gnome-desktop 3.10 transition, [11:45] the actualy daemon I made from mutter seems to be working well [11:45] g-s-d took about half a dozen backported patches [11:49] ppa:darkxst/gnome-desktop [11:49] one more patch I need to push for auto-starting d-bus service but right now lp keeps rejecting me ;( === MacSlow is now known as MacSlow|lunch === alan_g is now known as alan_g|afk [11:58] 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] seb128, its really the last one [12:02] and mostly just code moving around causing minor api changes [12:02] I [12:02] also working with upsteam to break out gnome-desktop deps for apps [12:03] but that won't happen for trusty [12:03] I wouldn't call the addition of a new dbus service to handle resolutions as "minor api change" [12:05] seb128, outside of gnome-desktop its just minor changes [12:06] right [12:06] it's gnome-desktop that makes me nervous though :p [12:06] btw did you look at the issues with the nautilus update? [12:07] seb128, not yet, running at limited capacity due to heat-wave here === alan_g|afk is now known as alan_g [12:08] been 40+C everyday this week ;( [12:08] yeah, I saw that in the news [12:08] quite some heat :/ [12:09] yeh! painful heat [12:16] desrt, larsu: want to review https://code.launchpad.net/~mitya57/ubuntu-themes/headerbar-fixes/+merge/200477 ? [12:18] seb128: will do after I finish my lunch [12:19] larsu, enjoy lunch ;-) [12:22] seb128: do you have an opinion about https://code.launchpad.net/~noskcaj/ubuntu/trusty/libgweather/3.10.1/+merge/200210 ? [12:22] seb128: i. e. ok to update libgweather to 3.10, or should we stay at 3.8? [12:22] 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] it'll require an e-d-s, gnome-clocks, gnome-panel etc. rebuilds [12:23] pitti, I don't think we use it anywhere important so it should be fine to update [12:23] (e.g it's not going to create issues for ubuntu touch or unity) [12:24] seb128: ok; it'll stay in -proposed for a bit anyway until the transition is done [12:24] ok [12:24] seb128: but I wasn't sure whether we have a general "stay on 3.8" for trusty [12:24] pitti, don't bother rebuilding e-d-s, I plan to do the minor point update today [12:24] seb128: merci [12:25] 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] *nod* [12:25] * pitti ← too far away from desktop business these days :/ [12:25] 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] ;-) === alan_g is now known as alan_g|lunch === MacSlow|lunch is now known as MacSlow [13:17] mitya57: what happens when you include minimize and maximize in GtkWindow-decoration-button-layout? [13:17] you write on that MR that we'll need to revisit it, but can't we just include them now? [13:17] gtk's default is icon:minimize,maximize,close and it doesn't seem to hurt us right now === alan_g|lunch is now known as alan_g [13:36] larsu: minimize and maximize didn't work for me, no effect [13:37] I think 3.10 only supports clos [13:37] *close [13:37] 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] In 3.12 we'll need a completely different approach (via gsettings), see my comment [13:38] mitya57: also, it doesn't work for me. gnome-calculator's close button is still on the right [13:38] which version have you tested with [13:39] I've built gnome-calculator from git, but that shouldn't matter [13:39] me too [13:39] jhbuild to be precise [13:39] I guess I shouldn't link it against gtk master` [13:39] I'll try that in a bit [13:40] Right, of course it should be using 3.10 [13:40] because 3.12 doesn't use that css property anymore? [13:42] GTK compatibility story between series is great isn't it? ;-) [13:43] ya [13:44] I do like that its development has picked up again, though [13:44] before, everyone was complaining that it moved to slowly and didn't have enough modern features [13:44] now it moves to fast... [13:45] 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] 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] that was my thinking as well [13:48] 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] mitya57: cool. works. Thanks for the patch!° [13:48] right [13:49] mitya57: we won't need the transparent fixes after Cimi acks the no-bg branch [13:49] but same reasoning as with my patch just now: it won't hurt, so meh [13:55] larsu: Ok, let's drop the transparency fix later (or drop it when merging) [14:11] 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] I guess we just overlooked that with all the GTK crazyness and holidays [14:15] New d-conf at deb http://people.canonical.com/~laney/package-junkyard ./ if anyone wants to try it [14:15] Laney, waouh, you even did i386 builds (for me?) ;-) [14:15] seb128: ok :) [14:15] some people are stuck in the past :P [14:15] going to try that once I'm done with notify-osd [14:16] seb128, you got a smart phone... next it'll be time to switch to amd64 :-p [14:16] Laney, rly? coming from the guy using xmonad and gnome-panel? ;-) [14:17] kenvandine, lol [14:17] ahem [14:18] Laney: hm, glib 2.39.1?? [14:18] haha [14:18] pitti, welcome to trusty [14:18] DON'T LOOK INSIDE THE REPOSITORY [14:19] OH GOD [14:19] lol [14:19] seb128: well, trusty has 2.39.2 [14:19] oh, sorry, these are old packages [14:19] seb128: I meant in Laney's link above [14:19] yeah I should delete those [14:19] pitti, oh, ok, ignore me then ;-) [14:19] one day Laney will discover ppas [14:19] :p [14:20] Laney: do you need testing for those? [14:20] pitti: for dconf [14:20] (I should stop trolling...) [14:20] I'll do glib after lunch [14:20] haha [14:21] It took me about 1 minute to build and upload that package [14:21] try doing that with a PPA [14:21] well, it takes one minutes less for you to build [14:21] it just takes 12 hours more waiting for launchpad to do it :p [14:22] ok, installed; rebooting anyway as I want to test new xkeyboard-config [14:22] good luck [14:25] 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] neat [14:26] not sure if I should upload things after didrocks' email [14:26] will look again after lunch if pitti didn't catch on fire [14:27] Laney: seems quite alright after a reboot (reading); I didn't try changing my config [14:27] although dconf-service is running, i. e. we still write config at boot [14:29] pitti, don't angry desrt like that [14:30] what was the kernel flag to enable dconf blame again? [14:32] >:| [14:33] DCONF_BLAME [14:34] DCONF_ASSERT_IF_STARTED_TOO_SOON [14:34] I just put that on the grub kernel option? [14:34] new option, enabled by default [14:34] and when i say 'option' i mean mandatory, of course [14:34] lol [14:35] * seb128 googles for "dconf blame", 3 results is "http://aseigo.blogspot.fr/2005/04/stupidity-of-dconf.html" [14:35] heh [14:35] usual suspects ? [14:36] i like aseigo [14:36] he's a really nice guy [14:36] hehe [14:36] always says reasonable things [14:37] never overtly racist or sexist or unreasonable in any way [14:43] whew [14:44] desrt, where is dconf_blame outputing? [14:46] seb128: run the 'dconf blame' command from the commandline [14:46] it will contact the service to fetch the log [14:48] desrt, thanks [14:48] http://paste.ubuntu.com/6756502/ [14:48] indicator-sound [14:48] larsu, hide from desrt :p [14:48] larsu: hey. how are things? [14:48] i hear you're writing to dconf on startup [14:48] let's talk.... out back for uh.... privacy [14:49] * larsu would never do such a thing! [14:50] i should check the monotonic time and if it's <~20s automatically blame [14:50] since it's probably unlikely that the user changes a setting within 20s of machine boot [14:50] that's very arbitrary [14:51] ya.... that's why i don't like it, which is ultimately why i won't do it [14:51] and probably fails in many cases [14:51] but requiring a reboot is kind annoying too [14:51] what exactly is blame doing? [14:52] it logs all requests that the service processes along with the output of 'ps f' at the time of the request [14:52] the man page doesn't even mention it :-/ [14:52] so you can find out who is responsible [14:52] larsu: it's a bit of an easter-egg feature [14:52] and it does so indefintely? [14:52] yes [14:52] you have to enable it with a kernel commandline argument... [14:52] right [14:53] what's in "parameters", the params to the dbus call? [14:53] junk [14:53] i should fix that [14:53] it used to show what the call was [14:53] so it won't contain useful information to me? [14:53] 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] to avoid hacks to deal with things like () and 'm' that dbus rejects [14:54] ah, right [14:54] but I can't find out from this which key is affected? [14:54] you can [14:54] but you have to deserialise it :) [14:54] gimme a sec [14:55] larsu, btw no need to reboot, you can add DCONF_BLAME=1 in /etc/environment and start e.g a guest session [14:56] seb128: ah cool thanks [14:56] desrt: I need g_variant_new_from_python_data_structure! [14:57] well, guest session is probably not the best one [14:57] >>> 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] GLib.Variant('a{smv}', {'/com/canonical/indicator/sound/interested-media-players': <['totem.desktop']>}) [14:57] I get a log long there [14:57] long [14:57] it's first login and some stuff like migrations and compiz profile init happen [14:59] desrt: thanks! It only writes to this key when an app contacts it... [15:00] at least, it should [15:00] larsu: no. [15:00] no?! [15:00] I didn't start totem for ages [15:00] you only write to gsettings in response to user interaction [15:00] not some app contacting you on an API [15:00] "please remove a feature because this is not how I designed this library" [15:01] "because you're slowing down login" [15:01] larsu, I didn't start any player in that session, so there is probably a bug [15:01] desrt: user interaction in this case is "user starts totem" [15:01] well, it might simply be a bug [15:01] seb128: right [15:02] larsu, it's followed by [15:02] 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] bah! [15:03] desrt: no... but a signal [15:04] hum [15:04] next one is g-s-d [15:04] GLib.Variant('a{smv}', {'/org/gnome/desktop/interface/enable-animations': }) [15:04] I guess that's an upstream bug [15:04] ya [15:04] i think that's already fixed [15:04] https://bugzilla.gnome.org/show_bug.cgi?id=694692 [15:04] Gnome bug 694692 in plugins "disable animations shouldn't be toggled with gsettings" [Normal,Resolved: fixed] [15:05] desrt: it's the typical round trip: read from a key into a collection which notifies that it has changed... [15:05] larsu: oops. [15:05] which writes back the key [15:05] who wrote this shit and what was I thinking! [15:05] if you're using bindings then it should protect against that... [15:05] it's even in a separate commit :/ [15:05] desrt: it's not a property [15:05] larsu, want a bug report about it? [15:05] larsu: ought to be :) [15:06] anything that changes and has a getter is prime property-making material [15:06] desrt: it will be if you make having a list of things as a property simple [15:06] seb128: nah, I'm on it already [15:06] larsu, thanks ;-) [15:06] unless it's easier for you to track later on [15:06] larsu: ah... not a strv, then [15:06] but rather a glist of objects? [15:06] ya, it's a pain [15:06] esp from vala [15:07] vala would make that easier, i think? [15:07] how does the binding stuff protect against that btw? [15:07] when it's changing the property it sets a flag and ignores property change notifications during that time [15:08] there's a race if you check against the previous value, no [15:08] ah, that makes sense [15:08] it's kinda ugly, but surprisingly effective [15:08] ya [15:08] and probably the only way?! [15:08] you could do the compare [15:08] but i consider it evil [15:08] after all, people only write to settings on user interaction, right? [15:09] also: until last cycle it was not strictly possible to do the compare [15:09] 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] 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] then in my log is gedit that I ran manually, which writes a bunch of keys on start [15:09] with the get_user_value() stuff of last cycle, a compare is more viable without breaking semantics [15:09] e.g [15:09] GLib.Variant('a{smv}', {'/org/gnome/gedit/preferences/ui/notebook-show-tabs-mode': <'always'>}) [15:10] seb128: let me see if the new gedit has this problem [15:10] because i love nagging those guys lately :) [15:10] ;-) [15:10] desrt: you still have a race when the user interacts quickly... [15:11] bah... i erased my jhbuild to make room for a git checkout of webkit [15:11] ...and i don't feel like rebuilding it [15:11] larsu: not really...... [15:11] if the user submits a request that says "i want the key to have value 'X' now" [15:11] and i see that it already has value X... [15:11] request over... [15:12] 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] i just drop the new one [15:13] er... not in-flight sorry... pending [15:13] (dconf's request management system is a bit complicated) [15:13] this is in dconf though, I was talking about in the app [15:13] same deal there, no? [15:13] the only thing you would have to worry about contending with is other people setting the key at the same time [15:13] and you'd have to worry about that anyway -- if their request came second then you'd lose your desired value anyway [15:13] which we don't have to worry about?? [15:14] 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] 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] which is that a second process may be writing at the same time [15:16] you can still lose, even if you always explicitly queue your write [15:16]