Xfce Forum

Sub domains
 

You are not logged in.

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

The Squash
Member
Registered: 2020-05-21
Posts: 5

STLWRT: The traditional brought back to life

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.

Offline

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

0strodamus
Member
Registered: 2014-01-22
Posts: 27

Re: STLWRT: The traditional brought back to life

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


archlinux | OpenRC | TOMOYO Linux | Xfce

Nihil Verum Nisi Mors

Offline

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

janp
Member
Registered: 2016-02-05
Posts: 17

Re: STLWRT: The traditional brought back to life

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

Offline

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

ToZ
Moderator
From: Canada
Registered: 2011-06-02
Posts: 6,863

Re: STLWRT: The traditional brought back to life

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?

Offline

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

The Squash
Member
Registered: 2020-05-21
Posts: 5

Re: STLWRT: The traditional brought back to life

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.

Offline

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

The Squash
Member
Registered: 2020-05-21
Posts: 5

Re: STLWRT: The traditional brought back to life

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.

Offline

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

The Squash
Member
Registered: 2020-05-21
Posts: 5

Re: STLWRT: The traditional brought back to life

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.

Offline

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

ToZ
Moderator
From: Canada
Registered: 2011-06-02
Posts: 6,863

Re: STLWRT: The traditional brought back to life

Thanks for the update.

Offline

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

CwF
Member
Registered: 2018-01-28
Posts: 68

Re: STLWRT: The traditional brought back to life

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.

Offline

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

The Squash
Member
Registered: 2020-05-21
Posts: 5

Re: STLWRT: The traditional brought back to life

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.

Offline

Board footer

Powered by FluxBB