Announcement

Collapse
No announcement yet.

Xfce 4.16 Is Making Good Progress On Utilizing GTK3 Client-Side Decorations

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

  • #31
    Originally posted by raster View Post

    Actually CSD is more efficient overall. It allows solving of some problems that are difficult or unsolvable with SSD, and what it REALLY is is having the toolkit handle decoration on the client side, so it doesn't mean "every app is custom".
    It also introduces a pile more unsolvable problems, such as making it impossible to do window tabs (multiple applications sharing one titlebar) without wasting even more space.

    Comment


    • #32
      Originally posted by archsway View Post

      It also introduces a pile more unsolvable problems, such as making it impossible to do window tabs (multiple applications sharing one titlebar) without wasting even more space.
      Congratulations. you found one thing it's not good at. There is thus a protocol that exists to request the client not decorate in Wayland (not universally supported yet - but it's necessary for things like tiling WMs to look nice, so eventually will be).

      You may have missed the bit where I was doing an overall evaluation from all the angles... But hey... everyone has their ax to grind.

      Comment


      • #33
        Originally posted by Britoid View Post
        The GTK3 => GTK4 migration is a lot easier than GTK2 => GTK3 and there are scripts to automate a large part of it, however it would still require a small amount of manual work.
        The migration from GTK+2 to 3 depended a lot on whether projects had been keeping up with API evolution over the lifetime of GTK+2. If your code compiled without deprecation warnings on the later versions of GTK+2, it would _usually_ also compile against GTK+3 with little or no modification — many projects did that during the transition period, switching between them with a build-time switch. Most of GNOME was in this category... apps like GEdit, Gnome Terminal, etc.

        But if you were a smaller project that was still using deprecated API because you didn't have the resources to keep chasing the latest changes, the migration to GTK+3 was a lot more difficult, because all that accumulated technical debt became due all at once with the removal of the deprecated APIs. And I suspect XFCE is in this category...

        Comment


        • #34
          Originally posted by raster View Post

          Congratulations. you found one thing it's not good at. There is thus a protocol that exists to request the client not decorate in Wayland (not universally supported yet - but it's necessary for things like tiling WMs to look nice, so eventually will be).

          You may have missed the bit where I was doing an overall evaluation from all the angles... But hey... everyone has their ax to grind.
          Another issue is dealing with unresponsive apps. With SSD the titlebar isn't controlled by the app and you can easily close it. For wayland there seems to be a ping-protocol to detect unresponsive apps, but I saw that fail, no idea if it is better nowadays.

          Concerning the protocol: KDE devs proposed a solution to let the client put arbitrary widgets in the server-side-controlled decoration. It never was considered by the Gnome devs so it couldn't take off.

          Comment


          • #35
            Originally posted by schmalzler View Post

            Another issue is dealing with unresponsive apps. With SSD the titlebar isn't controlled by the app and you can easily close it. For wayland there seems to be a ping-protocol to detect unresponsive apps, but I saw that fail, no idea if it is better nowadays.

            Concerning the protocol: KDE devs proposed a solution to let the client put arbitrary widgets in the server-side-controlled decoration. It never was considered by the Gnome devs so it couldn't take off.
            There's a ping protocol in X (it's under NETWM client extensions). If it's failed that's either a bug in the WM or compositor, or the client is responding and actively choosing not to respond to the user (or perhaps another bug on its end), but... all of this doesn't forbid the wm/compositor from doing what they already have been doing for decades: alt+left mouse == move window around anywhere. no titlebar needed. alt+right mouse == bring up wm/compositor control menu to do things like kill off the app. I can do the same thing in a terminal. An app can set a signal handler for SIGINT and ctrl+c will no longer work if it ignores it... but i can always ctrl+z then kill -9 PID ... but not like this is even needed - you can just also bring up a task manager and kill the process off ... so a user still can easily move the window out of the way or kill it or minimize it etc. - they simply have to use alt.

            A protocol to put widgets in a titlebar is madness. I totally agree with the gnome devs here. it adds a whole load of complexity of having to negotiate sizing cross-process, widgets that do not visually match their surroundings and stand out like a sore thumb (there is a reason kde has dropped xmbed from systray and pushed to an indicator protocol to describe these icons at a meta level...). not to mention this idea then violates one of the fixes of CSD which is to ensure content is synchronized. you'd have to now add a drawing sync protocol to ensure buffers/state are exactly matched frame by frame to get this right. it's a nasty rabbit hole you do not want to go down.

            Overall CSD is better... but like anything it can be abused and made bad, and CSD is not a new thing. It's been abused over the years. Anything can be abused. The solution is in not doing that.

            Comment


            • #36
              Originally posted by raster View Post

              A protocol to put widgets in a titlebar is madness. I totally agree with the gnome devs here. it adds a whole load of complexity of having to negotiate sizing cross-process, widgets that do not visually match their surroundings and stand out like a sore thumb (there is a reason kde has dropped xmbed from systray and pushed to an indicator protocol to describe these icons at a meta level...). not to mention this idea then violates one of the fixes of CSD which is to ensure content is synchronized. you'd have to now add a drawing sync protocol to ensure buffers/state are exactly matched frame by frame to get this right. it's a nasty rabbit hole you do not want to go down.
              So you know nothing about the specifics but argue on an implementation detail level... Wouldn't have expected that from you.

              Did a short websearch and found this:

              https://kver.wordpress.com/2014/10/2...w-decorations/

              So it's similar to the systray thing. client doesn't draw the widgets but give the server a specification.

              Comment


              • #37
                Originally posted by schmalzler View Post

                So you know nothing about the specifics but argue on an implementation detail level... Wouldn't have expected that from you.

                Did a short websearch and found this:

                https://kver.wordpress.com/2014/10/2...w-decorations/

                So it's similar to the systray thing. client doesn't draw the widgets but give the server a specification.
                That's also mad - it's requiring the wm/compositor to implement a full widget set to implement all those widgets. And I'm not arguing from the view that I don't want it or like it because it means work - the WM/compositor I work on has a complete widget set and so can do this if the protocol was supported, but I still think it's mad. It now also runs into consistency issues with widgets in a titlebar not matching the content. It's only consistent if it's KDE with every app an Qt/KDE app (or GNOME/Gtk etc.). Compositors like Weston would never implement this (or sway) as it goes against everything they are about - being simple and being able to skip needing any kind of libraries or code to do things like draw widgets etc. which means apps will have to have code to do it themselves or lose vital functionality which means we're back to CSD or fallback paths that now require the same feature to be supported in 2 ways.

                If you're going down the path of remote widgets then why stop at titlebars? Just move the whole paradigm to a widget server that creates windows, handles their content, thus even if the app has hung an edit box can still be typed into or a list can still be scrolled... a window can be resized and it redraws (or mostly - new content that wasn't already in the widget tree will not be provided until the client app un-hangs). This is a very different paradigm and titlebar widgets like this are a half-way house that isn't that great as you still have inconsistencies all over and massively raise the bar for making a wm/compositor that works.

                FYI there are no real details in that proposal either so i have to fill in the gaps too.

                Comment


                • #38
                  Originally posted by willbprog177 View Post
                  I'm an old dude, who likes 'legacy', stuff I guess. I don't see the point of CSD.
                  If you like legacy stuff, then you do like CSD's as they were already used more than 20 years ago in Xerox's GlobalView OS: http://toastytech.com/guis/gv.html

                  In fact, even the ViewPoint OS on the Xerox Star from 1981 already had CSD's/headerbars: http://toastytech.com/guis/gvstar3.jpg
                  Can't get any more legacy than that.
                  Last edited by Vistaus; 01-15-2020, 01:22 PM.

                  Comment

                  Working...
                  X