5 ms·

I see a lot of people suggesting Qt, is there a reason GTK isn't being suggested at all? I'm in a position where I'd like to develop a better client for Bitwar

by dastx 6y ago

I see a lot of people suggesting Qt, is there a reason GTK isn't being suggested at all? I'm in a position where I'd like to develop a better client for Bitwarden that includes autofill to the point of 1Password, and while I did start with GTK (learning for the first time), seeing no one recommend GTK here (compared to multiple people recommending Qt) isn't filling me with confidence

captainmuon 6y ago
I found GTK with Python really nice. With a bit of effort you were able to make it look native on all platforms. Clean API, visual Editor, and quite performant. Unfortunately the project suffers a bit from CADT (Google it) and the devs break backwards compatibly all the time. They seem no longer interested in providing compatibility across versions or for platforms other than GNOME unfortunately. With GTK 2, you could write an app with e.g. GTK 2.16 and it would still run with 2.32, but receive all new features from the toolkit. Now you are expected to constantly change your app with every release.
- awalton 6y ago
  GTK+ 3 was a bit of a nightmare in this regard, but GTK+ 3 is also feature frozen and will be supported for more years to come, so a new application doesn't have as much to worry about here. The downside would be the desire to port to GTK+ 4 in some amount of time, which might require a large amount of effort depending on the application. On the other hand, if you're starting today you could also start with GTK+ 4...
  - captainmuon 6y ago
    That's half of my complaint, that the GTK+ devs consider "stable" to mean "frozen". You are supposed to code against the latest completed version (e.g. the final GTK+ 3), which will not receive compatible feature updates, and then if you want to get the new features you have to port your code to the next version. Whereas under the old model (GTK+ 2.x) it was forwards compatible (if that is the right word) - you code against a stable but actively developed version, and your code will work with no or minimal changes for multiple years, and you will receive the benefits of new versions (historical examples: changes to file open/save dialogs, theming changes, window resize grippers, dragging windows from menubars, ...).
miki123211 6y ago
> I'm in a position where I'd like to develop a better client for Bitwarden Beware that, if you use GTK, you exclude a certain segment of the population who need Accessibility and aren't on Linux. This definitely includes screen reader users, but probably also users of voice recognition, switch control etc. QT works much better here. This is yet another tradeoff to make.
- awalton 6y ago
  What kind of misinformation are you trying to spread here? GTK+ has accessibility built into the toolkit itself - it's not optional, and it's always on. In fact, GTK+ had it before Qt did - ATK was written back in 2001 to be a part of GTK+, and the screen reader Orca is written to use GTK+ and the platform agnostic AT-SPI layer. It would take a full ten years for Qt to add an implementation here.
  - cycloptic 6y ago
    The parent post is saying it doesn't plug into the native a11y, which is true. Running the at-spi daemon on windows/mac would work for some things but it is obviously not ideal.
  - miki123211 6y ago
    COnsider that a lot of people who are forced to use GTK aren't actually on Linux, and Windows and Mac accessibility is literally nonexistent.
- cycloptic 6y ago
  The accessibility system in GTK is being redesigned in GTK4: https://blog.gtk.org/2020/02/17/gtk-hackfest-2020-roadmap-and-accessibility/ https://blog.gtk.org/2020/02/17/gtk-hackfest-2020-roadmap-an... The changes should make it similar to the way Qt works and should make it easier to plug in a Windows/Mac a11y backend. If there is interest in implementing/maintaining this then please help out if you're able.
formerly_proven 6y ago
Unless things changed a lot in the last ~three or so years, Non-Linux platforms like Mac and Windows aren't really in the focus of Gtk+. In the past ~five years a large number of cross-plattform Gtk+ applications redeveloped their UIs in "Not-Gtk+" (usually Qt). Wireshark, Subsurface, Openshot and LXDE come to mind, these are all pretty large, UI-centric projects, so replacing the toolkit is a lot of work and wouldn't be something you'd do just for shits and giggles. If you really, really want your app to use Gtk+ on Linux and be reasonable elsewhere, consider wxWidgets.
marcosdumay 6y ago
I'm not in the discussion above, but I would never recommend GTK for any cross-platform application because it enforced a Gnome-only look and feel that is completely alien on any other environment (even on Linux).

