by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 11:36

    garetxe on master

    gi-wnck-3.0.9 gi-gtk-3.0.36 haskell-gi-0.24.4 (compare)

  • Aug 09 23:13
    garetxe commented #305
  • Aug 09 22:36
    amcphail opened #305
  • Aug 09 20:37
    garetxe commented #304
  • Aug 09 20:24
    venanzio closed #304
  • Aug 09 20:24
    venanzio commented #304
  • Aug 09 19:37
    garetxe commented #304
  • Aug 09 19:25
    garetxe commented #304
  • Aug 09 17:09
    venanzio opened #304
  • Aug 08 10:30
    garetxe commented #303
  • Aug 08 10:28
    garetxe commented #303
  • Aug 08 05:06
    Magicloud commented #303
  • Aug 08 04:33
    Magicloud commented #303
  • Aug 08 04:31
    Magicloud commented #303
  • Aug 08 04:28
    Magicloud commented #303
  • Aug 07 18:18
    Magicloud commented #303
  • Aug 07 17:39
    Magicloud commented #303
  • Aug 06 21:59
    garetxe commented #303
  • Aug 06 21:47
    garetxe commented #243
  • Aug 05 15:36
    deech commented #243
Ivan Malison
@IvanMalison
yeah, so as far as i can tell, the parent types for window are defined here: http://hackage.haskell.org/package/gi-gdk-3.0.21/docs/src/GI.Gdk.Objects.Window.html#line-1444
which means we can't further extend the type family, so i mean
its unclear to me how http://hackage.haskell.org/package/gi-gdkx11-3.0.8/docs/src/GI.GdkX11.Objects.X11Window.html#line-154 would ever get used, since it is a descendant of Gdk.Window
Ivan Malison
@IvanMalison
okay looking into it more, it seems i have misunderstood the inheritance hierarchy
i guess i need to use x11WindowForeignNewForDisplay to get an X11WIndow instance
Iñaki
@garetxe

I would be willing to do all of these things if you are willing to merge the associated changes

Certainly, this sounds like a good idea, I would be happy to merge the changes.

but its weird because unlike with type classes this doesn't seem to be ad hoc extensible

Yes, that's right, it's not ad hoc extensible. But that should be OK, what this is encoding is the underlying GObject inheritance hierarchy, and this is not something that users of a library can change (it is fixed when you register the type).

The change was motivated by the support for creating custom GObject types from Haskell that I added a while ago, see https://github.com/haskell-gi/haskell-gi/blob/master/examples/advanced/CustomGObject.hs and https://github.com/haskell-gi/haskell-gi/blob/master/examples/advanced/CustomButton.hs
(The exposed interface is still a bit experimental, but it works.)
Iñaki
@garetxe
The old approach using ordinary instances made creating new types a pain, since one would need to add instances for all the parent types. Now it's the much more concise
instance O.HasParentTypes CustomButton
type instance O.ParentTypes CustomButton = Gtk.Button ': O.ParentTypes Gtk.Button
(If you are creating a type descending from Gtk.Button, say, and you want all the methods of Gtk.Button to apply.)
The error messages should also be a little bit better this way.

Required ancestor ‘GI.GdkX11.Objects.X11Window.X11Window’ not found for type ‘GI.Gdk.Window’.
so im just using xid <- GdkX11.x11WindowGetXid =<< liftIO (unsafeCastTo X11Window gdkWindow)

This is not safe in Wayland, no? It might be safe during runtime if the code only supports X11, but the type system doesn't know whether you are running in Wayland or X11.

