On Tue, 11 Jun 2013 16:31:59 -0300 Rafael Antognolli <[email protected]> wrote:
> Starting code here. Following are some comments. > > https://github.com/antognolli/wayland/commits/minimize > https://github.com/antognolli/weston/commits/minimize > > I didn't add code for the events that ask state changes from the > compositor, neither any code related to minimize yet. I tried to first > change the current maximized surface type to be just another state, as > suggested at some point in this thread. > > So, it ended up very hackish IMHO. In order to do that, when the > surface type is set to maximized, I change it to set the maximized > state instead, which is currently working correctly (from my tests). > But when the surface type is set to anything else than maximized, I > have to unset the maximized state, to keep the same behavior as before > these changes. > > I need to know if I should follow this path, in which case I'll > improve the above code (some refactory can take place), or if we > should use another approach. Maybe the minimized state should be in > fact another surface type, and we would only have states for things > like always_on_top and sticky (and any other that may come next). Or > maybe we can keep the same surface types that we had already, and just > add minimized as a state. > > What are your opinions about this? To get the big picture, let me reiterate the surface classification as a whole, the way I see it. Surface roles, exclusive: - cursor - drag icon - shell surface Shell surface types, exclusive: - top-level - transient (umm, what was this for, again?) - popup (menu?) Top-level shell surface states, each more or less toggleable on its own: - maximized - fullscreen - minimized - sticky - always-on-top or some equivalent layer thing ... Does this make sense? That is, only a top-level surface, which we should probably be calling as an application window, can be maximized etc., and I think the discussion was that it can be many things at once, like maximized and minimized. I don't think the states make sense as types, I would prefer the above hierarchy. A shell surface can only have one type at a time, but the states are not that restricted. It gives a nice tree-like hierarchy, instead of a directed graph where several surface types can have the same states. The tiling-WM developers would be concerned only about the top-level shell surface states, and could hopefully support all the shell surface types, which should make the difference between floating and tiling WMs more manageable. Protocol-wise, this means that requests set_maximized and set_fullscreen would be deprecated as is, and replaced with the state setting request. Request set_toplevel would deprecate the part of its behaviour where it changes a surface into normal state. We cannot remove the deprecated functionality, I believe, so it must be kept working, and just plumbed into the new kind of internal state change machinery inside weston. However, it's not that simple. Some states need parameters. Maximized needs an output, and fullscreen a few things more. Always-on-top equivalent might want a layer number or something. Therefore I'm not sure a single set_state request will work. Anyway, that's just what came to my mind now. I don't recall any of the earlier discussions anymore, maybe there were solutions to some of these issues, maybe not. Did we ever discuss the possiblity of fullscreen being a special kind of maximized, btw? If you look at the state list above, everything is orthogonal (toggleable independently) except maximized vs. fullscreen. This is just as a concept, how it maps into protocol is a different matter. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
