GTK3 support

[vanillajonathan]

Add support for the GTK 3 toolkit.

[wjaguar]

The code reorganization is done, adding a GTK3 backend to vcode.c is now largely trivial. But I'm myself at the moment busy with real life, so if no one else contributes the code, the implementation will have to wait till better times. :(

[JotaRandom]

I was reading GNOME docs related to GTK4+ and for GTK3 3.22 (or 3.26 depending on the source and page) is a "LTS" where 4.0 (and again or 4.6) is supposedly the next major target, yet initially GTK4 is scheduled for 2019-2020 and then 2 years for every new major GTK+ version so unless you think you can have GTK3 sorted before 2019-2020 better target GTK3.99 for GTK4 (like what GIMP look like will ended doing).

[wdlkmpx]

For GTK3 support to happen all the GTK1 code must be removed, all GTK2 deprecations should be replaced with pure GTK2 alternatives.

The projects supporting GTK1 are basically unportable to GTK3, because many GTK1 widgets no longer exist.. the codebase would be a complete mess.

Even porting a project to pure GTK2 without deprecations is something really incredibly difficult.

The path to GTK3 can be really long and painful and GTK3 support may never happen.. the gFTP project's GTKUI has been mostly rewritten and still cannot be ported to GTK3.. mhWaveEdit's fork 'gWaveEdit' might never achieve GTK3 support.

If GTK3 support is to be added, I'd suggest port everything to GTK 2.24 (the minimum supported version) before any attempt to add gtk3 support is made.

[wjaguar]

As to what need be done, you are exactly right.
As to what was done to let GTK+3 neatly coexist with GTK+1 and GTK+2 as a third option despite all that, it is the V-code engine (vcode.c)

The 3.49.xx branch does not refer to any "GTK1 widgets", or any GTK+ widgets whatsoever for that matter, anywhere outside vcode.c and its supporting mygtk.c ; the "V-code widgets" it uses instead, are abstract enough to work in console mode being driven by script statements.
IOW, there is no place left for any mess, much less a "complete" one, to develop; any newly-missing widget just has to be very superficially simulated in exactly one single place. The only reason this hasn't been done years ago as per initial plan, is that real life intruded; and with no one else working on the code, things ground to a complete halt for some periods.

[wdlkmpx]

Gtk1 and Gtk2 share many widgets Gtk2 and Gtk3 share many widgets Gtk3 and Gtk1 share few widgets What does that mean? If a project is supporting both gtk1 and gtk2... it probably is using many deprecated gtk2 widgets. Gtk3 support basically implies reimplementing everything. And that's what I'm probably seeing in mygtk and vcode Gtk3 support will include huge #ifdefs because because it doesn't use the common code that gtk1 and gtk2 share. However gtk2 and gtk3 do share many widgets and objects, but gtk2 deprecations include many gtk1 widgets. It doesn't matter the file, gtk2 introduces many new widgets that replace the old gtk1 widgets. Removing gtk1 support is just the first step, because removing gtk2 deprecations is the biggest task, it's a rewrite.

[wjaguar]

Using own brain to think is the first step. This isn't D&D, repeating magic words doesn't change reality.

For "reimplementing everything", you have to be using everything. No one ever does. And if you think about it, a program driving any widget wants only a very few fairly abstract things of it; display some value in, get new value out, maybe also modify the representation, and/or subscribe to notices of some type of changes. What exactly is happening there under the hood when it does, is an irrelevant technicality.
A totally different widget, or several, or no widget at all, giving sensible reactions to those very few requests, is a perfect drop-in replacement as far as everything outside vcode.c is concerned. As is exemplified by mtPaint happily running in commandline mode with all its "GUI code" doing its job without seeing any difference.

When deprecations count not against uses of widgets but types of them, they are not a problem. It is the differences in handling non deprecated ones which need be compensated for, that are tedious; as in having to review all the 1200+ calls to GTK+ to see if the function got replaced by a differently named one.

And if vcode.c gets a few more #ifdef's and #define's than now, so what?

[wdlkmpx]

You haven't tried to add gtk3 support, I assume you're quite knowledgeable and it won't be hard for you to add about 7000 lines. These old and unfortunate projects don't even support gtk2 properly. Other projects implement classes and stuff, reusable code and it still takes years to bring gtk3 support because the developers won't let gtk1 die in peace. Those of us who rarely use, read or write C code somehow manage to do more sacrificing some old junk. Edit: fixed typos.. phone

[wjaguar]

Naturally it won't be hard; tedious, surely. Lines to add I estimate at 1000, tops (it's quite improbable the few parts-to-reimplement could grow in size 7x, now isn't it?); it is the lines to review that are boooring. :)

As to the rest of your verbiage, I'm unsure whether you've come here to whine, or boast; in case it's the latter, please point me to your reason for it.

[wdlkmpx]

