gi-gdkpixbuf-2.0.26 fix

[rvl]

Makes it buildable with gi-gdkpixbuf 2.0.26 and prior versions.

See also: taffybar/gtk-sni-tray#25

[colonelpanic8]

Thanks!

[colonelpanic8]

I think the right way to fix this is to bump the gdk-pixbuf version

[rvl]

I think the right way to fix this is to bump the gdk-pixbuf version.

I was considering that, rather than using ugly CPP.
But the gi- dependencies tend to be horrible with cascading updates of transitive dependencies.
So I think it would be kinder to users to support both.

Also, this gi-gdkpixbuf API change seems like a bug to my inexperienced eye. Because returning NULL from that function means the gerror code should be checked and an IOException thrown - instead of returning Nothing.

[colonelpanic8]

I think the right way to fix this is to bump the gdk-pixbuf version.

I was considering that, rather than using ugly CPP.
But the gi- dependencies tend to be horrible with cascading updates of transitive dependencies.
So I think it would be kinder to users to support both.

@rvl Right I don't disagree that both should be supported, but the way you fixed the nixbuild was to use a patch for gtk-sni-tray. Seems like the right way to fix things is to bump the gtk-sni-tray version, and then apply the fixes to taffybar in a separate update.

Also, this gi-gdkpixbuf API change seems like a bug to my inexperienced eye. Because returning NULL from that function means the gerror code should be checked and an IOException thrown - instead of returning Nothing.

Not convinced, but probably not worth trying to figure it out.

[rvl]

OK, thanks for applying my compile fix. 👍
The nix build change was mostly just so I could test it while the gtk-sni-tray patch was unmerged and unreleased.

[rvl]

BTW I put my name down as maintainer for the taffybar package in nixpkgs.
Please do let me know if you need anything or have any news related to distro packages of taffybar.

[podiki]

Hi @rvl, wondering if you have any thoughts on this. Getting an error on building taffybar 3.2.5 with gi-gdkpixbuf 2.0.26, haskell-gi 0.25 that looks like that was fixed. (This is on guix actually, but I think I have it set up to be like a current cabal build. gtk-sni-tray 0.1.6.2 builds fine in same environment.) Chatting on the taffybar gitter it was suggested to check with the haskell-gi folks, which I will do, but thought I'd check in here first since it seemed you had a handle on this before.

Thanks!

End of build log (ignore the ?, some formatting issue on my end):

[27 of 65] Compiling System.Taffybar.Widget.Util ( src/System/Taffybar/Widget/Util.hs, dist/build/System/Taffybar/Widget/Util.o )

src/System/Taffybar/Widget/Util.hs:162:38: error:
    ? Couldn't match type ?PB.Pixbuf? with ?Maybe PB.Pixbuf?
      Expected type: IO (Either GError (Maybe PB.Pixbuf))
        Actual type: IO (Either GError PB.Pixbuf)
    ? In the second argument of ?($)?, namely
        ?catchGErrorsAsLeft
           $ PB.pixbufNewFromFileAtScale name (- 1) height True?
      In the expression:
        fmap (handleResult . first show)
          $ catchGErrorsAsLeft
              $ PB.pixbufNewFromFileAtScale name (- 1) height True
      In an equation for ?pixbufNewFromFileAtScaleByHeight?:
          pixbufNewFromFileAtScaleByHeight height name
            = fmap (handleResult . first show)
                $ catchGErrorsAsLeft
                    $ PB.pixbufNewFromFileAtScale name (- 1) height True
            where
                handleResult
                  = join . fmap (maybe (Left "gdk function returned NULL") Right)
    |
162 |   fmap (handleResult . first show) $ catchGErrorsAsLeft $

[rvl]

Hello @podiki - in nixpkgs taffybar is building against gi-gdkpixbuf-2.0.24. You could try that.

Or, check that you really have gi-gdkpixbuf-2.0.26 though. That error message doesn't seem to line up with the docs on Hackage: https://hackage.haskell.org/package/gi-gdkpixbuf-2.0.26/docs/GI-GdkPixbuf-Objects-Pixbuf.html#v:pixbufNewFromFileAtScale

[podiki]

With gi-gdkpixbuf-2.0.24 that would be with older taffy bar and haskell-gi-0.24 then? I checked the downloaded source, it is 2.0.26 (change in overrides file) and taffybar is using the 2.0.26 code too.

Hmm...I'm confused (as someone pretty new to Haskell). Source of gi-gdkpixbuf that you linked to certainly seems to have that Maybe (and in other functions like pixbufnewfromfile), not sure what is happening here.

[rvl]

I'm also confused @podiki. 😕

The Maybe change in gi-gdkpixbuf seemed wrong or unnecessary to me. Nonetheless, I added an #ifdef to taffybar so that it would compile with both .24 and .26 versions.

But perhaps this API change happened because of changes in haskell-gi(-base) or hsc2hs -- something like that? I believe that many if not all function signatures in gi-gdkpixbuf are generated from .gi interface definitions.

[colonelpanic8]

But perhaps this API change happened because of changes in haskell-gi(-base) or hsc2hs -- something like that? I believe that many if not all function signatures in gi-gdkpixbuf are generated from .gi interface definitions.

Yes they are all generated from .gi interface definitions. https://gi.readthedocs.io/en/latest/ I believe that maybe our heuristic for working out the type signature may not be working perfectly.