spitzak at gmail.com
Wed Sep 14 10:48:25 PDT 2011
dottomi at gmail.com wrote:
> Excuse me, I'm just a bystander, but is this list you speak of a list of
> all the windows registered by all of the connected clients?
> The main problem I have using GIMP is that when I focus a window, I
> don't want to focus on a /window/, I want to focus on an /application/.
> This means I want all of the application's windows to be moved to the
In my proposal this is done by the client (GIMP) raising all the windows
in response to the compositor telling it to raise one of them. The
compositor does not need to know anything about the fact that the
windows are related.
There are also "invisible" windows. Their only purpose is to provide
entries in a task-manager or panel type application. Attempts to raise
these are also handled by the client. For the GIMP there may be a single
"gimp" icon in the task manager. The fact that it raises all the image
and toolbar windows is only known by GIMP.
If there is a list with only the windows, it would require to move
> all of the windows one by one. You can also have a third-party window
> between your application's windows, and I think that's the part that
> should be avoided.
>> 2. There is a *atomic* api by which a client can map, unmap, and
>> change the stacking order of it's own windows.
> "Of it's own windows" in an absolute list, or in a client-only list?
It's own windows in an absolute list. This would be done by requesting
that window a (belonging to the client) be placed above/below window b
(which can be None or a client or other window). None is the most
useful. Compositors could also provide place-holder invisible windows so
a client can indicate what "layer" a window is in (compositors can also
force windows to be in "layers" by not obeying the window stacking order).
> Personally, I'd want to have a client request for a "single window
> object", and for a "window group object". In the server there would be a
> single list containing both single window objects and window group
> objects. A window group is an object which is managed by the client
> (map, unmap, register, unregister, reordering - i.e. what you're talking
> about here) and the client can only operate on windows in its own group
The "window group" is what I was calling the invisible windows for the
task managers. However the compositor does not have to know anything
about the group, the client is supposed to respond to requests to raise
the group by raising all the necessary windows.
> It makes things easier in the server to restack windows because
> you can move a whole group at once in the server-side list and you avoid
> having a client's window positioned between windows of another client,
> where the latter client does not want any third-party windows between.
> It also makes it impossible for a client to make changes to the absolute
> server-side list.
There will be a need to make a whole group of reorders "atomic". This
will make it look to the user as though the whole group raised at once,
and prevent other applications from inserting their windows between
them. Also this is vital so that a video player can use a low-res YUV
window below a higher-res "frame" with a transparent area, and the user
never sees them come apart.
More information about the wayland-devel