GTK 4 renders with OpenGL, has native a11y built-in, styled with a comprehensive CSS engine, runs on Linux/bsd/Mac/windows, has bindings for almost every noteworthy language…
What does this mean? `a11y` isn't some standard for making your app accessible, in fact it mostly seems to be guidelines for how to make your website more accessible. Is there an `a11y` native app checklist somewhere that Gnome is compliant with (and presumably QT/kde isn't?). Am I missing some protocol Gnome is implementing that QT/kde isn't?
Legitimate question, not snark, I've looked into in the past and I really don't see what Gnome's doing to comply with this that everyone else isn't.
> I really don't see what Gnome's doing to comply with this that everyone else isn't.
That's because Sun and GNOME created those layers two decades ago for Xorg.
Meanwhile QT continues to work great and they've largely solved the licensing issues that were a problem in the past. It's also a comparatively stable project and supports targets like android, iOS, rendering directly on to buffers (you can embed it into games). If you're starting a new project I think QT should be your default unless you have a good reason to use GTK.
I'm not qualified to assess the code quality of either project, but I have been impressed by QT for the few things I've needed to build a gui for. Things just work but if you need really specific functionality (like rendering directly to a framebuffer with no display server on embedded linux) it's not too hard to make it work. I'm honestly a bit mystified as to why anyone would choose GTK for a new project, unless they were specifically targeting the Gnome desktop and only the Gnome desktop.
Sort of?
Mostly just design patterns that are explicit to GNOME. And that is primarily a response to people being (rightfully or not) unhappy that too much GNOME was ending up in GTK itself.
It may do that but generally it still uses Cairo.
BTW, I would not rely long run on OpenGL existence on Windows and Mac (especially).
In any case GTK working on Windows and Mac is an artefact rather than something really usable.
I suspect that efforts to support such multiplatform feature makes Linux native GUI development less developed.
Generally Linux cannot be considered as a desktop OS as it has no stable and uniform system UI (window manager, graphics, etc.)
Uh, no it doesn't. I literally wrote the GL renderer, I know what I'm talking about.
> In any case GTK working on Windows and Mac is an artefact rather than something really usable.
Maybe pre-4, which is why it got redesigned.
> I suspect that efforts to support such multiplatform feature makes Linux native GUI development less developed.
What?
> Generally Linux cannot be considered as a desktop OS as it has no stable and uniform system UI (window manager, graphics, etc.)
Huh? You're out of your mind.
Do we have such basic thing as `MoveWindow(wnd,x,y,w,h)` on GTK?
Seems like still not:
- https://stackoverflow.com/questions/58103333/set-frame-posit...
- https://stackoverflow.com/questions/65508569/how-to-move-my-...
This is literally the dumbest argument ever. It's one extra line of code. If you have the GDK X11 backend, get the XID and call MoveWindow() yourself. If you have a macOS Window, call [NSWindow setFrame]. I don't see why you expect GTK to be your abstraction for insecure UI practices.
The compositor should be in control of this policy, not applications. Which is why that API isn't there any more.
It means that GTK is not a desktop API.
X11 is not a desktop API either as you cannot build with it GUI consistent with other applications on target platform.
Linux is not a desktop OS. By any means. Dot.
Until we have linux_move_window() function.
To make an OS you need a system of desktop-providing tools. Windows is an operating system that provides a desktop stack to the NT kernel. MacOS is an operating system built on Darwin and Mach. Following this line of logic, there are dozens of opinionated Linux distributions that qualify for your definition of desktop OS. (RHEL, Fedora, Ubuntu, KDE Neon, et al.)
Linux systems are no different than Darwin or NT ones if you compare like systems. If you spend all day comparing kernel features to OS features, I don't think you're going to make any meaningful discoveries.
To be short:
First Linux company that will decide to provide stable API similar to `WndProc(window, params)` (Windows) or `class_addMethod(window,@selector)` (Mac/iOS) will win Linux Desktop war - will make the Linux GUI for years to come.
If someone knows such company - please let us know, at least I am willing to participate.
If we're talking about kernels with windowing capabilities, there are none. If you're asking about OSes with a reliable, documented graphics stack, RHEL is literally what you're looking for. It's the shitty, "Windows-ified" model of desktop development, and almost everyone ignores it for desktop use. You might argue that it doesn't qualify, but you can't argue that nobody has tried it before.
Users and UI developers don't care. It is part of OS and it is always there.
The only things I know for sure are:
1. Desktop OS is not a distribution but set of popular GUI applications that work on that OS natively including tested specifically on it.
2. Lack of stable window and graphics API leads to fractured GUI developers community. Keeping in mind that number of Linux GUI developers is in magnitude of times less than for Windows/MacOS, makes Linux GUI perspectives very grim.
In general "desktop Linux" is not fair to its most loyal users because of these. Users are forced to pay extra price for hardware just to be able to run those Electron applications - no real native options for similar functionality.
That's what a Linux distribution is.
> Keeping in mind that number of Linux GUI developers is in magnitude of times less
It's roughly proportional to the number of people using Windows or MacOS for serious networking applications, yes.
> Users are forced to pay extra price for hardware just to be able to run those Electron applications
What are you even talking about anymore? Linux is not responsible for shitty Electron apps, Windows and MacOS is. People wanted a univeral runtime that worked across both operating systems - neither Microsoft nor Apple budged. So the browser it is - it just came with the side-effect that other browser-enabled platforms can also run Electron. Linux is not forcing you to use bad software because Apple and Microsoft can't work together to fix desktop computing.
If you don't like the Linux desktop, fine. Go use 9front or something. It still exists though, you cannot deny it's usability because you don't like the way it does something. I dislike the way MacOS handles it's desktop, but that doesn't mean it's not a desktop OS.
https://discourse.gnome.org/t/how-to-center-gtkwindows-in-gt...
As I’ve said above, not all windowing systems have a concept of
global coordinates or allow direct positioning of the windowing from
an application. Wayland, for instance, does not.
There's a lot to complain about with Wayland, but this is one of the few changes that seems rooted in logic rather than laziness.
You then use the "color shader" to copy from the texture atlas into the destination FBO to both create the shape and color at the same time. Since you often do this for a whole text editor, you can copy all of the glyphs and color them in a single glDrawArrays()s.
When GLyphy lands, it's a bit different. You preprocess the bezier curves into a simplified format (which doesn't have overlaps) and upload those to a texture atlas (but for general data). Then use GLyphy's shader program to render them, similarly to how the color shader was used.
For more general paths, which is much slower but also still very neat, you would do something akin to Pathfinder.