Iñaki
@garetxe
Using x11WindowForeignNewForDisplay looks correct.
Ivan Malison
@IvanMalison
x11WindowForeignNewForDisplay requires me to already have a x11 window id though
Iñaki
@garetxe
Oh, I see. Yes, if you already have a GdkWindow and want to get a X11Window out of it, a cast seems like the way to go.
simon-tud
@simon-tud
Is it possible to create a gtk container with a custom layout algorithm only using haskell code?
Ivan Malison
@IvanMalison
@simon-tud yes
or maybe not
Iñaki
@garetxe
@simon-tud Do you have some C/Python equivalent that does what you want?
simon-tud
@simon-tud
The naive way is to write some code and call it arbitarily but then I won't get the correct width and height from the child widgets so I assume the code has to be executed at the right time by the gtk loop? (I already came across the dance of calculating the preferred size and getting an actual size to deal with for the container).
simon-tud
@simon-tud
@garetxe I know that nautilus 2.30 had a custom layout algorithm which I could dig out. There were also those two pages talking about custom containers:
http://ptomato.name/advanced-gtk-techniques/html/custom-container.html
https://developer.gnome.org/gtkmm-tutorial/stable/sec-custom-containers.html.en
Iñaki
@garetxe
@simon-tud Looking to http://ptomato.name/advanced-gtk-techniques/html/custom-container.html, it seems doable, specially given the recent support in haskell-gi for GObject subclassing. But it is not straightforward, and it will probably require some hsc2hs glue code to be written by hand.
This sounds like a good idea for an advanced example showing the new subclassing capabilities, I can try to write the translation to Haskell when I get some time. Would you mind opening an issue, so I don't forget?
Ramiro Garay
@Kranioceros
I've been looking at the example of subclassing, but I don't understand how to use the objectClassInit method of the DerivedObject typeclass to define custom properties and signals. How can I, for example, define signals that do specific actions on the objects of the class if I don't have access to the objects? All that is available is the _klass parameter, which is a GObjectClass. Could someone point out to me how to achieve this?
It was a good exercise, it showed a number of shortcomings in the GObject support which should now be solved (in git HEAD, I will release new versions in some days)
@Kranioceros The same example also shows how to define properties for custom types, see https://github.com/haskell-gi/haskell-gi/blob/master/examples/advanced/CustomContainer.hs#L249
Defining new signals is trickier, and is not supported yet, unfortunately
Ramiro Garay
@Kranioceros
Okay, I see this is all fairly new in the library. It's not as if I really need these features, I'm just following the Gnome Developers tutorial on Gtk application development. Up to this point it has been really straightforward, but probably I should seek alternative solutions to subclassing.
In any case, thank you for taking the time to answer my questions
Iñaki
@garetxe
Sure!
Andri Möll
@moll
Damn that Gitter doesn't seem to have any way of searching the archive. Anywho, I've got a problem with getting any of the Haskell GI libraries to compile on GHC v8.4.3. They (e.g. gi-glib) keep on complaining about not finding Data.GI.CodeGen.CabalHooks. How would one go about debugging this? Thanks in advance!
I initially tried with Haskell-GI v0.21.5 from around April 2019, but it seems to be a problem with v0.22.6, too.
Haskell-GI itself compiles fine. It's only later when it gets to gi-glib that it fails.
Andri Möll
@moll
I saw GitHub issues regarding Stack, but this is with Cabal and its sandbox.
Andri Möll
@moll
Found the problem! I was disabling the static libraries (.as) globally via ~/.cabal/config through library-vanilla: False. This seemed to have broken GI libraries' custom-setup. Running cabal install with --ghc-option=-dynamic solved it.
Andri Möll
@moll
I noticed there have been backwards incompatible changes to Haskell GI lately. Is Haskell GI using semver and that's why it went to v0.22 from v0.21?
Where did v0.22.0–v0.22.2 go though? https://github.com/haskell-gi/haskell-gi/blob/master/ChangeLog.md jumps from v0.21.5 to v0.22.3.
Iñaki
@garetxe

Found the problem! I was disabling the static libraries (.as) globally via ~/.cabal/config through library-vanilla: False. This seemed to have broken GI libraries' custom-setup. Running cabal install with --ghc-option=-dynamic solved it.

Great, thanks for letting me know! I had seen this issue before, but I had no idea what caused it. I always resorted to removing the build cache, and that somehow fixed it.

I noticed there have been backwards incompatible changes to Haskell GI lately. Is Haskell GI using semver and that's why it went to v0.22 from v0.21?

Basically, yes. Although due to the way haskell-gi works, what this really means is the version of the API generated for the bindings, not the API of haskell-gi itself.

Where did v0.22.0–v0.22.2 go though? https://github.com/haskell-gi/haskell-gi/blob/master/ChangeLog.md jumps from v0.21.5 to v0.22.3.

Sorry, that's just me forgetting to update the ChangeLog.md file.

Iñaki
@garetxe
The full list of changes is easy to gather from the git log, I generally add a commit of the form Release haskell-gi-xxx when doing a release
Andri Möll
@moll
Okie. Thx.
Andri Möll
@moll
On topic others, do you by any chance have an idea why WebKit.settingsSetEnableWriteConsoleMessagesToStdout through Haskell seems to fail to have effect? It gets set, but console.logs never get printed to stdout. An independent test for WebKit in C confirms it works. Just in the Haskell runtime it doesn't seem to.
I know WebKit starts a separate process for its rendering. I wonder if it never gets the stdout file handle or what...
Iñaki
@garetxe
Not sure, sorry. The GHC runtime does various subtle things, so it's hard to tell. Are you using -threaded when compiling? If so, would you have a small testcase I could take a look to?
Andri Möll
@moll
I do have -threaded in ghc-options. I'll put a minimal test case up when I get back to it. Thanks for the offer to help!
Andri Möll
@moll