Comment by consteval | Hacker News Reader

Comment by consteval | Hacker News Reader

Parent Full thread

> I cant develop software that targets any reasonable range of desktop environments

I highly recommend Qt for this purpose.

Gtk has been a hot mess for the past few years with Gtk4 and libadwaita shenanigans. However, Qt has continued to evolve incrementally without dropping any backwards functionality.

It's incredibly full-featured and has amazing tooling. In addition to Qt Creator you also have the CLI tools for packaging and whatnot and KDE has Kirigami for components.

The nice thing is that Qt applications look pretty good in native environments like plasma, but they also look pretty good in Gtk environments, including older Gtk-3 desktops and newer Gtk-4 desktops. So you cover all your bases. You also get Mobile and Windows/Mac, if anybody cares.

The two real downsides are:

- GPL

- C++ only (ish). There's other bindings but they will not have the same level and quality of tooling. Gtk has less tooling overall, but MUCH more high-quality bindings.

> > I cant develop software that targets any reasonable range of desktop environments > > I highly recommend Qt for this purpose.

I really appreciate your comment. QT is a great framework doing a lot of heavy lifting. However, the accessibility software I help maintain needs the ability to know what windows are in the foreground, all applications running and emulating key/text/mouse input in any of those running applications. Wayland is antithetical to those features by design.

I can see your point with QT for standalone applications. However, with interacting with other applications I'm not sure QT can solve the issue.

If you target just one Wayland compositor, I think this is possible. I mean, each Wayland compositor is basically a display server. The trouble is the Wayland protocol itself doesn't necessarily provide all the tools for this (it does provide some, particularly in conjunction with systems like pipewire and portals).

But, for example, I think kwin can definitely do this.

This is because GTK is C, not C++. It's much easier to write bindings from C

Yes, I think the design of GTK and GObject worked out really well in the long run. On the surface it seems stupid to use C and then just "bolt on" a C++-like system on top. Why not just use C++? But clearly it's worked out.

Unfortunately, GTK has it's own set of drawbacks.

Reply on news.ycombinator.com