SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
SoylentNews
GTK 4.0 Toolkit Officially Released
GTK 4.0 features new widgets and reworks to existing elements, integrated media playback support, GPU acceleration improvements like work on its new Vulkan renderer, and better macOS support are some of the leading highlights. Some other additions include data transfer improvements, overhauling shaders, GPU accelerated scrolling, custom entry widgets are easy to make, OpenGL rendering improvements beyond the Vulkan work, restoring work on HTMl5 Broadway, better Windows support, and more.
GTK 4.0 is now considered stable for applications to begin supporting it. GTK 3 will continue to be maintained for the "foreseeable future" while GTK 2 is no longer going to be supported beyond one more point release.
This discussion has been archived.
No new comments can be posted.
GTK 4.0 Toolkit Officially Released
|
Log In/Create an Account
| Top
| 18 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Cole's Law:
Thinly sliced cabbage.
(Score: 5, Informative) by Unixnut on Thursday December 17 2020, @12:11PM (9 children)
It is a shame they are retiring GTK2, it is the last GTK toolkit that can integrate nicely with non Gnome desktop environments, like fluxbox (which is what I use).
I tried vim compiled against GTK3 libraries, and it was horrible. As are a lot of other gnome apps that worked well until they moved to GTK3. Thankfully Vim has the Athena build as well, but while it is better than GTK3, it is worse than GTK2 IMO. While other apps did not have non GTK builds, so had to switch to alternatives.
The problem is that Gnome seems to have started going down the KDE route of building a fully integrated platform a-la Apple OSX UI. So GTK apps only really work in a Gnome environment, and just break things with other desktop environments.
Seeing this release, it seems they are going even more into "deep integration", which does not bode well for third party DE's.
Until now GTK2 was still available, but if they are going to stop supporting it, soon it won't be usable anymore. What are the options then for those of us who don't use KDE/Gnome and their derivatives?
(Score: 5, Insightful) by Anonymous Coward on Thursday December 17 2020, @12:35PM (5 children)
fork gtk2 and maintain it yourself.
ideally, some of the current gtk developers will rally behind that, if they see that there's a big enough community who wants it.
(Score: 3, Funny) by Anonymous Coward on Thursday December 17 2020, @12:42PM (3 children)
Just use Qt.
(Score: 4, Insightful) by Anonymous Coward on Thursday December 17 2020, @02:19PM (2 children)
https://en.wikipedia.org/wiki/Qt_version_history [wikipedia.org]
https://wiki.qt.io/Qt_6.0_Release [wiki.qt.io]
There is no stability to be found when people get paid for constantly reinventing the wheel.
An intermediate layer to isolate program logic from GUI toolkit specifics is a must these days, for anything that need be supported long-term.
(Score: 0) by Anonymous Coward on Thursday December 17 2020, @03:01PM (1 child)
show us the code?
(Score: 3, Interesting) by Anonymous Coward on Thursday December 17 2020, @03:27PM
You are welcome.
GTK+1, GTK+2, GTK+3, scripting, and commandline scripting mode, all transparently supported through an intermediate layer:
https://github.com/wjaguar/mtPaint/tree/master [github.com]
Documentation on how it works inside: https://github.com/wjaguar/mtPaint/blob/master/doc/vcode.t2t [github.com]
(Score: 0) by Anonymous Coward on Thursday December 17 2020, @05:56PM
yeah, and people who use alt DEs can start writing apps for those DEs or forking gtk2 compat stuff. If enough people don't care stuff will die. That's just life.
(Score: 5, Interesting) by Anonymous Coward on Thursday December 17 2020, @02:12PM (2 children)
No, it is a cause to rejoice.
Incompetents and saboteurs will at last stop monkeying with the code.
Bugs that were willfully left unfixed by so-called "maintainers", could then be fixed by a community-produced patchset.
Look at GTK+1 Slackware package for an example of how it is done: https://slackware.osuosl.org/slackware64-current/source/l/gtk+/ [osuosl.org]
As to GTK+3, it will now actually get a chance, if the monkey squad will from now on confine their fun and games to the new-toy GTK+4. I, myself, have no hamsters in my ancestry to enjoy this kind of thing: https://developer.gnome.org/gtk3/stable/gtk-migrating-3-x-to-y.html [gnome.org]
(Score: 2) by leon_the_cat on Thursday December 17 2020, @08:51PM (1 child)
You know what they are so bad that i usually ended up just writing my own widgets at GDK level. That way they wouldn't explode when some 'dev' decided to completely change everything because his dog had some bone.
(Score: 0) by Anonymous Coward on Thursday December 17 2020, @09:58PM
Myself, I preferred to hack builtin widgets where possible; to keep the binary small, and to avoid breaking visual uniformity in case of theming.
Carrying around one's own widget library and just skinning them to look like GTK's counterparts is unnoticeable in a massive blob like Mozilla or LibreOffice, but would be unbecoming for something that tries to be compact. :)