William Swanson wrote:
On Fri, Sep 14, 2012 at 12:01 PM, Bill Spitzak <spit...@gmail.com> wrote:
Both Linux and windows support text files that say something like this (we
wrote the code that reads/writes these files):
window_position: 10,30,400,500
Your example is already deeply broken, since it doesn't consider
things like the current virtual desktop, the minimization/maximization
state, z-order, zoom level, rotation, 3D positioning, window roll-up
or a host of other issues that may or may not be relevant depending on
the current window manager / compositor.
Actually it does save the fullscreen/maximized/iconized state, that was
a simplified example. It does not save the Z because X does not support
setting that (and users expect the new windows on top). And it does not
store the virtual desktop because of a combination of non-use by our
users and I also think they expect new windows to appear on the current
desktop always.
When you really step back and think about it, why duplicate the same
position-saving code again and every app? Why not let the compositor
handle this? After all, the compositor is the one program that is
actually knows what's relevant and what is not.
The main problem is that this text is saved in a file along with a huge
amount of very app-specific code. So the api that is really needed is to
return a string that we can write ourselves to a file, and another api
to interpret this string. The problem here is you cannot stop apps from
parsing this string to extract info they want, and thus you may end up
with an undocumented x/y position api that you have to support.
Another big concern is that complex popup menu systems rely on accurate
positioning of the menu windows and knowledge of the obscured area. This
sounds like the reason xserver needs this information. A common example
is hierarchial popup menus where the submenu may popup to the left,
along with different graphics in the parent menu, if the normal location
to the right is obscured. It is also needed to correctly support
floating toolbox windows and dialogs (these are broken in X/Windows but
it is a huge hope Wayland will fix this by removing click-to-raise).
The current wayland api to automatically move windows into the
unobscured area is not usable for this. I don't see any way to do this
unless subwindows at least have accurate x/y positions or transforms
relative to the parent. It then makes sense to have a transform for the
parent so the api is consistent. I can also imagine a rather painful
amount of rewrite if the obscured region is per-window rather than a
global region with the windows positioned in it.
Apps also want to draw pictures of the monitor layout and thus need the
xy position of monitors.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
