-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Package Ports #4
Comments
Here are some ports in progress. I haven't opened PR's for these yet:
A few tests are disabled because I haven't figured out how to simulate mouse events fully in Gtk4. For ImageView I'm running into a crash that suggests referencing and unreferencing GObjects is not being handled perfectly in Gtk4. It's weird: if I split the tests into two different runs, they run fine. It's only if all are run at once that the crash occurs (which occurs at sort of random times late in the tests). So I think we will have to plan for an extended transition period. I added this at the beginning of |
I ported a larger (intern) software to Gtk4 and have seen crashes as well. This is certainly something that needs to be fixed first.
yes, of course! |
OK, I'll submit a PR on that when I have time. The crash I encountered while porting ImageView is now fixed! |
Has this been fixed by reintroducing sigatom, or is that unrelated? |
That's unrelated. The main loop/libuv code, which I don't understand, is basically unchanged in Gtk4. When I saw in JuliaGizmos/GtkObservables.jl#34 that sigatom was still needed in Gtk, I reintroduced it in Gtk4. The fix for the GC issue was in b1ee58e. When C objects "owned" by GTK (meaning we should not unreference them) are garbage collected by Julia but resurface later, we have to add a reference to them every time they resurface, otherwise when they are garbage collected again they might have their reference count go to zero and be destroyed by GTK. Gtk4 uses GI annotations that tell you whether objects are owned by the library or the caller of a function and uses this to avoid leaking memory, but if it's not done right this sort of crash can happen. Did it help with your crashes? |
IMHO |
OK, that makes sense. I'll look into this over the weekend. |
OK, I removed |
Then, lets keep it there but it remains internally. |
Hi @jwahlstrand, what ist the current status of Gtk4? I think we should slowly think about a migration plan. We are stress testing Gtk4.jl in January in our internal software stack and then can give feedback. I think we should then "freeze" @timholy: What is with the Gtk research software in your lab? Would you consider moving to Gtk4 if it is ready to go? |
Cool, I have been using Gtk4 for small things myself but haven't really used large parts of the API beyond simple tests, including dialogs :). It will be good to try it on something bigger so we can iron out more problems. Feedback would be great. The worst problem I'm aware of currently is a lot of bugs on MacOS and Windows. It's annoying enough that I am still using Gtk.jl for most things. But there have been a lot of fixes in GTK since the version we currently use, 4.6.0, was released. I would like to update GTK4_jll and see how much things improve. I can see the point of migrating many packages at once, given the incompatibility of Gtk.jl and Gtk4.jl, but we are not there yet. |
Ok, thanks for the update. Then let's open an issue with known regressions to track the progress. What's the process for updating |
It's not trivial to update GTK4_jll because it requires Wayland 1.21, and as far as I can tell, upgrading Wayland_jll will require updating the Alpine RootFS to 3.17. This is why I haven't attempted to do it myself... |
Why? |
The recipe uses Alpine's
Wayland 1.21 appeared in Alpine 3.17, I think. Is there another way around this? |
You can try to install the package from a different repository, you can use that of 3.17, sometimes it works without wrecking the system. I don't remember the syntax by heart but there should be some examples in Yggdrasil |
Thanks, I'll try that. |
My porting effort so far has been really smooth. With the new |
GtkObservables and ImageView ports have been released, and the last "big" Gtk package port (ProfileView) is ready to go. I'm going to close this as finished. |
I think it makes sense to prepare packages for a potential Gtk4 migration and ideally do the transition for all packages at the same time. Otherwise we will get into trouble that Gtk and Gtk4 cannot be loaded at the same time. The following list should be updated with new ports:
The text was updated successfully, but these errors were encountered: