On Wednesday 10 November 2010 09:21:24 Przemek Klosowski wrote: > On 11/09/2010 01:12 PM, Dennis Jacobfeuerborn wrote: > > X will run as a Wayland client. That means all applications that support > > X will be able to run remotely without change. Since QT and GTK both run > > on X and virtually all apps out there are programmed to use QT and/or > > GTK for most people nothing will change in the next couple of years. > > ... > > > Now let's assume Wayland is really successull. In that case people will > > want to get rid of X altogether and then you'd also lose the remote app > > support of X and in that case you obviously would need a replacement for > > this so apps can run remotely on an X-less Wayland desktop. > > The argument seems to be that toolkit libs like Qt and GTK+ will shield > us from major rewriting of apps. However, this implies that toolkits at > some point will switch from the X mode to Wayland mode, with the > resulting sudden loss of network transparency. This is precisely the situation we have when Qt/GTK+ programs are compiled for Windows: the programs work, they look right, but network transparency is lost. Of course, Windows was never really designed to support network transparency, so nobody is surprised by that. > I suppose one could imagine toolkits offering a dual backend: native > Wayland, and X that would be invoked by e..g. a commandline switch if > remoting was required. This seems a little heavyweight and awkward in > both deployment and maintenance. I do not think that a command line switch would even be necessary; the toolkit could just look for DISPLAY, and if that variable is set, it would automatically use X11. Of course, this means that we have to trust the toolkit developers to pay attention to both X11 and Wayland and provide equal levels of support for both, which is not something I really think would happen, at least not in the long run. -- Ben -- Message sent on: Wed Nov 10 10:24:25 EST 2010
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
