GNOME Display Settings Now Working On Wayland

[phoronix]

Phoronix: GNOME Display Settings Now Working On Wayland

In addition to the Hawaii Weston Shell update and better touch input support on Weston, there's some more good news for Wayland: the GNOME Display Settings is now working on Wayland via a new Dbus interface...

http://www.phoronix.com/vr.php?view=MTQzNTc

[TheBlackCat]

no, it's just an acceptance that after 20 years of massively incohrent desktops, and seeing them increasingly go their own way rather than even the very basic collaboration previously, things are only going to get worse. so why hopelessly compromise the design?

So the solution to "massively incohrent desktops" is to forcibly take away the last remaining bit of coherence?

you're assuming that this actually ends up supported with these clients. good luck with that.

They don't have to support it. That is the whole point. If the WM can make the decorations, they can implement those sorts of things without the application having to even know about them. But with CSD each application (or at least each toolkit) has to add support for those features independently, drastically limiting what the WM can do.

for the millionth time - it's not about the jagged line. i'm done.

You still haven't explained what it is about.

[daniels]

Your comment totally proves my point: You have no clue about usability.

right-o.

Instead of bringing the current paradigms closer together you basically say: ?Fuck mixed environments. I don't mix DigiKam with Gimp and you must neither and I don't care that Gnome does not allow for minimizing windows and Ubuntu's window controls are on the left when every other apps' buttons are on the right.?

no, it's just an acceptance that after 20 years of massively incohrent desktops, and seeing them increasingly go their own way rather than even the very basic collaboration previously, things are only going to get worse. so why hopelessly compromise the design?

SSD are the correct way for real-world scenarios. With CSD you can have your usability fuckup. I'm no one who wants to take configuration options away. As long as CSD are optional, I'm fine. I want to use Gimp 3 under PW2 and be able to minimize Gimp like I minimize Dolphin or pin a some window to be always visible or roll it up so only the title bar is visible.

you're assuming that this actually ends up supported with these clients. good luck with that.

No stupid jagged pixel line trumps that!

for the millionth time - it's not about the jagged line. i'm done.

[Awesomeness]

i don't want to live in a usability nightmare, which is why i don't mix and match random apps from ten different environments all together. the usability nightmare doesn't stop at window decorations: if all your menus, settings, shortcuts, VFS, print, etc is different ... what do window decorations actually buy you?

Your comment totally proves my point: You have no clue about usability.

Instead of bringing the current paradigms closer together you basically say: ?Fuck mixed environments. I don't mix DigiKam with Gimp and you must neither and I don't care that Gnome does not allow for minimizing windows and Ubuntu's window controls are on the left when every other apps' buttons are on the right.?

SSD are the correct way for real-world scenarios. With CSD you can have your usability fuckup. I'm no one who wants to take configuration options away. As long as CSD are optional, I'm fine. I want to use Gimp 3 under PW2 and be able to minimize Gimp like I minimize Dolphin or pin a some window to be always visible or roll it up so only the title bar is visible.
No stupid jagged pixel line trumps that!

[Vim_User]

As user of a tiling WM (read: no window decorations at all besides a 1 pixel border) for me the possibility to force applications to use SSD is not an option, it is a must.
Simple as that, window decorations have no use at all for me and applications that would display them nonetheless would be not welcome on my systems.

[daniels]

Thing is, you people worked for years only on back-end stuff. You seem to know nothing about usability of user-facing parts (as evident by Weston's crappy usability).

weston's not a real desktop environment. it's designed to test proofs of concept, not to be usable on a day-to-day basis with its default desktop shell. but thanks anyway.

At least in GTK and Qt CSD are optional. If you want to live in a usability nightmare, have fun there.

i don't want to live in a usability nightmare, which is why i don't mix and match random apps from ten different environments all together. the usability nightmare doesn't stop at window decorations: if all your menus, settings, shortcuts, VFS, print, etc is different ... what do window decorations actually buy you?

[erendorn]

Because you already need to put extra code related to decorations. You already do care about decorations when you choose to use CSD. The idea is to avoid this boilerplate when you don't. However, I already said it's not a big deal.

But the extra code is probably centered on the toolkit implementing decorations, and does not necessarily knows about what the shell provides for SSD. You cannot include in your app support for SSD you don't know about.

So, for seamless porting, it would indeed most likely be the other way: the shell/WM provides an API for windows decorations. If an application does not call this API, then it's a CSD only app.
If it does call the API, it a SSD capable app.
The API would include calls for the application to say if it is also CSD capable, and to return the WM policy (use SSD or CSD) if both are available.

[Maxjen]

I don't know what you call "default", but in my dictionary it's what happens when you don't say anything explicitly, so a default can't be "whatever the application wants". If the application doesn't states what it wants, THEN the default is applied.

I meant the default from the users perspective. If the user doesn't explicitly tell the application to use SSD the application should be allowed to use either CSD or SSD.

The default from the applications perspective can by definition only be SSD. And how SSD is being handled is the responsibility of the compositor. I heard that on plasma active for example SSD is equivalent to no decorations at all and on unity SSD would probably draw no decorations for maximized windows and standard decorations for everything else. On KDE or Gnome it would just be those standard decorations for everything.

If you allow the user to always override the behaviour of apps, then apps will have to code for both CSD and SSD anyway. Which is kind of silly, when you think about it. If the application doesn't have CSD coded in, forcing it to CSD would just create a window sans decorations. If the application doesn't have the SSD codepaths, forcing it to use SSD would create possibly undefined behaviour, or in the best case a window with empty titlebar and buttons that may or may not do anything.

That is not how the switch should work. There should be two cases:
1. The application is coded for SSD. => There is no switch
2. The application is coded for SSD and CSD. => There is a switch

Coding applications only for CSD is bad because
- desktops like plasma active or unity aren't possible
- consistency freaks can't always have consistent window decorations

There will probably still be these kinds of applications (think steam e.g.) but those wont work properly across all desktops.

[mrugiero]

Why does it make sense to add an extra function call to CSD-using apps, vs. using an already necessary function call in SSD-using apps?

Because you already need to put extra code related to decorations. You already do care about decorations when you choose to use CSD. The idea is to avoid this boilerplate when you don't. However, I already said it's not a big deal.

If you allow the user to always override the behaviour of apps, then apps will have to code for both CSD and SSD anyway. Which is kind of silly, when you think about it. If the application doesn't have CSD coded in, forcing it to CSD would just create a window sans decorations. If the application doesn't have the SSD codepaths, forcing it to use SSD would create possibly undefined behaviour, or in the best case a window with empty titlebar and buttons that may or may not do anything.

I see. Still, the switch on the functions is a good approach to avoid forcing developers for one or another.

[Teho]

sorry, but no. this argument has raged on for about five years now (hell, it's been going on this forum for about three), and every time people have indulged it and given the right reasons. i'm not going to prolong it, by rehashing exactly the same thing year on year.

Forums are pretty much unsearchable... you can't seriously expect people to have read any of the older topics. If you want to explain something once, write a blog post about it. That being said I have read pretty much everything I could find on Wayland during the past four years and I can't remember a single really strong argument for CSD. Then again I don't feel strongly about the subject either so I'm just curious.