
GTK 3.99 - severine
https://blog.gtk.org/2020/07/31/gtk-3-99/
======
c-smile
GTK still misses:

1\. Anything close to AdjustWindowRectEx() function. See:
[https://docs.microsoft.com/en-
us/windows/win32/api/winuser/n...](https://docs.microsoft.com/en-
us/windows/win32/api/winuser/nf-winuser-adjustwindowrectex)

2\. MoveWindow(window,rect) where rect is window frame rectangle. Instead GTK
has 6 other functions that do something close but no one of them do
MoveWindow.

See: [https://stackoverflow.com/questions/58103333/set-frame-
posit...](https://stackoverflow.com/questions/58103333/set-frame-position-of-
decorated-gtkwindow-on-screen)

Windows has these functions, MacOS has their direct equivalents, but GTK does
not have such, IMO basic, functionality.

Will we have anything like that in GTK4?

~~~
ATsch
Wayland does not allow clients to make decisions such as the precise placement
of windows for security and sanity reasons, so I do not think that these will
ever be added.

~~~
skeletal88
Then Wayland is kind of stupid. Why is that restriction needed or why do the
developers think that it is a good idea to have it?

For example, when the user has arranged the windows of an application in some
way, and then wants to save and then restore the placement of windows, how
should it be done by the application?

~~~
dahfizz
> how should it be done by the application?

It shouldn't be done by the application. It's the window manager's job to
manage windows.

As a user, I absolutely do not want applications to be able to put themselves
wherever _they_ want. The windows go where _I_ want, and the window manager
gives me a single place where I can manage all that.

~~~
quotemstr
More specifically, I want to give _some_ applications the ability to place
windows where they want, warp the mouse, grab certain keys globally, snoop
input, and so on. And I want to give _other_ applications a small sandbox
where they can't steal focus or hurt anything.

