GTK3 Port Progress

[sedwards]

So good news

1. Almost all UI elements are working
2. Connection to remote hosts works
3. Most options work

Bad news

1. Default sizing is wrong on the windows....this will require some tweaking
2. Transfer dialog which uses clist isn't compatible, I am having to rewrite this as a treeview
3. All of the transfer.c stuff which uses clists is beyond me at the moment, but if you can handle fixing the transfers, I can finish the rest of the GUI stuff.

[sedwards]

The major problem is that GTK Boxes are deprecated in favor of GTK Grid and getting things to line up in the correct places is proving near impossible.

I'd rather not litter the gFTP code with a bunch of IF GTK VERSION conditionals, but there may be no other way to do it if we want the GTK3 or even GTK4 ports to maintain the same basic UI and functionality.

It may be best to abstract away each function like the like the log window, the transfer window, the local and remote window and then conditionally use a box for gtk2 and a grid for gtk3/4.

More investigation will be required.

[wdlkmpx]

In GTK3, GtkTable is deprecated in favor of GtkGrid

GtkBox is not deprecated, I'll perform a massive update without breaking anything, just to reduce the number of gtk3 warnings.

For gtk4 support to happen, all GtkUIManager references should be removed, but they also removed GtkMenu, GtkMenuBar, GtkMenuItem in gtk4. Getting rid of GtkUIManager is not a simple task.

[wdlkmpx]

I added a few commits. I think the (gtk3) GtkBox warnings should be fixed now.

Yes I'll take care of the transfer window GtkCTree, it's quite difficult..

[wdlkmpx]

It is my understanding that it's possible to replace GtkTable with GtkBox,

I mean nested GtkBoxes, it takes some practice to master some widgets, one has to understand both widgets in order to replace one widget with another. That is particularly difficult for GtkCList/CTree vs GtkTreeView.

I came to realize that I need to create small apps (dialogs) in order to practice how to use and understand some widgets or glib functions, I'll create a simple dialog with a GtkTreeView with a GtkTreeStore model and a progress bar inside a GtkCellRenderer

[wdlkmpx]

I wrote a comment days ago, but I guess I forgot to click on the Comment button.

I guess I'm ready to start the process of replacing the transfer GtkCTree with a GtkTreeView. I wrote this dialog from scratch, it's a GtkTreeView with a GtkTreeStore model I guess I should use a GtkTreeView with a GtkListStore, the simpler the better, how about that?

This is how people are supposed to create menus with icons for gtk 3.10+

The thing is.. GtkMenuBar, GtkMenu, GtkMenuItem, GtkToolBar, GtkUIManager, etc no longer exist in GTK4.

The unnameable have done it again, making backwards compatibility harder and harder. Those shall not be named.

[wdlkmpx]

I'm not lying when I say that I mostly use GTK2 apps. I live in a bubble so it's kind of shocking when I read some old news that I already read years ago.. https://igurublog.wordpress.com/2014/03/22/gtk-3-10-drops-menu-icons-and-mnemonics/

With GTK2 it's sooo trivial to add icons to buttons and menus, GTK3 deprecates stock icons and access to the GtkDialog's action area. That can only mean more and more code to avoid using deprecated widgets and functions.

But the real breakage happens in gtk menus, this is how it must be done, no icons, no mnemonics.. it's shocking for Desktop users with real keyboards and monitors... https://developer.gnome.org/gtk3/stable/popup-anchors.png

Back in 2014, the unnameable caused a major breakage that makes gtk3 incompatible with itself: themes and functionality were suddenly broken, that's why apps should support gtk3 >= 3.14.

[rubyFeedback]

I'm not lying when I say that I mostly use GTK2 apps

I am in a mixed situation here. I use both gtk2 and gtk3, mostly via ruby.

I like the CSS parts in gtk3, but, oddly enough, I am not convince that gtk3 was really an improvement over gtk2. I haven't yet tested gtk4 really.

In regards to gftp, do you guys think it would be possible to keep the gtk2 port alive as well? I don't mind the gtk3 part of gftp but for visual guides, I feel that gftp based on gtk2 was actually GREAT. It was my favourite ftp client. These days I am mostly using ruby-gtk3 and use a slightly simpler layout based on gtk_grid, but I still think gtk2 was really really very useful.

As for the mess in regards to themes - well, personally I gave up on themes altogether and focus on CSS (or rather than variant gtk3 offers us). The reason is that while I can understand that you want a unified user experience, the default themes often annoy me to no ends. I have been using HTML + css for almost 20 years, so, nah, I don't need top-down themes really and I am not sure whether everyone else thinks the way how the gtk devs think. But the best solution here is really just using CSS - give people simply the power to define how they want to. For example in my ruby-gtk3 apps I use my CSS parts, and if someone wants to use their own parts, they can just do so. (We can use "id" in gtk, via set_name() - it is not the same as id in HTML but it is ok-ish for most other needs.)

