[00:25] <Trevinho> mdeslaur: I've used another approach here https://code.launchpad.net/~3v1n0/unity/lockscreen-keys-disable/+merge/217528
[00:34] <sarnold> Trevinho: that looks to me like it modifies some of the code you added recently to ensure it re-starts locked if it dies while locked -- does it still lock in that case?
[00:34] <Trevinho> sarnold: sure
[00:35] <Trevinho> sarnold: it just gets called in another cb function
[00:35] <Trevinho> sarnold: I could keep the old one, but duplicating the callbacks wasn't the nicest thing
[00:35] <sarnold> Trevinho: excellent :) thanks for reassuring me :)
[00:35] <bschaefer> looks good, and is way better then my branch
[00:35]  * bschaefer goes to reject his
[01:13] <mdeslaur> Trevinho: thanks!
[01:28] <Trevinho> mdeslaur: if there are not other issues, I'm going to bed... That branch should be enough
[04:04] <Mirv> morning
[08:03] <Laney> hey!
[08:11] <seb128> good morning desktopers
[08:14] <Laney> lut seb128
[08:14] <seb128> Laney, howdy, how are you?
[08:15]  * seb128 shakes fist at xnox
[08:15] <Laney> very good thanks! and you?
[08:15] <seb128> xnox, could you please stop uploading without considering the packaging vcs-es?
[08:15] <seb128> Laney, I'm good thanks ;-)
[08:16] <Laney> naughty xnox
[08:16] <seb128> especially that in this case he stepped over a version already used for a SRU
[08:16] <seb128> which made the SRU be rejected after a week of waiting in the queue
[08:16] <seb128> *great*
[08:23] <mlankhorst> so touch can corrupt xorg-server :P
[08:23] <mlankhorst> anyone here with a touchscreen and some interest in valgrind?
[08:24] <seb128> well, no special "interest" but I can probably help getting debug info
[08:28] <mlankhorst> yeah just spawning xorg-server + a unity session and reproducing bug 1311828 and bug 1298727 is enough.
[08:28] <ubot2> Launchpad bug 1311828 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT" [Medium,New] https://launchpad.net/bugs/1311828
[08:28] <ubot2> Launchpad bug 1298727 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in point_on_screen()" [Medium,Incomplete] https://launchpad.net/bugs/1298727
[08:28] <mlankhorst> something like "/usr/bin/valgrind --keep-stacktraces=alloc-and-free --show-reachable=yes --track-fds=yes --leak-check=full --error-limit=no --freelist-vol=50000000 --freelist-big-blocks=10000 --track-origins=yes --leak-resolution=high --malloc-fill=ef --free-fill=df /usr/bin/Xorg "$@" -core -verbose 10"
[08:29] <mlankhorst> and install xserver.*dbg$
[08:35] <seb128> k, I'm trying to do that in a bit, need to update my test config first, install valgrind, dbgs, etc and see if I can reproduce the bug
[08:35] <seb128> where do you put that command? do you replace the X binary by that or..?
[08:36] <mlankhorst> that's one way to do it :P
[08:36] <mlankhorst> I created an /etc/X11/X2 shellscript, and symlinked /etc/X11/X to it (that file must be a symlink or X won't start)
[08:37] <mlankhorst> http://paste.debian.net/96346/ my /etc/X22/X2
[08:38] <seb128> thanks
[08:38] <Laney> x22!
[08:38] <mlankhorst> oops :P
[08:40] <mlankhorst> oh and probably the dbg files for libdrm.*dbg$ and libpixman.*dbg$
[08:46] <xnox> seb128: argh, sorry. which package did i step over like that?
[08:46] <seb128> xnox, empathy
[08:47] <xnox> seb128: well, use SRU version numbers for SRUs? =)))))
[08:48] <seb128> xnox, what is a SRU version?
[08:48] <xnox> 3.8.6-0ubuntu9.1
[08:49] <xnox> as per SRU docs...
[08:51] <seb128> xnox, that wouldn't have changed the fact that the vcs had work to be uploaded that should have been included in that upload, instead of doing a no change upload
[08:51] <xnox> yeah, sorry.
[08:52] <seb128> no worry, please be careful with desktop packages next time though, most have packaging vcs-es
[08:52] <xnox> some are out of date, some are not.
[08:53] <xnox> i want a way to do version numbers for rebuilds that are not reusing any other upload numbers ideally. to avoid contention.
[09:09] <ricotz> seb128, hi
[09:09] <ricotz> just a short question ;)
[09:09] <ricotz> will utopic target gnome 3.12 or are you going straight for 3.13/14?
[09:09] <seb128> lol
[09:09] <seb128> ricotz, hey
[09:10] <ricotz> i guess the conservative approach turned out fine for you
[09:10] <seb128> ricotz, we plan to discuss the topic during the meeting later today, but I can tell you for sure not going to 3.13
[09:10] <seb128> I would rather ponder the "stay on 3.10"
[09:10] <seb128> but realistically I think we are going to end up doing 3.12
[09:10] <ricotz> alright ;)
[09:11] <seb128> and yes, the "stay on stable" serves us pretty well
[09:11] <ricotz> 3.12 sounds fine since there are a lot synced already too
[09:11] <seb128> we didn't have too much fire fighting since we do that and quality went up
[09:12] <ricotz> right ;)
[09:12] <seb128> well, 3.12 synced, so things depwait on a newer gtk?
[09:12] <seb128> I don't see gtk 3.12 being done/ready before some time
[09:12] <ricotz> no, just some minor components which doesnt require gtk 3.12
[09:12] <seb128> k, that's fine then
[09:13] <ricotz> gtk 3.12 is in gnome3-staging so testing it is possible
[09:13] <seb128> is that a proper update?
[09:13] <Laney> with patches?
[09:13] <ricotz> yes
[09:13] <seb128> or another of those updates dropping the patches that were too difficult to port?
[09:14] <ricotz> please just give it a short look and judge about it
[09:15] <ricotz> thanks, bbl
[09:16] <seb128> is there any known issue with themes or overlay scrollbar?
[09:16] <Laney> does seem to have all the patches, only change is git backports
[09:16] <seb128> yeah
[09:16] <seb128> I just compared the series
[09:17] <Laney> and the other ones didn't require much updating ...
[09:17] <Laney> what is this wizardry
[09:17] <seb128> larsu, ^ maybe you want to have a look/try gtk 3.12 from https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+packages?field.name_filter=gtk%2B3 ?
[09:17] <Laney> is this like bearing the fruits of upstreaming stuff or something :P
[09:18] <seb128> there must be some runtime issues with overlay-scrollbar or something
[09:20] <seb128> one gotcha is going to be the text-wrapping/dialogs I think
[09:20] <seb128> but we can distro patch that out before release if needed
[09:20] <Laney> yep, debian will probably do that too
[09:21] <seb128> looking to the NEWS entries, that seems not a crazy cycle
[09:21] <seb128> that's good news
[09:22] <seb128> I'm going to try it before the meeting today
[09:31] <seb128> somebody has been browsing e.u.c for lightdm issue and clicking the "create" button
[09:34]  * mlankhorst pokes seb128 
[09:34] <seb128> yes?
[09:35] <seb128> I'm starting the test box for your issue
[09:35] <seb128> sorry, got busy until now with other things
[09:46] <mlankhorst> k
[09:46] <mlankhorst> np  :)
[09:49] <darkxst> hey seb128, Laney
[09:49] <seb128> hey darkxst
[09:53] <darkxst> seb128, really? staying on 3.10? as if that well happen ;)
[09:54] <seb128> easiest way to avoid gtkheaderbars...
[09:55] <larsu> ricotz: where do you keep the packaging branch for gtk?
[09:55] <darkxst> seb128, did the entire conversation last night, just fly past you?
[09:55] <darkxst> larsu, we don't have any packaging branches currently, going to look at setting that up this cycle
[09:55] <larsu> darkxst: ah okay, thanks
[09:56] <seb128> darkxst, which one?
[09:56] <seb128> on how to handle gtkheaderbars?
[09:56] <darkxst> seb128, yes, gtkheaderbars!
[09:56] <seb128> or on the conflict of interest between flavors?
[09:57] <seb128> but, no, none did fly past no
[09:57] <darkxst> seb128, and ignoring the WN hints to get back titlebars
[09:57] <darkxst> WM even
[09:57] <seb128> I'm still not convinced we can make gtkheaderbar a non-regression for !gnome-shell users
[09:57] <seb128> I'm not convinced that wm bar + headerbar without control is not a regression in UI over what we have
[09:58] <seb128> I need to test on real cases to see how it looks/feel
[09:58] <darkxst> seb128, without window controls and with titlebars its not much difference to what in archives currently
[09:58] <seb128> like there is no title in the headerbar?
[09:59] <darkxst> seb128, huh? you guys would have a titlebar with a *title*!
[09:59] <larsu> seb128: I want to talk about this at the hackfest tomorrow
[09:59] <larsu> there are two approaches for us
[09:59] <larsu> (1) go csd, but with our theme
[09:59] <larsu> (2) make headerbars into primary toolbars by adding a titlebar
[10:00] <darkxst> larsu, upstream won't take 2, so that would have to be a distro patch
[10:00] <seb128> what do you mean with (2)?
[10:00] <seb128> the title issue is
[10:00] <seb128> what happens to http://curiousdtu.files.wordpress.com/2014/02/gedit2.png?w=774 if we add a wm bar
[10:00] <seb128> do we have "unsaved document" 3 times ?
[10:00] <seb128> one in the wm bar, one in the headerbar bellow it, one in the tab?
[10:01] <larsu> darkxst: I'm not so sure about that
[10:02] <larsu> seb128: no, it would hide the title in the toolbar
[10:02] <seb128> larsu, how would it look for apps that have only a title and a close button if we hide both
[10:02] <seb128> would we get an empty headerbar?
[10:02] <seb128> or would it get hidden?
[10:03] <larsu> I don't know about that case
[10:03] <larsu> most of the time, apps have additional buttons there
[10:03] <darkxst> larsu, when I discussed with them, they seemed to think ignoring the WM hints in Unity was the way to go
[10:03] <larsu> like in the screenshot you posted
[10:03] <seb128> larsu, https://lh6.googleusercontent.com/-Ixfpn57HBL8/UtbDAz_crhI/AAAAAAAAAaM/xwvAaPy8Ebc/w480-h500-k/gnome%2Bcalculator%2B3.11.3%2Bfedora%2B21%2Brawhide.png
[10:03] <desrt> seb128: i think i've seen this link somewhere before ;)
[10:03] <seb128> desrt, no, different one
[10:04] <seb128> that's not a buggy case this time ;-)
[10:04] <desrt> oh.  why do you show it, then? :)
[10:04] <larsu> darkxst: who is "them"?
[10:04] <seb128> just an example of headerbar with only a title and button
[10:04] <seb128> desrt, ^
[10:04] <seb128> desrt, because of <seb128> larsu, how would it look for apps that have only a title and a close button if we hide both
[10:04] <darkxst> larsu, mclassen and co
[10:04] <larsu> desrt is meaning to talk to him
[10:04] <desrt> was gonna yesterday but got busy with menus
[10:04] <larsu> seb128: fair point. Maybe we should hide it then
[10:05] <larsu> seb128: I'm not sure (2) is the better option, and in fact desrt just mentioned some compelling reasons for (1)
[10:05] <larsu> seb128: I'm still pondering and haven't thought about all of the issues
[10:05] <seb128> I'm unsure what (1) mean
[10:05] <seb128> is that doing what GNOME is doing?
[10:05] <larsu> yes, but changing it to look more like unity
[10:06] <seb128> e.g hidding the wm controls and making the theme look "native enoguh"
[10:06] <seb128> right
[10:06] <larsu> dark theming, different buttons etc
[10:06] <larsu> ya
[10:06] <seb128> my concern that we would never have perfect consistency that way
[10:06] <seb128> but I'm happy to be proved wrong
[10:06] <desrt> seb128: we decide to have a desktop based on five toolkits....
[10:06] <desrt> we will never have perfect consistency, ever
[10:06] <larsu> I'm not sure "perfect consistency" is what we should optimize for
[10:06] <larsu> many apps are going that route
[10:06] <larsu> for example chromium
[10:07] <seb128> chromium is much better integrated than gtkheaderbars
[10:07] <seb128> it even has a setting to use the name wm controls
[10:07] <darkxst> and QT apps pretending to be GTK ones like USC!
[10:07] <seb128> name->native
[10:07] <seb128> well, one toolkit you can dream about
[10:07] <seb128> but it's not going to happen
[10:07] <seb128> unless you want to replace skype, eclipse, libreoffice, firefox, chrome
[10:08] <seb128> and I don't see GNOME achieving that either
[10:08] <darkxst> seb128, epiphany is pretty slick these days ;)
[10:08] <seb128> so reality is that we have to deal with apps using different toolkits
[10:08] <seb128> darkxst, if you don't care about security in your browser yes
[10:08] <seb128> webkitgtk doesn't do security updates
[10:09] <desrt> epiphany is great -- for webapps, with trusted sites :)
[10:09] <darkxst> seb128, yes I know... that is why we still ship firefox ;(
[10:09] <seb128> which is why no distro ships with epiphany as a webbrowser
[10:09] <desrt> using it as a general-purpose browser is pretty much insane
[10:09] <desrt> (and unusable, honestly)
[10:09] <Sweetshark_gc> I hear there is a volunteer to finish the gtk3 native port of libreoffice in the channel?
[10:09] <seb128> right
[10:09] <seb128> Sweetshark_gc, would that be you? ;-)
[10:09] <Sweetshark_gc> seb128: *cough* no?
[10:10] <seb128> Sweetshark_gc, start by fixing those menus!
[10:10] <Sweetshark_gc> *grumble*
[10:10] <darkxst> Sweetshark, and add gtkheaderbars ;) just to annoy seb128 ;)
[10:10] <seb128> larsu, but yeah "perfect consistency" might not be the goal, I would still prefer to avoid user-experience-regressions in our default apps if possible
[10:10] <seb128> larsu, but solutions to that might be to patch like we did for menus
[10:10] <chrisccoulson> seb128, I'd be open to someone contributing a gtk port of oxide if you want a webengine that's maintained by the security team ;)
[10:11] <seb128> larsu, or to replace those apps by some "written for traditional desktops"
[10:11] <seb128> larsu, e.g we might decide that e.g eog design goals are too far from ours and that we would be better served by another image viewer
[10:11] <desrt> seb128: taking a step back, headerbars are an awesome step forward
[10:12] <seb128> desrt, depending for who, not for app writers that want to target the different desktops
[10:12] <desrt> seb128: i said to take a step back :p
[10:12] <seb128> they give their users a pretty suboptimal experience
[10:12] <desrt> i agree that they're not a great fit if you just drop one app into a desktop like this
[10:13] <desrt> but what i'm trying to say is, honestly, i think we should try to move more toward such designs ourselves
[10:13] <desrt> the issue here is only the consistency one
[10:13] <desrt> (and i agree that is an issue)
[10:13] <seb128> right, I agree with that
[10:17]  * darkxst hands seb128 a fork ;) 
[10:17]  * desrt hands seb128 a knife and a steak
[10:18]  * larsu hands seb128 some red wine
[10:19] <larsu> seb128: we'd have user experience regressions too if we switch apps, no?
[10:24] <seb128> larsu, not especially ? if some app is better ?
[10:24] <seb128> larsu, like we replaced f-spot by shotwell, I don't consider that an user regression
[10:25] <seb128> it's different, it doesn't mean less integrated/less easy to use/less features
[10:25] <desrt> seb128: i think the trouble is in finding high quality apps :)
[10:25] <desrt> for better or worse, gnome (still) has some of the best stuff around
[10:25] <larsu> seb128: I meant the confusion that comes with changing the app. But yeah, if it's much better that weighs more
[10:26] <seb128> desrt, well, one possible one could be evince ->  okular for example (note that I didn't look at okular, but poppler upstream keep using it as an example of better pdf viewed than evince)
[10:26] <desrt> seb128: poppler upstream are kde developers :p
[10:26] <seb128> I know, okular seems to be a good pdf viewer though
[10:26] <seb128> anyway no point to discuss specific examples
[10:27] <desrt> specific examples are good to discuss, i think
[10:27] <seb128> I'm also sure we would have no difficulty finding a decent calculator
[10:27] <desrt> okular might be good
[10:27] <seb128> it's not like gnome-calculator was the perfect calc
[10:27] <desrt> but if we want to switch away from nautilus or something?
[10:27] <seb128> we would take nemo
[10:27] <desrt> scary :)
[10:27] <seb128> that would give us back split view
[10:27] <desrt> why not caja?
[10:27] <seb128> and other stuff our users complain about loosing
[10:27] <ochosi> sorry to chip in, but are you discussing moving towards headerbars?
[10:27]  * larsu missed those games the last few cycles
[10:27] <seb128> I don't know what caja is
[10:27] <larsu> ochosi: yes
[10:27] <desrt> mate-nautilus
[10:28] <darkxst> ipython is a pretty good calculator ;) although probably not for thte masses ;)
[10:28] <ochosi> from xubuntu POV (if that is of any concern/interest to you guys) we were rather happy about you patching out the headerbars in 14.04
[10:28] <ochosi> s/xubuntu/xubuntu's/
[10:29] <larsu> yeah... the problem is that that will become increasingly hard
[10:29] <darkxst> ochosi, only nautilus and epiphany were patched, everything else was just avoided
[10:29] <desrt> also: headerbars, in their own right, are good
[10:29] <larsu> and seb128 is afraid that we'll get another patch madness like we have with menus now
[10:30] <ochosi> right, that's understandable. but personally i think it'd be better to talk to upstream about providing more options for !gnome-shell desktops
[10:30] <ochosi> just "dealing with what we got" is what xubuntu alone is forced to do, we're a tiny team and we have no leverage/voice
[10:30] <desrt> seb128: i hate to appeal to the media, but it seems that all i hear about anymore is gnome is getting better UI and unity is getting worse...
[10:31] <darkxst> ochosi, upstream did quite some work with for example allowing WM button layouts within the headerbars
[10:31] <desrt> i think we should not be afraid to follow gnome on some of the improvements
[10:31] <larsu> ochosi: talking to them about more options is asking them to do the work, which is a bit unreasonable
[10:31] <seb128> desrt, not sure what you call "media", I didn't read anything about GNOME vs Unity for a long time and all the trusty reviews I read stated that Unity was "a polished desktop now"
[10:31] <darkxst> but they are not going to make gtkheaderbars optional, and atleast in my discussions with them, they seem to think the WM should just ignore the MWN hints for decorations/titlebars
[10:32] <desrt> seb128: i just searched 'ubuntu unity' and the first item that came in google news is "Ubuntu 14.04 review: Missing the boat on big changes
[10:32] <seb128> desrt, is media = reddit ?
[10:32] <desrt> While a new kernel should mean better performance, Canonical's UI troubles persist. "
[10:32] <desrt> arstechnica in this case
[10:32] <ochosi> larsu: whatever happened to the good practice of a bit of backward compatability? anyway, i understand, but i think that'd be a good thing even if patches would have to be contributed. maybe i'm too optimistic about "making a voice heard"
[10:33] <ochosi> seb128: +1, i haven't read much about that either
[10:33] <larsu> ochosi: voices are heard, it's just that noone has time for it
[10:33] <ochosi> darkxst: yeah, but being able to disable headerbars would be more desirable. there's a lovely post by martin grÃ¤sslin about the shortcomings of headerbars (not being able to kill a hanging app,...)
[10:34] <seb128> desrt, yeah for crappy titles
[10:34] <seb128> "What's missing
[10:34] <seb128> Mir and Unity 8 did not make the cut, but they will be coming eventually (14.10 looks pretty likely to see at least xMir enabled by default)"
[10:34] <desrt> media on new gnome release seems to be "hey... this is finally getting really nice... too bad nobody ships it"
[10:34] <seb128> desrt, so arstechnica is speaking about the LTS not having the newest kernel, Mir or unity8
[10:34] <desrt> seb128: right
[10:34] <seb128> but the unity part of the review is rather positive
[10:34] <desrt> in general i see the biggest thing said about this release is "kinda boring... not much changes..."
[10:35] <seb128> right, that's a LTS
[10:35] <desrt> not much changes since last lts :p
[10:36] <seb128> desrt, that review you mentioned states "Ubuntu is one of the most polished desktops around, certainly the most polished in the Linux world, "
[10:36] <seb128> in the conclusion
[10:36] <desrt> seb128: and the very same article, in the conclusion, talks about the mess that all of our patching has caused us :p
[10:36] <seb128> they have more issues with things like nautilus dropping features, and they say it's coming from GNOME
[10:37] <seb128> "what does it say that it still can't make menus behave consistently?"
[10:37] <seb128> haha
[10:37] <seb128> desrt, well, I don't have the same reading
[10:37] <seb128> to me their issues is what I was pointing before
[10:37] <seb128> design changes from GNOME
[10:37] <darkxst> seb128, gnome-shell has improved in leaps and bounds since last LTS
[10:37] <seb128> that are making apps no consistent
[10:37] <ochosi> +1
[10:37] <desrt> seb128: seems like the biggest complaint is with global menu, in fact
[10:38] <desrt> but i think maybe we should stop arguing over what is written in the press
[10:39] <seb128> you are the one who started it!
[10:39] <seb128> but agreed
[10:39] <desrt> ya
[10:39] <desrt> even when i started it i knew it was a bad idea :p
[10:39] <seb128> I think your view of the press is biased as well
[10:39] <desrt> maybe
[10:39] <desrt> but one thing that is pretty clear is that people are liking the direction of gnome
[10:40] <desrt> so if they don't like how gnome apps are integrating in ubuntu then this is either an issue of integration or an issue of the patching that we've done
[10:41] <seb128> desrt, I'm unsure I agree with that, some people like where GNOME is going, some hate it
[10:41] <seb128> same for Unity
[10:41] <darkxst> desrt, or an issue of some gnome apps being very old (think gnome-terminal)
[10:41] <desrt> seb128: i think people are upset over some specific things in gnome -- i'm one of them
[10:41] <desrt> but the overall design idea appears to be paying off
[10:42] <seb128> I read lot of comments from user who like mint/cinnamon/elementary/xfce better than GNOME3 or Unity
[10:42] <desrt> ya... of course
[10:42] <desrt> i hear that some crazy people even like kde...
[10:42] <seb128> lol
[10:42] <seb128> I don't think GNOME is winning the "battle of minds"
[10:42] <desrt> i'm just saying that if we want to continue to have gnome apps, we may want to adopt some of their new approaches
[10:42] <seb128> we have more fragmention than before in anything
[10:43] <desrt> they're not bad
[10:43] <seb128> and I don't see a clear winner
[10:43] <seb128> in->if
[10:43] <desrt> and our increasingly complicated attempts to remain in the past are starting to hurt us more and more
[10:43] <seb128> well
[10:43] <desrt> (the past = make gnome apps look like they used to)
[10:43] <darkxst> desrt, well particularly hurting Ubuntu GNOME!
[10:43] <seb128> unity7/our current desktop is meant to be a "stable developer desktop"
[10:44] <seb128> our innovations go to unity8
[10:44]  * desrt kinda wishes gnome had this kind of focus...
[10:44] <seb128> that has its own set of apps, etc
[10:44]  * darkxst can't believe that some people prefer to crawl through applications menus, rather types a few letters to search for said app
[10:44] <seb128> so all the problems we discuss are going to be resolved there
[10:44] <seb128> the friction is on the "traditional desktop"
[10:45] <darkxst> seb128, how so? unity8 will just further disjoint the "traditional desktop" people?
[10:45] <desrt> darkxst: most people always had some sort of launcher icons for their favourites
[10:46] <seb128> darkxst, what do you mean?
[10:46] <darkxst> desrt, that is still there in gnome-shell and unity (I presume)
[10:46] <seb128> darkxst, well, unity8 comes with new apps using the new toolkit, so it's going to resolve the conflict of (ab)using GNOME apps to make them match our design
[10:47] <darkxst> seb128, touch apps on desktop ;)
[10:48] <desrt> fwiw, i don't care too much about ubuntu gnome...
[10:48] <larsu> darkxst: the idea is that those will be adjusted for desktop usage and  more laptops will have touchscreens
[10:48] <desrt> my primary concern is the increasing amount of developer resource we spend on patching things...
[10:48] <larsu> the question is what we do in the meantime
[10:48] <larsu> which might be a couple of cycles
[10:48] <seb128> right
[10:49] <seb128> well, as said we basically have 2 desktops
[10:49] <desrt> could maybe stop updating all gnome apps
[10:49] <desrt> this is a pretty viable idea, really...
[10:49] <seb128> unity7 is a "traditional" developer desktop, I don't see much design changes or innovation going there
[10:49] <seb128> that's what I was sort of suggesting
[10:49] <desrt> since most of the changes in gnome these days are changing to new UIs.... and then we just want to reverse those anyway
[10:49] <seb128> just keep unity7 as a solid base, just fix issues
[10:49] <desrt> kinda pointless
[10:50] <desrt> imho this is not the right approach, but i certainly like it better than moving to new versions and then hacking their UIs halfway back to the old way
[10:51] <darkxst> desrt, the entire point of Ubuntu GNOME is building a community around gnome desktop and make it work well in Ubuntu
[10:51] <desrt> darkxst: i know
[10:51] <darkxst> suggesting to hold everything back will just kill our project
[10:51] <desrt> but i guess it's not really the concern of canonical...
[10:52] <darkxst> and the potential developers that come from it ;)
[10:52] <desrt> darkxst: you've elected to fight an uphill battle...
[10:54] <desrt> unless we want to start forking everything (unity-nautilus, unity-evince, etc.) like we did g-s-d and g-c-c, you're faced with what is effectively a fork of gnome, trying to make it work like upstream
[10:55] <darkxst> desrt, I am not going to fork upstream projects! Canonical should be forking the oldies they want to keep
[10:56] <desrt> ya... maybe there is some good argument for this
[10:56] <larsu> seb128: 3.12 is working fairly nicely
[10:56] <desrt> we did it with g-s-d and g-c-c, after all
[10:56] <larsu> seb128: first issues I'm seeing are titlebar-less dialogs
[10:56] <seb128> larsu, good news!
[10:56] <desrt> but then you get the burden of packaging the gnome releases
[10:56] <larsu> seb128: even o-s seems to work
[10:56] <seb128> \o/
[10:56] <larsu> I haven't done extensive testing yet, though
[10:56] <desrt> this makes me very happy
[10:56] <desrt> it would have been extremely bad news if we would have had to get rid of o-s
[10:56] <seb128> desrt, if we are going down to "fork" we can as well share the fork, and use e.g nemo...
[10:57] <desrt> or caja
[10:57] <desrt> take a look at mate, seriously...
[10:57] <desrt> it's basically like releasing old versions of gnome :p
[10:57] <seb128> heh
[10:58] <desrt> just keep updating the libraries -- this is all most people care about
[10:58] <desrt> "developers", after all
[10:58] <larsu> desrt: it's what you care about
[10:59] <desrt> larsu: in so far as i care about people like yorba who care about things like which libraries are available on ubuntu
[11:00] <larsu> desrt: they also care about what kind of ui and platform integration we have
[11:00] <larsu> and it's a pain to support more than one for them
[11:00] <desrt> larsu: ya... but we can keep this looking OK by staying with old versions
[11:00] <larsu> man, why are we talking on irc?
[11:00] <larsu> I can even see your irc window from here
[11:00] <desrt> because we're not red hat ;)
[11:00] <larsu> haha
[11:02] <seb128> desrt, larsu: anyway, to focus back the discussion
[11:02] <seb128> let's make GtkHeaderBar work as good as we can on !gnome-shell (Unity being the main focus)
[11:02] <seb128> that's the first step
[11:02] <desrt> this sounds good
[11:03] <seb128> once we think we have "as good as we can get", we can see how apps feel like
[11:03] <seb128> and then decide on the next steps for those
[11:03] <seb128> like if we feel gtkheaderbar are integrated enough
[11:03] <seb128> or if we need to get out of our way to resolve extra issues
[11:03] <larsu> seb128: what do you mean by that? My suggestion (1) or (2) from earlier?
[11:03] <desrt> there are a few things that are needed to get it working right... but not majorly huge ones
[11:03] <larsu> (make them look native in unity or make them be toolbarS)
[11:04] <seb128> larsu, I'm sure, whichever you feel like is going to give us the best experience on Unity
[11:04] <seb128> *unsure*
[11:04] <desrt> sounds like we have some work for the coming days
[11:04] <larsu> ya, this is my main goal for the hackfest
[11:05] <seb128> great
[11:05] <larsu> seb128: interesting. I'm unsure as well :)
[11:05] <seb128> sorry for all the side discussions
[11:05] <larsu> no worries
[11:10] <alkisg> attente: hi, could I bother you a bit about http://bazaar.launchpad.net/~ubuntu-desktop/gnome-settings-daemon/ubuntu/revision/437.1.10, and in particular about these lines?
[11:10] <alkisg> 344+        if (n_sources < 2 || g_strcmp0 (g_getenv ("XDG_CURRENT_DESKTOP"), "Unity") == 0)
[11:10] <alkisg> 345                 strip_xkb_option (options, "grp:");
[11:10] <alkisg> These lines break keyboard layout switching in applications that grab the keyboard, like SDL applications, so we cannot type e.g. Greek in e.g. tuxpaint, tuxtype, teeworlds etc.
[11:10] <alkisg> See also e.g. my comment #7 in https://bugs.freedesktop.org/show_bug.cgi?id=42244
[11:10] <ubot2> Freedesktop bug 42244 in Server/Input/Core "Multimedia keys become unresponsive in full-screen applications" [Normal,Reopened]
[11:11] <alkisg> (it's not only about multimedia keys anymore, now it's significantly more important, all those applications become useless for non-latin environments)
[11:13] <attente> alkisg, we disabled it because layout switching is done differently in unity and we didn't want xkb switching to conflict with that
[11:13] <alkisg> attente: and, is there any provision for the issue I mentioned?
[11:14] <alkisg> Because I don't think you'll be able to allow keyboard switching without letting xkb manage it...
[11:14] <alkisg> (in apps that grab the keyboard)
[11:14] <seb128> alkisg, no, I think it's one of those GNOME design decisions where you are going to need to wait for wayland/Mir to have it working back correctly
[11:15] <alkisg> seb128: in Fedora they have it working like I mentioned
[11:15] <alkisg> It's an ubuntu-specific patch
[11:15] <attente> alkisg, sorry, i'm reading the bug report, but not really sure how the grp: option is related
[11:15] <seb128> alkisg, the freedesktop bug states "(It's the same in other distros too, it's not Ubuntu specific)"
[11:15] <alkisg> seb128: there are many many bugs about it, it's a lot more than this one,
[11:15] <seb128> alkisg, also the xorg grabbing is nothing Ubuntu specific
[11:15] <alkisg> ...I'll probably need to describe it better
[11:16] <seb128> alkisg, overstatement like that don't help, can you just focus on the issues?
[11:16] <alkisg> So, there are many issues wrt keyboard, switching etc, I'll ignore them for now and only focus on the issue I described above,
[11:16] <alkisg> i.e., how to switch layouts when unity-settings-daemon can't get an event because of the keyboard grab
[11:16] <seb128> alkisg, GNOME stopped using xserver group switching in favor of grabbing in the shell and doing changes themself from there
[11:16] <seb128> we do the same in Unity now
[11:16] <alkisg> seb128: I've been talking with upstream gnome for the past 3 days
[11:17] <seb128> and?
[11:17] <alkisg> The issue I'm mentioning right now, is ubuntu-specific
[11:17] <alkisg> ...but, you are right in what you say,
[11:17] <seb128> do you use Unity?
[11:17] <alkisg> and that causes a few other issues, like e.g. that when I use xkb to switch layouts, the indicators don't get updated
[11:17] <seb128> or gnome fallback?
[11:17] <alkisg> I tried in Unity, Gnome-fallback, gnome-shell etc
[11:17] <seb128> they all have the issue?
[11:18] <alkisg> The first two, but, if I launch unity-settings-daemon with a different XDG_CURRENT_DESKTOP, then fallback works two, and I imagine unity will too, I haven't tried that there
[11:18] <alkisg> So, I'm trying to see why that thing was added, in order to help patching it elsewhere
[11:19] <seb128> hum
[11:19] <alkisg> That one: || g_strcmp0 (g_getenv ("XDG_CURRENT_DESKTOP"), "Unity") == 0)
[11:19] <seb128> what you said doesn't make mutch sense
[11:19] <seb128> the old way was to let g-s-d/u-s-d do the grabbing
[11:19] <alkisg> setxkbmap -query, says: options:    grp:alt_shift_toggle,grp_led:scroll
[11:19] <seb128> in Unity session compiz is grabbing the keys
[11:19] <seb128> same as gnome-shell is doing
[11:20] <seb128> so technically compiz/Unity sessions should behave the same as gnome-shell
[11:20] <alkisg> That's the correct thing to have. But, that part of the code, strips the alt_shift_toggle, and we can't switch locale in e.g. tuxtype anymore
[11:20] <alkisg> Yes, I don't mind that part
[11:20] <seb128> or did they apply some fixes in newer version we didn't backport/do something different?
[11:20] <alkisg> It does cause issues, but other issues, not what I'm trying to describe
[11:21] <alkisg> (02:19:45 μμ) seb128: in Unity session compiz is grabbing the keys => I.e. I'm not asking to remove that,
[11:21] <alkisg> I'm only asking to allow xkb have a layout switching shortcut as well
[11:21] <alkisg> Same as gnome-shell does
[11:21] <seb128> hum?
[11:21] <seb128> the stripping is done by g-s-d
[11:21] <seb128> https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=fc3676f0457789307e49d7abbf8115457a25e479
[11:21] <seb128> same upstream
[11:22] <seb128> is that commit your issue?
[11:22] <alkisg> No
[11:22] <alkisg> I can solve my issue just by running: XDG_CURRENT_DESKTOP=Gnome unity-settings-daemon --replace &
[11:23] <seb128> well, that makes u-s-d do the grabbing again
[11:23] <alkisg> I.e. just by omitting the debian/patches/unity-modifier-media-keys.patch
[11:23] <seb128> instead of using the compositor
[11:23] <alkisg> seb128: see that one: http://bazaar.launchpad.net/~ubuntu-desktop/gnome-settings-daemon/ubuntu/revision/437.1.10
[11:23] <alkisg> 344+        if (n_sources < 2 || g_strcmp0 (g_getenv ("XDG_CURRENT_DESKTOP"), "Unity") == 0)
[11:23] <alkisg> The || part is Ubuntu-specific
[11:24] <alkisg> In upstream it's plain (n_sources < 2)
[11:24] <alkisg> That's what I'm asking to revert to what it is in upstream
[11:24] <alkisg> It's the same in unity-settings-daemon too
[11:24] <seb128> that doesn't make sense
[11:25] <seb128> oh
[11:25] <alkisg> It says, "remove the grp: if we're running Unity"
[11:25] <seb128> attente, is that supposed to be a && ?
[11:25] <attente> seb128, should be an ||
[11:26] <attente> seb128, alkisg, not sure what the consequences of removing it are
[11:26] <attente> alkisg, have you tested without it?
[11:26] <seb128> why did we add it?
[11:27] <alkisg> attente: I only tried with gnome-fallback and XDG_CURRENT_DESKTOP=Gnome unity-settings-daemon --replace &, then I came here to ask about why it was added, to see what to test or find other workarounds for them... :)
[11:27] <attente> seb128, i added it because i didn't want xkb to switch layouts when unity+u-s-d were already handling it
[11:27] <alkisg> Let me say some related things:
[11:27] <attente> but if it's inconsequential and only fixes things, then i'm all for removing it
[11:27] <darkxst> alkisg, XDG_CURRENT_DESKTOP=Gnome is not correct, you are just getting nothing behaviour with that
[11:27] <mdeslaur> seb128: hi! yes, I'll apply the fix on top of the SRU
[11:27] <alkisg> darkxst: I just wanted to skip the "|| Unity" check
[11:27] <seb128> mdeslaur, hey, thanks!
[11:28] <alkisg> To switch from us,gr, I'm using either (1) Win+Space, the gnome/unity defined shortcut, or (2) Alt+Shift, the XKB-defined shortcut.
[11:28] <seb128> alkisg, that leads to the issue you described though "if you cycle using xkb, the indicator is wrong"?
[11:28] <darkxst> alkisg, its XDG_CURRENT_DESKTOP=GNOME
[11:28] <alkisg> seb128: right, but I don't know how, it's solved in Fedora 20
[11:28] <mdeslaur> seb128: thanks! Sorry for the mail, but I was going Eod and wanted you to see it before I got back
[11:28] <seb128> mdeslaur, no worry, emails are good, please keep sending some in such cases ;-)
[11:29] <alkisg> I'll try to locate that after we agree on the first one, i.e. that keyboard switching in fullscreen applications is too important to drop
[11:29] <seb128> alkisg, so how do users configure/known about alt-shift?
[11:29] <seb128> isn't that confusing?
[11:29] <seb128> shouldn't win-space work in all cases?
[11:29] <alkisg> It's the default in xorg, when choosing "greek" in ubiquity
[11:29] <seb128> (though I guess it can't due to the xorg grabs limitation)
[11:29] <alkisg> And it affects the console too
[11:29] <seb128> you happen to know about it
[11:30] <alkisg> So, the gnome solution isn't really good, it breaks a lot of stuff
[11:30] <seb128> but it's not displayed in the UI
[11:30] <alkisg> $ grep OPTIONS /etc/default/keyboard
[11:30] <alkisg> XKBOPTIONS="grp:alt_shift_toggle,grp_led:scroll"
[11:30] <xnox> seb128: i've just commented on bug #1242572 ubiquity sets up alt+shift for layout switching, since console-setup does not support super+space combo yet.
[11:30] <ubot2> Launchpad bug 1242572 in ubiquity (Ubuntu Trusty) "Ubiquity sets Alt+Shift shortcut for layout switching, while installed system uses Super+Space" [Wishlist,Confirmed] https://launchpad.net/bugs/1242572
[11:30] <seb128> xnox, ok
[11:31] <xnox> i'm going to send a bug report to debian to start supporting super+space which is modern universal layout switcher.
[11:31] <alkisg> So when xorg starts, it starts with Alt+Shift. Then, Gnome also adds Win+Space. Then, unity-settings-daemon blocks Alt+Shift, and that last part is what I'm trying to get fixed first.
[11:31] <xnox> alkisg: is XKBOPTIONS something Xorg parsers?
[11:31] <seb128> alkisg, so you get 2 different keybindings doing the same thing through different mechanism, isn't that confusing?
[11:31] <alkisg> Yes
[11:31] <xnox> alkisg: and if yes, then what's the combo for super_space? or a list of all supported combos?
[11:32] <alkisg> seb128: people don't yet know Super+Space, it's a new thing
[11:32] <xnox> alkisg: super+space is default in unity, gnome3, windows7&8, mac os x.
[11:32] <alkisg> From the windows world, up to windows vista it was Alt+Shift, same as in xorg,
[11:32] <seb128> alkisg, people do know about super-space, that's what other OSes use (e.g win or macOS) and that's what is displayed in the settings UI
[11:32] <alkisg> And I think in windows 7/8 (I don't use them), the started Win+Space
[11:32] <seb128> right
[11:33] <alkisg> So, to sum up:
[11:34] <alkisg> Gnome broke the ability to get notified from xkb when I switch layouts in fullscreen apps, and doesn't want patches about that.
[11:34] <alkisg> I.e. in fedora 20, in tuxtype, I can press alt+shift to switch languages, but when I exit, the indicator doesn't get updated
[11:34] <alkisg> *didn't
[11:34] <alkisg> That the _only_ part that doesn't work OK in fedora 20, everything else is fine. It's pretty minor.
[11:35] <alkisg> I can press alt+shift OR win+space and change layout while in gnome-shell. They both make the indicator update itself
[11:35] <seb128> alkisg, alt-shift is a leftover not exposed in an user visible way, you just happen to know about it it seems
[11:35] <alkisg> In ubuntu, even if I manage to get the alt_shift_toggle back, the indicator doesn't get updated. That's my second thing I want to help solve.
[11:36] <alkisg> seb128: me and everyone that has been using it for the last 20 years... :)
[11:36] <alkisg> We don't know about Win+Space... that's the new thing
[11:36] <alkisg> And, it doesn't work in tuxtype, we're not able to type Greek there in 14.04, while we were able to in 12.04
[11:36] <seb128> alkisg, sorry to tell you that, but you are a minority
[11:37] <alkisg> seb128: I'm talking about *all* Greeks
[11:37] <alkisg> And possibly many other countries
[11:37] <seb128> alkisg, there are more users of win7/8/macOS/unity/gnome-shell than users of 20 years old unix
[11:37] <seb128> alkisg, I'm speaking about not knowing super-space
[11:37] <alkisg> seb128: http://www.ltsp.org/stories/widget-map/?location=Greece
[11:37] <xnox> seb128: reading man xkeyboard-config there is no support for grp:lwin_space_toggle =(
[11:37] <alkisg> None of the schools there has anything newer than windows xp
[11:37] <alkisg> 1000+ schools, multiply with a few labs each...
[11:37] <attente> so are the full screen applications doing a full active grab of the keyboard?
[11:38] <seb128> attente, seems they do
[11:38] <alkisg> Yes
[11:39] <alkisg> seb128: I don't mind about alt+shift or win+space. What I mind about more is, being able to type greek in tuxpaint/tuxtype/etc etc
[11:39] <seb128> alkisg, anyway that discussion about people not knowing super-space is not useful, please just stop assuming that's true/important
[11:39] <seb128> alkisg, right
[11:39] <seb128> alkisg, so please stop trying to make a case against the keybinding ;-)
[11:39] <alkisg> The window manager can't help there, it can't see the switch event
[11:39] <alkisg> I wan't, sorry if it sounded like I started that part...
[11:39] <alkisg> *wasn't
[11:39] <seb128> no worry
[11:40] <attente> i do wonder what happens if we remove that condition and just try what upstream does
[11:40] <seb128> do you know if there is a bug in launchpad for the tux issue?
[11:40] <attente> sounds racy
[11:40] <alkisg> attente: I think we'll get bug reports about "alt+shift doesn't update the indicator", which is the second more significant thing that I'd like to work on
[11:40] <seb128> in which way?
[11:40] <seb128> well, ideally we wouldn't have 2 ways
[11:41] <alkisg> attente: It does work in Fedora though, so I'm confident there's some solution there provided upstream...
[11:41] <seb128> but it seems like due to xorg it's either the group cycle workaround to let those users to have a way to cycle
[11:41] <seb128> or nothing
[11:41] <alkisg> seb128: fedora does have 2 ways too
[11:41] <seb128> right
[11:41] <alkisg> And, console will have alt+shift for some time...
[11:41] <seb128> due to xorg I guess
[11:41] <alkisg> Right
[11:41] <seb128> ideally we would have 1 channel
[11:41] <seb128> working for everything
[11:42] <seb128> I guess the gnome-shell indicator listen for the xorg grp changes and react to them to update its config or something
[11:42] <seb128> attente, is indicator-keyboard doing that?
[11:42] <alkisg> No, it isn't, I tried it
[11:42] <alkisg> It's listening for a gsettings change
[11:43] <alkisg> /org/gnome/desktop/input-sources/current
[11:43] <attente> yeah, alkisg is right
[11:43] <seb128> which means that if we remove that u-s-d condition, we would create issues for users for hit alt-shift
[11:43] <seb128> like some could do it without noticing
[11:43] <alkisg> Create some, solve some
[11:43] <seb128> and get an invalid keymap
[11:43] <seb128> or at least not matching the indicator
[11:43] <alkisg> The ones solved are more important. And I'm confident the others can be solved as well.
[11:44] <seb128> not sure they are more important
[11:44] <xnox> mlankhorst: can xkeyboard-config support something like "grp:lwin_space_toggle" ? as in "switch keyboard layouts using Super + Space" ? This is for bug #1242572
[11:44] <ubot2> Launchpad bug 1242572 in xkeyboard-config (Ubuntu Trusty) "xkeyboard-config, console-setup, and ubiquity should use Super+Space for switching keyboard layouts" [Wishlist,Confirmed] https://launchpad.net/bugs/1242572
[11:44] <seb128> alkisg, what happen if you switch to greek before starting the game? you can then input in greek?
[11:44] <mlankhorst> xnox: no idea, what happens when you try?
[11:45] <alkisg> seb128: yes. Well, in some other cases, like teeworlds, I can't play the game, because it expects a latin "a" for left, instead of a greek "α"
[11:45] <alkisg> seb128: this also works: sleep 20 && dbus-send --session --type=method_call --print-reply --reply-timeout=2000 --dest=org.gnome.SettingsDaemon.Keyboard /org/gnome/SettingsDaemon/Keyboard org.gnome.SettingsDaemon.Keyboard.SetInputSource uint32:1 & tuxpaint --fullscreen
[11:46] <alkisg> I.e. it changes the layout while inside the fullscreen app
[11:46] <seb128> right
[11:46] <seb128> well the issue is that the game grabs the keyboard
[11:46] <alkisg> Right
[11:46] <seb128> so you super-space doesn't reach compiz anymore
[11:46] <seb128> I don't see a way around using the xorg cycling while we use X
[11:46] <alkisg> That's a xorg limitation; the problem is that gnome, window managers etc, haven't thought that limitation when designing the new way to manage layouts
[11:47] <seb128> it's not they didn't
[11:47] <seb128> it's that they designed a clean architecture, that is going to work fine for wayland
[11:47] <alkisg> But anyway that's an upstream decision, no point in discussing it here unless we want to carry a patch that translates xkb events => gsettings
[11:47] <alkisg> They're using backends
[11:47] <alkisg> xkb is one of the backends
[11:47] <alkisg> xkb provides a hook
[11:48] <alkisg> They just chose not to allow other implementations change the layout, and use that hook to get notified
[11:48] <alkisg> They decided that only gnome would use xkb...
[11:48] <alkisg> Anyway, not what we should be talking about
[11:48] <attente> alkisg, it would also depend on what keyboard layout they start the application with too
[11:48] <alkisg> So, what do we do now?
[11:49] <attente> alkisg, if the user starts with a US layout, then they still won't be able to switch to the Greek layout because it won't exist in the user's layouts
[11:49] <xnox> mlankhorst: good point. i wonder how to test it without settings-daemon/compiz/etal getting in the way.
[11:49] <alkisg> Is the "can't type greek inside fullscreen apps" enough of a problem, to drop the "|| desktop=unity" code above?
[11:50] <seb128> alkisg, it's enough of a problem to deserve being resolved, we are unsure that dropping the code is the best way to resolve it (yet)
[11:50] <alkisg> OK, let's see what issues that would cause
[11:50] <alkisg> 1) 2 ways to change layouts
[11:50] <alkisg> That the same in fedora, and I think also in windows
[11:50] <attente> seb128, alkisg, we might be able to do it, but we also need to add a bit of code to unity to handle the ISO_Next_Group key code
[11:50] <alkisg> Let me check in windows...
[11:51] <attente> alkisg, but that still won't solve the problem if the user starts the app in US
[11:51] <alkisg> attente: it will
[11:51] <alkisg> Windows 7 doesn't support win+space, only alt+shift
[11:51] <attente> alkisg, switch to a US layout, then try 'setxkbmap -query'
[11:52] <alkisg> attente: with xorg, we never switch layouts, it's always "us,gr"
[11:52] <alkisg> We switch... I don't know the terminology... the active set?
[11:52] <alkisg> The xprop never gets updated
[11:52] <attente> alkisg, is unity-settings-daemon not running for you?
[11:52] <attente> unity-settings-daemon overrides the layouts lists when the input source is changed
[11:52] <alkisg> If I change that with win+space, then it gets to  "gr,us"
[11:53]  * alkisg tries to say that better: with xorg, it's always: "us,gr". with gnome, it's: "us,gr" or "gr,us"
[11:53] <alkisg> It's never plain "us"
[11:53] <attente> alkisg, what i'm seeing now is not the same
[11:54] <attente> if i'm using unity-control-center, adding us and gr, then switch to us, i only see us when i call setxkbmap
[11:54] <mlankhorst> xnox: murder them :D
[11:54] <mlankhorst> or run a diff flavor
[11:55] <attente> alkisg, because every time u-s-d switches input sources, it uploads a new xkb configuration
[11:55] <alkisg> attente: it does, and it's "us,gr" or "gr,us"... now I'm with gnome-fallback, want me to switch to unity?
[11:55] <xnox> mlankhorst: oh does like xubuntu/lubuntu actually use X to switch layouts? I've tried $ startx gedit, and i can't switch keyboard layout in it.
[11:56] <attente> alkisg, i'm using unity and that's what's happening for me
[11:56] <mlankhorst> xnox: not sure
[11:56] <attente> alkisg, please try it :)
[11:56] <alkisg> attente: ah. There's also a note in the input-sources schema, let me find it...
[11:57] <attente> although i don't really understand why it wouldn't be the same, isn't unity-settings-daemon also running under gnome-fallback?
[11:57] <alkisg> It is
[11:57] <alkisg> attente: what's the output of this? gsettings get org.gnome.desktop.input-sources sources
[11:57] <alkisg> [('xkb', 'us'), ('xkb', 'gr')] for me
[11:57] <attente> anyways, we can try to remove it, but we do need to add something to unity
[11:58] <attente> alkisg, [('xkb', 'us'), ('xkb', 'gr')]
[11:58] <attente> and switching to 'us' results in only 'us' for the xkb configuration
[11:59] <alkisg> attente: do you have ibus running?
[11:59] <alkisg> If so, could you stop it?
[11:59] <alkisg> That's another bug, it shouldn't be running at all, but that's for upstream im-config...
[11:59] <alkisg> Tooo many keyboard-related bugs in the 12.04 => 14.04 transision.. :(
[12:03] <attente> alkisg, killing ibus doesn't change what i'm seeing
[12:04] <alkisg> OK give me a few minutes to test with unity
[12:05] <attente> ok
[12:06] <alkisg> But, I think that the implementation parts are the details, if we could agree first on what we want to do, I'm pretty sure we could provide patches for that.
[12:06] <alkisg> What I'd like to do, is make Ubuntu 14.04 do what Fedora 20 does, which isn't perfect like Ubuntu <= 12.04 was, but it's good enough. Everything works, even the indicator gets updated when I press alt+shift, and the only minor detail that doesn't work is that the indicator doesn't get updated while I'm inside a full screen app that grabs the keyboard
[12:06] <alkisg> If we could agree that we want to accept patches in that direction, I'm pretty sure it's implementable without diverting from upstream
[12:06]  * alkisg checks unity...
[12:06] <seb128> the goal sounds fine yes
[12:07] <attente> so remove the condition from u-s-d, handle ISO_Next_Group in unity, then maybe upload a secondary layout in u-s-d?
[12:08] <attente> sounds like it should be ok
[12:08] <alkisg> attente: if you have patches for that, I'd be more than glad to extensively test them :)
[12:09] <attente> alkisg, sure :)
[12:09] <attente> actually... i guess it's all u-s-d
[12:10] <xnox> mlankhorst: so i've definately tested xorg now, stopped lightdm / quit all unity sessions, did "startx", launched terminal, kill all gnome/unity-settings-deamons, then use setxkbmap to get russian and usa layout.
[12:10] <xnox> mlankhorst: lwin_space_toggle, win_space_toggle do not work, win_toggle does work.
[12:10] <attente> alkisg, have you checked setxkbmap under unity?
[12:10] <xnox> mlankhorst: so yeah, x clearly does not support super_space here.
[12:10] <mlankhorst> seems so :P
[12:10] <xnox> mlankhorst: can you forward that bug upstream? or should I file it somewhere?
[12:10] <alkisg> attente: I'm creating a livecd, because I've changed my system too much to be sure that it's clean...
[12:10] <mlankhorst> but does it work with unity?
[12:11] <xnox> mlankhorst: with unity - either gnome-settings-daemon or unity-settings-daemon or ibus or compiz intercept "super+space" and switch layouts.
[12:11] <xnox> mlankhorst: however this does not work e.g. in full-screen x apps, etc. as widely discussed above.
[12:11] <attente> alkisg, it's ok, no matter. i already know that it doesn't work on my machine, so that's something else to fix
[12:13] <mlankhorst> xnox: ok
[12:14] <xnox> mlankhorst: registering in the freedesktop bugzilla to open a bug report.
[12:20] <xnox> mlankhorst: filed https://bugs.freedesktop.org/show_bug.cgi?id=78076
[12:20] <ubot2> Freedesktop bug 78076 in General "Please add support for grp:lwin_space_toggle and similar" [Enhancement,New]
[12:23] <xnox> mlankhorst: would you write a patch for that? :-)
[12:24] <Laney> attente: check these beasts crushing hard https://www.youtube.com/watch?v=xAB9-VGIkzM
[12:26] <mdeslaur> Trevinho, seb128: http://www.ubuntu.com/usn/usn-2184-1/
[12:26] <mdeslaur> Trevinho, seb128: thanks! :)
[12:27] <seb128> mdeslaur, thanks!
[12:27] <alkisg> Thank you very much guys, I'll be back later on to try to help as much as I can. :)
[12:27] <mlankhorst> xnox: suddenly everyone wants something from me :P
[12:27] <seb128> work_alkisg, thanks for pointing those issues and helping getting them resolved!
[12:29] <attente> Laney, impressed to see any free soloing ;)
[12:30] <Laney> definitely bouldering opportunities in malta btw ;-)
[12:30] <Laney> (including DWS...)
[12:30] <attente> sounds fun :)
[12:31] <Laney> scary
[12:37] <xnox> mlankhorst: how would like to be bribed? =)
[12:40] <mlankhorst> ok lets see..
[12:43] <mlankhorst> xnox: looks like it should be fixable easily :P
[12:44] <mlankhorst> copy alt_space_toggle I guess
[12:45] <mlankhorst> hm no slightly more involved
[12:54] <xnox> Laney: with updated gnome-keyring job, it appears as if launchpadlib based things (e.g. like any ubuntu-archive / ubuntu-dev-tools scripts) fail to work, time out activating secrets api and fail to store lp token in the keyring.
[12:54] <xnox> Laney: have you noticed this?
[12:54] <Laney> no I use those inside lxc
[12:54] <Laney> lemme try
[12:58] <Laney> xnox: yeah ...
[12:58] <Laney> that's supposed to be dbus activated
[13:06] <Laney> xnox: I think it's because it's not on the user's bus
[13:06] <xnox> Laney: so gnome-keyring must start on started dbus?
[13:07] <Laney> try it, that made it work for me
[13:07] <Laney> then we get back to gpg/ssh ordering problems again
[13:08] <xnox> yeah it's racing with dbus job which is starting on xsession-init.
[13:08] <xnox> do we? i thought we wouldn't. gpg-/ssh- agents will not start, until gnome-keyring completes even if it's blocked by dbus not started yet.
[13:09]  * xnox will add sleeps to simulate blockage.
[13:09] <Laney> oh, you mean that started dbus and <what we have now> will work?
[13:10] <xnox> yeah.
[13:10] <xnox> "started dbus and (<what we have>)"
[13:10] <xnox> that's what i'm testing here now.
[13:10] <Laney> k
[13:14] <Laney> lunch!
[13:14] <Laney> i'm thinking fried eggs
[13:14] <mlankhorst> xnox: is it ok if both super keys work? :P
[13:14] <xnox> mlankhorst: yes, that's even better cause that's how it currently works under gnome-settings-daemon
[13:16] <seb128> mlankhorst, is http://paste.ubuntu.com/7359309/ having what you need?
[13:19] <mlankhorst> looks good, but  grr @ xf86platformVTProbe crap
[13:23] <mlankhorst> xnox: I have no idea what I'm doing, so here it is http://paste.debian.net/96403/ :P
[13:23] <mlankhorst> will probably break or something
[13:23] <xnox> mlankhorst: let me test it =)
[13:24] <mlankhorst> or fail to load
[13:24] <xnox> mlankhorst: better that, than the experimental efibootmgr i'm about to test.
[13:25] <xnox> mlankhorst: edit comments "toggle using lwin + space as combo" to say it's "win + space", not "lwin + space".
[13:26] <seb128> mlankhorst, do you want me to copy that somewhere, or are you going to send to upstream/to whatever bug you use for the issue?
[13:27] <mlankhorst> seb128: nah just checking at this point, going to need hardware first to do a bisect
[13:27] <seb128> k
[13:27] <seb128> the valgrind error/bt are not enough for upstream to have a clue?
[13:28] <mlankhorst> no they can reproduce that already
[13:28] <seb128> so they should be able to fix it?
[13:28] <mlankhorst> oh that vt probe bug I already fixed in utopic
[13:29] <mlankhorst> but the deliveremulatedmotionevent looks weird
[13:29] <seb128> the log has another error from the touch
[13:32] <mlankhorst> yeah looking at that, seems weird
[13:34] <mlankhorst> it shouldn't be called beyond end of the event queue, so the bug is not in EnqueueEvent, I think.
[13:36] <xnox> mlankhorst: loads correctly, does not work. space acts like a space, instead of "win+space" combo.
[13:36] <xnox> (when pressing simultaniously or holding down windows key and then pressing spacebar)
[13:37] <xnox> let me just try one more time, just in case.
[13:37] <mlankhorst> hm was afraid of that :P
[13:40] <mlankhorst> xnox: what if you load meta_win too?
[13:40] <xnox> altwin:meta_win ?
[13:41] <xnox> mlankhorst: loading: setxkbmap -model pc105 -layout us,ru -option grp:win_space_toggle,altwin:meta_win
[13:41] <xnox> makes windows+space not produce a " ", but it doesn't change layout either.
[13:41] <mlankhorst> hm
[13:41] <mlankhorst> I guess the mod4 should be Meta
[13:42] <xnox> oh, loading altwin:meta_win rmeoves win_space_toggle.
[13:43] <mlankhorst> ok, can you try the patch with Mod4 changed to Meta ?
[13:44] <xnox> mlankhorst: ok.
[13:50] <mlankhorst> I think the altwin one should no longer be needed then
[13:50] <xnox> mlankhorst: doesn't work, with or without.
[13:51] <mlankhorst> gr, stupid xkb-data defining a whole language
[13:56] <mlankhorst> xnox: http://paste.debian.net/96410/
[14:03] <xnox> mlankhorst: i wonder if all my tests are flawed, since i'm running them under compiz and e.g. Super+S does compiz wall thing.
[14:04] <xnox> *sigh*
[14:04] <xnox> still no.
[14:05] <mlankhorst> :/
[14:05] <mlankhorst> well I have no clue anyway, just guessing based on the syntax from xkb-data
[14:06] <xnox> i'll try again later in something more basic, like lubuntu.
[14:12] <mlankhorst> try a raw xserver + xev
[14:20] <mdeslaur> seb128: I need a bit of help...
[14:21] <mdeslaur> seb128: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-datetime/trunk.13.10/revision/282
[14:21] <mdeslaur> seb128: that causes unity-greeter to segfault, and I can<t seem to figure out why
[14:26] <larsu> mdeslaur: do you have a backtrace?
[14:29] <mdeslaur> larsu: not yet, I haven't figured out how to get one from the greeter
[14:42] <mdeslaur> seb128: hrm, this work though (but is a hack...) http://paste.ubuntu.com/7359767/
[14:44] <larsu> mdeslaur: that also removes functionality....
[14:45] <mdeslaur> larsu: oh?
[14:46] <larsu> mdeslaur: you unsetting an action that is referenced by the menu item. charles will know what it does exactly
[14:47] <mdeslaur> larsu: I added the else, the old code simply didn:t set activation-action
[14:47] <mdeslaur> charles: could you take a look?
[14:48] <larsu> mdeslaur: ah right, I misread. Probably a bug in the menu item itself then (which is in lp:ido)
[14:48] <charles> mdeslaur, sure
[14:48] <mdeslaur> charles: for context, I'm trying to release http://bazaar.launchpad.net/~indicator-applet-developers/indicator-datetime/trunk.13.10/revision/282 as a security update
[14:49] <mdeslaur> charles: but that commit causes the greeter to segfault
[14:49] <mdeslaur> seems something doesn't like not having "activation-action" set...but I can't figure out why
[14:50] <charles> mdeslaur, do you have a stacktrace?
[14:51] <mdeslaur> charles: how can I get a stacktrace for unity-greeter? (that's what segfaults)
[14:51] <charles> good question, I don't know. larsu?
[14:52] <larsu> charles: no clue, but you should be able to reproduce it with the loader (it includes the greeter profile)
[14:53] <mdeslaur> here;s my log, fwiw: http://paste.ubuntu.com/7359836/
[14:53] <mdeslaur> larsu: the loader?
[14:54] <charles> that's a good thought
[14:54] <charles> mdeslaur, install libindicator3-tools and try running "indicator-loader3 com.canonical.indicator.datetime"
[14:54] <charles> and see if that crashes or ont
[14:55] <mdeslaur> ok, one sec
[14:55] <charles> indicator-loader3 will show you all the profiles' menus for a service
[14:55] <charles> so if that crashes too, it's a quick way to get a stacktrace
[14:57] <mdeslaur> oh, that<s pretty cool
[14:58] <larsu> mdeslaur: rather  /usr/lib/x86_64-linux-gnu/indicator-loader3 /usr/share/unity/indicators/com.canonical.indicator.datetime
[14:58] <larsu> I can't reproduce it here, though
[14:58] <larsu> ah, maybe because I don't have e-d-s set up
[14:58] <mdeslaur> apt-get install evolution
[14:58] <larsu> ya ... still can't reproduce
[14:59] <mdeslaur> hrm, how do I make it load my updated package...
[14:59] <Trevinho> seb128: hi
[15:00] <larsu> seb128: he's out doing exersise
[15:00] <larsu> *exercise
[15:00] <Trevinho> larsu: ah, ok thanks
[15:01] <mdeslaur> ah! got it
[15:04] <larsu> can you reproduce the crash?
[15:05] <mlankhorst> xnox: ?
[15:05] <larsu> charles: from the rough stacktrace in mdeslaur's paste, it looks like one of the qdata is set incorrectly
[15:05] <larsu> qdata uses g_data_list
[15:07] <xnox> mlankhorst: moved on to debugging efibootmgr instead =)
[15:09] <mdeslaur> larsu: I can, yes, by double-clicking a date in the calendar...I'm trying to get a proper backtrace now
[15:11] <charles> larsu, that's plausible from the log, but at first read I don't see how we get to a qdata error from that diff -- it's not using qdata directly, nor indirectly with strings
[15:11] <mdeslaur> this isn't helpful at all: http://paste.ubuntu.com/7359979/
[15:11] <Laney> aww, was diffing e-d-s against the wrong left version
[15:11] <larsu> charles: yes it is, it calls set_data_full for activation-action and selection-action
[15:11] <Laney> "holy shit, this can be a sync?"
[15:16] <mdeslaur> larsu: what calls set_data_full for activation-action?
[15:16] <charles> mdeslaur, so you're getting this by applying http://bazaar.launchpad.net/~indicator-applet-developers/indicator-datetime/trunk.13.10/revision/282 to Saucy, yes?
[15:16] <mlankhorst> seb128: I might not make the meeting, in that case: testing vt switching and filing/fixing bugs related to it. investigating some touch bugs, fixing bug 1301839, some upstream kernel work
[15:16] <ubot2> Launchpad bug 1301839 in xserver-xorg-video-intel (Ubuntu) "AMD Radeon HD 8670A/8670M/8690M[1002:6660] Low-graphic mode with Trusty" [Undecided,Confirmed] https://launchpad.net/bugs/1301839
[15:16] <mlankhorst> and bug 1313986
[15:16] <ubot2> Launchpad bug 1313986 in linux (Ubuntu) "[GeForce 9400 GT] Nouveau driver does not work with kernel 3.13.0-24 (Ubuntu 14.04)" [Undecided,Incomplete] https://launchpad.net/bugs/1313986
[15:16] <mdeslaur> charles: yes, and running in the greeter
[15:16] <larsu> mdeslaur: http://bazaar.launchpad.net/~indicator-applet-developers/ido/trunk.14.04/view/head:/src/idocalendarmenuitem.c#L623
[15:16] <charles> mdeslaur, and using that formula you're also getting the crash in indicator-loader3?
[15:17] <mdeslaur> charles: yes, I had to log into my session, update my datetime packages, kill the datetime daemon in my session, and then use indicator-loader3
[15:18] <mdeslaur> charles: indicator-loader3 crashes when I select the greeter one, and then double click on a date or two
[15:18] <charles> mdeslaur, ok I'll try to reproduce here
[15:18] <charles> larsu, good point about set_data_full there
[15:19] <charles> so you're right, we are using qdata, I wasn't thinking of ido
[15:19] <charles> but the crash shows it is coming from inside libgtk, so that makes sense
[15:20] <larsu> you set the qdata on a widget and the crash happens when it is destroyed
[15:20] <mdeslaur> charles: fyi, I did this during testing earlier just to see: http://paste.ubuntu.com/7359767/
[15:21] <brookswarner> KombuchaKip - you here for Desktop meeting?
[15:26] <seb128> Trevinho, hey
[15:27] <Trevinho> seb128: Hi!
[15:27] <Trevinho> I was wondering ... since https://code.launchpad.net/~3v1n0/unity/lockscreen-keys-disable/+merge/217528 is in archive trough the mdeslaur's distro patch, can we now manually sync trunk merging that?
[15:29] <seb128> Trevinho, why manually? didn't you merge back when you landed it?
[15:29] <seb128> Trevinho, is it still in a silo ?
[15:29] <seb128> in which case you can m&c the silo
[15:30] <seb128> oh, it's meeting time
[15:30] <Trevinho> seb128: well, bregma is not here this week thus we (as a team) don't have any way to get a silo
[15:30] <Trevinho> seb128: mh, ok, talk later
[15:31] <seb128> qengho, Sweetshark_gc, mlankhorst, Laney, tkamppeter, desrt, attente, larsu, kenvandine: hey, it's meeting time!
[15:31]  * Sweetshark_gc readjusts his beach towel.
[15:31] <tkamppeter> seb128, can I start this time, as I have to leave earlier.
[15:31] <charles> mdeslaur, which branch should I try applying that patch to, in order to re-create the crash?
[15:31] <desrt> OMeetinG
[15:31] <seb128> tkamppeter, sure, go ahead
[15:32] <tkamppeter> - Installed Utopic on one machine for development
[15:32] <tkamppeter> - cups-filters: Released 1.0.53 with several security fixes
[15:32] <tkamppeter> - ghostscript: Fix to make it work when incompatible fonts are installed
[15:32] <tkamppeter> - system-config-printer: Suppress running HPLIP checks on non-HP printers
[15:32] <tkamppeter> - HPLIP: Fix for HP OfficeJet Pro K550 which is EOL at HP.
[15:32] <tkamppeter> - Bugs.
[15:32]  * qengho grumbles.
[15:32] <mdeslaur> charles: the package in saucy...I don<t think there;s a branch for it
[15:32] <desrt> mdeslaur: (meeting)
[15:33] <seb128> tkamppeter, did you find anyone to ping about the libspecte/ghostscript issue?
[15:34] <kenvandine> hey seb128, sorry i'm in a call atm
[15:34] <seb128> kenvandine, no worry, some time before your turn, or you can skip if needed
[15:35] <tkamppeter> seb128, I have looked into it, it is definitely not Ghostscript, but for sure libspectre. So we have to wait for Marek Kasik to comment on the Freedesktop bug. I have commented on the LP bug.
[15:35] <seb128> ok
[15:35] <KombuchaKip> brookswarner: I'm here buddy. I'm always idling in here.
[15:35] <seb128> tkamppeter, do you have contacts with marek? maybe you could try pinging him?
[15:36] <seb128> tkamppeter, thanks for looking to the issue in any case
[15:36] <tkamppeter> seb128, yes, I will send an e-mail directly to him then.
[15:36] <seb128> tkamppeter, thanks
[15:36] <seb128> ok, next is qengho
[15:36] <seb128> qengho, hey
[15:36] <qengho> Hey!
[15:37] <qengho> - in-progress: Fixing the problems aura brings to chromium, one at a time: horiz
[15:37] <qengho> ontal scroll, widget placement when DPI adjusted, menu sensitivity
[15:37] <qengho> - to-do: tab screwwyness bug.
[15:37] <qengho> - in-progress: Trying to get 34.0.1847.131 out, which should fix a few bugs. (This week's way upstream makes my life interesting: Deprecating make as build tool.)
[15:37] <qengho> EOF
[15:37] <KombuchaKip> seb128: If you or anybody else would like to test my upstream patch for Mozilla Thunderbird, that would be awesome. https://bugzilla.mozilla.org/show_bug.cgi?id=824909
[15:37] <ubot2> Mozilla bug 824909 in OS Integration "can't print .eml files - print preview remains blank" [Normal,Assigned]
[15:37] <seb128> KombuchaKip, hum, please wait for your turn ;-)
[15:38] <seb128> qengho, do you know if the update fixes the "loose tabs from the session/mix order" issue?
[15:38] <qengho> seb128: I don't know if it does.
[15:38] <seb128> ok
[15:38] <charles> mdeslaur, what command line would I use in Trusty to get the version of i-datetime that you're patching against?
[15:38] <seb128> I guess it's not the only bug on your list ;-)
[15:39] <seb128> charles, (we are in a meeting, please use the other channel where we moved the discussion)
[15:39] <charles> ack
[15:39] <seb128> thanks
[15:39] <seb128> qengho, thanks
[15:39] <seb128> mlankhorst, there?
[15:40] <KombuchaKip> seb128: Yeah man, I can imagine. Bugs galore.
[15:40] <seb128> ok, he said he might not be there anymore
[15:40] <seb128> his status update was
[15:40] <seb128> " I might not make the meeting, in that case: testing vt switching and filing/fixing bugs related to it. investigating some touch bugs, fixing bug 1301839, some upstream kernel work
[15:40] <ubot2> Launchpad bug 1301839 in xserver-xorg-video-intel (Ubuntu) "AMD Radeon HD 8670A/8670M/8690M[1002:6660] Low-graphic mode with Trusty" [Undecided,Confirmed] https://launchpad.net/bugs/1301839
[15:40] <seb128> and bug 1313986
[15:40] <seb128> "
[15:40] <ubot2> Launchpad bug 1313986 in linux (Ubuntu) "[GeForce 9400 GT] Nouveau driver does not work with kernel 3.13.0-24 (Ubuntu 14.04)" [Undecided,Incomplete] https://launchpad.net/bugs/1313986
[15:41] <seb128> ok
[15:41] <seb128> Sweetshark_gc, you are next ;-)
[15:41] <Sweetshark_gc> - LibreOffice Hackfest Las Palmas 2014 https://wiki.documentfoundation.org/Hackfest/GranCanaria2014
[15:41] <Sweetshark_gc> -- lightning talks in front of students
[15:41] <Sweetshark_gc> -- wrote a unittest for writer
[15:41] <Sweetshark_gc> -- investigated mail merge wizard issues, unfortunately quite a mess
[15:41] <Sweetshark_gc> -- various meetings
[15:41] <Sweetshark_gc> - TDF administrative stuff
[15:41] <Sweetshark_gc> - various mails and coordination
[15:41] <Sweetshark_gc> - now back to that LibreOffice unity menu issue :/
[15:41] <Sweetshark_gc> EOF
[15:41] <seb128> Sweetshark_gc, when do you fly back?
[15:42] <Sweetshark_gc> next wednesday. Ill take friday of and thursday is labour day, so three more work days.
[15:43] <Sweetshark_gc> I hope to find an opportunity to catch up with the aentos guys (who wrote the unity integration stuff) for dinner or something still ...
[15:43] <seb128> ok
[15:43] <seb128> have fun there!
[15:43] <seb128> (same in France btw, thursday is off)
[15:44] <Laney> :o
[15:44] <seb128> good luck for the menus issue as well, let me know when you get a fix, seems like a SRU topic
[15:44] <larsu> (same in Germany, but I'll be at the hackfest anyway)
[15:44] <seb128> Sweetshark_gc, thanks
[15:44] <seb128> Laney, your turn
[15:44] <Laney> • distro-info patch / discussions to not fail so hard when the info gets out of date (due to not having a codename on release day which happens every time now)
[15:44] <Laney> • webkit SRU / update
[15:44] <Laney> • gstreamer SRU / update
[15:44] <Laney> • apport SRU for str vs bytes bug in precise
[15:44] <Laney> • Update vala to 0.24 & make it the default
[15:44] <Laney> • Various merges and syncs from merges.u.c, including (prepared, not uploaded) cheese 3.12 with de-headerbarification patch
[15:44] <Laney> • Discussions / testing an upstart job for gnome-keyring to resolve the races (others please test the package in U)
[15:44] <Laney> • Start looking at e-d-s 3.12
[15:44] <Laney> • Brief systemd test, basically boots a system but my /e/n/i interfaces didn't come up :(
[15:44] <Laney> ⚠
[15:45] <Laney> oh I'm off Monday and Tuesday (to continue the holidays theme)
[15:45] <seb128> Laney, I saw your cheese patches got commited upstream, good job ;-)
[15:46] <Laney> ya, amigadave is a good guy
[15:46] <seb128> Laney, the 1st is not a bank holiday in the u.k?
[15:46] <Laney> no
[15:46] <Laney> monday is though
[15:46] <ogra_> weirdos
[15:46] <ogra_> :P
[15:46] <Laney> 'early may bank holiday'
[15:46] <seb128> k
[15:47] <seb128> enjoy that one ;-)
[15:47] <ogra_> go with the rest of the world :)
[15:47] <seb128> Laney, thanks
[15:47] <seb128> desrt, your turn
[15:47] <desrt> hihi
[15:47] <desrt> in berlin this week for the gtk hackfest
[15:48] <Laney> they moved it from may 1st, don't know why (some places like schools have festivities on that day anyway)
[15:48] <desrt> did some work on adding support for horizontal rows of buttons in gmenumodel -- made sure we have a good fallback for if we try to display it in a normal menu
[15:48] <desrt> (ie: we make it as a section with a hint -- if we don't support the hint, we will just display the items normally)
[15:48] <desrt> did some work on better reporting of invalid dbus messages (due to bugs in gmenumodel client that were crashing hud)
[15:48] <desrt> also added support for Implements= in gdesktopappinfo
[15:49] <desrt> the usual bug fixing, etc.
[15:49] <desrt> oh... spent some time looking into the issues about headerbar/csd and resizing under compiz
[15:49] <desrt> this stuff is pretty complicated, but there is at least a partial gtk bug here... but it has nothing to do with the resizing
[15:50] <desrt> it seems that compiz doesn't support resize on windows with borders but no headerbar.... and that's a really really old hint that we ought to support
[15:50] <desrt> Trevinho: i think you said you might be able to help here?
[15:51] <desrt> maybe not.  that's all.
[15:51] <seb128> let's keep the discussion with Trevinho as an after meeting topic
[15:51] <Trevinho> desrt: yes, it's all in unity's DecoratedWindow code
[15:52] <seb128> I would like to discuss a bit GTK/GNOME updates at the end of the meeting anyway
[15:52] <seb128> desrt, thanks
[15:52] <seb128> attente, hey
[15:52] <larsu> update all the things \o/
[15:52] <desrt> larsu: s/all/ALL/
[15:52] <larsu> not that many...
[15:52] <Laney> I already almost typoed a couple of times
[15:52] <attente> seb128, hi
[15:53] <Laney> luckily I typoed ppa:laney/u-merges instead of ubuntu
[15:53] <desrt> Laney is fishing for beer in malta...
[15:53] <Laney> baa
[15:53]  * larsu would definitely chime in on beer for Laney
[15:53] <attente> i spent more time debugging eclipse menus, uploaded to a ppa
[15:53] <larsu> *chip in
[15:54] <attente> also looked into non-latin shortcuts for java/inkscape/blender
[15:55] <attente> i uploaded that to a ppa, but it breaks keyboard layout switching under gnome-shell, and causes regressions under unity if the layout switcher is set to shift
[15:56] <seb128> do you need more testers for some of those?
[15:56] <larsu> some russian testers?
[15:57] <attente> i think the eclipse fix is ok, but really need to figure out what's happening for the non-latin shortcuts
[15:57] <desrt> attente: gtk does some internal mapping to figure out the equivalent latin code
[15:58] <desrt> depending on the set of all installed keymaps
[15:58] <desrt> i had to track this down back in the day when i wrote that altgrabber stuff...
[15:58] <attente> desrt, yeah
[15:58] <attente> but this is for java/inkscape/blender
[15:58] <attente> which are all assuming a latin keyboard group 0
[15:58] <desrt> so even if you're in english mode your hebrew shortcuts will work for menus written in hebrew, based on which physical key you press
[15:58] <seb128> same issue as libreoffice?
[15:58] <attente> seb128, yes
[15:58] <seb128> shrug
[15:58] <desrt> ah.  tricky.
[15:59] <seb128> some days I hate those GNOME changes
[15:59] <attente> so i just swapped the order
[15:59] <attente> in u-s-d and g-s-d
[15:59] <seb128> things were much easier/robust when we were using xkb
[15:59] <attente> in g-s-d this works, but breaks the xkb grp: option
[15:59] <desrt> seb128: you only hate gnome changes on _some_ days? :)
[15:59] <larsu> only on days ending in '-day'
[15:59] <seb128> ;-)
[15:59] <desrt> larsu: and wednesday
[15:59] <attente> in u-s-d this works, unless you set your switching shortcut to left shift right shift, or both
[16:00] <seb128> shift+something you mean?
[16:00] <attente> seb128, well. to be more accurate, it causes a regression where you cannot type capital letters in the non-latin layout
[16:01] <seb128> that seems annoying indeed
[16:01] <attente> ppa is here: https://launchpad.net/~attente/+archive/java-non-latin-shortcuts
[16:02] <seb128> in the libreoffice bug Rui (the GNOME guy who did the changes) basically said that libreoffice needs to be "fixed" to not assume that group 0 is a latin keyboard
[16:02] <seb128> so might be that we need to "fix" java as well?
[16:02] <attente> i think that's unrealistic to patch every package doing this
[16:02] <seb128> attente, what's the approach you are taking to try to make it work?
[16:03] <seb128> right, I think so too
[16:03] <attente> seb128, basically reversing the order as set by g/u-s-d
[16:03] <seb128> which is why I'm unhappy about those GNOME changes :/
[16:03] <seb128> to have a latin back in group 0?
[16:03] <attente> so instead of ru,us, you get us,ru
[16:03] <attente> seb128, yes
[16:03] <seb128> why does that create issues for shift?
[16:04] <attente> if you set your keyboard layout switcher to shift
[16:05] <desrt> maybe details for later?
[16:05] <attente> unity grabs that so that it can do a modifier-only grab on shift-<random character>
[16:05] <larsu> +1
[16:05] <seb128> yes, I was starting thinkg that
[16:05] <attente> yeah...
[16:05] <attente> sorry
[16:05] <seb128> no worry, I'm asking for some details because we have everybody around
[16:05] <seb128> which includes desrt
[16:05] <larsu> right
[16:05] <seb128> but I guess we can discuss that again later
[16:05] <seb128> attente, thanks
[16:05] <desrt> LARSU
[16:06] <desrt> GO!
[16:06] <seb128> larsu, your turn
[16:06]  * larsu doesn't listen to anyone but seb128 
[16:06] <larsu> oh. shit.
[16:06] <seb128> lol
[16:06] <larsu> it was a bug fixing week again
[16:06] <larsu> some minor evince issues (some accels stopped working after the gmenu port)
[16:07] <larsu> some playing around with the sound widgets in ido
[16:07] <larsu> which is getting SRUed
[16:07] <seb128> did you stack those evince fixes/did them in the same branch btw?
[16:07] <desrt> larsu: we're getting a slider in upstream gmenumodel soon.  i'd like your input there.
[16:07] <seb128> I've those on my list of things to look at/land
[16:07] <larsu> seb128: no, they're in different branches but should be fairly independent
[16:08] <larsu> let me know if they don't merge cleanly
[16:08] <seb128> ok, good
[16:08] <larsu> desrt: yes, let's talk about that later though
[16:08] <desrt> ofc
[16:08] <larsu> also, gmenumodel was crahsing for the hud when the hud sent invalid dbus messages to it
[16:08] <larsu> I added some input validation checks
[16:09] <larsu> (desrt was talking about this too, he added g_dbus_warning() for this reason)
[16:09] <desrt> larsu: if you review g_dbus_warning() i'll review your stuff that uses it :p
[16:09] <larsu> will do
[16:09] <larsu> had some conversations with desrt about the headerbar issue
[16:10] <larsu> I think that's about it... crazy week with lots of small things
[16:11] <seb128> larsu, thanks
[16:11] <seb128> kenvandine, there?
[16:12] <seb128> likely not
[16:12] <seb128> so my turn
[16:12] <seb128>  * spent most of the week in launchpad, reading the bugs filed after release/triaging/targetting the ones to SRU
[16:12] <seb128>  * did some SRUs (empathy, rhythmbox)
[16:12] <seb128>  * helped testing some other SRUs
[16:12] <seb128>  * some debugging (valgrined xorg for touch/xserver segfault issues)
[16:12] <seb128>  * quite some IRC discussions (gtkheaderbar, new gnome-desktop, GNOME updates)

[16:12] <vedic> Which gui do you recommend? I have tried xfce4 but I think I need a bit better but light as well. xfce4 is light but I need a bit better
[16:13] <seb128> KombuchaKip, oh, sorry I almost forgot you ... you had something to share I think
[16:13] <desrt> vedic: (desktop team meeting in progress right now, sorry)
[16:13] <seb128> vedic, hey, try #ubuntu for user questions
[16:13] <KombuchaKip> seb128: Hey man. No problem. Yes, a patch. https://bugzilla.mozilla.org/show_bug.cgi?id=824909
[16:13] <ubot2> Mozilla bug 824909 in OS Integration "can't print .eml files - print preview remains blank" [Normal,Assigned]
[16:13] <seb128> did you manage to get it in a ppa for testing?
[16:14] <vedic> seb128,, desrt: Ok. Thanks
[16:14] <seb128> KombuchaKip, did you manage to get it in a ppa for testing?
[16:15] <KombuchaKip> seb128: No not going to do that yet until upstream accepts it. Then I'll build a PPA, and then I'll SRU it.
[16:15] <seb128> ok
[16:15] <KombuchaKip> seb128: Otherwise there is no point in going through all of that if upstream says it's no good.
[16:15] <seb128> well, if upstream accept it/merge it you probably don't need to SRU
[16:15] <seb128> we security update new versions
[16:15] <seb128> right
[16:15] <KombuchaKip> seb128: Yep
[16:16] <seb128> good luck with that, seems like they have been busy with releases but have it on their review list
[16:16] <seb128> KombuchaKip, thanks
[16:16] <desrt> and back to seb
[16:16] <seb128> ok, so end of roundtable
[16:16] <larsu> GNOME!
[16:16] <seb128> let's discuss GNOME updates
[16:16] <larsu> glib: yes. gtk: yes.
[16:16] <desrt> i know larsu's opinion
[16:16] <KombuchaKip> seb128: No problem. So far they seem agreeable upstream and I can't see why they'd turn it down. Looks like there isn't much being done on Thunderbird these days, so you'd think they'd take it.
[16:16] <larsu> I know desrt's.
[16:16] <seb128> desrt, what is planned in glib this cycle ?
[16:16] <larsu> GWallclock
[16:17] <desrt> seb128: nothing major
[16:17] <larsu> EggObjectList *cough*
[16:17] <desrt> probably will get the mainloop done this cycle...
[16:17] <seb128> desrt, same as usual anyway, should be stable and if it's not you are there to fix the issues, right?
[16:17] <desrt> in terms of new APIs.... it seems quiet right now
[16:17] <larsu> desktop file cache?
[16:17] <desrt> things have moved back to gtk hacking more...
[16:17] <desrt> larsu: ya.. maybe this as well, but again, not new API
[16:17] <larsu> right
[16:17] <seb128> ok
[16:17] <desrt> seb128: ya.... glib is pretty low-risk, for sure
[16:17] <seb128> so glib 2.41/42: ack
[16:18] <desrt> can't speak to gtk yet... i suspect we will know more after this week
[16:18] <seb128> gtk 3.12: ack
[16:18] <larsu> I think we should get the new gtk. I suspect that we can get rid of a lot of the background hacks I've had to put into the theme
[16:18] <seb128> (seems to be easy, still need some testing before landing though)
[16:18] <larsu> because 3.12 has the unified drawing stuff
[16:18] <seb128> larsu, new = 3.12 right?
[16:18] <desrt> pixelcache++
[16:18] <larsu> I'll find this out in the next days
[16:18] <seb128> not 3.13
[16:18] <larsu> seb128: yes
[16:18] <seb128> +1 for that
[16:18] <larsu> we'll bother you about 3.13 once 3.12 is in+
[16:18] <seb128> I plan to throw it to the desktop team ppa for some extra testing first
[16:18] <seb128> right
[16:18] <larsu> great
[16:19] <seb128> let's settle down on the Debian merges, etc first
[16:19] <larsu> I've been running it for a while today and it seems to cause no major issues
[16:19] <desrt> would be nice to follow unstable with the base libraries as well
[16:19] <Laney> we'll need to keep an eye on dialog widths
[16:19] <seb128> then we can discuss 3.13 maybe
[16:19] <desrt> but maybe wait for the second half of the cycle
[16:19] <Laney> and I think there's something with dialog headers too
[16:19] <desrt> soup, dconf, gvfs, etc, etc
[16:19] <seb128> right
[16:19] <larsu> Laney: yes, dialog headers are client-side now
[16:19] <larsu> which is stupid, but I wouldn't consider it a major issue
[16:19] <Laney> isn't there a gtksetting for it?
[16:19] <larsu> there should be ya
[16:19] <desrt> there may be some things we find upsetting about the new gtkdialog behaviours
[16:20] <desrt> like how the buttons are in message dialogs now... kinda ugly imho
[16:20] <desrt> they fill the entire bottom of the dialog
[16:20] <larsu> isn't that fixable with css?
[16:20] <desrt> i doubt it...
[16:20] <desrt> there is only limited control over sizing from css...
[16:20] <desrt> stuff like padding/margins/etc
[16:20] <larsu> margin?
[16:20] <larsu> now there's no margin - setting one should put the buttons back to were they where, no?
[16:21] <seb128> is that in 3.12 ? do we have an example/screenshot of what we are talking about?
[16:21] <desrt> no...
[16:21] <larsu> anyhow, we can have a look
[16:21] <desrt> https://wiki.gnome.org/Design/HIG/Dialogs has mockups
[16:21] <desrt> pretty much looks like this
[16:22] <seb128> k
[16:22] <seb128> well anyway let's get the new gtk in the ppa and see how things are going with it
[16:22] <desrt> http://blogs.gnome.org/mclasen/files/2014/03/gedit-messagedialog.png is the real deal
[16:22] <desrt> not so nice....
[16:22] <seb128> urg, indeed not
[16:22] <desrt> probably not too difficult to fix, but it would be some patching
[16:22] <desrt> not just theme
[16:22] <larsu> who's idea was that anyway?
[16:23] <desrt> designers
[16:23] <seb128> yeah, and "why"?
[16:23] <desrt> seb128: nfc.
[16:23] <seb128> but yeah, I think we need to fix that
[16:23] <larsu> well, it's 3.13 material
[16:23] <seb128> with some luck they get feedback that make them reconsider it
[16:23] <larsu> let's fix it when we get therew
[16:23] <seb128> +1
[16:23] <seb128> larsu, but are you sure?
[16:24] <seb128> larsu, that screenshot has "for 3.12" written in the gedit in the screenshot
[16:24] <larsu> oh, might be ya
[16:24] <larsu> we need to fix it, then :D
[16:24] <seb128> agreed
[16:24] <seb128> ok
[16:24] <seb128> so glib->2.42
[16:24] <seb128> gtk->3.12
[16:24] <desrt> also note: the other things get turned off via xsettings
[16:24] <desrt> so the headerbar dialogs will not be on on unity, by default
[16:25] <seb128> likely going to update gvfs/libsoup/librsvg/gdk-pixbuf/g-i as usual
[16:25] <larsu> they are right now though
[16:25] <seb128> headerbar dialog default to off iirc
[16:25] <larsu> seb128: the buttons are in the bottom, but the titlebar is still csd
[16:25] <desrt> ya... we had quite an argument about this
[16:25] <larsu> something messed up there
[16:25] <larsu> *is
[16:26] <seb128> k, something to watch for
[16:26] <seb128> so summary
[16:26] <seb128> * glib->2.42, gtk->3.12
[16:26] <seb128> * likely going to update gvfs/libsoup/librsvg/gdk-pixbuf/g-i as usual
[16:26] <seb128> * desrt/larsu/Trevinho working on make csd work better under Unity
[16:26] <desrt> i'll chat with benjamin tomorrow about that
[16:27] <seb128> we are waiting on the outcome of ^ to determine what to do with apps
[16:27] <desrt> LIM is problematic...
[16:27] <Laney> what about the apps we de-csded?
[16:27] <seb128> default would be to update to 3.12/merge with Debian for things not using GtkHeaderBar
[16:27] <desrt> seb128: not too many more of those around...
[16:27] <seb128> let's stay away from adding GtkHeaderBar uses until we know better where we stand
[16:27] <seb128> Laney, like?
[16:28] <seb128> Laney, well, as said ^, I would suggest staying away from CSD until we have a better idea on how well it works
[16:28] <seb128> desrt has a good point with LIM
[16:28] <Laney> yes, for apps where it's not a problem
[16:28] <Laney> like evolution
[16:28] <seb128> Laney, it is a problem for evolution?
[16:28] <larsu> we could have LIM with csd - we wouldn't even need dbus!
[16:29] <desrt> putting the 'local' in LIM
[16:29]  * desrt likes it
[16:29] <larsu> LLIM
[16:29] <larsu> locally locally integrated menus
[16:29]  * desrt llikes it
[16:29] <seb128> larsu, not consistent with LIM in other apps though
[16:29] <larsu> seb128: it woudld be visually
[16:29] <seb128> like display on mouseover?
[16:29] <larsu> *it could be
[16:29] <larsu> seb128: well, we'd need to add code for that obviously
[16:29] <desrt> seb128: dunno if you notice but anything is possible in gtk these days :p
[16:30] <seb128> lol
[16:30] <larsu> except setting multiple accels for an action
[16:30] <seb128> well, one thing at the time
[16:30] <Laney> is it?
[16:30] <seb128> let's get CSD working in Unity first
[16:30] <desrt> larsu: i said 'these days', not 'last year'
[16:30] <larsu> desrt: 'last year' is what we have in ubuntu though
[16:30] <desrt> s/CSD/resizing of windows with no titlebars/
[16:31] <seb128> well, we also need to have a non duplicated decoration
[16:31] <desrt> ya... this is the motif hint
[16:31] <desrt> you can request a border (ie: resizable) but not a titlebar
[16:31] <desrt> this is the one that falls all over the place
[16:31] <desrt> in unity this means you get neither
[16:31] <larsu> compiz needs to get with the times! Think of all the motif apps not working
[16:31] <desrt> in kde/xfce you get both
[16:32] <desrt> anyway.... won't change the world
[16:33] <seb128> k
[16:33] <larsu> this meeting is getting longer than it used to be
[16:33] <seb128> well, we know what to work on/have enough decided to start the cycle
[16:33] <larsu> right
[16:33] <seb128> larsu, well, over 1h is wrong for sure
[16:34] <seb128> but we had the extra topic
[16:34] <seb128> so let's wrap there
[16:34] <seb128> we can discuss more specifics/updates later in the cycle
[16:34] <larsu> ya, not complaining, just observing
[16:34] <seb128> there is a vUDS in june as well
[16:34] <desrt> (it's not true.  he was complaining.)
[16:34] <seb128> we should have enough to keep busy until there
[16:34] <larsu> (desrt is lying)
[16:34] <desrt> i think we're done :)
[16:34] <desrt> i'll buy larsu an icecream to make him happy
[16:34] <larsu> \o/
[16:34] <seb128> larsu wants his kebab
[16:35] <larsu> not now
[16:35] <seb128> ;-)
[16:35] <seb128> Laney, did you have anything more you wanted to discuss there?
[16:35] <attente> so... about the java/inkscape/blender shortcuts...
[16:35] <Laney> not really, if non-headerbar apps are ok to update to
[16:35] <seb128> Laney, or is the "let's update glib/gtk, deal with Debian merges, make csd work better" then figure out what we do next a good start of cycle plan for you?
[16:35] <seb128> yes
[16:36] <seb128> let's stay away from adding for headerbars until we work more on that
[16:36] <seb128> but everything else is fine to go 3.12
[16:36] <Laney> ok
[16:36] <seb128> thanks everyone
[16:36] <seb128> desrt, larsu: please help attente!
[16:36] <Laney> we should maybe work on empathy/telepathy/IM at some point ;-)
[16:36] <seb128> attente, I'm unsure if you were trolling them btw :p
[16:36] <attente> lol
[16:36] <Laney> (or use pidgin)
[16:37] <seb128> Laney, use pidgin!
[16:37] <desrt> larsu has already closed his laptop, with prejudice
[16:38] <attente> seb128, about the eclipse fix, i think it's ok for an sru
[16:38] <attente> well, unity-gtk-module fix for eclipse
[16:38] <seb128> attente, did you mp it already ?
[16:38] <attente> seb128, https://code.launchpad.net/~attente/unity-gtk-module/1208019-2/+merge/216964
[16:40] <seb128> attente, thanks
[16:40] <seb128> desrt, larsu, charles, tedg: ^ can you review that one?
[16:40] <seb128> in looks fine to me in principle
[16:40] <Laney> seb128: are you going to upload that 3.12 to the desktop ppa?
[16:41] <seb128> Laney, yes, but probably not this week, rather next (since thursday is an holiday and I'm taking friday off)
[16:41] <desrt> seb128: larsu and i are just about to head out for respective dinner dates
[16:41] <Laney> ok i'll upload it to u-merges then
[16:41] <seb128> Laney, if you want to do it feel free
[16:41] <Laney> not going to review the diff right now
[16:41] <Laney> I just want it atm to build some stuff
[16:42] <seb128> Laney, u-merges?
[16:42] <Laney> my 'u' testing ppa
[16:42] <seb128> desrt, larsu: have fun!
[16:42] <seb128> Laney, oh, ok
[16:50] <ogra_> oh man ... this pile of lockscreen bugs is a PR disaster
[16:51] <Laney> erm
[16:51] <ogra_> (is there any key combo that doesnt let you bypass the lock ? )
[16:51] <Laney> trolling?
[16:51] <ogra_> every time i open a new news site there was a new one found in LP ... and they pick on all of them
[16:52] <ogra_> Laney, nope
[16:52] <ogra_> alt-f2 ... not ctrl-alt-t
[16:52] <ogra_> s/not/now/
[16:52] <seb128> ogra_, it's 1 bug
[16:53] <ogra_> is it ?
[16:53] <seb128> yes
[16:53] <ogra_> bug 1313885 suggests ctrl-alt-t is new
[16:53] <ubot2> Launchpad bug 1313885 in unity (Ubuntu Utopic) "lock screen bypass" [Critical,In progress] https://launchpad.net/bugs/1313885
[16:53] <seb128> ogra_, it's the same issue
[16:54] <ogra_> but a different fix ?
[16:54] <seb128> ogra_, it's "by playing with indicator you can end up having the keyboard focus in the session"
[16:54] <seb128> no
[16:54] <ogra_> ah, k
[16:54] <seb128> the fix is buggy/incomplete
[16:54] <seb128> you can still end up with the keyboard going to the session
[16:54] <seb128> which let you do "keybinding of your choice"
[16:55] <ogra_> well, in any case news pages seem to love to pick it up
[16:56] <seb128> well, nothing we can't do about that, out of fixing the issues
[16:56] <seb128> can't->can
[16:57] <seb128> ogra_, stop reading so much "news" sites
[16:57] <mdeslaur> ogra_: feel free to send this list of bugs to the news sites: https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver?field.searchtext=&orderby=-datecreated
[16:59] <ogra_> seb128, lol
[17:00] <Laney> It's what you get if you do everything in the open
[17:00] <ogra_> mdeslaur, after fighting with two reporters for half the night about bug 1308572 i gave up doing such stuff
[17:00] <ubot2> Launchpad bug 1308572 in unity (Ubuntu) "Ubuntu 14.04: security problem in the lock screen" [Critical,Fix released] https://launchpad.net/bugs/1308572
[17:01] <ogra_> they nicely reported it as present in the release in their news
[17:01] <mdeslaur> ogra_: apparently reporting about bugs that are already fixed doesn't bring readers :)
[17:02] <ogra_> mdeslaur, "Ubuntu 14.04 released with serious lockscreen bug !!!111oneone" makes a wonderful clickbait headline
[17:03] <Laney> I wouldn't get worked up about it
[17:03] <Laney> Bugs happen, they get fixed, we move on
[17:03] <ogra_> yeah
[17:03] <mdeslaur> ogra_: I publish 2-5 USNs every single week, they do realize there are a constant flow of security issues, right? :)
[17:04] <Laney> If someone wants to make a few cents writing about them then that's up them as far as I'm concerned
[17:04] <Laney> it's not worth getting distracted over
[17:04] <mdeslaur> anyway, /me goes back to work
[17:05] <ogra_> mdeslaur, i would expect they do ... after all its the biggest german security news site ... (though i would also expect some serious research from them, its the first time i see them doing such a clickbait thing)
[18:28] <asac> with bregma being on vacation who would know something about how the unity8 session with mir works?
[18:28] <asac> on deslktop?
[18:28] <asac> and lightdm etc.
[19:01] <seb128> asac, mterry might be able to help you
[19:01]  * mterry looks up
[19:01] <mterry> I don't see scrollback
 with bregma being on vacation who would know something about how the unity8 session with mir works?
[19:02] <seb128>  on deslktop?
[19:02] <seb128>  and lightdm etc.
[19:02] <seb128> mterry, ^
[19:02] <mterry> asac, I might yeah
[19:02] <seb128> mterry, sorry, just random shoot, you seem like one of those who could know
[19:07] <tedg> larsu, I thought we had a signal for when a menu was shown if there was a special action defined, no?
[19:10] <asac> mterry: Saviq is already talking to stgraber  in -touch on this topic now... lets see if they figure it :)
[19:10] <Saviq> mterry, come to -touch, you'll definitely be helpful
[22:56] <larsu> tedg: we do, see the "submenu-action" section in https://wiki.gnome.org/Projects/GLib/GApplication/GMenuModel