Harald Braumann wrote: > > It is an application (or maybe toolkit) level problem: handle the > > event that the X display connection is being closed better than by > > killing the application and allow it to reconnect to a new display > > later (through some communication protocol). > > But couldn't it be done on Xlib level? Then it would work immediately > for all apps. On the Xlib-level some mapping would have to be done > (Atoms, XIDs, ...).
Even if you were to embed the guts of a proxy X server into Xlib, there would still be plenty of issues. In particular, it would need some degree of high-level knowledge (e.g. of properties) so that it knows when it needs to perform mapping. This would require ongoing maintenance as new properties come into use. It would also preclude applications communicating X-related information via "unofficial" channels. > And both servers would have to provide the same > extensions and visuals (at least those, that are used by the app). The > case when some of those are missing on the target server would still > have to be handled by the toolkit. > > Waiting for all the toolkits to implement X roaming (there's not only > GTK and Qt), will probably exceed the time the universe has left. Waiting for it to happen transparently will likely take longer, as it's a significantly harder task. Regardless of the level at which it occurs, you can't make the transfer entirely transparent unless the application is particularly simple. One of the biggest issues is the complexity and level of integration of desktop environments. Toolkits are no longer just about displaying windows. There's also integration with a whole range of services provided by the desktop environment. If you move between displays, any other clients which were on the previous display will simply vanish. Even if identical programs are running on the new display, it isn't likely to be feasible (especially at the protocol or Xlib levels) to simply establish new connections and pretend that nothing has changed. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