I'm sorry I didn't think twice. It's basically to whine and boast. But my intention was a bit different but I ended saying something else. I've been reading code that is probably a bit more outdated, but share the same principles.. deprecated gtk2 + gtk1 = 85% gtk1 / 15% gtk2. The gtk3 code path implements completely different methods, and adds many more lines. To be able to move stuff forward people must be gtk gurus, because not even the current deprecated gtk2 code applies to gtk3.. multiply the difficulty * 20 widgets, 50 events, 300 casts, and so on. Most people follow this logic: delete really ancient code and slowly remove deprecated stuff, when the time comes to add support gtk3.. it will be hard but not a PITA. There's a reason non-gnome projects are still in 2010. But I'm sure some #defines can be added to workaround some issues.

[wdlkmpx]

Keeping ancient code also makes it difficult for new developers that might not understand things that happened before they learned to walk. So it all comes down to mindlessly trying to add a new gtk port, I don't think there are many C+gtk coders and the few that are left are probably busy with some gnome or mate project. I'm not a C coder and I'm struggling to understand GTK, but I already edited probably 10 000 lines of C code just to update some apps I use, without really understanding what I'm doing hahaha

[wjaguar]

To do anything with any GTK+ reliably, people "must be gtk gurus", for the sad reason that the thing is buggy, in different ways in different versions. In mtPaint I do quite a few conditional workarounds for various things.
To make things in GTK+1 work not much worse than in GTK+2, it is double that; one has to read both codebases, and sometime add sizable chunks for something which in GTK+1 just is not there. #ifdef'ing them out in GTK+2 where the same can be done natively in a few lines.

After dealing with that, GTK+3 is just more of the same.

[wdlkmpx]

That's true, but some bugs might be fixed in newer revisions who knows. And after 15 years I think it's mostly safe to raise the minimum requirements, it's not that gtk apps are adding more and more features every year, in fact the opposite might be true for most projects... gnome-mplayer, it probably had 30000 lines of code, after I deleted about 15000 lines it started to behave properly in gtk2 and gtk3 And adding more features looks like a bad idea unless the one who understands all supported gtk versions is doing it. I see that people trying to update gtk projects are mostly doing it out of desperation. Someone tried to update mhwaveedit in 2017 and after spending a few months he came to realize that it was too much work. a few days ago I decided to continue his work and fixed a couple of issues I found and added a ton of changes to the whole project, but the change from GtkObject to GObject introduces bugs that I'm not able to understand or fix at the moment.. if I become busy I'll just forget everything I learned and perhaps someone else will continue the good deed

[wjaguar]

The core problem has not changed any in those 15 years. GTK+ itself is adding more and more cruft year in and year out, with hw struggling to catch up. People who still use GTK+1, usually do it for the reason of some kind of weak device. The niche of image editor for such devices is mtPaint's and always was.

Understanding all supported versions is a must for equalizing behaviour on them, yes, but it is always a work in progress; some corner cases may lurk for years and years in depths of UI before getting noticed. :)

As I see it, people trying to "update" GTK+1&2 projects mostly do it from a misplaced belief that "newer == better"; the maxim "If it ain't broke, don't fix it" need be studied diligently and meditated upon. :)
One valid reason is to do it as a technical challenge, but any loss of functionality (including compatibility) is a failure then.

[wdlkmpx]

I understand all of that, and I'm aware there's very weak hardware, although I no longer have such hardware, even a Pentium 4 is quite powerful.. but maybe a raspi 1 is slow enough. Gtk1 = windows 95 Gtk2 = windows XP Gtk3 = windows 8 Gtk4 = windows 10 There's not gtk windows 7 because gtk is not worthy. Some old apps were indeed broken, or partially broken, too much gtk1 in a gtk2 app that it _started to segfault_ at some point (gmrun). Or even though they worked before, many features got broken somehow... how to fix this old stuff.. by deleting code. I've seen several apps with broken features, that was my motivation. Indeed it's a technical challenge, I personally don't need gtk1 apps, never needed them... never used them, and gtk2 is the base for me.. the problem is this: many old apps are basically gtk1 with enough stuff to make them work with gtk2 http://gtk2-perl.sourceforge.net/doc/porting.html GTK+ changed fairly substantially from version 1.2 to 2.0, much more so than from 1.0 to 1.2. Subsequent updates (possibilities are 2.0 to 2.2, 2.2 to 2.4, then to 3.0) will almost certainly be much, much smaller. Nonetheless, most programs written for 1.2 compile against 2.0 with few changes. The problem is porting gtk1 to gtk2... sometimes it's not possible, it's like rewriting an app.

[wdlkmpx]

And I must say that GTK2 is the best gtk version by far, it has many features and advanced widgets.. GTK3 makes widgets dumber and deprecates some essential functionality. In the case of many old apps, we're basically seeing gtk2 apps with gtk1 widgets, and it looks a bit precarious, the difference between GtkCList/GtkCTree vs GtkTreeView is that GtkTreeView looks more pro, it's way more powerful and responds to more events (right click). So overall, GTK2 is a huge improvement over GTK1 And GTK3 introduces many regressions compared to GTK2. GTK4 will be an abomination for sure. So overall, GTK2 is the only gtk version that must be supported properly, to its full potential...

[wjaguar]

