GTK+ 3.90.0 Released, Advancing Towards GTK 4.0

[JonathanM]

Maybe it should be rewritten in something else than C?
Something object-oriented, perhaps C++ or Rust?

I don't see a transition to C++ happening. There seems to be some interest in Rust, but even if the Gtk/Gnome team would switch that transition would happen over many years. I'm just an outsider though, so I could be completely wrong.

A limitation in Gtk.Paned is that it can only have two children to resize between, so if you want a resize-able container on both sides you would to nest two Gtk.Paned in some weird hierarchy. Which is hackish, confusing and frustrating.

You could write your own container that fits your needs. Except that support for your new container won't be included in the themes of your user. (and if you want to theme it yourself you may need to make multiple stylesheets for multiple Gtk+3.0 versions. Its not worth the effort.) I really hope Gtk+4.0 will make custom containers and widgets more viable. Composing widgets out of common elements should make things better in Gtk+4.0.

Another bothering thing is that you have to explicitly call .show_all() everywhere because else the widgets wont show as they are not visible by default.

As far as I know this has been changed in changed in Gtk+4.0 (or 3.90, however you want to call it), widgets are now shown by default.

[Mateus Felipe]

Maybe it should be rewritten in something else than C?
Something object-oriented, perhaps C++ or Rust?
A non-object oriented language just isn't suitable for a widget toolkit. At least not to use it, but perhaps C is still a good choice because of bindings in many languages?

Sorry to tell you, but C++ is not Object-Oriented, and Rust does not even try to be.

[dkasak]

Maybe it should be rewritten in something else than C?
Something object-oriented, perhaps C++ or Rust?
A non-object oriented language just isn't suitable for a widget toolkit. At least not to use it, but perhaps C is still a good choice because of bindings in many languages?

Maybe not. Glib / gobject *are* object oriented: https://en.wikipedia.org/wiki/GObject

It must be very painful to write GTK applications in C.

So don't. I've done some hacking on gtk+ ( fixing bugs with combo boxes ). It's not so bad. If you need maximum performance, you need to use a low-level language. If not, use Python or whatever. That's why the bindings are there. Do you know Rust? Do you know C++? Are you saying that if gtk+ was written in either C++ or Rust, you'd quit writing stuff in Python? I don't think so. Maybe you haven't thought things through so well.

A limitation in Gtk.Paned is that it can only have two children to resize between, so if you want a resize-able container on both sides you would to nest two Gtk.Paned in some weird hierarchy. Which is hackish, confusing and frustrating.

I don't see what that has to do with your assertion that everything needs to be rewritten in another language. You're free to implement your own weird paned widget if you don't like GtkPaned.

Another bothering thing is that you have to explicitly call .show_all() everywhere because else the widgets wont show as they are not visible by default.

If you're using Glade / builder, you just set the top-level window as visible, and that's it. As for having to call show_all() "everywhere" ... it's once per top-level window you create. That's not "everywhere".

Other meandering complaints removed - just more of the same.

[uid313]

I don't see a transition to C++ happening. There seems to be some interest in Rust, but even if the Gtk/Gnome team would switch that transition would happen over many years. I'm just an outsider though, so I could be completely wrong.

There is Corrode for automatic source code translation from C to Rust.

You could write your own container that fits your needs. Except that support for your new container won't be included in the themes of your user. (and if you want to theme it yourself you may need to make multiple stylesheets for multiple Gtk+3.0 versions. Its not worth the effort.) I really hope Gtk+4.0 will make custom containers and widgets more viable. Composing widgets out of common elements should make things better in Gtk+4.0.

Yes, and I could write my own operating system and widget toolkit.
Gtk.Paned sucks and is limiting. For very simple things it works, but when you need more than one resize-able container then it gets frustrating and confusing with weird hacky, non-intuitive hierarchies.

As far as I know this has been changed in changed in Gtk+4.0 (or 3.90, however you want to call it), widgets are now shown by default.

Yes, I've heard so too. Which sounds great!

[uid313]

Sorry to tell you, but C++ is not Object-Oriented, and Rust does not even try to be.

What, C++ is not object oriented?

[uid313]

Maybe not. Glib / gobject *are* object oriented: https://en.wikipedia.org/wiki/GObject

Well it doesn't look or feel very object oriented with stuff like:
gtk_button_new_with_label("Ok") instead of new Gtk.Button("Ok")

And:
gtk_button_set_label(ok_button, "text") instead of button.set_label("text")

I don't see what that has to do with your assertion that everything needs to be rewritten in another language. You're free to implement your own weird paned widget if you don't like GtkPaned.

Oh it doesn't have anything to do with that. Those are two entirely different statements.
GTK could stay with C, but I just hope that there will be some improvements to Gtk.Paned because I find it lacking.

If you're using Glade / builder, you just set the top-level window as visible, and that's it. As for having to call show_all() "everywhere" ... it's once per top-level window you create. That's not "everywhere".

Other meandering complaints removed - just more of the same.

Yeah, I guess. But I found this non-intuitive and as a developer new to GTK+ this caused me to stumble a bit and has bit me a couple of times, where things I expect to be visible are not.
Luckily there is GtkInspector which is an amazing tool that has helped me a lot.

[JonathanM]

Well it doesn't look or feel very object oriented with stuff like:
gtk_button_new_with_label("Ok") instead of new Gtk.Button("Ok")

And:
gtk_button_set_label(ok_button, "text") instead of button.set_label("text")

That's because it's object orientation bolted on top of C, C doesn't have a nice object oriented syntax.

About Rust, I just read a mail on the Vala mailing list that referred to this:

...
In particular, Niko and Federico have been working on a GObject plugin for Rust that allows us to have a nice, almost Vala-esque, syntax for writing GObjects. It’s pretty exciting to watch a compiler hacker at work. After lots of talks about GObject design internals, performance hacks, re-entrancy protections, and more, I think we’re headed down a solid path to enabling our Object Oriented style of development, but from Rust.

Vala has a similar syntax to what you describe (button = new Gtk.Button.with_label("Ok"); button.set_label("text");), but If you don't like Vala you may soon be able to use Rust in a similar way.

[Guest]

Looking at librsvg and seeing the massive leaks trunk which don't exist in 2.40.16, I am not really sure using Rust in Gnome is a good idea for users.
It may be for developers but keep in mind users have to use this as well.

[nomadewolf]

Looking at librsvg and seeing the massive leaks trunk which don't exist in 2.40.16, I am not really sure using Rust in Gnome is a good idea for users.
It may be for developers but keep in mind users have to use this as well.

How is not using a modern and actually good programming language not good? Care to elaborate on that?
It doesn't have to be Rust. Go or C# would be good enough for me. Yes i said it: C# is actually a good language. M$ is responsible for loads of crap, but they did that right, for once!

[Guest]

How is not using a modern and actually good programming language not good? Care to elaborate on that?
It doesn't have to be Rust. Go or C# would be good enough for me. Yes i said it: C# is actually a good language. M$ is responsible for loads of crap, but they did that right, for once!

It's good for developers and enthusiasts who are motivated by innovation. Users don't want massive groundbreaking changes and have to deal with regressions on production systems. I don't want stuff to keep changing. Nobody has time for that. Gtk+ 3.22 is a good example of that sentiment.