15:00:01 #startmeeting Workstation WG 15:00:01 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:01 The meeting name has been set to 'workstation_wg' 15:00:04 #meetingname workstation 15:00:05 The meeting name has been set to 'workstation' 15:00:08 #topic Roll call 15:00:10 .hello pfrields 15:00:11 stickster: pfrields 'Paul W. Frields' 15:00:31 * mclasen___ is here 15:00:36 cschalle sends his regrets 15:01:09 Hi 15:01:18 o/ 15:01:26 * stickster holds the door open a couple minutes 15:01:36 hola 15:01:44 hello! 15:01:56 sorry, afk for a bit, got a support call 15:02:13 Hi juhp? 15:02:51 no problem rdieter, thanks for checking in :-) 15:03:14 #chair mclasen mcatanzaro rdieter kalev 15:03:14 Current chairs: kalev mcatanzaro mclasen rdieter stickster 15:03:42 Well, we have a nominal quorum since Rex will probably drop back in soon... let's go 15:03:59 #topic Wayland status and update 15:04:17 #info mclasen dropped a helpful summary to the list so we can revisit this from last week 15:04:51 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 looking... 15:05:31 #link https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/message/2MAIRIHMJ5LZ2LKPDWNUV4GC6ZRDICYI/ 15:05:33 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 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 but that still gives us until the first week of march, I believe 15:06:05 sgallagh et al have been using it for day to day work 15:07:23 I continue to push until then to get the incomplete pieces in (startup notification is landing today, for example) 15:08:00 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 it has been implemented 15:09:18 oh? I must have misread, sorry 15:09:18 but the protocol has not been agreed on on the wayland side 15:09:52 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 hmmm, yeah 15:10:15 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 https://git.gnome.org/browse/gtk+/log/?h=wip/wayland-primary-selection is the gtk side of primary selection 15:11:02 https://git.gnome.org/browse/mutter/log/?h=wip/primary-selection is the mutter side 15:11:32 kalev: carlos' implemented a temporary solution for startup notification that is pretty much that, yes 15:11:50 ahh, cool 15:12:21 I'll make sure its correctly handled in pk session service too then 15:12:53 does the primary selection need support in qt as well? 15:13:25 kalev: if you are running qt apps as native wayland 15:13:39 are we? 15:14:17 for example, isn't the liveusb creator app Qt based? 15:14:38 not sure if that uses primary selection for anything, though. my recollection is "no" 15:14:46 hard to see much need for primary selection there... 15:14:48 I don't remember seeing any text forms 15:14:51 rdieter: any idea what the qt default backend is? 15:14:53 er, entry forms 15:15:28 kalev: liveusb-creator (at least for f23) is qt4 based it looks like 15:15:34 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 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 If we can't identify those then everyone potentially can have a different answer :-) 15:16:15 "whatever I think is important" :-D 15:16:38 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 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 I'm most concerned about the accessibility features. 15:17:46 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 keyboard accessibility features (sticky keys, slow keys, bounce keys, sound keys, etc) 15:17:53 visual bell - titlebar flashing won't work for csd. We should just flash the entire window in that case 15:17:55 mouse accessibility features such as hover-to-click 15:18:10 I believe the first 4 items in my status update were in the blocker category 15:18:45 Primary selection, input methods, tablet support, startup notification. 15:19:55 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 A11y features isn't among the top four, but also aren't done according to status 15:21:10 Should a11y be among the blocker list? 15:21:11 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 the on-screen keyboard has a separate item on the list 15:21:53 I think there's more here than can realistically be developed in the next three weeks 15:22:11 and orca is not in great shape under X either, if you ask me 15:22:18 thats neither here nor there 15:23:18 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 re: orca, perhaps... I believe we have several users around Fedora who use it (kendell on our list, jnadeau also) 15:23:50 mcatanzaro: you have your own clipboard implementation? 15:23:53 I would hate to think we come out with a release that they can't use 15:24:35 stickster: it seems that kendell is fairly satisfied with the state of orca in wayland from his mail this morning 15:24:46 otaylor: I hadn't seen that mail -- very good to know! 15:24:49 otaylor: yeah, I was glad to see that 15:24:53 * stickster breathes sigh of relief 15:25:01 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 they might have to pick the X session from the chooser once, then they can go about their business 15:25:39 true, it's not so black or white. good point. 15:25:45 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 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 We did it for a customer project but upstreaming the work is not gonna happen in the near future. :/ 15:26:26 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 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 mcatanzaro: does the web process have an X connection under X? 15:27:52 mcatanzaro: how did you arrive at the list of {*keys, visual bell, hover-to-click} ? 15:28:00 otaylor: Dunno 15:28:08 stickster: I copy-pasted it from https://fedoraproject.org/wiki/Wayland_features#accessibility_features 15:28:31 stickster: Which I could not have done under Wayland xD 15:28:35 mcatanzaro: "Is the web process sandboxed under X" ? 15:28:40 mcatanzaro: touché 15:28:50 otaylor: No, there's no web process sandbox period, why do you ask? 15:29:22 I mean, I worked on it a bit, but it's turned off because it's not any good. Seems unrelated? 15:29:34 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 mcatanzaro: you *probably* could open a wayland display connection used just for DND, use the GtkClipboard from that 15:30:25 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 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 (sorry to sidetrack) 15:30:59 stickster: people are asking for the other way around 15:31:43 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 but I don't think that is realistic 15:32:23 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 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 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 or rather, is it likely a similar set of new problems that will make it just as hard then :-) 15:34:07 otaylor: *jinx 15:34:22 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 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 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 Can we concentrate on deciding that, and move on? 15:35:25 mcatanzaro: Hmm, true, unlike X, wayland tries to restrict cut-and-paste based on the focus 15:35:27 otaylor: We really cannot rebase GTK+, it would break too much in F23; the others we could do 15:35:49 I bet we could backport the GDK Wayland backend changes if we really wanted to, though 15:36:03 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 stickster: I think tablet support is Wacom tablets 15:36:37 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 mcatanzaro: Doesn't that also mean touchscreens on some devices? 15:36:58 mcatanzaro: mclasen: Or is that a non-target? 15:37:29 stickster: qa didn't dictate that, no 15:37:38 mclasen: thanks, I wouldn't think so 15:38:39 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 And I'm not aware of any problems with touchscreen laptops, so.... 15:39:26 Let's do this methodically. 15:39:32 #proposed Blocker: primary selection 15:39:33 +1 15:39:51 +1 15:40:18 (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 +1 15:40:34 what mcatanzaro said, although s/never/only sometimes/ for me 15:40:46 otaylor: mclasen: ^^^ 15:40:53 +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 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 +1 for primary selection 15:41:51 #agreed Primary selection is a blocker (+5, 0, 0) 15:41:58 #proposed Blocker: Input methods 15:42:14 stickster: what do you mean by that? 15:42:21 +1, but it sounds like it's already done, right? 15:42:31 So it'd be a bit confusing to vote on it, I'd say #undo :) 15:42:43 mostly, fixing candidate window is the problem here -- do we really care about that? 15:42:48 #undo 15:42:48 Removing item from minutes: AGREED by stickster at 15:41:51 : Primary selection is a blocker (+5, 0, 0) 15:42:57 Nooo zodbot :p 15:42:59 #agreed Primary selection is a blocker (+5, 0, 0) 15:43:03 so #propose then? 15:43:04 dammit 15:43:16 stickster: Sounds like rtcm is going to land that fix soon regardless. 15:43:55 yes, and ibus is working fine, so skip. 15:44:19 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 well it's a positioning thing and a fix is coming, so it sounds like this will not be an issue 15:44:51 yeah 15:45:14 Can someone phrase what needs to be considered "done" for startup notification? 15:45:59 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 are you asking for a more detailed description of the feature? 15:46:49 mclasen: What needs to be done in order for us to say "startup notification, as a blocker, is cleared" 15:47:10 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 currently it keeps spinning until timeout 15:47:50 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 yeah, but at least we can be testing that in Alpha 15:48:30 #proposal Blocker: Startup notification 15:48:59 +1, sounds reasonable and should be testable in Alpha anyway 15:49:02 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 +1 15:49:10 +1 final blocker, -1 alpha blocker. 15:49:15 +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 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 mclasen: +1? 15:51:53 +1 for startup notification 15:52:17 mcatanzaro: Can you agree with the clarification ^^ I mentioned above? 15:52:21 stickster: +1 15:52:38 #agreed Startup notification is a blocker (+5, 0, 0) 15:52:49 OK, I'm going to take the remaining ones to list. 15:52:56 Fair enough 15:53:00 #action stickster take remaining blockers to list, we have 8 min left 15:53:26 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 #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 #undo 15:53:38 Removing item from minutes: 15:53:44 #topic Anything else on risk list for F24 15:53:49 I think there's GNOME 3.20, which is quite general, and not really "risky" per se. 15:54:03 not at risk: graphical upgrades - all the bits are in for that in 3.19.90 15:54:19 Live media creator is a question though. Does that affect anything about our plan for a Live USB Creator-installable? 15:54:38 mclasen: Eggggscellent 15:54:48 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 oof 15:55:17 mcatanzaro: how is the coverage of our default Workstation apps? 15:55:51 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 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 not that that would have stopped anybody from doing it... 15:56:36 So I guess the hope is that maintainers see the ugly and Do The Right Thing 15:56:43 And there have been several unintentional regressions, it's been a much rougher cycle than usual 15:56:59 The problem is maintainers will not see the ugly until they upgrade to F24 15:57:09 Well, that is what the Alpha is for after all 15:57:19 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 that really can't be helped, other than by qa of the alpha 15:57:21 We should be sure to make that a point for marketing 15:57:21 Yeah. 15:57:39 Like, "GNOME folks and fans, here's something to pay attention to" 15:57:59 it is certainly worth looking out for things that look wrong, style wise 15:58:06 #action stickster Make a note for F24 Alpha release notes to look for appearance issues in GTK+3 apps 15:58:24 mcatanzaro: We're not going to get to your PA flat volume topic today. Can you take that to list? 15:58:28 Yup. 15:58:34 I don't want that to wait for two weeks given the schedule 15:58:36 thank you sir 15:59:17 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 I'm concerned that LUC in F23 does not look particularly user-friendly.... 16:00:12 mcatanzaro: Are you using the one from the copr? 16:00:15 I don't know about anything about that - what is the problem ? 16:00:24 mclasen: OK, we'll have to take this to list, meeting time is over. 16:00:30 #topic One last thing 16:00:32 true 16:00:32 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 #info BIG thank you to mcatanzaro fo chairing last time :-) 16:00:53 And... that's it, we gotta run 16:00:58 #endmeeting