[05:29] <pitti> Good morning
[09:01] <Laney> morning!
[09:01] <hyperair> evening!
[09:11] <seb128> good morning desktopers!
[09:11] <seb128> "On a positive note, the autopilot fix is in now, and ubuntu-system-settings was able to run all the tests"
[09:11] <seb128> \o/
[09:14] <Laney> nice!
[09:14] <Laney> hey seb128
[09:15] <seb128> hey Laney, how are you?
[09:16] <seb128> can you take the wet weather back? that rain is boring :/
[09:18] <Laney> quite nice here today ^_^
[09:20]  * larsu looks out the window
[09:20] <larsu> sunshine \o/
[09:20] <seb128> bah :p
[09:36] <Laney> BAH!
[09:36] <Laney> Feb 13 CD Image        ( 48K) LiveFS ubuntu/trusty/i386 failed to build on 20140213
[09:41] <Laney> unity-control-center-signon got NEWed to universe
[09:42] <seb128> Laney, there is no NEWing with the CI stuff
[09:42] <seb128> but yeah, it landed to universe, thanks for pointing it out
[09:42]  * seb128 fixes
[09:42] <TheMuso`> larsu: Is ido managed by CI? I see changes in teh branch that haven't been uploaded to the archive. In particular, I am awaiting the fix for bug #1242550.
[09:42] <ubot2`> Launchpad bug 1242550 in ido (Ubuntu) "indicator-sound keyboard controls with left/right ARROW keys broken" [High,Fix committed] https://launchpad.net/bugs/1242550
[09:42] <Laney> I'll still call it NEWing :-)
[09:42] <Laney> also, do you want to get these emails?
[09:42] <seb128> TheMuso`, it's under autolanding, I'm going to do a landing request for it
[09:42] <seb128> larsu, ^^
[09:42] <seb128> Laney, more email? no, thanks
[09:43] <Laney> the image failure ones are good usually
[09:43] <seb128> where do I subscribe/unsubscribe?
[09:43] <TheMuso`> seb128: Ok no worries. Just wasn't sure if it fell off the radar or not.
[09:43] <Laney> it's in some file
[09:43] <Laney> on the CD build server
[09:43] <larsu> wow, that hasn't landed in a while
[09:43] <seb128> indeed
[09:44] <larsu> are we getting autolanding for it now?
[09:44]  * seb128 misses the good old days where landing happened without you having to think
[09:44] <larsu> me too
[09:44] <seb128> larsu, "auto" in the sense of somebody needs to put a line on a gdoc
[09:44] <larsu> which is kind of what I still do tbj
[09:44] <larsu> *tbh
[09:44] <larsu> seb128: :-/
[09:44] <seb128> yeah, let's not argue over that
[09:44] <seb128> we just need to be careful and ask for landings
[09:44]  * seb128 adds one
[09:45] <larsu> thanks
[09:45] <seb128> I put one for the theme as well
[09:46] <seb128> Laney, done
[09:46] <Laney> ty
[11:44] <Sweetshark> seb128: hmmm, I just had a weird experience. With enabled trusty-proposed, I didnt get libreoffice (the meta pkg) with an 'apt-get update' causing all kinds of confusion as I then had 4.2.0-0ubuntu1 and 4.2.0~rc4-0ubuntu1 packages mixed. Manually downloading the *.deb as build in proposed worked fine though.
[11:44] <Sweetshark> I wonder what is happening there.
[11:45] <Sweetshark> all the other packages just came in with the update.
[11:45] <didrocks> mlankhorst: hey, from colin:
[11:45] <didrocks> 12:43:56 cjwatson | wonder why xorg-server/ppc64el just started failing to build with an array-bounds error
[11:45] <didrocks> 12:44:58 cjwatson | I've overridden the never-passed autopkgtest failure there, but ppc64el will need to be sorted out
[11:50] <popey> seb128: any suggestion where I should file this "my keyboard keeps switching to US" bug?
[11:54] <desrt> hi hi hackers
[12:07] <hikiko> hello could someone help me a little with a branch? I am doing something with GVariants and I get a strange seg fault in a place I shouldnt...
[12:08] <seb128> hikiko, hey, can you pastebin your code and the bt
[12:08] <seb128> desrt, good morning!
[12:08] <hikiko> sure thank you seb128
[12:09] <seb128> popey, uninstall ibus (I guess you don't use it) and see if it keeps happening?
[12:09] <seb128> popey, the indicator/GNOME stack didn't change recently, I doubt it's the xorg update so I would blame ibus
[12:09] <seb128> popey, did you notice a pattern on when it changes?
[12:09] <mlankhorst> didrocks: I have no idea, nothing in xorg-server changed afaics
[12:10] <didrocks> mlankhorst: colin is telling it never passed
[12:10] <seb128> Sweetshark, did the apt-get update work?
[12:10] <mlankhorst> oh that's fine then
[12:10] <popey> seb128: no, it appears randomly
[12:14] <hikiko> seb128, http://paste.ubuntu.com/6925189/
[12:15] <hikiko> I was trying to get the size of an array that contained 1 dictionary entry I should get 1
[12:16] <hikiko> the array seems correct it should have a dict entry with a string (LVDS1) as a key and an int value (9)
[12:17] <hikiko> seb128, if you need to run the code you need to install these gsettings too: bzr branch lp:~hikiko/gsettings-ubuntu-touch-schemas/new-schema-for-unity7-8
[12:25] <didrocks> mlankhorst: I don't think it's really fine, colin has to override everytime
[12:26] <Laney> umm
[12:26] <Laney> xorg has no autopkgtest, he's talking about the firefox one
[12:26] <seb128> hikiko, shouldn't you use "a{si}" for the signature?
[12:26] <Laney> don't ride mlankhorst for that
[12:27] <hikiko> in which place seb128 ?
[12:27] <seb128> hikiko, wait
[12:28] <seb128> larsu, desrt: can you help hikiko?
[12:29] <desrt> hikiko: this is your own code or code in someone else's program/library?
[12:29] <seb128> desrt, it's her code, http://bazaar.launchpad.net/~hikiko/unity-control-center/unity-control-center.per-monitor-fonts-scale-factor-slider/view/head:/panels/display/cc-display-panel.c#L647
[12:29] <seb128>   g_settings_get (self->priv->desktop_settings, "scale-factor", "a", &dict);
[12:29] <seb128> the corresponding schemas is
[12:29] <seb128> http://bazaar.launchpad.net/~hikiko/gsettings-ubuntu-touch-schemas/new-schema-for-unity7-8/revision/7
[12:29] <seb128>         <key name="scale-factor" type="a{si}">
[12:29] <seb128>  
[12:30] <seb128> desrt, she's hitting http://paste.ubuntu.com/6925189/
[12:30] <seb128> I guess the gvariant use is incorrect
[12:30] <hikiko> I am not sure let me try :)
[12:30] <larsu> hi
[12:30] <larsu> hikiko: do you have a full stacktrace?
[12:31] <Sweetshark> seb128: I did it again with a fresh VM -- everything went fine there.
[12:31] <seb128> Sweetshark, good
[12:31] <desrt> seb128: i saw that.... i'm wondering what the code looks like :)
[12:32] <desrt> thanks for the link
[12:32] <seb128> desrt, http://bazaar.launchpad.net/~hikiko/unity-control-center/unity-control-center.per-monitor-fonts-scale-factor-slider/view/head:/panels/display/cc-display-panel.c#L647
[12:32] <larsu> hikiko: nevermind, I read the scrollback
[12:32] <seb128> yw
[12:32] <desrt> hikiko: &a is for GVariantIter
[12:32] <hikiko> seb128, sec I think that was it just a sec to verify it
[12:32] <desrt> er.  'a' rather
[12:32] <desrt>   g_settings_get (self->priv->desktop_settings, "scale-factor", "a", &dict);
[12:32] <desrt> in this case you should have 'GVariantIter *dict'
[12:32] <larsu> desrt: morning :)
[12:33] <desrt> larsu: hi :D
[12:33] <hikiko> desrt, larsu and seb128 it was the a{si}
[12:33] <hikiko> I have other bugs too
[12:33] <hikiko> but I can solve them
[12:33] <hikiko> I think :)
[12:33] <seb128> hikiko, btw, looking at https://code.launchpad.net/~hikiko/unity-control-center/unity-control-center.per-monitor-fonts-scale-factor-slider/+merge/205227 ... the config parser thing is scary
[12:34] <hikiko> seb128, I ll remove this
[12:34] <seb128> good!
[12:34] <hikiko> I use the gvariant instead
[12:34] <desrt> hikiko: no... seriously... it's the g_settings_get() line that is the problem
[12:34] <desrt> "a" _does not_ work with GVariant*
[12:34] <desrt> and in fact, "a" is not a valid format string in any case
[12:34] <seb128> desrt, she said that she changed the "a" but "a(si)" there I think
[12:35] <hikiko> yes desrt I just found out that I should use a{si} like seb128 said
[12:35] <desrt> that won't fix it either, unfortunately
[12:35] <desrt> "a{si}" will still want to use a GVariantIter
[12:35] <desrt> if you want to use a GVariant* then try "@a{sv}"
[12:35] <desrt> or even better: dict = g_settings_get_value (...);
[12:36] <desrt> no need to guess in that case
[12:36] <hikiko> @a{sv} is not for string-string key-value pair?
[12:36] <meetingology> hikiko: Error: "a{sv}" is not a valid command.
[12:36] <desrt> sorry.. @a{si} :)
[12:36]  * desrt has intense muscle memory for typing a{sv}
[12:36] <hikiko> oh so @ is like reference-dereference?
[12:36] <desrt> @ means "give me this as a GVariant* instead of the usual type"
[12:36] <meetingology> desrt: Error: "means" is not a valid command.
[12:37] <desrt> and for "a" the "usual type" is GVariantIter/GVariantBuilder
[12:37] <desrt> take a look at https://developer.gnome.org/glib/stable/gvariant-format-strings.html
[12:37] <desrt> it documents what each character means
[12:37] <desrt> https://developer.gnome.org/glib/stable/gvariant-format-strings.html#gvariant-format-strings-arrays is 'a'
[12:38] <desrt> https://developer.gnome.org/glib/stable/gvariant-format-strings.html#gvariant-format-strings-gvariant is '@'
[12:38] <hikiko> I see :)
[12:39] <hikiko> I thought I should use a to deconstruct the array and get the gvariant dict-entries thanks a lot :)
[12:39] <hikiko> ok I am going to fix my other bugs now :) thanks a lot everybody!!
[12:45] <desrt> hikiko: it's worth noting that the newest glib version (which will be in trusty) also has a new type: GVariantDict
[12:45] <desrt> which would make your usecase quite a lot easier -- it supports adding one entry to a dict, for example
[12:45] <desrt> actually -- i take that back.  this type only works with a{sv} dicts :(
[12:45] <desrt> (sorry -- these types of dicts are really the absolute most common)
[12:46]  * desrt considers supporting others....
[13:33] <marga> Hi all! I'm having trouble with an issue running trusty, which I can't figure out.  The problem is that when I just boot, I can't switch VTs.  If I restart lightdm, though, I can.  I've found that seat0 is set to "CanGraphical=no", whereas in a non-customized installation it's set to "CanGraphical=yes".
[13:33] <marga> I'm assuming some config file of mine is causing this, but I already tried moving some away to no avail.  Any suggestions?
[13:36] <seb128> marga, hey, no idea, maybe mterry knows better about those details but he's not online yet
[13:36] <marga> ok, tnx
[13:39] <seb128> larsu, huummm
[13:40] <larsu> seb128: did you see a croissant au chocolat?
[13:40] <seb128> lol
[13:40] <seb128> larsu, I had one this morning!
[13:41] <larsu> \o/
[13:41]  * larsu should get one and instagram it to didrocks 
[13:41] <larsu> if that is something you do with instagram...
[13:41] <seb128> ;-)
[13:41] <didrocks> tsss :p
[13:42]  * ogra_ heard FAXing is the new instagram
[13:42] <seb128> larsu, I was debugging why evince stopped autoreloading documents when they change on disk
[13:42] <seb128> larsu, turns out it's your patch
[13:43] <seb128> larsu, ev_window->priv->settings is NULL, and 0001-Port-to-GMenuModel-and-add-menu-bar.patch drops ev_window_ensure_settings()
[13:43] <seb128> larsu, do you remember why you did that?
[13:43] <seb128> that function seems to be useful and not related to menus
[13:44] <didrocks> because of too many croissants au chocolat
[13:44] <didrocks> this thing *that doesn't exist* is just making you take bad decisions
[13:44] <seb128> didrocks, yeah, so as so good that you forget what you were doing before bitting in them
[13:44] <mdeslaur> lol
[13:44] <larsu> seb128: I don't remember, but I wrote it down: https://git.gnome.org/browse/evince/commit/?h=wip/gmenu&id=c100e1fd670e4cdca935c867b652bcda82360fde
[13:44] <didrocks> seb128: rohhhh
[13:44] <larsu> haha
[13:44] <seb128> larsu, ok, so that's buggy somehow
[13:45] <seb128> larsu, in shell/ev-window.c
[13:45] <seb128> ev_window_document_changed (EvWindow *ev_window,
[13:45] <seb128> 			    gpointer  user_data)
[13:45] <seb128> {
[13:45] <seb128> 	if (ev_window->priv->settings &&
[13:45] <seb128> 	    g_settings_get_boolean (ev_window->priv->settings, GS_AUTO_RELOAD))
[13:45] <seb128>  
[13:45] <seb128> settings is NULL there
[13:45] <seb128> which makes it bail out from reloading
[13:46] <larsu> right ... that looks like an oversight
[13:46] <larsu> I've replaced the other ones with ev_application_get_settings()
[13:46] <seb128> larsu, can you take it from there and fix it?
[13:46] <seb128> you probably know that code better than me
[13:46] <larsu> seb128: of course. I'm already on it :)
[13:46] <seb128> larsu, danke!
[13:46] <seb128> larsu, I'm buying you a croissant au chocolat next time we meet
[13:46] <seb128> shame for didrocks that he's trolling me
[13:47] <seb128> he's going to regreat not having one
[13:47] <seb128> :-p
[13:47] <didrocks> I can't have one, that doesn't exist again :)
[13:47] <larsu> I will eat it in front of him and he'll implode because of a lack of logic
[13:47] <didrocks> so I can't eat something that doesn't exist