by dastx 6y ago

captainmuon 6y ago

I found GTK with Python really nice. With a bit of effort you were able to make it look native on all platforms. Clean API, visual Editor, and quite performant. Unfortunately the project suffers a bit from CADT (Google it) and the devs break backwards compatibly all the time. They seem no longer interested in providing compatibility across versions or for platforms other than GNOME unfortunately. With GTK 2, you could write an app with e.g. GTK 2.16 and it would still run with 2.32, but receive all new features from the toolkit. Now you are expected to constantly change your app with every release.

awalton 6y ago
GTK+ 3 was a bit of a nightmare in this regard, but GTK+ 3 is also feature frozen and will be supported for more years to come, so a new application doesn't have as much to worry about here. The downside would be the desire to port to GTK+ 4 in some amount of time, which might require a large amount of effort depending on the application. On the other hand, if you're starting today you could also start with GTK+ 4...
- captainmuon 6y ago
  That's half of my complaint, that the GTK+ devs consider "stable" to mean "frozen". You are supposed to code against the latest completed version (e.g. the final GTK+ 3), which will not receive compatible feature updates, and then if you want to get the new features you have to port your code to the next version. Whereas under the old model (GTK+ 2.x) it was forwards compatible (if that is the right word) - you code against a stable but actively developed version, and your code will work with no or minimal changes for multiple years, and you will receive the benefits of new versions (historical examples: changes to file open/save dialogs, theming changes, window resize grippers, dragging windows from menubars, ...).

miki123211 6y ago

> I'm in a position where I'd like to develop a better client for Bitwarden Beware that, if you use GTK, you exclude a certain segment of the population who need Accessibility and aren't on Linux. This definitely includes screen reader users, but probably also users of voice recognition, switch control etc. QT works much better here. This is yet another tradeoff to make.

awalton 6y ago
What kind of misinformation are you trying to spread here? GTK+ has accessibility built into the toolkit itself - it's not optional, and it's always on. In fact, GTK+ had it before Qt did - ATK was written back in 2001 to be a part of GTK+, and the screen reader Orca is written to use GTK+ and the platform agnostic AT-SPI layer. It would take a full ten years for Qt to add an implementation here.
- cycloptic 6y ago
  The parent post is saying it doesn't plug into the native a11y, which is true. Running the at-spi daemon on windows/mac would work for some things but it is obviously not ideal.
- miki123211 6y ago
  COnsider that a lot of people who are forced to use GTK aren't actually on Linux, and Windows and Mac accessibility is literally nonexistent.
cycloptic 6y ago
The accessibility system in GTK is being redesigned in GTK4: https://blog.gtk.org/2020/02/17/gtk-hackfest-2020-roadmap-and-accessibility/ https://blog.gtk.org/2020/02/17/gtk-hackfest-2020-roadmap-an... The changes should make it similar to the way Qt works and should make it easier to plug in a Windows/Mac a11y backend. If there is interest in implementing/maintaining this then please help out if you're able.

formerly_proven 6y ago

Unless things changed a lot in the last ~three or so years, Non-Linux platforms like Mac and Windows aren't really in the focus of Gtk+. In the past ~five years a large number of cross-plattform Gtk+ applications redeveloped their UIs in "Not-Gtk+" (usually Qt). Wireshark, Subsurface, Openshot and LXDE come to mind, these are all pretty large, UI-centric projects, so replacing the toolkit is a lot of work and wouldn't be something you'd do just for shits and giggles. If you really, really want your app to use Gtk+ on Linux and be reasonable elsewhere, consider wxWidgets.

marcosdumay 6y ago

I'm not in the discussion above, but I would never recommend GTK for any cross-platform application because it enforced a Gnome-only look and feel that is completely alien on any other environment (even on Linux).