A few questions about a fork of GTK

I am currently working on a fork of GTK 3.2 intended for "traditional" user interfaces. Now I am wondering how much demand there is for a fork like this and whether I should break API/ABI compatibility with mainline GTK 3 by changing the prefixes for all of the GTK/GDK types, functions and changing the names of the files. Would anyone like to give some ideas?

4 Likes

I think there are a lot of people that prefer the traditional interface. I have no idea if it would break things. Most here came to Mate because they didn't want the radical changes Gnome3 brought. I haven't seen a great deal of enthusiasm for Yaru either.
Yet you never know, there are those that like and want the latest greatest stuff. I hope you can be successful.

1 Like

First of all: You definitely should contact @gordon
He is also working on a GTK fork, called STLWRT, and has come quite far.
I suppose if you both bundle your efforts or at least participate in some information c.q. code exchange you both will be better off :slight_smile:

There is demand from several people who are not quite happy with the way the current GTK(Gnome) is breaking things at the moment.

Better ask @gordon :slight_smile:

1 Like

I have no much idea about gtk versions, but if it brought back this:

then it would be great! As for now, after an upgrade it does not feel to me like Linux Mint anymore. There is even a new "UbuntuMATE" branding which is quite apt I'd say, because that's what seems to slowly happen to Mint.

Edit: I am sorry for the confusion, it turns out that LM and UbuntuMATE are two different things :slight_smile: Someone gave me a UM stick, telling that it is LM :slight_smile:

I have got in contact with him before, unfortunately, he is currently in a rough situation and cannot help out or work on anything open source for the foreseeable future. I even tried to resurrect STLWRT personally, unfortunately, due to several issues I had to scrap my efforts on STLWRT and start working on a new fork based on GTK 3.

3 Likes

In theory, nothing major should break, and porting over programs should be as simple as replacing the prefixes and linking against this new library. But we will see how things work out when I'm finished porting over the major changes from newer versions of GTK 3.

2 Likes

Ah, theory and application can certainly be very different. Good luck.

2 Likes

There is a nice project called gtk3-classic that restores classic gtk behaviour.

There is also a MATE and gtk3 fork called CAFE desktop.

2 Likes

I already knew about those projects, but I decided to create a new fork because those projects only fix some of the annoyances and regressions brought on by modern (post 3.2) versions of GTK3. They do not fix the lack of support for theming engines, the "touchscreen-friendly" spin buttons introduced in 3.4, the horrid design of the fancy new font and colour choosers, text drawing in progress bars being broken, colour variations for themes not being supported directly and so on.

My fork aims to fix all of those. While also solving the fact that mainline GTK3 will be killed off entirely in a few years (which is something that the gtk3-classic patch set will never solve).

2 Likes

Another question, should I implement popovers and headerbars for the sake of compatibility or should I leave them out?