Page 5 of 11 FirstFirst ... 34567 ... LastLast
Results 41 to 50 of 106

Thread: GNOME Display Settings Now Working On Wayland

  1. #41
    Join Date
    Feb 2011
    Posts
    1,068

    Default

    Quote Originally Posted by Honton View Post
    They want SSD because they don't trust the app developers.
    A blatant lie. That is only one of a number of reasons. There are a bunch of technical reasons they support SSD over CSD.

    Quote Originally Posted by Honton View Post
    And I can't blame them when it comes to KDE. Sure KDE would screw up and add inconsistent theming and various fluffy themes. But you can't blame CSD, blame the bad culture of KDE.
    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.

    This also explains why Gnome has been okay with CSD. Qt (and thus KDE) apps have supported GTK theming and HIGs for a long time now. So Gnome doesn't have to worry about KDE apps suddenly breaking established workflows, they know KDE devs will bend over backwards to maintain consistency as they always have.

    Quote Originally Posted by Honton View Post
    Enforce HIGs, themes, designs etc and you are good.
    Impossible to do when an entire toolkit, with a huge number of apps, simply ignores them.

  2. #42
    Join Date
    Dec 2011
    Posts
    2,008

    Default

    Quote 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.

  3. #43
    Join Date
    Aug 2011
    Posts
    70

    Default

    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 at 09:05 AM.

  4. #44
    Join Date
    Feb 2011
    Posts
    1,068

    Default

    Quote 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.

  5. #45
    Join Date
    Aug 2011
    Posts
    70

    Default

    Quote 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.

  6. #46
    Join Date
    Dec 2010
    Posts
    1,111

    Default

    Quote 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.

  7. #47
    Join Date
    Oct 2010
    Posts
    417

    Default

    Quote 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.
    Quote 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).

  8. #48
    Join Date
    Jul 2013
    Posts
    348

    Default

    Quote 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...

  9. #49
    Join Date
    Dec 2010
    Posts
    1,111

    Default

    Quote 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.

  10. #50
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •