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.
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.
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?
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.
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...
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.
>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.
This is already how it works. The plan with GNOME and wayland is to put those in the xdg desktop portal so they can be subject to whatever security policy is appropriate. Really, nothing has changed here in regards to how much mechanism is provided or not.
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.
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.
> 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.
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.
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.
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).
Or, in another words, Wayland is the same as the modern X, minus the legacy core that couldn't be removed from X because it is not extension (anyone using stippled unaliased lines yet?) and plus sandboxing.
Yeah, the end game for this seems pretty horrible. Wayland (still) doesn’t work, and is user-hostile (at least for this user). The BSD’s and most applications I use seem to be sticking with x.org.
Maybe this is the end of portable, open source video stacks.
I have found that “OK, why don’t you just do xyz if you think you’re so smart” shuts down interesting discussion, and that’s what you’ve been doing here. Would you be willing to not do that or explain why you think that isn’t the case here?
No, it does not shut down discussion, it shuts down bikeshedding. There's a large peanut gallery with strong opinions how they would do it, but because they never did something similar, they have no idea what they are talking about and what trade-offs are involved.
Unsurprisingly, people who know these things, for example because they develop it, may disagree with the peanut gallery and do it in a way they consider the best.
I would much rather hear a reason why something wouldn’t work than the responses saying “ok, how would you do it” and “ok, well someone would have done that if it was legitimate but they didn’t”.
It's not that simple; explaining one reason why something would not work means re-examing many of the underlying assumptions and not many like to go deeper than that one problem at hand in isolation. The "ok, how would you do it" forces thinking about underlying issues, because the solution you propose has to account for factors you otherwise wouldn't think of.
It is not a new problem either; this video is 9 years old already: https://www.youtube.com/watch?v=ZTdUmlGxVo0. It is almost one hour long, but well worth to watch to see the two different approaches to clash.
On Mac OS, you can ask the WM to store the geometry for you and recreate it. It's exposed to devs via the NSApplicationWindow (or something) API and then backed by a protocol between the app and the windowing server, leaving the latter in ultimate control.
Wayland doesn't have an equivalent protocol yet, but this is also how it would be idiomatically done there.
But of course macOS also has APIs on NSWindow to move it around, as well as accessibility and AppleScript APIs to do it as a user in a scriptable way. Why the limitation?
Wayland does have some ways (meaning protocols) to do explicit positioning, e.g. relative to a parent owned by the same client (for popups), that have been standardized.
The primary limitation is not to allow clients to set their x,y in the global scene (or even look them up), but there are proposed protocols that allow global positioning in a semantic sense like "I would like to be at the left edge" or "I am an overlay type thing" (z positioning). Some of those are in production use internally to Wayland-based desktop shells, e.g. KDE's Plasma, or used in communities like sway/wlroots+addons (e.g. dmenu implementations).
Why not do x,y? It means you don't have this sort of level positioning code in the apps, which are very expensive or impossible to fix after the fact (apps stop being maintained, etc.) when new ideas come up. Say you want to apply a transform to client windows - scale them, or put them into a 3D sphere in a HMD. Wayland compositors have full flexibility there because the apps don't make assumptions.
> Say you want to apply a transform to client windows - scale them, or put them into a 3D sphere in a HMD. Wayland compositors have full flexibility there because the apps don't make assumptions.
Except that macOS can do all this regardless? WindowServer can do all sorts of transformations on windows, fully independent of the position the window has set for itself. That's how all the fancy Mission Control/Exposé animations work.
The point of this demo is not practical usability today, but to demonstrate, that global positioning on the desktop as we know today might get much more complex in future. So why shut the door?
macOS can place windows wherever it likes, see Mission Control. It has APIs that can literally reach across processes so you can draw a window’s content as a little “view” in your window if you like, and apply the rich set of CoreAnimation transformations to it. What happens in a case like that is that the window gets placed in a new coordinate system that is orthogonal to its “original coordinates” (since of course it has no idea what would be going on without changes to the application frameworks) and moved and rendered freely. (Again, Mission Control was added with zero work or cooperation on the part of applications, even though they had the “window move” APIs from day one, which was many years prior. I would be entirely unsurprised if one could make a demo like the one you just showed fairly “easily”, barring private APIs and accessibility permissions and such.)
Yes and users have to unplug monitors to find windows that have done this.
> Why the limitation?
Because users don’t want it? We have window managers and some of us are using automatic window managers. The very idea of movewindow doesn’t make any sense in a lot of topologies.
Why do you care? You don’t write or use any software that would need this anyway, do you?
Either way, allowing it from applications is a lot different than allowing it from user scripts or accessibility tools in terms of potential for misuse.
In javascript you can't set your window to be borderless and transparent and be drawn on top of everything else so that you can intercept clicks or trick users into clicking on something.
> why do the developers think that it is a good idea to have it?
Because it has little utility and a lot of risk; Baddies use this to trick people. It is also so hard to use it correctly/meaningfully in many display topologies (mostly multihead+multidpi, but also tiling, virtual desktops, etc) without querying that topology that there’s no big hurry to offer an API that users don’t want and nobody can use correctly.
> 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?
It shouldn’t: Putting that logic into every application is bloat at best, and a lot harder than just writing down x/y coordinates and screen numbers to a file (ever had to unplug a monitor to find a window on a Mac or windows desktop? Never happens on Unix!) so it makes sense to centralise it:
This is the job of the window manager and really, its only job. There are lots of window managers on Unix because users have varying needs here (I like using a lot of accessibility tools- If you could move my windows I might never find them again!)
You just don't get to set the absolute position of your window. The precise position and making sure it isn't going off of the edge of the screen is the responsibility of the compositor.
This is good because it ensures proper security sandboxing and makes sure clients still work even when the windowing paradigm changes, e.g. with multiple desktops or window tiling. Developers hardcoding such assumptions is what caused much of the pain of Xorg so it's understandable that they want to make sure it does not happen again.
I might generally agree, but there are some very cool applications of this feature. The rhythm game Rhythm Doctor moves the window in sync with the music. [1] Surprisingly it even worked on i3wm via Wine. I would be sad if similar things couldn't be done in the future, even if they aren't enabled by default.
> The application cannot decide where its window ends up.
Yes that's how it works. I think there may be some APIs that let you 'hint' to the WM from the application, but it's possibly entirely up to the WM how to interpret those hints.
> Every used a tiling WM?
Sorry not sure what you're asking here. A tiling WM yes could possibly ignore the hints or interpret them in its own way. But not everyone is using a tiling WM, if that's what you're asking?
That should be on the person using a tiling window manager. The whole problem with development this side of the mobile revolution is the regression not to the mean but to the least common denominator and it's what made Windows 8 so horrible.
If a WM might exist that chooses to ignore the positioning call, that doesn't mean everyone should be robbed of that functionality.
StatusIcon and AppIndicator is extremely annoying.
Clientside decorations, ridiculous headerbar, button+hamburger menus, etc, etc. They are trying their absolute hardest to copy Mac os, and making sure everyone's stuff breaks in the meantime.
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.
Those large amount bindings are possible due to the GTK be written in C, which allows creating binding to GTK via FFI - foreign function interface or native interface (borrowing the term from java JNI).
Creating bindings to QT is harder because Qt is written in C++ and C++ compilers does not have a standard ABI and FFIs foreign function interfaces can only load C-compatible functions and types. Another challenge is that older Qt (< Qt5) versions relied too much on MOC - Meta Object Compiler for reflection and callbacks.
The workaround for calling a C++ libraries from other languages is to create a C-API for the C++ library via 'extern "C"' wrappers with opaque pointers. Qt could be used by many other programming languages if it was shipped with an official C-API or interface as previously mentioned.
I a have a proof-of-concept code of a C-API for Qt5 Widgets and three client codes in C, D-language and Julia language which call the C wrapper library and build Qt5-Widgets user interfaces. This code is available at: https://caiorss.github.io/C-Cpp-Notes/CwrapperToQtLibrary.ht...
Another way to generate bindings to C++ libraries is by using SWIG that parses the C++ code generates native interface bindings.
The fact C++ has no stable ABI is not what stops you from creating language bindings, because you need that kind of interoperability only for those symbols that need to cross the FFI.
It's more about how the library is designed than the implementation language itself; for instance, Tensorflow is mostly written in C++, but its intended use is as a Python module. Also, by using GLib you take in so many GLib-specific types and assumptions it becomes extremely wonky using it from non-GLib code, and you often end up writing some kind of FFI anyway in order to wrap its behaviour. I've even seen some libraries ship both a C and a GLib wrapper, as if it was almost like a separate language.
LLVM is a good example of C++ being able to interface with other languages using its C FFI, being completely written in C++ but having bindings for almost every programming language.
I can count among them at least C, C++, D, Rust, OCaml and Python, for instance, and while it has an "LLVM-C" library available, you are not necessarily forced to use it; you can just export what you need directly from C++ using a file with a few functions defined as extern "C".
Rust is probably even trickier to interface with C but it's still pretty doable, given that GNOME is now rewriting several components in Rust (see librsvg).
I still think one of the main reasons C++ was discarded so quickly at the time, despite Qt and KDE being older than GNOME and in C++ already, was being born from a culture that had at the time already rejected the adoption of C++.
GNU has historically always discouraged its projects, especially those they cared about the most, from using C++. It's well documented how strongly RMS despised the language and how he actively pushed people towards using C for such tasks. I think it's still written in somewhere in the GNU website, even.
Heck the GCC developers had to ask RMS the permission to switch to C++ a few years ago, due to GCC becoming harder and harder to maintain. Ironically, it used internally its own private C implementation of dynamic vectors, while being one of the main implementers of the STL. I think it even had some sort of garbage collection inside, and that they largely reimplemented an object system too using C and macros (it's been a while since I read the GCC sources, so my memories could be incorrect). RMS wasn't really that happy about it, but it grumpily said they could.
The lack of standard ABI makes harder to call C++ from foreign-function interfaces or from dlopen/LoadLibrary dynamic loading functions. It lack of ABI also does not allow linking against object-codes built by the other compilers or even older versions of the same compiler.
In C, a symbol name matches the function name, if you have a function called 'void my_function()', the symbol will be 'my_function' and you will be able to load this function from a foreign function interface as libffi.load('my_function', ... types ...). The trouble with C++ bindings is that symbols are mangled, the function names are encoded, a function named 'Workaround1::get_callback()::callback' can be encoded (mangled) as _ZZN11Workaround112get_callbackEvE8callback - this encoding is specific to a given compiler ABI, in addition FFIs cannot load non-C types.
Tensorflow uses the hourglass design pattern, this library is implemented internally in C++, but does not exposes a C++ API, instead it exposes a C wrapper built with 'extern "C" and opaque pointers (void* pointers or incomplete types). This approach allows the library to be used in the same way as a C library and makes easier to call the library via FFI. Another benefit is the better binary compatibility as object-codes built with other compilers canlink against Tensorflow without any issues. Another library that uses this approach is the Squirrel embedded scripting language, that is implemented in C++, but only exposes a C API. So, this technique allows a C++ library to be used as C library and makes possible calling it through FFI.
I guess that in the case of LLVM it may also use this pattern of using C++ internally and only exposing a C API via extern "C". The disadvantage of this pattern is the need of lots cumbersome extern "C" wrappers for every member function of a class and for all exposed classes. LibClang LLVM may be helpful for automating the generation of this C wrapper code.
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
I really wish there was a standard stable ABI for namespaces, vtables, and maybe name mangling operators and overloaded functions. In other words, a standard ABI for OOP APIs. The problem with C++ abi isn't just that it can change, but that it is implementation defined,so different compilers produce different abis.
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.
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.
Just every major release you have to start from scratch, again, including any tooling you might have had for previous version now requiring rewrite from scratch.
Objective C componentization model has its own traps. And too many of them unfortunately.
Object's ownership model in particular, when need of `[obj release]` is always a guess based on name of constructor function (name should contain "alloc", "new", "copy") but there are exceptions. I cannot even classify such architectural decision...
Among all practical UI systems I know, Windows's approach ( HWND and WndProc ) is the most flexible, stable on the long run. Despite its damn simplicity (or rather because of it?).
Objective C is not forced to have such design; if you don't import Foundation you can use plain libobjc and create your own root class, you can name methods however you want. Objective C historically boiled down to basically a preprocessor that transformed its Smalltalk-like additions to C to calls to objc_* functions and C structures. In the years, Apple has added syntax to interface with their own classes (i.e. @autorelease that AFAIK interfaces with NSAutoreleasePool), but that's about it.
If everyone had rolled its own OOP in C now we would have dozens of incompatible and hard to interoperate object systems, all trying to do in a library the same stuff C++ and Objective C do at compiler level. I understand doing simple IsA relations with casts, or using function pointers for virtual dispatching, because they are sane and clean. These guys basically implemented reflection and duck typing in C.
I think it's one thing to wrap that sort of thing inside your program; it's after all your project and you can do whatever you deem appropriate to make it work.
Using such a concoction in a library is kind of demanding everyone to deal with the mess you made if they wish to interact with your code, and it's a pretty different thing, IMHO.
GObject is very far from the beauty and simplicity of C that every one knows and love. It's also arguably vastly clunkier and uglier that Objective C or C++ are.
This is arguably false; for instance, Qt has official first-party bindings for Python. It's just that the tools Qt has make them not that necessary.
Qt has not one but 2 fully functional IDEs (QtCreator and KDevelop) and good designer tools that lower a lot the complexity of writing a GUI. QtQuick is also very nice.
Gnome has what? Anjuta? Glade was nice but it didn't avoid you the hassle of using GObject. I think Vala is a clear proof of what I'm trying to say. They knew the shortcomings of their system, and how difficult it was to use, so they basically wrote a language that hid the complexity of GObject under a thick layer of nicer syntax. It was also a way to discourage people from using C# and Gtk#...
sure, there are a lot of good qt tools, but they by and large tether you to c++. people would love to have good qt bindings for whatever language the rest of their project is in, but the fact that qt is implemented in c++ makes it hard.
No, it does not. The world is full of scriptable C++ programs and C++ libraries with dozens of language bindings. As I wrote before LLVM, perhaps the most important compiler toolkit out there, is completely written in C++ and almost every language out there has bindings to call into it.
If Qt is hard to interface with, it's not because of C++, it's because of Qt. Also, Gtk+ is quite hard to interface with to begin with, given how much it relies on GLib/GObject and how weird it is to use it. That's I think the #1 reason GTK has so many bindings, RAD would be simply not feasible otherwise.
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.
Both GTK and GNOME have used .99-style release candidate micro numbers, and odd/even minor numbers to represent devel/stable (as Linux once did) for a VERY long time. ~18 years ago, GTK/GNOME decided that major number bumps meant breaking changes.
.99 means "we're absolutely serious about this release candidate" because you know you're going to eat it if you ship a three-digit minor. How embarrassment.
Kids, a bit of community tradition won't hurt you. :-)
I'd trust Matthias to know when GTK is ready, and it's a signal to the community that it's definitely time for testing and porting. But he can still make micro bumps. :-)
Indeed: as it is said in the post, they had to give up on a feature because they could not implement it in time for their .99 version and they locked themselves in that system.
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).
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.
Semantic sorting has existed for a long time. GNU coreutils have been able to do a "version sort" for years (eg, "ls -v" or "sort -V"), using the Debian rules which also happen to be a superset of semver. "4.0~alpha.1" sorts before "4.0".
NetBSD does similar (major.99.iteration), and before its alpha or beta, this is where things get hashed out. It’s a reserved magic number (one hopes there aren’t 99 minor releases that would start a conflict over x.99.y) so that sucks (being “magic”), but it seems to work out in practice.
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.
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.
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 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.
So still only an option for porting few special applications for making them available at all and nothing for building applications purposely cross platform.
Well, most of QT libraries are LGPL, therefore you don't need a commercial license for a non open source project as long as you dynamic link against the Qt library and don't static link against it. On Windows it is easy to pack an application with all shared library dependencies, all you need is copying the shared libraries (*.dll files) to the executable directory. Unlike on Unixes, on Windows, the loader searches first the dependencies at the executable current directory or in directories listed in PATH variable.
Other alternatives are: WxWidgets; MFC - Microsft Foundation Classes that has GUI builder in Visual Studio IDE; Borland VCL - Visual Component Library; Sciter library which allows creating the GUI in html and has a C API. Another way is to build the application on top of Win32 GUI API that is well documented and has lots of examples, unlike X11-Xorg (X Windows System) used on Unixies, such as Linux distributions or BSD variants.
The GTK 4 transition is totally unnecessary. Any new functionality needed can be incorporated into the existing API in a backwards-compatible manner. Major version bumps should be an absolute last resort, not something a major infrastructure library does when it gets too stable and its developers get bored.
You want a new recyclerview-like list widget? Great. Make a new damned widget. You want a retained-mode rendering system? Great! Add a bunch of new widget hooks. Don't require a whole new major version bump and make everyone using GTK3 deal with dependency hell trying to get upgraded. It feels like only yesterday that most things finally moved off GTK2.
There is ZERO reason for an ABI break here. None. GTK3's ABI is a perfectly adequate base for adding new functionality. The GTK people, by making a GTK4, made a lot of work for everyone for no benefit.
Is the GTK4 API cleaner? I guess? Event objects are opaque now. There's no root window. Yay? But "it looks slightly cleaner" is a totally inadequate justification for the pain of yet another GTK ABI transition.
I could go and on about how much gratuitous breaking changes piss me off.
The same goes for Wayland, by the way --- X11 has an extension mechanism. Wayland could have used it. And don't tell me about the core protocol breaking the model --- it doesn't hurt anything if you don't use it.
X has serious architectural problems. What would it mean to build a completely new windowing API using the extension system, if 'proper use' would mean using exclusively the new extended API? Is that meaningfully different from or better than building a new windowing system (cf wayland) and implementing x11 on top of it (cf xwayland)?
FWIW, I think wayland also has serious architectural problems, and see arcan as much more promising, but rewriting/replacing legacy can definitely be justified. Extension hell is much worse than compatibility hell. If you don't like gtk4's api, then don't use it; gtk3 will continue to work. It's better that an api should be coherent and cohesive than that it should bend over backwards to keep compatibility with ideas that no longer make sense. Obviously, this should be applied within reason—don't do a complete rearchitecture every month—but compatibility breaks are important and necessary.
> if 'proper use' would mean using exclusively the new extended API? Is that meaningfully different from building a new windowing system (cf wayland) and implementing x11 on top of it (cf xwayland)?
We're already in a world where "proper use" of X11 means relying on ubiquitous extensions. Nobody uses the core font rendering APIs anymore --- instead, everyone uses fontconfig and XRENDER. The transition was gradual and smooth. Nobody had to rewrite applications. Both old-font-API and new-font-API X11 applications shared the same X server, the same connectivity configuration.
The transition to Wayland should have looked like a super-XRENDER, not some bespoke new thing with an embedded X server that will always be a second-class citizen just like embedded X servers on Windows and macOS are.
Making some grand new thing and emulating the legacy thing is harder to get right than just teaching the legacy thing to do something new. Why? Because in any rewrite, you not only have to rewrite the parts of the old system that are bad, but also the parts that are good.
Yet the people who were working on Xorg decided to write wayland instead. Why? Because there was little more benefit to he had from the previous approach. Xorg had become a slow and bloated synchronous IPC service and replacing it with a UNIX pipe was the logical solution.
> Xorg had become a slow and bloated synchronous IPC service and replacing it with a UNIX pipe was the logical solution.
You do realize the the X11 server connection is also almost always a Unix socket, right? (ITYM "Unix socket", not "Unix pipe".) That's like showing out your spork and replacing it with a spork.
> Yet the people who were working on Xorg decided to write wayland instead.
My whole point is that they were wrong to do so, just like I think the GTK people are wrong to break ABI on GTK4.
A completely new solution was inevitable because there was nothing more that could be done with Xorg. All of the complexity that mattered had moved into the WM, Compositor or Client. It wasn't actually doing anything anymore.
> A completely new solution was inevitable because there was nothing more that could be done with Xorg.
I see no evidence behind this assertion. What specifically would have prevented the further evolution of Xorg?
> All of the complexity that mattered had moved into the WM, Compositor or Client.
Good. So that means that Xorg didn't have to change very much. All Xorg had to do is provide mechanism, not policy, and let WM, compositor, and client cooperate as they've been doing for decades.
But instead the Xorg maintainers got bored and decided to make a big ball of mud with no separation of concerns.
Wayland happened mainly because they could get to 90% of Xorg functionality easily and ignored the fact that the last 10% would take over a decade to achieve parity on.
> Wayland happened mainly because they could get to 90% of Xorg functionality easily
We're at 12 years of Wayland and counting and the thing still isn't really usable outside a very narrow use-case. I still run X11 myself and will for a long time. As far as I'm concerned, Wayland has set free software windowing back by a decade. After all this time, Wayland still isn't at parity with X11 even for use cases that Wayland intends to support --- and some things that X11 can do are non-goals for Wayland and will never be supported. What exactly is so compelling in Wayland that it was worth putting progress on hold since 2008?
Yeah, yeah, I get that Wayland has a nice buffer-based composition system. So what? Whatever Wayland does, it could have done over an X11 extension.
Wayland was the default in Ubuntu 17 and is still the default in Fedora. I like it because dealing with multiple displays and tearing under X annoys me more than dealing with screen capture under Wayland. “Not really usable outside a very narrow use-case” overstates the problem.
As the other poster mentioned, X11 used to run on really old resource-constrained systems. Nothing about it precludes using it for embedded automotive applications. A tiny MCU could manage it. The MCUs used for current automotive stuff are powerful enough to run Linux with Vulkan for crying out loud.
Though I think for many of these embedded applications both X11 and Wayland are overkill when EGL direct works just fine. A full windowing system is massive overkill.
Because the problem isn't with X, it's that all the toolkits people want to use were written basically to use X as a glorified framebuffer. Wayland is a reorienting of the underlying stack to accomodate this. You could absolutely make an automotive stack with something like X and Motif, but nobody in the industry really wants to use those tools.
Most embedded graphical Linux applications don't use X (X Windows System), instead they use framebuffer directly or any library such as Qt Widgets or QtQuick/Qml that draws on top of the framebuffer device file. So, there is no need for developing a new Window system that can work on both Desktop or embedded systems.
> We're at 12 years of Wayland and counting and the thing still isn't really usable outside a very narrow use-case.
Must be a wide narrow you're talking about. I've been using it as my default session across two different distros and the only problem I can recall having was strange mouse-grabbing behavior in Firefox, and I don't even think that was Wayland's fault.
This is the comment I wish I had made. The transition from 2 to 3 was terrible for end users, distros, and app developers. I wonder if redhat is trying to embrace/extend/extinguish because it's impossible for me to see gtk (and gnome) teams actions as anything less than overtly hostile.
Please don't. It's getting rather boring to see the baseless conspiracy theories that show up whenever an article is posted about gtk, gnome or systemd. Apparently they're trying to embrace extend extinguish their own business now?
Please don't make these inflammatory comments either, it adds nothing to the discussion. You're in the thread of a GTK release announcement making these comments, I'm not sure what you're trying to accomplish but I doubt it's going to be constructive. I've used GTK for a few projects, it's not perfect but the conspiracy theories and aggression are unwarranted. Nobody is out to get you. At worst, as a developer you can ignore it and use Qt instead and it won't affect you.
Personally I would rather make a new toolkit, but it takes many years and many contributors to make a decent one. GUI toolkits are a complex business. Don't discount the amount of work that was already done on GTK or Qt, there are some serious lessons you can learn from those codebases.
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.
>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.
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.
Deprecation does not imply removal in the short-term. Java has deprecated many things which will never be removed, because they care about compatibility. Just because there's a newer way to do something does not mean the old way must be removed as soon as possible. If it was very high maintenance and it prevented the addition of new functionality, this might be justified. But that's not the case. It's completely gratuitous.
The GTK+ removals are akin to removing "strlen()" from the C library because a better "strlengh()" was added in the meantime. Compatibility matters. And well-maintained projects balance that with the addition of new features.
Deprecated, perhaps, should suitable replacements be standardised. Removed, absolutely not.
It cannot be overstated just how terrible compatibility breaks are. C is nearly 50 years old, and all of its standard functions are thoroughly entrenched, despite their numerous known defects. It took long enough to eliminate gets(), and that was broken from inception.
In almost all cases, removal is not the best solution. Supplementing with a safer or better alternative to supersede the original, by all means. But deliberate breakage causes nothing but pain all around.
In the case of GTK+, it's nearly 25 years old. These is a legacy of thousands of applications, large and small, which have invested hundreds of thousands of developer-hours in it. Obsoleting things might save the GTK+ developers a little extra effort (though I doubt this), but it imposes several orders of magnitude more work upon the worldwise developer base tied to GTK+, which could be avoided entirely without holding back progress.
So you expect the developers to keep maintaining old interfaces forever? The C library, that I understand (POSIX and all), but GTK+? I think that's an unnecessary burden.
Now if someone wanted to make a shim library that had the old APIs, that might be doable.
Removing an unused and long-deprecated interface is low impact. Removing a widely-used interface is very high impact.
When you have an interface that is nearly 25 years old and a staple part of every GTK+ application in existence... that's a very high impact change. I'm unsure how the GTK+ developers rationalised that one. But I am completely certain they made the wrong call there. It's too disruptive. I don't think it should have ever been dropped, or considered for dropping. Deprecated, yes. But not dropped.
I'm coming from the perspective of an end-user of GTK+: an application developer. Though I have historically also contributed bits upstream. I moved away from using GTK+ several years back at this point, precisely because the upstream maintenance practices were too much of an ongoing imposition, along with all the other criticisms one can make of it. GTK+ might be "free", but the cost of using it is very, very high.
There are 800 deprecated symbols in GTK 3. They were removed in GTK 4 because nobody upstream is willing to pay the cost to maintain them anymore. There is a real cost and typically this cost is that you have to commit to bugfixes and refactoring on the deprecated bits for the entire lifecycle of the new version, which is potentially many years. If the app developers aren't willing to pay the cost either, then you've got a hung jury situation.
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.
> "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.
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.
They broke enough of the theming API on every minor release that for a few years it was essentially impossible to run any GTK theme other than the GNOME sanctioned default theme (Adwaita). Adwaita was updated in lock step with GTK minor releases (by the same developers), and unaffiliated theme builders were left with periodic drops of subtly different behavior and no notes or tools on how to update their themes. It drove many of them away.
This was apparently a part of a deliberate strategy around GNOME branding. The GNOME developers wanted all GTK apps to have one consistent look-and-feel, they wanted people to associate this look with GNOME, and they wanted people to start thinking of GTK apps as "GNOME Apps."
More recently, they crippled existing functionality for server side-window decorations in Wayland (which literally every other toolkit supports), because GNOME decided to use exclusively client-side decorations. They vetoed all of the reasonable seeming workaround proposals, essentially telling developers to either use GNOME's decorations or to manually draw the close/maximize/minimize buttons.
Honestly, all of the crap that systemd gets should be redirected towards GTK/GNOME. I've never seen a group of developers act in such bad faith.
The GNOME/GTK devs and systemd devs are pretty tightly coupled... Recall the infamous config defaults change that killed sessions impacting things like tmux/screen? Pretty sure it was done because of gnome-session...
Theming is internal, not public API though. It is fine to break internal APIs, that's why they are internal.
Themers were warned, that the styling engine was under heavy rework. Gtk people could either wait few years until it's done and be stuck with Gtk2 meanwhile, or go out with Gtk3, which has relatively stable public API and internal API under rework. It's no brainer to take the same way they took. They also communicated this, so anyone who ignored their advice has no basis to complain. They were told exactly what is going to happen, and that they will either have to keep up, or not do it yet.
Switch to client-side decorations was also done for a very good reason. There's a post by Rasterman (author of the Enlightenment WM) on reddit, where he details it why - and he is not even associated with Gnome. Windows and Mac also do client-side decorations, you just cannot see it, because clients cannot connect directly to the compositors, they have to use the client side libraries that handle that. Which is exactly what Gtk does.
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.
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.
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.
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.
Separately from what? "QML has a deep JavaScript integration, and allows signal handlers and methods to be defined in JavaScript" according to the docs[1] - the JS engine[2] doesn't seem separable from the QML-based parts of the UI toolkit.
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.)
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.
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.
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.
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.
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.
Hmm. I can't think of any actual cross-platform GTK apps that is widely used like Telegram.
The only app that is close to "qualify" on this could be GIMP, but will it get over the issue of user responses like: "I only want Adobe® Photoshop®, Ableton® Live NOT this 'GIMP' or what is this thing called 'Ardour'".
Has anyone figured out how to save a file with the keyboard?
On one machine, opening a file dialog hangs the UI rendering thread for about 60 seconds, and then I close the dialog box because I never wanted to invoke it anyway (different workflow).
On the machine where I need it, it doesn’t hang (small victory), and it autoselects the default file name, but not the default extension (good).
However, it puts the keyboard focus in the directory listing. So, if you start typing, it filters the directory listing instead of overwriting the selected text in the filename. Tab and shift-tab move keyboard focus to even more obscure UI elements.
I just want to type:
<ctrl>-s filename <enter>
I’m pretty sure that used to work!
I guess I should see if someone’s reimplemented $COMPLICATED_APP from scratch in qt yet...
As a use case let us imagine you desire to open a file to edit in gimp. It is very common to have a folder full of images named very non descriptively by the software that interfaced with your camera or by your camera software on your phone.
Image0001 Image0002 ... Image0165
One useful workflow is to open your file manager which has a nice view in which individual file names are placed under iconic views of the images. Importantly this view is zoomable allowing one to easily view a big enough view of the individual images to allow one to differentiate one similar image from another.
GTK file pickers have traditionally offered.
- Nothing just file names
- Miniscule non zoomable icons that are too small to differentiate and thus virtually useless. I'm talking about 2x3mm on a 24" screen.
- no thumbnails as icons but a panel off to the side which would show a preview of the selected item forcing you to blindly select image0007 and then image0008 each in turn in order to get a look at each in turn in order to select the correct item.
None of these options are even slightly usable. Even the gimps file picker is pretty mediocre and its an image editing program. The really strange thing is obviously such functionality is available when browsing files with nautilus.
QT file pickers on Linux offer functionality similar in nature to normal file managers in browsing and sorting. One can select an icon view and zoom making it actually usable to select images.
A file picker gui is a very basic piece of functionality. A 16 year old bug for offering functionality similar to windows 95 is a legitimate source of consternation.
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?
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.
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.
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.
There was a time when I had a terminal with just the background transparent. I recall that. You could do it in software and even on hardware on a Via Unichrome.
Terminal with transparent or even blurred background is very doable. I've done it on my i3-gaps and urxvt setup both with urxvt's "fake" transparency and by using a compositor.
It's funny to see people on HN freaking out and, when Gnome moves a preference from one sheet in preferences dialog to another sheet, in the same dialog.
I wonder, if these people even use Gnome, or they just want to join the bashing.
Btw, if you do use Gnome, you can find it in Preferences | <profile> | Colors.
1. Anything close to AdjustWindowRectEx() function. See: https://docs.microsoft.com/en-us/windows/win32/api/winuser/n...
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...
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?