GTK 3.99
blog.gtk.org
blog.gtk.org
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?
Which I think is a terrible thing to have separate, for the functionality reasons you're illustrating.
But that's why.
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?
If a WM might exist that chooses to ignore the positioning call, that doesn't mean everyone should be robbed of that functionality.
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?
Wayland doesn't have an equivalent protocol yet, but this is also how it would be idiomatically done there.
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.
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.
Can macOS do it?
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?
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.
> 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?
https://wayland-book.com/xdg-shell-in-depth/popups.html
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.
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.
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'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/ma...
https://github.com/swaywm/wlr-protocols/tree/master/unstable
> https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fed...
> 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.
Maybe this is the end of portable, open source video stacks.
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.
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).
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.
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.
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.
And FYI, X11 can already be sandboxed using those methods in combination with firejail: https://firejail.wordpress.com/documentation-2/x11-guide/
[1] starts at 0:40 https://www.youtube.com/watch?v=5-kZ1xcxhx4)
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!)
…no? I’m not sure why this would be an issue specific to those?
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.
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.
That’s nice in theory, but hasn’t gtk stopped providing API compatibility between minor releases?
I’m all for ABI stability, but without API stability, it’s meaningless.
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.
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#...
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.
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.
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?).
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.
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.
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 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.
* 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... 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.
> When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version:
> Example: 1.0.0-alpha < 1.0.0.
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. :-)
GTK/GNOME started doing time-based releases every six months 18 years ago. Hasn't missed a beat.
I have some toy Qt projects for non-technical users, but with recent licensing stories around the Qt Company I'm looking at alternatives.
- 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.
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.
I'd really rather not go through all that again.
According to https://developer.gnome.org/gtk3/stable/gtk-migrating-3-x-to..., the changes were pretty minor.
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.
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.
> API changes every minor release.
vetinari:
> the changes were pretty minor.
Was this pun intended? ;-)
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.
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.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
Don't tell me that X is bloated.
Enlightenment was fast on that machine. The desktop switcher in the panel had old-school desk lamps pointing at the active desktop.
I miss that theme, and I can’t find any screenshots.
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.
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.
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.
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.
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.
Also, systemd seems similarly hostile and is also from redhat.
Wayland... does seem to be solving some real problems, but the transition hasn’t been going well either.
Would you create a new open-source desktop application using gtk4? Would you want to package and maintain systemd/pulse/etc?
Also: why are you responding to all the critical comments in the thread, and writing dismissive replies?
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.
Still hasn't been improved in 20 years? sad.
It's stable (unlike gtk), and truly free (unlike qt, which is also a c++ behemoth). It's utterly simple and elegant.
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.)
Do you not consider GLib and associated libraries to also fulfill this application development framework role?
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.
None of which have anything to do with GTK+ as an application development framework. They are independent projects.
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.
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.
Ditto for "in depth documentation". ;)
I suspect the problem is lack of API stability, not the relative quality of any given pair of releases.
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'".
- Use Auto-Night Mode to make Telegram night mode match the system Dark Mode settings.
- Also added an option to switch to system window frame in Windows and Linux.
- System notifications for Linux
Nice and seamless overall now. Get my notifications using system notifications, and looks better in Sway using system frame.
Before that, before GNOME existed, GTK definitely had file dialogs - everyone used to complain about the design.
[1] https://developer.gnome.org/gtk3/stable/GtkFileChooserDialog...
[2] https://mail.gnome.org/archives/gtk-devel-list/2004-March/ms...
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.
As Don Norman says "They probably won a prize"
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...
Here’s an example: https://github.com/Const-me/Vrmac/blob/master/RenderSamples/...
Win32 equivalent: https://github.com/Const-me/Vrmac/blob/master/RenderSamples/...
But seriously, thanks folks. Enjoying your stuff every day
Me? I'll keep writing tcl/tk applications. It's stable, cross-platform, and did I mention it's stable?
https://askubuntu.com/questions/475935/did-they-just-remove-...
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.
I'm pretty sure only Gnome users bash Gnome because non-Gnome users just don't care. I've been on Gnome since 2003.
https://developer.gnome.org/gsk4/stable/GskRenderNode.html#g...