=== _salem is now known as salem_
[09:02] <Saviq> mzanetti, hmm, icon data is stored in accountsservice directly is it?
[09:02] <mzanetti> Saviq: need to check, one sec
[09:03] <mzanetti> Saviq: yes
[09:03] <Saviq> mzanetti, not great, means old icons in launcher when they get updated :/
[09:04] <mzanetti> Saviq: yes...
[09:04] <mzanetti> Saviq: but I can't access stuff from the greeter session otherwise
[09:05] <Saviq> mzanetti, we might need to refresh the data on startup though
[09:05] <mzanetti> hmm... I think I acutally do that... it's been a while
[09:06] <mzanetti> Saviq: no. I don't atm
[09:06] <Wellark> hey, how can I run a single test under qmltest directory ?
[09:06] <Wellark> from a local checkout
[09:06] <Saviq> Wellark, make -C builddir testFoo
[09:07] <Saviq> mzanetti, yeah, I'll file a bug
[09:07] <Saviq> mzanetti, we should also hook up to app upgrades
[09:08] <Wellark> Saviq: cool. thanks
[09:08] <Saviq> mzanetti, can I ask you to review https://code.launchpad.net/~renatofilho/unity8/blue-led/+merge/224899
[09:16] <mzanetti> Saviq: hmm... wouldn't be some telepathy stuff the better place for this?
[09:16] <Saviq> mzanetti, that's temporary
[09:16] <mzanetti> ok
[09:17] <Saviq> mzanetti, we'll have a central notification place at some point, telepathy isn't enough either
[09:22] <Wellark> Saviq: could I get somebody to take a quick look https://code.launchpad.net/~unity-api-team/unity8/modeminfo/+merge/225159
[09:25] <Saviq> Wellark, the components should probably go to lp:ubuntu-settings-components
[09:25] <Saviq> Wellark, and actually you might be able to just use Menus.StandardMenu from https://code.launchpad.net/~unity-team/ubuntu-settings-components/suru-theme
[09:25] <Saviq> Wellark, it's landing with the suru theme in a few moments
[09:26] <Saviq> dednick, looks like this would fall on your plate ↑
[09:27] <Saviq> Wellark, hmm or maybe not, you have two icons on the left
[09:27] <dednick> Saviq: yeah. i just saw it this morning
[09:28] <dednick> Saviq: custom item
[09:29] <dednick> Wellark: that needs to go into lp:ubuntu-settings-components
[09:43] <Wellark> dednick: could we move it there if we actually need it somewhere else. it's indicator-network related custom component and will not be used anywhere else
[09:43] <dednick> Wellark: it will most likely be in settings as well.
[09:44] <dednick> Wellark: there are no menu components in unity8 anymore.
[09:44] <Wellark> dednick: settings display the information in an entirely different manner as there is actually room there. this is purely an indicator thing
[10:00] <dednick> Wellark: is there a spec for this item anywhere?
[10:07] <Saviq> mzanetti, is there a way we can affect colour of the header icons?
[10:07] <mzanetti> Saviq: it's uitk's Action component. Don't think it has an api for that.
[10:07] <Saviq> ok, we'll need it
[10:07] <mzanetti> Saviq: the back button is even hidden inside the PageHeadStyoe
[10:08] <mzanetti> Saviq: so when the dash becomes an app, it won't inherit shell's theme any more
[10:08] <mzanetti> Saviq: will we still need it then?
[10:09] <Saviq> mzanetti, yes, scope authors need to have control over that
[10:09] <mzanetti> ok
[10:09] <mzanetti> Saviq: yeah. I guess we'd need to talk to timp
[10:09] <mzanetti> Saviq: will you or should I take care of that?
[10:09] <Saviq> mzanetti, already talking
[10:09] <mzanetti> ack
[10:12] <Wellark> dednick: no, there is none. I discussed this item with mpt at Malta and we agreed that I will cook it up so that we can get the information to the indicator. I will attach the related bug reports to the MP.
[10:12] <dednick> Wellark: https://docs.google.com/a/canonical.com/document/d/1OyHUg_uUfmhDNa-9UrMc1tZ_eH_99PEU_V2l1YFA1UY/edit#
[10:13] <dednick> Wellark: i've commented on your MP
[10:14] <dednick> mzanetti: do we have sim unlock in the greeter now?
[10:14] <mzanetti> dednick: define "in the greeter"
[10:15] <dednick> uuuh. in the greeter screen. ie forced to unlock before get into dash
[10:15] <mzanetti> dednick: so it won't be "in" the greeter, but yes, it should pop up behind the greeter so you'd get there when swiping the greeter away
[10:15] <dednick> mzanetti: because apparently that's a requirement.
[10:16] <mzanetti> dednick: its not there yet, no
[10:16] <dednick> mzanetti: right.
[10:16] <mzanetti> dednick: faik Wellark was to take care of that
[10:16] <mzanetti> afaik
[10:17] <dednick> mzanetti: ok. it's apparently not supposed to be part of indicators. guess we added that as a temp patch
[10:17] <dednick> Wellark: ^
[10:17] <mzanetti> dednick: so all it takes is to fire a notification
[10:17] <mzanetti> my last information was the indicators were supposed to do that... but its been a while
[10:17] <mzanetti> I think Saviq has the full plan on it
[10:19] <Saviq> mzanetti, dednick, yeah the button was temporary, and yes it's supposed to show before the greeter, not sure if cancellable though
[10:20] <mzanetti> Saviq: Olga revised Katies decision to show it before the greeter
[10:20] <dednick> Saviq, mzanetti: apparently not. requirement for german operators to enter sim to get to phone.
[10:20] <dednick> "to phone" - being to be able to use any part of phone
[10:20] <Saviq> dednick, interesting, Nokia didn't get the memo then ;)
[10:20]  * mzanetti has a hard time to believe that
[10:21] <Saviq> dednick, and it's stupid, too - just take the SIM card out and you're in
[10:21] <dednick> JohnLea: ^
[10:21] <dednick> heh. true
[10:22] <dednick> perhaps not germany. he did say "I think"
[10:23] <dednick> aaaanyway..
[10:23] <mzanetti> dednick: still, the button in the indicators needs to stay I think
[10:24] <mzanetti> dednick: if you cancel the dialog, you still want a way to introduce the pin later
[10:29] <JohnLea> dednick, mzanetti, Saviq; hyia, minor adjustment from my conversation with dednick earlier; the only place users will be able to unlock the SIM PIN is via the screens and designs that I shared with dednick, but this does not necessarily need to block the user from entering the phone as long as when a SIM PIN is needed we can display the relevant screen from the designs I shared and then return the user to where they were.  However if
[10:29] <JohnLea>  this is not possible for RTM it is ok to require the user to enter the SIM ping before logging into the phone (if this makes you life easier)
[10:40] <Wellark> JohnLea: umm, which design are you talking about, just to be sure?
[10:40] <dednick> Wellark: https://docs.google.com/a/canonical.com/document/d/1VajNkWbBH61iVixXJAmOvNGiG__GWQTMXGNOZijXWJw/edit#heading=h.dxyj97l61sl7
[10:40] <dednick> it's the greeter design
[10:45] <Wellark> dednick, mzanetti, Saviq: indicator-network will have to have the SIM Unlock button in the future, too, as already stated that the user might just cancel the sim unlock dialog on the first time
[10:46] <mzanetti> yep, makes sense to me
[10:46] <Saviq> Wellark, I agree, it should be triggered automatically by some events (like trying to call a non-emergency number or so)
[10:47] <Saviq> Wellark, but indeed a clear button to do so is needed, too
[10:47] <Wellark> dednick: where can we get more info on this requirement from german operators
[10:47] <Saviq> just a second ago I cancelled the dialog on my N9 accidentally and I had to pop the SIM out and back in, had no idea how to unlock otherwise
[10:47] <Wellark> sounds like there might be some misunderstanding going on with that requirement..
[10:48] <dednick> Wellark, Saviq, mzanetti: so we're just going to ignore what the designers say?
[10:48] <Wellark> SIM code != general lock code
[10:48] <Saviq> dednick, where does it say the button should not be there?
[10:48] <dednick> i'm not saying it's wrong. but we'll have to re-work if it is
[10:48] <dednick> JohnLea just said so. and https://docs.google.com/a/canonical.com/document/d/1OyHUg_uUfmhDNa-9UrMc1tZ_eH_99PEU_V2l1YFA1UY/edit#
[10:49] <Saviq> dednick, I don't think that's what JohnLea said, he just said those are the screens to unlock, not how to get to that screen in case you dismissed it
[10:50] <Saviq> dednick, that document doesn't cover that use case AFAICT, is all
[10:50] <dednick> "the only place users will be able to unlock the SIM PIN is via the screens and designs that I shared with dednick" and "as long as when a SIM PIN is needed we can display the relevant screen from the designs"
[10:51] <JohnLea> Saviq, dednick; ideally for RTM if the user needs to unlock a SIM at a later date they should be directed to the greeter screens https://plus.google.com/hangouts/_/canonical.com/toolkit-sync and then back to where they were
[10:51] <mzanetti> JohnLea: sure... it'll always be the same pinentry screen
[10:51] <mzanetti> JohnLea: we're talking about how to open it again if it got dismissed when it popped up automatically
[10:52] <Saviq> JohnLea, you don't want to show it on every unlock after it's dismissed do you?
[10:52] <Saviq> so there needs to be a way to trigger the SIM entry UI
[10:52] <JohnLea> Saviq; that can be set in System Settings I think, one sec I'll find the design
[10:52] <Wellark> JohnLea: SIM PIN != lock code
[10:53] <JohnLea> Wellark; of course!
[10:53] <Wellark> looking at the greeter spec it seems to handle SIM PIN the way it should handle lock code
[10:53] <Wellark> or am I missing something
[10:53] <dednick> Wellark: it does both.
[10:53] <mzanetti> Wellark: well, its the same dialog
[10:53] <JohnLea> Wellark; yes, they are different things, but they are handled in a very similar way
[10:53] <JohnLea> very similar dialog
[10:54] <Wellark> so what happens when the user boots up, sees the greeter, sees the <<unlock>> there, swipes the greeter open and then cancels the SIM unlock dialog?
[10:55] <Wellark> JohnLea: ^
[10:55] <dednick> JohnLea: i think having quick access button on indicator menu for locked sims wouldn't be a bad thing. Problem with the idea that "if you want to use your phone, then pop up SIM unlock" is that you can't receive calls either. Don't think the user should be prompted for SIM pin every time they use the greeter.
[10:56] <Saviq> +1
[10:57] <Saviq> JohnLea, btw, should I add a ubuntu-ux task for purely visual bugs as well? bug #1336731
[10:57] <ubot5> bug 1336731 in Unity 8 "Sticky headings when scrolling the dash should have some visible separation from the icons that slide under them." [Undecided,New] https://launchpad.net/bugs/1336731
[10:59] <mzanetti> dednick: I very often intentionally not unlock the sim to not be reachable... but still want to use the phone as a music player.... so if it were me, I wouldn't pop it up every time automatically
[10:59] <mzanetti> but that's just my 2 cents... I guess I would survive it would do so too
[11:01] <JohnLea> dednick; the SIM PIN settings are shown at https://wiki.ubuntu.com/SecurityAndPrivacySettings#Phone  By default a user only ever needs to enter the SIM PIN one time, however in Germany there are different regulations, so the option to for the user to enter the SIM PIN after switching on the phone in order to use the SIM will be switched on
[11:02] <mhr3> Saviq, can you or someone take a look at https://code.launchpad.net/~unity-api-team/unity-api/scope-settings-shell/+merge/225287 pls?
[11:02] <JohnLea> Saviq, yes, add ubuntu-ux for visual bugs as well, thanks!
[11:03] <facundobatista> Holas
[11:03] <mzanetti> buenos dias
[11:06] <sil2100> bregma: hi! Could you give me a ping once you're around?
[11:06] <bregma> sil2100, sure
[11:07] <bregma> sil2100, ping
[11:07] <sil2100> bregma: ;) :D So, I have a question about the compiz landing that's set to Testing: Done right now
[11:07] <sil2100> Silo 10
[11:07] <sil2100> bregma: since I already saw a compiz SRU for trusty in -proposed
[11:07] <bregma> yes, we had to respin the package
[11:07] <sil2100> bregma: ok, so I'll just re-publish it again then
[11:07] <sil2100> Thanks
[11:08] <bregma> sil2100, thanks, we've already been in touch with SRU people, but it was a holiday here yesterday so the middle bits were neglected
[11:13] <Saviq> mhr3, no api version bump?
[11:15] <mhr3> Saviq, needs fixing i guess
[11:15] <mhr3> Saviq, was mostly a question if you're happy with such interface
[11:16] <Saviq> mhr3, looks fine from what I can tell
[11:16] <Saviq> mhr3, properties will be a QVariantMap I assume?
[11:16] <mhr3> pete-woods, ^?
[11:17]  * mhr3 still needs to look at the actual impl
[11:22] <Saviq> /food, then new header
[11:22] <Saviq> mhr3, fyi, new UITK release will happen just after suru, so we won't be blocked by that
[11:23] <Saviq> *but* sil2100 is chicken and doesn't want to release suru into the same image as new Mir
[11:23] <sil2100> :|
[11:24] <Saviq> ;P
[11:24] <sil2100> I'm not chicken... :|
[11:24] <sil2100> ;)
=== MacSlow is now known as MacSlow|lunch
[11:27] <pete-woods> Saviq: yes, the properties is just boring variant map
[11:44] <dandrader> mzanetti, is there an app that visibly changes when I press the volume keys?
[11:44] <pete-woods> Saviq: if you're interested in the API usage, I have a "developer UI" (i.e. crappy QML) here http://bazaar.launchpad.net/~unity-api-team/unity-scopes-shell/scope-settings/view/head:/tools/settings/Settings.qml
[11:44] <dandrader> mzanetti, i.e., showing in its UI in response to the presses
[11:44] <mzanetti> dandrader: don't think so... I tested with xbmcremote which would changes my living room's volume when the buttons work
[11:45] <mzanetti> dandrader: but you'd need xbmc running somewhere for that
[11:45] <dandrader> mzanetti, np, will write a simple qml app then
[11:45] <mzanetti> ok
=== MacSlow|lunch is now known as MacSlow
=== alan_g is now known as alan_g|lunch
=== dandrader is now known as dandrader|afk
[12:28] <larsu> dednick: hey man, how's it going?
[12:29] <larsu> dednick: did you see https://code.launchpad.net/~larsu/indicator-messages/add-simple-dbus-api ?
[12:29] <larsu> I'm starting to think we should have this API in unity itself and handle notifications and messaging menu with it
[12:29] <larsu> (this or something similar)
=== dandrader|afk is now known as dandrader
=== _salem is now known as salem_
=== alan_g|lunch is now known as alan_g
[13:05] <dednick> larsu: hey. havent seen it.
[13:08] <kgunn> dandrader: mzanetti greyback_ miracles never stop...mir040 landing in archive atm...so later today we can jettison mir out of rightedge ppa
[13:08] <dednick> larsu: so that is a dbus menu to add messages to the menu model in indicator-messages?
[13:08] <dandrader> kgunn, finally :)
[13:08] <greyback_> kgunn: yay!
[13:08] <dednick> larsu: dbus api i mean
[13:09] <larsu> dednick: exactly, but without all the baggage that we needed for the desktop's messaging menu
[13:10] <larsu> and I think going through a gmenumodel for this just makes it more complicated
[13:10] <dednick> larsu: right. why would it be exposed by unity8? That means that any app using it would need to be using unity8
[13:10] <larsu> since we could use the same api for notifications (which uses org.freedesktop.Notification right now)
[13:10] <dednick> rather than indicator-messages
[13:10] <larsu> ya, that's my point
[13:11] <larsu> basically, I want notifications and messaging menu to become the same thing from an apps pov
[13:11] <dednick> larsu: by notification you mean?
[13:11] <larsu> ah sorry, bubble notifications
[13:11] <larsu> and snap decisions
[13:12] <larsu> snap decisions look exactly the same as entries in the messaging menu on the phone
=== MacSlow_ is now known as MacSlow
[13:14] <dednick> larsu: mmmm. are you meaning that we don't go through indicator-messages at all?
[13:14] <larsu> ya
[13:15] <larsu> dednick: if we go this way (notification center style I mean), indicator-messages would only contain code to convert between two kinds of APIs
[13:15] <larsu> might as well have this in unity8 directly
[13:15] <larsu> especially considering that we already have a notification api in unity8
[13:15] <dednick> larsu: so why would we add the complication of 2 paths into unity8 messaging menu?
[13:16] <dednick> and 2 paths into notifications
[13:16] <larsu> that's what we have now, I want to consolidate it into one
[13:16] <larsu> an app now has to talk libmessaging-menu and libnotify
[13:16] <larsu> and feed both with exactly the same data
[13:17] <larsu> what I'm proposing is that we only have this new api for both of them
[13:17] <larsu> and deprecate everything else
[13:17] <larsu> and since then indicator-messages would only do something  very trivial, get rid of that too
[13:19] <larsu> just throwing this idea out there for now, I haven't talked to all the relevant people yet
[13:19] <larsu> (but I guess this is the start of it)
[13:20] <mzanetti> uuhhh... nasty Qt 5.3 bug (I suppose its qt 5.3): scrolling on unity8's launcher with the mouse wheel scrolls the launcher *and* the dash behind it
[13:22] <dednick> larsu: gmenumodel business?
[13:22] <larsu> dednick: hm?
[13:23] <dednick> larsu: the message menu is described as a gmenuodel
[13:24] <larsu> dednick: in other news, Chipaca pointed out a bug in the messaging menu: you can't "open" the message below the one you've just activated
[13:24] <larsu> dednick: right, I don't think it's that beneficial to us anymore
[13:24] <larsu> hm, untiy8 segfaults when I close it
[13:25] <dednick> larsu: by open/activate, do you mean expand?
[13:25] <larsu> dednick: by open I mean expand, by activate I mean click on the app icon
[13:26] <dednick> larsu: when you click the app icon, it should open the app.
[13:27] <Chipaca> dednick: put two messages on there, expand the top one and click the app icon
[13:27] <dednick> oh. other way around
[13:27] <Chipaca> dednick: the second one moves up, but it seems to get stuck in a weird state, you can no longer expand it
[13:28] <dednick> Chipaca: hm. mine is ok
[13:28] <dednick> well, when i click on the app icon my indicators dissapear
[13:28] <larsu> right, you need to reopen it :)
[13:29] <Chipaca> yeah, i skipped that bit :)
[13:29] <dednick> Chipaca: ah. yeah, true.
[13:29] <dednick> Chipaca: need to expand another one first
[13:30] <dednick> Chipaca: i think the model thinks it's still expanded
[13:30] <Chipaca> without knowing the code, that's what it looked like, a model and view out of sync
[13:32] <dednick> larsu: and as for the api, think you're asking alot there :) It will be a lot of work which we don't "really" need right now.
[13:34] <larsu> dednick: Chipaca is having trouble implementing push notifications with the messaging-menu API, this would help him a lot
[13:34] <larsu> dednick: and the same will happen for sdk guys trying to expose both the messaging menu and libnotify to applications
[13:34] <larsu> dednick: I'm not saying we need to do the full-on switch now
[13:35] <larsu> which is why I've added it to indicator-messages for now
[13:35] <larsu> as a transition
[13:35] <larsu> but before we decide to merge it, I want to make sure we're all on the same page on how to go forward
[13:36] <dednick> larsu: I don't think it can be in unity8 process though.
[13:37] <dednick> larsu: will need it in greeter.
[13:37] <dednick> as well i mean
[13:37] <larsu> does greeter have bubble notifications? The same would apply to those, no?
[13:38] <dednick> larsu: don't know about notifications.
[13:38] <larsu> dednick: who does?
[13:38] <larsu> Saviq: ?
[13:38] <Saviq> larsu, there's only a single layer of notifications now
[13:39] <Saviq> larsu, we did have two when we split the greeter, but we reverted that
[13:39] <dednick> same with indicators i guess
[13:39] <dednick> but will be split.
[13:40] <Saviq> larsu, and ultimately I'm after actually only having one layer of notifications, common for everything, syncing them between greeter and session proved real error prone
[13:41] <Saviq> we may need one per user, there's investigation to eb had
[13:41] <Saviq> be
[13:41] <larsu> Saviq: what do you mean by layer?
[13:41] <larsu> having it in a separate process?
[13:41] <Saviq> larsu, no, rendered by the greeter session
[13:42] <larsu> right, but where does it get the data from?`
[13:42] <larsu> accountsservice?
[13:42] <Saviq> larsu, it will have to get it from the sessions, multiplex with its own
[13:43] <Saviq> there's advantages and disadvantages, but I think we can cope
[13:46] <larsu> Saviq: makes sense to me. I was just talking to dednick about combining notifications and the messaging menu, since snap decisions look exactly the same as entries in the messaging menu
[13:46] <larsu> Saviq: and then letting unity8 handle both of them, without the indicator as a middle man
[13:46] <larsu> do you have any thought on that?
[13:47] <Saviq> larsu, I think the whole PostOffice approach would facilitate that
[13:47] <Saviq> larsu, and yeah, don't think there needs to be an indicator in between
[13:47] <Saviq> larsu, but that's far away
[13:49] <larsu> Saviq: I've proposed a branch for indicator-messages to help the transition (so that applications / push notification service can already use a simpler API to get stuff into the messaging menu)
[13:49] <larsu> Saviq: I also don't know how the post office would help here. That's just another consumer of the api, no?
[13:49] <Saviq> larsu, that's the only thing the app would talk to
[13:50] <Saviq> larsu, whether that message would result in bubble, bubble+menu entry, menu entry alone, the post office would decide
[13:50] <dednick> i think it would work well for notifications, but would need some way for the data to live between greeter/unity sessions for messages.
[13:50] <larsu> Saviq: and the post office talks to unity how?
[13:50] <Saviq> larsu, I wouldn't want to introduce a temporary API like this unless we have a longer-term plan that this aligns with
[13:51] <Saviq> larsu, whatever we say works
[13:51] <larsu> Saviq: that's what I'm discussing right now..
[13:51] <Saviq> larsu, I won't have time to discuss this properly for a few weeks at least still
[13:54]  * Saviq hates Qt for the doc url mess, had to remove all related history >:[
[13:55] <larsu> Saviq: I'm bringing this up now because it's quite hard to integrate with the messaging menu right now and I'm afraid we're wasting some people's time
[13:56] <Saviq> larsu, is that a public API on the phone anyway? or is this about push?
[13:56] <Saviq> public/supported
[13:57] <larsu> Saviq: not public, but for the push guys to use (and later the sdk guys if we ever decide to let apps issue notifications)
[13:58] <Saviq> larsu, yeah, the "later" part is something that will require the PostOffice discussion to happen properly for sure, if the API is just for push consumption, I'm fine with that
[13:59] <Saviq> larsu, whether it's going to be a separate process later that will expose the same / similar API and then communicate that to the shell, or just a library shell will load I've no strong opinion on, both works just fine
[14:00] <larsu> Saviq: right, that's what I'm thinking. It would even live in indicator-messages at first (for the transition)
[14:00] <larsu> I did call it com.canonical.Notifications though
[14:00] <larsu> not sure if that's what we want
[14:00] <larsu> I do like the thought of merging notifications and this, though
[14:01] <Saviq> larsu, it's internal API for push consumption alone, not *really* important
[14:01] <Saviq> larsu, sure, completely agree, but not *now* ;)
[14:03] <larsu> Saviq: okay, understood :) I do find it a bit odd with how low of a priority everyone treats notifications and the messaging menu
[14:04] <Saviq> larsu, it's not low priority, they just work good enough as they do now, no significant work has been planned on those for first release
[14:04] <Saviq> larsu, we're driven by business and design req, nothing came on that topic from there
[14:06] <larsu> Saviq: that's my point. "nothing came from there"
[14:07] <Saviq> larsu, must mean it's purrfect, what you complain about!
[14:08] <larsu> Saviq: :) I don't know. I don't think it's good enough at all. Do we have apps other than phone that puts stuff into the messaging menu?
[14:09] <Saviq> larsu, you know lifecycle prevents that on the phone anyway
[14:09] <Saviq> so not a huge prio
[14:13] <sil2100> seb128, Saviq: I can also publish the suru silo now if you want, but only on your resposibility! What's in that silo? Is that only some path change for the themes or something more complicated?
[14:13] <Saviq> sil2100, the default icon theme changed, icons got updated in apps, unity8 and settings had some adaptations to new icon sizes
[14:14] <Saviq> sil2100, I can take on the responsibility if you need me to
[14:14] <Saviq> whoa it's 4pm already
[14:14] <larsu> Saviq: lifecycle prevents it because we have a bad API. Why do we have push notifications anyway if this doesn't work?
[14:15] <Saviq> larsu, what doesn't work? push notifications are not lifecycled, push is exactly one way to "escape" lifecycle
[14:17] <larsu> Saviq: ah, the idea is that apps can only notify about something via push for now?
[14:17] <Saviq> larsu, yes
[14:18] <Saviq> larsu, if they're focused, they shouldn't even use notifications / messaging menu as... they're focused
[14:18] <Saviq> larsu, and if they're not focused, they're suspended, so they can't do it anyway
[14:19] <Saviq> larsu, so system services / push are the only way to issue notifications / messaging menu items
[14:20] <larsu> Saviq: fair enough, thanks
=== alan_g is now known as alan_g|tea
[14:33] <karni> mhr3_: I could have done something wrong, but I wouldn't expect to meet an assertion in scoperegistry :) Any ideas what could have gone wrong? http://paste.ubuntu.com/7737096/
[14:34] <mhr3_> karni, display name unset for a new scope?
[14:35] <karni> mhr3_: you're right, I'm using cmake to configure the ini file, and removed the setting SCOPE_TITLE from my CMakeLists, thanks
[14:39] <dandrader> Saviq, completely forgot about that indicators mp review
[14:40] <Saviq> dandrader, I'd have pung you, but the afternoon crept up on me
=== mhr3_ is now known as mhr3
=== dandrader is now known as dandrader|lunch
=== gatox is now known as gatox_lunch
=== alan_g|tea is now known as alan_g
=== alan_g is now known as alan_g|EOD
[17:08] <mhr3> Saviq, yey, cache-control in production for the click apps server
=== gatox_lunch is now known as gatox
=== dandrader|lunch is now known as dandrader
[17:26] <mzanetti> Saviq: still around?
=== boiko_ is now known as boiko
[18:07] <Cimi> Saviq, you know where ApplicationManager.keyboardVisible is defined? (real one, not mocks)
[18:08] <greyback_> Cimi: it's in unity-mir
[18:08] <greyback_> Cimi: I thought you were going to ask me tomorrow
[18:08] <eridu> hey everyone; I'm seeing a regression in Unity in the HUD alt-tap behavior
[18:09] <Cimi> greyback_, I grep for it and nothing appears
[18:09] <eridu> after upgrading to 14.04, the HUD started being launched even if I used a key chord like alt-b or alt-f as long as the tap is short enough
[18:09] <eridu> should I report this as a bug, or is there anything I could do first to ensure it wasn't my own system?
[18:10] <greyback_> Cimi: right you are. It's long gone
[18:11] <Cimi> greyback_, wondering how the shell works then...
[18:11] <greyback_> eridu: I say you should log it as a bug
[18:11] <eridu> greyback_: how do you recommend doing that? is there an apport line I should run so that all the right information gets harvested?
[18:12] <Cimi> greyback_, we have this piece of code in the shell is doing nothing
[18:13] <greyback_> Cimi: so I see. OSKController is only thing managing keyboard as far as I know
[18:13] <greyback_> Cimi: dead code I guess
[18:13] <greyback_> 4menot4U
[18:13] <greyback_> bollocks
[18:13] <Cimi> greyback_, so why the shell has input filtering under osk?
[18:13]  * greyback_ changes password
[18:16] <Cimi> tomorrow...
[18:16] <greyback_> Cimi: lp:unity-mir src/modules/Unity/Application/OSKController.qml
[18:16] <greyback_> that should be doing all you need, but yes tell me tomorrow what's wrong
[18:21] <dandrader> greyback_, have you been able to successfully use QLoggingCategory filtering yet?
[18:22] <greyback_> dandrader: I did ages ago with a test. But I've not tried it since. Note that all messages are enabled by default so far
[18:22] <Saviq> mzanetti, back
[18:22] <dandrader> yeah, that I know
[18:22] <mzanetti> Saviq: reading through the merge... you often comment the import version bump
[18:23] <mzanetti> Saviq: I asked sdk people and asked if they think its a problem if I have mixed stuff from e.g. Ubuntu.Components 0.1 and ..Themes 1.1
[18:23] <mzanetti> Saviq: they said I shouldn't do that, and we should update to 1.1 in general
[18:24] <mzanetti> Saviq: so I bumped it at least every where where I touched the import statements anyways
[18:24] <Saviq> mzanetti, hmm I don't think it matters as long as you have the right imports in the right places
[18:24] <Saviq> mzanetti, and for migration to 1.1 let's just do a separate MP just for that
[18:25] <mzanetti> Saviq: as albert said, I don't think auto bumping everything to 1.1 is a good idea
[18:25] <mzanetti> or well in general auto updating qml imports
[18:25] <mzanetti> I would think that when we touch them anyways in code we test we should upgrade them
[18:25] <mzanetti> but not doing one batch that doesn't get enouch attention to each and every one
[18:26] <mzanetti> it probably doesn't really matter now for uitk 0.1 -> 1.1
[18:26] <mzanetti> but we should figure a strategy for this
[18:26] <mzanetti> Saviq: want me to revert all the import changes then?
[18:26] <Saviq> mzanetti, dunno, I just wouldn't touch them unless needed, I can't see how that would be a problem
[18:27] <Saviq> mzanetti, all those that are not required I think yes, no need to touch them AFAICT
[18:27] <Saviq> mzanetti, if it was the problem to have them mixed, it doesn't matter if you change in 5 places but not in 50
[18:27] <mzanetti> ok
[18:28] <Saviq> mzanetti, imports don't propagate across files, so the fact that you need 1.1 somewhere means that you just need 1.1 in that particular file
[18:28] <mzanetti> sure... I know that
[18:28] <Saviq> mzanetti, singletons are interesting actually
[18:29] <mzanetti> I just had the import theme pretty much everywhere at some point. that's why I bumped the other components to 1.1 too
[18:29] <Saviq> mzanetti, I think wherever you use singletons you need to bump all at the same time
[18:29] <mzanetti> cause I'd say we agree that if theme 1.1 is needed, the components should be 1.1 too
[18:29] <Saviq> mzanetti, sure, where there is themes 1.1, components in sync
[18:29] <Saviq> mzanetti, but if there's nothing 1.1 required, let's leave them be
[18:30] <Saviq> mzanetti, I think singletons are an exception - you need to bump all uses, otherwise you'd probably end up with separate files
[18:30] <mzanetti> Saviq: I still think it would be better to upgrade them like this... but your call. gonna revert the changes
[18:30] <Saviq> mzanetti, but what's the advantage?
[18:30] <mzanetti> Saviq: esp for QtQuick, I wouldn't want to do the one commit that bumps 2.0 to 2.2
[18:31] <mzanetti> but I would be ok with upgrading the parts I touch anyways
[18:32] <mzanetti> aanyways. will add the singleton and see what's left
[18:33] <Saviq> mzanetti, right now I have the feeling that it's best to only bump when we actually need the changes, I don't see much of a difference between bumping them all at once or bumping without the need
[18:33] <Saviq> mzanetti, truth be told we should ask Simon/Alan if they thought about that
[18:34] <mzanetti> hmm... ok... I would have said its better to keep up to date instead of having 2.0 and 2.10 mixed at some point
[18:34] <Saviq> mzanetti, there's a flaw in that approach, though - what if we don't touch a file between now and 2.10
[18:34] <Saviq> it'll be at 3.0 still
[18:35] <Saviq> 2.0
[18:35] <mzanetti> sure...
[18:35] <Saviq> and then we need auto-bump anyway
[18:35] <mzanetti> but then its not many any more which could bring potential issues
[18:35] <Saviq> we could bump in waves, too
[18:35] <Saviq> like per component
[18:36] <mzanetti> ok well... lets just think about it and discuss that again when albert is back. I'm sure he has an opinion on it
[18:36] <Saviq> yeah
[18:36] <mzanetti> for now I do what you told
[18:44] <om26er> Hi! can anyone please review my test branch for unity8 ?
[18:44] <om26er> https://code.launchpad.net/~om26er/unity8/launcher_integration_test/+merge/224701
[18:45] <om26er> We need this in for a UX test.
[18:46] <Saviq> om26er, hey, we're a bit swamped for reviews, it's not like we singled out yours to leave rotting
[18:46] <Saviq> om26er, we'll definitely get to it
[18:47] <om26er> Saviq, ok.
[18:47] <Saviq> om26er, it's not too big either, so it shouldn't take too long
[18:47] <dandrader> Saviq, btw, nick set his https://code.launchpad.net/~nick-dedekind/unity8/indicator.call-hint/+merge/218627 as "work in progress". so I think I got away with it for now :)
[18:48] <Saviq> dandrader, looks Needs review to me?
[18:48]  * dandrader checks again
[18:49] <dandrader> oh right, that was on jun 30. don't know why I didnt get the next status update e-mail
=== salem_ is now known as _salem