hexchat
hexchat copied to clipboard
hexchat
Port to gtk3
I'm not able to, I contribute on downstream packaging but I can't code that much. I didn't want to be rude, I just think it's important and I found no specific issue on porting to gtk3.
I believe it's just a lot of effort to move everything across. Feel free to fork and maybe I'll help out too!
menu.c is needs some work and xtext.c needs a ton of work.
If somebody wants to rebase https://github.com/hexchat/hexchat/tree/xtext-cairo
Or ideally rewrite based on the improvements here: https://github.com/leeter/hexchat/blob/cpp-dev/src/fe-gtk/xtext.cpp
Well to me, it seems that upgrading to GTK3 at this point is not a worth while target. GTK4 should be the target of any rewrite if it were to happen. This would definitely require some maintainer blessing though.
@tristan957 IMHO we should identify which parts talk to GTK and have them in some sort of feature/bugfix freeze so that any and all work on them will concentrate on porting those parts to GTK4. Just my opinion.
I think one of the larger things holding back a port is the main widget for the text which I think is a GTK2 TextView. I remember @TingPing had some reservations about using a GtkListBox.
The current textbox is a 100% custom mess. It has in the past had a direct port to GTK3 but is such a mess that it was full of bugs and performance issues.
At this point in time I personally have no interest in ever doing this task but my thoughts on the best path forward are probably to make an entirely new GTK4 widget. I wouldn't stand in anybodies way if they want to do that (as long as they ensure it functions on Windows).
Unless somebody plans on stepping up and doing this work I don't think this issue should be constantly bumped.
Well Matthias has those blog posts about GTK4 custom widgets. I'll try to look into checking out what the current widget is, and see how a maybe a GTK4 solution could look. Right now my mind is totally in GtkListBox implementation mode, so maybe looking at the GTK2 widget will get my mind churning with a different idea.
You should consider (at least on Linux) using STLWRT instead of GTK. GTK doesn't have a future outside of GNOME.
EDIT: interesting read: https://ubuntu-mate.community/t/horrible-gtk3-gnome-ui-design-is-leaking-into-ubuntu-mate-applications-in-20-04/22028/57
How can anyone use STLWRT when it has no website, no documentation, and not even a build system? Seems like vaporware to me.
GTK doesn't have a future outside of GNOME.
This isn't even true. GTK has a brighter future now than ever before. GTK supports mobile platforms very well through libhandy, and has seen a lot of work on its win32 and macOS backends.
It's a fact that GTK has no future outside of GNOME.
Those willing to create a GTK4 port bypassing GTK3 will find that they have to rewrite the whole app.
It is obvious you have not ported an app from GTK3 to GTK4. Unless you are creating custom widgets, the APIs are very similar. There are new concepts to learn like controllers and gestures, but every major version of every piece of software ever written uses major versions to break APIs usually to make them much better and in this case the GTK developers made absolutely the right calls. Plus you have the removal of GtkContainer, but the docs are so stupid simple that a caveman could do it. People who exclaim "No one uses GTK outside of GNOME; No one will port their app to GTK 4; No will do X" are generally close-minded like yourself and don't know what they are talking about. If you have nothing constructive to say, just don't say anything. Open source software and more specifically the Linux community are some of the most toxic areas on the internet. This thread is really no different.
Ok this is the golden rule. You do not bypass GTK3 while porting from GTK2 to GTK4.
Superb GTK apps like Geany have GTK2 and GTK3 ports, and compile in old and new distros, it's not that hard to do something like that in an app that deals with pure text like HexChat.
GTK3 is highly compatible with gtk2 but also introduces many incompatible changes that will be enforced in GTK4.
Adding GTK4 support to complex gtk apps is not feasible without dropping gtk2 support... the good guys have removed GtkMenu, GtkMenuItem*, GtkToolBar*, GtkUIManager, GtkContainer, gtk_main(), and so many things that the code will have to change drastically.
All those widgets exist in GTK3 and GTK2, but GTK3 introduces GtkApplication and GtkUIManager is deprecated in favor GtkBuilder.
So GTK3 allows developers to build a GTK application in a GTK2 style or a GTK4 style.
Many non-gnome C gtk apps are still GTK2 or GTK1, only a few selected gtk apps are GTK3, some other apps were ported to GTK3 by some volunteers who forked the projects, but the status is alpha or beta. Most non-gnome C gtk apps will not be ported to GTK4, it was painful enough to make it compile with gtk3, and people will say: "enough is enough".
Even when someone knowledgeable takes over development, it's not enough, because people have different views on how things should be done.
It's really not hard to move things forward, but requires a lot of time, and a struggle with others will ensue,
I guess is only a matter of someone saying, "I'll do this, I know I can, just accept my PRs".
Proper GTK3 support will take some time, if the developer gives up, the port will be unusable.
Other projects slowly add gtk3 support while keeping gtk2 support through ifdefs and allow people to build both ports for testing, just in case everything goes wrong.
Tristan will be the one, the chosen one, the gnome guy who will bring things up to date directly from gtk2 to gtk4, ignoring what other people who have dealt with and edited thousands of C gtk code lines said.
He is the one :D
From what I'm seeing, while it's feasible to upgrade hexchat from gtk2 to 3 and then to 4 (following the migration guide from the gtk development docs) I wonder if it would be more feasible to start one from scratch, fe-gtk4 anyone? Would also give a chance to modernize the interface a little while still keep the hexchat charm. Though honestly, I'd love to hear from @TingPing on his thoughts now that gtk4 is out. I know I'd love to help out where I can with some code regardless the route taken.
I do not find this thread to be productive at all but I'll just leave my point.
All of these technical questions frankly don't matter. This task is just big enough that no drive by committer is going to do it. This is the amount of work that requires an experienced developer dedicating a lot of time to this project.
In that past that was me and my preferred approach was starting clean (https://github.com/tingping/irc-client). However years have passed, my time was diverted, and my priorities in life are elsewhere.
I have no plans at all to make or even review large changes to HexChat.
I do not find this thread to be productive at all but I'll just leave my point.
All of these technical questions frankly don't matter. This task is just big enough that no drive by committer is going to do it. This is the amount of work that requires an experienced developer dedicating a lot of time to this project.
In that past that was me and my preferred approach was starting clean (https://github.com/tingping/irc-client). However years have passed, my time was diverted, and my priorities in life are elsewhere.
I have no plans at all to make or even review large changes to HexChat.
Then based on this comment, can we have this issue closed?
In the meantime, GTK4 was released and the support for GTK2 has ended. https://blog.gtk.org/2020/12/16/gtk-4-0/
Another advantage of GTK3 for many users will be Wayland support.
Maybe a fork to FLTK would be more appropriate? GTK and Qt seem to be getting bloated these days.