I have a two questions

[ghost]

1. Would in the future there be a possibility of full compatibility with all GTK2 and GTK3 applications?
2. What is your goal for GTK themes? Support only GTK2 themes? Only GTK3 themes? Or both?

I'm considering in the future maintaining personally either GTK2 LXDE or an older version of XFCE, either on this account or a different one. I think this project will be a big help when and if I do so. Thank you.

[thesquash]

1. In short: Yes. I'm actually spending an "insane" (notice the quotes) amount of time setting STLWRT up so that it can work with not just GTK+ 2 applications, but GTK+ 3 apps and hopefully later ones too. Planned is GTK-MM support too to bring C++ bindings to STLWRT, so you can run apps like the GNOME or MATE System Monitor. Specifically, my plan is (not out of disrespect but for ease of programming) to support all but the oldest features from GTK+ 2, and add features from GTK+ 3 as necessary to run one application or another.
2. For starters, GTK+ 2 themes should work out of the box. GTK+ 3 themes use CSS, and STLWRT doesn't have support for CSS just yet. Nevertheless, at some point there will be a need to implement CSS support and I hope to do so, though it will not be in the first stable release or even the second, I can tell you.

Good luck with your endeavor/endeavour maintaining GTK+ 2 LXDE or GTK+ 2 XFCE -- at least I know that this project can be useful... I mean, I always know this project can be of use, but I often let it slip my mind temporarily.

[ghost]

Will you be maintaining gtkmm (The C++ bindings for GTK) as well? Or is this GTK (as in the C version, not the C++) only?

[thesquash]

I have plans to have GTKMM bindings for STLWRT as well. I don't see why I wouldn't maintain them as well.

[ghost]

Will stlwrt require the large amount of dependencies associated with GTK3 and GTK2 to a lesser degree? I'm hoping this project isn't as beefy as GTK3 currently is. Will static linking be supported as well?

[thesquash]

Not to dissent, but GTK+ 2's dependencies really aren't that great per se. The dependencies I can think of right now are: the X11 libraries (in order to display stuff), Pango (for text rendering), Cairo (also to display stuff; layered on top of the X11 libraries for the most part), GLib (for cross-platform IO and pseudo-object-orientedness), GDK-PixBuf (for rendering images), and ATK (for accessibility support). OK, and there's also CUPS (for printing support) if you or your distribution builds that part. I really can't do without anything but ATK and CUPS in STLWRT; my plan is to modularize STLWRT so that distributors can put select features of STLWRT into separate packages, so that users aren't always stuck with accessibility support or CUPS.

GTK+ 3, however, is beast-like, admittedly. For starters, it always insists on pulling in Epoxy (for cross-platform OpenGL rendering); on a Linux system, that always means pulling in Mesa or some other implementation of OpenGL as well. That can get big. Another problem is that GTK+ 3 is built with megabytes of built-in theme source code so that you can get a GNOME-istic desktop without installing themes. (Yay! :rolls_eyes:) These are kind of annoying dependencies and I have no plans whatsoever to require them in STLWRT. Now, eventually there may be an OpenGL module that pulls in Epoxy. But you must give your clearance before the module is pulled in.

And GTK 4 (even though you didn't mention it, it is a reality now, albeit a laughing stock at present): There's no beating it really in design stupidity. Thanks to various "feature" additions, the main library all by itself (not including dependencies!) is ~30 MB. Plus, good luck getting it for your distribution yet. Even the (relatively) cutting-edge Gentoo has masked GTK 4 over grounds that it's too unstable for use.

OK, I'll admit: Even on GTK+ 2, Pango pulls in HarfBuzz (for font glyph shaping for languages such as Arabic), which now often pulls in the International Components for Unicode for C (icu4c). That's pretty bulky. But it's not really GTK's fault per se.

So in short: I pledge to modularize STLWRT as much as possible, but there is a limit to what I can reasonably be expected to do. Contributions are welcome, however!

[thesquash]

Oh yeah -- and static linking: I've read reports that GTK couldn't be statically linked and that it segfaulted whenever you tried to statically link it. I don't know the cause of the segfaults. However, once I have a working version, I'll check into fixing that on STLWRT.

[vitacell]

Oh yeah -- and static linking: I've read reports that GTK couldn't be statically linked and that it segfaulted whenever you tried to statically link it. I don't know the cause of the segfaults. However, once I have a working version, I'll check into fixing that on STLWRT.

Look at glib:
https://suckless.org/sucks/
https://bugzilla.gnome.org/show_bug.cgi?id=674446
https://bugzilla.gnome.org/show_bug.cgi?id=768215#c16

[thesquash]

I read those links, and I still don't think GLib and other libraries can't be statically linked; quite frankly, I personally think those comments against GLib in general are somewhat merited, but highly and unnecessarily argumentative at the same time. I think the fine people at Suckless have a point, and I generally agree with them; however, I still believe GLib is better than the alternative and we can make it work.

[wdlkmpx]

There should be a glib2 alternative that implements the same api, no wonder QT is light years ahead, excellent cross platform support, static linking... huge binaries that don't need a mini distro installed and so on.

The Gnome devs have destroyed the development of many GTK apps, the whole thing should be forked including all dependencies maintained by the Gnome team, to prevent further destruction of the linux desktop. Such was the damage.