If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Despite being hosted on fdo, Wayland is mostly an Intel project. If Intel orders him to implement something else (or at least an alternative route), it'll happen.

It's funny... when Kristian worked at Red Hat one of the main criticisms of Wayland was that it was "mostly a Red Hat project" with all the same concerns...

Isn't the worst case (let's say Intel decides that Word Perfect on DOS had the ultimate UI and should be the foundation for all future Linux work) just that someone else would have to take over the heavy lifting on Wayland ?

Comment

You didn't answer the question. If applications can already disable WM decorations, then what's your problem?

Answer that please, instead of talking around it and trying to sneak out, Mr. Usability Authority.

Stop spreading lies. You asked ?Do you actually know that applications can bypass window manager decorations right now on X?? and I answered ?Yes.?
That's straight and forward and not sneaking out.

Later in the very same post I wrote: ?Once users get GNOME applications into their hand which they cannon minimize under other DEs (Plasma Desktop or whatever) because minimizing is not something that fits into GNOME Shell?s workflow, a shitstorm will break out.?
You wrote ?On Wayland, window decorations will be standardized by your DE. All KDE apps will still look the same. All Gnome apps will look the same.? The part of my post I just quoted points out the exact problem with 'KDE apps have their own window decorations and GNOME apps have their own window decorations.'
Are you incapable of understanding basic English? Seems that way. Learn English first before replying to any of my posts. It's not my job to explain everything twice for people with lacking English skills.

Comment

It's funny... when Kristian worked at Red Hat one of the main criticisms of Wayland was that it was "mostly a Red Hat project" with all the same concerns...

Nothing funny here because I never criticized it for being a Red Hat project just as I don't criticize it being an Intel project.
Talk to the people who were the 'Red Hat project' critics instead of replying to me.

Comment

Stop spreading lies. You asked ?Do you actually know that applications can bypass window manager decorations right now on X?? and I answered ?Yes.?
That's straight and forward and not sneaking out.

Later in the very same post I wrote: ?Once users get GNOME applications into their hand which they cannon minimize under other DEs (Plasma Desktop or whatever) because minimizing is not something that fits into GNOME Shell?s workflow, a shitstorm will break out.?
You wrote ?On Wayland, window decorations will be standardized by your DE. All KDE apps will still look the same. All Gnome apps will look the same.? The part of my post I just quoted points out the exact problem with 'KDE apps have their own window decorations and GNOME apps have their own window decorations.'
Are you incapable of understanding basic English? Seems that way. Learn English first before replying to any of my posts. It's not my job to explain everything twice for people with lacking English skills.

And *I'm* supposed to be the troll? Seriously? If you want to see trolling, just read your own posts.

And talking about English, you didn't even understand the issue. Nor the question. So, let me state it again, so that slower people (like you, apparently) can get it:

If it's already possible to bypass the WM without Wayland, then what's the problem with Wayland always allowing it?

If you're really *that* slow and still don't understand the question, then I apologize; I suppose my English skills are really that bad. You see, I learned the language myself. It wasn't taught in school, nor did I have any English lessons. I'm sorry that my English isn't up to your high standards. But I think people with at least half a brain should be able to understand me perfectly.

If it's already possible to bypass the WM without Wayland, then what's the problem with Wayland always allowing it?

You really don't get it, do you? Wayland is not allowing to bypass the WM for window decorations, Wayland is enforcing it. Under X11 an application has to explicitly override getting the window decoration used by the WM. Under Wayland applications have do it all by themselves. That means that even though one DE?s interface guidelines demand uniformity among them, and I repeat this the third time now, KDE applications will have one window decoration and GNOME applications will have their own and considering GNOME?s currently set work flow, all GNOME applications may not have a 'Minimize' button. Applications not belonging to either group, such as Firefox and Chrome (the latter doing it already by default but with an option to use WM decorations), will have to implement decorations completely on their own.
Behold the (possible) future of Linux applications: http://imageshack.us/f/145/31341369.png/ (Just an image I gimped up in a hurry.)
Yeah, after years of working on consistency (such as the fd.o icon naming convention which allows one icon theme to be used by both KDE and GTK applications) the element that was consistent even in the most inconsistent times of Unix GUI applications, the common window decoration by default for all apps is thrown out the window.
It'll be a usability mess if uphold and all because of some Inkscape users?

