Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 07 22:06
    goose121 closed #286
  • Apr 07 22:06
    goose121 commented #286
  • Apr 07 10:24
    garetxe commented #286
  • Apr 07 10:23
    garetxe commented #287
  • Apr 07 07:17
    mjepronk commented #287
  • Apr 07 07:16
    mjepronk closed #287
  • Apr 07 07:16
    mjepronk commented #287
  • Apr 07 03:40
    garetxe commented #288
  • Apr 07 03:40

    garetxe on master

    Fix gi-gtk-hs homepage (#288) (compare)

  • Apr 07 03:40
    garetxe closed #288
  • Apr 07 00:56
    leifmetcalf opened #288
  • Apr 06 19:28
    garetxe commented #287
  • Apr 06 19:16
    mjepronk commented #287
  • Apr 06 16:51
    garetxe commented #287
  • Apr 06 16:50

    garetxe on master

    Hackage does not support build-… (compare)

  • Apr 06 16:47

    garetxe on master

    haskell-gi-0.23.1 (compare)

  • Apr 06 16:15

    garetxe on master

    Try to resolve symbols before c… (compare)

  • Apr 06 06:54
    mjepronk commented #287
  • Apr 05 15:00
    garetxe commented #287
  • Apr 05 14:56
    mjepronk edited #287
santiweight
@santiweight
ah
i need control over the specific size of the gradients
so the goal would be to have the box filled 30% one colour 20% antoher etc
oh it seems that syntax does have that
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:)