search

idanarye / woab

Widgets on Actors Bridge - a GUI microframework for combining GTK with Actix
https://crates.io/crates/woab
MIT License
14 stars 1 forks source link

Support Gtk4 #49

Closed piegamesde closed 2 years ago

piegamesde commented 3 years ago

The major bump is slowly trickling down the ecosystem, and WoAB is one of the last on my dependency list.

idanarye commented 3 years ago

The main obstacle is the signal connection. With GTK3 I had BuilderExtManual::connect_signals which allowed me to provide a function for generating the signal closures. GTK4 doesn't have that. It's not a binding issue - GTK4 itself does not have gtk_builder_connect_signals_full. Instead, when the builder loads the XML, it automatically tries to connect the signals to existing functions in the binary.

Apparently this behavior can be overidden with something called BuilderScope, but gtk-rs have not figured that out themselves yet.

Another option is to forget about GtkBuilder's automatic(ish) signal connection, and do it manually(ish). I can dissect the XML (already doing it for [derive(woab::Factories)]), extract the signals, and store them in a separate vector added to woab::BuilderFactory. Then BuilderConnector::connect_to can just go over that vector and connect each signal. Of course - id-less objects need to have an id generated and added to them...

Another thing to consider is how to maintain support for GTK3. The options are:

  1. Completely drop support for GTK3. GTK4 is still new, so I'm not sure I can justify that...
  2. Use feature flags. This can be hard to maintain though...
  3. Make a brand new crate (woab4?) for GTK4, and maintain both crates.

I hate all these options, but if I can pull 2 off it should be the easiest to keep synchronized...

piegamesde commented 3 years ago

If BuilderScope is the recommended solution and the Rust bindings are working on implementing it, I suggest to simply wait for this to happen instead of doing temporary workarounds.

Regarding the upgrade path for this crate, all options are indeed bad in some way or another. Not that I'm against 2., but I'd like to note that Cargo assumes that crate features must not be mutually exclusive. Personally, I think having the whole crate move to Gtk4 entirely one day be the best option, with a gtk3 branch where important changes are backported.

idanarye commented 2 years ago

So apparently they chose to do it by adding a struct called BuilderRustScope which you can register callbacks into. This won't work for WoAB, because we don't want to pre-register the signals by names, but as part of it they've added RustClosure which seems like a safe way to create GTK usable closures - so maybe I can just implement BuilderScopeImpl myself and return RustClosures on the fly?

Either way, I'll have to wait for the next release of gtkrs4.

piegamesde commented 2 years ago

I think the features we need are release now

idanarye commented 2 years ago

Yes - which means we now have to decide whether or not to abandon GTK3. I think you and I are the only ones using WoAB, so it shouldn't be that much of an issue to completely drop support for it.

piegamesde commented 2 years ago

I'd be okay with putting gtk3 support onto a separate branch and slowly phase it out.

idanarye commented 2 years ago

So apparently we should no longer use Glade - we should use Cambalache instead. This adds a bit more complexity...

piegamesde commented 2 years ago

I haven't followed the recent development, but they seem to be still using the same file format*? I haven't used Glade for a while now, I always edit the XML manually. So in general I don't think this directly affects Woab.

* I know that there's a project with new UI files syntax, but as far as I know it also just compiles back to the old XML.

idanarye commented 2 years ago

I thought so too, but apparently Glade output some tags that GTK4 can't read. gtk4-builder-tool simplify --3to4 can deal with some of them (e.g. <packing>), but still leave some things (like <property name="shadow-type">) that GTK4 can't read.

I do use Glade - I find no virtue in manually editing XML files - so this is a dealbreaker for me. I also need to be able to use list boxes, which I currently can't with Cambalache.

piegamesde commented 2 years ago

The linked Cambalache issue is now resolved. Do we have any other blockers?

Also, given the improvements on gtk-rs for Gtk4, to which extend do we still actually need woab for writing applications? This might be a good opportunity to re-evaluate the fundamental concepts.

idanarye commented 2 years ago

The linked Cambalache issue is now resolved. Do we have any other blockers?

Akrasia?

Also, given the improvements on gtk-rs for Gtk4, to which extend do we still actually need woab for writing applications? This might be a good opportunity to re-evaluate the fundamental concepts.

Can you be more specific?

My main reason for creating WoAB was to write a GUI client that talks with a server via WebSocket. I wanted the GUI to respond to various events from from the server, and also send commands to it when the user interacts with the GUI. I find that the actors model was the best way to work with WebSockets like that, considering Rust's ownership model.

The fact that I managed to map so nicely the GUI events to actor messages was a bonus.

How does gtk4-rs solve these problems in a way that makes WoAB redundant?

piegamesde commented 2 years ago

How does gtk4-rs solve these problems in a way that makes WoAB redundant?

I mostly used WoAB for the state handling and the autoconnect of method callbacks. In Gtk 4, they added this templating feature that does the callback handling, and the Rust bindings seem to support it rather well. The state handling appears to have improved too, although it still looks really boilerplatey.

I'm thinking I'll rewrite my WoAB application in Gtk 4 from scratch and see how it goes; which features I'll miss most from WoAB ^^

piegamesde commented 2 years ago

I'm thinking I'll rewrite my WoAB application in Gtk 4 from scratch and see how it goes

So far, the port is going rather smoothly. Furthermore, the main pain points I previously had with Gtk have gotten way better since the addition of composite templates. Therefore, I personally have no need for WoAB anymore.

Thank you for this library and the excellent help all along the way.