4 ms·

Doesn't seem like there'd be any good reason to do it. Gtk4 has great low and high level bindings in the form of gtk-rs and relm.

adamnemecek 5y ago
There's a very good reason. GTK never looks very good. Also it uses paradigms that are just not idiomatic in Rust.
smoldesu 5y ago
Writing GTK4 apps sucks, at least in Rust. They removed so many idiomatic ways to build apps, and all you're left with is a shitty component system that forces you to write incomprehensible UI layout code instead of leaving it to JSON/XML languages that are much better suited to the process. In any case, gtk-rs's bindings after 9.0.0 are hardly usable, and require me to re-write entire apps just to get them to launch in the new and "improved" GTK4 wrapper, now with incredibly blurry text, compositor issues and broken stylesheets... sigh. I, for one, would love to see someone fork GTK3 for desktop purposes. GTK4's development has almost entirely been predicated by the GNOME team (despite how hard they deny it), and additions like libadwaita has made GTK unusable for many. After Pop_OS! was publically harassed by the GNOME team, I kinda expected them to take that project up. I can settle for a desktop fork all the same though.
- mixedCase 5y ago
  Sounds like you want high level bindings, instead of gtk-rs. Have you tried relm4? > and additions like libadwaita has made GTK unusable for many Could you expand on that?
  - smoldesu 5y ago
    > Sounds like you want high level bindings, instead of gtk-rs. Have you tried relm4? No, because as of 9.0.0 it was perfectly capable of building ergonomic UIs and works with external tools like Glade. It used to have plenty of features, now it does not. I haven't tried relm4 because I'm not going to write any apps for GTK4 while it's still broken (egregious text rendering issues, assistive tools like Cambalanche are completely unfinished and unusable in production, inconsistent compositor blocking, etc.) Plus, relm still doesn't fix the issue of how horrible it is to write GTK code inside a language as restrictive as Rust. With previous versions of gtk-rs you could at least circumvent that by drawing a definitive line between GUI code, builder code, and functional code (what is this, the future?), but now it's all been homogenized into .rs files and endless method calls. What a great development experience! [/s] > Could you expand on that? libadwaita has done nothing but further fracture the Linux landscape while pushing the onus onto me, the developer, to re-write the app to look native on other systems. On GTK2 and 3, I could write once, deliver to any platform and have it look as native as any other system utility. It's flexibility is what gave it it's value, since it was mostly just an open-source widget standard that could be used on any system you please. Unfortunately, now that the GNOME team has become the primary development leader of the GTK project, and projects like libadwaita do more harm than good for the desktop userspace as a whole. It provides me basically no value as a developer, and all of the "muh accessibility" and "muh dependability" arguments are total bunk. GTK3 was arguably more accessible since people with vision impairments could activate high-contrast or complimentary stylesheets that enabled them to... actually use the device. Nowadays, my only option is to assimilate into their brown blob UI or get thrown out for being "wrong". Does that seem like Linux to you?
    - awrmc 5y ago
      That seems like a lot of revisionist history. From what I've seen GTK never had good cross-platform development support. Programs like GIMP and Inkscape always looked and behaved very oddly to me on other platforms. The little support that's there is because interested parties contributed it. If this is what you want, it's self-defeating to refuse to contribute it. If you do not want to use Rust, you can always use another language like Python or Javascript. I might be misunderstanding because the rest of your complaints are jumping around a lot, it would be easier to understand what you're talking about if you shared some code illustrating what the problem is.
      - smoldesu 5y ago
        > From what I've seen GTK never had good cross-platform development support. From the start, GTK was written so that it would have good cross-platform support. GTK itself (not GNOME or Glib) is perfectly system agnostic, and as you've mentioned, it compiles and runs on other platforms. Not sure why you'd knock the way GIMP and Inkscape LAF on other systems; they both look perfectly native on Windows, and much better than the majority of cruddy MacOS desktop app wrappers. If there's a "more native" solution, I'd like to hear it. > The little support that's there is because interested parties contributed it. If this is what you want, it's self-defeating to refuse to contribute it. I can't. The GNOME team never opened libadwaita for public comment, or held any forums where I could voice concerns with the direction they were headed. They won't accept contributions that allow cross-platform stylesheets because it would undermine GNOME's own authority as a middleware distributor. I can understand how this all sounds accusatory, but I really do recommend that you research it. The community has been completely locked out of the GNOME decision-making process. > If you do not want to use Rust, you can always use another language like Python or Javascript. I might be misunderstanding because the rest of your complaints are jumping around a lot My problem here is explicitly with gtk-rs, a Rust crate that handled GTK bindings. It was a really good library until it hit v14, when the developers lobbed off support for Glade files as well as idiomatic/procedural app design. Now, the crate is pretty much useless as anything other than a GNOME support tool. This expanding GNOME-ification is particularly concerning because, as mentioned before, the GNOME team pretty much doesn't care about anything the community has to say. It's a bad direction for the project to be heading in, and it definitely makes it harder for regular people to write good-looking, system-agnostic GTK apps. > it would be easier to understand what you're talking about if you shared some code illustrating what the problem is. I wish I had code to share. I haven't been able to successfully port any of my apps with full feature parity on GTK4. The gist of my code/ergo concerns mostly boil down to this; v9.0.0 allowed you to build programs functionally and register their various interfaces as closures. This made it fairly simple to not only separate UI code from function code, but was also really comfortable to write "like a normal app". v14 eliminated this workflow though, instead forcing you to write UI code with Rust the same way you write the interactions, which have now shifted from a "flexible functional approach" to pure-object-orientation. For a language like Rust, that's two steps removed from madness. It's certainly not a great approach for small, hacked together utilities, and it completely throws the more advanced, idiomatic programs under the bus.

