since migrating to GTK 4 I keep getting issues with accessing disowned pointers when using event controllers
haskell-gi tells me that the call to widgetAddController is disowning the pointer, the problem being that there are many callbacks in the application that use the event controller
WARNING: Accessing a disowned pointer <0x00000000649d0680>, this may lead to crashes.
• Callstack for the unsafe access to the pointer:
CallStack (from HasCallStack):
notOwnedWarning, called at .\\Data\\GI\\Base\\ManagedPtr.hs:194:25 in haskell-gi-ba_-0.25.0-e54f296d31598ac13124f52c63d6d957a696495e:Data.GI.Base.ManagedPtr
unsafeManagedPtrCastPtr, called at .\\GI\\Gtk\\Objects\\GestureSingle.hs:584:17 in gi-gtk-4.0.4-f0386fac927306f5dfd453fb2b725fbcae403b0c:GI.Gtk.Objects.GestureSingle
gestureSingleGetCurrentButton, called at src/app\MetaBrush\Event.hs:106:25 in main:MetaBrush.Event
• The pointer was disowned at:
CallStack (from HasCallStack):
disownManagedPtr, called at .\\Data\\GI\\Base\\ManagedPtr.hs:335:15 in haskell-gi-ba_-0.25.0-e54f296d31598ac13124f52c63d6d957a696495e:Data.GI.Base.ManagedPtr
disownObject, called at .\\GI\\Gtk\\Objects\\Widget.hs:5847:20 in gi-gtk-4.0.4-f0386fac927306f5dfd453fb2b725fbcae403b0c:GI.Gtk.Objects.Widget
widgetAddController, called at src/app\MetaBrush\Application.hs:489:3 in main:MetaBrush.Application
I don't have a simple reproducer and maybe I'm just doing something stupid but at the moment I'm confused because it looks like any use of event controllers runs into this issue
or maybe this is just to be expected? adding the event controller to the widget means the widget now controls the lifetime of the event controller, and if there are any callbacks that refer to this event controller I must ensure they stop happening if the widget is no longer around?
Hi @sheaf:matrix.org ! Yes, this is expected: the controller is marked as
(transfer null) in the introspection data, which means that managing its memory becomes the responsibility of the widget. And in particular, haskell-gi has no way of knowing if the underlying pointer it's alive after the call (well, currently, in principle it could detect it, but I haven't implemented it yet).
But perhaps there is a way so that you don't need to access it explicitly after adding it to the widget. How does the callback code look like?
I have callbacks of the form
void $ GTK.afterGestureClickPressed viewportClicksController
( handleMouseButtonEvent viewportClicksController )which monitors clicks in a certain drawing area for user interaction over that area
and
handleMouseButtonEvent gestureClick nbClicks x y has code like do { button <- GTK.gestureSingleGetCurrentButton gestureClick; handleAction (MouseClick (Point2D x y) button nbClicks) }, usual stuff really
so all in all I'm just adding some event controllers to a drawing area so that the user can interact with it to draw stuff on it etc
the drawing area is going to be present for the lifetime of the application so I assume this isn't going to be an issue based on what you said, thanks for taking the time to answer
In C this is not an issue, because the callback receives the pointer to self, but in the Haskell bindings we omit it
It will not be an issue in practice, no, but let me think if I can come up with a way of avoiding the warnings here
This is not very hard to fix (we just need to expose the
self argument in the callback somehow), but I need to think about the best way to expose this in the bindings
Maybe an opportunity to use implicit parameters? :)
hi @garetxe , the fix using implicit parameters seems absolutely fine to me, and I think seeing the implicit parameter in the callback type in the haddocks should give users enough to go on to figure this out
I'm unsure about how to try out the commit, usually I add a
source-repository-package stanza to my cabal.project pointing to that commit but I can't do that here, could you advise?
I assume I have to clone the repository myself and then run some code generation step first?
hi @sheaf:matrix.org ! I am not sure why that wouldn't work. Just to be clear: you only need the latest
haskell-gi and haskell-gi-base from github, the bindings themselves (the gi-* packages) in hackage should be OK. Just make sure that they are regenerated (removing your .dist-newstyle should do the job).
Please make sure that you use commit haskell-gi/haskell-gi@04bf16a, I have changed some things there
ah, I didn't realise I only needed to change haskell-gi and haskell-gi base, I'm trying that now and will let you know, thanks
However, I am a bit stumped how to configure / setup my project to use GTK4 with stack
I tried adding "gi-gtk-4.04" to the "extra-deps" property of the "stack.yaml" file, but then I run into trouble with mismatched dependencies
Is there an example project or howto how to use GTK4 + haskell-gi and stack?
Is there an example project or howto how to use GTK4 + haskell-gi and stack?
Unfortunately nothing that I am aware of. It should be possible to do by adding enough packages to your stack.yaml, there is some relevant discussion in haskell-gi/haskell-gi#339
Nevertheless, if you have a chance I highly recommend trying
cabal before going into that. At least for building haskell-gi generated bindings it is often easier with cabal.
How would you translate
new Gtk.Window [ On #destroy Gtk.mainQuit ]
`to code that doesn't use labels?
Also: I'm trying out the WebKit example, and the text is much smaller than compared to other browsers
Is it supposed to be like this? Is it perhaps because of NixOS?
I also see the text slightly small here. It is not intentional, it seems to be due to defaults in webkit. You can check by opening "Epiphany", Gnome's web browser, which is also based on WebKit.
At least in my computer both epiphany and the webkit example display text at the same size.
If you figure out how to make the default a bit larger I would gladly welcome a pull request :)
@garetxe: Thanks for confirming my suspicion, Epiphany shows much larger text (that is within the normal range, albeit a bit smaller than what Firefox displays). What I get on https://haskell.org is text so small that it's hard to even read. It's likely a problem with my nix derivation for it then.
Hi! I'm currently trying to combine some concepts of gi-gtk-declarative with the reflex-gi-gtk library, but i've hit a (seeming) dead end for me.
I want to write an equivalent of https://hackage.haskell.org/package/gi-gtk-declarative-0.7.0/docs/src/GI.Gtk.Declarative.Bin.html#bin for a reflex-based application