[09:53] <tsdgeos> Saviq: that "just remove it" it's not a good enough solution tbh
[09:53] <tsdgeos> i want to have both unity8 and unity7 installed
[09:53] <tsdgeos> why do i need to have two network indicators in unity7?
[09:53] <Saviq> tsdgeos, because indicator-network doesn't yet implement everything nm-applet does
[09:54] <tsdgeos> Saviq: sure, then indicator-network should be blacklisted for the desktop
[09:54] <tsdgeos> or whatever mechanism makes me not have a ugly unity7 experience
[09:54] <tsdgeos> Saviq: sent you the email with the crash-tester btw
[09:54] <Saviq> tsdgeos, thanks
[09:55] <Saviq> tsdgeos, we could potentially disable the network indicator in the desktop profile, but then unity8 on the desktop would lose it, too... I'm not sure nm-applet is good enough with unity8
[09:55] <Saviq> tsdgeos, but anyway
[09:55] <tsdgeos> sure, not my biggest problem :D
[09:56] <Saviq> tsdgeos, yes, my replies were more to the "I don't know where that came from"
[09:56] <tsdgeos> was just giving my opinion
[09:56] <Saviq> rather than this is the right solution
[09:56] <seb128> tsdgeos, Saviq: you can edit /usr/share/unity/indicators/com.canonical.indicator.network and drop the desktop section, we should probably do that by default seeing the number of people complaining about it
[09:57] <seb128> then people who want to test the indicator on the desktop would need to edit to add back
[09:57] <Saviq> seb128, yeah, but as said above, is nm-applet working good enough under the desktop unity8 session?
[09:57] <seb128> but opt-in probably makes sense, most people get the indicator through other depends, not because they want to use it
[09:58] <Saviq> yeah sure
[09:58] <seb128> I've not tried it
[09:58] <seb128> but nm-applet is indicator-application
[09:58] <seb128> does that work under unity8?
[10:01] <Saviq> seb128, it does, somewhat
[10:02] <Saviq> hmm it actually seems to work fine
[10:02] <Saviq> can't enable cellular, though
[10:03] <Saviq> hmm or maybe that's actually indicator-network in desktop profile, not nm-applet
[10:03] <Saviq> btw, the list of things that get removed:
[10:04] <Saviq> with indicator-network:
[10:04] <Saviq> account-plugin-ubuntuone* indicator-network* ubuntu-system-settings* ubuntu-system-settings-online-accounts* unity-scope-click*
[10:04] <Saviq> not great
[10:07] <seb128> Saviq, just drop the sections from /usr/share/unity/indicators/com.canonical.indicator.network to make sure it's not it
[10:07] <Saviq> seb128, yeah, no nm-applet under unity8, but that's probably fine (i.e. if you want unity8 and network, you need indicator-network), as long as ↑ those deps get fixed - like account-plugin-ubuntuone depending on the indicator network? what gives?
[10:09] <seb128> Saviq, it doesn't depends on it, it depends on ubuntu-system-settings-online-accounts
[10:09] <seb128> which depends on u-s-s
[10:10] <seb128> which depends on i-n since it's the backend used for the wifi panel
[10:12] <Saviq> seb128, why does it depend on u-s-s, don't we have a desktop version of that?
[10:13] <seb128> mardy, ^
[10:13] <seb128> mardy, well I guess we could maybe have a | gnome-control-center-signon
[10:13] <seb128> ups
[10:13] <seb128> Saviq, ^
[10:13] <seb128> but I'm unsure, I didn't look at potential differences
[10:14] <Saviq> seb128, right
[10:15] <mardy> Saviq: removing ubuntu-system-settings-online-accounts on the desktop is fine
[10:15] <mardy> Saviq: not sure about account-plugin-ubuntuone
[10:15] <Saviq> mardy, yeah, I didn't think that one would be fine
[10:17] <Saviq> yeah, "online accounts" → no Ubuntu One account (I can actually add one (???), but that just shows a grey screen - probably plugins cached somewhere and not reloaded on removal)
[10:17] <Saviq> mardy, ↑ bug, btw?
[10:18] <mardy> Saviq: IIRC, plugins are not cached
[10:18] <seb128> Saviq, mardy: if "removing ubuntu-system-settings-online-accounts on the desktop is fine" we should probably have account-plugin-ubuntuone depends on "u-s-s-o-a | g-c-c-s"
[10:18] <Saviq> so yeah, we need to solve the deps somehow, otherwise people will end up with indicator-network on their unity8-less desktops
[10:19] <mardy> seb128: I think so, unless they have a different package for the U1 plugin on the desktop
[10:19] <Saviq> mardy, I mean "cached" in signond or somewhere - in memory basically
[10:20] <mardy> Saviq: I don't think so, but the OA UI is coming from the online-accounts-ui D-Bus service, which exits after a few seconds of inactivity
[10:20] <mardy> Saviq: if you just briefly closed and re-opened it, it may be that the old process was reused
[10:20] <Saviq> hmm on second look it seems that online-accounts-ui doesn't even work on the desktop
[10:20] <Saviq> seb128, ↑
[10:20] <seb128> Saviq, you mean?
[10:20] <Saviq> for U1
[10:21] <Saviq> seb128, I mean I can't add a U1 account through g-c-c
[10:21] <Saviq> http://pastebin.ubuntu.com/7032274/
[10:21] <seb128> right, I noticed that recently as well
[10:21] <seb128> it works through ubuntuone-control-panel-qt though
[10:22] <mardy> seb128, Saviq: actually, IIRC we never had a U1 account plugin for the desktop
[10:22] <seb128> mardy, but it's showing in the list of "protocols" in the u-c-c UI
[10:22] <Saviq> seb128, mardy, yeah, so in fact it's probably fine for the plugin to not be there either
[10:22] <seb128> mardy, which is confusing
[10:22] <Saviq> (there == on the desktop)
[10:22] <Saviq> it is
[10:23] <mardy> seb128: it definitely shouldn't be listed, but I think it will go away if you remove the plugin
[10:24] <seb128> mardy, not sure how I got the plugin installed, I guess that's because of touch stuff
[10:25] <seb128> but yeah, still a bug
[10:25] <mardy> seb128: yep
[10:25] <Saviq> mardy, actually I can't get it to disappear from g-c-c...
[10:25] <Saviq> removed he plugin, killed signon*
[10:25] <Saviq> it's still there...
[10:25]  * Saviq files bugs
[10:26] <seb128> Saviq, do you have ubuntuone-credentials-common installed?
[10:26] <seb128> Saviq, that ships /usr/share/accounts/providers/ubuntuone.provider
[10:26] <Saviq> seb128, yeah
[10:27] <seb128> if I move that file away it stops being listed
[10:27] <Saviq> seb128, +1
[10:27]  * Saviq not sure where to file bug... the provider shouldn't be there if the plugin isn't there, should it...
[10:27] <Saviq> and it shouldn't be listed in g-c-c anyway, as it's incompatible with it apparently
[10:28] <seb128> Saviq, open on gnome-control-center-signon and let mardy reassign if needed I guess? ;-)
[10:29] <Saviq> seb128, ;)
[10:34] <Saviq> seb128, mardy, bug #1287640
[10:34] <seb128> Saviq, thanks
[10:34] <mardy> Saviq: thanks
[11:03] <mzanetti> Saviq: in here https://code.launchpad.net/~mzanetti/unity-api/new-screenshot-and-focusing-api/+merge/199810
[11:03] <mzanetti> Saviq: line 157, is this enough?
[11:04] <Saviq> mzanetti, should be
[11:04] <mzanetti> thanks
[11:04] <Saviq> mzanetti, the resulting .pc file has it as the version?
[11:05] <Saviq> mzanetti, unity-mir needs an update of Provides, and unity8 needs and update of Depends (and unity8-fake-env of Provides:, too)
[11:05] <mzanetti> yep, its in there
[11:05] <mzanetti> right...
[11:28] <mzanetti> Saviq: ok... I think we can start reviewing the right edge stuff... there's quite a bit stuff to fix for sure, but I think feedback from reviewers would help me a lot in this stage
[11:29] <Saviq> mzanetti, any dep or conflict with new-scopes?
[11:29] <mzanetti> Saviq: yes. it'll conflict with new-scopes as is right now... but as I don't know how long new-scopes will still take I based everything on trunk, hoping that the right edge would land first
[11:30] <Saviq> mzanetti, ok, let's see that race ;)
[11:31] <mzanetti> Saviq: we also could agree on an order... but I'd need an ETA for new-scopes then
[11:31] <mzanetti> and last time I asked you weren't sure about that => I went for trunk
[11:32] <mzanetti> in any case. the stuff that conflicts is 90% dropping the new-scopes stuff and using the right-edge stuff
[11:32] <mzanetti> and I can obviously do/help with the merge, regardless who comes first
[11:33] <Saviq> mzanetti, yup, well we'd like new-scopes to land asap, they basically need a review soon, too
[11:33] <Saviq> mzanetti, but probably some cleanup first
[11:35] <Saviq> mzanetti, could you look into dropping the HUD (just the integration part in Shell.qml for now) and skip the hud tests in autopilot?
[11:35] <mzanetti> Saviq: ack.
[11:39] <Saviq> mzanetti, btw, https://wiki.ubuntu.com/Process/Merges/Checklists/Unity-Mir
[11:39] <mzanetti> Saviq: ?
[11:40] <Saviq> mzanetti, on your merge for unity-mir, please add the checklists
[11:40] <Saviq> -s
[11:40] <mzanetti> huh? isn't it there? /me checks
[11:40] <Saviq> mzanetti, ah, I meant -api
[11:40] <Saviq> mzanetti, and yeah, it's there
[11:40] <Saviq> mzanetti, sorry for the noise
[11:41] <mzanetti> np
[11:41] <mzanetti> so yeah, you start from here https://code.launchpad.net/~mzanetti/unity8/right-edge-2/+merge/204798 and all the related ones are listed in the checklist
[11:43] <Saviq> mhr3_, what do we do about:
[11:43] <Saviq> 24	-Recommends: ${unity-default-masterscopes},
[11:43] <Saviq> 25	+ unity-scope-scopes,
[11:43] <Saviq> 26	+ unity-scope-onlinemusic,
[11:43] <Saviq> 27	+ unity-scope-mediascanner2,
[11:43] <Saviq> 28	+ unity-scope-click,
[11:44] <Saviq> ETOOMANYmhr3s
 mhr3_, what do we do about:
