Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 20 22:07
    garetxe opened #272
  • Jan 15 10:12
    GordonGgx closed #271
  • Jan 15 08:42
    GordonGgx opened #271
  • Jan 11 01:36
    covert8 closed #269
  • Jan 09 17:03
    garetxe commented #270
  • Jan 09 17:02

    garetxe on master

    update urls in haskell-gi-base.… (compare)

  • Jan 09 17:02
    garetxe closed #270
  • Jan 09 10:32
    juhp opened #270
  • Dec 29 2019 17:47

    garetxe on master

    Always use cabal 3.0 for CI (compare)

  • Dec 29 2019 17:46

    garetxe on master

    Always use cabal 3.0 for CI (compare)

  • Dec 29 2019 17:43

    garetxe on master

    Always use cabal 3.0 for CI (compare)

  • Dec 29 2019 17:42

    garetxe on master

    Always use cabal 3.0 for CI (compare)

  • Dec 29 2019 16:56

    garetxe on master

    Do not fail fast for github CI (compare)

  • Dec 29 2019 16:44

    garetxe on master

    Store caches separately for sep… (compare)

  • Dec 29 2019 16:29

    garetxe on master

    Test different combinations of … (compare)

  • Dec 28 2019 23:29

    garetxe on master

    Remove Travis scripts Merge branch 'master' of github… (compare)

  • Dec 28 2019 23:23
    travis-bot-haskell-gi removed as member
  • Dec 28 2019 23:17
    jplatte removed as member
  • Dec 28 2019 23:08

    garetxe on master

    Remove Travis badge (compare)

  • Dec 28 2019 21:43

    garetxe on master

    Fix github CI (compare)

Iñaki
@garetxe
:)
Andri Möll
@moll
One other thing, if I may. http://hackage.haskell.org/package/gi-gdk-3.0.22/docs/GI-Gdk-Structs-EventKey.html#v:setEventKeyWindow takes a Ptr Window. Which of the https://hackage.haskell.org/package/haskell-gi-base-0.23.0/docs/Data-GI-Base-ManagedPtr.html functions seem appropriate to you to get a Ptr out to jam in a Gdk.eventNew? My initial crack went with Gtk.getWidgetWindow widget and passing that to withManagedPtr and then to setEventKeyWindow, but that seems to cause GTK go haywire and delete the widget. :P
I presume that's because GTK frees the associated GdkWindow, but nothing had incremented its use prior to me jamming it to that GdkEventKey struct.
Andri Möll
@moll
I threw a g_object_ref_sink in between the setEventKeyWindow call and it seems to have fixed the premature deletion issue.
It certainly would be better if setEventKeyWindow would take a ManagedPtr and call ref on it itself.
Iñaki
@garetxe
The issue is that you are putting a pointer inside a struct, so the bindings lose track of it, and cannot ensure that there is no leak
Andri Möll
@moll
That looks like an one of those label overflow things. I'm keeping it simple with "plain" functions. :)
Iñaki
@garetxe
So by default we do the safe thing, and ask the person using the bindings to be explicit, by passing the ptr
But :&=says that it is fine to allocate
Andri Möll
@moll
It is a struct, but isn't GTK free-ing all related ref counted fields if one calls its g_object_free or smth on it? I remember seeing the event-copy function mentioning that it increases the ref counts on its members.
Iñaki
@garetxe

That looks like an one of those label overflow things. I'm keeping it simple with "plain" functions. :)

Oh :) Then you need to do something like what you did

Andri Möll
@moll
I suppose technically Haskell GI could ensure no-leaks if it ensured the return value of Gdk.eventNew came with a finalizer that unref-ed the event which in turn would, presumably, unref its fields.
Iñaki
@garetxe

It is a struct, but isn't GTK free-ing all related ref counted fields if one calls its g_object_free or smth on it? I remember seeing the event-copy function mentioning that it increases the ref counts on its members.

Unfortunately haskell-gi cannot know this, from the point of view of the introspection data there is no information saying "this field will be freed when the struct is freed". So we have to play it safe

Andri Möll
@moll
Elsewhere there is referencing introspection? So far Haskell GI seems to know when you ref things. :P
Iñaki
@garetxe

I suppose technically Haskell GI could ensure no-leaks if it ensured the return value of Gdk.eventNew came with a finalizer that unref-ed the event which in turn would, presumably, unref its fields.