Actually mtPaint's baseline is GTK+ 2.4 (what the first version was developed on) with some features newer than that taken advantage of if not forbidden at compile time; GTK+ 1.2 is supported as far as technically possible, and that's it.
The use of GtkList and GtkCList instead of GtkTreeView has three causes; first, despite all their bugs, the first two were at least left alone ("deprecated", see) while churn in GtkTreeView went on and on and on. Bugs you know, you can work around once and forget about; bugs randomly thrown at you, not. Second, GtkTreeView was really dog slow for large lists (such as in file selector sometimes). And third, it is not a container so has no settable border. :) Which deficiency may not seem like much, but is a very nasty thing to work around; as the widget is scrollable, and cannot integrate with GtkScrolledWindow through a container. (Now investigating what the easiest workaround would be for GTK+3.)
P.S.: Workaround is 23 lines but required some digging to find what in the manual works for real. As usual.

[wdlkmpx]

To finish my incendiary discourse. I've seen several projects change drastically in the transition from gtk1 to gtk2.. that's not necessary unless you're thinking about porting to gtk3 and find that almost 90% of the gtk code is not even compatible with gtk2 without deprecations.. the first step towards gtk3 support, Without reading a porting guide, it was clear to me that GtkCList/GtkTree (icons, nodes and text) -> GtkTreeView would be really traumatizing. In my insane efforts I added probably 1700 lines to a project with pure gtk2 code to replace gtk1 code (almost the same amount of lines were deleted).. and it probably needs about 600-1000 new lines to handle the GtkCList/GrkCTree transition to GtkTreeView. And who knows what other widget is waiting to be ported. So... I can't help thinking that adding a gtk3 port without even trying to update the gtk2 code.. would require a gtk guru of the highest order. And thanks to mtPaint I converted some xbm icons to png and deleted about 245 lines that dealt with bitmaps adding transparency or something. Thanks mtPaint

[wdlkmpx]

As I try to understand things and find potential fixes to bugs introduced by severe changes (gtk1 -> gtk2).. this is some invaluable advice: There is another player that becomes as important as Gtk: Glib2. Gtk2 2.0 introduces GObject (Glib2) and deprecates GtkObject. During gtk2 lifetime, the gnome guys deprecated many widgets that originated in gtk1 and stuff that originated in gtk2 as well, they also introduced a few more widgets. By the time gtk2.24 was released, gtk2 already had many features and stuff that is part of gtk3... while retaining backwards compatibility. But Glib2 continued to evolve and you have to understand both libs equally... https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#g-clear-object I said this to several project leaders: gtk2.24 + glib 2.32 = ubuntu precise , slackware 14.0 The new base for the new era. Glib2 continued to deprecate many functions and stuff. And the same glib is used for gtk2 and gtk3. And that's how some apps get broken or hopelessly out of date. They also deprecated some gdk stuff in gtk2.. and you must learn cairo instead. You can do a thousand things and once you finished updating to gtk 2.24, gtk3 can be just another port... hidpi and wayland support. Gtk4 can wait until 2030. Cheers.

[wdlkmpx]

https://developer.gnome.org/gtk3/stable/ch26s02.html#id-1.6.3.4.15 So it seems that in GTK2 everything related to GtkObject was deprecated, except the GtkObject class, which derives from GObject. In gtk3, GtkObject no longer exists and everything was moved to GObject and GtkWidget adquires the destroy signal. https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget-destroy Changing GtkObject to GObject or GtkWidget is confusing as hell https://stackoverflow.com/questions/9667517/gobject-gtk-gnome-gtk-gl-gtk2-gtk3-i-dont-understand It starts to make sense, I guess that's why I have no idea how to fix stuff. But changing all the references from GtkObject* to GObject* is a big change in itself and indeed a define would do trick or something.. FYI..

[wjaguar]

As one sleepy brown bear once said:
"If ye find that the Bullock can toss you, or the heavy-browed Sambhur can gore;
Ye need not stop work to inform us; we knew it ten seasons before."

[wdlkmpx]

Imagine, if the path from gtk2 to gtk3 is confusing enough, imagine new developers seeing gtk1 along the gtk2 and gtk3 code trying to add gtk4 support. Confusing is the key. Confucius knew about this. This classified knowledge is actually known by few people. Some gtk developers of the past don't know how hard it would be to port something to gtk3, even in small apps with wrappers in everything. And when it comes to develop gtk apps, C is probably now the least used language.. a single app is treasure that will not happen again.

[wjaguar]

Once again, you need to understand the concept of separation between application logic and UI representation. If a developer mixed the two up, then yea, throw a different widget toolkit at him and watch the descent to madness. :) But when the two neither know nor care about each other's specifics, either side can be changed with total ease.
This is why V-code reigns supreme here. :)

[wjaguar]

Rememberest thou well this my wisdom; it is not the variations in names thou needst fear, nor widget replacements. It is undocumented changes under the hood.
Behold and admire: https://mail.gnome.org/archives/gtk-devel-list/2013-May/msg00011.html
Note that GtkPixelCache is NOT exported by GTK+3; to work around the issue, you have to roll your own.
The two-paragraph sidenote "Scrolling" lurking in "The GTK+ Drawing Model" can serve for a vocabulary definition of "glossing over".

[wjaguar]

Option added in 3.49.25 - "./configure gtk3"