On Wed, 20 Mar 2013 22:06:22 -0600 Scott Moreau <ore...@gmail.com> wrote:
> Hi Jason, > > On Wed, Mar 20, 2013 at 7:56 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote: > > > > There is one more question that I think needs to be answered. And > > that is: do we handle things in terms of set/unset or in terms of > > set_maximized, set_fullscreen, set_minimized, and set_normal (probably > > want a better name for that one). Really, which of those two we do > > doesn't matter that much because the toolkit can force it either way. > > It's mostly a matter of who tracks the state and handles it. I think > > I like simply setting the state instead of keeping track of set/unset > > better, but I'm open to discussion on that. > > I have this all working in gh next. The only thing left to consider > that I can think of is: Do we want to support 'unmaximizing or > unminimizing (or unfullscreening) a surface retains stacking state'. > So basically if there is a bottom-level surface and you state change > it then toggle it back, do we always want it on top no matter what? Or > do we want to optionally support retaining stacking order on state > restore (setting back to 'normal'). If we want to support this > feature, then a new un* request is required for each state set > request. I move that we do support this feature and I'm working on > this in gh next. 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? 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? 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? 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? 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. 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? 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? 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? 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 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. 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. Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel