STLWRT: The traditional brought back to life

The Squash · 2020-05-21 20:16:13

Right now and for the past few weeks I've been working on a maintained derivative of GTK+ 2 named STLWRT.

Now, I've tried to explain this to other people on other forums in the past few weeks and a lot of people don't quite get what I just said at first. So let me elaborate.

I used to use GTK+ 1. GTK+ 1 was good enough for me at the time. At the time XFCE did not use GTK; it used XForms, a proprietary toolkit, which I did not approve of.

Then I switched to GTK+ 2. I found it was great. I used GNOME and LXDE desktops for a long time. (I got used to using GNOME, so I didn't bother trying out XFCE for a long time, even once it was ported to GTK.)

Then came GTK+ 3. I realized something bad was brewing, even though it didn't unfold as quickly as I figured it would. Soon after GTK+ 3 was released, GNOME 3 was released. This was when I dropped GNOME like a hot potato and have barely used it since then.

Fast forward some years and LXDE went dead. This was in 2016. I considered MATE and XFCE as my next desktops. I was hoping to go with XFCE but realized it was on the cusp of going partially GNOME-style, so I ultimately switched to MATE, the desktop I still use today. I thought I could live in peace forever.

I write apps with GTK. I am familiar with how GTK works, and I try to keep up-to-date on the latest information about the versions of GTK around the corner. I was thus disturbed when I read about what's going on in the development of GTK 4. Many of the changes in GTK 4 seem, frankly, stupid to me and totally undermine the traditional GUI concepts. GTK 4 doesn't even have real menus.

In the 9 years since GTK+ 3 was released, I've realized there are a lot of people who don't like GTK+ 3 (and much less GTK 4), but who are unable or unwilling to do anything about it.

Today, there are still some "stubborn" developers who insist on keeping their applications GTK+ 2-only. Until recently the GIMP was like this.

On the other side of the coin, there are a lot of application developers who have just converted their applications to use GTK+ 3 and don't want to go back. XFCE may be a good example of this.

And there are some projects which have been dropped over this insanity. LXDE is a good example of this.

This results in a fragmentation of the community to say the least. GIMP needs GTK+ 2. XFCE needs GTK+ 3. Eventually, the GNOME character map will need GTK 4. And so on. Users will have to install all of the versions of GTK required to run those programs, and this wastes memory and disk space. It may seem that doesn't matter today, but a lot of users choose XFCE because it's lightweight and they have hand-me-down hardware. These users, probably the core userbase, are thus disappointed.

As such, I have been working on a solution: STLWRT started as a fork of GTK+ 2. I have grown it into far more than that: It implements most of the features from GTK+ 2, some of the features from GTK+ 3 (enough to run some applications -- the list is growing), and can be modified to emulate almost any version of GTK. It preserves the user interface of GTK+ 2, coercing GTK+ 3 applications to warp their styles until the GTK+ 3 applications look similar to GTK+ 2 applications. It keeps the features from GTK+ 2 that users (in general) desired, and it (eventually) will be able to read GTK+ 2 and GTK+ 3 themes. It doesn't matter if you have modules from both versions of GTK -- modules for either version work fine on STLWRT, and can even interoperate.

My plan with STLWRT is, once I believe it is stable enough for other developers to try it out, I'll release it -- under the LGPL, just like GTK was.

I'm hoping the users on this forum are generally more technically oriented and will understand me better and be able to give me pointers and advice.

What does everyone here thing about STLWRT given what I've said? I'll answer further questions as they are asked. Thank you.

0strodamus · 2020-05-30 06:01:33

This sound very promising. Thanks for sharing and I hope your fork goes well!

janp · 2020-05-30 13:25:09

Very interesting, will look forward for news , thank you.

ToZ · 2020-05-30 13:30:42

The Squash wrote:

My plan with STLWRT is, once I believe it is stable enough for other developers to try it out, I'll release it -- under the LGPL, just like GTK was.

When do you think this might happen?

The Squash · 2020-05-31 17:39:36

Hey there everybody! I appreciate the interest in this project.

As for when I think I'll release it, I think it'll be early to mid July (this year, 2020, of course). Think maybe July 10th, 2020. I wish I could get it to you sooner, but I'm just about swamped with business and personal issues right now.

That's all I can write about it right now; I've got another issue cropping up right now. Sorry.

The Squash · 2020-06-01 17:51:10

I've gotten far enough with STLWRT now that I'm incrementally adding features from GTK+ 3 until the applications I want to use start working. As unlikely as it may sound, that's the Tao of STLWRT: Implement as little as possible, because practically speaking, few applications use the other features of GTK+ 3. Sure, this means developing for STLWRT is a catch-up game, but I'm hoping eventually it'll get to the point that I / we can catch up with the latest stuff the GTK project is implementing. Or really, we don't need to play catch-up with GTK: We need to play catch-up with the application developers. That's the point of STLWRT: to stop riding the GTK / GNOME / Red Hat bandwagon and start riding the application developers bandwagon.

The Squash · 2020-07-21 00:03:35

Well, it's been a long time since I posted here, so I'll bring the XFCE community up to speed.

STLWRT still can't compile yet, but don't worry -- I'm working hard at it with every last spare second I have (within reason). I uploaded the code to GitHub and keep it updated with the version I'm working on right now frequently. The code is available at: https://github.com/thesquash/stlwrt.

I thought I'd let you all know that I'm not slacking here.

ToZ · 2020-07-21 00:55:53

Thanks for the update.

CwF · 2020-07-21 03:09:55

I just did a run upgrading a debian buster image to bullseye and the some of issues were indeed the many programs wanting to keep gtk2 elements. Many related to python2 also. The bullseye/20.04 change seems to be big. Would this STLWRT be a drop in for a debian stable, or only a worked over derivative.

The Squash · 2020-07-22 21:38:38

CwF wrote:

Would this STLWRT be a drop in for a debian stable, or only a worked over derivative

First of all, understand that I intend no hard feelings toward you or anyone at all by saying this. I'm just being honest.

That said, I've been busting my behind (so to speak) to make STLWRT as backward-compatible as possible with old GTK+ 2 applications. If you go to the source code link I provide above, you can take a look at the README where I explain in more detail (I think) what are some of the issues impeding STLWRT somewhat right now.

The Squash · 2020-08-20 02:01:28

Well, it's been a long time since I last gave a status update. So here I am again.

STLWRT continues to come along, although its development has slowed lately: I've recently gotten a flood of feature requests coming my way, feature requests for GTK-based applications. Many people recognize that I am skilled at writing GTK-based applications and additions to existing GTK-based applications and I am now at the center of an endless stream of requests. I think I had better start turning down requests a few at a time, at least new requests...

(By the way, if anyone reading this happens to be someone who has requested a feature from me, don't feel put down. It's really up to me to turn down feature requests.)

More interestingly, I was searching through my records about STLWRT and found these two pictures which I hadn't bothered to post yet. The first one shows an application, the MATE Accessibility Preferences, which was compiled against GTK+ 3 but was running on STLWRT. Note that it is fully themed, using the classic Clearlooks GTK+ 2 theme engine. The second picture is probably more interesting, as everything in the picture, from the application windows to the window manager (yes, even Marco, the MATE window manager), is using STLWRT. Plus the picture shows off STLWRT's default use of classic GTK+ 2.10-era icons, which I personally think are better looking than the GTK+ 2.12-era Tango icons, at least with the default theme.

Presented with no further comment:

MATE Accessibility Preferences

STLWRT 0.0.20 in action

I tried to run some newer XFCE applications on STLWRT back then, but the design of STLWRT in version 0.0.20 was rudimentary. My (unsuccessful) trial of Thunar 4.14 on STLWRT was actually what led me to start re-writing STLWRT in a cleaner fashion, unrestrained by the clutches of the GTK+ 2 source code layout.

As always, great community and great software! I like XFCE anyways!

0strodamus · 2020-08-22 05:34:52

Thanks for the update!

Xfce Forum

Sub domains

#1 2020-05-21 20:16:13

STLWRT: The traditional brought back to life

#2 2020-05-30 06:01:33

Re: STLWRT: The traditional brought back to life

#3 2020-05-30 13:25:09

Re: STLWRT: The traditional brought back to life

#4 2020-05-30 13:30:42

Re: STLWRT: The traditional brought back to life

#5 2020-05-31 17:39:36

Re: STLWRT: The traditional brought back to life

#6 2020-06-01 17:51:10

Re: STLWRT: The traditional brought back to life

#7 2020-07-21 00:03:35

Re: STLWRT: The traditional brought back to life

#8 2020-07-21 00:55:53

Re: STLWRT: The traditional brought back to life

#9 2020-07-21 03:09:55

Re: STLWRT: The traditional brought back to life

#10 2020-07-22 21:38:38

Re: STLWRT: The traditional brought back to life

#11 2020-08-20 02:01:28

Re: STLWRT: The traditional brought back to life

#12 2020-08-22 05:34:52

Re: STLWRT: The traditional brought back to life

Board footer