Yeah, but this would mean treating GdkEvent specially, and I want to keep my sanity :) Luckily gtk4 fixes this to a large extent, GdkEvent gains accessor functions with well defined memory management.

Elsewhere there is referencing introspection? So far Haskell GI seems to know when you ref things. :P

Yes, the problem is that is is a struct field. Generally we can do things nicely when there is a setter function, but this is not the case (generally) for struct fields

Andri Möll
@moll
Ah, okay, so GdkEvent's fields are derived from structs and not from more informative introspection of setters.
Thanks. Got it.
Iñaki
@garetxe
Right, they are a thin wrapper over setting a pointer. We know the type, so we can help a bit, but we don't know the memory ownership semantics
(Although if you allow yourself to use overloading :&=papers over this complication.)
Andri Möll
@moll
The description accompanying :&=doesn't make much sense to my eyes. O:)
Iñaki
@garetxe
Yeah, I just realized that :D
Could you please file an issue? (Sorry, I don't have access now) This is definitely something to improve in the documentation
Andri Möll
@moll
Sure! I'm aiming for the most-issues-opened on Haskell GI award anyway. :P
Iñaki
@garetxe
:D It's really very helpful, thanks!
chenyulue
@chenyulue
Hi, are there some tutorials about gi-gtk? Except the hackage documents and examples
Andri Möll
@moll
I got a start with the examples in the repository, @chenyulue.
Whoops, you did mention the examples already. :innocent:
For the rest I personally went with general GTK tutorials and just translated the examples to Haskell GI-s style.
Apart from an example or two I'd say it's a better use of everyone's time to write tutorials for the original library in its original language and then separately a few on how to translate from the source language to the bindings' language. :P
chenyulue
@chenyulue
Thanks! @moll Mark Karpov's tutorial is also in my notes. Seems the general GTK tutorials is the only choice for learning haskell GUI programming with GTK+.
Karl Melvan
@kmelvn
trying to capture all key press and key release events on a GtkWindow - can't find the function for setting my handler for "key-press-event" and "key-release-event"?
I'm not using overloading, so something like onWidgetKeyReleaseEvent? can't find it in the docs...
Karl Melvan
@kmelvn
oh, I'm looking at 4.0.1 docs and using 3.0.32 ... oh, there's new version :)
due43
@due43
hello
First time using this forum
I am unclear on ManagedPtr, when do I disown or own an object? I want to be able to lookup windows by name, and figured I needed to store a map from name to weak ref
You see the lookups happen according to user input, so I want to allow that objects they indicate might have been cleaned up by gtk already, and in particular I dont want the fact that I have a name for an object to keep it from getting cleaned up if it's reference count would otherwise drop to 0...
due43
@due43
So I envisioned something like (mp :: Map Text GWeakRef) ... But I don't even know how to create a GWeakRef using haskell
and ManagedPtr's machinery makes me wonder if I can use it as a weakref, by disown/own
due43
@due43
I understand ManagedPtr is like ForeignPtr, but allows finalizers to be toggled on and off.. But I wish the documentation was more clear about what said finalizers do in the bindings, so I understood when I would want to toggle them.
Iñaki
@garetxe
Hi! Sorry for the slow reply, I just saw your message
Yes, a ManagedPtr is essentially a ForeignPtr that can be "disowned", meaning that the finalizer can be discarded.
The finalizer is almost always some sort of *_unref function, that releases the reference the Haskell value keeps to the GObject (or boxed value, etc.)
The rule of thumb is that you don't need to worry about owning/disowning from the Haskell side at all: if the annotations are correct then a reference to the underlying object will be created when the Haskell wrapper is created, and when the Haskell wrapper is garbage-collected the reference will be dropped.
Iñaki
@garetxe
I don't think that using ManagedPtr here is the right solution, at least currently, since it provides no safety net: if the underlying pointer becomes invalid the ManagedPtr will not know, and the program will probably crash.
(But adding such a safety net is a good idea, I just opened haskell-gi/haskell-gi#272)
Regarding your actual issue, I think that if I implement haskell-gi/haskell-gi#272 (and added a small API to ensure that the underlying object had not been destroyed) would cover your use case. I will try to implement this as soon as I get a chance.