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.
(1)
(1)
Cole's Law:
Thinly sliced cabbage.
(Score: -1, Spam) by Anonymous Coward on Thursday December 17 2020, @08:02AM (1 child)
and other occult logos
(Score: 2) by DannyB on Thursday December 17 2020, @04:06PM
Wait a sec . . . what about programming in J/\\//\ or J/\\//\script ?
I new it must be of the devil! That would explain so much about Java 9 in particular.
I also now have to reconsider that Java 15 increasing its maximum heap from 4 TB to 16 TB might not be a good thing. It allows ever larger Hello World programs [github.com] to be created. (There is also the Java FizzBuzz Enterprise Edition [github.com]
The thing about landline phones is that they never get lost. No air tag necessary.
(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. :)
(Score: 3, Touché) by HammeredGlass on Thursday December 17 2020, @01:38PM (1 child)
I'm still waiting for non-destructive layer editing.
(Score: 2) by Marand on Wednesday December 23 2020, @12:29PM
Don't hold your breath, the devs don't seem to care very much about it or anything else that isn't arguing with critics.
I was involved in a conversation about a completely different piece of software (Krita) a while back and when someone decided to champion the superior editor, GIMP, I mentioned that I still preferred Krita for most photo editing as well because it's more polished and featureful nowadays. As an afterthought I tossed in a remark about how the Krita devs managed to implement non-destructive editing years before gimp even completed implementing GEGL, which was claimed to be a necessary prereq for upcoming NDE support.
So of course a gimp dev shows up to argue that no, they never promised that, I was making shit up, and their roadmap has always said it would come with the 3.2 version. In response I linked the release notes from 2009 where they mentioned GEGL in the context of "eventually bring[ing] high bit-depth and non-destructive editing to GIMP" and pointed out that in less time than it took gimp to mostly implement the NDE pre-req (and still no Gtk3 despite Gtk4 looming), Krita did a major Qt version change, supported high bit-depth colour, and implemented working NDE.
In return he spent the rest of the conversation nitpicking my grammar and calling me a liar because mostly-complete GEGL support only took 9 years, not the 10+ I initially said, plus arguing that it's not their fault it's taking so long because they have to port to GTK3 too. And pointed out that some people like gimp's pace of development just fine, implying anyone that didn't was just impatient.
Apparently in GIMP-world everything's fine and development is happening at a brisk pace and any inconvenient reality that disagrees with that is a lie or not their fault. Basically the usual GNOME dev discussion or bug reporting experience, no surprise there.
If you want non-destructive raster editing on Linux and would like to use it before GNU Hurd goes mainstream, try Krita instead.
(Score: 0) by Anonymous Coward on Thursday December 17 2020, @06:00PM
now i can resume work on my program i was working on which needed gtk4's new video element. gtk3 copied to CPU instead of just rendering with GPU. gtl4 should solve that.
(Score: 3, Touché) by Lester on Thursday December 17 2020, @08:45PM (2 children)
GIMP, once the flagship of GTK. In fact, GTK was created as a GUI lib for GIMP, replacing Motif.
Why are 4 and 5 are each three years. Weel that is waht they said. GTK plans according with GTK+, version numbering, and long-term support [lwn.net], there will be a new release each three years, that obviously will break compatibility.
This article nails down my feelings "Why do we keep building rotten foundations?" [wordpress.com]
(Score: 2, Insightful) by Anonymous Coward on Thursday December 17 2020, @09:39PM (1 child)
Code which has GTK+ 2.6 as baseline, for no loss of functionality has to require GTK+ 3.12 minimum. Which is 3+ years since 3.0; i.e. Don't be an early adopter. Coincidentally, GTK+ 2.6 itself is nearly 3 years since 2.0, too.
Now it is better; old relics like feature parity are annulled by party decree right from the start:
"Warping the pointer is disorienting and unfriendly to users. GTK 4 does not support it. In special circumstances (such as when implementing remote connection UIs) it can be necessary to warp the pointer; in this case, use platform APIs such as XWarpPointer() directly." https://developer.gnome.org/gtk4/stable/gtk-migrating-3-to-4.html#id-1.7.4.3.9 [gnome.org]
A tiny little question that raises; if I need a compatibility layer and platform API calls anyway, why not use platform API for everything and let GTK+4 with their "new incompatible releases" happen to somebody else?
(Score: 2) by Lester on Friday December 18 2020, @12:24PM
There are three kind of users:
Usually early adopters are using just one release, the last one that was beta not long time ago. Conservative users use the current stable release. And stiff users, use one stable version ago, or two, or even three stable versions ago. There are a few early adopters, a few stiff users, and most users are conservative users
GTK, because its lack of backward compatibility, is getting that most users are conservative users, and work in a single version, instead of several. Early adopters use several different versions, not just one. And conservative users are reduced to almost zero, because versions become obsolete before they get the critical mass.