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.

CSD vs SSD

I have been reading and thinking about CSD vs SSD a long time and this is what I think:

CSD
+Flexibility
+Simplifies Wayland implementations
+Cleaner speration of conserns, a compositor shouldn't do any rendering of gui
-Can't impose graphical conformity regarding to decorations, the user experience can be confusing if every Application/toolkit chooses to go their own way
+Better model for a voluntary graphical conformity , a system "GUI theming and settings" system that is toolkit agnostic giving applications and toolkits information/hints how to render in a conforming manner

SSD
+Impose Conformity and make the user experience less confused and integrated
-Adds complexity for the Wayland implementation and do break separtion of conserns
-Harder to implement custom GUI design - for a minority applications and use cases the "GUI defaults" are not an optimal solution

I think KDE's decision to use SSD in KDE 5 may be the right and rational decision for them (and only for them). I don't know much about KDE but all software projects live with a legacy, as I understand KDE has always tried to achive a nice conformity in the user experience, even with "alien" toolkits like gtk+. For KDE to rewrite everything and change core principles in a short time span and such new and unknown technology as Wayland, would be impossible. Maybe in KDE 6 there are a time for such work.

CSD
+Simplifies Wayland implementations
+Cleaner speration of conserns, a compositor shouldn't do any rendering of gui
-Can't impose graphical conformity regarding to decorations, the user experience can be confusing if every Application/toolkit chooses to go their own way

+Better model for a voluntary graphical conformity , a system "GUI theming and settings" system that is toolkit agnostic giving applications and toolkits information/hints how to render in a conforming manner

You mean better potential model. This does not exist yet, and given the history with theming and HIG compatibility between toolkits almost certainly never will.

Originally Posted by Bulldog

SSD

No point repeating the stuff above.

But this all assumes that SSD or CSD is mandated, rather than something like we have now where SSD is the default but applications can choose to use CSD.

I thought window managers wouldn't be used with Wayland, that windows management was integrated with the compositor with the exception for compositor specific addons?

I never said it had to be a stand-alone window manager. A compositor that does window management is also, by definition, a window manager.

But this isn't really relevant to my post, which wasn't Wayland-specific but talking more generally about the relative benefits of the two approaches.

For the record, I don't think Wayland mandates that window management be handled by the compositor. The compositor could conceivably pass along window management-related information to another program which actually manages the windows. Whether that is a good approach or not is another question.

I have been reading and thinking about CSD vs SSD a long time and this is what I think:

CSD
+Flexibility
+Simplifies Wayland implementations
+Cleaner speration of conserns, a compositor shouldn't do any rendering of gui
-Can't impose graphical conformity regarding to decorations, the user experience can be confusing if every Application/toolkit chooses to go their own way
-Adds complexity to client programs
+Better model for a voluntary graphical conformity , a system "GUI theming and settings" system that is toolkit agnostic giving applications and toolkits information/hints how to render in a conforming manner

SSD
+Impose Conformity and make the user experience less confused and integrated
-Adds complexity for the Wayland implementation and do break separtion of conserns
-Harder to implement custom GUI design - for a minority applications and use cases the "GUI defaults" are not an optimal solution

I added a point, and made bold a phrase I see no reason for. A compositor shouldn't do any rendering of GUI? That's something to argue about. Should the app care about it? As I see it, the app cares about solving a problem, and this decorations just add boilerplate to solving it.
Anyway, my concerns could be fixed with the use of some decorations library, where you'd only have to call a function to draw a standard decoration if you don't have esoteric ones.