Announcement

Collapse
No announcement yet.

GNOME Display Settings Now Working On Wayland

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Bulldog
    replied
    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.
    Last edited by Bulldog; 08-16-2013, 03:51 AM. Reason: typo

    Leave a comment:


  • mrugiero
    replied
    Originally posted by Honton View Post
    It is about not becoming constrained by the WM. And you porved my point perfectly by listing the limitations of todays WMs. What if I want more? What if I want to have a progress bar in my title bar?
    The "old" model (SSD) doesn't stop you from making feature rich apps, since your example is currently done in most cases inside the window. At most, it stops you from making such features more screen space efficient.

    CSD is like prometheus' fire, yes. We can make good or bad of it. The nice part is we decide. Respecting HIGs, Theming and design guidelines are a good way to do it, Gnome proved this. KDE could do this too, it is really not that hard. Or are you saying that app developers shouldn't have the right to decide and features must be done away with? That is sweet irony, I think. Gnome wants flexibility and features, KDE wants to be locked down.

    Qt's "write once, deploy everywhere" should not be allowed to stop us from making the best possible Linux desktop AND reducing complexity. KDE can find other ways to make the same code behave differently.
    Read again what you quoted, please, and then point out where did I say devs shouldn't have the right to decide features. I clearly stated it's good to have it as an option (for example, if I understood correctly, Qt handles it with a switch to enable CSD on your app). Forcing CSD means you have no decoration by default, and your example is a corner case, and someone actually taking the time to design something as superfluous (on most cases) as the decorations is not really common, and something most try to avoid.

    Also, you seem to assume I am pro KDE, while I actually dislike it, and use XFCE instead.

    Leave a comment:


  • Awesomeness
    replied
    Originally posted by TheBlackCat View Post
    The indicator spec would have supported this in a consistent manner, but we all know what happened there.
    I'm not entirely sure but I think the plan for KWin 5 is that applications will be able to define titlebar elements and tell KWin's SSD via dbus about it.

    Leave a comment:


  • Daktyl198
    replied
    Originally posted by Honton View Post
    Are you saying the apps should decide where and when to omit decorations? Works for CSD.
    No offense, but you're an idiot.

    He is saying that the USER should be able to switch between CSD and SSD for each application individually.
    The app would start off as CSD, and if the user didn't like it they could flag it to use SSD instead.
    Those apps that don't use CSD would be flagged for SSD automatically.

    This allows the developers to take advantage of CSD, while allowing the user to give themselves a more consistent look if they desire.

    On another note:
    Why is it that every post about Gnome or KDE ends up being a:
    "You're f***ing wrong, Gnome is da best." <Gnome fans
    "Nu-uh, KDE is better!!" <KDE fans
    instead of a:
    "Hurray for Gnome!" <Gnome fans
    "Congrats on the Gnome team" <KDE fans.

    Criticism is fine, but outright attacking people because they like something you don't is pure idiocy. Every innovation for each team drives Linux further and _HONESTLY_ each team could learn a lot from the other.

    /me waits for the predicted response of anger and rage at the mention of the two teams learning from each other...

    Leave a comment:


  • Nobu
    replied
    Originally posted by Maxjen View Post
    There would only have to be a simple flag to tell the applications to draw the decorations themselves or not. And depending on this flag firefox for example would have to make a little bit extra space and put the tabs there. Doesn't sound that complex to me.

    On the other hand it would massively simplify things and improve consistency for applications that don't want to draw the decorations themselves like most games.
    Originally posted by Honton
    Are you saying the apps should decide where and when to omit decorations? Works for CSD.
    Most apps don't draw their decorations themselves anyway--the toolkit does. The exceptions (Firefox, Chrome, etc.) have to deal with this already, it's just simpler with wayland (because the method of handling this is defined, you just need to hook into the right functions).

    Leave a comment:


  • Awesomeness
    replied
    Originally posted by uid313 View Post
    Maybe Qt or KDE developers should commit some patches to GTK to respect Qt (and thus KDE) stuff.
    That was already attempted back in 2006 when Qt3 was still the current release. The work was rejected by Gnome.
    Actually there were two projects attempting to do that kind of integration work: A theme engine for GTK (GTK-Qt-Engine) for theme compatibility and KGtk for KDE Open/Save windows in GTK applications.

    Later the opposite direction was done: Gnome support was implemented directly in Qt because the Qt camp is not afraid of other projects.

    Leave a comment:


  • Maxjen
    replied
    Originally posted by Honton View Post
    So instead of fixing the apps, the protocol should be more complex and error prone?
    There would only have to be a simple flag to tell the applications to draw the decorations themselves or not. And depending on this flag firefox for example would have to make a little bit extra space and put the tabs there. Doesn't sound that complex to me.

    On the other hand it would massively simplify things and improve consistency for applications that don't want to draw the decorations themselves like most games.

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by Honton View Post
    So instead of fixing the apps, the protocol should be more complex and error prone?
    Yeah, let's limit window manager to only those features supported by all apps, rather than letting them add features themselves and have them automatically applied to all apps. Great way to drive innovation there.

    Leave a comment:


  • Maxjen
    replied
    CSD is great if done properly. For example firefox on windows with the tabs in the decoration looks much neater than on linux. But if implemented poorly I would like to have the option to tell the application "no, this sucks, please use server side decorations". Also if someone wanted to do something like unity where you merge the decoration with the panel for fullscreen windows you would probably need this. And it would be nice if games in window mode that don't use toolkits like Qt or Gtk could rely on server side decorations instead of implementing their own decorations.(which would obviously look inconsistent)

    For these reasons I think SSD should be supported as a fallback and applications should have to choose between
    - drawing no decorations at all and rely on server side decorations
    - or use client side decorations but only if the system allows them to and provide a fallback case if it doesn't

    In the end a lot of people would probably use client side decorations for applications that are native on their desktop environment and server side decorations for everything else.

    EDIT: Mostly unrelated, but I also think it is important that the shadows are not part of the decoration, because otherwise different applications would have different shadows and if you for example rotate windows the shadow would rotate with them and it would look stupid.(like when you rotate the wayland terminal) So hopefully the compositors will be drawing the shadows.
    Last edited by Maxjen; 08-15-2013, 09:05 AM.

    Leave a comment:


  • uid313
    replied
    Originally posted by TheBlackCat View Post
    Quite ironic when the biggest problem KDE has to deal with in this area is GTK refusing to respect Qt (and thus KDE) themes and HIGs. CSD won't change that, it will only make it worse. Given this history, GTK almost certainly also won't respect Qt (and thus KDE) decoration buttons and button locations, not to mention decoration menus, necessary to properly interact with Kwin and Plasma features.

    The group Kwin developers have the most to fear isn't other KDE developers, KDE apps do and always will play well with Kwin. It isn't even individual apps that change everything like Chrome. What they, and every KDE user, has the most to fear is the numerous GTK apps that up to this point have been able to work reasonably well with Kwin and Plasma features, but with CSD decorations would suddenly break KDE users' long-established workflow.
    Maybe Qt or KDE developers should commit some patches to GTK to respect Qt (and thus KDE) stuff.

    Leave a comment:

Working...
X