Reply With QuoteKWin is an X window manager. Of course it does all sorts of things highly tied to the X Window System.
KWin does use Qt, but it's not ALL it uses.
Senior Member
doesn't porting a toolkit to wayland automaticaly means that the apps using it can run on it???Originally Posted by Elv13
ie KWin is written in Qt (as i read in wikipedia) and qt is being ported to wayland as we speak
Senior Member
KWin is an X window manager. Of course it does all sorts of things highly tied to the X Window System.
KWin does use Qt, but it's not ALL it uses.
Phoronix Member
So if wayland is a compositor then does that mean it will have problems with running compiz? (thinking that it would be hard to port gnome 3 and the like)
Senior Member
Wayland is realy starting to take off
If it could have a remote desktop X11 replacement extention then that would be great!
Senior Member
can somebody explain the situation with the window managers compositors etc on Wayland??
things like Kwin Metacity/Mutter Enlightenment Compiz just have to slightly modify the code to target wayland right??
Phoronix Member
Wayland doesn't use something called "window manager". With X11, apps only draw contents of windows, and frame + title bar is drawn by window manager. With Wayland, like e.g. MS Windows, apps draw not only contents, but also the title bar, etc. This is why screenshots of gtk+/qt on Wayland show windows without title bar (it's simply not drawn at all by these toolkits on X11).
But about *compositing* managers... I'm not that much into Wayland
Junior Member
I wonder where you got that from (maybe this aprils fools joke?).
KWin is a X window manager with optional compositing support, nothing else. Thus it heavily depends on X technology.
Qt has its own form of window management built in, which wayland is being ported to.
Some details about it here. I wonder how this will work/look in the end...
Junior Member
nope.
see my above post. I don't know exactly, but I guess that the same is true for other X window managers as well. They all implement something that is very specific to X and it wouldn't make any sense to "port" them (read http://en.wikipedia.org/wiki/X_window_manager for example).
Senior Member
What are the benifits of apps drawing their own borders compared to sync fences?
Phoronix Member
The apps can have application-specific borders, like Chromium has. You could also do a lot of other creative stuff like merging and dividing windows, or making shaped, round/octogonal/etc windows, not only rectangular. Imagine a music player which has a playlist part, an equalizer part and a main control part. They are oval, but if you put them close together, they merge (using a pretty animation) to become one in whatever order and at whatever side you like.
The current X window manager paradigm doesn't offer the flexibility to do a lot of stuff. Look, for example, at Audacious. it can do some of the above, through native X features and assorted hacks, but it has some limitations. If you attach component windows together, you can still drag the whole composition around only by dragging the main window. You cannot merge them together so that it is essentially one window; it is visually obvious that it is several different windows stuck together. Also, dragging it around can produce visual glitches; for example, if you drag the Audacious window near a panel, it will try to stick to it, but the sticking effect only works with the main window, the rest seems to be dragged individually, unsticking them from the main window.
Just several thoughts.
