6 ms·

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

by 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.
- awrmc 5y ago
  >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 In my experience Qt apps behave much better on Windows and Mac because they're designed to be native first. GTK was never designed to do that, it started out as a clone of Motif and it only ran on Unix, the cross-platform support was added later when some Windows developers wanted to port GIMP to Windows. To me GIMP and Inkscape always had some weird GTK widgets that don't look or act anything like Win32 widgets. I'd say use Qt if you want a better native experience on mac and windows. >The GNOME team never opened libadwaita for public comment, or held any forums where I could voice concerns with the direction they were headed. I can understand how this all sounds accusatory, but I really do recommend that you research it. I've researched it. This isn't how open source works, projects are not driven by public comments on forums. They're driven by people showing up to work together on a shared goal. Those who show up and write the code, get to be the decision makers. >The community has been completely locked out of the GNOME decision-making process. It doesn't make much sense to say this, the whole point here is the community makes the decisions for itself and nobody else. Every single contributor past the original founders are from the community. >They won't accept contributions that allow cross-platform stylesheets >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 I've no idea where you got this. I've never seen any comments from libadwaita developers to suggest that. This doesn't need to be contributed either, if you have a stylesheet you want to work on you can just ship it as part of your app, or create another add-on library for platform extensions similar to this: https://github.com/GNOME/gtk-mac-integration https://github.com/GNOME/gtk-mac-integration Regardless of where it ends up, the styles for GIMP on Win32 is just a theme, if that's not available in newer versions then somebody needs to port it to the new theming system. You could wait for a GIMP contributor to do it but that might take a long time. >It was a really good library until it hit v14, when the developers lobbed off support for Glade files I might still be misunderstanding, but the break was caused by GTK4. The GTK3 bindings are a separate crate. You can use those until the GTK4 gui designer is released. Breaking glade wasn't done on purpose. >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 I can't really figure out what you mean for sure but I did some searches. Closure support is still there but it appears to have been moved to another crate called gtk-rs-core. https://gtk-rs.org/gtk-rs-core/stable/0.14/docs/glib/closure/struct.Closure.html https://gtk-rs.org/gtk-rs-core/stable/0.14/docs/glib/closure... https://gtk-rs.org/gtk-rs-core/stable/0.14/docs/glib/macro.clone.html https://gtk-rs.org/gtk-rs-core/stable/0.14/docs/glib/macro.c...

by awrmc 5y ago

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.

awrmc 5y ago
>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 In my experience Qt apps behave much better on Windows and Mac because they're designed to be native first. GTK was never designed to do that, it started out as a clone of Motif and it only ran on Unix, the cross-platform support was added later when some Windows developers wanted to port GIMP to Windows. To me GIMP and Inkscape always had some weird GTK widgets that don't look or act anything like Win32 widgets. I'd say use Qt if you want a better native experience on mac and windows. >The GNOME team never opened libadwaita for public comment, or held any forums where I could voice concerns with the direction they were headed. I can understand how this all sounds accusatory, but I really do recommend that you research it. I've researched it. This isn't how open source works, projects are not driven by public comments on forums. They're driven by people showing up to work together on a shared goal. Those who show up and write the code, get to be the decision makers. >The community has been completely locked out of the GNOME decision-making process. It doesn't make much sense to say this, the whole point here is the community makes the decisions for itself and nobody else. Every single contributor past the original founders are from the community. >They won't accept contributions that allow cross-platform stylesheets >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 I've no idea where you got this. I've never seen any comments from libadwaita developers to suggest that. This doesn't need to be contributed either, if you have a stylesheet you want to work on you can just ship it as part of your app, or create another add-on library for platform extensions similar to this: https://github.com/GNOME/gtk-mac-integration https://github.com/GNOME/gtk-mac-integration Regardless of where it ends up, the styles for GIMP on Win32 is just a theme, if that's not available in newer versions then somebody needs to port it to the new theming system. You could wait for a GIMP contributor to do it but that might take a long time. >It was a really good library until it hit v14, when the developers lobbed off support for Glade files I might still be misunderstanding, but the break was caused by GTK4. The GTK3 bindings are a separate crate. You can use those until the GTK4 gui designer is released. Breaking glade wasn't done on purpose. >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 I can't really figure out what you mean for sure but I did some searches. Closure support is still there but it appears to have been moved to another crate called gtk-rs-core. https://gtk-rs.org/gtk-rs-core/stable/0.14/docs/glib/closure/struct.Closure.html https://gtk-rs.org/gtk-rs-core/stable/0.14/docs/glib/closure... https://gtk-rs.org/gtk-rs-core/stable/0.14/docs/glib/macro.clone.html https://gtk-rs.org/gtk-rs-core/stable/0.14/docs/glib/macro.c...