14:00:07 <stickster> #startmeeting Workstation WG
14:00:07 <zodbot> Meeting started Wed Mar 16 14:00:07 2016 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:07 <zodbot> The meeting name has been set to 'workstation_wg'
14:00:09 <stickster> #meetingname workstation
14:00:09 <zodbot> The meeting name has been set to 'workstation'
14:00:13 <stickster> #topic Roll call
14:00:14 <JacobCZ> oh, sorry, didn't realise :D I meant EMEA
14:00:17 <stickster> .hello pfrields
14:00:19 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
14:00:20 <mcatanzaro> .hello catanzaro
14:00:22 <zodbot> mcatanzaro: catanzaro 'None' <mcatanzaro@gnome.org>
14:01:51 * stickster waits for the crowd to arrive... in the meantime, o/ michael
14:02:02 <mcatanzaro> o/ stickster
14:02:05 <kalev> hello!
14:02:12 <stickster> #chair mcatanzaro kalev
14:02:12 <zodbot> Current chairs: kalev mcatanzaro stickster
14:02:15 <stickster> o/
14:02:26 <kalev> \o/
14:02:32 <mcatanzaro> I see wtay is here for the PulseAudio discussion
14:02:45 <wtay> \o.
14:02:50 <stickster> Hi Wim!
14:03:27 <wtay> Hey everyone
14:03:34 <mcatanzaro> Also patrakov
14:03:42 <patrakov> hi
14:04:10 <stickster> \o :-)
14:04:31 <mclasen___> .hello mclasen
14:04:32 <zodbot> mclasen___: mclasen 'Matthias Clasen' <mclasen@redhat.com>
14:04:43 <stickster> #chair mclasen___ rdieter_work
14:04:43 <zodbot> Current chairs: kalev mcatanzaro mclasen___ rdieter_work stickster
14:04:53 <stickster> Let's get started
14:04:59 <stickster> #topic Default applications
14:04:59 <rdieter> .hello rdieter
14:05:00 <zodbot> rdieter: rdieter 'Rex Dieter' <rdieter@math.unl.edu>
14:05:01 <rdieter> hola
14:05:05 <stickster> #chair rdieter
14:05:05 <zodbot> Current chairs: kalev mcatanzaro mclasen___ rdieter rdieter_work stickster
14:05:12 <stickster> o/ Rex :-)
14:06:34 <stickster> #info mcatanzaro dropped proposal for dropping Evolution + Boxes for now. Currently we have added Logs, dropped Bijiben, and propose to keep Shotwell and Rhythmbox around until Photos and Music are ready to move into the set of upsream core modules.
14:07:12 <stickster> First, are there any objections to Logs/Bijiben changes?  If so, now's the time to say so :-)
14:07:29 <mclasen___> I was going to comment on this, since I've heard a bit of chatter regarding the 'workstation aligns to upstream gnome' push
14:07:47 <stickster> please
14:08:01 <mcatanzaro> "more or less aligns"
14:08:03 <mclasen___> it might be worth stressing that this is actually an alignment that we're doing on both sides: we've made changes on the upstream gnome modulesets to align better with whats in the workstation
14:08:16 <mclasen___> so it is not just changes on the fedora side to follow the whims of upstream
14:08:37 <mclasen___> just wanted to clarify that, for the record
14:08:58 <mcatanzaro> Indeed, I moved lots of apps into GNOME core to match what Fedora is shipping.
14:09:07 <stickster> mclasen___: mcatanzaro: Any examples you want to include? (I'm in favor/agreement, ftr)
14:09:28 <mcatanzaro> cheese, file-roller, gedit, gnome-characters, gnome-clocks, gnome-initial-setup, gnome-logs, gnome-maps, gnome-software, gnome-weather
14:09:44 <stickster> :-) noted!
14:10:11 <mcatanzaro> We're basically trying to make the upstream modulesets "sane"
14:10:25 <stickster> #info Alignment between Workstation and GNOME upstream is a two-way street -- both projects have done some work to better align
14:10:26 <mcatanzaro> As distros could not reasonably do anything with the previous ones.
14:10:30 <mclasen___> you've also pushed a bunch of immature apps back to a new 'incubator', right ?
14:11:17 <mcatanzaro> Yes, I'm using "incubator" for stuff that we want to be in core, but which we think are not quite ready yet (gnome-music, gnome-photos, gnome-calendar, gnome-boxes for now, gnome-dictionary).
14:11:51 <mcatanzaro> Kind of a compromise between plans and reality.
14:12:28 <stickster> This makes sense to me too. Shall we knock out the Shotwell and Rhythmbox issue before we bore the PA guys to death? :-)
14:13:02 <mclasen___> as I've suggested on the list recently, we should make some concrete criteria for when to move music and photos (and boxes) back out of the incubator
14:13:13 <stickster> #idea mclasen noted we should push for Music + Photos to replace RB + Shotwell in F25, and have criteria for that replacement.
14:13:37 <mclasen___> I believe we had some discussion around such criteria for photos at some point
14:13:42 <mcatanzaro> The criteria should probably be a subset of what's on https://wiki.gnome.org/Apps/Music/Roadmap and https://wiki.gnome.org/Apps/Photos/Roadmap
14:13:46 <mclasen___> things like editing, import, export
14:14:00 <mclasen___> some of which have been addressed already
14:14:20 <mcatanzaro> I don't think we should set the criteria at this meeting, though. :)
14:14:46 <mclasen___> no
14:14:56 <stickster> mcatanzaro: As our resident proponent for All Things Default App, would you be willing to put together a first shot at a critical list of criteria for the mailing list?
14:14:57 <mclasen___> lets move on, and do criteria on the list
14:15:01 <stickster> mclasen___: agreed
14:15:19 <mcatanzaro> stickster: Yeah, but maybe not this week, I'll add it to my to-do list.
14:15:24 <mcatanzaro> +1 move on
14:15:31 <stickster> mcatanzaro: I think it would be safe to do for 4 weeks out
14:16:11 <stickster> #action mcatanzaro put together a first shot at criteria for Music + Photos default app swapout in F25
14:16:19 <stickster> moving on...
14:16:25 <stickster> #topic PulseAudio and flat volumes
14:16:58 <stickster> So there are essentially two questions we are still stuck on IIUC...
14:17:11 <stickster> 1. Is it reasonable to stick with the current situation of disabled flat volumes for F24?
14:18:04 <stickster> 2. What is the plan for volume control in the near future (toward F25/GNOME 3.22) and how it affects developers, users, and other pieces of the system UI?
14:18:56 <patrakov> 1. No working alternative has been implemented upstream so far
14:19:18 * stickster notes that the change for (1) was made based on Wim's input, but it's not irreversible, nor intended to dismay or marginalize the PA maintainers
14:19:27 <wtay> I think for 2. most of the gui is built around non-flat volumes..
14:19:39 <patrakov> 1a. GNOME guys are against per-application volume control anyway and so conveniently avoid the question
14:19:53 <wtay> you have the global volume on top, the per app volume as a volume slider in the apps
14:20:25 <patrakov> wtay: prpopnents of flat volumes want you to reinterpret this UI
14:21:09 <patrakov> the in-app slider, according to their opinion, is supposed to represent the absolute volume of that app, and the "master" is just a convenient handle for moving all app sliders
14:21:23 <wtay> I think we can all agree that giving flat volumes to all apps is a bad idea
14:21:27 <kalev> one important thing to note might be that Ubuntu ships with non-flat volumes, which means that this is what a lot of app developers target as well
14:21:38 <patrakov> on linux.org.ru such reinterpretation was called 'logic from mars", i.e. completely artificial and foreign
14:21:42 <stickster> kalev: There are a number of distros that do likewise
14:22:01 <patrakov> kalev: not only ubuntu, also arch and opensuse
14:22:29 <mclasen___> patrakov: I think we can leave the heated rhethoric out of this discussion
14:22:34 <stickster> patrakov: Let's please refrain from assigning motives or slinging rhetoric please
14:22:53 <stickster> we are here to discuss the roadmap ahead and use that to decide the right thing to do for Workstation
14:23:25 <wtay> I believe gnome would prefer to move to a role based volume design
14:24:37 <patrakov> wtay: yes, see their roadmap: https://wiki.gnome.org/Design/SystemSettings/Sound
14:24:43 <stickster> wtay: would that mean that some apps get to manipulate the user-set session volume, and some don't?
14:24:45 <mcatanzaro> I wonder what a "role-based volume design" is. :)
14:24:59 * stickster is not really clear on what this means from user POV... speaking as a user and a non-dev
14:25:32 * mclasen___ sees if he can get hadess over here to talk about gnomes volume control desires/plans
14:25:39 <wtay> it means a volume for "media" "notifications"and "alarms"
14:25:50 <patrakov> stickster: link above. although it omits details how foreign apps such as vlc (which have their own in-app volume slider) should behave in gnome environment
14:25:58 <wtay> so all media apps have the same volume slider, basically
14:25:58 <rdieter> what I'm interested in, is the any estimate or time-frame to address the issues behind our wanting to (temporarily) disable flat volumes
14:26:20 * stickster skims through the page
14:27:25 <mclasen___> way, patrakov: we should really bring in the relevant people here instead of second-guessing old design mockups
14:27:52 <rdieter> to me, that addresses most directly question 1, and how that affects future decision-making
14:29:09 <wtay> in any case, some (non gnome) apps would want to control the volume themselves and then we likely don't want to give them flat volumes
14:29:30 <wtay> like browsers
14:30:13 <stickster> wtay: mcatanzaro: Does that put us back in the situation where browser plugins can surprise (or hurt) users, or damage their hardware?
14:30:43 <patrakov> stickster: why "back"?
14:31:04 <wtay> stickster, not if we disable flat volumes
14:31:13 <stickster> Ah, OK
14:31:44 <mcatanzaro> stickster: I think wtay is proposing that apps that understand flat volumes can opt-in to the current behavior, but by default apps would not be able to raise the system volume.
14:31:58 <mcatanzaro> So that would avoid the problem we currently have where YouTube keeps setting the system volume to 1.
14:32:05 <wtay> if there is a mechanism to block some apps from using flat volumes, that would also avoid loud surprises
14:32:17 <stickster> mcatanzaro: Thanks, that's what I wasn't clear on.
14:32:22 <patrakov> wtay: there was a patch for that in pulseaudio archives
14:32:47 <mcatanzaro> I think it should be opt-in rather than opt-out, because reality is most apps are developed on Ubuntu and app developers don't understand or expect flat volumes.
14:32:56 <wtay> I would like the user to opt in on what apps can use flat volumes
14:33:00 <patrakov> wtay: it was rejected because it leads to inconsistent UI in pavucontrol (no way to determine visually whether the slider represents absolute volume or not)
14:33:40 <mclasen___> hadess: hey, any input from you on this ?
14:34:02 <hadess> mclasen___, i don't really care either way, because i want to remove application volumes altogether :)
14:34:05 <patrakov> wtay: search for "[RFC] Per-client flat-volumes control"
14:34:12 <wtay> but yes, some apps with and others without flat-volumes is very confusing in mixer apps
14:34:13 * stickster notes, no one has addressed rdieter's question about timeframes
14:34:33 <rdieter> stickster: maybe that means there isn't any time-frame (yet)
14:34:47 <hadess> mclasen___, that's one of the goals of the redesign: https://wiki.gnome.org/Design/SystemSettings/Sound
14:34:58 <mclasen___> wtay: does that mean we won't get such an opt-in api for clients ? or do we need to add more api for mixers to learn about clients choices ?
14:35:23 <hadess> mclasen___, per-application class volume, so your video playback apps have all the same volume, and they can't raise it themselves on startup
14:36:03 <wtay> mclasen___, if it were me, I would not let clients opt-in
14:36:04 <stickster> And the reason for asking about timeframe is mostly about seeing whether disabling flat volume is likely to be swapped out for some other change within one release, or not. It sounds to me like this won't be solved for some time yet, and we're not playing quick flip-flop with users by disabling FV now.
14:36:07 <mclasen___> hadess: which sounds like non-flat-volume-y to me ? or maybe I'm entirely confused now
14:36:09 <alexlarsson> can't raise it? surely there must be a volume control in a video player?
14:36:27 <hadess> alexlarsson, "on startup"
14:36:50 <alexlarsson> ok, so it can't restore its old saved volume in case some other video player changed inbetween?
14:36:52 <hadess> "stupid application, thinking it can remember its volume better than pulseaudio"
14:36:53 <alexlarsson> or somthing?
14:37:10 <patrakov> hadess: on pulseaudio side, there is no way to determine whether something is done "on startup" or based on user input
14:37:11 <hadess> alexlarsson, it doesn't have its own volume, there's a single volume for the class of application
14:37:12 <alexlarsson> makes sense, although a bit hackish
14:37:24 <alexlarsson> hadess: yeah, but the app might not be aware
14:37:36 <hadess> patrakov, details
14:38:29 <wtay> the role based volume would be more like flat volumes, you get only 1 slider
14:39:00 <hadess> wtay, either that, or it means that the volume inside the app is always relative to the system/class volume
14:39:08 <wtay> right
14:39:13 <alexlarsson> are the per-class volumes absolute or relative to some master volume?
14:39:18 <rdieter> I forget, were there any other flat-volume blocker'y type issues besides "apps surprising users with max volume" ?  or is that the only/primary one?
14:39:48 <patrakov> hadess: only the second option makes sense, because the first would bring the issue back - the app would bump the class volume to 100%
14:40:11 <hadess> rdieter: it's apps restoring their volume on startup, pushing the volume system volume up
14:40:35 <rdieter> hadess: whatever you want to call it, sure.  let's call it blue
14:40:45 <stickster> :-)
14:41:09 <hadess> it's broken apps, really
14:41:37 <rdieter> my point is, if that issue is addressed, then are we happy to re-enable flat-volumes?
14:42:39 <hadess> rdieter: what issue? the broken apps fixed? we're not in control for some of them
14:43:03 <rdieter> hadess: some apps will never be fixed, like web browsers
14:43:06 <wtay> and that's not even 'broken' in all cases
14:43:41 <patrakov> rdieter: I don't know a way to address the issue. We already have warnings at https://freedesktop.org/software/pulseaudio/doxygen/volume.html and https://freedesktop.org/software/pulseaudio/doxygen/introspect.html , but software authors who use abstraction layers such as gstreamer won't read our docs
14:43:46 <wtay> it needs to be blocked in pulseaudio somehow and only non-flat volumes can do that right now
14:44:16 <rdieter> It's my understanding, workstation WG is more-or-less considering this the primary blocker for enabling flat-volumes.  Please correct me if I'm wrong. ??
14:44:29 <stickster> rdieter: I don't recall another blockery issue like "hurt your eardrums/scare the bejeezus out of you"
14:44:37 <hadess> rdieter: they're already enabled
14:45:05 <stickster> hadess: I think rdieter means, reverse the disabling of them in shipped config
14:45:10 <stickster> which we just did recently
14:45:12 <hadess> right
14:45:17 <patrakov> hadess: they were disabled recently, the talk is about reenabling when the issue is fixed
14:45:34 <stickster> It sounds to me like that won't be, for example, within the next release
14:45:36 <mcatanzaro> hadess: Also websites changing the system volume to 1 via JavaScript, you must have experienced that on YouTube. To my understanding, WebKit is not broken...?
14:45:57 * mclasen___ has never experienced that
14:46:06 <wtay> mcatanzaro, correct
14:46:23 <stickster> mclasen___ noted it would be a little unruly to flip-flop our volume control approach within six months. But I'm not getting the sense that's likely.
14:46:23 <mcatanzaro> For some reason it happens to me with my new headphones, but never with my old headphones, I dunno why
14:46:28 <patrakov> mclasen___: get a demo: https://jsfiddle.net/bteam/FbkGD/ (try to reduce volume)
14:47:01 <mcatanzaro> Oh, patrakov got a CVE for this, I forgot about that. :p
14:48:11 <mclasen___> I still don't understand how that is anything other than a browser bug, but lets not go down that rabbit hole
14:48:36 <rdieter> ok, so given: 1.  we (WG) generally consider "hurt-your-eardrums" to be a blocker issue, and 2.  pulseaudio (or any other level of software stack) isn't going to address this in the foreseeable future, then I think the decision to disable flat volumes was the right one
14:48:52 <Southern_Gentlem> mclasen___,  yes in the borwser you cannot change the volume but the system control works
14:49:01 <patrakov> stickster: about flip-flopping, I don't see it as an issue, because it will likely be turned to class based volume control (if that is implemented) which is different both from flat and non-flat
14:49:22 <mcatanzaro> mclasen___: I don't understand it either, that's why patrakov and wtay are here. :)
14:50:07 <wtay> mclasen___, the browser does not really have any other option that to set the volume to 100% when the API is called to do that
14:50:12 <stickster> rdieter: It seems that way to me, too. And that if upstream introduces a new volume control model (such as class-based), we'd very likely just take that upstream configuration as our new one, and look at bug reports, rather than second guess the next model
14:50:28 <patrakov> mclasen___: it's "the same bug in two browsers" (firefox and webkit-based)
14:50:35 <rdieter> stickster: +1
14:50:43 <mclasen___> sounds like we're done then ?
14:51:29 * mcatanzaro senses we have consensus? :)
14:51:45 <wtay> disabled it remains..
14:51:52 <stickster> mclasen___: Unless someone wants to propose an additional change -- it sounds like there's still discussion for upstream to have but I didn't hear anyone screaming at us for the decision, which is good :-)
14:52:11 <mclasen___> stickster: we didn't really tell anybody
14:52:22 <mclasen___> which is maybe a good point: put this change in the release notes ?
14:52:39 <patrakov> mclasen___: I forwarded the invitation to David Henningsson, and he is not here
14:52:45 <stickster> mclasen___: aside from ML, bug, and this meeting, no -- but yes, release notes absolutely
14:53:02 <stickster> #action stickster add disabled flat volume note to release notes
14:53:09 <wtay> I think the only pulseaudio developer that likes flat volumes in theory besides me is Arun
14:53:59 <hadess> wtay, in theory, i guess the original implementer also likes them :)
14:54:40 <stickster> #agreed rough consensus: stay with disabled flat volumes, and stay aware of upstream changes in volume model for future releases
14:54:40 <wtay> it could be
14:55:04 <stickster> Thanks to all the PA and upstream guys for contributing to the discussion here.
14:55:11 <mclasen___> do we have time for another topic ?
14:55:11 <stickster> #topic Open floor (any other business)
14:55:17 <stickster> go for it mclasen___ !
14:55:23 <mclasen___> atomic workstation probably takes more than 5 minutes
14:55:31 * stickster has to close meeting abruptly at 11am, I have a call then
14:55:32 <mclasen___> not sure it makes much sense to open that
14:55:39 <mcatanzaro> Let's save it for next meeting
14:55:47 <mclasen___> if we have any one liner, lets rather do that
14:56:09 <stickster> #action stickster Make sure rpm-ostree/atomic workstation headlines at next meeting
14:56:17 <mclasen___> I will try to get atomic workstation prepared for  the next meeting, write a Change page draft, etc
14:56:42 <mclasen___> alexlarsson, amigadave: sorry I made you come to a flat volume discussion :-/
14:57:03 <alexlarsson> yay! :)
14:57:18 <stickster> heh
14:57:26 <stickster> alexlarsson: But we are around on #fedora-workstation all day
14:57:37 <stickster> anything else before we close? 30 sec to gavel drop! :-)
14:57:47 <alexlarsson> well, at least i missed my "learn about compass" talk
14:57:49 <mcatanzaro> Thanks for coming wtay and patrakov, I guess we'll be seeing alexlarsson and amigadave back next week :)
14:57:52 <alexlarsson> something good came out of it!
14:57:57 <patrakov> :)
14:57:58 <mcatanzaro> *in two weeks
14:58:11 <mclasen___> march 30
14:58:21 <stickster> OK, thanks all -- see you on the tubez
14:58:25 <stickster> #endmeeting