X11 could have been evolved in this direction by sandboxing applications
within little mini-universes within the existing protocol. Windows solved this
problem without breaking compatibility:
[https://en.wikipedia.org/wiki/User_Interface_Privilege_Isola...](https://en.wikipedia.org/wiki/User_Interface_Privilege_Isolation)

I have a fundamental philosophical disagreement with the Wayland and GNOME
camp. They believe that they can enumerate all interesting use cases and that
each app should fit in one of their pre-defined boxes. I'm old school and
believe in making systems that provide mechanism, not policy, and that give
applications the ability to do unanticipated things.

~~~
c487bd62
Why don't you propose a protocol to solve the issues you have? If it solves a
problem other users have it would get adopted I'm sure (except maybe GNOME).

I'm not a Wayland developer but it's what I observed in the issue tracker of
my WM. A limitation is often overcome by a protocol and a basic implementation
after. If you put the work in, the wlroots and KDE people are always very nice
and will help you get started.

[https://github.com/wayland-project/wayland-
protocols/tree/ma...](https://github.com/wayland-project/wayland-
protocols/tree/master/stable)

[https://github.com/wayland-project/wayland-
protocols/tree/ma...](https://github.com/wayland-project/wayland-
protocols/tree/master/unstable)

[https://github.com/swaywm/wlr-
protocols/tree/master/unstable](https://github.com/swaywm/wlr-
protocols/tree/master/unstable)

~~~
hedora
They did propose a protocol: X11 plus sandboxing, modeled after the windows
approach to sandboxing.

~~~
c487bd62
And they are free to continue adding features and maintaining their preferred
software choices. Nobody else seems to want to do it. IIRC the X11 maintainers
are the same people who started Wayland.

> [https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-
> fed...](https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-
> workstation-31/)

> Once we are done with this we expect X.org to go into hard maintenance mode
> fairly quickly. The reality is that X.org is basically maintained by us and
> thus once we stop paying attention to it there is unlikely to be any major
> new releases coming out and there might even be some bitrot setting in over
> time. We will keep an eye on it as we will want to ensure X.org stays
> supportable until the end of the RHEL8 lifecycle at a minimum, but let this
> be a friendly notice for everyone who rely the work we do maintaining the
> Linux graphics stack, get onto Wayland, that is where the future is.

But we were talking about Wayland here. You're free of course to fantasize
about hypothetical scenarios or propose features to software nobody wants to
maintain.

~~~
ComputerGuru
One of the problems is that X is effectively being deprecated in favor of
something that isn't X 2.0: it has different goals, different targets,
different ideologies, and not to mention different architecture.

Eg Wayland is unashamedly Linux-centric (mind you, definitely not the same as
Linux exclusive), while X most definitely isn't. One was designed to allow for
remote rendering, one wasn't. One integrates the window manager functionality
and one doesn't. The list of course goes on.

~~~
ATsch
The things you list have not really been true in the real world for a long
time. Modern Xorg uses the same Linux exclusive APIs as Wayland, is not
network transparent, relies heavily on window manager and compositor features,
etc. Modern Xorg and Wayland are more or less conceptually identical. Wayland
just replaces the X server with a UNIX socket and has a clean slate for APIs.

~~~
wott
1\. You're conflating X and Xorg.

2\. Network transparency is still there and I use it everyday. The problem is
toolkits (GTK and others) who decided it would be 'simpler' to redo everything
themselves in a canvas. Of course the result of not taking advantages of X
primitives was a massive slowdown over the network.

3\. Wayland sits at an odd place, not having the advantages of being a proper
protocol in the sense of X (complete abstraction from the substrate), while at
the same time not having the advantages of being a direct API to hardware
(simplicity, performance).

------
qalmakka
The part of GTK+ I've always hated the most is how much it relies on GObject,
which is probably one of the worst ideas ever conceived by mankind.
Reinventing a whole object system using C and shitload of macros is such an
aberrant idea I cannot even start ranting on why it's an utter abomination.
The fact it was born mostly from the hate the GNU project always harboured for
C++ is what has always bewildered me the most. I understand that C++ in the
nineties was a steaming pile of manure, but basically reinventing a poor man's
copy of Objective-C just because they desperately wanted to write their stuff
in C, and nothing else, is just too much.

And for what? GCC was basically the reference implementation of an Objective C
compiler, a language that basically boils down to an object system hastily
glued on top of C. I don't think it would have been so unreasonable to use
that instead of rolling their own... I guess they had their reasons for not
doing that, or not cooperating with GNUstep for that matters.

The irony is that has led to the creation of a million language bindings, such
as Vala, Gtk#, PyGTK, Gtkmm, gjs, ... just to lower the massive learning curve
of writing GTK applications in C. This is something Qt has clearly never
struggled with, given that I've yet to see a relevant Qt app not based on C++
or (recently) QtQuick.

~~~
rjeli
I mostly agree with you, whenever I want to put a simple native linux gui on
top of some tool I'm disappointed by the difficulty of the GObject api.
However, one advantage is that the C abi hasn't budged as the binary lingua
franca. The C++ abi can change, but that only happens every decade or so, so
it's not that bad. The worse part is that most FFI libraries always support C
perfectly and C++ is always "experimental". So you can quickly throw together
a library for a language that wraps GTK without worrying about the ABI. The
downside is, obviously you want to smooth over GObject in MyCoolPyGTK, so each
library develops its own API which you have to learn over and over, and you
end up with 12 tabs open of the shoddy MyCoolPyGTK docs, GTK docs, GObject
docs, and reverse engineering how they talk to each other behind the scenes.
/rant

~~~
hedora
> _However, one advantage is that the C abi hasn 't budged as the binary
> lingua franca._

That’s nice in theory, but hasn’t gtk stopped providing API compatibility
between minor releases?

~~~
thayne
That's not the point. The point is other languages don't have FFI for c++
because it doesn't have a stable/standard abi, so it's much harder to make
bindings to qt than to gtk for most languages.

~~~
hedora
Version one might take a bit longer, but you don’t have to re-write the qt
bindings every three months.

I’m all for ABI stability, but without API stability, it’s meaningless.

~~~
thayne
First of all Gtk doesn't require a rewrite every three months...

Secondly, at least for dynamic languages, you typically don't need to worry
about wrapping Gtk's API, you just wrap GObject, and use introspection to
dynamically generate classes.

------
chungy
It's a serious blast to the past, and not necessarily a good one, to see
versioning treated like this, where they'll pick 3.9? as a form of
alpha/beta/RC phases for 4.0.

I think semver (more-or-less a formalization of what was already becoming
popular before semver got published) makes more sense. Go ahead and use
4.0-alpha.1, 4.0-beta.1, 4.0-rc.1 as needed. The strings still sort fine.

~~~
layer8
The problem is that "4.0" sorts before "4.0-alpha.1". Not saying that 3.99 is
better, but something's gotta give.

~~~
deathanatos
If you're lexicographically sorting, maybe? But if you're doing that, 3.10 and
3.2 won't sort correctly, either.

~~~
itp
Nah, this was never really about lexicographic sorting. Pre-semver, there was
general consensus between systems like dpkg and RPM about how version numbers
worked. This is a bit of a simplification, but it roughly works out like this:

* Split version number into version numbers separated by non-alphanumeric components (e.g., 3.10.2 becomes (3,10,2) and 3.2 becomes (3,2)).

* Compare two versions item by item numerically (in this case, 3==3 but 10 > 2 so 3.10.2 is newer than 3.2).

This is a massive oversimplification, and if you're curious you can read more
at
[https://fedoraproject.org/wiki/Archive:Tools/RPM/VersionComp...](https://fedoraproject.org/wiki/Archive:Tools/RPM/VersionComparison)
for the gory details.

Source: long ago I worked at a company named Ximian that shipped a software
update product that worked on systems using both RPM and dpkg, and I had to
deeply understand this problem space.

~~~
jdub
Ha ha. _waves_

------
randtrain34
Can someone point me to a roadmap/changes to be expected for GTK 4.0? I've
looked on the blog and googled around, but couldn't find an authoritative
source.

~~~
marsrover
[https://gitlab.gnome.org/GNOME/gtk/-/milestones/1](https://gitlab.gnome.org/GNOME/gtk/-/milestones/1)

------
johannes1234321
Anybody can share some recent experience with Gtk on Windows? In previous
versions it worked, however results where quite "special" from a Windows
point-of-view. Did they manage to get a more native feeling? Or is it still
better to use wxwidgets on top?

I have some toy Qt projects for non-technical users, but with recent licensing
stories around the Qt Company I'm looking at alternatives.

~~~
nyanpasu64
I tried gtk-rs on Windows last year (2019). Everything about it was alien.

\- The theme was Adwaita. [https://github.com/B00merang-
Project/Windows-10](https://github.com/B00merang-Project/Windows-10) claims to
be a Windows 10 GTK theme, but doesn't feel like Win32 to me. Win32 is mostly
gray (with some white elements), while this theme is white.

\- The title bar buttons were "missing images" because vcpkg's GTK
installation forgot to include images.

\- Using ShareX to Ctrl+PrintScreen (region screenshot), then clicking on a
GTK window, included the shadow around the window. The shadow was custom-
drawn, not delegated to Windows.

\- Dragging a GTK window to the side of the screen produced custom-drawn blue
rectangles, not native Windows Aero Snap. Aero Snap was custom-drawn.

~~~
johannes1234321
So still only an option for porting few special applications for making them
available at all and nothing for building applications purposely cross
platform.

------
ohazi
Is GTK 3 -> 4 expected to be as big a clusterfuck as 2 -> 3?

I'd really rather not go through all that again.

~~~
nfoz
What were the problems with this transition?

~~~
rleigh
There are so many that I could spend several hours ranting about them.

If you invested time and effort in writing GTK+ 2.x applications, the GTK+
developers spent zero time caring about API compatibility even for cases where
it would have cost them nothing to maintain. They just had to rip it all out
just for the sake of it, even when single line compatibility forwarding
functions would have been entirely sufficient to avoid breakage.

This is the fundamental dichotomy with GTK+. Its developers want to hack on
the toolkit itself for their own amusement and occasionally for GNOME
features. They don't care about the needs of the application developers who
would use their toolkit to write actual applications. God forbid it's used for
its intended purpose. If you invested thousands of hours into using it, they
will not bear that in mind as they rip out stuff people used for over two
bloody decades in the name of "progress". Like GtkHBox. Gone. There since 1997
and used by every GTK+ application on the planet, but that's no reason to keep
"old code"!

That's their choice. But other libraries like Qt do take better care of the
interests of their customers and end users, and don't gratuitously break core
functionality on a whim while chasing shiny new things. In the above example,
the GtkHBox class is replaced by GtkBox with an "orientation" property.

Now, any sane developer would retain GtkHBox and simply implement it in terms
of GtkBox with a defaulted "orientation" to horizontal. New way works. Old way
works. No breakage. Everyone is happy. But they just had to rip it all out in
the name of "progress". Consider how many instances of this there are in a
large codebase. Hundreds to thousands in a big UI. The breakage was entirely
avoidable and quite unnecessary. Maintaining the compatibility code would have
been a tiny effort with a few one-liner compat functions, but ripping it out
imposed huge problems upon every user of the library. "Cleanliness" needs to
be traded off against "breaking end users", but they have the scale dialled
all the way to one side, which is spectacularly unhelpful and inconsiderate.

That's just one class and one example. You could write a book enumerating all
of the other instances. It's that bad.

No one who looks at this rationally in 2020 should be choosing GTK+ for a new
project. You know in advance it will end in tears and frustration, as all of
the value you created will be destroyed on a whim by developers who should
know better, but go ahead and break everything anyway just because they can.
That's their choice. But it's our choice to not get sucked into the bizarre
world where this kind of software maintenance is considered in any way
acceptable or justifiable. Seriously. These people are on another planet. What
project intentionally gives the finger to all of their developer base? A
really messed up one with nonsensical priorities.

Sorry if this comes over badly. If you can't tell, I've got a bit of pent-up
frustration after spending far too many hours of my life trying to work around
GTK+, submit patches which are ignored, and try to develop applications in
spite of GTK+, not because of it. I should have just used Qt from the start.

~~~
cycloptic
>retain GtkHBox and simply implement it in terms of GtkBox with a defaulted
"orientation" to horizontal.

I'm sorry, I understand your frustration but to me this is a terrible example
and kind of makes the rest of your post look like complaining about a non-
issue. This is exactly how it's already implemented in GTK 3. GtkHBox was
deprecated there and slated for eventual removal, then it got removed in GTK 4
because the whole point of it is an API break and removal of deprecated
functions. If this bothers you, you can keep using GTK 3 which is now
considered feature-complete. The situation with GTK 2 was the same, you could
keep on using it if you didn't want to bother updating your application.

~~~
rleigh
Wow, that response demonstrates exactly what is wrong with this library and
its developers.

"You can carry on using the old version" is a real cop-out which does not
address the substance of the complaint in any way whatsoever.

Yes, I know it's being removed in GTK+4. You didn't _have_ to remove it. You
chose to. And to hell with the consequences. You could have kept it pretty
much indefinitely with near zero maintenance overhead if you cared about
compatibility and the extent to which that core functionality was used.

I am always surprised at how much time gets wasted on trivia, and yet a simple
maintenance issue like this is too difficult despite requiring much less
effort.

~~~
cycloptic
I'm not a GTK developer so please spare me the shooting of the messenger. All
I did was read their documentation. From what I've seen there are very few
paid developers actually working on GTK. Everyone else is volunteers and none
of them are interested in maintaining deprecated APIs for any protracted
amount of time. Even with the removal of a lot of deprecated functions in GTK
4, there is still a ton of untested code sitting around that nobody really
maintains. You're welcome to write tests for these and maintain an external
compatibility layer yourself if you want, but it makes no sense to expect
other volunteer developers to do this for you when the old versions are
considered stable.

~~~
rleigh
> "Everyone else is volunteers and none of them are interested in maintaining
> deprecated APIs"

This is a complete cop-out. It's maintained by several RedHat employees as
part of their duties, and a handful of volunteers.

Every software project on the planet, including commercial ones, is maintained
with limited resources. The amount of development and maintenance which is
possible is constrained by the available developer hours, and work is budgeted
based on that.

The cost/benefit of maintaining the compatibility code is so low that it's not
even worth the effort to remove it. The time taken to drop it was likely on a
par with the time to retain it. It was already written. But the cost _imposed
on all their userbase_ after removing it is absolutely huge. And it means that
an application can't target old and new versions due to the break. That wreaks
havoc with support lifetimes and imposes thousands of developer-hours of
effort for porting. Lots of effort... just to get back to where you were.
Unjustifiable.

I could understand if there was a huge benefit to be gained. But there isn't.
And when you look at what they do spend their time on, so much is wasted on
other activities that justifying its removal based upon developer resources
wears a little thin. It's a weak justification which ultimately boils down to
just wanting to, and completely ignoring the actual users of the library.

~~~
cycloptic
If the cost/benefit is so low then you do it. I'm completely 100% serious
about this, I assume you have some customers lined up who are willing to pay
for this so just take the money and don't worry about what anyone else does.
Make it as an external library so you don't have to spend time convincing
upstream to merge and maintain it. None of the existing volunteers are willing
to do this work, and the paid developers get paid to work on what Red Hat
customers pay them to work on, which evidently is not related to maintaining
legacy applications at all. If they want to leave money on the table, that's
their problem. There is nothing wrong about what you're saying but it's mostly
hot air, you're preaching to the choir here.

------
AlexMax
Good for them. Does this mean we're going to get a GNOME 4 as well? I'm quite
curious to see what neat things the new version of GTK enables in practice.

~~~
matthiasv
While the toolkit certainly has an influence on all core apps that are part of
GNOME, the shell is entirely independent of GTK. So, highly unlikely there
will be a GNOME 4 any time soon.

~~~
IAmLiterallyAB
Eh I bet there will be. Every Gnome/GTK version until 3.22 had the same
version number and were released at the same time. The only reason that
stopped is because GTK 3.22 was supposed to be "stable" and "the last GTK 3"
version while Gnome still wanted to do updates.

------
Jerry2
Anyone know if they've finally added thumbnails aka "icon view" to the file
picker?

~~~
Shared404
That would be an issue with the GNOME DE, not the GTK toolkit.

~~~
Jerry2
Nope... it's been an issue in GTK's tracker for over 16 years. They would have
passed the buck long time ago if it wasn't their issue.

~~~
Shared404
I stand corrected.

------
techntoke
Telegram has shown the enormous potential of Qt with the latest update. Not
that I have a horrible time with GTK, but Qt just feels better and lighter
overall. qutebrowser is another example of the amazing potential of Qt.

~~~
saagarjha
Personally, I much prefer GTK apps over Qt ones. What makes you think that Qt
does it better?

~~~
rleigh
Qt doesn't even compete with GTK+, it's in an entirely separate class which
GTK+ will never reach. It's an entire application development framework of
over a dozen libraries, only a few of which are related to GUI functionality.
And for the libraries where there is overlap e.g. QtCore and QtWidgets, the Qt
design and functionality is again such a step up that it's not even worth
comparing.

GTK+ is a simple and limited X11 toolkit. It can be visually attractive. But
it's not something you would chose rationally based upon features, code
quality, code maintainability or having a good developer ecosystem and
support. Because it would come in last place on every metric, unfortunately.

There are very good reasons people don't use GTK+ for commercial projects. Or
even open source projects, unless they haven't learned the hard way yet.
Fundamentally: its developers don't prioritise the needs of the very
application developers who should be their primary customers.

(I used to develop open source and commercial GTK+ applications. What a huge
waste of time and effort that was. Utterly soul destroying how many unfixable
bugs I had to find and work around.)

~~~
marktangotango
> It's an entire application development framework of over a dozen libraries,
> only a few of which are related to GUI functionality.

Do you not consider GLib and associated libraries to also fulfill this
application development framework role?

~~~
rleigh
Good grief, no! It's not remotely comparable to the array of Qt libraries. Can
it handle XML parsing, XSLT transforms, SVG rendering, database access, OpenGL
scenegraphs, gamepad input, networking, chart rendering. No. It doesn't even
do one of them, and that's not even the full list.

GLib is a set of basic C functions for missing standard library functionality
which range from acceptable to awful. An "application development framework"
it is not. It's a set of simple helper functions and some primitive containers
with so-so performance and very little safety.

Use the C++ standard library and avoid 99% of it with containers that work
properly and classes that aren't fragile because you're still pretending that
C can do object orientation and object lifetime management sanely. It can't.
Constructing vtables by hand with GObject might be clever to prove a point,
but it's no way to write a robust application that the compiler can actually
type check and that static analysis can find problems with.

~~~
cycloptic
>XML parsing, XSLT transforms, SVG rendering, database access, OpenGL
scenegraphs, networking

Off the top of my head there is libxml2, libxslt, librsvg, libgda, libclutter
(and now GSK with GTK 4). Networking is included in the gio part of glib.

Unfortunately there are no good gtk/gobject-style libraries for generic
gamepad input or chart rendering as far as I'm aware.

~~~
rleigh
> Off the top of my head there is libxml2, libxslt, librsvg, libgda,
> libclutter

None of which have anything to do with GTK+ as an application development
framework. They are independent projects.

~~~
cycloptic
These are the libraries that most GTK applications are using for those
purposes. You can bikeshed about whether they call themselves an application
development framework or not but Qt is also split up into separate projects in
separate git repositories like this.

~~~
rleigh
The Qt libraries are released together as an integrated whole, all using
common functionality in QtCore and being designed to work together.

The libraries you mentioned are a random collection of unrelated open-source
libraries. There is no comparison. It's not "bikeshedding" to point out a
completely baseless argument.

~~~
cycloptic
As far as I can tell, those projects I mentioned are all either maintained by
GNOME developers under the GNOME umbrella, used in a large number of GTK apps,
or they use glib/gobject and make extensive use of the same design patterns as
GTK. It's confusing to me how you're trying to say they aren't designed to
work together. The situation is the same as Qt, the only difference there is
that it's centered around their C++ QObject design patterns.

If the argument is that the Qt libraries are all developed together by paid Qt
Company developers then sure, that's true, the libraries I mentioned aren't
like that where one company is working on them. But that's different than
saying they're designed to work together.

------
Const-me
I use it as needed, but I think it’s way too complex overall.

Here’s an example: [https://github.com/Const-
me/Vrmac/blob/master/RenderSamples/...](https://github.com/Const-
me/Vrmac/blob/master/RenderSamples/09-VideoPlayer/GTK.cs)

Win32 equivalent: [https://github.com/Const-
me/Vrmac/blob/master/RenderSamples/...](https://github.com/Const-
me/Vrmac/blob/master/RenderSamples/09-VideoPlayer/Win32.cs)

------
pxi
What a bargain! All that amazing software for just $3.99 :)

But seriously, thanks folks. Enjoying your stuff every day

------
dilandau
GTK is openly hostile to 3rd party developers and theme makers, ever since gtk
became synonymous with gnome (around 3.0). This is going to be a nightmare for
open-source developers and distros, which will likely be forced to support
both for a long time to come.

Me? I'll keep writing tcl/tk applications. It's stable, cross-platform, and
did I mention it's stable?

------
klysm
Does the .99 versioning irk anybody else? It seems like a very inelegant
solution.

~~~
ordu
Using negative numbers (like 4.-1) would be worse, because of version string
parsers using '-' as a delimiter.

------
marsrover
Still waiting for an acrylic blur (or some other type of blur) to bring Gnome
to parity with modern desktops.

~~~
jaas
I don't understand what you're asking for. Can you explain?

~~~
nightfly
Transparency with a blur effect for windows. So you can see some of the color
that's behind them without all the detail. I'm... not really a fan of it. It
drives me crazy in windows that terminal transparency is for the entire window
(even the text!) and not just the background.

~~~
marsrover
I don't think anyone is asking for the blur to encompass the text in a
terminal. Is this a bug? I could have sworn when I used Windows Terminal that
this wasn't the case, but it has been a while.

~~~
Firehawke
If you turn on the acrylic mode, yeah, it covers the whole window. I have the
preview of WT installed here and acrylic looks awful compared to how it did
back in Windows 7. Probably a function of the way Microsoft wants you to use
it in "modern" Windows 10 as opposed to Windows 7 as there are marked
differences in how acrylic looks compared to the Windows 7 era and less
configurability.

