Announcement

Collapse
No announcement yet.

The Better Looking Window Decorations For GNOME 3.16

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

  • The Better Looking Window Decorations For GNOME 3.16

    Phoronix: The Better Looking Window Decorations For GNOME 3.16

    With the GNOME 3.16 series, Mutter uses GTK+ for drawing all window decorations regardless of using client-side decorations, and there's also many other GTK+ improvements...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    So GNOME will remove metacity-1 themes from their theme packages

    This will have consequences for anyone running GNOME themes on GTK3 apps outside of GNOME. Unity and Cinnamon users will need a separate metacity-1 theme in any theme originally written for GNOME whose authors do not include a metacity theme. Hopefully most themes whose target audience includes those running GTK2 as well as GTK3 (other than Firefox) will still
    include the metacity theme or else look decent with the default.

    For users of MATE with compiz on upcoming GTK3 versions, there will always be the option of Emerald (unsupported but works) if metacity themes break again.

    GNOME is right about one thing: using css instead of the metacity-1 format to write the window manager theme will make it easier. Unfortunately I don't see an option to use css window manager themes outside of GNOME anytime soon. Given that a hell of a lot of GTK3 apps are run outside of GNOME, this could become a problem if theme authors do not keep up. I maintain my preferred theme myself locally, but few people do that, so people could find themselves giving up on broken themes.

    Comment


    • #3
      Originally posted by Luke View Post
      This will have consequences for anyone running GNOME themes on GTK3 apps outside of GNOME. Unity and Cinnamon users will need a separate metacity-1 theme in any theme originally written for GNOME whose authors do not include a metacity theme. Hopefully most themes whose target audience includes those running GTK2 as well as GTK3 (other than Firefox) will still
      include the metacity theme or else look decent with the default.

      For users of MATE with compiz on upcoming GTK3 versions, there will always be the option of Emerald (unsupported but works) if metacity themes break again.

      GNOME is right about one thing: using css instead of the metacity-1 format to write the window manager theme will make it easier. Unfortunately I don't see an option to use css window manager themes outside of GNOME anytime soon. Given that a hell of a lot of GTK3 apps are run outside of GNOME, this could become a problem if theme authors do not keep up. I maintain my preferred theme myself locally, but few people do that, so people could find themselves giving up on broken themes.
      This isn't the first time GTK-3 theming is broken outside of gnome. It's the reason I avoid GTK-3. I can't seem to get those apps to look and feel integrated.

      GTK-2 and QT both have a ton of identical themes. Not true for GTK-3. Even if it did, it breaks so often.

      Comment


      • #4
        Originally posted by duby229 View Post
        This isn't the first time GTK-3 theming is broken outside of gnome. It's the reason I avoid GTK-3. I can't seem to get those apps to look and feel integrated.

        GTK-2 and QT both have a ton of identical themes. Not true for GTK-3. Even if it did, it breaks so often.
        IMO this is the fundimental issue with GTK+ these days, it's development is so tightly coupled to GNOME that it makes it unsutable for use on other platforms, and increasingly for other Linux desktops.

        Comment


        • #5
          Gtk2 and GTK3 themes can be matched-with a lot of images

          Originally posted by duby229 View Post
          This isn't the first time GTK-3 theming is broken outside of gnome. It's the reason I avoid GTK-3. I can't seem to get those apps to look and feel integrated.

          GTK-2 and QT both have a ton of identical themes. Not true for GTK-3. Even if it did, it breaks so often.
          I've been playing with my old Gtk3 port of a modified UbuntuStudio theme since Gtk3.14 came out in Vivid and broke support for the old style "background image" check and radio button internal boxes. I fixed that rather quick-but also replaced the previous checkbox images with direct screenshots of the Gtk2 Ubuntustudio checkboxes in the process. Then I took the radio boxes from the E17 theme I was using and put them in the Gtk2 theme with the "pixmap" engine which is always available.

          What I've found is this: when matching Gtk2 and Gtk3 themes to look almost exactly alike, many widgets must be on at least one of them an image of that widget in the other. I like to use a common "assets" directly symlinked into both of them for images. In many cases I use the same image for both, in other cases I let one version render something like a toolbar from a gradient and the other gets an SVG image of that

          What began in early October as Gtk3 bugfixes for Cairo-dock and extended into porting a Gtk3.12 theme into a Gtk3.14 theme has now matured into a theme good enough to make it difficult to determine which Gtk version you are using for an unknown program unless you are using either a Gtk3 sidebar (layout is different except in Nemo) or a header bar. Those header bars were another challenge: I was able to make them look almost like a toolbar topped with the Metacity Ubuntustudio theme but containing the window buttons in client side decoration, yet theme to a flatgray toolbar when topped with a server-side decoration by Compiz. Looks good in gnome-shell, in cinnamon, and in MATE. Still can't find a way to "stripe" that sidebar treeview however.

          The E17gtk theme I used to rebase my theme on when I heard about theme engine deprecation, as well as the "Delorean Dark" theme I got the gtk-wide-separator (sidebar bug) fix from both match their Gtk3 and Gtk2 versions by using a lot of images. There are a lot of themes like this on DeviantArt and more on Gnome-look. When I get my theme fully done I might set up an account there and post it along with a backported version for Gtk3.12, a matter of replacing the gtk-widgets-assets file with one using "background-image" instead of "gtk-icon-source" for checks and radio items. I will always have to maintain this through future rounds of Gtk3 breakage anyway, as I am unwilling to part with the theme I've used since 2008.

          I can't post screenshots here, or I would show you Caja and Nemo side by side, along with nearly indistiguishable instances of Pluma and Ubuntu's Gedit 3.10. Only took half a Gtk development cycle to get there...

          Comment


          • #6
            Does anyone else see the weird square edges on the top corners of the client-side decorations?



            That's driving me nuts. They better fix that.

            Comment


            • #7
              @ Luke: It sounds like you finally got something together you can use that suits you. If you get it hosted somewhere, post a link here, I'll check it out.

              Comment


              • #8
                Originally posted by FuturePilot View Post
                Does anyone else see the weird square edges on the top corners of the client-side decorations?



                That's driving me nuts. They better fix that.
                It has to do with X being 'by cavemen, for cavemen': it doesn't properly support decoration alpha transparency (AFAIK) and probably never will (since most X devs have abandoned it and are working hard on Wayland). X still mainly lives in a 1-bit monochrome world, long before RGB (let alone RGBA) was dreamed of. But today, transparency is still rocket science in Linux Land (apparently). Wait for Wayland.
                Last edited by Remdul; 31 January 2015, 03:15 PM.

                Comment


                • #9
                  Originally posted by Remdul View Post
                  It has to do with X being 'by cavemen, for cavemen': it doesn't properly support decoration alpha transparency (AFAIK) and probably never will (since most X devs have abandoned it and are working hard on Wayland). X still mainly lives in a 1-bit monochrome world, long before RGB (let alone RGBA) was dreamed of. But today, transparency is still rocket science in Linux Land (apparently). Wait for Wayland.
                  While mostly true, that doesn't explain this particular scenario, since both screenshots are on X, yet the one with the old-style decorations doesn't show the problem. No, this is probably just a rendering error... a bug in the new code that hasn't been fixed yet.

                  Comment

                  Working...
                  X