adamnemecek 5y ago

There's a very good reason. GTK never looks very good. Also it uses paradigms that are just not idiomatic in Rust.

smoldesu 5y ago

Writing GTK4 apps sucks, at least in Rust. They removed so many idiomatic ways to build apps, and all you're left with is a shitty component system that forces you to write incomprehensible UI layout code instead of leaving it to JSON/XML languages that are much better suited to the process. In any case, gtk-rs's bindings after 9.0.0 are hardly usable, and require me to re-write entire apps just to get them to launch in the new and "improved" GTK4 wrapper, now with incredibly blurry text, compositor issues and broken stylesheets... sigh. I, for one, would love to see someone fork GTK3 for desktop purposes. GTK4's development has almost entirely been predicated by the GNOME team (despite how hard they deny it), and additions like libadwaita has made GTK unusable for many. After Pop_OS! was publically harassed by the GNOME team, I kinda expected them to take that project up. I can settle for a desktop fork all the same though.

mixedCase 5y ago
Sounds like you want high level bindings, instead of gtk-rs. Have you tried relm4? > and additions like libadwaita has made GTK unusable for many Could you expand on that?
- smoldesu 5y ago
  > Sounds like you want high level bindings, instead of gtk-rs. Have you tried relm4? No, because as of 9.0.0 it was perfectly capable of building ergonomic UIs and works with external tools like Glade. It used to have plenty of features, now it does not. I haven't tried relm4 because I'm not going to write any apps for GTK4 while it's still broken (egregious text rendering issues, assistive tools like Cambalanche are completely unfinished and unusable in production, inconsistent compositor blocking, etc.) Plus, relm still doesn't fix the issue of how horrible it is to write GTK code inside a language as restrictive as Rust. With previous versions of gtk-rs you could at least circumvent that by drawing a definitive line between GUI code, builder code, and functional code (what is this, the future?), but now it's all been homogenized into .rs files and endless method calls. What a great development experience! [/s] > Could you expand on that? libadwaita has done nothing but further fracture the Linux landscape while pushing the onus onto me, the developer, to re-write the app to look native on other systems. On GTK2 and 3, I could write once, deliver to any platform and have it look as native as any other system utility. It's flexibility is what gave it it's value, since it was mostly just an open-source widget standard that could be used on any system you please. Unfortunately, now that the GNOME team has become the primary development leader of the GTK project, and projects like libadwaita do more harm than good for the desktop userspace as a whole. It provides me basically no value as a developer, and all of the "muh accessibility" and "muh dependability" arguments are total bunk. GTK3 was arguably more accessible since people with vision impairments could activate high-contrast or complimentary stylesheets that enabled them to... actually use the device. Nowadays, my only option is to assimilate into their brown blob UI or get thrown out for being "wrong". Does that seem like Linux to you?
  - awrmc 5y ago
    That seems like a lot of revisionist history. From what I've seen GTK never had good cross-platform development support. Programs like GIMP and Inkscape always looked and behaved very oddly to me on other platforms. The little support that's there is because interested parties contributed it. If this is what you want, it's self-defeating to refuse to contribute it. If you do not want to use Rust, you can always use another language like Python or Javascript. I might be misunderstanding because the rest of your complaints are jumping around a lot, it would be easier to understand what you're talking about if you shared some code illustrating what the problem is.
    - smoldesu 5y ago
      > From what I've seen GTK never had good cross-platform development support. From the start, GTK was written so that it would have good cross-platform support. GTK itself (not GNOME or Glib) is perfectly system agnostic, and as you've mentioned, it compiles and runs on other platforms. Not sure why you'd knock the way GIMP and Inkscape LAF on other systems; they both look perfectly native on Windows, and much better than the majority of cruddy MacOS desktop app wrappers. If there's a "more native" solution, I'd like to hear it. > The little support that's there is because interested parties contributed it. If this is what you want, it's self-defeating to refuse to contribute it. I can't. The GNOME team never opened libadwaita for public comment, or held any forums where I could voice concerns with the direction they were headed. They won't accept contributions that allow cross-platform stylesheets because it would undermine GNOME's own authority as a middleware distributor. I can understand how this all sounds accusatory, but I really do recommend that you research it. The community has been completely locked out of the GNOME decision-making process. > If you do not want to use Rust, you can always use another language like Python or Javascript. I might be misunderstanding because the rest of your complaints are jumping around a lot My problem here is explicitly with gtk-rs, a Rust crate that handled GTK bindings. It was a really good library until it hit v14, when the developers lobbed off support for Glade files as well as idiomatic/procedural app design. Now, the crate is pretty much useless as anything other than a GNOME support tool. This expanding GNOME-ification is particularly concerning because, as mentioned before, the GNOME team pretty much doesn't care about anything the community has to say. It's a bad direction for the project to be heading in, and it definitely makes it harder for regular people to write good-looking, system-agnostic GTK apps. > it would be easier to understand what you're talking about if you shared some code illustrating what the problem is. I wish I had code to share. I haven't been able to successfully port any of my apps with full feature parity on GTK4. The gist of my code/ergo concerns mostly boil down to this; v9.0.0 allowed you to build programs functionally and register their various interfaces as closures. This made it fairly simple to not only separate UI code from function code, but was also really comfortable to write "like a normal app". v14 eliminated this workflow though, instead forcing you to write UI code with Rust the same way you write the interactions, which have now shifted from a "flexible functional approach" to pure-object-orientation. For a language like Rust, that's two steps removed from madness. It's certainly not a great approach for small, hacked together utilities, and it completely throws the more advanced, idiomatic programs under the bus.