Wayland Becomes A FreeDesktop.org Project

[nerdopolis]

There are many more Disadvantages of having the apps draw their own borders

http://blog.martin-graesslin.com/blo...w-decorations/


Have you ever opened up a maximized window in Windows, and then have it open up a progress window for a long operation, and then try to minimize or move the maximized window, only to have it throw a "ding" sound at you, and flash the titlebar of the progress window?

[loonyphoenix]

There are many more Disadvantages of having the apps draw their own borders

http://blog.martin-graesslin.com/blo...w-decorations/


Have you ever opened up a maximized window in Windows, and then have it open up a progress window for a long operation, and then try to minimize or move the maximized window, only to have it throw a "ding" sound at you, and flash the titlebar of the progress window?

There are several good arguments in the article, but the blogger is seriously exaggerating the problems. For example, non-consistency is already possible and an issue, as exemplified by Chromium. Whether client-side window decorations are implemented or not, it is already possible to use something application-specific. CSWD just makes it easier to make a good application-specific windows decoration, which you can't convince me is bad. I'm sure there will be a common window manager library; maybe there will be two, one for GTK and one for Qt, if the two don't agree on something. But GTK and Qt visual incompatibility is nothing new, and I don't see how common window decorations with different widget styles is any better than different windows decorations with different widget styles. There will be something like QtCurve, but for windows decorations, for those who want consistency.

Also, I can't see why CSWD can't be handled by an external windows decorator like Kwin or Mutter. I'm sure current X window managers can be altered to be usable by non-X programs, if there is a common API for using a window decorator. It's only apps which specifically want to render their own decorations which will have any of the problems described. So I don't think using client-side windows decorations will have any disadvantages; it will only offer more possibilities.

All of this depends on the way things are handled by GTK and Qt developers. I'm sure it's possible to make a mess of things; however, with some planning and collaboration between the two factions, a lot can be gained at minimal cost.

[V!NCENT]

Drawing their own window was understood by me like technically drawing their own window plus border and not like having UI circus like on MS Windows. I hate that.

[KellyClowers]

Still not impressed by Wayland. Even less so now that I realize that apps draw their own titlebars, etc. on it.

[drag]

Still not impressed by Wayland. Even less so now that I realize that apps draw their own titlebars, etc. on it.

really?

Like how in X apps draw the title bar?

How the weird do you think things work in X?

[drag]

Drawing their own window was understood by me like technically drawing their own window plus border and not like having UI circus like on MS Windows. I hate that.

Uh. they can do that in X if they want. Anyways your window manager is a X application and it draws the borders for everything.

I don't understand how people came to the bizzare conclusion that this is something new or undesirable.

[pingufunkybeat]

Having window management in a separate process is a FEATURE, and not a bug.

It's the best thing about X, period. I hate unminimiseable and uncloseable zombie windows on that other operating system.

Window management the X way comes at a cost, which is evident in issues such as rubber-banding when resizing, etc. But it's still very useful.

[loonyphoenix]

I hate unminimiseable and uncloseable zombie windows on that other operating system.

Oh, and having the whole UI freeze because of io activity is better? A non-responsive window which can be dealt with by killing the application that is responsible for it is the least of Linux's problems when it comes to dealing with hung apps.

I think Wayland can pull off an emergency process killer which would work under any conditions, even with peaked CPU and IO activity. Window managers are not an answer to the problem of unresponsive hung apps.

[nerdopolis]

loonyphoenix This is not just about hung apps, but this is also about apps that have unminimizable/unmovable windows just because of a modal window open.

And killing an app with an unresponsive GUI is not a good idea, it could still be working, but too busy to update its GUI (because its single threaded).

Window managers may not be the solution to hung apps, but that does not give them the excuse to create problems related to hung apps.

[loonyphoenix]

loonyphoenix This is not just about hung apps, but this is also about apps that have unminimizable/unmovable windows just because of a modal window open.

And killing an app with an unresponsive GUI is not a good idea, it could still be working, but too busy to update its GUI (because its single threaded).

Window managers may not be the solution to hung apps, but that does not give them the excuse to create problems related to hung apps.

I still don't think that would be a problem with Wayland. You might be right about all clients drawing decorations themselves, and windows managers might be very useful, but I think window managers can still be implemented in a Wayland environment. Why can't a separate window manager be just another Wayland client which draws decorations around the areas that all other clients request? That seems like the natural way a transition between X and Wayland might evolve. X apps will have fewer things to rewrite if the API of Wayland window managers stays compatible. The development of Wayland is pretty young, and I think the developers will come up with a working solution.