I think the original poster's idea is exactly what is needed:
I the compositor crashes or exits, the clients will detect this. It is
then the client's job to find a new compositor and recreate their
state on the new one. Most toolkits store quite enough redundant
information that they should be able to do this, I would suspect the
biggest trick will be to completely forget any ids from the previous
compositor.
The way the client will detect when the new compositor is available is
by following exactly the same rules they use when the first start up
to locate the compositor. If for instance when a client starts it
attempts to open a named pipe, this is exactly what it will do after
the previous compositor exits. If it fails to open it probably should
try repeatedly with a timeout between each try, and only exit with an
error after a very long time (30 seconds or so). This will give time
for the compositor to restart, and would also solve the current
problem where you can't launch a compositor and a bunch of clients
simultaneously.
Besides handling crashing, this should also be the way to switch
compositors. A compositor could actually force a client to a different
compositor by first modifying the client's environment in whatever way
is needed so it will connect to the new one, then closing the
connection.
On Mar 6, 2011, at 10:04 AM, Marty Jack wrote:
On 03/06/2011 12:41 PM, nerdopolis wrote:
Hi.
I just want to bring this up for early consideration:
It seems that many things in Wayland will be determined by they
type of compositor server you are running, such as if you want to
have a tiling window manager in Wayland, or one that has other
features.
My question is that will users be able to have the ability to
change their Wayland servers on the fly? not only would such a
thing allow the users to change functionality, but it will also
help in the case if the Wayland server goes down, where the session
is not lost.
Will this have to happen in the apps themselves? If so, how would
the apps "know" that the socket (or maybe even a new socket) is
available for reconnect?
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
An interesting point. A parallel to <window-manager> --replace, and
probably something that users would want to do while they are
experimenting with different looks.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel