Announcement

Collapse
No announcement yet.

GNOME Display Settings Now Working On Wayland

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

  • #46
    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.

    Comment


    • #47
      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).

      Comment


      • #48
        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...

        Comment


        • #49
          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.

          Comment


          • #50
            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.

            Comment


            • #51
              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

              Comment


              • #52
                Originally posted by Bulldog View Post
                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
                - Additional work for application developers who don't need the flexibility
                - Can't impose HIG conformity
                - Makes handling of application freezes and hangups much more difficult
                - Makes handling different system form-factors more complex for applications
                + Simplifies some graphical effects like window distortion
                + (or - depending on your perspective) Simplifies weird-shaped windows like ovals

                Originally posted by Bulldog View Post
                +Flexibility
                + Increased flexibility for applications
                - Decreased flexibility for window managers

                Originally posted by Bulldog View Post
                +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 View Post
                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.

                Comment


                • #53
                  Originally posted by TheBlackCat View Post
                  - Decreased flexibility for window managers
                  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?

                  Comment


                  • #54
                    Originally posted by Bulldog View Post
                    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.
                    Last edited by TheBlackCat; 08-16-2013, 08:29 AM.

                    Comment


                    • #55
                      Originally posted by Bulldog View Post
                      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.

                      Comment


                      • #56
                        Originally posted by Maxjen View Post
                        For example firefox on windows with the tabs in the decoration looks much neater than on linux.
                        Tabs in the decoration always look like dog vomit, regardless of CSD or SSD

                        Comment


                        • #57
                          Originally posted by KellyClowers View Post
                          Tabs in the decoration always look like dog vomit, regardless of CSD or SSD
                          What ? This is one of the best features of modern browsers. Tastes & colors...

                          Comment


                          • #58
                            Originally posted by doom_Oo7 View Post
                            What ? This is one of the best features of modern browsers. Tastes & colors...
                            It's still a corner case. It's great on Firefox and Chrome and such, but mostly useless (or at least something most will not take advantage from) on most cases, and extra work if CSD is mandated.

                            Comment


                            • #59
                              Originally posted by doom_Oo7 View Post
                              What ? This is one of the best features of modern browsers. Tastes & colors...
                              If by best, you mean worst, sure.

                              Comment


                              • #60
                                its funny way more then just the GNOME display settings are working on Wayland 97% of the main Gnome Apps work on Wayland

                                Comment

                                Working...
                                X