Ubuntu moving towards Wayland
bdwheele at indiana.edu
Tue Nov 9 18:44:19 UTC 2010
On Tue, 2010-11-09 at 19:12 +0100, Dennis Jacobfeuerborn wrote:
> On 11/09/2010 06:12 PM, Gregory Maxwell wrote:
> > On Tue, Nov 9, 2010 at 11:55 AM, Adam Jackson<ajax at redhat.com> wrote:
> >> On Tue, 2010-11-09 at 04:05 -0500, Jon Masters wrote:
> >>> +1 for bringing these points up. No offense to krh (because it's nice
> >>> technology) but you can pull my genuine networked applications from my
> >>> cold dead hands. I agree that I see this ongoing trend to move toward
> >>> things that are fluffy and pretty at the cost of flexibility.
> >> No. You see the system you know and understand being replaced by one
> >> you don't. You have an emotional attachment to the old system because
> >> it gives you a feature you like and the dozens of problems with it
> >> aren't important to you. And you claim that the replacement is less
> >> flexible because you don't understand or don't want to learn the new
> >> thing.
> > I've mostly been watching here and I think people have been fairly
> > clearly about their concerns: Network transparency is important to
> > them, and they understand that the wayland message is that it will not
> > be supported. This message has been clear enough to me here and
> > elsewhere— with people arguing things like applications which need
> > network transparency are all now web based.
> You are mis-interpreting the message probably because you are not a
> developer and as a result don't know how software is designed in layers.
> Wayland handles the visual aspects of the desktop. Networking doesn't
> belong there. A remote app layer will sit on top of Wayland and deal with
> the communication between both ends.
And where does that sit in the architecture?
Looking over the architecture page (2nd figure) it looks like the only
way to get the kind of network transparency that X has under Wayland is
to put the network between the Wayland client and Wayland Compositor.
Which would mean that the passing of events has to be networkable from
the start. If its put on top it ends up being the VNC model of doing
things and that sucks in a big way.
Answering that you can still use X on top of Wayland doesn't do
anything: it is the native Wayland clients that are the issue. If they
are not network transparent then it cannot be a suitable replacement for
X because native clients _will_ appear and we end up with the situation
of OSX and Windows where some clients are more equal than others.
> > [snip]
> >> Remoting a wayland application is _trivial_. Either to an X or to a
> >> wayland view system. It's hard to make wayland remoting less flexible
> >> than X over the network, since the natural remoting level (surface
> >> updates) is basically stateless unlike X's sixteen complete IPC
> >> interfaces, and unlike X you're actually guaranteed that the window
> >> surfaces exist and have meaningful content. So you get the
> >> long-lusted-for "screen for X" almost for free.
> > One message ago you were saying that the network transparency concern
> > was a non-issue because GTK/QT apps would support both wayland and X.
> > Here you're saying that wayland will have network transparency?
> > I'm rather confused. Can you help me understand? So long as
> > integrated network transparency doesn't get any worse I don't think
> > that anyone raising concerns would have an issue.
> 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.
Are the native wayland clients network transparent? If they are not,
then it isn't a suitable replacement for X for my usage (or my 2 dozen
users) and it means that either the native wayland clients or X clients
will be second class citizens as time goes on.
> That's why it's so hard to understand why people are already bringing out
> their torches and pitchforks over this.
> 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.
Which should be considered now. VNC screen scraping sucks. If the
native clients cannot be networked from the beginning, then they will
never be able to be networked in a suitable fashon. Its not something
you can bolt on later "if [it] is really successful"
I like the concept of the project and I like the energy, but the bottom
line is: if you want to make a replacement for X it needs to offer at
least the same feature set. That includes network transparency.
More information about the devel