unfortunately the gtk 4 have been late for years now
Announcement
Collapse
No announcement yet.
GTK Planning More Improvements In 2021 From Better Accessibility To Animation Framework
Collapse
X
-
Originally posted by HadrienG View PostThis is the core reason why GTK&friends try so hard to shoehorn relatively high-level programming language concepts into a C API, even though the result is a mess that is not really usable without reversing the transformation in every language-specific binding by translating every C API back into a high-level API (which leads to fat bindings, and thus lots of effort duplication).
- Likes 5
Comment
-
Originally posted by ssokolow View Post
I'd say GTK is ahead of the curve on that, given that it defines its APIs using GIR these days.
Heck, my perspective is "I love GObject APIs... I just wish I didn't have to use them with a toolkit that's become dominated by the concerns of the GNOME 3 HIG."
- Likes 2
Comment
-
I would like to see implicit animations that are enabled by default or can be enabled by just setting a property to true. So that the developer does not have to think about animations. Example, he calls _sidebar.show() or _sidebar.hide() and it should show/hide the sidebar with an smooth default animation. Because many developers want a nice app with animations but are not UI designers, and often care about the functionality more than the design and presentation.
Also the format of GtkBuilder .xml or .ui files is rather convoluted, and I found it pretty hard to hand-edit with a text editor because it has sibling elements instead of children elements. This format could be simpler. Maybe other formats like Qt's QML or XAML is easier.
- Likes 1
Comment
-
I was looking at the source and I'm wondering, with Gtk4 will it be possible to check the signals names at compile time?
I mean g_signal_connect() takes the signal by name and if the string is misspelled it only prints a warning and if the string is NULL it just returns 0.
Did I misunderstand something?
Comment
-
Originally posted by Alexmitter View Post
You never needed to use any of the Gnome HIG widgets, though most people realized that they are just better sooner or later in development.
gtk3-mushrooms is listed as abandoned by its maintainer.
It'd be nice to have the option of writing a native-feeling GUI using gtk-rs instead of using PyQt+rust-cpython.Last edited by ssokolow; 25 November 2020, 09:25 AM.
- Likes 2
Comment
-
Could be just my opinion, though.
- Likes 4
Comment
-
GTK and Qt are... meh.
Qt moves a lot faster and has lots of funding in comparison to GTK, but too much bugs as typical in projects governed by contract development.
GTK moves very slowly and has very slow management. Even worse, it's ruled by GNOME ultra-simplistic authoritarian madness.
We all are doomed. It needs to change ASAP or Linux desktop will lose the stuff it gained over years. The toolkit wars must end, more collaboration must happen.
Why GObject is based on C? What about migrating to C++?
What about making QTK?
Comment
-
Originally posted by jo-erlend View Post«- a new UI design tool, integrated with GNOME Builder»
That's been on my wish list for quite some time. You know, people said a lot of bad things about Visual Basic 6, but it really did make programming fun and easy for beginners and GtkBuilder with something like Glade integrated, I think would be a really great way to attract more beginners, but when done well, it's also a very productive way to do things.
Comment
Comment