Forking GTK 2 apps

[Member Thanatophobia]

Are there any plans for antiX forking the GTK 2 toolkit library? Or recompiling or porting packages to GTK 2?

Despite many packages in the Debian repositories are currently moving on to GTK 3, for now there are a few packages there that still use GTK 2 and the library is still available on Debian even though it has been end-of-life for some time, and it might not remain there for long in future releases considering that many of those packages are now unmaintained.

I have noticed that antiX and MX Linux maintains a few additional packages in its repos that are not found in the Debian repos, including a few that still relied on GTK 2 such as ROXTerm and a few others along with their GTK 3 counterparts.

There have also been packages recompiled for GTK 2 on the AUR.

Personally, I prefer GTK 2 applications as they have a classic look to them, are much lighter, and their themes look better. GTK 3 is too heavy and GNOME oriented and I don’t like it’s “modern” and uniform aesthetics. I also don’t like having to keep two different sets of libraries taking up space and not matching up with the rest of the UI.

I know there is still FLTK and Motif, with their respective environments available from each of them (FLWM and MWM/CDE). And not too many mainstream applications are built for those toolkits nowadays either.

The only option I have is maybe switch to Qt, though I don’t like how it looks and there aren’t too many applications that use Qt as opposed to GTK.

I would make it a personal project to repackage applications that can still be compiled against GTK 2, and maybe take the time to learn the GTK toolkit in order to backport it.

Also AFAIK, there is at least one fork based off of the GTK 2 code called STLWRT (link to GitHub here https://github.com/thesquash/stlwrt), which is supposed to compile both GTK 2 and GTK 3 apps into consistently looking like GTK 2.

Is it antiX’s plan to keep supporting GTK 2 in its repos and offer GTK 2 apps indefinitely? Or will all packages eventually be ported to GTK 3/4 with only that version available?

• This topic was modified 1 year, 3 months ago by Thanatophobia.
• This topic was modified 1 year, 3 months ago by Thanatophobia.
• This topic was modified 1 year, 3 months ago by Thanatophobia.

[Anonymous]

Helpful

Up

0

::

xref: MX Linux forum topic: Forking and maintaining GTK 2 library and applications

.
> I prefer GTK 2 applications as they have a classic look to them, are much lighter, and their themes look better.

I share your sentiment.

> GTK2 [..] many of those packages are now unmaintained

unmaintained == forcibly deprecated, by the Gnome project and the Debian Gnome Team
(Jeremy Bicha, and the team, is (y)our nemesis ~~ an opponent or rival which we cannot best or overcome)

unmaintained ~= cherished, “warts and all”.
No showstopper bugs, so no expectation of need to “maintain” it. If it ain’t broke don’t fix (deprecate) it…

> GTK 3 is too heavy and…

…and editing or creating gtk3 themes is quite a chore. Many, if not most gtk3 themefiles need to be “compiled”.

> I would make it a personal project to repackage applications that can still be compiled against GTK 2, and maybe take the time to learn the GTK toolkit in order to backport it.

For personal use, I’ve preserved several gtk2 applications ~~ compiling ’em and their (now absent from debian stable repo) dependent libraries on the newer O/S version. It’s quite a chore, for any given application there are typically a LOT of dependent library packages (many of which have also been nixed from debian). backforward porting cannot be fully achieved (the app will run, but gLib or another component will spammily spew deprecation warnings. To skirt namespace collision (gtk3 libs bearing same-name), one would need to compile-and-rename various chained, low level, library packages (e.g. ,myglib2) and search/replace all affected references throughout the application source code. Alternatively, we (you, me) may be able to utilize LD_PRELOAD and AppImage packaging to continue delivering select gtk2 applications.

Also, bear in mind that many of our (well, true for mine at least) cherished “good old applications” are pygtk (python 2 + gtk 2)
which necessitates curation and maintenance of a plethora packages which provide various python2 libraries.

> There have also been packages recompiled for GTK 2 on the AUR

Really “recompiled”, or just preserved to (still) build against gtk2, or against a non-current version of gLib?
If you share some links, I will take a look.

> a fork based off of the GTK 2 code called STLWRT [..] to compile both GTK 2 and GTK 3 apps into consistently looking like GTK 2.

Smells like a fool’s errand considering that there’s nosuchthing as *one* “gtk3”. Breaking changes//deprecations exist across the 20+ various gtk 3.xx versions

Is it antiX’s plan to keep supporting GTK 2 in its repos and offer GTK 2 apps indefinitely?

Clearly the answer is NO.
Most if not all of the antiX -authored (scripted, not compiled) utilities have already been rewritten; the newer versions use python3 + gtk3; the compiled antiX/MX apps rely on Qt.

[Author]

Posts