Comment

I will wade in here. One of the features I make great use of is the ability to add custom buttons to the window decoration of every application (in my case the stay on top button). Stay on top is an integral part of my workflow. If we go to having wholesale client side window decorations then I have to convince the maker of every application that I want a little button that lets me pin it to the top - this isn't going to happen and I will loose a valuable feature (well probably I will set a keyboard shortcut for it but I would prefer the button as it also gives a visual indicator). Presumably the toolkit could leave a blank space at the top of it's context window which the compositor/window manager could then composit on the window decorations. This would leave you with a single context, thus eliminating a lot of the problems that Window decorations currently have.

Comment

You really don't get it, do you? Wayland is not allowing to bypass the WM for window decorations, Wayland is enforcing it. Under X11 an application has to explicitly override getting the window decoration used by the WM. Under Wayland applications have do it all by themselves. That means that even though one DE?s interface guidelines demand uniformity among them, and I repeat this the third time now, KDE applications will have one window decoration and GNOME applications will have their own and considering GNOME?s currently set work flow, all GNOME applications may not have a 'Minimize' button. Applications not belonging to either group, such as Firefox and Chrome (the latter doing it already by default but with an option to use WM decorations), will have to implement decorations completely on their own.
Behold the (possible) future of Linux applications: http://imageshack.us/f/145/31341369.png/ (Just an image I gimped up in a hurry.)
Yeah, after years of working on consistency (such as the fd.o icon naming convention which allows one icon theme to be used by both KDE and GTK applications) the element that was consistent even in the most inconsistent times of Unix GUI applications, the common window decoration by default for all apps is thrown out the window.
It'll be a usability mess if uphold and all because of some Inkscape users?

There's nothing stopping standardization of window decorations by freedesktop.org. I really don't see the issue here. We already have stuff like dbus and libnotify. I can imagine a "libdecor" where the various DEs and/or GUI libraries can hook into. KWin on Wayland (or whatever the part of KDE that will be drawing the decorations will be called) will then work with that.

I do not think that users will notice much difference, as all that stuff will be handled under the hood.

Comment

There's nothing stopping standardization of window decorations by freedesktop.org. I really don't see the issue here. We already have stuff like dbus and libnotify. I can imagine a "libdecor" where the various DEs and/or GUI libraries can hook into. KWin on Wayland (or whatever the part of KDE that will be drawing the decorations will be called) will then work with that.

I do not think that users will notice much difference, as all that stuff will be handled under the hood.

So what is the advantage of this over server-side decorations, besides adding more complexity and yet another abstraction layer?

Comment

So what is the advantage of this over server-side decorations, besides adding more complexity and yet another abstraction layer?

There isn't more complexity. The logic of decoration would simply shift out of the window manager / composer into a library. There is no abstraction taking place.

The advantage is that there are no more synchronization issues between the app drawing its buffer, and the wm drawing the decorations.
When an app resizes, it is just a matter of rendering into a bigger buffer, and attaching it atomically. No inbetween states where the WM has already drawn
bigger decorations, but the app is lagging behind.

Comment

So what is the advantage of this over server-side decorations, besides adding more complexity and yet another abstraction layer?

There's an abstraction layer already in X11. The WM. In Wayland, there is no WM. So no abstraction is actually added. It will be a replacement for the current abstraction, not a new one.

The advantage is that applications have much more control over their decorations. Take Chrome and Firefox as an example; it's not possible in X11 to add tabs and other stylized elements to the title bar. With Wayland, it would be possible to keep the default decoration and add more stuff to it. If the various DEs agree to some common standard (I'm looking at freedesktop.org) of course.