[11:44] <Saviq>  24 -Recommends: ${unity-default-masterscopes},
[11:44] <Saviq>  25 + unity-scope-scopes,
[11:44] <Saviq>  26 + unity-scope-onlinemusic,
[11:44] <Saviq>  27 + unity-scope-mediascanner2,
[11:44] <Saviq>  28 + unity-scope-click,
[11:45] <mhr3> Saviq, hmmm
[11:45] <mhr3> we don't really have desktop vs phone now
[11:45] <mhr3> so if we keep it as hard recommends it'd be fine imo
[11:45] <mhr3> for now anyway
[11:46] <Saviq> mhr3k
[11:53] <tsdgeos> hmmm
[11:53] <tsdgeos> don't know what i did but my unity8 indicators area is now empt
[11:53] <mzanetti> Saviq: when you said disable the hud, you really meant to get rid of the hud completely? as in: if you drag from the bottom edge the hud button would not appear any more?
[11:53] <tsdgeos> any idea why that may be happening?
[11:53] <mzanetti> tsdgeos: same here
[11:53] <tsdgeos> oh really?
[11:54] <mzanetti> tsdgeos: I merged with tnrunk and they appeared again
[11:54] <tsdgeos> that's really unfortunate when i'm trying to fix a crash in indicators :D
[11:54] <mzanetti> :D
[11:54] <tsdgeos> mzanetti: hmmm, i'm up to date with trunk
[11:54]  * tsdgeos does a clean build
[11:54] <mzanetti> tsdgeos: well, I did a run_on_device on my right-edge-stuff and they were gone as of today, I did some merging, rebooting, rebuilding and they appeard again
[11:56] <tsdgeos> ok
[11:56] <tsdgeos> this is on the desktop fwiw
[11:56] <tsdgeos> nope, nothing
[11:57] <tsdgeos> what, i'm getting the fake scopes
[11:57]  * tsdgeos puzzled
[11:58] <tsdgeos> i must have broken something with the ppa purge :-/
[11:59] <Saviq> mzanetti, yes, get rid of it
[11:59] <mzanetti> my pleasure, sir
[11:59] <Saviq> mzanetti, it's going "somewhere else", but we don't know where yet
[12:00] <tsdgeos> and they are back
[12:00] <tsdgeos> after installing unity8
[12:00] <tsdgeos> that brought lots of packages that build -c didn't
[12:00] <tsdgeos> weird
[12:00] <Saviq> tsdgeos, build -c doesn't
[12:00] <Saviq> tsdgeos, build -s does
[12:00] <tsdgeos> ahhhh righto
[12:01] <mzanetti> Saviq: that pCell stuff is crazy (the cool way) :)
[12:18] <Saviq> mzanetti, indeed!
[12:27] <mzanetti> Saviq: is this how you imagined it? https://code.launchpad.net/~mzanetti/unity8/disable-hud/+merge/209226
[12:27] <Saviq> mzanetti, nah, just remove it from Shell altogether
[12:27] <Saviq> mzanetti, so that we don't even instantiate it
[12:27] <mzanetti> ok
[12:27] <Saviq> mzanetti, we can easily bring it back with bzr
[12:28] <Saviq> /food
[12:28] <mzanetti> ok
[12:30] <mzanetti> tsdgeos: the BottomBar is only there for revealing the hud, right?
[12:30] <tsdgeos> mzanetti: yes
[12:30] <mzanetti> ok. /me removes the BottomBar too
[13:53] <Saviq> dednick, what can we do about the "unity8 exiting kills indicators" thing? ;) it's getting annoying ;D
[13:54] <mhr3> saviq, thoughts about adding an activityindicator to a scope view when there are no results visible and the one in the search bar isn't visible either? ie for surfacing
[13:54] <dednick> Saviq: um. check if it's being run on desktop i guess.
[13:55] <Saviq> mhr3, I think it could fit somewhere in the new header
[13:55] <davidcalle> mhr3, on a slightly related topic, could we have somehting like "pull to reload", to update surfacing? (eg. news scope)
[13:55] <Saviq> mhr3, like replace the looking glass icon
[13:55] <Saviq> davidcalle, nothing to do with mhr3 ;D
[13:55] <mhr3> saviq, so basically needs design :)
[13:55] <mhr3> davidcalle,  ^^
[13:55] <Saviq> yup
[13:56] <mhr3> i'll talk with mike
[13:56] <mhr3> but tbh i'd like the pull to reload too
[13:56] <mhr3> would mean caching == solved :)
[13:57] <dednick> Saviq: i'll take a look
[13:57] <Saviq> dednick, don't worry, was just a I-got-annoyed-by-this-right-now issue ;)
[13:58] <mhr3> saviq, same for my indicator issue btw ^ :)
[14:01] <Saviq> mhr3, ENOUNDERSTOOD
[14:01] <mhr3> saviq, no activityindicator -> also I-got-annoyed-by-this-right-now
[14:01] <Saviq> mhr3, ah ;)
[14:06] <Saviq> MacSlow, hey, can I steal you for some investigation on notification ap tests?
[14:06] <Saviq> MacSlow, i.e. http://ci.ubuntu.com/smokeng/trusty/touch/mako/219:20140304:20140304/6967/unity8/848175/
[14:06] <MacSlow> Saviq, looking...
[14:07] <Saviq> MacSlow, somehow the assertion fails, even though I can see the notification correctly and the icon is there
[14:07] <Saviq> so iconSource is definitely != ""
[14:07] <Saviq> MacSlow, so it might be something with ap
[14:08] <MacSlow> Saviq, most likely
[14:10] <MacSlow> Saviq, I'm still wondering, if those could somehow be moved to pure qmltests... what keeps me away from porting them, is the missing interaction with the real backend
[14:11] <Saviq> MacSlow, right, these are of the kind that should stay this way - they're integration tests
[14:11] <Saviq> MacSlow, *maybe* less extensive
[14:13] <MacSlow> Saviq, I don't know enough of AP's internals to provide a better (non-string based) test there... which might be more robust
[14:15] <mhr3> saviq, btw qtry_compare sucks - i replaced it with qsignalspy and shaved off almost 3seconds from make test
[14:18] <MacSlow> Saviq, these AP-tests for snap-decisions "failing" have held back jenkins-approvals many times
[14:20] <Saviq> MacSlow, yeah, but not that one, I'm getting 100% fail on that
[14:20] <Saviq> MacSlow, where before it was just flaky
[14:20] <Saviq> MacSlow, and the only failures that we look over currently are unity8 crashes, which that one isn't
[14:21] <MacSlow> Saviq, it's not new notification-code at fault I bet, as I'm still waiting on some reviews :)
[14:22] <Saviq> MacSlow, yeah I know ;) nothing ours changed recently - while autopilot did
[14:22] <Saviq> MacSlow, so ok, I'm looking into it further
[14:23] <MacSlow> Saviq, is there maybe a "state" that AP stores, which is not in sync with the real notification?
[14:29] <Saviq> MacSlow, not sure, but just confirmed old autopilot passes this test, upgrading 1 by 1 now
[14:29] <MacSlow> Saviq, bisecting the other way ;)
[14:31] <tsdgeos> @unity: standup?
[14:48] <Saviq> mzanetti, bug #1287689 is already marked as dupe of the non-rotating shell
[14:48] <Saviq> mzanetti, or maybe we just multiplexed - I was clearing it up with Jamie in #ubuntu-touch
[14:48] <mzanetti> Saviq: ok. sorry. missed that
[14:49] <Saviq> mzanetti, don't be :)
[14:49] <mzanetti> but in any case, Jamie's report seems a dupe of some bug :)
[14:49] <Saviq> mzanetti, also
[14:49] <Saviq> plugins/Utils/easingcurve.h	UNKNOWN	*No copyright*
[14:49] <Saviq> plugins/Utils/easingcurve.cpp	UNKNOWN	*No copyright*
[14:49] <Saviq> qml/Stages/SwitchingApplicationImage.qml	UNKNOWN	*No copyright*
[14:49] <Saviq> qml/Stages/SpreadDelegate.qml	UNKNOWN	*No copyright*
[14:49] <Saviq> qml/Stages/TransformedSpreadDelegate.qml	UNKNOWN	*No copyright*
[14:49] <mzanetti> meh...
[14:49] <mzanetti> thanks. I'll fix
[14:50] <mzanetti> Saviq: doing a hangout on air now for an hour. so if possible, ping me again after 5pm :)
[14:50] <Saviq> mzanetti, will do
[16:08] <Saviq> mterry, qt is crashing on startup some 5-10% of the runs
[16:08] <mterry> Saviq, :(  that makes tests hard to rely on
[16:09] <Saviq> mterry, is fixed with 5.2
[16:09] <mterry> Saviq, ah!  OK, I saw you all talking about that in emails
[16:09] <Saviq> mterry, yup
[16:10] <mterry> Saviq, well, that branch is ready, I think
[16:11] <Saviq> mterry, please chase reviewers, then :)
[16:12] <tsdgeos> Mirv: we need https://codereview.qt-project.org/#change,79857 in 5.2.1
[16:16] <Saviq> fixes bug #v
[16:16] <Saviq> 1277206
[16:16] <Saviq> bug #1277206 grr
[16:32] <mhr3_> saviq, how do we want to deal with gotoScope / openScope that wants to define the search string / filter/department state?
[16:32] <mhr3_> saviq, should i be passing that somehow to the signals, or try to deal with it internally?
[16:33] <mhr3_> saviq, basically i'm pretty sure that if i set a .searchString on the scope, you're going to invalidate it as soon as you create the visual component
[16:34] <mhr3_> or am i wrong?
[17:07] <Mirv> tsdgeos: Saviq: luckily weekly meeting now, pushing a build so that I check it compiled fine in the morning and copy the landing PPA
[22:18] <kdub> mterry, is there a command line way to start usc?
[22:19] <mterry> kdub, not really, it heavily relies on its two-way communication with lightdm
[22:19] <mterry> kdub, if you want to insert yourself
[22:19] <mterry> kdub, edit /usr/share/ubuntu-touch-session/usc-wrapper
[22:20] <kdub> mterry, alright, thanks
[22:31] <tedg> mterry, So, it seems we did similar work...
[22:31] <mterry> tedg, on volume/mute?  bummer
[22:31] <tedg> mterry, I've got a bunch of stuff going into account service.
[22:31] <tedg> mterry, But not volume/mute
[22:31] <mterry> tedg, the source package?
[22:31] <tedg> mterry, But I set up nice proxies and stuff :-)
[22:32] <tedg> mterry, https://code.launchpad.net/~ted/indicator-sound/account-service-support/+merge/205891
[22:35] <mterry> tedg, interesting.  Shouldn't conflict with my stuff though
[22:36] <tedg> mterry, Yes, but the volume/mute should probably go into sound settings.
[22:36] <mterry> tedg, also, these policykit permissions keep being duplicated around.  We might want to consolidate on com.ubuntu.AccountService.GreeterReadAny and GreeterModifyAny
[22:36] <mterry> tedg, settings?
[22:36] <tedg> +1
[22:36] <tedg> mterry, The account service schema
[22:37] <mterry> tedg, like this?  https://code.launchpad.net/~mterry/gsettings-ubuntu-touch-schemas/volume/+merge/209158
[22:38] <mterry> tedg, that also can provide the generic polkit actions
[22:38] <tedg> mterry, It should go in the one installed by indicator-sound
[22:38] <tedg> It seems they're more about indicator-sound than touch.
[22:38] <mterry> tedg, why necessarily?  That package above already contains lots of sound related settings
[22:38] <mterry> tedg, they are trying to remove the touch namespace wherever possible
[22:39] <mterry> tedg, they renamed the binaries, and will rename source
[22:39] <tedg> mterry, [22:40] <mterry> tedg, that's because com.ubuntu.touch.AccountsService.Sound.xml with the other sound settings exists, but they haven't migrated them to non-touch namespaces yet
[22:40] <tedg> Who is setting those?
[22:40] <mterry> tedg, telephony-service and ubuntu-system-settings look at the other settings like ringtones and silentmode
[22:41] <mterry> tedg, it's true that indicator-sound is the only one that currently needs to look at volume/mute, but they seemed like system-y settings that indicator-sound was just an implementation detail of
[22:42] <mterry> tedg, but I'd be happy to move them over if you feel like that's where they ought to live
[22:42] <tedg> mterry, Well, I didn't realize that we had an entire repo of random settings… still deciding how I feel about that.
[22:43] <tedg> What I'd really like is that they're stored in ALSA and the greeter and user session both read from there.
[22:43] <tedg> That's probably a minor pipe dream right now.
[22:43] <mterry> tedg, does ALSA have the per-user permission structure to allow that?
[22:43] <tedg> I think that's what logind is setting the permissions of using the ACLs.
[22:44] <tedg> The stuff we're getting around with the audio group.
[22:44] <mterry> tedg, but for storing settings?  And we'd need to be able to adjust settings when user isn't logged in by logind
[22:44] <tedg> We'll they're not settings. They're state.
[22:45] <tedg> logind thinks that the greeter is a login session :-)
[22:45] <mterry> tedg, fair.  "but for storing state?  And we'd need to be able to adjust state when user isn't logged in by logind"
[22:45] <tedg> Yes, it does. It's reading/writing that state to the audio chips. Really it's stored there.
[22:46] <mterry> tedg, how does that work for multiple users?
[22:47] <tedg> mterry, Well, you only have one set of speakers. So the audio chip doesn't really understand multiple users. Logind gives permission to modify the driver based on who as the active session.
[22:48] <mterry> tedg, I get that.  But how does volume setting normally work in that environment?  Like, if I have two users open, who sets the volume when I switch from one session to another?
[22:48] <tedg> mterry, I believe it's who ever is the active session. So when you switch, you trade control.
[22:49] <tedg> Fast user switching volume fight, go!
[22:49] <mterry> tedg, sure, but which component is changing the volume is my interest
[22:49] <mterry> tedg, because the correct volume to set must be saved somewhere for that user
[22:50] <tedg> mterry, I don't  know how Pulse behaves there, but I'd hope it doesn't reset it when you change. You wouldn't want to take your laptop to a coffee shop, mute it, and then switch users to music blaring.
[22:51] <mterry> tedg, I thought volume setting was per-user today.  Just not shared with greeter
[22:51] <tedg> mterry, It could be. Each user has a Pulse daemon.
[22:52] <tedg> mterry, I think the issue is that logind isn't giving access to lightdm?
[22:52] <mterry> tedg, ok, so theoretical ideal place for greeter to talk to would be pulse
[22:52] <mterry> tedg, but it doesn't have per-user outside-of-home support for accessing/setting state
[22:52] <tedg> Well, no, pulse is per-user. ALSA.
[22:53] <mterry> tedg, but then when they logged in, pulse would override that state, right?
[22:53] <mterry> either pulse holds the right user volume state or it doesn't
[22:53] <tedg> mterry, I'm not sure on that, but I don't think it should.
[22:53] <tedg> We really need diwic here for this.
[22:53] <tedg> Perhaps tomorrow morning would be a better time :-)
[22:54] <mterry> tedg, anyway, I restarted the design discussion, but the design has been and still is per-user volume state
[22:54] <mterry> tedg, hence keeping it in AS
[22:55] <tedg> mterry, Hmm, where is that discussion?
[22:56] <mterry> tedg, there was some in email, but mostly in long-standing bug 840777
[22:56]  * tedg subscribes
[22:57] <mterry> tedg, the bug description outlines what design (JohnLea) wants.  I recently re-confirmed with him that it's correct.  But mpt and laney disagree
[23:01] <tedg> We have a bunch of multi-user issues. Need to put design time there.
[23:01] <mterry> tedg, not too much time!
[23:02] <tedg> mterry, We wouldn't want to take away from redesign v10 of the notifications ;-)
[23:04] <mterry> tedg, :)  I was more worried about 14.04
[23:04] <tedg> mterry, We've got at least 6 weeks before final designs are due for that!
[23:05] <tedg> ;-)
[23:05] <mterry> :)