Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 18:51
    moll opened #258
  • 18:50
    moll edited #257
  • 18:49
    moll opened #257
  • 18:25
    moll opened #256
  • Aug 19 14:05
    portnov edited #255
  • Aug 19 14:04
    portnov opened #255
  • Aug 19 09:31
    chenyulue opened #254
  • Aug 18 23:04
    moll opened #253
  • Aug 16 14:14
    moll opened #252
  • Aug 13 23:38
    moll opened #251
  • Aug 13 22:34
    santiweight commented #243
  • Aug 13 22:09
    moll opened #250
  • Aug 13 21:22
    moll opened #249
  • Aug 13 16:09
    moll commented #248
  • Aug 13 15:25
    moll edited #248
  • Aug 13 15:24
    moll opened #248
  • Aug 08 20:38
    garetxe commented #247
  • Aug 08 20:37
    garetxe commented #247
  • Aug 08 19:57
    juhp commented #247
  • Aug 08 19:56
    juhp edited #247
Iñaki
@garetxe

It's not often you see a function that takes an array of IOs and wants to do the sequenceing for you... I'm not even sure whether that's weird or convenient. ^_^

:D Honestly I can't recall why it does that, probably convenience at some point (currently the generated bindings don't use it anymore). I could change it, but I think there are some projects using it, so perhaps not worth making it more "normal".

Hey! Is there a reason https://hackage.haskell.org/package/gi-webkit2-4.0.24/docs/GI-WebKit2-Objects-WebsiteDataManager.html#v:constructWebsiteDataManagerBaseDataDirectory is in the IO monad as opposed to MonadIO as all the other functions are?

No good reason, it should be easy to change. A pull request would be appreciated, otherwise feel free to open an issue so I don't forget to do it.

Andri Möll
@moll
Created haskell-gi/haskell-gi#246. One day I'm bound to learn how to build Haskell GI manually and run its tests. :)
Do you yourself use Haskell GI to build an end-user facing GTK app, too, or have you just ended up responsible for it without actually using it in anger? :)
Iñaki
@garetxe

Created haskell-gi/haskell-gi#246. One day I'm bound to learn how to build Haskell GI manually and run its tests. :)

:) Thanks for the reminder! I just implemented this.

Do you yourself use Haskell GI to build an end-user facing GTK app, too, or have you just ended up responsible for it without actually using it in anger? :)

I actually started working on this because I wanted to play with GUIs in Haskell, but then got distracted writing haskell-gi itself :) (based on some prior work by Will Thompson). These days I spend most of my time on the bindings themselves, although sometimes I do write small apps for personal use.

Andri Möll
@moll
Hey again! Am I correct in assuming that one can't really define the libsecret schema from Haskell to use password attributes? http://hackage.haskell.org/package/gi-secret-0.0.11/docs/GI-Secret-Structs-Schema.html
There are funcs for creating said attributes (http://hackage.haskell.org/package/gi-secret-0.0.11/docs/GI-Secret-Structs-SchemaAttribute.html), but adding them to a schema struct seems missing.
you will see XXX Could not generate method Schema::new due to missing support for some GHashTable methods. Probably easy to add, could you please open an issue so I don't forget to look into this? Thanks!
Andri Möll
@moll
Great. Will do. Thank you!
Andri Möll
@moll
As requested: haskell-gi/haskell-gi#248 :)
Iñaki
@garetxe
Great, thanks! :)
Andri Möll
@moll
Here's my work-around for that one other fellow still in his diapers that wants to use libsecret from Haskell in the future: https://github.com/haskell-gi/haskell-gi/issues/248#issuecomment-520901023
Andri Möll
@moll
I'm trying to construct and trigger a keyboard event manually. The web has led me to https://mail.gnome.org/archives/gtkmm-list/2007-June/msg00115.html — that is, creating a new GdkEvent and filling in its keyboard properties (http://hackage.haskell.org/package/gi-gdk-3.0.22/docs/GI-Gdk-Unions-Event.html). I don't, however, see any way to set the Event keyboard modifiers. They are available in http://hackage.haskell.org/package/gi-gdk-3.0.22/docs/GI-Gdk-Structs-EventKey.html, but not in the more general event type. Any idea what's going on there? Thanks in advance!
mainDoEvent (https://hackage.haskell.org/package/gi-gtk-3.0.32/docs/GI-Gtk-Functions.html#v:mainDoEvent) seems to strictly want an Event, too, so going with EventKey doesn't seem to do the trick.
Iñaki
@garetxe
Would it work to construct an EventKey and then use coerce when calling mainDoEvent?
Andri Möll
@moll
Wow, quick reply, thanks! Let me find out!
It seems to type check. ^_^
My event doesn't seem to work, but that could be that I'm missing some fields.
Thanks!
Iñaki
@garetxe
You're welcome!
Andri Möll
@moll
Btw, Gdk type links seem to be broken on Hackage — https://hackage.haskell.org/package/gi-gtk-3.0.32/docs/GI-Gtk-Objects-Widget.html#v:getWidgetWindow should probably link to GdkWindow.
Want another issue for that? :P
Iñaki
@garetxe
Yep, please! Probably the same as the other one you reported recently (sorry, a bit busy lately), but it won't harm to have it there just in case.
Andri Möll
@moll
No hurry. It's OSS — nothing's stopping me from jumping in and fixing things myself. ^_^
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!