[13:47] <seb128> larsu, seems you are right, it's starting
[13:47] <seb128> ;-)
[13:47] <larsu> gotta be careful
[13:47] <larsu> we don't actually want to lose didrocks :)
[13:48] <didrocks> you and all your illogicness! ;)
[13:48]  * didrocks hugs larsu
[13:48]  * didrocks hugs seb128
[13:48]  * seb128 hugs didrocks and larsu ;-)
[13:48]  * larsu joins the hugfest
[13:49] <seb128> larsu, https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1279755 assigned to you
[13:49] <ubot2`> Launchpad bug 1279755 in evince (Ubuntu) "Evince no longer automatically reloads PDF on change" [High,Triaged]
[13:49] <Sweetshark> grouphug!
[13:49] <larsu> seb128: thanks :)
[13:49] <seb128> larsu, thank *you* for fixing it ;-)
[13:49] <seb128> Sweetshark, you can join, https://launchpad.net/ubuntu/+source/libreoffice/1:4.2.0-0ubuntu1 moved to release pocket!
[13:49] <seb128> well done
[13:53] <MacSlow> seb128, larsu: the workarea branch is good go to
[13:53] <seb128> \o/
[13:53] <seb128> MacSlow, thanks for the review!
[13:53] <larsu> thanks man
[13:54] <MacSlow> larsu, such "mostly red"-diffs are my favourite :)
[13:55] <larsu> MacSlow: same :)
[13:55] <larsu> the biggest one is that we have gdk_screen_get_monitor_workarea() now
[13:56] <MacSlow> larsu, yeah I think I didn't have that initially and had to use plain X11 to get that
[13:57] <larsu> right
[13:57] <Mirv> didrocks: I wonder where the metacity upload went since I don't see it?
[13:57] <MacSlow> but it's so long ago, I don't remember what call was added with which gtk+ version
[13:59] <didrocks> Mirv: hum metacity_2.34.13-0ubuntu4_source.ubuntu.upload
[13:59] <didrocks> Mirv: I didn't get any rejection email
[14:00] <didrocks> Mirv: just redputed -f
[14:00] <seb128> didrocks, Mirv: right serie in the changelog?
[14:00] <didrocks> trusty when I checked
[14:01] <seb128> k, dunno then
[14:01] <didrocks> Distribution: trusty
[14:03] <didrocks> second dput worked…
[14:03] <didrocks> I even didn't resign
[14:04] <didrocks> just dput -f (as the first one had a .upload file already)
[14:05] <seb128> weird indeed
[14:05] <Sweetshark> seb128: \o/
[14:09] <Mirv> didrocks: weird
[14:10] <Mirv> now there anyway
[14:10] <marga> Hey mterry, seb128 said that you might be able to shade some insight into a problem I'm having... I'll repeat what I said earlier.
[14:10] <marga> mterry, I'm having trouble with an issue running trusty, which I can't figure out.  The problem is that when I just boot, I can't switch VTs.  If I restart lightdm, though, I can.  I've found that seat0 is set to "CanGraphical=no", whereas in a non-customized installation it's set to "CanGraphical=yes".
[14:11] <marga> mterry, I'm assuming some config file of mine is causing this, but I already tried moving some away to no avail.  Any suggestions?
[14:13] <seb128> sil2100, there?
[14:13] <marga> uhm, also, the vanilla installation I'm coparing to is a VM, whereas the one that doesn't work is a real machine with an NVIDIA card... It might be related to that last fact, maybe.
[14:52] <seb128> Laney, attente_, mpt, (tedg, kenvandine if you want to join): settings meeting in ~10min
[14:52] <seb128> mterry, hey
[14:53] <mterry> seb128, hello
[14:53] <seb128> mterry, did you see marga's question a bit earlier? (asking but you might have IRC timeouted and missed it)
[14:53] <mterry> seb128, missed it
[14:53] <marga> I have just found that it's totally NVIDIA's fault.
[14:53] <seb128> marga, you should ask again ;-)
[14:53] <seb128> oh ok, "good" I guess
[14:53] <marga> If I use nvidia-331 it works fine, but with nvidia-current it doesn't.
[14:54] <asac> mlankhorst: when will the xorg-server build bustage be fixed?
[14:54] <seb128> mterry, seems missing it spared you work, good move ;-)
[14:54] <marga> What's the deal with that? Why is "current" still pointing to 304?
[14:54] <seb128> asac, it's fixed, cf #ubuntu-devel
[14:54] <mterry> seb128, :)
[14:54] <seb128> asac, but builds failed because the CI copy copied the new binaries to universe
[14:54] <mlankhorst> asac: /me shakes magic 8ball
[14:54] <mlankhorst> outlook not so good :-(
[14:54] <seb128> asac, I just promoted those, need to wait another publisher run now to retry
[14:55] <seb128> marga, tseliot is maintaining those, you can ask him I guess, I don't follow the versioning much
[14:56] <asac> seb128: ok, so we rebuild xorg and with some luck stuff will build?
[14:56] <asac> and then kgunn can continue?
[14:56] <seb128> asac, retrying the builds once the publisher has moved the binaries to main should let us finish that transition yes
[14:57] <mlankhorst> the mir architectures still fail :P
[14:57] <seb128> mlankhorst, did you retry?
[14:57] <seb128> mlankhorst, or do they fail because of a code bug/issue in the upload?
[14:57] <Laney> no
[14:57] <mlankhorst> because ne w mir is not published y et
[14:57] <Laney> he retried too early
[14:57] <seb128> shrug
[14:57] <Laney> use rmadison to check
[14:57] <seb128> mlankhorst, I told you to use rmadison
[14:57] <Laney> seb already said that
[14:58] <tseliot> marga: we migrated nvidia-current to 334 because nvidia-current used to contain a driver that supported legacy cards, and nvidia-304 happens to be a legacy driver.
[14:58] <seb128> mlankhorst, you are wasting buildds resources by retrying like that
[14:58] <seb128> Laney, get your tablet, settings meeting about to start ;-)
[14:58] <Laney> phone!
[14:58] <seb128> that works too!
[14:59] <marga> tseliot, ok, so there are no plans of making nvidia-current point to anything more current?
[15:00] <tseliot> marga: not really. We only still keep it around to help with dist-upgrades.
[15:01] <marga> tseliot, ok.  No other meta package to help with staying current either?
[15:01] <seb128> mpt, kenvandine, ted, attente_, Wellark: who is coming for the settings meeting?
[15:01] <mlankhorst> asac kgunn didrocks: why not spend the time waiting on testing mesa 10.1.0-rc1 :D
[15:01] <mlankhorst> https://launchpad.net/~canonical-x/+archive/x-staging/+packages
[15:04] <tseliot> marga: are you asking because your packages need to depend on nvidia or only because you want to always get the latest driver?
[15:05] <marga> tseliot, I'd like to always get the latest driver, yes.
[15:05] <mlankhorst> seb128: you too btw^ :D
[15:05] <seb128> mlankhorst, k
[15:06] <tseliot> marga: ok, then either nvidia-331 or nvidia-331-updates. When we move to whatever LTS version NVIDIA comes up with, these two packages will become transitional and you'll be migrated to the correct driver.
[15:08] <marga> tseliot, ok, I understand.  But just to be sure, is there a reason why you don't want a meta package that is always the same?
[15:08] <kenvandine> seb128, lonely ?
[15:08] <attente_> mpt, hey, since we probably can't change the system display language on the fly, how should we prompt the user to reboot the phone when the language is changed?
[15:09] <mlankhorst> marga: that's a bad idea, nvidia has dropped support for cards previously
[15:09] <tseliot> marga: the rationale for this kind of behaviour is that if NVIDIA decides to drop support for a number of cards in their newer driver, we can decide to migrate users to the legacy driver, thus preventing problems on upgrades.
[15:09] <seb128> kenvandine, were, but it's fine now, we are 4
[15:09] <marga> mlankhorst, tseliot: ok, everything clear.  Thanks.
[15:09] <tseliot> np
[15:16] <seb128> kenvandine, we miss you though!
[15:22]  * kenvandine hugs seb128
[15:25]  * seb128 hugs kenvandine back
[15:31] <Laney> seb128: https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1276699/comments/5 is the comment I was mentioning
[15:31] <ubot2`> Launchpad bug 1276699 in ofono (Ubuntu) "scan-for-operator script fails: org.ofono.Error.Failed: Operation failed" [Undecided,Incomplete]
[15:31] <Laney> I bet the D-Bus API changed
[15:31] <seb128> seems possible yeah
[15:31] <seb128> blame rsalveti!
[15:38] <sil2100> seb128: what's up?
[15:38] <sil2100> Been deep in code ;)
[15:41] <seb128> sil2100, what do you code on?
[15:42] <sil2100> seb128: OSK bug-hunting
[15:43] <seb128> oh
[15:43] <seb128> did you track it down? ;-)
[15:44] <rsalveti> seb128: haha
[15:44] <rsalveti> I did the original implementation, that worked fine :P
[15:44] <seb128> rsalveti, then you handed over and it well downhill!
[15:47] <seb128> went even
[15:52] <sil2100> seb128: not entirely, but I think I'm close!
[15:52] <seb128> sil2100, do you have some free slots to deal with landing requests for desktop stuff? (they should be safe since they don't impact touch)
[15:54] <sil2100> seb128: I see most of them are assigned already, and I think that's a good thing to release those
[15:55] <seb128> sil2100, the CI train ones or the old landing pipeline ones?
[15:55] <seb128> sil2100, I put 3 on the old landing ask for things that are not under CI train yet
[15:56] <sil2100> Aaaaaaa
[15:56] <sil2100> seb128: ok, I'll try to look at those, not sure if didrocks didn't want all projects to use the CI train already - but for small projects like that I guess we could still release in the old way
[15:58] <seb128> sil2100, thanks
[16:11] <seb128> larsu, evince fixed verified&uploaded
[16:12] <larsu> seb128: thanks :)
[16:12] <seb128> thank you!
[16:22] <seb128> bregma, Trevinho, the new unity has some issues :/
[16:23] <bregma> seb128, hardly surprising since landing has been blocked for 4 months
[16:24] <seb128> for specifics
[16:24] <seb128> - in expose mode, there is some flickering between the windows and the decoration
[16:24] <seb128> (e.g open 2 nautilus win, click on the launcher icon)
[16:24] <seb128> likely something for Trevinho with the new decorations
[16:25] <seb128> - the first time the dash is open (or resized) the background is solid black
[16:25] <Trevinho> seb128: mh let me check
[16:25] <seb128> that's really visible and not nice
[16:25] <seb128> that's on a intel i5 hardware
[16:25] <Trevinho> ah, seb128 yes... Well I've two ways to fix it...
[16:25] <Trevinho> one is caching the texture before painting it, the other is trying the new cairo....
[16:26] <Trevinho> as it seems that this paint using a scaled texture causes some slowdown, and I'd like to see if the new cairo with device scaling might help
[16:26] <seb128> Trevinho, new cairo?
[16:26] <Trevinho> so I left that as it is but it's a minor known thing :)
[16:26] <seb128> Trevinho, I'm running the git snapshot from the desktop ppa here
[16:26] <Trevinho> seb128: cairo with device scaling...
[16:26] <seb128> Trevinho, I'm running that version
[16:26] <Trevinho> seb128: yes, but I'm not using its features in uinity yet
[16:26] <seb128> oh ok
[16:27] <seb128> well, in any case it's quite unpleasant looking
[16:27] <seb128> we can't land that to trusty like that :/
[16:27] <Trevinho> seb128: mh it's quite stuble here... but I guess it depends on hw... so I can fix it by caching the value
[16:28] <seb128> it's quite visible on my i5 laptop and that's not a slow box
[16:28] <seb128> it's sure not a very recent one, but it's not a notebook either
[16:31] <Trevinho> seb128: that's not due to new decorations though... at least that's due to the gtk theming that we're using for decorations... Before we were painting things guessing the theme, now we're using the real one and this might be more expensive
[16:31] <seb128> Trevinho, you are speaking about the flickering or the dash background?
[16:32] <Trevinho> flickering
[16:32] <seb128> Trevinho, oh, sorry, that's minor in my opinion
[16:32] <Trevinho> as for the dash bg... mh, never got it :o
[16:32] <seb128> the annoying one is the dash background being solid
[16:32] <Trevinho> solid or black?
[16:33] <Trevinho> do you have a screenshot?
[16:34] <didrocks> sil2100: seb128: we'll need someone at some point for those though
[16:34] <Trevinho> as there have been a lot of changes, and not having daily-landing and the human-quality checking every few days possibly made us to lose something....
[16:34] <didrocks> (those projects)
[16:34] <didrocks> Trevinho: registered on the FOSDEM side (see my request yesterday) btw?
[16:35] <seb128> didrocks, right, I just don't want to block e.g themes fixes on finding somebody
[16:35] <didrocks> sure
[16:35] <Trevinho> btw the dash might be draw less (better thing), and this might lead to problems
[16:36] <Trevinho> didrocks: mh, what you mean sorry, probably I missed something :P
[16:36] <didrocks> Trevinho: so that our talk is published on the FOSDEM website, you had to register on it
[16:36] <didrocks> so that you are linked as a speaker
[16:36] <Trevinho> didrocks: ah ok :)
[16:37] <didrocks> Trevinho: just tell me once done, I'll then email
[16:37] <Trevinho> didrocks: is there a form? as I can't find anything on the site...
[16:37] <didrocks> Trevinho: https://penta.fosdem.org
[16:38] <Trevinho> didrocks: oh, thanks but it asks me for a password
[16:38] <didrocks> Trevinho: click on FOSDEM 2014
[16:38] <didrocks> and there is a sign in
[16:38] <didrocks> ah
[16:39] <didrocks> Trevinho: https://penta.fosdem.org/submission
[16:39] <didrocks> that link should work and you have create account
[16:42] <seb128> Trevinho, bregma: http://people.canonical.com/~seb128/unity.ogv
[16:43] <seb128> Trevinho, bregma: that's what opening the dash first time after unity start or restart is with the new unity for me
[16:43] <Trevinho> seb128: mhhm
[16:43] <seb128> Trevinho, you see what I mean by "not nice looking" ;-)
[16:44] <Trevinho> ok it might be due to the fact compiz doesn't send the texture to compiz quick enough...
[16:44] <Trevinho> seb128: I'm a bit busy now but I could check how we could avoid that later... but I'd probably need you to test the code :)
[16:45] <Trevinho> seb128: are you using multi-monitor?
[16:45] <seb128> Trevinho, yes, dual screen
[16:45] <Trevinho> seb128: can you try to remove one?
[16:46] <seb128> Trevinho, no such issues then
[16:47] <Trevinho> seb128: yeah, it's something I experienced some time ago, but I've not found that anymore... it looks that compiz is laggy in sending the proper framebuffer texture to secondary monitors in some cases... but really I've not had this anymore since long time... :/
[16:48] <seb128> Trevinho, bregma: I opened https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1279886 about that
[16:48] <ubot2`> Launchpad bug 1279886 in unity (Ubuntu) "[new-trusty-unity, multimonitor] Dash background displayed as solid on first opening" [High,New]
[16:49] <Trevinho> seb128: thanks
[16:49] <seb128> yw
[16:49] <Trevinho> seb128: tell me, does it happen in both monitors for you?
[16:51] <seb128> Trevinho, shrug, it doesn't happen anymore now that I played with xrandr to turn one screen on/off
[16:51] <seb128> now I've the same issue on the launcher and only on one screen it seems
[16:51] <seb128> the launcher icons also have "flicker" when you move them
[16:52] <Trevinho> seb128: it's basically a race...
[16:52] <seb128> like you can first see a white rectangle behind
[16:52] <Trevinho> seb128: that's an old thing
[16:52] <seb128> ok
[16:52] <seb128> I pay more attention than usual because I'm doing testing :p
[16:52] <Trevinho> seb128: and that's because the texture doesn't get alpha background for some reasons at the beginning
[16:52] <Trevinho> I've tried to fix... ity but with no jou
[16:52] <Trevinho> joy
[16:52] <seb128> k
[16:53] <Trevinho> or... maybe I've an idea now... let me try
[17:10] <Sweetshark> ricotz: btw, I created https://launchpad.net/~libreoffice/+archive/libreoffice-4-2 -- Im not populating it for trusty now as the main archive is up-to-date, but feel free to dump saucy/raring/precise stuff there.
[17:13] <ricotz> Sweetshark, ok, but raring is EOL ;), will some "final" 4.2 builds in the main ppa first though
[17:13] <ricotz> Sweetshark, did you got my concerns?
 hi, jfyi, libo_CHECK_SYSTEM_MODULE([mdds], [MDDS], [mdds >= 0.10.1])
 not 0.9.1 like the packaging currently refers to
 also please pick up http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=3ff0aa58c9aa10a1e173aaef294b8be1c3958d0f;hp=619a5d1159e28c0010a49649feb43c64a3a68f3b
[17:14] <ricotz> Sweetshark, please push the packaging branches too
[17:15] <Sweetshark> ricotz: yeah, noted.
[17:15] <Sweetshark> ricotz: ah, will do.
[17:16] <ricotz> Sweetshark, thx
[17:24] <Trevinho> didrocks: finally done... account name: 3v1n0
[17:27] <Trevinho> seb128: so, it seems that my idea about the launcher icon was right... can you confirm it: http://pastebin.ubuntu.com/6926582/ ?
[17:27] <didrocks> Trevinho: great, thanks
[17:27] <Trevinho> didrocks: thank you!
[17:30] <seb128> Trevinho, not now but, I don't have an unity build tree locally, going to take a bit
[17:30] <seb128> Trevinho, I'm going to try later and let you know
[17:31] <Trevinho> seb128: thanks
[17:38] <seb128> sil2100, nice that you debug, but can't drop everything else on the floor for most of a day, need to context switch sometimes... what's the status of the landings we discussed earlier?
[17:40] <Laney> we should get some desktop landers ...
[17:40] <Laney> ;-)
[17:54] <seb128> Trevinho, your new decorations don't have a context menu, is that wanted?
[17:54] <Trevinho> seb128: otp
[17:54] <seb128> k
[17:57] <Trevinho> seb128: so... no, it's something I've still to do... And at this point I want to make it for both the panel (for maximized windows) and the  normal decorations, but that's a minor thing I left for next weeks
[17:58] <Trevinho> before UIF
[17:58] <seb128> ok, as long as it's coming before the LTS
[17:58] <seb128> that seems like a regression and a blocker to land new decorations though
[17:58] <Trevinho> seb128: sure, the same is for the "this window is freezed" dialog..
[17:59] <Trevinho> seb128: it's a regression indeed, but I'm not sure design ever wanted them in theory... it was just a legacy functionality left out from the gtk-window-decorator
[17:59] <Trevinho> ah, if you upgraded please make sure if the decor plugin and the gtk.-window-decorator are not loaded anymore there (I've added migration scripts, bu who knows...)
[18:00] <seb128> Trevinho, dropping those features is what angry our users and we agreed we don't want to angry more of them before the LTS
[18:00] <Trevinho> seb128: I know, and that's why they'll be back
[18:00] <Trevinho> it's something I already stated on the MR of the new decorations...
[18:00] <seb128> Trevinho, they are not, I downgraded back to the trusty version to compare thing and I had no decoration :p
[18:00] <Trevinho> seb128: nice :)
[18:00] <seb128> Trevinho, well, we are not supposed to land things with regression, they should not be merged if they are not feature complete
[18:01] <seb128> Trevinho, and yeah, menus are not great, but designers didn't provide us any other way to e.g pin a video player on top for example
[18:01] <seb128> which is an useful feature if you want to watch something in a corner while keeping doing other stuff
[18:01] <Trevinho> seb128: things are depening on it and we can't block trun because of this... you understand, that it would make merging impossible otherwise
[18:01] <Trevinho> trunk^
[18:02] <seb128> the decorator work shouldn't have landed in trunk while it was incomplete
[18:02] <Trevinho> seb128: indeed. I use that, and ti's planned to get them back
[18:03] <seb128> Trevinho, I understand you, but it was decided we would stop landing stuff with regression because then priorities changes and work is dropped and we release with regressions
[18:03] <seb128> the only way to stop that is to not land stuff until they are complete
[18:03] <seb128> Trevinho, that's nothing against you btw, but we have rules and they should be followed
[18:03] <seb128> bregma, ^
[18:04] <Trevinho> seb128: I know... Np I'll work on them asap, but really.. that was a very minor thing compared the all work needed to get all the decorations in
[18:37] <Trevinho> seb128: have you noticed that last nautilus + light-themes (the ones from the build ppa, so trunk) has "rounded" corners under the decorations? http://i.imgur.com/YKsXdGR.png
[18:37] <Trevinho> seb128: basically it was because it used to use an header-bar
[18:38] <Trevinho> but it's quite ugly
[18:38] <seb128> hum
[18:38] <seb128> what nautilus version do you use?
[18:38] <Trevinho> seb128: also the "home" button is cut on the left side
[18:38] <seb128> that was supposed to be fixed by the version uploaded
[18:38] <Trevinho> seb128: 1:3.10.1-0ubuntu4
[18:39] <seb128> hum
[18:40] <seb128> Trevinho, I had the pixel issue, I pointed it on https://code.launchpad.net/~darkxst/ubuntu/trusty/nautilus/310/+merge/200275
[18:40] <seb128> but the version update he did fixed it
[18:40] <seb128> I need to check again
[18:40] <seb128> yeah, doesn't happen for me
[18:40] <seb128> with the old decorator
[18:40] <seb128> but I doubt that has to do with the decorator
[18:41] <Trevinho> seb128: no, it's unrelated... it seems an app issue
[18:41] <Trevinho> as the decorator draws outside the window shape
[18:41] <Trevinho> I might have some outdated packages though
[18:41] <Trevinho> but surely not nautilus or light-themes
[18:42] <seb128> Trevinho, http://bazaar.launchpad.net/~darkxst/ubuntu/trusty/nautilus/310/revision/406 was supposed to fix that
[18:42] <seb128> and the fix works for me
[18:42] <seb128> what is your XDG_CURRENT_DESKTOP?
[18:43] <Trevinho> seb128: unity of course..
[18:44] <seb128> Trevinho, you never know with env, they can get screwed
[18:44] <seb128> I was speaking about the env variable
[18:44] <Trevinho> yes, yes.. but I've cheked :)
[18:44] <seb128> not the desktop you run ;-)
[18:44] <seb128> k
[18:44] <seb128> well, I can't confirm, but I'm going to keep an eye on it
[18:44] <Trevinho> ah. wait... the fix was after 1:3.8.2-0ubuntu4
[18:45] <Trevinho> according the changelog
[18:45] <Trevinho> oh, no .... I confused the main version...
[18:45] <Trevinho> yeah the revision I have should work
[18:45] <popey> seb128: found it! control+space!
[18:46] <Trevinho> seb128: but for your information, I'm getting htat also with metacity...
[18:46] <Trevinho> so it's not really an unity issue
[18:46] <seb128> popey, yeah, that's the keybinding to switch layout...
[18:46] <seb128> popey, how do you press that by error/without noticing?!
[18:47] <popey> http://imgur.com/nQMk94C
[18:47] <seb128> Trevinho, yeah, I didn't expect it, the headerbar gives round corners but that codepath should be disabled under !GNOME
[18:47] <seb128> popey, right, that's normal
[18:47] <seb128> popey, ctrl-space is the ibus keybinding to cycle layouts
[18:47] <popey> i have _never_ seen that dialog before today ☻
[18:48] <seb128> popey, it was not working before
[18:48] <seb128> seems they fixed it with the recent ibus update
[18:48] <popey> i forsee an apt-get remove of ibus in my future
[18:48] <seb128> big hammer
[18:48] <seb128> you can run ibus-setup and disable the keybinding
[18:48] <popey> i only have uk layout
[18:48] <seb128> but how do you manage to do ctrl-space by error?
[18:48] <popey> so why would it flip to us when i only have one?
[18:49] <seb128> because us is always added as a fallback
[18:49] <popey> and in "Text entry" it says "Super+Space" not Ctrl+Space
[18:49] <seb128> that's needed so e.g ctrl-C works in russian layouts
[18:49] <seb128> right
[18:49] <seb128> text entry is our layout stuff
[18:49] <seb128> ibus-setup is ibus
[18:49] <seb128> we should probably disable the ibus one by default
[18:49] <seb128> I'm still interested on how you press those 2 keys by error
[18:50] <seb128> I wonder if that's a common issue
[18:50] <seb128> they are not near of each others on my keyboard
[18:51] <popey> V is near space
[18:51] <popey> CTRL+V is something I press often
[18:51] <popey> but I dont think I mis-hit
[18:51] <popey> I think I have CTRL held down too long then move on to pressing space after pasting something
[18:52] <popey> so press and hold ctrl, tap v, press space, lift ctrl
[18:52] <popey> thanks for the info, happy now ☻
[18:53] <seb128> popey, yw, https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1278511 btw
[18:53] <ubot2`> Launchpad bug 1278511 in ibus (Ubuntu) "CTRL-Space no longer works under Unity" [High,Confirmed]
[19:02] <bschaefer> seb128, that should be because it was changed to Super+Space right?
[19:02] <bschaefer> in ibus 1.5.3?
[19:02]  * bschaefer thinks that bug is invalid...
[19:16] <attente_> i have an old ibus branch that disables the trigger under unity if that's what we want to do
[20:12] <robert_ancell> cyphermox_, has network manager gone unstable recently? I'm getting issues connecting to a WiFi repeater and I had issues connecting to an airport lounge network (my Android phone connects fine to both)
[20:13] <robert_ancell> I'm thinking the lounge might be a similar case of a repeater. When I disable the repeater it works fine
[20:13] <cyphermox_> robert_ancell: no
[20:13] <robert_ancell> cyphermox_, the good thing is I can easily reproduce by switching the repeater on and off - what logs can I give?
[20:13] <cyphermox_> I'm getting issues with my own wifi device too, I think there has been changes in the kernel
[20:14] <cyphermox_> robert_ancell: usually syslog has what we need
[20:14] <robert_ancell> ok, I'll be back in a sec
[20:18] <robert_ancell> cyphermox_, does http://paste.ubuntu.com/6927515/ give any hints?
[20:19] <bschaefer> seb128, hey, do you know if libcairo 2.0 is landing for 14.04?
[20:19] <cyphermox_> robert_ancell: 80:3F:5D:98:16:55 is the repeater?
[20:20] <seb128> bschaefer, is there a such thing?
[20:20] <bschaefer> err
[20:20] <bschaefer> seb128, i though Trevinho talked to you about it?
[20:20] <robert_ancell> cyphermox_, yes. Used to work fine
[20:20] <seb128> bschaefer, attente_: no opinion on the ibus keybinding, if you stuff superseed it we should disable the ibus keys
[20:20] <cyphermox_> there's this weird "wrong mac address" wl_cfg80211_get_station error too
[20:20] <seb128> bschaefer, oh, you mean hidpi support? that's not 2.0
[20:21] <bschaefer> seb128, o thought it was 2.0, my bad
[20:21] <bschaefer> seb128, but yes!
[20:21]  * bschaefer has the ppa but didn't check the version
[20:21] <seb128> bschaefer, no worry, and yes I want to land that, but upstream isn't rolling tarball and I don't like uploading random git snapshots
[20:21] <seb128> bschaefer, it's 1.3
[20:22] <cyphermox_> robert_ancell: there is no error aside fro that "wrong mac address" message and the information that you're roaming to a different device
[20:22] <bschaefer> seb128, alright, we can plan accordingly :), thanks!
[20:22] <cyphermox_> robert_ancell: could you be on a system with the iwldvm driver?
[20:22] <bschaefer> seb128, for now ill just assume it wont land so we don't get stuck depending on it
[20:22] <attente_> i want to disable it, but maybe clearing the default is enough?
[20:23] <bschaefer> attente_, disabling umm ctrl+space? Or super?
[20:23] <robert_ancell> "12:00.0 Network controller: Broadcom Corporation BCM4313 802.11bgn Wireless Network Adapter (rev 01)"
[20:23] <cyphermox_> nope. :/
[20:23] <attente_> bschaefer, ctrl+space, the ibus trigger
[20:23] <robert_ancell> Don't know what kernel driver that uses these days
[20:23] <seb128> attente_, clear/disable, what's the difference?
[20:23] <bschaefer> attente_, i think im a bit out of context :)
[20:23] <attente_> when switching using ctrl+space, i-keyboard doesn't see it happen, so it doesn't reflect the current im properly
[20:24] <cyphermox_> robert_ancell: sudo /usr/lib/NetworkManager/debug-helper.py --wpa debug
[20:24] <bschaefer> attente_, right it doesn't only super+space
[20:24] <robert_ancell> cyphermox_, after the problem or now?
[20:24] <cyphermox_> robert_ancell:  run that and reproduce the issue please
[20:24] <attente_> seb128, i mean disable as in it won't work even if the user sets it through ibus-setup
[20:24] <robert_ancell> ok
[20:24] <bschaefer> attente_, could you add ctrl+space to the keyboard indicator?
[20:24] <cyphermox_> well, running it for a while helps
[20:24] <attente_> clear as in, just change the default to be no keybinding
[20:24] <bschaefer> attente_, i can imagine that making some users confused
[20:24] <attente_> the user could still set it
[20:24] <robert_ancell> cyphermox_, and get syslog?
[20:24] <cyphermox_> we'll get to know more about what wpa thinks of all this
[20:24] <cyphermox_> yup
[20:24] <cyphermox_> it's all going to end up in syslog
[20:24] <Trevinho> seb128: let's continue evaluating it, but the fact is that if we want hidpi support in 14.04 (for gtk apps) there's not much choice
[20:24] <attente_> bschaefer, the thing is it's basically two different key bindings
[20:25] <Trevinho> seb128: or just backporting the relative patch
[20:25] <seb128> bschaefer, Trevinho: you can count on it landing
[20:25] <bschaefer> seb128, cool, that works as well, thanks again!
[20:25] <seb128> bschaefer, Trevinho: I uploaded it in the ppa a week ago, I plan to move that forward, I just got busy
[20:25] <seb128> bschaefer, Trevinho: it's going to be in trusty next week one way or another
[20:25] <Trevinho> seb128: nice
[20:25] <bschaefer> seb128, yup, i've been using that ppa for a bit now and no problems
[20:26] <bschaefer> attente_, hmm correct they are, you should be able to read all the ibus hotkeys
[20:26] <bschaefer> through gconf or w/e they use now a days
[20:26] <bschaefer> attente_, im not sure how hard it is for the keyboard indicator to use more then 1 hotkey for this
[20:26] <attente_> bschaefer, but if the user uses the ibus hotkey, they'll only be switching among the ibus input methods
[20:27] <attente_> if the user uses the g-s-d key, they'll be switching among those + keyboard layouts
[20:27] <bschaefer> attente_, right, but if you hook up keyboard indicator to read the ibus hotkeys, cant you just set those hotkeys?
[20:27] <bschaefer> for g-s-d to act on?
[20:27] <attente_> bschaefer, oh. i see what you mean
[20:27] <bschaefer> attente_, again, i think im missing something but that sounds like the most dynamic method
[20:27] <attente_> for i-keyboard to intercept the ibus one?
[20:27] <bschaefer> attente_, right, as i-keyboard already depends on ibus right?
[20:28]  * bschaefer hasn't checked in a while...
[20:28] <robert_ancell> cyphermox_, I should email you that log right? Looks like it has keys in it
[20:28] <robert_ancell> cyphermox_, also, how to disable debugging
[20:29] <bschaefer> attente_, its a bit close to FF but there use to be a way to read the hot keys from ibus...i think i have it down in an AP test
[20:29]  * bschaefer goes to check
[20:29] <attente_> bschaefer, if we do this, i'm afraid of the situation where both keybindings are equal to each other
[20:29] <bschaefer> attente_, isn't that how it is by default? Super+Space?
[20:30] <attente_> bschaefer, it comes from /desktop/ibus/general/hotkey triggers i believe
[20:30] <bschaefer> right
[20:30] <bschaefer>         variant = config.get_value('general/hotkey', 'triggers')
[20:30] <bschaefer> is how im getting it in python AP test
[20:30] <attente_> bschaefer, ibus default seems to have changed to control+space recently
[20:30] <bschaefer> attente_, ooo yeah thats interesting...it use to be super+space for most of this dev cycle :)
[20:31] <bschaefer> attente_, hmm it use to work when both were the same though? How would that cause issues now?
[20:33] <attente_> bschaefer, ironically i think it wasn't a problem before because they were fighting over the same key grab...
[20:33] <bschaefer> attente_, haha, i see. Those are always fun bugs :)
[20:33] <attente_> but if we were to get i-keyboard intercepting it, i'd try to use the key grabber for that...
[20:33] <bschaefer> so now the problem is... if you set the hotkeys dynamically, if ibus gets it first, i-keyboard wont get it
[20:34] <bschaefer> attente_, it might not be a bad idea to, by default remove the hotkey from ibus, and add super+space / ctrl+space under i-keyboard
[20:34] <bschaefer> to change langauge?
[20:34] <bschaefer> language*
[20:35] <bschaefer> which is what you were suggesting a bit ago (i think)
[20:35] <attente_> well, i was only proposing the first half of what you're proposing now
[20:35] <attente_> disabling the ibus trigger completely under unity
[20:36] <bschaefer> that would work for most use cases, another problem is umm anthy or hangul users usually use Alt_L + <something>
[20:36] <bschaefer> theres always to many things to remember for input methods
[20:36] <bschaefer> attente_, that doesn't sound like a bad idea vs what we have now
[20:37] <attente_> bschaefer, the actual keybinding doesn't matter so much
[20:37] <attente_> bschaefer, they can still set it to Alt_L + <something> under the text entry settings
[20:37] <robert_ancell> jasoncwarner, damn, that was some fast shipping!
[20:37] <bschaefer> attente_, i wonder if we could just let users set what they want in ibus, and i-keyboard reads it
[20:38] <bschaefer> attente_, but have ibus patched such that it doesnt actually try to grab those keys?
[20:38] <bschaefer> that way theres no fighting...
[20:38] <bschaefer> attente_, that also sounds like a crazy-ish idea...and yours sounds a bit safer
[20:38] <attente_> bschaefer, so you want both the g-s-d switcher and ibus switcher to work?
[20:39] <sil2100> seb128: hi! Those old landings from the old spreadsheet - you guys tested those on the desktop right?
[20:39] <seb128> sil2100, good morning! yes
[20:39] <attente_> bschaefer, i mean work exactly the same way
[20:39] <sil2100> seb128: let me land some of them then
[20:39] <bschaefer> attente_, well yes above the hood
[20:39] <seb128> sil2100, thanks
[20:39] <bschaefer> attente_, we could force users to only use g-s-d though to change the hotkey
[20:39] <robert_ancell> cyphermox_, there?
[20:39] <cyphermox_> robert_ancell: yeah, email. to disable you can either reboot or use --wpa info
[20:40] <bschaefer> attente_, but im not sure how easy it'll be for them to find it if they are use to ibus-setup
[20:40] <bschaefer> attente_, just trying to avoid the confusion of not being able to find where to change the hotkeys when they fail or something
[20:41] <bschaefer> attente_, but really, what is the easiest + best way for you to solve this atm?
[20:42] <attente_> bschaefer, i'd say disabling the input trigger under unity is easiest
[20:42] <bschaefer> attente_, that sounds good to me :)
[20:42] <attente_> bschaefer, it avoids a lot of side effects of trying to support two different keyboard layout/IM switchers...
[20:42] <bschaefer> right
[20:43] <attente_> and i'm thinking of the case of the bug seb128 posted earlier
[20:43] <bschaefer> attente_, it would get very chaotic, and simple is usually best
[20:43] <attente_> if your ctrl+space is broken in emacs
[20:43] <attente_> and it's not obvious why ctrl+space is grabbed by ibus
[20:44] <bschaefer> very true, and finding out why is no easier...
[20:44] <attente_> then your first instinct would be to check the text entry panel i would think...
[20:44] <attente_> but then you don't see it there, it's set in ibus-setup
[20:44] <robert_ancell> cyphermox_, emailed
[20:44] <bschaefer> yeah, i would assume users who dont use ibus wont have a clue
[20:44] <attente_> which most people aren't using...
[20:44] <bschaefer> attente_, though really if they dont use ibus it should be started :)
[20:44] <attente_> bschaefer, agreed
[20:44] <bschaefer> shouldnt*
[20:45] <bschaefer> which is how i imagined things use to work
[20:45] <attente_> bschaefer, aha.. we've come full circle again..
[20:45] <bschaefer> :)
[20:45] <robert_ancell> Is this why ctrl+space doesn't work anymore...
[20:45] <bschaefer> robert_ancell, i would imagine, if you check if ibus-daemon is running, i would assume its stealing your hotkey
[20:45] <robert_ancell> sneaky ibus
[20:45] <robert_ancell> yep, it's running
[20:46] <bschaefer> robert_ancell, to fix that for right now, you should be able to do ibus-setup
[20:46] <bschaefer> and remove the hotkey
[20:46] <attente_> robert_ancell, you're using emacs? or this is something else?
[20:46] <bschaefer> or kill the daemon
[20:46] <robert_ancell> emacs
[20:46] <bschaefer> but the daemon autostarts :(
[20:47] <bschaefer> attente_, isn't input fun to get right? haha...
[20:47] <seb128> robert_ancell, ibus-setup to disable it
[20:47] <attente_> bschaefer, it's a joy :)
[20:47] <seb128> robert_ancell, hey btw ;-)
[20:47] <robert_ancell> fixed:)
[20:47] <bschaefer> attente_, :), hmm sooo ibus does need to start up for i-keyboard...?
[20:48] <bschaefer> attente_, which is fine, lets disable the hotkey under unity, make it super+space, if the ibus users want ctrl+space they can set it and be happy
[20:48] <bschaefer> while we dont trample on emacs users, or any users who don't use ibus
[20:48] <attente_> bschaefer, i-k only needs it for getting the IM name and icon, which is only necessary if the user has one in his lsit
[20:48] <attente_> *list
[20:49] <attente_> bschaefer, disable it? or set the default to super+space?
[20:49] <bschaefer> attente_, sorry, set default to super+space
[20:49] <bschaefer> some users will complain though...
[20:49] <bschaefer> as ctrl+space has been the default for ibus for a long time
[20:49] <bschaefer> well for IMs for a while...
[20:49] <attente_> i thought super+space was default in 13.10
[20:50] <bschaefer> attente_, hmm it could have been? Im sort of lost on the time atm :)
[20:50] <bschaefer> attente_, where was ibus 1.5.3 pushed to main?
[20:50] <bschaefer> when*
[20:50] <bschaefer> last release?
[20:52] <attente_> bschaefer, not sure, changelog says last september
[20:52] <bschaefer> the last entry in ibus is:  -- Osamu Aoki <osamu@debian.org>  Sat, 24 Aug 2013 01:25:05 +0900 ... which yeah
[20:52] <attente_> whoops, right
[20:52] <bschaefer> attente_, hmm which should have been in for 13.10
[20:53] <bschaefer> and i haven't heard of to many complaints...but the fact that ibus changed back to ctrl+space sounds like there was enough to change it back
[20:54] <bschaefer> attente_, so i suppose back to why i-k needs ibus, which is only for the IM name and icon if the user has one in its list?
[20:55] <bschaefer> the list of IMs? like pinyin?
[20:55] <bschaefer> (which is installed by default IIRC)
[20:55] <attente_> there's one other case where i-k needs ibus
[20:55] <bschaefer> it was that crash right?
[20:55]  * bschaefer forgot that bug...
[20:56] <attente_> um.. just when migrating the user's old settings to the g-s-d input source settings
[20:56] <bschaefer> attente_, wasn't there this crash, if ibus wasn't started but then the user selected like pinyin or something...
[20:57] <bschaefer> in the i-k, ... i can't remember much more from it
[20:57] <bschaefer> attente_, well so if we need ibus started, then im fine for just moving the default to super+space
[20:57] <bschaefer> if the users want ctrl+space, they'll have to do that them selfs, but thats fine
[20:58] <attente_> yeah
[20:58] <attente_> i'm seeing the changelog again, it does seem like it was super+space at one point:
[20:58] <attente_>   * This initiates ibus 1.4 to 1.5 transition.  This changes IM
[20:58] <attente_>     switching key to SUPER-space and integrates xkb.
[20:58] <attente_>     Closes: #690605, #699368
[20:58] <bschaefer> right the 1.5 transition is when it happened
[20:58] <bschaefer> and i've not heard any complaints about that in 13.10...
[20:58] <cyphermox_> robert_ancell: I don't see anything weird
[20:59] <cyphermox_> I'm guessing the repeater consistently has higher signal level than the other station so you'd always roam to it if it's available
[20:59] <attente_> bschaefer, if there weren't any complaints before, maybe nobody will complain if we disable it :P
[20:59] <bschaefer> attente_, but then the issue you were talking about before...if the user changes to ctrl+space...
[20:59] <bschaefer> then i-k doesn't read it :(
[21:00] <bschaefer> attente_, thats the hope :), though there will be a but more users on an LTS
[21:00] <bschaefer> be a bit*
[21:00] <cyphermox_> robert_ancell: you disconnected rather than waiting for it to roam didn't you?
[21:00] <robert_ancell> cyphermox_, I "reconnected", i.e. clicked on the network name again
[21:00] <cyphermox_> right
[21:00] <robert_ancell> It doesn't seem to roam automatically for me
[21:01] <robert_ancell> I can move to the lounge where the reception to  the repeater is awful. I'm sitting right beside the primary AP and it doesn't roam
[21:01] <cyphermox_> ah? that's what seemed to happen from the first syslog
[21:01] <attente_> bschaefer, if the user sets the key binding in ibus-setup, should ibus be able to switch the IM under g-s-d's nose?
[21:01] <cyphermox_> I thought 80:... was the repeater
[21:02] <bschaefer> attente_, hmm right, g-s-d shouldnt be responsible for changes in ibus, the user SHOULD really change the hotkey in g-s-d
[21:02] <bschaefer> attente_, soo really, we just need to be sure to announce, if you want ctrl+space as your hotkey change it in g-s-d
[21:02] <bschaefer> not ibus-setup
[21:03] <bschaefer> attente_, it just seems unfair for g-s-d to be reasonable for two different hotkey settings...
[21:03] <sil2100> seb128: ok, I published the 2 smaller ones, but I think didrocks will want unity-gtk-module to be released as part of CITrain
[21:04] <seb128> sil2100, why? it's desktop only, and even so, we can figure that later rather than blocking fixes no?
[21:05] <attente_> bschaefer, to put it simply, if the user sets the input trigger in ibus-setup, should that allow ibus to switch layouts?
[21:05] <attente_> *input methods
[21:05] <bschaefer> attente_, right, thats the question here hmm
[21:06] <bschaefer> attente_, it seems like at this point, what is *wanted* by default right?
[21:06] <attente_> because with g-s-d and g-c-c and i-k, i don't know if it makes sense for ibus to be managing that at all any more
[21:06] <bschaefer> attente_, it would be really really really nice if ibus no longer controlled the hot keys if g-s-d is doing it
[21:07] <bschaefer> that way the only way to change the hotkey was is in g-s-d/i-k?
[21:07] <bschaefer> attente_, im not sure how to disable 'hotkeys for ibus only if g-s-d' is manging it though...
[21:08] <bschaefer> attente_, i also have a very small perspective coming from the unity/ubuntu point of view
[21:10] <bschaefer> attente_, to keep things simple, while keeping things sane, if the user changes the hotkey in ibus, i don't think g-s-d should be responsible for keeping up with that...
[21:10] <bschaefer> it will make i-k useless though if that happens...
[21:13] <robert_ancell> I feel bad that Ubuntu has rough edges and then I try Windows 8 and feel a lot better :)
[21:14] <sil2100> seb128: I can publish, but if Didier or Alexander will be angry, I'll just send them to you ;)!
[21:15] <seb128> sil2100, don't worry, I can handle them ;-)
[21:15] <attente_> bschaefer, even if we change ibus' default back to super+space, we still have the problem of ibus changing input method under g-s-d's and i-k's nose
[21:15] <seb128> robert_ancell, yeah, I tried to press the power button to reboot 3 times today, I missed the bios boot option and want to get back there ... press power, see the machine suspends, press again, wait to resume, grrr
[21:15] <bschaefer> robert_ancell, :), i've yet to try windows 8 out ... it might be a refreshing thing to try
[21:16] <attente_> as well as the apparent lack of consistency between ibus' list of IMs and g-s-d's list of input sources
[21:16] <bschaefer> attente_, i know :(. We really should/must have only 1 place to change these hotkeys
[21:16] <bschaefer> having more is over complicated things
[21:16] <robert_ancell> bschaefer, it's got some nice ideas, but it's still got lots of rough edges
[21:16] <robert_ancell> bschaefer, I definitely think it's a better bet than the traditional desktop for them
[21:16] <bschaefer> robert_ancell, thats refreshing to hear
[21:17] <attente_> bschaefer, maybe setting the ibus default to no hotkey is reasonable
[21:17] <seb128> robert_ancell, they have the same issue we have, they are sitting between old school stuff and their new stuff, and you get a mixed bag
[21:17] <bschaefer> attente_, it'll take some changing, but there must be only 1 place to change settings like this
[21:17] <attente_> bschaefer, then if the user wants to explicitly do the switching by ibus, they can
[21:17] <bschaefer> and i vote g-s-d, if its the only doing it by default
[21:17] <attente_> bschaefer, and if the user never sets it, ibus never grabs something unintentionally important
[21:18] <bschaefer> attente_, i agree...if the user wants to change the default go ahead
[21:18] <bschaefer> but if it breaks things, all we can suggest is change it in g-s-d
[21:18] <bschaefer> and things will work
[21:18] <attente_> i don't know what effect this will have under other desktops though
[21:19] <bschaefer> attente_, thats one thing im also worried about, but if g-s-d doesn't exist on other desktops
[21:19] <bschaefer> then ibus will rule there
[21:19] <bschaefer> hotkey changing wise
[21:19] <attente_> bschaefer, in that case i guess the user manually sets it in ibus-setup
[21:19] <bschaefer> we aren't disabling ibus it self from changing the hotkey, we'll just have g-s-d do it by default here...if they change that order
[21:20] <bschaefer> then thats their issue, and will cause issues...
[21:20] <bschaefer> but we can't control every possible situation
[21:21] <bschaefer> attente_, if we make g-s-d control the hotkey, then thats what we support (imo)
[21:21] <attente_> bschaefer, sorry.. i think you confused me a bit :S
[21:21] <bschaefer> at lease when it comes to unity/ubuntu (again thats my area of perspective)
[21:21] <bschaefer> attente_, i might be a bit confused :)
[21:22] <Sweetshark> Hmmm, is reducing the LibreOffice noop incremental build time to two thirds good enough?
[21:22] <bschaefer> attente_, so the issue we are talking about now, is if the users changes the hotkey in ibus-setup right?
[21:23] <Sweetshark> whops, wrong window.
[21:23] <robert_ancell> Sweetshark, we wont tell if you wont
[21:23] <Sweetshark> robert_ancell: alright then ;)
[21:24] <attente_> bschaefer, i guess it's several issues
[21:25] <sil2100> seb128: hey, do you want to do a packaging ACK of the unity-gtk-modules package ? ;)
[21:25] <attente_> bschaefer, g-s-d maintains a list of input sources, and switches between them using its own key bindings
[21:25] <seb128> sil2100, yes, I approved the mr, +1
[21:25] <sil2100> seb128: https://jenkins.qa.ubuntu.com/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_unity-gtk-module_0.0.0+14.04.20140213.2-0ubuntu1.diff <- it seems attente_ only moved packages around and added multi-arch
[21:25] <seb128> sil2100, thanks!
[21:25] <sil2100> \o/
[21:25] <attente_> bschaefer, ibus maintains a list of input methods, and switches between them using its own key bindings
[21:25] <bschaefer> attente_, correct, and by default g-s-d updates ibus to match its own right?
[21:26] <bschaefer> users super+space? or do they both grab that key and update?
[21:26] <bschaefer> using*
[21:26] <attente_> bschaefer, g-s-d doesn't touch ibus's list of engines
[21:26] <bschaefer> attente_, then how is ibus being updated along with g-s-ds' list?
[21:26]  * bschaefer thought that is how things were happing...
[21:27] <bschaefer> attente_, or was that the side effect you mentioned?
[21:27] <attente_> g-s-d explicitly sets ibus' IM every time the user changes to an ibus input source
[21:28] <bschaefer> i see... soo for example, if we press super+space a couple times and land on pinyin
[21:28] <bschaefer> g-s-d sets ibus im to pinyin?
[21:29] <attente_> bschaefer, right
[21:29] <attente_> the little bit of code that does that is here: http://bazaar.launchpad.net/~unity-settings-daemon-team/unity-settings-daemon/trunk/view/head:/plugins/keyboard/gsd-keyboard-manager.c#L1160
[21:30] <attente_> bschaefer, so g-s-d has its list and keybindings, ibus has its list and keybindings
[21:31] <attente_> the problem is now we have the two trying to do the same thing
[21:31] <attente_> no problem if g-s-d changes input sources, because all it does is explicitly set the IM if it's an ibus source
[21:31] <bschaefer> attente_, we should, drop ibus hotkeys, and let g-s-d do this
[21:32] <bschaefer> iff g-s-d is the one by default is doing this
[21:33] <attente_> bschaefer, yeah. i'm just a bit concerned that someone will be like: oooh. ibus-setup, let's change the key trigger. hey it doesn't work...
[21:33] <bschaefer> attente_, the fact we allow ibus to try to grab at the key as well sounds like a race condition/bug waiting to happen
[21:33] <bschaefer> attente_, right, and if that happens, we don't support that if we are allowing g-s-d to do this
[21:33] <bschaefer> well we can say we dont support doing that...
[21:33] <bschaefer> any hotkey changes dealing with IM/ibus should happen through g-s-d
[21:34] <attente_> bschaefer, works for me
[21:34] <bschaefer> attente_, this is if and only if g-s-d is doing the hotkey stuff for IMs, that way ibus will normally work outside of g-s-d
[21:34] <bschaefer> attente_, i don't think we can control that perfectly, and if the user does that
[21:34] <attente_> bschaefer, ok, so we'll disable it and remove it from ibus-setup as well, just so there isn't any confusion i guess?
[21:34] <bschaefer> attente_, sounds good
[21:35] <bschaefer> attente_, as really, if the user does indeed set the hotkey in ibus-setup the language switcher will work for ibus
[21:35] <attente_> bschaefer, and this is only under unity
[21:35] <bschaefer> and g-s-d will no longer work
[21:35] <bschaefer> attente_, yes!
[21:36] <bschaefer> attente_, it would be good to somehow announce/have a bug that says, if you change the hotkey in ibus-setup it'll cause g-s-d to no longer to anything
[21:36] <bschaefer> to no longer do*
[21:37] <bschaefer> attente_, but i can only imagine this being an edge case where ibus users want ctrl+space...
[21:37] <attente_> bschaefer, we won't need it if we remove the ability to set the key binding in ibus-setup
[21:37] <bschaefer> attente_, if we can do that for unity/ubuntu that would be perfect!
[21:38] <bschaefer> attente_, we should still have a nice place to let the users know where to change it now though hmm...
[21:38] <attente_> bschaefer, i thought we agreed on disabling it entirely though
[21:39] <bschaefer> attente_, even in g-s-d?
[21:39] <attente_> no, i mean disabling ibus' keybindings only
[21:39] <bschaefer> attente_, right, i agree with that, but if the users now want to change the hotkey and they only know about ibus-setup
[21:39] <bschaefer> they will make a bug about ibus-setup not changing the hotkey
[21:40] <bschaefer> attente_, but really, we can wait for the bugs to role in before doing anything
[21:40] <bschaefer> roll*
[21:40] <bschaefer> geez...
[21:40] <bschaefer> attente_, anyway, i agree with that solution :)
[21:42] <attente_> bschaefer, ok, will do
[21:43] <bschaefer> attente_, cool, and thanks again for getting that compiz/unity key grabber landed!
[21:45] <attente_> bschaefer, i think i owe the unity team a few beers for that one...
[21:45] <bschaefer> attente_, :), i think at this point everyone owes everyone beers haha
[21:46] <attente_> bschaefer, hehe :)
[22:19] <ochosi> robert_ancell: just a very quick question on greeter+indicators: this is how you properly shut down the indicators (= kill them)? http://bazaar.launchpad.net/~unity-greeter-team/unity-greeter/trunk/view/head:/src/unity-greeter.vala#L589
[22:20] <robert_ancell> ochosi, yeah, we're pretty blunt in the greeter. We should use upstart
[22:20] <ochosi> ok, just good to know
[22:20] <robert_ancell> oh wait, we are now
[22:20] <ochosi> since we support the indicators in gtk-greeter as well, we have to shut them down too ::)
[22:20] <robert_ancell> indicator_pid is actually the upstrat pid
[22:21] <robert_ancell> ochosi, but yeah, they should shutdown cleanly with SIGTERM
[22:23] <ochosi> robert_ancell: ok, good to know. well we'll stick to what you're doing for now i guess