The thing is if you look closely at gtk4 i did notice : 1) Menubars can be done in gtk4 as well as toolbars. 2) A window shadow and the headerbar can do window decorations. Like back the days of unity they can be themed.
3) It should be possible to replace libadwaita with something different that loads files from disk to a small ram drive-/ressource. Sry but what gbome tells us there is just garbage. Gtk4 cpuld be themed and look as gtk3. Scrollbars could be done with combining some other widgets.
The dev behind Xfce terminal did a video where he explained that he has moved gtk functionality for menubars, toolbars and statusbars into a separate library called xfce-libs. I assume scrollbars can also be found there.
So in the future when an Xfce application developer ports code to gtk4 they can use xfce-libs to get access to the gtk classes that have been dropped from gtk4.
This sounds like a good solution and Xfce devs can start using it even before porting to gtk4. Something similar should be developed for MATE or maybe reuse xfce-libs, because it's probably just a small library.
0.9.0
======
This is a development release.
- Replace the deprecated GtkActionEntries with XfceGtkActionEntries (Issue #79)
This library seems like a good start however it would still require application developers to add code to use it.
For applications which will run in a range of desktop environments they'd need a bunch of if/else statements to detect whether it's running in GNOME and should follow their daft conventions, or in XFCE/MATE etc and should render a sensible legacy UI.
It doesn't even stop with titlebar, menus and scrollbars; there's also things like the use of what they call 'pop-overs' in place of traditional contextual menus (e.g when you right click somewhere and get a menu).
E.g. One of the first applications I noticed was 'remmina' (an RDP client) - when I looked at their source code I could see they'd done as advised by GNOME and removed all of their legacy menu code in place of the new GTK3+ titlebar with embedded buttons and hamburger menu. For a short while they'd included detection of XFCE to present classic menus but then they dropped it as being too much extra code to maintain.
The specific trouble with menus and the possibility of alternative libraries is that the menus are no longer expressed in a hierarchical tree structure - you will have several individual buttons e.g. 'save' which sit outside of the hamburger menu's structure, and the hamburger itself has a load of top level items and arbitrary submenus which certainly don't follow any classic structure e.g. File/Edit/View/Window menu sections... The only possible way for an 3rd party library or interposer to display these in a classic format is either to guess based on the item names (e.g. put 'print' under the File menu, Select All under the Edit menu etc) which would be really haphazard, or to maintain some kind of mapping file which recognises the app being run an remaps to classic menus based on these rules. Obviously that would be a lot of work and would require maintenance in order to keep up with changes in every supported application. Therefore, I don't see this as a practical solution.
All of this is why I'm so angry with GNOME here - they've made a design choice in their desktop and pursued it almost religiously to get wide scale adoption by developers without ever stopping to consider how badly this breaks things for everybody else.
If it was an oversight I'm angry that they didn't act with more care.
If they did this in the full knowledge of the widescale impact it would have on the whole ecosystem including traditional desktops then I'm not going to print the four-letter words I want to call them! Empires have no place in the Linux world - perhaps they should go and work for Microsoft instead.
The damage is already largely done due to so many applications already converting to this new structure and removing the 'legacy stuff'.
Fixing this mess properly will require:
- GTK to re-add legacy support, OR the creation of a new extension library
- Persuading a lot of projects to re-implement stuff they already spent time removing.
I can't see any way of getting back to normality without both of the above happening 
The other consideration is that even if this gets fixed, the current dreadful UI is firmly baked in to LTS distributions (I'm using Ubuntu but it's similar for many others). Such a major change wouldn't be included in regular patches so LTS users will have to wait until at least the next long term release unless they want to install alternative packages for their desktop environment plus each and all of their affected applications.
I'm extremely upset about this (if you can't already tell from my rantings) - Since making a permanent switch to a Linux desktop back in 2007, this problem comes second only to the time when GNOME2 was abandoned and my long-standing, stable desktop setup was ripped out of my hands. Fortunately, the excellent MATE desktop was born out of those ashes and rescued me, but not until after a few months of disruption and upset.
I got screwed by GNOME back then (due their ideological decision to axe a perfect good desktop and replace it with something 'better') and now I'm getting screwed by GNOME again due to their ideological views on throwing away the rulebook on good desktop UI principles and forcing something 'better' on everyone!
If it weren't for the fact that most of the stuff I use is based on GTK with no viable alternatives (e.g. all mainstream web browsers are based on GTK so far as I can tell ) then I'd probably give more consideration to abandoning it.
I'm trapped - there's quite literally nothing I can do right now to escape these changes. Switching to KDE or wherever won't fix it, switching to Windows or masOS would only impose worse UIs which are even less customisable... Linux is about freedom and choice, yet here we are: backed into a corner by a single, dominant player
The only difference between this and a Microsoft-imposed Windows UI change is that this one is open source and so can technically be changed, but the reality is that it's so big and affects so many software packages as to be practically impossible for the community to fight back
My quick answer would be "I hope not" IMHO it is the "phonifacation" of the desktop apps that have gotten us into this Unity/GTK3/GTK4 mess. Dinky little mobile phone screens are different than full size desktops. Trying to pretend this fact doesn't exist is counter productive.
2 Likes
I still think the only thing to do now is to switch Linux over to Qt. I think the main barrier would be that Qt has no support for C, so I got started on binding Qt's C++ code to C after making my last comment. The bindings are almost half complete. As Ovation1357 said, the Linux community is still bound by the managers of core utilities like GTK, even if they are called "community maintained". The best way to avoid this would be to make future libraries use compatible syntax so that they can be swapped seamlessly by users. For example, if future toolkits used the same syntax for functions as GTK or Qt but had additional features that those toolkit lacked, then apps that use GTK or Qt could switch without doing a full rewrite of their GUI code, and users could switch between the 2 without the app even noticing.
Anyways, this isn't how things are today and developers still have to choose which toolkit to use from the very beginning, so Qt at least has to be an option. I'll try to finish the bindings as soon as possible and I'll report back to this forum once they're complete.
1 Like
There is always ELF 
EFL Tutorials
About gtk4, can I do standalone popovers in gtk4 like in gtk3?
Something like this:
// gcc test.c `pkg-config --cflags --libs gtk+-3.0 gdk-3.0 glib-2.0` -lX11 && ./a.out
#include <unistd.h>
#include <stdio.h>
#include <X11/Xlib.h>
#include <X11/Xatom.h>
#include <gtk/gtk.h>
#include <gdk/gdkx.h>
#include <glib.h>
static void my_gtk_realize(GtkWidget* widget, gpointer data)
{
gtk_widget_set_window(widget, (GdkWindow*)data);
}
static void file_quit(GtkWidget* widget, gpointer data)
{
gboolean* running = (gboolean*)data;
*running = FALSE;
}
int main(int argc, char** argv)
{
gtk_init(&argc, &argv);
XVisualInfo vinfo;
GdkDisplay* gd = gdk_display_get_default();
Display* d = GDK_DISPLAY_XDISPLAY(gd);
cairo_rectangle_int_t rect;
XMatchVisualInfo(d, DefaultScreen(d), 32, TrueColor, &vinfo);
XSetWindowAttributes attr;
attr.colormap = XCreateColormap(d, DefaultRootWindow(d), vinfo.visual, AllocNone);
attr.border_pixel = 0;
attr.background_pixel = 0;
Screen *scr = DefaultScreenOfDisplay(d);
Window w = XCreateWindow(d, RootWindowOfScreen(scr), 0, 0, 350, 200, 0, vinfo.depth,
InputOutput, vinfo.visual, CWColormap | CWBorderPixel | CWBackPixel, &attr);
XSelectInput(d, w, StructureNotifyMask);
GC gc = XCreateGC(d, w, 0, 0);
Atom wm_delete_window = XInternAtom(d, "WM_DELETE_WINDOW", 0);
XSetWMProtocols(d, w, &wm_delete_window, 1);
Atom net_wm_state_skip_taskbar=XInternAtom (d, "_NET_WM_STATE_SKIP_TASKBAR", False);
Atom net_wm_state = XInternAtom (d, "_NET_WM_STATE", False);
XChangeProperty (d, w, net_wm_state,
XA_ATOM, 32, PropModeAppend,
(unsigned char *)&net_wm_state_skip_taskbar, 1);
Atom WM_HINTS;
WM_HINTS = XInternAtom(d, "_MOTIF_WM_HINTS", True);
if ( WM_HINTS != None ) {
#define MWM_DECOR_NONE 0
#define MWM_HINTS_DECORATIONS (1L << 1)
struct {
unsigned long flags;
unsigned long functions;
unsigned long decorations;
long input_mode;
unsigned long status;
} MWMHints = { MWM_HINTS_DECORATIONS, 0,
MWM_DECOR_NONE, 0, 0 };
XChangeProperty(d, w, WM_HINTS, WM_HINTS, 32,
PropModeReplace, (unsigned char *)&MWMHints,
sizeof(MWMHints)/4);
}
XMapRaised(d, w);
GdkWindow* gw = gdk_x11_window_foreign_new_for_display(gd, w);
gdk_window_move (gw,
535,
600);
gdk_window_set_pass_through (gw, TRUE);
gdk_window_set_type_hint (gw, GDK_WINDOW_TYPE_HINT_POPUP_MENU);
GtkWidget* gtk = gtk_widget_new(GTK_TYPE_WINDOW, NULL);
/* Tell GTK+ that we want to draw the windows background ourself.
* If we don't do this then GTK+ will clear the window to the
* opaque theme default color, which isn't what we want.
*/
gtk_widget_set_app_paintable(gtk, TRUE);
GtkWidget *close_button;
GtkWidget *box;
GtkWidget *label;
GtkStyleProvider *style_provider;
g_signal_connect(gtk, "realize", G_CALLBACK(my_gtk_realize), gw);
gtk_widget_set_has_window(gtk, TRUE);
gtk_widget_realize(gtk);
GtkWidget* popover = gtk_popover_new(gtk);
gtk_popover_set_constrain_to(GTK_POPOVER(popover),
GTK_POPOVER_CONSTRAINT_NONE);
rect.x = 1;
rect.y = 100;
rect.height = 1;
rect.width = 1;
gtk_popover_set_pointing_to(GTK_POPOVER(popover), &rect);
gtk_popover_set_position(GTK_POPOVER(popover), GTK_POS_RIGHT);
gtk_popover_set_modal(GTK_POPOVER(popover), FALSE);
style_provider = GTK_STYLE_PROVIDER (gtk_css_provider_new ());
gtk_style_context_add_provider (gtk_widget_get_style_context (popover),
style_provider,
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
char *css_text;
css_text = g_strdup_printf ("popover.background {\n"
" border: solid 2px;\n"
"}\n");
gtk_css_provider_load_from_data (GTK_CSS_PROVIDER
(style_provider),
css_text, -1, NULL);
g_free (css_text);
box = gtk_box_new(GTK_ORIENTATION_VERTICAL, 5);
label = gtk_label_new("Frieder_Saugschmerle\nwas here.");
close_button = gtk_button_new_with_label("Ok");
gtk_widget_set_sensitive (close_button, TRUE);
gtk_box_pack_start (GTK_BOX(box), label, TRUE, FALSE, 10);
gtk_box_pack_start (GTK_BOX(box), close_button, FALSE, FALSE, 10);
gtk_container_add(GTK_CONTAINER(popover), box);
gtk_container_add(GTK_CONTAINER(gtk), popover);
gtk_container_set_border_width (GTK_CONTAINER(gtk),
0);
gboolean running = TRUE;
g_signal_connect(G_OBJECT(popover), "closed", G_CALLBACK(file_quit), &running);
g_signal_connect(G_OBJECT(close_button), "clicked", G_CALLBACK(file_quit), &running);
gtk_widget_show_all(gtk);
while (running)
{
Window focus;
int revert_to;
XGetInputFocus(d, &focus, &revert_to);
if (focus != w)
running = FALSE;
while (g_main_context_pending(NULL))
{
g_main_context_iteration(NULL,FALSE);
}
}
XDestroyWindow(d, w);
XCloseDisplay(d);
}
[quote="Ovation1357, post:88, topic:22028, full:true"]
If they did this in the full knowledge of the widescale impact it would have on the whole ecosystem including traditional desktops[/quote]
GNOME absolutely, unquestionably, willfully, did exactly that. They make no pretense of this being an accident or an oversight: they're proud of it, and they don't care who knows it - because after all, if you don't think it's better it's just because you're either "like, old" or you've got accessibility issues, and in either case you can just f**k right off because that makes you not part of the tribe.
The damage is already largely done due to so many applications already converting to this new structure and removing the 'legacy stuff'.
Yes, but that was the whole point of CSD - it explicitly broke the contract of window manager and application responsibilities so that programs realistically had to choose one approach and abandon the other.
Since Red Hat owns GNOME and gets to choose which programs get to be installed by default on RHEL and Fedora, just as Canonical and even the UM team choose whether Evolution or TBird or whatever gets to be the default email client this week, there is enormous pressure on "independent" developers to adopt "the new GNOME approach" - not least because GNOME is busy making sure that otherwise your program will not only not be "blessed", it will simply stop working entirely in the next Fedora release, when the functionality you're using for e.g tabbed dialogs has been ripped out of GTK entirely.
Trying to recover from the damage GTK3+, and especially GTK4, has and will cause is simply not possible: there are far too many programs involving far too much work. It's analogous to a crystal statue - trivial to shatter into pieces, but impossible to reassemble. Uptake of CSD has been extremely slow, but even so it's wasted millions of hours of developer time over the last decade to reach its current breadth. A return to sensible design principles would require a similar amount of time and effort, distributed across the same group, and that's just not going to happen without an impetus as large as the combination of carrots and threats that GNOME used to get the transition to CSD in the first place - and like it or not, nobody else in the Linux desktop space can provide that any longer, so this is how it's going to stay.
To take the easiest example, look at Firefox. For over a decade now, Firefox has failed to render scrollbars properly because it comes bundled with its own defective and comically-outdated version of GTK. It's worked correctly for literally just a few months total at most in all that time, and I'm pretty sure even that tiny success was more an accident than anything else. 
When Firefox adopts CSD, as it will inevitably do as soon as anyone at Mozilla cares enough to bother with it, since the Windows build has already been using CSD for longer than I can remember, nothing you or anyone else can do short of patching Firefox itself, three times a month, every month, forever [1], will get you a "working" titlebar that looks like it belongs with the rest of your desktop.
While I share your dislike of both the Windows 8 level of design competence in GNOME3 and the Dunning-Kruger poster children responsible for it, unless you have a few million dollars of your own that you want to get rid of you're going to have to accept it. Tilting at windmills is cathartic in the short term, but terrible for your stress levels in the long term, and ultimately unproductive.
You can have a consistent *DE* still, such as MATE provides, but that's the most you can hope for: the days of a consistent desktop have passed (other than "mostly so" on OSX), and now that the CSD fiasco has reached critical mass I don't expect that we will ever see such a thing again.
AFAICS, the best - and possibly only - thing that can be done in the long term is what Perberos did to start MATE in the first place: fork GTK, which unfortunately comes with a crippling maintenance burden - not least because Wayland is explicitly intended to make it gratuitously expensive to use anything other than the RedHat ecosystem. With luck, that's an action that only needs to be taken once a decade or so, but it's still asking a lot from people who generally don't have a lot of "spare" time in the first place.
I guess we'll find out soon enough, either way. 
3 Likes
Thanks arQon, I wholeheartedly agree with everything you've said.
The sad, short story is that our beloved desktop UI is doomed and there's extremely little we can do about it
I wish I did have millions at my disposal to be able to counter this affront to free software.
1 Like
Reading some of the comments regarding the future of GTK and its possible effect on Mate, left me a bit confused. Let's say in a few years from now Mate starts being ported to GTK 4. I understand that some compromises will be inevitable, but it's not to the point that it will be impossible, right?
Btw, regarding CSD windows, I can tolerate them designwise, but what I really hate about them is simply how huge they look compared to SSD windows and other ui elements on a traditional GTK DE like Mate. Because of that they look really out of place. Luckily, this can be mitigated by some themes that make the ui elements of CSD windows smaller, so that they look proportionally more consistent with SSD windows. I think WhiteSur and the new Linux Mint GTK themes do this really well.
Just wanted to remind everyone that the C bindings for Qt could still turn things around. The idea of MATE was to keep GNOME 2's design alive, which doesn't have to mean using GTK. The project is here on github: https://github.com/sammonius/qtc.
The reason I keep clinging on to this is that despite the fact that I've used GTK for nearly a year for some of the apps I've tried making, I could tell from the start by looking at the terrible documentation and rediculously huge buttons that it was going to be a pain in the butt. The only reason I went with GTK is because it was all that's available for C. After a few months of misery I decided that giving up on C completely would be better than having to deal with GTK and installed Qt... which turned out to be even better than I thought it would be.
I fully belive that GTK would be forgotten in less than 4 years if Qt had fully-functional C bindings. The one on github is still not finished (and it was never half finished, that was a HUGE mistake to think that). If anyone can come help me make it on github it would be great . Hopefully it's finished soon.
4 Likes
Well if we're convinced that we need to move in that direction, perhaps looking into the planned fork of Cuttlefish might have some value? If it's just a matter of recreating some of our panel applets that should be simple enough, right? Yet somehow I suspect this is still easier said than done.
I remember when Unity was supposed to be the new desktop environment, some of the other desktops developed themes that resembled Gnome 2, like IIRC there was a configuration for Lubuntu that did this. The problem was that while superficially it resembled the Gnome 2 desktop, any attempts to customize the interface were doomed to failure for anyone used to Gnome 2.x's point and click move of applets and elements on the panel. Instead you needed to do things the LXDE way and use their configuration application to change things. It created a cognitive dissonance because while a lot of things looked the same none of them worked quite the same.
I suspect after a while no one was using it because the last time I looked that option was no longer there.
Still rather than starting completely from scratch, perhaps it would make sense for those who can code who are looking at this issue to adapt part of an existing desktop such as Cutefish and see if a set of options can be carved out to make a new home if\when it becomes impossible to keep going forward with GTK?
The gnome devs are stubborn to not support theming and theyll drop menubars in future. To be honest scss ist quite powerful but you would need to add an entire library with similar functionality to libadwaita in top of libgtk-4. This library would need to be updated and Mate would need to replace marco-/metacity with an CSD decoration compositor. Each SSD Window hast to Bel loaded INSIDE a CSD Container Like its eine in gnome. Sadly thats the only doable Future of mate stays in gtk.
my thought is to create a separate library for writing MATE applications that is compatible with Gtk, similar to how Elementary has Granite, although I'm not sure how that all works, also maybe similar to xfce-libs mentioned earlier in the thread, ending up using gtk for just the base window with most or all custom widgets
If you are looking for GUI-libs with C bindings, maybe Enlightenment/E17 would be an option.
(AFAIK Enlightenment should be E24 at the moment but is still often referred to as E17)
It is pure C, pretty elegant and also has a wayland-compositor ready to use
There is gscan2pdf besides Simple Scan.
I read this thread with interest, which might be the thread essential to Mate's existence in the future. Big thanks, and no offense to the few developers who work so hard on this project. But what is the future of Mate? The whole point of Mate is the traditional look and feel, isn't it? Mate uses a fork of Gnome2 to accomplish that. If we cannot maintain the traditional look and feel, then Mate is obsolete. I gather from this thread that it will be impossible to maintain the Gnome2 look and feel without forking GTK, AND either convincing app developers to provide alternate builds, OR forking whatever app we want to include with Mate with the traditional look and feel, correct?
I gather that there are some other efforts to accomplish that, among which are X-Apps and Cosmic (Pop!_OS).
This thread is 2 years old. Simple question: What is the current status of affairs? Does the dev team have any strategy regarding the GTK team dropping support for a traditional look and feel? Is it worth changing to and committing to Mate at this point in time? I am looking to switch from Windows and I like Mate best, but I don't want to commit to a desktop environment that is on life support without strategy to overcome its apparent demise. Is there any realistic hope, or might it be better to try to get used to hideous and counter-intuitive hamburger menus and inconsistent, cluttered CSD on the desktop? Is the strategy maybe to fork a number of "core" applications, and live with the fact that the rest of 3rd party applications won't match the look and feel? Another problem is that as long as Mate doesn't switch to GTK3/4, we will be left out of a number of useful improvements like some recent performance improvements they made, or fractional per-monitor scaling.
1 Like
I'm convinced that MATE has a future, and even though that future may not be as bright as it could be, I am of the opinion that it's not going anywhere anytime soon (at least the traditional desktop interface isn't going away!).
Now, before I continue, let me make it clear to you (and anyone else reading this) that I may be slightly biased.
-
I am a fervent MATE user myself; literally every installed Linux system I use that has a graphical user interface at all, has MATE installed, and I use it exclusively unless I'm researching a feature that some other desktop has.
-
I have made many significant changes (feature additions, bug fixes, etc.) to MATE in the past, well, two years. (Two years and two months to be exact, but I'm not going to be a stickler about it.)
-
I am (at least nominally) a quality assurance tester for the Ubuntu MATE project and have made some code changes to Ubuntu-MATE-specific components of the desktop.
-
I was the driving force behind STLWRT (you may have read about it above), and while I still agree with everything that I said above, I strongly suspect I'm going to have to essentially start over with the whole STLWRT thing. (I was going about it wrong -- I didn't know then what I know now. I should have made incremental changes rather than trying to overhaul the whole thing all at once. Stupid me.)
-
On top of that, as of the 12th of this August (2022), I am now a member of the MATE Core Team of developers. So I do real development and maintenance work on the desktop.
I'm not trying to boast, as much as it may seem like I am. All that is just a disclaimer that I'm in the MATE project up to my neck, so to speak, and I have no intention of giving it up. None. So expect a little bit of bias coming from me.
As for current affairs, I recently read a fellow MATE team member's memo to everybody on the team. He said in that memo (from nearly a year ago) that the situation with GTK 4 is grim (of course, I said that even longer ago), and that basically, in his opinion it would be stupid to port MATE to GTK 4, at least the way it is now. Even if MATE were ported to GTK 4, we have another problem, that GNOME applications running on the MATE desktop will be themed nothing like the MATE applications. Basically, GNOME applications won't be themeable, and there are speculations that GTK 5 will remove theming support entirely -- though we'll have to worry about that only in a few years.
And, the MATE project is notorious for making sweeping changes really slowly. I'm not saying that to be rude; the MATE project literally has only 21 team members for the whole thing of 45 individual packages (and one of those members is me!). Believe it or not, porting from GTK+ 2 to GTK+ 3 took from before MATE version 1.8 (2014) until version 1.18 (2017), and even today we still find errors caused by the switch to GTK+ 3! Here's an example I literally just got finished reading:
(It's not obvious from that pull request, but to my understanding, the issue there was that the name of a "flag" changed from GTK+ 2 to 3. For some background: I'm sure you've seen "grayed out" buttons in some application or another -- those buttons and settings that you can't change no matter how many times you click them, because something else needs to change before the option can be enabled. GTK uses a "flag" to track whether a user interface element -- a.k.a a widget -- should be drawn "grayed out". In GTK+ 2, the flag was called GTK_STATE_INSENSITIVE; in GTK+ 3 an equivalent flag was introduced called GTK_STATE_FLAG_INSENSITIVE, and the old flag marked as obsolete.)
In short, even if the team were to switch to GTK 4, writing the code takes time, testing it even longer. Nobody in the MATE team seems to be interested in porting to GTK 4 right now anyway, and even if so, there are at least two people (me and the guy who wrote that warning about GTK 4's theming crisis) who would object to that, and I'd certainly do anything in my power to prevent MATE from being ported to GTK 4. So I think you don't have to be worried at this point in time.
By the way, your post implies that MATE isn't ported to GTK+ 3 yet:
We've been using GTK+ 3 exclusively since 1.18 (2017) and using it in some places since 1.16 (2016). And furthermore, there is some support for HiDPI on MATE already. The main reason why it's not more widely supported is that not everybody has a HiDPI monitor to test on. (That includes me.)
TL;DR: Sorry for the long-windedness, but in summary, MATE is here to stay, and I'm going to do everything I can to make sure that happens, and I think everyone else will continue to put their hearts and minds into it.
6 Likes
I agree. The Thing is even it would need to extend gtk4.x to use classical Notebooks,menubars,Scrollbars and toolbars.
On GTK4 you would need to compiles the whole library and possibly on GTK5 all applications just to use another theme.
Sadly i lack the skill to do it, but mate should have a alternative window decoration manager that uses scss gtk theming api. Reason is gtk3/4 themes would use these and drop metacity in future.
I'd hate to chase this too far down the rabbit hole here, but I just want to say this:
Interestingly, when Metacity first came out, it didn't have specific window manager themes; it actually used GTK's theming mechanism, and many themes needed extra statements (back then, in their gtkrc files) to theme Metacity widgets like the window buttons and the titlebar. Only around 2005 did Metacity get its own theme file format.
Yeah, I'm not sure why Metacity changed over to special theme files for the window manager. It certainly seems to have made the WM more complicated. Still, I have no plans on removing the existing Metacity theme support we have, but better GTK integration with the WM decorations is something I was already considering.
It's technically possible to enable full fractional scaling with GTK+3. On Ubuntu 22.04 (Gnome), which only uses GTK+3, it works fine, both on X11 and on Wayland, by default. So it's possible for the MATE team to implement it.
More specifically, GTK4 does not bring any benefit in terms of fractional scaling. That's why fractional scaling cannot be a reason to switch to GTK4.
I think that once Gnome/Red Hat stop maintaining GTK+3, the best idea would be for the MATE, Xfce, Cinnamon, and GIMP team to get together and to fork GTK3, which they use together.
I'm pretty sure that MATE, Xfce, Cinnamon and GIMP will be using GTK3 for another decade or so, so this is the best solution. By then Gnome will be at GTK5 or GTK6. 
3 Likes