GTK3 deprecating stock icons was also annoying, yep. HOWEVER had, I don't think this is the end of the world - at worst you can just use the gtk2 apps and distribute them via gftp too. I use emojis/unicode as surrogate to some extent; not perfect either, but even upstream gtk3 devs being annoying is not the end of the world. I just feel that the improvements in gtk3 were not really worth the trade off. My main editor is still bluefish 1.x by the way; I tried to use bluefish 2.x but the changes killed my productivity. One day I shall aim to recreate all these oldschool gtk2 apps via ruby-gtk2. :)

(CSS is a great addition though; I'd wish we could have that in gtk2 as well...)

[wdlkmpx]

Well C is pretty low level compared to other languages / bindings. It's possible to support all gtk versions with a single codebase, but that requires a genius.

The simpler the app, the more likely to be ported to gtk3 while keeping gtk2 support.. I've done that with 3 apps already... 3 simple GTK games.

I always try to support gtk 2.14+ or (2.10+) and with my gtkcompat.h I keep the code readable for other people that don't want to deal with deprecated gtk2 code, there are some gtk3+ functions in the gtkui code, but gtkcompat.h ensures that a gtk2 compat function is used, but it's not enough for Menus for examples, that's when 700-1000 lines will be added if GMenu/GtkApplication/GtkBuilder is to be used for gtk 3.10+.

GTK4 introduces and forces too many incompatible changes. This is not very noticeable in very small and simple apps, where miracles can be achieved with hard work and determination, but GFTP is big enough and it will be as painful as the transition from GTK1 to pure GTK2 without deprecations (task still not finished after 1 year).

For example GTK4 removed the GDK_THREAD stuff, that's one of many blows to gFTP, which is a threaded application.

That's why apps should be as simple as posible while keeping all the essential and important features. We're alone and trying to do exactly the opposite of what the unnameable orGanization does.

[wdlkmpx]

I think the app needs a Status Bar where global transfer info is reported.

And the "Transfer Window"... is just a simple list with details about the specific transfer. And includes a nice progress bar in one of the columns and the icon changes when the transfer is active.

That looks like a good idea. I'll try to implement that. After that I guess the GTK3 port will compile.

Overall, I think pure GTK code is a nightmare to work with, there must be a layer above, to avoid applying the same long and dramatic changes to whole projects and instead call something like this:

gtkutil_menuitem_new (a, b, c, d, e, f, g, h, i)

Just create a menu item with a label, b accelerator, c callback, d icon, e check_state, f menu, g submenu, etc. I don't care how you do it, just do it..

[wdlkmpx]

The main problem with replacing the Transfer Window GtkCTree stuff is that the GtkCTreeNode equivalent is not a pointer but a opaque structure that must be filled after calling a function, and a GtkTreeIter becomes invalid when tge rows change.

I don't know other projects handle this situation, but I basically rewrote the Bookmarks GTK stuff, and it's a bit limited compared to what the GTK1 version used to allow. But while the Edit Bookmarks dialog is running everything is done using GtkTreeStore/GtkTreeModel functions, and this is converted to a GHashTable/singly linked list (tree) after applying the changes.

So the problem with the transfer stuff becomes apparent, as it uses the underlying gftp UI common that provides a gpointer to store references to nodes.

So it takes years to understand and work with a GtkTreeView and just when you think you can do things with it, the GTK team will announce that your knowledge is invalid, and developers must have infinite time to learn how to use new widgets and concepts every 2 major releases.

https://blog.gtk.org/2020/06/07/scalable-lists-in-gtk-4/

And, to be clear, it also does not mean that we are removing treeviews and combo boxes from GTK 4—it is too late for that, and they are still used in many places inside GTK. That may be a GTK 5 goal.

[wdlkmpx]

The more I learn about GTK, the more I think I'm wasting my time. The level of anger is over 9000. I'm sure many people stopped developing their app when they saw they needed to rewrite it, not just fix it or adapt it to a newer GTK version.

You have to learn how both the new and the old widgets work, and also other related widgets that must be replaced at the same time, some changes are so huge and complex that it's a rewrite. And that's my experience with every single app I updated to compile with GTK3. So far I have not been able to finish the gtk3 port of really complex/large apps.

Stuff has also been moved to glib2, so the threading stuff will need to be rewritten or redesigned. GtkApplication allows only 1 menubar, what a joke.

In GTK4 they also removed widget signals: https://developer.gnome.org/gtk4/stable/gtk-migrating-3-to-4.html#id-1.7.4.3.14

The reference manual states that the way to port from gtk2 to gtk4 ... can only happen by porting to gtk3 first. No surprise there. https://developer.gnome.org/gtk4/stable/gtk-migrating-2-to-4.html

For every GTK major version, removing deprecated code = some major rewrite, so there needs to be a toolkit above the GTK toolkit to bypass such a horrible situation.

So I request permission to do whatever I please with the GTK UI (and the whole codebase)...

[wdlkmpx]

Talking about progress, a quick look to GTK video players reveals a truth that nobody wants to know, they're all incredibly basic.

https://linuxreviews.org/GNOME_Videos https://linuxreviews.org/Parole https://linuxreviews.org/Celluloid

There was one GTK video player that was packed with features, but it has fallen into the darkness, and it's quite hard to update and fix without removing basically everything.

This explains why a gFTP feature is hidden in the GtkComboBoxes, to trigger it, a special technique must be used, with the old GtkCombo it all happened naturally, and it's no longer possible without a special technique.

[MartinX3]

currently in arch linux gftp is the only package forcing me to keep the gtk2 package installed on my system.

@wdlkmpx what's the current status of replacing every gtk2 peace by gtk3?

[wdlkmpx]

@wdlkmpx what's the current status of replacing every gtk2 peace by gtk3?

Hmmm it will happen and I think gtk3 will be the end of the line for gFTP, with many deprecation warnings of course.

I was expanding my gtk stuff while editing other projects, so massive changes will be applied to gftp all at once, but recently I've been busy with command line apps, forking like 20 projects and unifying all of them into a single app. It really takes a long time to edit, simplify and unify C code but I'll be back to gftp the next month probably

[MartinX3]

Hmmm it will happen and I think gtk3 will be the end of the line for gFTP, with many deprecation warnings of course.

I was expanding my gtk stuff while editing other projects, so massive changes will be applied to gftp all at once, but recently I've been busy with command line apps, forking like 20 projects and unifying all of them into a single app. It really takes a long time to edit, simplify and unify C code but I'll be back to gftp the next month probably

I would take the first 2 projects and externalise common things into a lib project, which gets included as a git submodule.

Then take the next project to port and refactor the lib project again until you added all projects to this lib project. That results into a steady process of refactoring your projects.

Btw now it's gtk 4.6.3.

And have fun with your projects I avoid C (and C++/PHP/Go) as languages. Maybe Rust would be good for me, but I'm used to kotlin and typescript.

[wdlkmpx]

Btw now it's gtk 4.6.3.

Actually 4.6.5, but I really doubt gftp will ever be ported to gtk4, even porting it to pure gtk3 without deprecations seems somewhat unfeasible, well, at least to me. Some people might have read my extensive rants in the last 2 years, I just think gtk is a dead end for (mildly) complex projects... and heavily threaded projects, the toolkit is being increasingly bastardized, so there's no motivation to learn gtk4.

Having said that, I'm still using a custom distro I last built in 2019 with 2017 (debian) core components, so I'm trying to figure out what distro should I use next, Alpine Linux sounds like a good base to create a live distro, that way I can test if something builds with gtk4. I'm going slightly mad

[MartinX3]

I'm using Arch Linux on my Servers and EndeavourOS on my Computers.

Btw how about going Qt?

[wdlkmpx]

This branch contains preliminary work to finish the gtk3 port, it's somewhat old, but it can be finished anytime https://github.com/masneyb/gftp/commits/gtktreeview

I had philosophical & technical issues while trying to implement the transfer window gtktreeview, the first thing that came to mind is that lftp is basically what gftp-text could become in the distant future https://en.wikipedia.org/wiki/Lftp

In this branch there are some ported patches from the fangq repo that add extra buttons, everything that works is already ported to the upstream repo I think https://github.com/masneyb/gftp/commits/fangq

[keithbowes]

The more I learn about GTK, the more I think I'm wasting my time. The level of anger is over 9000. I'm sure many people stopped developing their app when they saw they needed to rewrite it, not just fix it or adapt it to a newer GTK version.

It's generally better to use Glade to make the UI. That way whena new version of GTK comes out, your UI files can be automatically converted. I created my own fork of obmenu, which was written in GTK 2 using Glade files. I was able to convert it to GTK 3 and then to GTK 4 very easily. The current code has both GTK 3 (obmenu.glade) and GTK 4 (obmenu.ui) files, but I'm thinking of just removing GTK 3 support instead of keeping two separate Glade files and some occasional differences in the API. (Far harder than getting it to work with GTK 3/4 was getting the code to work with Python 3; originally, I just got it to working with GTK 3 in Python 2.)

Though, I do wish that the GTK devs would just leave well enough alone wrt to the API. Some changes in GTK 4 I understand, like making menus and clipboard access less X11-centric, but some others seem silly. Wlroots does the same thing: every version the API changes and often for no good reason, so every time a new version of wlroots comes out, you have to change (usually a lot of) your code and release a new version, even if little if anything was done to your compositor's codebase.