15:00:01 <stickster> #startmeeting Workstation WG
15:00:01 <zodbot> Meeting started Wed Feb 17 15:00:01 2016 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:01 <zodbot> The meeting name has been set to 'workstation_wg'
15:00:04 <stickster> #meetingname workstation
15:00:05 <zodbot> The meeting name has been set to 'workstation'
15:00:08 <stickster> #topic Roll call
15:00:10 <stickster> .hello pfrields
15:00:11 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
15:00:31 * mclasen___ is here
15:00:36 <mclasen___> cschalle sends his regrets
15:01:09 <mcatanzaro> Hi
15:01:18 <stickster> o/
15:01:26 * stickster holds the door open a couple minutes
15:01:36 <rdieter> hola
15:01:44 <kalev> hello!
15:01:56 <rdieter> sorry, afk for a bit, got a support call
15:02:13 <mcatanzaro> Hi juhp?
15:02:51 <stickster> no problem rdieter, thanks for checking in :-)
15:03:14 <stickster> #chair mclasen mcatanzaro rdieter kalev
15:03:14 <zodbot> Current chairs: kalev mcatanzaro mclasen rdieter stickster
15:03:42 <stickster> Well, we have a nominal quorum since Rex will probably drop back in soon... let's go
15:03:59 <stickster> #topic Wayland status and update
15:04:17 <stickster> #info mclasen dropped a helpful summary to the list so we can revisit this from last week
15:04:51 <mclasen> yeah, I sent a summary last night. If you haven't read it yet, now might be a good time.
15:04:59 * stickster searches for link
15:05:06 <stickster> looking...
15:05:31 <stickster> #link https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/message/2MAIRIHMJ5LZ2LKPDWNUV4GC6ZRDICYI/
15:05:33 <kalev> we've had the wayland session as the default in rawhide for a while, so it has gotten quite a bit of testing too
15:05:40 <mclasen> as for, timing of decision making, I did talk to the fedora qa team before devconf, and we tentatively agreed to make a go-no-go decision for wayland by default before f24 alpha
15:05:49 * mcatanzaro had not checked email yet, starts reading
15:05:53 <mclasen> but that still gives us until the first week of march, I believe
15:06:05 <kalev> sgallagh et al have been using it for day to day work
15:07:23 <mclasen> I continue to push until then to get the incomplete pieces in (startup notification is landing today, for example)
15:08:00 <stickster> It has. On the other hand, there are some gaps that may be a concern. mattdm asked me specifically about the primary selection status while we were in Brno and I think we want a story there beyond "nope" -- it looks like there's a proposal there but not implemented yet
15:09:02 <mclasen> it has been implemented
15:09:18 <stickster> oh? I must have misread, sorry
15:09:18 <mclasen> but the protocol has not been agreed on on the wayland side
15:09:52 <mclasen> I see if we can get that unstuck between now and end of February, but that may indeed be the one thing we end up blocking on
15:10:14 <stickster> hmmm, yeah
15:10:15 <kalev> mclasen: does the startup protocol include the current window time hack that is used for focus stealing prevention on X ?
15:10:27 * stickster is fine with waiting until pre-Alpha to make this determination, just to be clear... the only reason for revisiting this topic is to make sure everyone has access to the updates mclasen provided, and knows the timeline for deciding
15:10:47 <mclasen> https://git.gnome.org/browse/gtk+/log/?h=wip/wayland-primary-selection is the gtk side of primary selection
15:11:02 <mclasen> https://git.gnome.org/browse/mutter/log/?h=wip/primary-selection is the mutter side
15:11:32 <mclasen> kalev: carlos' implemented a temporary solution for startup notification that is pretty much that, yes
15:11:50 <kalev> ahh, cool
15:12:21 <kalev> I'll make sure its correctly handled in pk session service too then
15:12:53 <kalev> does the primary selection need support in qt as well?
15:13:25 <otaylor> kalev: if you are running qt apps as native wayland
15:13:39 <kalev> are we?
15:14:17 <stickster> for example, isn't the liveusb creator app Qt based?
15:14:38 <stickster> not sure if that uses primary selection for anything, though. my recollection is "no"
15:14:46 <mclasen> hard to see much need for primary selection there...
15:14:48 <stickster> I don't remember seeing any text forms
15:14:51 <kalev> rdieter: any idea what the qt default backend is?
15:14:53 <stickster> er, entry forms
15:15:28 <otaylor> kalev: liveusb-creator (at least for f23) is qt4 based it looks like
15:15:34 <otaylor> I think wayland support is only in qt5
15:15:40 * mclasen launches scribus in his wayland session and finds it showing up in xlsclients
15:15:47 <stickster> I think the general question we're probably tending toward here is... "What is the list of must-have's for Wayland that will cause a no-go flag?"
15:16:06 <stickster> If we can't identify those then everyone potentially can have a different answer :-)
15:16:15 <stickster> "whatever I think is important" :-D
15:16:38 <mclasen> I did take a stab at that back in december when I classified some of the items on the Wayland_features list as 'blocker
15:17:35 <stickster> mclasen: I was looking at https://fedoraproject.org/wiki/Wayland_features and couldn't find that, but maybe you put this on the tasklist?
15:17:43 <mcatanzaro> I'm most concerned about the accessibility features.
15:17:46 <mattdm> For what it's worth, I'm still pretty strongly of the opinion that we should keep with the earlier messaging of "one release where it all works (eg all blockers crossed off) before it's the default"
15:17:51 <mcatanzaro> keyboard accessibility features (sticky keys, slow keys, bounce keys, sound keys, etc)
15:17:53 <mcatanzaro> visual bell - titlebar flashing won't work for csd. We should just flash the entire window in that case
15:17:55 <mcatanzaro> mouse accessibility features such as hover-to-click
15:18:10 <mclasen> I believe the first 4 items in my status update were in the blocker category
15:18:45 <stickster> Primary selection, input methods, tablet support, startup notification.
15:19:55 <mclasen> of those, input methods are in ok shape, startup notification is supposedly landing today, tablet support and primary selection are still in the 'finalize protocol review' stage
15:21:09 <stickster> A11y features isn't among the top four, but also aren't done according to status
15:21:10 <stickster> Should a11y be among the blocker list?
15:21:11 <mcatanzaro> joanie is telling me Orca under Wayland is not in great shape, and I guess caribou (on-screen keyboard) does not work at all
15:21:43 <mclasen> the on-screen keyboard has a separate item on the list
15:21:53 <mcatanzaro> I think there's more here than can realistically be developed in the next three weeks
15:22:11 <mclasen> and orca is not in great shape under X either, if you ask me
15:22:18 <mclasen> thats neither here nor there
15:23:18 <mcatanzaro> The other thing not on the list in WebKit, we don't have any clipboard support yet, and we're not going to implement it in the near future, sorry. So no copy or paste in devhelp or yelp or gnome-online-accounts or Epiphany (to the extent you care about it)
15:23:34 <stickster> re: orca, perhaps... I believe we have several users around Fedora who use it (kendell on our list, jnadeau also)
15:23:50 <otaylor> mcatanzaro: you have your own clipboard implementation?
15:23:53 <stickster> I would hate to think we come out with a release that they can't use
15:24:35 <otaylor> stickster: it seems that kendell is fairly satisfied with the state of orca in wayland from his mail this morning
15:24:46 <stickster> otaylor: I hadn't seen that mail -- very good to know!
15:24:49 <mattdm> otaylor: yeah, I was glad to see that
15:24:53 * stickster breathes sigh of relief
15:25:01 <mclasen> now, now. even if the wayland session does not address the one or other use case, they will still be able to use the release
15:25:17 <mclasen> they might have to pick the X session from the chooser once, then they can go about their business
15:25:39 <stickster> true, it's not so black or white. good point.
15:25:45 <otaylor> stickster: I don't think that we can say that "a11y is a blocker" in the abstract - that doesn't mean much - do we require that a) there is usable support (already have that apparently) or b)everything wors better than it does on X
15:26:06 <mcatanzaro> otaylor: No, that's the problem, we used to use the GTK+ clipboard API from the web process. It doesn't work in Wayland, we have to set up clipboard proxying from the web process to the UI process.
15:26:20 <mcatanzaro> We did it for a customer project but upstreaming the work is not gonna happen in the near future. :/
15:26:26 <stickster> otaylor: of course -- I was more opening the door for some input on "what needs to work for us to be satisfied with a11y under Wayland"
15:27:01 <stickster> mcatanzaro laid out a set of functions which is a good start
15:27:02 * mclasen thinks you have to ask people with the relevant disabilities that question
15:27:24 <otaylor> mcatanzaro: does the web process have an X connection under X?
15:27:52 <stickster> mcatanzaro: how did you arrive at the list of {*keys, visual bell, hover-to-click} ?
15:28:00 <mcatanzaro> otaylor: Dunno
15:28:08 <mcatanzaro> stickster: I copy-pasted it from https://fedoraproject.org/wiki/Wayland_features#accessibility_features
15:28:31 <mcatanzaro> stickster: Which I could not have done under Wayland xD
15:28:35 <otaylor> mcatanzaro: "Is the web process sandboxed under X" ?
15:28:40 <stickster> mcatanzaro: touché
15:28:50 <mcatanzaro> otaylor: No, there's no web process sandbox period, why do you ask?
15:29:22 <mcatanzaro> I mean, I worked on it a bit, but it's turned off because it's not any good. Seems unrelated?
15:29:34 <otaylor> mcatanzaro: if it was sandboxed it couldn't have a X connection, if it's not sandboxed, then you probably just are connecting to the same X server
15:30:14 <otaylor> mcatanzaro: you *probably* could open a wayland display connection used just for DND, use the GtkClipboard from that
15:30:25 <stickster> It would be great if we knew that "Wayland by default in F(n) means these features will be done in F(n+1)" but that's pretty unrealistic :-)
15:30:35 <otaylor> mcatanzaro: I don't see why that wouldn't work even if you are using a nested wayland connection for everything else
15:30:58 <otaylor> (sorry to sidetrack)
15:30:59 <mclasen> stickster: people are asking for the other way around
15:31:43 <mclasen> I've also been asked if we could backport the wayland improvements from rawhide to f23 or make them available as a copr
15:31:59 <mclasen> but I don't think that is realistic
15:32:23 <stickster> mclasen: That sounds hard, yeah. But let me ask another question, will it get any easier once f24 is out, to backport from rawhide -> f24?
15:33:13 <stickster> iow, if the difficulty is based on invasive stack changes that will be in by f24 and maybe not such a problem
15:33:58 <otaylor> stickster: I think it's always going to be hard to bring in some big piece of work without rebasing a bunch of components
15:34:01 <stickster> or rather, is it likely a similar set of new problems that will make it just as hard then :-)
15:34:07 <stickster> otaylor: *jinx
15:34:22 <mcatanzaro> otaylor: I will ask Garnacho about your suggestion, but I think it won't work because the web process has no... something or other... mutter window? Hence the decision to use a clipboard proxy. https://github.com/WebKitForWayland/webkit/pull/14 is the downstream code we need to work with (sorry to sidetrack)
15:34:56 <stickster> All right -- we *do* need to get back to a real decision here of what to block on (I'm assuming QA didn't dictate this)
15:35:02 <otaylor> stickster: there's no *reason* we couldn't rebase GTK+/Mutter/Xwayland (xorg-x11-server) but that's not something we'd want to do for a released release
15:35:05 <stickster> Can we concentrate on deciding that, and move on?
15:35:25 <otaylor> mcatanzaro: Hmm, true, unlike X, wayland tries to restrict cut-and-paste based on the focus
15:35:27 <mcatanzaro> otaylor: We really cannot rebase GTK+, it would break too much in F23; the others we could do
15:35:49 <mcatanzaro> I bet we could backport the GDK Wayland backend changes if we really wanted to, though
15:36:03 <stickster> I'm OK with mclasen's four items as a start (although I don't know what "tablet support" means without OSK, but perhaps if OSK is planned to be done it's a non-issue)
15:36:16 <mcatanzaro> stickster: I think tablet support is Wacom tablets
15:36:37 <mcatanzaro> I'm not certain that needs to be a blocker. I would like to see OSK and the missing a11y features on the blocker list.
15:36:50 <stickster> mcatanzaro: Doesn't that also mean touchscreens on some devices?
15:36:58 <stickster> mcatanzaro: mclasen: Or is that a non-target?
15:37:29 <mclasen> stickster: qa didn't dictate that, no
15:37:38 <stickster> mclasen: thanks, I wouldn't think so
15:38:39 <mcatanzaro> stickster: Touchscreen laptops are an important target for GNOME, we should block if there are problems there. iPad-style tablets, not so much. Nobody is running Fedora on tablets anyway (besides awilliamson and a few adventurers), we shouldn't block on that.
15:39:09 <mcatanzaro> And I'm not aware of any problems with touchscreen laptops, so....
15:39:26 <stickster> Let's do this methodically.
15:39:32 <stickster> #proposed Blocker: primary selection
15:39:33 <stickster> +1
15:39:51 <mcatanzaro> +1
15:40:18 <mcatanzaro> (I never use it myself, but I know we're in for a deluge of complaints if we don't have it.)
15:40:34 <kalev> +1
15:40:34 <stickster> what mcatanzaro said, although s/never/only sometimes/ for me
15:40:46 <stickster> otaylor: mclasen: ^^^
15:40:53 <otaylor> +1 (if we're planning it, we can't take it away and then add it back in the next release - unnecessary noise)
15:41:09 <mclasen> stickster: I don't think tablet support needs to be a blocker, either - I put it on there because it was a prominent feature of gnome
15:41:23 <mclasen> +1 for primary selection
15:41:51 <stickster> #agreed Primary selection is a blocker (+5, 0, 0)
15:41:58 <stickster> #proposed Blocker: Input methods
15:42:14 <otaylor> stickster: what do you mean by that?
15:42:21 <mcatanzaro> +1, but it sounds like it's already done, right?
15:42:31 <mcatanzaro> So it'd be a bit confusing to vote on it, I'd say #undo :)
15:42:43 <stickster> mostly, fixing candidate window is the problem here -- do we really care about that?
15:42:48 <stickster> #undo
15:42:48 <zodbot> Removing item from minutes: AGREED by stickster at 15:41:51 : Primary selection is a blocker (+5, 0, 0)
15:42:57 <mcatanzaro> Nooo zodbot :p
15:42:59 <stickster> #agreed Primary selection is a blocker (+5, 0, 0)
15:43:03 <stickster> so #propose then?
15:43:04 <stickster> dammit
15:43:16 <mcatanzaro> stickster: Sounds like rtcm is going to land that fix soon regardless.
15:43:55 <stickster> yes, and ibus is working fine, so skip.
15:44:19 <mclasen> stickster: the candidate window is an integral part of the input method support, so I do think we care about it, but yes, it can be considered done (modulo testing)
15:44:48 <stickster> well it's a positioning thing and a fix is coming, so it sounds like this will not be an issue
15:44:51 <stickster> yeah
15:45:14 <stickster> Can someone phrase what needs to be considered "done" for startup notification?
15:45:59 <stickster> come on guys, let's not run the clock out here, help me out :-)
15:46:15 * mclasen not sure about the question
15:46:23 <mclasen> are you asking for a more detailed description of the feature?
15:46:49 <stickster> mclasen: What needs to be done in order for us to say "startup notification, as a blocker, is cleared"
15:47:10 <mclasen> the concrete thing that is needed is that the spinner next to the app menu disappears when a newly launched app opens its window
15:47:21 <mclasen> currently it keeps spinning until timeout
15:47:50 <mcatanzaro> That's the sort of serious polish issue that I would not want to see in the final release, but which would not matter so much in the alpha.
15:48:11 <stickster> yeah, but at least we can be testing that in Alpha
15:48:30 <stickster> #proposal Blocker: Startup notification
15:48:59 <stickster> +1, sounds reasonable and should be testable in Alpha anyway
15:49:02 <mcatanzaro> Looks like it's not going to be ready for the alpha... mclasen, any chance garnacho is free to get that in prior to beta timeframe?
15:49:03 <kalev> +1
15:49:10 <mcatanzaro> +1 final blocker, -1 alpha blocker.
15:49:15 <otaylor> +1 (though sounds mostly done for this purpose) - we can't make a release that looks that unpolished with wayland the default
15:50:00 <stickster> mcatanzaro: to be fair, it's not that it has to work correctly in Alpha to pass, just that there is enough implementation there to actually fix the bugs for final
15:50:45 <stickster> mclasen: +1?
15:51:53 <mclasen> +1 for startup notification
15:52:17 <stickster> mcatanzaro: Can you agree with the clarification ^^ I mentioned above?
15:52:21 <mcatanzaro> stickster: +1
15:52:38 <stickster> #agreed Startup notification is a blocker (+5, 0, 0)
15:52:49 <stickster> OK, I'm going to take the remaining ones to list.
15:52:56 <mcatanzaro> Fair enough
15:53:00 <stickster> #action stickster take remaining blockers to list, we have 8 min left
15:53:26 <mcatanzaro> Let's also discuss gnome-terminal on the list, it's shrinking by one row due to some window size code that doesn't work in Wayland
15:53:33 <stickster> #topic Anything else on risk list for F24?  I think there's GNOME 3.20, which is quite general, and not really "risky" per se.
15:53:38 <stickster> #undo
15:53:38 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f20c18ae350>
15:53:44 <stickster> #topic Anything else on risk list for F24
15:53:49 <stickster> I think there's GNOME 3.20, which is quite general, and not really "risky" per se.
15:54:03 <mclasen> not at risk: graphical upgrades - all the bits are in for that in 3.19.90
15:54:19 <stickster> Live media creator is a question though. Does that affect anything about our plan for a Live USB Creator-installable?
15:54:38 <stickster> mclasen: Eggggscellent
15:54:48 <mcatanzaro> stickster: To be blunt, GTK+ 3.20 is going to break layout or theming most GTK+ 3 apps. Most of the GNOME ones will be updated but many will not be. That's a risk (but we'll push forward with it anyway)....
15:55:02 <stickster> oof
15:55:17 <stickster> mcatanzaro: how is the coverage of our default Workstation apps?
15:55:51 <mcatanzaro> stickster: Most will be updated, but many will not be (without some particular effort to check them, which I don't intend to make :)
15:56:08 <mclasen> gtk 3.20 requires updates for apps that ship custom css, which was never meant to be a guaranteed stable api so far
15:56:33 <mclasen> not that that would have stopped anybody from doing it...
15:56:36 <stickster> So I guess the hope is that maintainers see the ugly and Do The Right Thing
15:56:43 <mcatanzaro> And there have been several unintentional regressions, it's been a much rougher cycle than usual
15:56:59 <mcatanzaro> The problem is maintainers will not see the ugly until they upgrade to F24
15:57:09 <stickster> Well, that is what the Alpha is for after all
15:57:19 <mcatanzaro> So, it would be nice to have some effort to check at least the apps we install by default; they'll probably be mostly fine.
15:57:20 <mclasen> that really can't be helped, other than by qa of the alpha
15:57:21 <stickster> We should be sure to make that a point for marketing
15:57:21 <mcatanzaro> Yeah.
15:57:39 <stickster> Like, "GNOME folks and fans, here's something to pay attention to"
15:57:59 <mclasen> it is certainly worth looking out for things that look wrong, style wise
15:58:06 <stickster> #action stickster Make a note for F24 Alpha release notes to look for appearance issues in GTK+3 apps
15:58:24 <stickster> mcatanzaro: We're not going to get to your PA flat volume topic today. Can you take that to list?
15:58:28 <mcatanzaro> Yup.
15:58:34 <stickster> I don't want that to wait for two weeks given the schedule
15:58:36 <stickster> thank you sir
15:59:17 <stickster> mclasen: Anything you (or anyone) can add on relationship between LMC-created ISOs and our ability to install in LiveUSB Creator? Is it basically "wait and see if things work, and fix them in a jiffy if not"?
15:59:58 <mcatanzaro> I'm concerned that LUC in F23 does not look particularly user-friendly....
16:00:12 <stickster> mcatanzaro: Are you using the one from the copr?
16:00:15 <mclasen> I don't know about anything about that - what is the problem ?
16:00:24 <stickster> mclasen: OK, we'll have to take this to list, meeting time is over.
16:00:30 <stickster> #topic One last thing
16:00:32 <mclasen> true
16:00:32 <mcatanzaro> No, I'm not. So I'm still skeptical on this primary deliverable change, but I agree in principle that it'd be nice to deliver a GUI USB creator rather than an ISO.
16:00:48 <stickster> #info BIG thank you to mcatanzaro fo chairing last time :-)
16:00:53 <stickster> And... that's it, we gotta run
16:00:58 <stickster> #endmeeting