Announcement

Collapse
No announcement yet.

Dual X Servers Running Side-By-Side With Wayland

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by drag View Post
    The only thing I don't like about Wayland is the "oh we'll support X through composited interface, but toolkits like GTK can be ported to support it natively".
    GTK already supports 5 or 6 backends. It's intended to be portable. Same with any other toolkit. Wayland won't require any extra layers at all. If anything, Wayland essentially removes from the graphics stack the layers that exist within X today.

    If -- and that's a big "if" -- Wayland's model is determined to truly be the successor to X, then it's really just a matter of adding a new backend to a toolkit that already has half a dozen.

    If GTK was to get popular on Wayland then that means that unless new features are supported both in X and in Wayland then that means that GTK won't be able to benefit easily from improvements in either one.
    See, though, the entire reason Wayland works the way it does is because real applications don't need additional features in EITHER backend. The future that we're approaching is one in which all rendering is done via OpenGL (usually through a higher-level toolkit/library interface), in which X subwindows are unused, in which DBUS facilitates all high-level desktop app communication, and in which all X really does is provide the basic window stacking/management features on top of the in-kernel or library-ified graphics and input components. That's why Wayland is so simple. Nobody really needs the features the Wayland design lacks. All modern applications need from the windowing system are windows, direct rendering, compositing, input, and a few other basics.

    Almost all interesting features -- including allowing apps to move between X servers like you just asked for, as well as networking -- are really toolkit problems and library problems. A modern toolkit's abstraction layer needs very little outside of a way of getting hold of an OpenGL context, getting input events, and low-level stuff like threading and I/O and basic audio. Current toolkits have bigger abstraction layers mostly just because they were designed in the day and age when the X drawing API or Windows' GDI API were actually considered useful.

    Comment

    Working...
    X