On Sat, 23 Mar 2013 15:58:29 -0500 Jason Ekstrand <ja...@jlekstrand.net> wrote:
> Scott, > I have a few technical comments to make down below. Before I go onto > those, I want to make sure we are perfectly clear about the purpose of > this discussion. So please read the following through (multiple times > if needed) before going on to the technical bits. > > The Wayland project is primarily about PROTOCOL. Specifically, it is > about the Wayland core protocol: that which is described in > wayland/protocol/wayland.xml. What we (myself, Bill, and Pekka) are > trying to discuss with you is a proposed min/max PROTOCOL that will, > eventually, get added to wayland/protocol/wayland.xml. This has a > number of implications. > > First, we are talking about what the protocol OUGHT to be, not what it > is right now. Ideas that get thrown around in the mailing list need > to be evaluated and discussed based on their technical merits and how > clean they make the client/compositor interactions. We need to be > looking for the best possible solution to the problem as a whole. In > particular this means that "I have it working" is not a valid > justification in the face of technical issues or potentially better > solutions. > > Second, none of this is yet in wayland master. Until the min/max > protocol makes its way into a Wayland release, nothing is final and > everything is flexible. This means that the entire min/max protocol > is up for revision. Just because you "have it working" in your gh > next branch doesn't mean that it can't be thrown out and re-worked. > Also, It is not practical for us to hold a discussion based on the > incremental changes that you commit to your gh next branch. As the > protocol gets re-worked, please send new versions to the list, rebased > against wayland master, that incorporate those changes. This will > make it much easier to see how everything fits into the Wayland > protocol as a whole. (I already asked you to do this a few e-mails > ago.) > > Third, this discussion is NOT about implementation. While Weston and > your gh next Weston may be valuable, they are largely irrelevant to > the current discussion. What we need to focus on is trying to make > the client/compositor interactions as clean as possible. This has > nothing to do with the internal implementation details of Weston or > any other compositor. Those implementation details are useful only in > so far as they help us understand the client/compositor interactions > and the potential pitfalls of a given protocol. > > Finally, this is about the Wayland protocol, not the Weston protocol. > This means that we don't just throw a bunch of undocumented > events/requests into the protocol file, start implementing it in > Weston, and document how we ended up implementing it. That is exactly > backwards of how the protocol should be developed. I'm not saying > that implementing it in Weston isn't useful for getting the kinks out. > What I'm saying is that the protocol comes first and then we > implement it to make sure it works. > > One more thing before I go onto the technical details: Bill Spitzak. > Just because he gets on your nerves doesn't mean you should just > ignore him. You are very much into the implementation details whereas > Bill tends to come at things from a perspective that is more > high-level and theoretical. This is a very useful perspective when > discussing a protocol because the protocol should transcend the > details as much as possible. Bill does read the e-mails and he > frequently points out potential pitfalls that other people miss. He > is also usually very clear in his examples (in his first e-mail in > this series he drew you an ASCII-art picture to demonstrate what he > meant). You need to stop ignoring him and writing off everything he > says as worthless. At the very least you need to act towards him in a > more professional manner. > > Technical comments follow. > > On Fri, Mar 22, 2013 at 6:29 PM, Scott Moreau <ore...@gmail.com> wrote: > > Hi Pekka, thanks for your comments here. > > > >> > >> Scott, > >> > >> do you mean that these unminimize, unmaximize, etc. requests would > >> actually work like undo? Unmaximize would undo what the last > >> maximization did, as opposed to just set_normal which might do > >> something slightly different since its aim is to make the window > >> normal, not undo something? > > > > Right, I am asking if there is a case for such functionality. The more > > I think about it, it seems like it might seem like a bug in normal > > desktop usage. But if you happen to have another external program that > > you might want to use to manipulate window states, maybe you'd want a > > finer grain control there. I'm not sure of all the possible cases, > > which is why I'm asking for input. > > > >> > >> If so, does it make sense to have state specific undo requests? > >> > >> Consider this sequence, driven by the client: > >> 1. the window is normal > >> 2. maximize the window > >> 3. minimize the window > >> 4. unmaximize the window > >> > >> What happens at step 4? Is it possible to define the outcome of > >> such cases in an intuitive way? > > > > This illustrates the point perfectly. This is definitely all about > > semantics and expected behavior. This must be clearly documented in > > the protocol description. I had it working so you could do this. You > > could minimize, toggle maximized state and unmaximize with the correct > > state. This works fine when doing > > maximize->minimize->unmaximize->unminimize but causes a frame glitch > > when doing unmaximize->minimize->maximize->unminimize. The frame > > glitch is probably easily worked around. However, it is noteworthy > > that if you have this behavior, then you can't assume that maximize > > and toplevel will be counterparts, but instead, that you'd need > > explicit unmaximize notification. > > The last thing we want is a protocol full of "semantics and expected > behaviour". If implementing this correctly requires a lot of expected > behaviour, we need to re-think the protocol. > > To solve this problem I suggested above that we simply replace all of > the set_X and unset_X requests with set_X requests and one > "set_normal" or whatever that returns to a default window state. This > way, instead of having to worry about what to set/unset to get to a > desired state, the client simply tells the compositor what the next > state should be. In order to do things correctly, the client is going > to have to track state anyway, so it might as well explicitly tell the > compositor what state it wants next. (This suggestion has gone > completely unanswered.) > > >> Does it ever make sense to send a unBAR when the previous operation > >> was FOO, not BAR? Could you do with just one undo request for all > >> the un* cases? (If not, why?) > >> > >> What if a client undoes twice? N times? > >> > >> Add this to the above sequence: > >> 5. unminimize the window > >> > >> Is the window now in normal state or maximized state? > > > > Since this email, I have made it so you cannot toggle maximize while > > in a minimized state. This is the way xfce works and it's reasonably > > sane behavior. > > > >> > >> > >> I'm thinking this purely from the compositor point of view, and I > >> don't have any tangible suggestions here, but the above just > >> seems to generate more illegal than legal sequences, which also > >> means the code in the compositor must be checking for all the > >> illegal cases, and emit errors. The illegal sequences might not > >> make any sense to use, but the compositor (and the protocol spec) > >> must be aware of what happens when they are received. It might be > >> worth to actually draw (as on paper) the state machine with all the > >> requests you might get in each state. > >> > >> Is there any way this protocol could be designed in a way, that > >> illegal sequences would not exist, or at least would be in the > >> minority? > > > > I would like to dismiss the term 'illegal' here in it's entirety > > because it is biased by definition. I prefer 'possibly problematic'. > > When talking about a protocol "illegal" is a perfectly valid word. > Until we define how everything should work there's a significant > possibility for "illegal" interactions. > > >> As such, having only the set-requests without corresponding > >> un-requests would cut down the number of illegal (or just > >> unintuitive) sequences a lot. Adding a single undo request won't make > >> it much worse, the only suspicious case is undoing multiple times > >> in a row, I think. Adding corresponding un-request for each state > >> request leads to a minor combinatorial explosion of possible > >> sequences for which there is no obvious idea on what should happen. > > > > Yes, this is an orchestration between the clients and shell. It > > doesn't sound too complicated until you take a look at what's actually > > going on. I did not have time to draw a picture but mainly, you have > > to keep everyone in sync. And by everyone I mean: > > > > 1) The shell plugin > > 2) The wl_shell_surface clients > > 3) The xwayland clients > > 4) The desktop-shell client > > > > These all must be 'on board', for everything to go as intended. > > This is entirely an implementation detail of weston. It is completely > irrelevant to the current discussion. > > >> Btw. how do you intend to restore the stacking order on undo, in > >> practice, in the Weston implementation? It is possible other > >> windows have been deleted, created, and shuffled between set and > >> undo, so what will you use as the anchor to go back to? > > > > I am using gh next as a testbed to work out many of the details. > > > >> > >> > >> As for the whole idea of undoing stacking order changes; you seem > >> to assume that set_<state> requests will change the stacking order. > >> Is that right? > > > > The stacking order is (optionally) only changed when a state is restored. > > > >> > >> Or is that just a convenient workaround for the fact, that we do > >> not have protocol for explicitly controlling stacking order? So you > >> just add implicit stacking side-effects to unrelated requests? > > > > There's a lot of missing protocol, again, gh next is the testbed for > > the current implementation I have. > > > >> > >> If we had orthogonal requests for controlling stacking order, then > >> set_<state> requests would not need to touch stacking order at all. > >> Excluding stacking order, is there something else you would want to > >> undo, or would the whole undo thing become unneeded? > > > > I would like to think, that there are far and few between cases where > > we'd want such a behavior. Weston is reportedly a toy, not a real DE > > and I'm playing with it a bit. I'm not trying to enforce policy, I'm > > trying to open up the possibility of doing more interesting things. > > > >> > >> I would like to strongly suggest to consider splitting the protocol > >> into orthogonal concepts. That is what I did when I separated > >> clipping and scaling from the sub-surfaces protocol. It may seem > >> like more work to start with, but the end result will be cleaner, > >> more intuitive, and more versatile. It will also allow you to > >> reduce the interactions and implications, making designing the > >> protocol easier, and leading to a better end result. The short-term > >> downside is that you cannot take shortcuts in the design to have > >> a certain use case running sooner; you will have all use cases > >> running correctly later. As a compromise to allow development and > >> testing, your implementation can violate your own spec while > >> unreleased. > > > > I'm not sure what you mean by 'splitting the protocol into orthogonal > > concepts' here. > > By "splitting into orthogonal concepts" he means developing two > completely separate protocols: one for specifying stacking order, the > other for minimizing/maximizing. At the protocol level, they would > have basically no overlap. In particular, the min/max protocol should > specify NOTHING about stacking order other than, perhaps, fullscreen > is on top. > > >> Window state and stacking order often change hand-to-hand, but I > >> see no reason to tie them together on the protocol level. That is > >> why I would suggest to handle window state in one set of requests, > >> and stacking order in a another disjoint set of requests. Moving a > >> fullscreen window to the top could still be implemented by moving > >> it to the fullscreen layer in Weston, but that really is just an > >> implementation detail. From the client's point of view the > >> fullscreen window is simply "on top" at that time. > > > > The bottom line is, the four components I mentioned here, must work > > together and be 'on the same page' regarding semantics. Each component > > is responsible for it's own state tracking. I have found it is easier > > to track state when the calls are in consistent pairs. This also > > yields potentially more flexible control for the window manager (shell > > plugin). > > I don't see how this comment has anything to do with the interaction > between stacking and min/max. Also, it's mostly about implementation > details again. Jason, thanks for reading my mind and replying what I wanted to say, but was too tired. :-) - pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
