[08:20] <Saviq> didrocks, hey, could you have a look at https://code.launchpad.net/~aacid/unity8/killqt51/+merge/217055, we're dropping support for Qt < 5.2.1, should we add (>= 5.2.1) to all the qt build deps, even though qt's own deps would force it anyway?
[08:24] <didrocks> Saviq: yeah, better to be explicit and have that for all build-deps/deps you depend on Qt
[08:25] <Saviq> tsdgeos, ↑
[08:25] <tsdgeos> ?
[08:25] <Saviq> tsdgeos, like qtdeclarative5-private-dev
[08:26] <tsdgeos> ok
[08:26] <tsdgeos> looks a bit unneeded to me tbh
[08:26] <tsdgeos> but ok
[08:26] <Saviq> tsdgeos, is just explicit, is all
[08:26] <tsdgeos> man with me adding N/A to packaging :D
[08:26] <Saviq> tsdgeos, OTOH we could say we want it only where we really require new Qt
[08:26]  * tsdgeos hides
[08:26] <Saviq> ;D
[08:27] <tsdgeos> i mean i didn't add it to the others since it was just cascading
[08:27] <Saviq> tsdgeos, yeah I understand, that's the question I asked to Didier
[08:27] <tsdgeos> you can't have qtbase5-private-dev 5.1 if you have qtbase5-dev (>= 5.2.1)
[08:27] <Saviq> tsdgeos, so qtbase5-dev, qtdeclarative5-dev, -private-dev, those are the three we really require atm
[08:28] <Saviq> tsdgeos, when we start importing QtQuick 2.2, we'll add it to qtquick2-plugin
[08:28] <tsdgeos> ok
[08:29] <Saviq> all the others I think we could still have 5.0, right?
[08:29] <Saviq> qtbase5-private-dev, too
[08:29] <Saviq> (should be >= 5.2.1
[08:29] <Saviq> )
[08:30] <tsdgeos> Saviq: i think so, yes
[08:30] <Saviq> so yeah, let's be meaningful about it
[08:30] <tsdgeos> pushed
[08:30] <Saviq> sure the net result is going to be the same
[08:31] <Saviq> tsdgeos, re: import 2.0 vs. 2.2, think importing two different versions of QtQuick will be more costly than just using the same across the board?
[08:32] <tsdgeos> Saviq: don't think so
[08:32] <tsdgeos> it's the same library
[08:32] <tsdgeos> just the interpreter does some "QML symbol" hiding depending of which import you did
[08:32] <tsdgeos> but i don't think that's going to be faster slower if you import one or many
[08:35] <Saviq> tsdgeos, right
[08:35] <Saviq> k makes sense
[08:45] <tsdgeos> Saviq: just to make sure, at the Card.qml level, template and components are shared by all Cards of the same "parent", it's only cardData that is different
[08:45] <tsdgeos> right?
[08:45] <Saviq> tsdgeos, yes
[08:45] <Saviq> tsdgeos, template and components are per-category
[09:00] <Saviq> didrocks, ACK on packaging changes when you have a moment please https://code.launchpad.net/~aacid/unity8/killqt51/+merge/217055
[09:02] <didrocks> Saviq: done
[09:02] <Saviq> didrocks, thanks!
[09:32] <Saviq> Cimi, you might want to check your local branches for tags, vrruiz's branch had old ones
[09:33] <Saviq> Cimi, as a reminder: http://people.canonical.com/~msawicz/unity8/strip-u8-tags.sh
[09:34] <Cimi> Saviq, I did run it, not sure the latests
[09:34] <Cimi> Saviq, is there a way to run it locally?
[09:35] <Cimi> Saviq, takes ages remotely
[09:35] <Saviq> Cimi, I only meant your local branches
[09:35] <Saviq> Cimi, so wherever you have the checkouts
[09:35] <Saviq> Cimi, so that you don't push them anywhere ;)
[09:35] <Saviq> Cimi, only Victor's branch has them from the approved ones currently
[09:36] <Saviq> Cimi, but since you reviewed it
[09:36] <Saviq> Cimi, you merged it in your branch somewhere, and that could've "infected" you with them
[09:36] <Cimi> Saviq, I checked out his branch directly
[09:36] <Cimi> didn't merge to mine
[09:36] <Cimi> but thanks
[09:37] <Cimi> Saviq, is there a command we can use to run inside a branch and check for tags?
[09:37] <Saviq> Cimi, so, FYI: when reviewing, you should always merge on trunk ;)
[09:37] <Saviq> Cimi, `bzr tags | wc -l`\
[09:37] <Saviq> -\
[09:37] <Cimi> Saviq, I do the opposite
[09:37] <Cimi> Saviq, I checkout a branch
[09:37] <Cimi> then I merge trunk inside
[09:37] <Cimi> it's kinda the same thing
[09:37] <Saviq> Cimi, kinda, but reverse to what actually happens when things are landed
[09:38] <Saviq> Cimi, probably 0.000001 probability something goes differently
[09:38] <Cimi> yes agree but is the same thing
[09:38] <Cimi> Saviq, but it has the advantage that I don't have to specify a path when I branch :)
[09:38] <Cimi> otherwise "bzr branch lp:unity8" complains I have already a folder unity8 :)
[09:39] <Cimi> laziiiiness
[09:39] <Cimi> :D
[09:40] <Saviq> Cimi, colo branches FTW
[09:40] <Cimi> Saviq, what the hell is that, I am googling
[09:40] <Cimi> :)
[09:42] <Saviq> Cimi, I only have a single folder with a unity8 checkout
[09:42] <Saviq> Cimi, and switch between branches with `bzr switch colo:foo`
[09:43] <Saviq> git-style
[09:43] <Cimi> oh wow cool
[10:23] <Saviq> /food
[10:30] <Cimi> ping me when you back Saviq :)
[10:41] <Cimi> dednick, you know how to create a snap decision?
[10:42] <dednick> Cimi: i do.
[10:42] <dednick> Cimi: if you're talking about the shutdown dialog, I'm not sure that it should be a snap decision.
[10:43] <dednick> "even though it may look like one at the moment"
[10:43] <Cimi> why?
[10:44] <dednick> Cimi: because I think it's a bit insecure.
[10:45] <Cimi> dednick, insecure in which meaning?
[10:45] <dednick> Cimi: possibly one of those new fangled SecureDialog that mirco is writing. Or something generated by dbus call which we can secure with apparmor
[10:46] <dednick> Cimi: anything can generate a snap decision.
[10:46] <Cimi> dednick, I have the powerd code in front of me
[10:46] <Cimi> dednick, basically I need to change the callback
[10:47] <Cimi> and it's C!!
[10:47] <Cimi> finally I understand :D
[10:47] <dednick> Cimi: i think that the shutdown calls should probably be sent to powerd from unity8.
[10:47] <Cimi> dednick, so I can do pretty much everything we want
[10:48] <Cimi> haven't played with dbus yet but I think it will be fairly easy to send something
[10:48] <Cimi> that we can hook up on the shell
[10:48] <dednick> Saviq: was there ever a consensus on who was responsible for shutdown?
[10:48] <dednick> powerd/systemd/unity8 ?
[10:51] <Cimi> dednick, I'd say unity8 or notifications have to confirm shutdown
[10:51] <Cimi> so powerd must sends and receive
[10:52] <Cimi> I mean emit something and wait something else, securely
[10:54] <dednick> Cimi: this is what I had when i was originally doing this: https://code.launchpad.net/~nick-dedekind/powerd/dbus-shutdown
[10:55] <Cimi> oh wow C
[10:55] <Cimi> I love C
[10:55] <dednick> Cimi: and https://code.launchpad.net/~nick-dedekind/unity8/powerdown for the dialog
[10:55] <dednick> but it's probably way out of date.
[10:59] <dednick> Cimi: but i don't really like the idea of sending a request from powerd, then a async response from unity8. I think maybe mirco's dialog interface may be a good plan.
[11:01] <dednick> Cimi: it's even possible that unity8 should handle the pwer key event itself.
[11:04] <dednick> Cimi: and now you understand why this hasn't been finished yet :)
[11:07] <Saviq> dednick, lightdm as far as I can tell
[11:07] <Saviq> Cimi, ↑
[11:07] <Saviq> so unity8 would receive the power button press, display a dialog and tell LightDM to shut down
[11:08] <Saviq> which goes in concert with reducing powerd's responsibility to handle input
[11:08] <Saviq> I don't think anything external needs to be involved
[11:08] <Saviq> Cimi, is there design for the dialog?
[11:08] <dednick> Saviq: ah yeah, lightdm was the one. not systemd.
[11:09] <dednick> Saviq: a very "rudimentary" design. https://launchpadlibrarian.net/158819734/poweroff-buttons.png
[11:10] <Saviq> right, so that does look ~kind of like a snap decision / system dialog
[11:11] <Saviq> we should find out whether it's supposed to participate in the usual snap decision flow
[11:12] <dednick> and if it's a final design...
[11:13] <dednick> dont want to do it as a snap and then find out, "oh, it should be full screen" ala pin lock. :)
[11:13] <Cimi> Saviq, there is a video
[11:14] <dednick> Cimi: you have a link?
[11:16] <Cimi> dednick, I can put it on google docs
[11:17] <Cimi> dednick, https://drive.google.com/a/canonical.com/file/d/0B2mvp37s6lHvMWZ5OVFZM2wtbk0/edit?usp=sharing
[11:17] <Cimi> Saviq, ^
[11:18] <dednick> hm. ok, i guess it may be a final design then...
[11:18] <dednick> can't generate a snap decision from unity8 though...
[11:19] <dednick> unless mirco fixed that
[11:19] <Cimi> dednick, it was signed off
[11:19] <Saviq> there's no QML component that you could with, yet
[11:20] <Cimi> Saviq, what?
[11:20] <Cimi> dunno much about snap decisions
[11:20] <Saviq> Cimi, there's no QML component to generate a snap decision with
[11:21] <dednick> you can't send a snap decision from unity8, even with the C api. something to do with the event loop iirc
[11:21] <Saviq> oh
[11:21] <Saviq> should be possible to inject without DBus, though
[11:22] <Saviq> but might be tricky, too
[11:22] <dednick> yep.
[11:22] <Saviq> Cimi, please find out whether the shut down dialog should be a snap decision indeed, as in what happens if you get a call when the dialog is on screen - should the call s-d show up next to it, or maybe shutdown cancelled
[11:24] <Cimi> Saviq, shutdown should not cancel if I receive a call while I have the snap decision on
[11:24] <Cimi> Saviq, it should queue and show both
[11:24] <Cimi> I should be able to shut down the phone and ignore the call
[11:24] <Saviq> Cimi, you certain?
[11:25] <Cimi> Saviq, it's my common sense
[11:25] <Saviq> Cimi, yeah, sorry, not good enough, please confirm the design
[11:25] <Saviq> FWIW while any s-d is on screen, you won't be able to interact with the app
[11:25] <Saviq> so you'd cancel the shutdown dialog anyway
[11:25] <Cimi> Saviq, I am want to switch off the call because I don't want to hear my wife calling me because I am upset, and she stops me from powering off my phone
[11:26] <Saviq> Cimi, still, we're not the ones to take this decision
[11:26] <Cimi> or different use case
[11:26] <Cimi> I am in a meeting, ringtone loud
[11:26] <Cimi> or before departure
[11:26] <Cimi> on a plane
[11:27] <Saviq> Cimi, please confirm with design that the shutdown dialog is really meant to behave like any other s-d
[11:27] <Cimi> trying to switch off the phone but somebody calls me and cancels
[11:27] <Cimi> with my ringtone ringing in front of Ryanair angry stewart
[11:27] <Cimi> I will do now :)
[11:28] <Cimi> Saviq, granted that we want this, showing two notifications on screen
[11:29] <Cimi> Saviq, shutdown notification and incoming call
[11:29] <Cimi> Saviq, what shall we do next?
[11:29] <Cimi> Saviq, sending dbus call from powerd?
[11:30] <Saviq> Cimi, no, let's not build any more knowledge into powerd, when we want to move it out of there
[11:30] <Cimi> ok
[11:30] <Saviq> although powerd currently handles long-power-press as power-click anyway
[11:30] <Cimi> that's why
[11:30] <Cimi> Saviq, https://code.launchpad.net/~nick-dedekind/powerd/dbus-shutdown
[11:31] <Cimi> is fairly correct
[11:31] <Cimi> in my opinion
[11:32] <Saviq> but going in the wrong direction
[11:33] <Saviq> we want to move stuff out of powerd, not move more inside it
[11:33] <Cimi> there are only issues with the timeout and possible segfaults ibecause we're not handling dispose
[11:33] <dednick> Saviq: what about the power click (screen off) ??
[11:33] <Cimi> g source should be cleared
[11:33] <Cimi> on dispose
[11:33] <Saviq> dednick, that should ultimately go into unity8 as well
[11:33] <Saviq> dednick, same as activity monitoring
[11:34] <Saviq> and suppression mechanisms, too
[11:35] <dednick> mmm
[11:36] <Saviq> so yeah... that's long-term
[11:36] <dednick> i see heads exploding when putting power management into shell.
[11:37] <Cimi> yeah
[11:37] <Cimi> I agree
[11:38] <Cimi> shell is a shell, should not handle power
[11:38] <Cimi> can control power, but not interact with it IMHO
[11:38] <Cimi> there should be a service for that
[11:38] <Cimi> if shell crashes or hangs, I cannot switch off my phone
[11:39] <dednick> Cimi: well, you cant anyway, because there's no cnfirm :)
[11:40] <Cimi> dednick, you can if you leave in powerd
[11:40] <Cimi> dednick, one looong press to start shutdown
[11:40] <Cimi> dednick, like you did, 20 secs in your branch
[11:40] <dednick> Cimi: i think that's hardwired into android
[11:41] <Cimi> dednick, android?
[11:41] <Cimi> dednick, you mean the phone?
[11:41] <Cimi> motherboard whatever
[11:41] <dednick> whereever
[11:41] <Cimi> ok
[11:41] <Cimi> got it
[11:42] <Cimi> might be right
[11:42] <Cimi> but for emergency shutdown
[11:42] <dednick> but, anyway. volume key handling is also in unity8...
[11:42] <dednick> so...
[11:42] <Cimi> a 10 or 5 seconds shutdown should be handled by a daemon/service
[11:42] <Cimi> dednick, I think is wrong
[11:43] <Cimi> dednick, those things should go as services
[11:43] <Cimi> for the same reasons about hanging shell
[11:43] <Cimi> and whole system collapses
[11:44] <Cimi> we took shit for years because when compiz was crashing unity7 was bringing down everything, and viceversa
[11:45] <Cimi> we should eventually move all those hardware functionalities in something separate
[11:45] <Cimi> so they are guaranteeded to work regardless of the shell running/crashing/slowing down
[11:46] <Cimi> that way shell could also suspend itself when I am playing a video or doing something else fullscreen
[11:46] <dednick> I'm not arguing...
[11:46] <Cimi> thus saving more battery
[11:47] <Cimi> dednick, so let's start by architect the power button better :)
[11:48] <dednick> what does the desktop use?
[11:51] <dednick> woops
[11:51] <dednick> long press power button on desktop shows power dialog. why dont we use the same thing?
[11:52] <dednick> (of course, even after dismissing the dialog, my desktoip got shut down; but that's not the point....)
[11:54] <Cimi> ahah
[11:54] <Cimi> dednick, I think we use gnome power manager or something for that
[11:56] <Cimi> dednick, and ultimately apparently upower
[11:58] <Saviq> Cimi, shell becomes the compositor, display server, if it slows down, you won't be able to do anything anyway, so that's not a valid argument
[11:58] <dednick> i think we use the session indicator
[11:59] <Saviq> Cimi, and for battery life - that's exactly why we need to move input handling into the shell, so that powerd does not wake on every event, when the shell already does
[11:59] <Saviq> Cimi, and please don't "rearchitect" things, there's other people responsible to do that
[12:01] <Cimi> Saviq, those are hardware buttons
[12:01] <Cimi> and services
[12:01] <Saviq> Cimi, everything is hardware at some point
[12:02] <Saviq> and splitting the responsibilities isn't getting you anywhere
[12:02] <Cimi> they should be controlled independently from the UI
[12:02] <Saviq> no, they should not
[12:02] <Saviq> 'cause UI reacts to those hardware buttons
[12:03] <Saviq> we want a pre-suspend animation, we need to composite a pre-resume frame, we need to reduce the number of input receivers to a minimum to save power
[12:03] <dednick> Saviq: desktop not runnig a shell. runs a music player in the vterm. presses volume button. what happens?
[12:03] <Saviq> dednick, input goes to the music player
[12:04] <Saviq> dednick, and it does whatever it wants with it
[12:04] <Saviq> why are we trying to treat volume and power buttons different than any other key you have on your keyboard?
[12:04] <Saviq> dednick, even now volume and power buttons are handled by unity7
[12:04] <dednick> Saviq: so every player should be intepretting events then, not the shell.
[12:05] <Saviq> dednick, sure, if it reaches the player, it should interpret it, but the shell needs to be able to override behaviour
[12:05] <Saviq> dednick, if music player isn't focused, what do you want the volume buttons to do?
[12:05] <Saviq> if there isn't music played at all, what then?
[12:05] <Cimi> Saviq, change master volume
[12:06] <Saviq> Cimi, what does that change?
[12:06] <Cimi> hardware buttons should change the master volume of my sondcard/output
[12:06] <Cimi> not the current player
[12:06] <dednick> mmm
[12:06] <Saviq> Cimi, that's really not how it works
[12:07] <Cimi> how it should imho
[12:07] <Saviq> no, you're not considering a lot of cases
[12:07] <Cimi> Saviq, I am happy to understand why it would be better handled in the shell
[12:07] <Saviq> when it comes to volume buttons, MeeGo has done the best job there is
[12:08] <Saviq> by default, screen off → nothing happens
[12:08] <Saviq> by default, screen on → you change profile between loud, quite, muted etc.
[12:08] <Saviq> when music plays, screen off → volume changes
[12:08] <Saviq> when music plays, screen on → volume changes
[12:09] <Saviq> when no music playing, but focused app interprets volume → it does what it wants to
[12:09] <Saviq> handling that in "a service" is really going to be a PITA
[12:09] <Saviq> for no advantage at all
[12:10] <Saviq> if you change your music volume, you don't want that to affect the ringtone volume, so you can't change master volume
[12:10] <Saviq> etc.
[12:10] <Saviq> so no, I completely disagree, and I'm not the only one, for that matter
[12:10] <Saviq> even in unity7 it's the sound indicator I think that grabs volume and media keys
[12:11] <Saviq> and tells Pulseaudio to do what it needs to do, which changes current output volume, not master volume
[12:11] <Saviq> and talks to apps via MPRIS about media keys
[12:11] <Cimi> Saviq, android has separate volumes
[12:11] <dednick> ok, so i get the argument for the volume, but power as well? there's no real intrpetation there is ther?
[12:11] <Cimi> Saviq, so probably different audio slots
[12:11] <Cimi> you can have a service/deamon adjusting volumes of those slots
[12:12] <Saviq> Cimi, and that service needs to know what is in the foreground now
[12:12] <Saviq> Cimi, so you get into IPC
[12:12] <Saviq> please, let's not
[12:12] <Cimi> when a player is connected to the media slot and the screen is off, the audio daemon modifies output volume of this slot
[12:12] <Cimi> I am saying is not PITA
[12:12] <Saviq> yeah, and now we have 55 services
[12:13] <Saviq> every single one waking up on volume button press
[12:13] <Saviq> to see if it wants to handle it
[12:13] <Saviq> yay for battery life
[12:13] <karni> mhr3: I found a bug in scope Preview (or so I suspect), but have trouble triaging it. can you help?
[12:13] <Cimi> Saviq, why they should react? just the "audio daemon"
[12:14] <Saviq> Cimi, they don't want to react, but they will still get the volume button press if they connect directly to the input stream
[12:14] <Cimi> I understand this
[12:15] <Cimi> but I still think that power button should be handled in the most reliable way
[12:15] <Saviq> Cimi, and if there's something that's meant to route the input just to the audio daemon, that thing needs to listen to all input, and wake on every input event, even though the shell needs to, as well, so we at least double the CPU time to handle that event at the lower level
[12:15] <Saviq> dednick, Cimi, as long as it's meant to have a result in the UI (suspend screen, display power off dialog), why not handle it in the UI?
[12:15] <Saviq> Cimi, that's different, forced shutdown needs to happen in a lower level indeed
[12:16] <Saviq> but anything that's actually supposed to affect the UI relies on the fact that the UI is actually working
[12:16] <Saviq> if it's not, how is it better that something lower level will listen to it, if nothing is going to happen anyway?
[12:17] <dednick> Saviq: are we going to have different path for ubuntu desktop?
[12:17] <Saviq> dednick, no, why?
[12:17] <dednick> if we dont run unity8
[12:17] <Saviq> dednick, we have the same path we have _now_ in unity7
[12:18] <Saviq> dednick, power button press is handled by your current vt
[12:18] <Saviq> dednick, it's just an input event like any other
[12:19] <dednick> mk. thats fine by me.
[12:19] <Saviq> yay, pressing power + esc just halted the PC for me :P
[12:19] <Saviq> that's lower level for ya!
[12:19] <dednick> :) yeah, it shut me down earlier
[12:20] <Saviq> so, all in all, all input needs to go: hw → shell → app → shell
[12:20] <dednick> power is handled by indicator-session on desktop
[12:20] <Saviq> so that we can behave smart
[12:20] <Saviq> with only power being interpreted by lower level as well to force shutdown
[12:20] <dednick> + a unitydialog/zenity
[12:21] <Saviq> yups
[12:21] <mhr3> karni, what's the issue?
[12:21] <dednick> Saviq: but where is the button press picked up? unity7?
[12:22] <Saviq> dednick, not sure in the unity7 case, it might be LightDM talking to the session
[12:22] <Saviq> not sure power is just an X key event under X11, but would expect so
[12:23] <karni> mhr3: I have a preview with two buttons. Each belongs to separate 'actions' widget. Both launch the same URL, even though preview data returned from smart scope server is correct.
[12:23] <Saviq> let me check something
[12:23] <karni> mhr3: if you could check if two buttons from two separate action widgets properly map to their uri actions, that would be great
[12:25] <mhr3> karni, and you adding 'uri' props to the actions?
[12:25] <mhr3> s/and/are/
[12:26] <Saviq> dednick, under X it seems somewhat different, if there's no session running / intercepting the power off event, you get shutdown
[12:26]  * Saviq not sure we're actually getting a PowerOff event on the phone
[12:26] <Cimi> Saviq, same thing with ctrl alt del
[12:26] <karni> mhr3: this is interesting. so, for first one, I have 'uri': result['uri'] , but I just noticed for the second I have 'url': result['foobar_url'] - even if I made a mistake, second button should launch what first button launches
[12:26] <Saviq> Cimi, yeah, those are interpreted by the vt probably, since nothing intercepts it
[12:26]  * karni tries
[12:26] <Cimi> Saviq, exact;y
[12:27] <Saviq> Cimi, but that's just _fallback_
[12:27] <Cimi> Saviq, we should have something similar
[12:27] <Cimi> Saviq, I am not againt handling them in the shell
[12:27] <mhr3> karni, can you pastebin the entire json pls?
[12:27] <Cimi> Saviq, I am just for having a fallback when shell is not responding
[12:27] <Saviq> Cimi, we have something exactly the same, that still means that *if* there's a shell working, you interpret them in the shell
[12:27] <Saviq> Cimi, of course, but that's not what you argued
[12:27] <Saviq> Cimi, you argued there should be a service regardless of whether shell is working or not
[12:28] <karni> mhr3: just fixed line 21 (/s/url/uri), testing http://paste.ubuntu.com/7329484/
[12:28] <mhr3> karni, yea, that should work afaict
[12:29] <Saviq> Cimi, and power/c+a+d are really a special case, volume isn't
[12:29] <Saviq> Cimi, does your volume change when you switch to a VT and press volume up/down buttons?
[12:29] <mhr3> karni, and why aren't you defining all the buttons inside a single actions widget?
[12:29] <karni> mhr3: 1) because I can :D 2) I wanted to have them one under another. Is there another way to achieve this?
[12:30] <karni> mhr3: so, yeah, /s/url/uri fixed the problem.
[12:30] <Saviq> karni, that's against design ;)
[12:30] <karni> Saviq: oh sh!t :O (/me fixes ;) )
[12:30] <mhr3> karni, ^^ what he said :P
[12:30] <Saviq> karni, it's meant to be:
[12:30] <Saviq>                     (primary action)
[12:31] <karni> mhr3: I suspect PreviewActions was iterating through actions, or something, and assigned the second button action of the first one, because there were 2 buttons, but one proper uri. still, strange.
[12:31] <Saviq> (secondary action) (primary action)
[12:31] <Saviq> (negative action) (primary action)
[12:31] <karni> Saviq: thank you
[12:31] <Saviq> (combo button) (primary action)
[12:31] <karni> Saviq: well, we haven't gone through design with this yet, so, that problem would surface :)
[12:31] <karni> thanks, anyway!
[12:31]  * karni fixes
[12:31]  * Saviq wonders if we should limit the number of action widgets to one
[12:31] <Saviq> probably not...
[12:31] <mhr3> karni, if "uri" is not defined for the button, it falls back to result.uri (as in result for which the preview was requested)
[12:32] <karni> Saviq: in theory, buttons can be interleaved by other widgets
[12:32] <Saviq> karni, yeah, I know
[12:32] <karni> mhr3: oooh that explains it. pretty smart ;D
[12:32] <karni> just saying. I know you know :D
[12:35] <karni> has Ubuntu Palette been updated, and bazillion of 'TODO's by me in unity8 are gone ;D?
[12:36] <Saviq> karni, it's not that easy
[12:36] <karni> I'm sure it's not :)
[12:36] <Saviq> karni, it's not about updating the palette, but about extending it - we still need the original palette for the rest of the shell
[12:36] <karni> right
[12:36] <Saviq> karni, but anyway, this will go away with dash becoming an app
[12:36] <Saviq> karni, which will have its own theme
[12:37] <karni> oh cool!!
[12:37] <karni> Saviq: does that mean we'll allow custom Dash apps? :O
[12:37] <Saviq> karni, define custom dash apps?
[12:37] <karni> Saviq: I write my own Dash. since Canonical's Dash is an app, I can install mine as well?
[12:38] <karni> s/is/will be
[12:38] <Saviq> karni, well, it's going to be a special app
[12:38] <karni> ;>
[12:38] <Saviq> karni, arguably, yes, it would be possible
[12:38] <Saviq> karni, it's only gonna be special in the sense that it's not closeable, is respawned, and that some gestures / buttons will take you to it
[12:39] <karni> Saviq: I see
[12:39] <Saviq> so it could be possible to replace that with some other app, as long as it mimics the original dash
[12:40] <karni> Saviq: I find it amusing that second button from actions widget shows to the left. while this is consistent with what you said about button layout (same as on Android, secondary action | primary action, cancel | confirm), it's somewhat counterintuitive they should up in reverse.
[12:40] <karni> right
[12:41] <Saviq> karni, depends on which paw you use your phone with ;)
[12:41] <Saviq> thumb works well with the positive button
[12:41] <mhr3> Saviq, it's like running scope-tool in the mir-preview-session
[12:41] <mhr3> super confusing
[12:41] <karni> Saviq: haha. I'm not saying about the palms. I'm saying, in code, I do: actions.append(foo), actions.append(bar), and then I get bar | foo on the phone
[12:41] <Saviq> mhr3, lol :D
[12:42] <Saviq> mhr3, so that's what you were trying to do? :)
[12:42] <Saviq> karni, yeah, they go RTL, since any actions beyond the second will be collapsed into a combo button (at some point at least)
[12:42]  * karni agrees with the "negative | positive/confirm" layout. I meant how code maps to button layouting
[12:42] <mhr3> Saviq, you mean my unity-mir adventures?
[12:42] <Saviq> mhr3, yup :)
[12:43] <mhr3> Saviq, nope ;)
[12:43]  * karni noted
[12:43] <mhr3> Saviq, i wrote something like android's zygote for qmlscene
[12:43] <Saviq> mhr3, to speed up launch?
[12:43] <mhr3> yep
[12:43] <karni> what confuses me is, when I launch a browser from a scope result preview, when I swipe the browser to right, I get to "Apps" screen, and not to the scope results I was browsing.
[12:44] <karni> mhr3: I heard you and Ondrej were working on this. cool.
[12:44] <Saviq> karni, right, dash resets by design when you unfocus it
[12:44] <Saviq> mhr3, are you putting it under upstart jobs?
[12:44] <mhr3> Saviq, but qt is very unfriendly to pre-init stuff without having an actual QCoreApplication, so doesn't help much
[12:44] <karni> personally, I think it's a wrong decision. but I have nothing to say about this professionally.
[12:45] <Saviq> karni, file a bug, this behavior might not be wanted any more
[12:45] <mhr3> Saviq, i did it without upstart
[12:45] <Saviq> karni, a *lot* has changed
[12:45] <Saviq> mhr3, so no lifecycle management :?
[12:45] <karni> Saviq: ok
[12:45] <Saviq> mhr3, we really want all apps to be managed by upstart...
[12:45] <mhr3> Saviq, well... i did hook up closing, but if the app forked, noone would know :)
[12:45] <Saviq> mhr3, yeah
[12:46] <mhr3> Saviq, and i disagree, what upstart does to track forks is stupid
[12:46] <mhr3> and we'll get rid of upstart anyway
[12:46] <Cimi> Saviq, volume keys in X are input events
[12:46] <Cimi> they come from kbd
[12:47] <Saviq> Cimi, yes, I know, handled by the shell, not by no service
[12:47] <Cimi> not sure on phones
[12:47] <Saviq> Cimi, read Shell.qml
[12:47] <Cimi> but i was concerned of power button
[12:47] <Saviq> mhr3, sure, but we'll replace it with logind or whatever session systemd, same thing - we need everything to under there
[12:48] <karni> https://bugs.launchpad.net/unity8/+bug/1312707
[12:49] <mhr3> Saviq, i need to dig into systemd, but i hope it does something more sophisticated than ptracing to track forks
[12:49] <mhr3> i think it uses cgroups
[12:49] <mhr3> which means you could add arbitrary process to it
[12:49] <mhr3> and therefore my zygote would work fine :)
[12:50] <Cimi> Saviq, so let me add power button to shell's powerd plugin?
[12:50] <Saviq> mhr3, I'm sure it's possible to "inject" a process into a job
[12:50] <mhr3> Saviq, not with upstart currently, no
[12:50] <Saviq> mhr3, kk
[12:50] <Saviq> Cimi, I don't think we should spend time on this task right now
[12:51] <Saviq> Cimi, we need to clear up the whole powerd vs. unity8 story
[12:51] <Saviq> Cimi, dednick, https://blueprints.launchpad.net/ubuntu/+spec/client-1410-unity-ui-power btw
[12:52] <Cimi> Saviq, I was assigned to boot down animation
[12:53] <Saviq> Cimi, I understand, but I don't think this task was evaluated enough
[12:54] <mhr3> Saviq, anyway, next weekend i'll patch qt to be able to pre-init v4 ;) we'll see how that goes
[12:54] <dednick> still can't find where the desktop power button is being caught. lightdm seems to be doing it's own thing with systemd, the same as the indicator-session is... unity7 guys probably have more info
[12:54] <mhr3> dednick, aren't those things handled by gsd?
[12:54] <Saviq> mhr3, you talked with mardy on that?
[12:55] <Saviq> mhr3, he did mention the MeeGo preloader a few times now
[12:55] <mhr3> right
[12:55] <mhr3> mardy, input ^^?
[12:55] <dednick> mhr3: gsd? err, gnome-settings-daemon ?
[12:56] <mhr3> dednick, yea, seb128 might know
[12:56] <Cimi> definitely not xevent
[12:56] <Cimi> I ran xev
[12:57] <Cimi> pressed power button
[12:57] <mhr3> udev
[12:57] <Cimi> yeah
[12:57]  * Cimi looks udev
[12:57] <dednick> well, it's being processed by indicator-session action somehow...
[12:57] <dednick> bregma: ping
[12:58] <bregma> yes?
[12:58] <dednick> bregma: howdy. your team did the unity7 shutdown dialog right?
[12:58] <bregma> certainly
[12:58] <bregma> or at least, one of them
[12:58] <dednick> bregma: you know where the power key event comes from?
[12:59] <dednick> as in, how does it get to indicator-session
[12:59] <bregma> isn't that a logind thing?  I really don;t know for sure, it's a maze of twisty little passages, all different
[13:00] <bregma> it could also be gnome-session-daemon, it does things like taht
[13:01] <seb128> unity-settings-daemon does it
[13:01] <Saviq> dednick, there's gnome.SessionManager with some methods like that
[13:01] <dednick> ah
[13:01] <dednick> seb128: thanks
[13:01] <seb128> logind handles the power button to shutdown the system
[13:01] <seb128> but the session puts an inhibitor and react to the action by showing a dialog
[13:01] <seb128> dednick, what are you trying to do?
[13:02] <dednick> seb128: just trying to get a handle on how the desktop handles shutdown vs phone.
[13:02] <bregma> I think there needs to be a breakout session on that in Malta
[13:02] <Saviq> +1
[13:03] <Saviq> and the whole desktop vs. phone session handling
[13:03] <bregma> amen
[13:03] <seb128> dednick, http://bazaar.launchpad.net/~unity-settings-daemon-team/unity-settings-daemon/trunk/view/head:/plugins/media-keys/gsd-media-keys-manager.c#L2505
[13:03] <Saviq> bregma, you're there second week I hope?
[13:03] <bregma> absolutely
[13:03] <seb128> Saviq, dednick, bregma: let's wait to have systemd in the picture to do session handling, no need to build more on upstart to replace that next cycle
[13:04] <Saviq> seb128, well, we need something working for this cycle ;)
[13:04] <Saviq> actually, for the last cycle!
[13:04] <seb128> dednick, in unity8 it's likely mir that should grab for those keys and call the handlers
[13:04] <mhr3> eek
[13:04] <seb128> Saviq, we have something working?
[13:04] <mhr3> don't turn mir into gsd :P
[13:05] <Saviq> seb128, shell, that si
[13:05] <Saviq> is
[13:05] <Saviq> mhr3, ↑
[13:05] <Saviq> not mir itself
[13:05] <bregma> I get the feeling mir is replacing more than X, it's replacing systemd too?
[13:05] <seb128> Saviq, mir/shell are the same thing to me :p
[13:05] <Saviq> seb128, well, they're not ;)
[13:05] <seb128> right
[13:05] <Cimi> cool guys
[13:05] <Saviq> seb128, what we have working is powerd shutting down after 5s or so
[13:05] <seb128> well, key grabbing is not going to be done by some 3rd party daemon
[13:05] <Saviq> seb128, but no way to show shutdown dialog et al
[13:05]  * bregma is going to start a rumour that Canonical wants to replace systemd with mir
[13:05] <Cimi> Saviq, 2
[13:05] <Cimi> I think
[13:05] <Cimi> :D
[13:05] <Saviq> Cimi, 2? feel short
[13:06] <Saviq> lol
[13:06] <seb128> Saviq, I was speaking about https://code.launchpad.net/~charlesk/indicator-session/lp-1296814-logout-using-unity-session/+merge/215487
[13:06] <Saviq> brb
[13:06] <Cimi> Saviq, http://bazaar.launchpad.net/~phablet-team/powerd/trunk/view/head:/src/powerd.cpp#L61
[13:06] <Saviq> seb128, well, yeah, that's short-term
[13:06] <Saviq> seb128, so that you can logout at all from unity8 preview
[13:06] <seb128> Saviq, k
[13:07] <seb128> but yeah, agree, that needs discussions
[13:07] <seb128> it's all work for you guys at the end
[13:07] <seb128> unity8 should do the grabbing
[13:08] <Saviq> indeed
[13:08] <seb128> Saviq, dednick, bregma: in fact the way keybindings work in trusty (iirc) is that the compiz grabs the keys and calls dbus methods, the actions are done by u-s-d
[13:08] <seb128> we did that the same way GNOME did with gnome-shell
[13:08] <seb128> it means g-s-d/u-s-d stop using xorg
[13:08] <seb128> they just provide dbus interfaces
[13:08] <seb128> the grabbing/callback being done by the shell
[13:09] <mhr3> oh yea, we really have unity-settings-daemon now
[13:09] <mhr3> when did that happen? :)
[13:10] <seb128> mhr3, this cycle, we also have unity-control-center
[13:10] <mhr3> seb128, fwiw me not noticing is a hat off to your work ;)
[13:10] <seb128> mhr3, ;-)
[13:12] <dednick> ok, well now that my head is sufficiently exploded. i shall get back to some real work
[13:14] <bregma> so, in Unity 7, compiz grabs the shutdown key, sends it to u-s-d, which calls indicator-session, which sends to Unity (in compiz), which puts up a dialog, eventually returning the result to indicator-session, which then tells u-s-d to tell logind to shut down?
[13:14] <bregma> is there an autopilot test for that?
[13:14] <seb128> lol
[13:15] <seb128> bregma, I'm not sure about the compiz->shutdown part, I don't think it gets back through u-s-d
[13:15] <seb128> u-s-d is what receives the dbus call from compiz and call the action
[13:15] <seb128> but the action then is directly going to the gnome-session dbus api (I think)
[13:15] <dednick> i vote for the unity8 -> logind option!
[13:15] <seb128> which calls logind
[13:15] <dednick> 2 steps... easy peazy
[13:16] <mardy> mhr3: hi! https://gitorious.org/meegotouch/meegotouch-applauncherd/source/8bbf9aea2586015eb7cdaa7f2d42b4f821b787cf:README
[13:16] <seb128> dednick, that's basically what we have today
[13:16] <seb128> dednick, you need steps in between because you need the session to be able to block logout if there is unsaved work
[13:16] <dednick> seb128: actually, today we have 1 step on phone i thin. powerd = god
[13:16] <mardy> mhr3: that was very smart, you could pre-init lots of different stuff very easily
[13:16] <seb128> dednick, right, which means "if you have unsaved work, sucks to be you"
[13:16] <dednick> seb128: yep :)
[13:17] <dednick> seb128: your fault for pressing power button!
[13:17] <bregma> dednick, I am thankful for that, since the power button tends to be the way to swicth apps much of the time
[13:17] <seb128> ;-)
[13:19] <mhr3> mardy, yea, so i implemented something similar
[13:19] <mhr3> mardy, i was focusing on qml, but pre-initing enough of qt is an issue
[13:20] <mhr3> mardy, basically you need qapplication for everything and you can't pre-init qapplication
[13:26] <mardy> mhr3: I got disconnected, I don't know what messages of mine went through, so I'll re-paste them:
[13:27] <mardy> 16:19 < mardy> mhr3: cool! BTW, also sailfish OS has something similar, let me find it...
[13:27] <mardy> 16:22 < mardy> mhr3: https://github.com/nemomobile/mapplauncherd and https://github.com/nemomobile/mapplauncherd-booster-qtcomponents
[13:27] <mardy> 16:23 < mardy> mhr3: the latter is a booster they use to preinitialize all the QML components of their toolkit
[13:36] <mhr3> mardy, hm, that is indeed interesting
[14:00] <paulliu> tsdgeos: hi. Your comment about the zooming doesn't work. Does it not zooming at all?
[14:01] <paulliu> tsdgeos: I have the zooming worked. But it is a bit strange on central points so I'm debugging it right now.
[14:02] <tsdgeos> paulliu: it did weird things
[14:02] <tsdgeos> mainly moving the image around
[14:02] <tsdgeos> maybe some zooming happened too
[14:02] <tsdgeos> but it was very easy to end up with the image not even visible
[14:03] <paulliu> tsdgeos: ok. Let me fix it a bit.
[14:45] <kgunn> bregma: do we need to have some sync time with dandrader|bbl today on bug 1307701
[14:46] <kgunn> so you can leave and enjoy time off
[14:49] <bregma> kgunn, yes sir
[14:51] <paulliu> tsdgeos: https://code.launchpad.net/~paulliu/unity8/zoomImage/+merge/207941
[14:51] <paulliu> tsdgeos: pushed. Should work now.
[14:51] <tsdgeos> paulliu: cool
[15:27] <sil2100> Trevinho: hello!
[15:28] <sil2100> Trevinho: are you around? I would have some questions regarding the locally integrated menus, and I think you were working on those?
[15:29] <sil2100> bregma: who would be the best person to ask about the local menus right now?
[15:30] <bregma> sil2100, Trevinho except he's off today
[15:30] <sil2100> Ah...
[15:30] <sil2100> bregma: thanks :)
[15:33] <Cimi> sil2100, it's national holiday in italy, I hope he is not around :)
[15:34] <Saviq> slackers
[15:36] <kgunn> just clear up any confusion...not a holiday in the US
[16:19] <dandrader> bregma, I'm back
[17:58] <mterry> kgunn: can you do me a favor and update silo 002?  I want to add lp:~mterry/lightdm/resettable to it (and once that is built, rebuild unity8)
[17:59] <kgunn> mterry: ack
[17:59] <mterry> kgunn, this will get us instant lockscreen!  (a couple small visual oddities right now, but those should go away with nonblocking Mir)
[18:00] <kgunn> yes!
[18:09] <kgunn> mterry: if you join #ubuntu-ci-choo-choo i added your name to get pung by the bot
[18:09] <mterry> kgunn, marked as auto-join now
[18:09] <kgunn> cool...
[18:09] <kgunn> it'll ping all 3 of us...
[18:10] <kgunn> i gotta go dark for a bit...saga of replacing the smashed window continues
[18:10] <kgunn> but i'll be off and on until ~4pm...then i get to go see Carmack talk
[18:12] <mterry> :)