[00:33] <ochosi> robert_ancell: hm, i implemented the blanking now and it has exactly the effect i was afraid of.. the session that gets started does indeed inherit the blank settings
[00:33] <ochosi> (this is the patch, only weighs a few lines and applies against gtk-greeter trunk: http://dpaste.com/1548435/ )
[00:34] <ochosi> i also added another call to reset the settings to defaults, but somehow that doesn't work :/
[00:34] <robert_ancell> ochosi, does the session not apply the setting when it starts?
[00:34] <robert_ancell> This is XFCE right?
[00:34] <ochosi> yeah
[00:35] <ochosi> xfce doesn't do anything about these values unfortunately :/
[00:35] <robert_ancell> so it just uses the X defaults?
[00:35] <ochosi> so the greeter will have to reset whatever is default
[00:35] <ochosi> yup
[00:35] <robert_ancell> yeah, I guess the greeter can read it on startup and clear it
[00:35] <ochosi> well if you look at the patch, that's what i tried
[00:35] <ochosi> i added some debug output locally, the values do get read successfully
[00:36] <robert_ancell> ochosi, did you call an XSync or equivalent?
[00:36] <ochosi> hm, i didn't
[00:36] <robert_ancell> Since the greeter is quitting it might not have actually sent the request
[00:36] <ochosi> oh
[00:36] <robert_ancell> there's a gdk call for it
[00:36] <ochosi> since the simple call worked at the beginning, i presumed it would at the end as well...
[00:36] <ochosi> good catch, i'll see whether that helps
[00:37] <ochosi> XFlush (display); ?
[00:44] <ochosi> robert_ancell: somehow that doesn't seem to work either, tried both XSync and XFlush now
[00:44] <robert_ancell> hmm, X is notoriously hard to diagnose :(
[05:54] <pitti> Good morning
[09:04] <Laney> morning
[09:04] <Laney> happy monday!
[09:04] <Laney> or something like that
[09:05] <seb128> good morning desktopers
[09:05] <seb128> Laney, hey, happy monday! had a good w.e?
[09:07] <Laney> hey seb128, it was very nice thank you - we went away to the peak district for some hiking
[09:07] <Laney> you?
[09:09] <seb128> mine was good as well
[09:09] <seb128> some tennis, some shopping, some video gaming
[09:09] <seb128> relaxing in between, and spa yesterday afternoon
[09:11] <Laney> sounds pleasant indeed
[09:13] <pitti> hey Laney, bonjour seb128
[09:13] <seb128> pitti, lut, ça va ? bon w.e ?
[09:14] <pitti> seb128: oui, merci ! we did some badminton and a nice long walk, and played Wizard with some friends until late night on Saturday :)
[09:16] <seb128> wizard? I guess that's a board game?
[09:17] <Laney> sounds a bit like contract whist
[09:17] <pitti> a card game
[09:17] <Laney> played some of that over the weekend :-)
[09:17] <pitti> http://en.wikipedia.org/wiki/Wizard_%28card_game%29
[09:17] <Laney> (hey pitti!)
[09:17] <pitti> it's a bit similar to Skat, but with simpler rules, and more interesting strategies
[09:18] <seb128> sounds like fun in any case ;-)
[09:36] <Laney> hmm, two random reboots this morning
[09:36] <Laney> suspecting disk issues
[10:46] <seb128> Laney, so, about those sounds setting in accountsservice ... you think we should make accountsservice replace gsettings as the configuration backend for those settings?
[10:46] <seb128> Laney, I've to admit it makes me uncomfortable, I've much less trust in accountsservice than gsettings to be a nice API to use and for stability/performance as well
[10:47] <Laney> It seems like the way to go for user properties which need to be accessed by parts of the 'system'
[10:48] <seb128> desrt, larsu: do you have an opinion on the topic? the context is the "ringtone" config for example
[10:48] <seb128> we had it in gsettings
[10:48] <seb128> but the greeter needs it
[10:48] <seb128> so we need it to accountsservice
[10:48] <seb128> I was suggesting "syncing" it there by some way but letting gsettings the primary storage and have user apps still use that
[10:48] <seb128> Laney suggests replace gsettings by accountsservice and have apps talk to accountsservice instead
[10:49] <desrt> ...
[10:49] <desrt> does the phone really have users?
[10:49] <seb128> the tablet has
[10:49] <desrt> like what do we do?  ringtone depending on who is selected at the login screen?
[10:49] <seb128> yes
[10:49] <desrt> that seems pretty random
[10:49] <seb128> well, if it's not ringtone you can think wallpaper
[10:49] <seb128> or locale
[10:49] <seb128> or keyboard layout
[10:49] <Laney> It'll look up the 'active' user from logind
[10:50] <chrisccoulson> hello desktoppers!
[10:50] <Laney> and play that guy's ringtone
[10:50] <seb128> chrisccoulson, hey, how are you?
[10:50]  * desrt makes a face
[10:50] <chrisccoulson> seb128, yeah, not too bad thanks. how are you?
[10:50] <desrt> seb128: keep using accountsservice, i guess
[10:50] <seb128> chrisccoulson, I'm good, thanks
[10:50]  * mpt imagines scrolling through the user list while the phone is ringing
[10:50] <Laney> it's not about that really
[10:50] <desrt> seb128: this is the future... we can shove all kinds of crack in there now
[10:50] <seb128> desrt, "keep"? we currently use gsettings
[10:50] <desrt> we can even have keys that have default values which contain '<' characters
[10:50] <desrt> TECHNOLOGY!!
[10:50] <seb128> desrt, so you would port desktop apps to talk to accountsservice rather than use gsettings?
[10:51] <Laney> I would only do it for things that need to be there
[10:51] <Laney> gsettings is nicer to work with
[10:51] <desrt> seb128: it seems like there are maybe a half-dozen or dozen examples of these type of settings that need to be available from the login screen
[10:51] <seb128> Laney, what is the API like for a desktop app to get a value and key changes update with accountsservice? I've the feeling that's a lot less nice that the 1 line with gsettings-qt
[10:51] <desrt> random apps settings are obviously not this case
[10:51] <Laney> seb128: well, indeed, we wrote a nice library for gsettings didn't we?
[10:52] <Laney> it would be more than 1 line without that ...
[10:52] <seb128> Laney, right ... so we write a nice one for accountsservice? ;-)
[10:52] <Laney> that'd be good
[10:52] <desrt> this is spinning wildly out of control
[10:52] <seb128> that change just feels wrong to me
[10:53] <desrt> we might have encrypted homedirs on the tablet?
[10:53] <seb128> I've trust in gsettings to be good (e.g robust and easy to use), I don't have the same trust in accountsservice
[10:53] <mpt> desrt, seb128: Last week we (charles, ted, and I) deprioritized all the indicator-related work based on who is selected, on the grounds that on Touch it’s pretty hard for an account to be selected without prompting you to log in.
[10:53] <desrt> seb128: accountsservice doesn't call abort()..... yet ;)
[10:53] <seb128> desrt, think convergence, we need to design for the desktop usecase, so yes, we mighgt have encrypted userdirs
[10:54] <seb128> mpt, well, if you use your device as an user and lock the screen that user should probably be the default one you are prompted to unlock if you turn the device back on?
[10:55] <seb128> "turn back on" being "resume from suspend", not a full power down/up cycle
[10:55] <Laney> so what would you do?
[10:55] <mpt> seb128, true.
[10:55] <desrt> seb128: does my desktop ring when i'm not logged in?
[10:56] <Laney> you want the telephony service to read accountsservice
[10:56] <seb128> desrt, if you have a SIM card, I guess so
[10:56] <Laney> u-s-s to write to gsettings
[10:56] <Laney> and ??? to mirror it?
[10:56] <seb128> Laney, is telephony-service a system or user service?
[10:56] <desrt> Laney: stop right there
[10:56] <desrt> you're about to violate The Rule
[10:57] <Laney> desrt: I'm asking seb128 what his design is
[10:57] <Laney> seb128: It runs as the user currently because multi user isn't worked out yet, I guess
[10:57] <seb128> well, the design we have on the desktop with the background is
[10:57] <seb128> - the gsettings key is the canonical config
[10:57] <desrt> desktop background is a great example of a violation of the rule :(
[10:57] <seb128> - nautilus/g-s-d monitor the key and write to a-s when it changes
[10:57] <Laney> I don't think nautilus is a good example
[10:57] <Laney> it's some weird local hack we did
[10:57] <seb128> - all the apps/config UI writes to gsettings
[10:58] <seb128> desrt, what rule?
[10:58] <desrt> seb128: data lives in one place
[10:58] <desrt> 'sync' is bad
[10:58] <Laney> sync 'smells' to me
[10:59] <desrt> i like sleep
[10:59] <seb128> desrt, yeah, what do you do up at 6am...
[11:00] <desrt> seb128: i started writing patches and i couldn't stop
[11:00] <desrt> now that i stopped to talk on IRC i realise that i'm actually very tired
[11:00] <desrt> i think i'm going to go grab a few hours :)
[11:00] <Laney> tata
[11:01] <seb128> ;-)
[11:01] <desrt> one comment first:
[11:01] <desrt> the only sane way to handle the sort of thing that you're proposing, in my opinion, is to do it from inside of dconf itself
[11:01] <seb128> desrt, Laney: ok, you win, let's drop gsettings and use a-s then, I just fear that a-s is going to suck to use for app writers compared to gsettings
[11:01] <desrt> the refactoring dconf got a cycle or two ago makes it pretty easy to support some kind of a plugin system inside the writer service that could do this sort of thing
[11:02] <desrt> ie: have a mapping of dconf paths to account service properties
[11:02] <seb128> that would be nice
[11:02] <desrt> then it's not really a 'sync' exactly
[11:02] <Laney> interesting
[11:02] <Laney> an AS backend?
[11:02] <desrt> because when you write it it's actually writing to both places straight away
[11:02] <desrt> Laney: as a plugin to dconf
[11:02] <ali1234> and what if the user's desktop doesn't use dconf to store settings?
[11:03] <desrt> i'm probably not going to think this is a good idea once i've had some sleep :)
[11:03] <desrt> so there's that....
[11:03] <seb128> ali1234, what is the user uses iOS?
[11:03] <ali1234> iOS doesn';t run on ubuntu, stop with the irrelevant comments
[11:03] <desrt> ta.
[11:03] <seb128> ali1234, not sure the question makes sense, we are talking about a stack we write and we are using dconf
[11:03] <ali1234> i'll make this very clear for you: what if the uses uses xubuntu
[11:04] <seb128> does xubuntu wants a phone edition and reflect session settings on their greeter?
[11:04] <ali1234> no and yes
[11:04] <seb128> in which case they should use dconf
[11:04] <seb128> or figure out another way to do what they want
[11:04] <ali1234> we already have it btw
[11:04] <Laney> neither AS nor this dconf idea I don't really understand would be ubuntu specific
[11:05] <seb128> Laney, they might not want to use dconf apparently
[11:05] <seb128> or AS
[11:05] <ali1234> we currently acieve it using AS
[11:05] <seb128> ali1234, do you use AS as the primary storage? (e.g is your desktop side reading there)
[11:05] <ali1234> no
[11:05] <seb128> or do you write to AS in addition to the "normal config"?
[11:05] <ali1234> yes
[11:05] <seb128> desrt, night btw ;-)
[11:06] <ali1234> xfce stores all settings in xfconf
[11:06] <seb128> ok, so same we do for the background image atm
[11:06] <ali1234> the background selector thing is patched to also write to AS
[11:06] <seb128> ok
[11:06] <seb128> that's a design we don't want
[11:06] <seb128> because then you need to teach every single app that want to change the background to write to AS
[11:07] <seb128> and duplicate that code tons of times
[11:07] <ali1234> well if you replace it with a design that uses dconf, xfce will not be able to use it, and we will have to keep the bad design
[11:07] <seb128> well, you could patch xfconf to do the same thing
[11:08] <seb128> whatever our solution is, it's not going to talk to xfconf anyway
[11:08] <ali1234> true
[11:09] <ali1234> of course that means the xfconf has to know the meaning of the schema
[11:09] <ali1234> same goes for dconf
[11:10] <ali1234> you still have to write a patch for every program that sets the background, but all the patches go into dconf instead of each individual program, and they still have to be kept in sync with the programs, but the developers of the programs won't see the patches
[11:11] <seb128> Laney, I need some time to think about it, I don't like much having to "sync", but I like less replacing gsettings by a-s, especially for something as important as the ringtone (if something bugs in that stacks it might mean you don't receive calls anymore on your phone, which sucks)
[11:12] <seb128> ali1234, why would you have to write patch? atm in ubuntu-desktop we just patch nautilus, it already monitors the gsettings config to update the rendering, we just added a "write to a-s" to the function it calls
[11:13] <Laney> I think you should try and get some evidence for your lack of trust
[11:13] <Laney> I don't share it and I don't know where it comes from
[11:13] <Laney> relatedly, I was kind of surprised to see no fallback code in telephony-service
[11:14] <Laney> don't know what happens if the ringtone gets deleted or something
[11:14] <ali1234> seb128: yes, that same patch is currently in xfdesktop
[11:17] <ali1234> point being if somebody changes the way nautilus handles the wallpaper, then the patch won't apply in ubuntu and somebody will fix it. but not if the patch lives in dconf: then nobody will notice until it breaks on an install
[11:17] <seb128> Laney, ok, fair enough, I guess we should give it a try ... the lack of trust gets from "direct read from a mmap <-> talking to a process over dbus" and from "nice api designed to be nice to app writers <-> raw dbus calls to a service"
[11:17] <seb128> gets->comes
[11:18] <seb128> reading from a mmap is as solid as you can get, dbus roundtrip with another process involved seems more likely to hit bugs
[11:20] <seb128> ali1234, well, configuration keys should never change, but yeah, if that happens somebody will need to update all clients
[11:21] <seb128> Laney, didrocks' new landing process is going to be nice for those changes btw, when we do a landing ask it's going to give us a ppa with the new telephony-service and u-s-s to test ;-)
[11:21] <Laney> heh
[11:50] <seb128> Laney, ok, I made my mind, +1 for using a-s ... if we add fallback code, to play the default sound in telephony-service, in case the config is empty/buggy
[11:51] <Laney> seb128: righto
[11:52]  * Laney just built telephony-service for armhf to test that
[11:52] <Laney> not the default thing, haven't done that yet
[11:53] <Laney> dear phone, please kindly turn on, no love, iain
[12:05] <Laney> decent, it works
[14:20] <seb128> Laney, there is a webkit 2.3.2 -> 2.3.4 update to do, want to do it?
[14:20] <seb128> Laney, I'm just asking because there is a wishlist bug from adam-yorba about it, wondering if I should assign it ;-)
[14:47] <Laney> seb128: will do at some point
[14:47] <Laney> test building on all arches sucks though
[14:47] <seb128> Laney, ok, so I'm assigning the bug to you
[14:47] <Laney> sure
[14:47] <seb128> right, I was pondering just doing a dch -v update and pushing to a ppa just to see what happens
[14:47] <seb128> ;-)
[14:49] <mlankhorst> sure, makes sense
[14:49] <Laney> if you have a ppa which builds for ppc* and arm64 ;-)
[14:49] <Laney> there will be some patch wrangling
[14:50] <mlankhorst> hm speaking of which, I'll need ppc64 and arm64 enabled on x-staging at some point
[15:47] <sil2100> seb128: hi! How do you stand with free time today? You think you'll have a moment for a preNEW review?
[15:48] <seb128> sil2100, you can assume that every day is busy but it doesn't hurt to ask ... what source this time?
[15:48] <seb128> we need a queue for preNEW like for sponsoring etc
[15:48] <sil2100> seb128: it's
[15:48] <sil2100> lp:account-plugin-evernote this time
[15:49] <sil2100> (wild newline)
[15:49] <seb128> sil2100, ok, let me have a look
[15:49] <sil2100> seb128: thank you! :)
[15:49] <seb128> you are lucky, I just caught me at a time where I was done with something and looking for the next thing to pick from my todolist ;-)
[15:50] <sil2100> hah, excellent timing then ;)
[15:52] <seb128> sil2100, there is a typo in the description
[15:52] <seb128> " This plugin enables developers to authenticate to their Evernote developer
[15:52] <seb128>  sanbox account, which allows syncing of Evernote notes across Ubuntu devices."
[15:52] <seb128> sanbox -> sandbox
[15:53] <seb128> sil2100, NEWS and README are empty, no need to list them to install (e.g drop debian/docs)
[15:56] <sil2100> seb128: hah, didn't see that typo - will fix those issues straight away
[15:57] <seb128> sil2100, do we know where the icon is coming from?
[16:02] <sil2100> seb128: I will make sure we know exactly, but from what I see it's our creation right now
[16:03] <sil2100> seb128: it's the Reminders app icon: https://launchpad.net/reminders-app
[16:04] <sil2100> seb128: should I add copyright for this as well? Since I saw that the reminders-app doesn't have it copyrighted under debian/copyright as well
[16:05] <sil2100> seb128: so I thought it's a convention
[16:05] <seb128> sil2100, I'm asking because our artwork is usually CC-BY-SA
[16:05] <seb128> sil2100, but I'm not picky about it
[16:05] <seb128> having it under GPL wfm
[16:05] <seb128> sil2100, otherwise it looks good for NEW, maybe just check with design that the license for the artwork is ok
[16:06] <sil2100> seb128: will do, thank you! Fixing what was pointed out and asking design in a moment
[16:06] <seb128> sil2100, great
[16:13] <sil2100> seb128: https://code.launchpad.net/~sil2100/account-plugin-evernote/more_minor_fixes/+merge/201450 <- in case you want to confirm the fixes ;)
[16:25] <seb128> sil2100, looks good, thanks
[17:33] <GunnarHj> bregma: ping?
[17:33] <bregma> GunnarHj, pong
[17:33] <GunnarHj> bregma: Hi Stephen! Your remark yesterday on the ubuntu-doc list made me curious. Can you give me a pointer to some info on the planned changes for 14.04 on input method handling?
[17:36] <bregma> GunnarHj, we have related blueprint https://blueprints.launchpad.net/unity/+spec/client-1404-unity7-hotkey-handling but nothing specific on IM stuff
[17:36] <bregma> there were problems in 13.10 wih IM and keyboard selection conflicts
[17:39] <GunnarHj> bregma: Indeed there were, and I hope that most of it has been dealt with by now. But as regards IM there have also been discussions on reverting to how things worked in 13.04, or switch to fcitx. I thought that nothing of that will happen, but your list comment made me wonder. ;-)
[17:41] <bregma> we do not plan to switch to fcitx in Ubuntu 14.04 LTS
[17:41] <GunnarHj> bregma: Will the current "Text Entry" UI be just about as it is now?
[17:42] <bregma> GunnarHj, we have some IM changes in Unity pending upstream
[17:42] <attente> bregma, GunnarHj, i have a ppa that should fix some of the problems
[17:43] <attente> https://launchpad.net/~attente/+archive/gnome-key-grabber
[17:43] <GunnarHj> Thanks, attente!
[17:44] <GunnarHj> attente: One thing I'm wondering about is the default keyboard shortcuts for switching input source. Currently they involve the "Super" key which does not work.
[17:45] <attente> GunnarHj, they'll work with the ppa, but the super key still also activates simultaneously
[17:46] <attente> so you'll see the launcher numbers the same way the super key is held down
[17:46] <attente> and possibly the shortcut help screen
[17:46] <GunnarHj> attente: Wouldn't Alt+Shift be a better default?
[17:47] <GunnarHj> attente: Less confusing...
[17:48] <attente> GunnarHj, i'm not sure tbh... it seems like a lot of the non-latin guys want something like that, while the cjk guys prefer something like modifier+space
[17:49] <GunnarHj> attente: Ok... What's most important, of course, is that the default works.
[17:49] <GunnarHj> attente: Should I install all those four packages to test?
[17:49] <attente> GunnarHj, right
[17:49] <attente> GunnarHj, sure, if you're up for testing the ppa, by all means
[17:50] <GunnarHj> attente: Will do. Somehow I got myself involved in this mess (via ubuntu-docs). ;-)
[17:51] <attente> GunnarHj, heh
[18:32] <GunnarHj> attente: I tested your PPA, and can confirm that Super+Space works with those packages.
[18:33] <attente> GunnarHj, thanks
[18:45] <xclaesse> dunno who to ask, but what's the plan regarding kdbus in ubuntu ?
[18:45] <xclaesse> as I understand it needs a bit of userspace in systemd
[18:46] <xclaesse> will ubuntu implement its own ?
[19:14] <Delemas> After a 13.04 to 13.10 upgrade my server logs are getting spammed every 6 seconds by systemd-logind as per: http://pastebin.ca/2535595 This happens even when user isn't logged in. Anyone know why?
[19:47] <Delemas> Nevermind I found the cause... Monitoring service run amok...