Should be runtime check?

[elextr]

Shouldn't this be a runtime check, the need for the call depends on the version of glib being used, not the version being compiled against.

Wonder if there are any more like that?

Ahh FIF only finds this

[codebrainz]

I think the guards are just to stifle the compile-time deprecation warning, I don't think there's any harm in actually calling them, they just don't do anything any more, IIUC.

[elextr]

Yeah, but if its compiled against a new version the call is removed, but if its then run against an older version it will fail AFAICT.

[codebrainz]

Would have to check which version it was removed deprecated and whether we even support it anymore.

[elextr]

The test is right for deprecation, but we support back to 2.28. So if Geany is compiled against a glib newer than 2.36 it won't run on a version older than 2.36.

[codebrainz]

My guess is that nobody downgrades their glib, so someone who compiles it themselves or gets it from their distro package manager, or uses the win32 or OSX binaries (which embed fixed glib version), would never notice this bug.

[elextr]

Yeah, thats probably why there have been no bug reports, but its still wrong :)

[codebrainz]

When you change it to use the runtime check, you might need to do some tricks to avoid adding (yet another) "deprecated" warning at compile time. I think the gtk2 branch build is still "deprecated" warning-free :)

[b4n]

Hum… will the linker even accept the older version? It could in theory with this check alone, but I'm not sure it will with the rest of the GLib. Anyway, OK, if you want to change those go ahead, they do seem slightly dubious as you say, although I doubt anyone will actually suffer from them.

[xiota]

The links into the source don't seem to point where they're supposed to. Is it still relevant now that Geany has officially moved to GTK3?

[elextr]

This has probably been overtaken by the passage of time and 30+ glib versions, closing.