Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:11
    clkamp closed #273
  • 10:11
    clkamp commented #273
  • 10:11
    clkamp edited #273
  • 10:10
    clkamp edited #273
  • 10:10
    clkamp edited #273
  • 10:10
    clkamp edited #273
  • 10:10
    clkamp edited #273
  • 10:09
    clkamp edited #273
  • Feb 18 22:08

    garetxe on gi-gio-2.0.26

    (compare)

  • Feb 18 22:07

    garetxe on master

    Mark the return value of appInf… (compare)

  • Feb 18 22:05
    garetxe commented #276
  • Feb 18 14:14
    phuhl commented #276
  • Feb 18 14:11
    phuhl commented #276
  • Feb 18 14:09
    phuhl edited #276
  • Feb 18 14:08
    phuhl opened #276
  • Feb 17 17:37
    jmazon opened #275
  • Feb 12 15:23
    clkamp edited #273
  • Feb 12 15:21
    clkamp edited #273
  • Feb 09 22:13
    garetxe commented #274
  • Feb 09 22:04
    garetxe commented #274
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.