Client Side Decorations For Wayland

[damipereira]

Ok, on a more serious note, this has nothing to do with CSD or SSD. Clients can draw whatever they wish, just like Google Chrome does on Linux right now. CSD will change nothing in this regard.

Right now they CAN draw their own decorations, if csd is implemented they will have to. This will make harder to decide on window decorations, if the toolkits (gtk,qt,efl) start drawing the decorations, then they will have to decide on a common way of doing it, so that they get the images for drawing it from the same spot or something like that. So you clean some stuff but mess with the toolkits and/or the users.

Chromium right now has client side decorations, and behaves very bad in kde and gnome. if this get's common it will be a disaster, and implementing client side decoration as the standard way of windowing in wayland is pushing this misbehavior a lot further.

IMHO giving so much people (app developers) more control about what they can do with something which is supposed to be standard and common everywhere is a really bad idea.

PD: About the people who say it doesn't matter if the decorations are different, one of the main reasons I moved to linux was just that, all the windows looked the same, no stupid msn or antivirus window trying to re-invent everything.

[etnlWings]

I think it's a bit unfair to say that CSD is terrible because Windows made some boneheaded decisions when dealing with non-responsive apps.

It wasn't a serious attempt to poison the well; I was merely pointing out the irony.

Since Wayland apps will still require a client-side library, the library can have a tight contract with the server about behavior of the non-client areas. If the contract is broken, Wayland the server can quickly step in and provide a replacement experience for the user until the app is back on its feet or terminated.

We're still talking about a workaround for an issue that needn't exist, however. Granted, even with SSDs, the grace afforded apps could do to be tighter, requiring constant communication with the server.

IMHO giving so much people (app developers) more control about what they can do with something which is supposed to be standard and common everywhere is a really bad idea.

It's giving app devs more responsibility and taking control away from WM devs and users, also. We've already seen the creep of mediocrity with things like libwnk finding it's way into myriad WMs; no doubt a CSD Wayland world is going to look a whole lot like Metacity.

[kayosiii]

One of the biggest things I like about KDE is that I can have a button to keep the window on top. With CSD I only get that if the individual application implements that feature - sounds like a massive step backwards to me.

[?John?]

One of the biggest things I like about KDE is that I can have a button to keep the window on top. With CSD I only get that if the individual application implements that feature - sounds like a massive step backwards to me.

I'm using Compiz with Emerald and my window title bar looks like this:
icon, title, dynamic space, minimize, roll up/down, toggle always on top, toggle stickiness, maximize/restore, close.
It may seem like an overkill, but sometimes it's actually invaluable.

I also hate the idea of forcing people that often fail to get even the absolute basics right into position where they're much more likely to screw up, while giving up proven ways to save the day when the shit is about to hit the fan.

[etnlWings]

I use the sticky/above/shade buttons, also. It's one of the simplest and most user-visible ways to expose WM functionality and report the status of a window (being able to see which windows are stickied/pinned above without needing to interact with them). It's not even used to it's full potential now, when a WM can (easily) implement a button for just about anything WM-related in the titlebar. It's possible that a CSD spec could include support for expandable spaces to be filled-out by a WM, or other daemon but you're unlikely to see anything like that supported.

[movieman]

With CSD I only get that if the individual application implements that feature - sounds like a massive step backwards to me.

Wayland is a massive step backwards, so this shouldn't be surprising. Lately Linux developers seem to have decided that they want to reimplement Windows... badly.

[?John?]

It's possible that a CSD spec could include support for expandable spaces to be filled-out by a WM, or other daemon but you're unlikely to see anything like that supported.

I think that's the whole point of these "flames" - the whole concept seems to be lowering the bar too much and potentially putting users at risk introduced by incompetent/irresponsible "developers" with too much control/freedom.

Linux developers seem to have decided that they want to reimplement Windows... badly.

That's it, we're boned!

[yogi_berra]

Lately Linux developers seem to have decided that they want to reimplement Windows... badly.

As opposed to re-inventing UNIX, badly... http://www.amazon.com/UNIX-Haters-Ha.../dp/1568842031

[SunSet]

I think that's the whole point of these "flames" - the whole concept seems to be lowering the bar too much and potentially putting users at risk introduced by incompetent/irresponsible "developers" with too much control/freedom.


That's it, we're boned!

if this is true, how'd you change the issue?

[elanthis]

CSD has nothing to do with giving app developers more control. For fuck's sake, they can ALREADY use CSD if they want to on X11 today right now on your existing window manager! CSD is about solving real technical problems with the way that server-side decorations work that still today have no workable solution.

In practice, all apps will just use their toolkit's window borders and controls, which will be made to work with the desktop as shipped by the distribution. All KDE apps will use Qt and hence all have the same standard KDE controls that you'd expect, all GNOEM apps will use GTK+, and so on.

Apps like Chrome are _more likely to have standard window controls_ with CSD because now the toolkits can add first-class support for things like the tabs-on-top layout that Chrome popularized. That means that future Chrome versions can use an existing toolkit for its window borders and management without needing to lose its compact layout, and those toolkit-provided borders will retain the controls that all the other apps on your desktop has. This is better for consistency and user control, not worse.

p.s. Chrome allows you to turn off CSD if you don't like it for some reason. Contrast to many other Linux apps that don't give you such an option, today, on X11, with your existing window manager, because the app sets the necessary X11 properties to disable window controls and then draws their own. Think of XMMS2, or just about every other media player out there besides the ones that ship with KDE/GNOME.