Restoring Metacity titlebar theme support #90
Replies: 5 comments 7 replies
-
|
Theoretically yes, if one knows which GTK version(s) or commit(s) caused the problem over in GTK+3's codebase, then a patch could be included here to revert them. Please show us a screenshot showing the breakage, along with which apps, and what distro, as I don't use Metacity myself. From my limited GTK knowledge, I can't see how Metacity alone would break (being "server side decorations")... but CSD ("client side decoration") apps are under GTK's plague, yet they're broken here even with these patches (#32) |
Beta Was this translation helpful? Give feedback.
-
|
I'm not actually using Metacity itself, but Cinnamon Desktop's window manager (Muffin) used to be able to use older Metacity themes to theme it. In the latest Cinnamon (5.6) in Fedora 37, this ability is gone, and the Themes preferences dialogue doesn't even show the ability to configure the window manager anymore. In theory you could somehow translate the indecipherable Metacity XML code into equally indecipherable CSS code for gtk.css. Therefore GNOME's changes to GTK+ have broken functionality in someone else's desktop (if they want to mess up their OWN environment, more power to them, but don't mess with mine). This is what the titlebars used to look like:
whereas now the most you can get is this (and that already requires a bit of hacking/unbreaking):
Do you notice that that the background and foreground windows look exactly the same? How is this at all useful? I suspect the people who made this change must not use their computers for doing actual WORK. |
Beta Was this translation helpful? Give feedback.
-
|
From looking at change logs and their commit histories, this seems more like Muffin and/or Cinnamon's "fault" for removing support for these older window decorations rather than something GTK+3 unexpectedly "broke" in an update.
Nothing in GTK 3.24.36's change log suggests they did this. I'm more certain that this isn't a You could try downgrading |
Beta Was this translation helpful? Give feedback.
-
|
Well, the "window border" settings item was still there when I had Fedora 36 that had Cinnamon 5.4, but even after forcing a dnf downgrade to the earliest version of Cinnamon/Nemo/Muffin, I can't get the option back. So how are we going to manage to force themability (and theme configuration) back into these systems? I should never have stopped using CDE. |
Beta Was this translation helpful? Give feedback.
-
|
I don't know... but if downgrading and a restart didn't work, then it may well be some other newer library or package that no longer supports what is needed to render this "legacy" theme. The session type (X11, Wayland) may be worth checking. Since the window manager is responsible for title bars (except CSD apps) - you could swap |
Beta Was this translation helpful? Give feedback.
-
|
I tried "marco --replace" under Cinnamon, and while it changed the window manager, the panel went away along with pretty much all the Cinnamon controls |
Beta Was this translation helpful? Give feedback.
-
|
Well, next time I'm running Cinnamon I'll see what it does. For now I'm running Mate as it seems the least fouled-up of desktop environments these days. Short of running CDE that is. |
Beta Was this translation helpful? Give feedback.
-
|
So what is the next step to un-do the damage to GTK and get proper theming back? Other than abandoning anything based on GTK and re-starting with a different UI toolkit? (I tried out KDE/Plasma, and could never get it to work the way I wanted). Cinnamon had been just right, but the GNOME devs are intent on breaking anything that doesn't fit their deranged and deluded view of computing, I had previously been quite happy to see GNOME develop whatever vision they had for their environment, and leave that to people who prefer that design. But once their changes started messing with MY preferred environment, then it became time for us to break away from their continued destruction. And yes, it IS an intentional breakage, use this as an example: https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/ Perhaps it's time to FORK GTK+. Call it something like CTK (Cinnamon Toolkit)? Or MTK (Mint Toolkit). |
Beta Was this translation helpful? Give feedback.
-
|
There was a work in progress fork of GTK 2 called STLWRT, that I believe was going to run GTK+3 apps and make them look like GTK+2. https://github.com/thesquash/stlwrt Unfortunately, it looks like that development has stalled. Not surprising, as a project the size of GTK is a massive undertaking. |
Beta Was this translation helpful? Give feedback.
-
|
Honestly, I don't think there is an "undo". GTK's development is focused on GNOME, and as a result, GTK apps follow the GNOME Human Interface Guidelines (HIG). Except programs made specifically for other GTK environments like Cinnamon and MATE, but it's inevitable something will have to change in future -- either those apps adopt GTK+4 (and possibly more of their design language) or consider a fork to preserve GTK+3. Worry about that when GTK 3.24 reaches EOL. A fork might only work if majority of distros, environments and apps support it. Developers (and companies) writing programs for Linux already have to decide between GTK, Qt or a cross-platform toolkit like Electron, Flutter, TK, etc. For me, GNOME 2 (then MATE under GTK 2) were good times, but I felt it was time to move on and embrace change. I slowly transitioned to KDE; tried out new Qt apps and made it work for me (like having dual panels). It took some weeks to feel like home again, but I'm happy that KDE/Qt (for the most part) ain't ditching the traditional metaphor (menu bar, toolbars) any time soon -- though, it's increasingly becoming the non-default. |
Beta Was this translation helpful? Give feedback.
-
|
Well, just after my previous message, I found there IS a fork called "CTK" (https://github.com/cafe-desktop/ctk). I had tried KDE/Plasma again, and it got close to usable, but even with that there were too many quirks and unconfigurable settings, and KDE continues to look far too "plastic-y", application & accessory behavior is way off, the file manager INSISTED on using single-click activation even when I explicitly set it for double-click. In the end I was having to do too many work-arounds and make too many compromises in order to approach the same functionality. I have NO problem with "embracing change". But that change has to achieve something, to improve upon what went before. But it seems the only purpose of changes in GTK is flog the egos of GNOME developers. Looks like I made the mistake of not becoming Amish. I suppose when technological society finally collapses in upon itself in a few years, we won't have computers or a power grid to use anyway. |
Beta Was this translation helpful? Give feedback.
-
yes, it is GTK 3 fork, I think GTK 4 is an enemy for classic desktops. It is easy to port GTK applications to CTK. It needs one ctk theme installed for the look (I am working in cafe-themes (mate-themes fork)). I am working in CAFE desktop (not finished yet), which is a MATE desktop fork with CTK. CAFE terminal works with BTE (which is VTE fork with CTK). CAFE panel works with libvnck (which is libwnck fork with CTK). Croma (marco fork with CTK) is very stable (two months working without crash). One classic desktop without gtk3 with the same look is possible, and easy to port :) It never will follow the gnome guidelines, it just respect the classic look for classic desktops, the Classic Tool Kit. |
Beta Was this translation helpful? Give feedback.
-
Now that the GNOME folks managed to break Titlebar theming in the latest GTK+, is there a way these patches could add that functionality back in? The GNOME folks have the arrogant view that you shouldn't be allowed to theme your desktop.
Beta Was this translation helpful? Give feedback.
All reactions