GTK2 ABI seems broken, at least on Windows

[Arioch]

First of all, there seems to be  no more GTK2 for Win32, only for Win64 - https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer

However, when you run the GTK2 hello-world the program fails with "there is no gtk_file_selection_get_selections entrypoint in DLL libgtk-win32-2.0-0.dll"

The introspection confirms it: https://gitlab.com/freepascal.org/lazarus/lazarus/uploads/264b57972ba6bbe1b241dd1ba01ff3ca/2022-09-08_13_42_50-Lister__fileinfo__-__C__Program_Files_GTK2-Runtime_Win64_bin_libgtk-win32-2.0-0..png

(from https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39887 )

https://developer-old.gnome.org/gtk2/stable/GtkFileSelection.html

This doc (official or no more?) has a lot of lines line

Code: C  [Select][+][-]

1. // gtk_file_selection_set_filename
2. #define gtk_file_selection_set_filename gtk_file_selection_set_filename_utf8

I had a short Discord chat with MSYS2 devs

Biswa96 — Сегодня, в 6:08
There are some aliasing between gtk_file_selection_get_selections and gtk_file_selection_get_selections_utf8. See gtkalias.h and gtkaliasdef.c files in gtk2 source code.

Arioch — Сегодня, в 6:09
Ooops, so i would need sources... Are them there in git? So i won't need the whole pack?
Also, there should be some documentation, why what tag done and what did it mean. ABI breaking should have meaning attached

Biswa96 — Сегодня, в 6:11
You do not need source code for normal use cases. There is no ABI breakage. The symbol is just aliased like that. Docs also says

#define gtk_file_selection_get_selections gtk_file_selection_get_selections_utf8
"gtk_file_selection_get_selections is deprecated and should not be used in newly-written code."

Arioch — Сегодня, в 6:13
Well, there was ABI exported symbol, then it ceased to be. It was breaking. Okay, that is the start... Those two source files are in the msys2 repo?..

Biswa96 — Сегодня, в 6:14
Please read the documentation carefully. The DLL exports gtk_file_selection_get_selections_utf8 then it gets aliased in preprocessor to gtk_file_selection_get_selections for backward compatibility.

Arioch — Сегодня, в 6:15
Ahem, i'd like to, but gtk.org only hosts docs for gtk 3 and 4

Biswa96 — Сегодня, в 6:15
I read the docs from your provided links in that GitHub issue.

Arioch — Сегодня, в 6:16
I think the app in question was compiled before that aliasing was made.
Maybe i even have some 10 years ago gimpwin distros to see.

Those were not official docs, or i did not identified them like that.
Okay, thanks, at least some pointers. I am not at the desktop anyway, so would remain for later.

Biswa96 — Сегодня, в 6:17
Then the app need a fix.

Arioch — Сегодня, в 6:18
Perhaps. But i needed to make sure with some specific reasoning, rather than jumping out saying "your app is at fault, i think so"

There seems to be no aliasing in LCL, example

both fpcsrc\packages\gtk1\src\gtk\gtkfilesel.pp and fpcsrc\packages\gtk2\src\gtk+\gtk\gtkfilesel.inc

Code: Pascal  [Select][+][-]

1. function  gtk_file_selection_get_filename (filesel:PGtkFileSelection):Pgchar;cdecl;external gtkdll name 'gtk_file_selection_get_filename';
2.  

It probably was added later than GTK 2.0.0 but it seems no one knows for sure when and why,

If such code still runs on Linux - then perhaps there is some added backward compatibility layer, that was nremoved form Windows. Or at least from MSYS2, who make compiled GTK2 runtime installers now.

[AmatCoder]

It probably was added later than GTK 2.0.0 but it seems no one knows for sure when and why

*_utf8 functions was added in GTK 2.6, reserving old names for DLL ABI backward compatibility.

But they were removed for 64-bit versions of Windows in GTK 2.14:

Code: C  [Select][+][-]

1. /* Binary compatibility version. Not for newly compiled code. Also not needed for
2.  * 64-bit versions as there should be no old deployed binaries that would use
3.  * the old versions.
4.  */

Note that GTK 2.6 version is from the year 2005 and 2.14 version is from the year 2008.
Support for 64-bit Windows was not available from MinGW until 2011.

When GTK got support it even had a disclaimer:

Download for Windows (64-bit)

Note that these 64-bit packages are experimental. Binary compatibility between versions is not guaranteed.

[Arioch]

Great you found the specific point of time.

So, can we safely assume now that ALL of those funciton in GTK1/GTK2 LCL sources today should be moved to *_utf8 linknames and there would be no practically machines with GTK so old the *_utf8 functions are missed ?

Also i fail to grasp mere documentation about G Encoding". Can we safely assume GTK funcitons return UTF-8 encoded filenames? Or is it dependent upon some settings, like Current Thread Locale in windows, EXPORT LOCALE in Linux, etc? The rename suggests they decided to drop it and to make their API UTF8-only. But their docs still claim conversion of filenames to UTF when receiving from GTK and converting back from UTF8 when sending to GTK. It confuses me greately..

[marcov]

Is GTK2 (let alone GTK1) still supported as LCL backend for Windows  ?

[AmatCoder]

So, can we safely assume now that ALL of those funciton in GTK1/GTK2 LCL sources today should be moved to *_utf8 linknames and there would be no practically machines with GTK so old the *_utf8 functions are missed ?

Yes. All Linux distributions has 2.24 version since ten years ago at least. And version 2.6 was introduced eighteen years ago.
Nobody uses such old distributions.

Even more: The minimum Gtk 2 version supported for Lazarus is Gtk 2.8: https://wiki.freepascal.org/GTK2_Interface#Introduction

Can we safely assume GTK funcitons return UTF-8 encoded filenames?

On Windows, yes.
On Linux, no:

Historically, Linux has not had a defined encoding for file names: a file name is valid as long as it does not have path separators in it (“/”). However, displaying file names may require conversion: from the character set in which they were created, to the character set in which the application operates.

Example:
An application creates a file named "Tést". The application which created it uses ISO-8859-1 for its encoding.
But GTK uses UTF-8 for its strings. On Linux, if you get a file name from the file system - for example with readdir() - and you want to display the file name to the user with GTK, you will need to convert it into UTF-8.

[Arioch]

The application which created it uses ISO-8859-1 for its encoding.

what should it mean, specifically ?

in Delphi/Windows it would mean result of `GetThreadLocale` for the current thread, which by default is the same as all other threads and with Windows user interface default language setup.

in Linux there was a whole bunch of LOCALE_xxx and LANG_xx environment variables. I even used to know few of them :-)

On top of that Delphi and FPC have overriiding in their RTL, SetMultiByteConversionCodePage - but Dephi does not use it, while Lazarus does.

https://wiki.freepascal.org/FPC_Unicode_support#DefaultSystemCodePage

This has THREE different defaults even, System, FileSystem and RTLFileSystem   Ж8-[...]

Maybe i just won't need it. Hopefully.

Perhaps just DLL/SO function names can be safely patched in GTK2 sources, for all the platforms at once.
I eared that it can get to the situation, when for different platforms different names would be needed.

---------

An application creates a file named "Tést". The application which created it uses ISO-8859-1 for its encoding.

For what i remember fomr Linux 2.4/2.6 times, the filesystem would normally convert that name to it's internall format. And the charset used to communicate filenames to Linux kernel is normally specified in mount command options. Some filesystems would always use UTF-8 or UTF-16 on-disk, others would let mount charset be immediately used.

Then there is another seam, betwene Linux and application. Not sure which charset could be used there and how it was decided. Anyway, we do not control it.

Then we have a seam between GTK and application code. This is  where we get control and thus responsibility...

And i can not choose between two ideas. Frankly, maybe it is not relevant in practice.
I also was double ocnfused, because functions with and without _utf8 suffics could behave differently (then that suffix would have marked this difference in behavior, like windows API is having most functions as a pair of xxxxA and xxxxW functions.

I could imagine, that GTK functions would return/consume filenames in UTF-8 regardless of what locale/charset is set for the application code and UI (even if app's charset is not UTF8).

I could imagine that GTK functions would return/consume filenames in some vagule OS-selected charset regardless of app's own internal charset (even if it would be UTF-8 while OS'es one is pre-Unicode).

if you get a file name from the file system - for example with readdir() - and you want to display the file name to the user with GTK, you will need to convert it into UTF-8.

Frankly, i would have expecteed GTK functions to do it transparently, especially if they have *_utf8 suffix.
i GTK-providd functions can do proper transcoding - then GTK managd ot get all information required. Then it could do transcode on their own.

What i was fearing is that mere changing function name from old to *_utf8 would suddenly change behavior and break some apps. And i still do, regardless the "#define" in the Gtk docs. I don't feel the whole picture and this lefts me wary.

[Arioch]

Is GTK2 (let alone GTK1) still supported as LCL backend for Windows  ?

IDE seems to allow choosing GTK3 and GTK2

And also some GTK - which i  thought to be "GTK and auto-choose version" but maybe it meant GTK1

Also, what can GTK3 be safely used ? Google safe their API was so unstable as to unreliable.

But i wanted gtk2 for debug purposes, to be closer to behaviour reported from gtk2/linux

[marcov]

Is GTK2 (let alone GTK1) still supported as LCL backend for Windows  ?

IDE seems to allow choosing GTK3 and GTK2

And also some GTK - which i  thought to be "GTK and auto-choose version" but maybe it meant GTK1

But I wonder who used them after 2008.

Also, what can GTK3 be safely used ? Google safe their API was so unstable as to unreliable.

During all GTKs, they were pretty loose with regards to backwards compatibility, as you already have noticed.

However during GTK1 and first half of the GTK2 lifecycle, the GTK team generally fixes most submitted bugs.

Then they started to let bugs linger forever and only seemed to fix GNOME bugs, and  Gnome favours web-like GUIs with the GUI having a lot of distance between elements so that detail rendering doesn't matter.  This makes GTK less suitable as backend for a UI with precise rendering like LCL.

But i wanted gtk2 for debug purposes, to be closer to behaviour reported from gtk2/linux

You will have a choice of continuing this path, or porting to LCL/win32 for Windows sake. I don't envy that choice.

I long ago made my win32/64 GUI leading, with a portable mindset, and  then just let whatever worked on Linux with GTK<x> just happen.  That way I at least have one quality long term stable UI.

[Arioch]

Oh, no :-)

Luckily it is not about some big legacy apps, it is just about making changes to LCL itself :-)

This googling made me feel, that if i ever would need x-platform compatibiltiy beyond LCL itself, i'd perhaps indeed choose LCL/Qt.

Though i remember Linux has more lightweight toolkits, wxWidgets, FLtk and what not. But i guess LCL of Linux toolkits only had Qt and GTK really developed.

Then i heard Mint/XApps folk talked about forkng gtk3 and stabilizing it, but perhaps this did not take off.

[PascalDragon]

Though i remember Linux has more lightweight toolkits, wxWidgets, FLtk and what not. But i guess LCL of Linux toolkits only had Qt and GTK really developed.

It's always a question of manpower. GTK and Qt are the two largest toolkits, so supporting them is important. For anything more there isn't enough manpower.

[MarkMLl]

It's always a question of manpower. GTK and Qt are the two largest toolkits, so supporting them is important. For anything more there isn't enough manpower.

Also the more widget sets the LCL supports, the more apps will have to be aware of facilities that work in most widget sets but not all of them.

Historically, the GTK developers have justified casually changing their APIs by pointing to Linux being prepared to change internal APIs (applicable to driver modules etc.). Which leads me to wonder whether they really have any interest in providing an interface to anything other than Gnome, and to question the judgement of Linux distreaux which are oriented heavily towards chasing the "latest and greatest" GTK version.

If GTK, as a project, is not prepared to commit itself to the Windows platform, I suggest that for an individual or a small team to attempt to maintain that combination is futile: far better to throw ones weight behind Qt.

MarkMLl

[Arioch]

Which leads me to wonder whether [GTK team] really have any interest in providing an interface to anything other than Gnome, and

to question the judgement of Linux distreaux which are oriented heavily towards chasing the "latest and greatest" GTK version.

If GTK, as a project, is not prepared to commit itself to the Windows platform, I suggest that for an individual or a small team to attempt to maintain that combination is futile: far better to throw ones weight behind Qt.

1. My some hours of googling and blog-reading suggest that GTK 4 explicitly or almost explicitly claimed they only care about Gnome. The Gnumeric guy in particular felt thrown under the bus. This, paradoxically, makes me think that supporting GTK2 in LCL is practically better than supporting GTK3. The only possible other avenue would be someone (like Mint folk) initiating a GTK fork and then cherry-picking commits from mainline GTK so that it retains backward compatibility. However i did not find much of it, and here your are silent about it too, so i cinclude this idea did not live up.

2. It was said that GTK is structured in a way making co-existence of different libs in one system rather hard if possible. Maybe just because GTK is not approaching SemVer and do not separate their changes between breaking and incremening. Then, distros could hypothetically, settle on building GTK-using apps with static linking, but they do not. Because it would complicate their build pipelines and because it would be extra maintenance, both security and other bugs. RAM use on users machine too, but Android phonees hint that is nomore pressing factor. If Gnumeric author says so - then i have to trust him, he has 1st-hand experience.

Then there are docker/flatpack and other semi-VMs, which could pack GTK and others SOs - but normal distros would not go that way for all their apps too.

0install initiative did not make up, trying to marry CAS (content-addressible storage, like bittorrent and Git) to traditional package managers.

So, if GTK tiself does not provide for it - then either some app programmers would come up with multiversion-friendly gtk fork, or not. Distro-makers would not do it.

3. Well, as soon as GTK2 is supported by LCL, any change of LCL has to be changed on it, at least by someone.  I didn't found GTK2/Win32 binaries any more, but GTK2/Win64 still are compiled. And polished old project can live long despite bit rot. Especially that Windows used to be doing lots for backward compatibility. But this is saying it again, that LCL/GTK2 could be more practically mantainable target than LCL/GTK3

[MarkMLl]

1. My some hours of googling and blog-reading suggest that GTK 4 explicitly or almost explicitly claimed they only care about Gnome. The Gnumeric guy in particular felt thrown under the bus. This, paradoxically, makes me think that supporting GTK2 in LCL is practically better than supporting GTK3. The only possible other avenue would be someone (like Mint folk) initiating a GTK fork and then cherry-picking commits from mainline GTK so that it retains backward compatibility. However i did not find much of it, and here your are silent about it too, so i cinclude this idea did not live up.

I am agnostic. From the POV of Lazarus and the LCL GTK2 appears entirely adequate, but regrettably everything is driven by the extent to which distreaux are prepared to continue supplying it.

MarkMLl

[Arioch]

So, the last question remains for me, which kind of bug should be opened.

To officially discard GTK2 on Windows support, or to patch GTK sources - for all platforms at once - to move to newer *_utf8 names.

I wonder...

[PascalDragon]

1. My some hours of googling and blog-reading suggest that GTK 4 explicitly or almost explicitly claimed they only care about Gnome. The Gnumeric guy in particular felt thrown under the bus. This, paradoxically, makes me think that supporting GTK2 in LCL is practically better than supporting GTK3. The only possible other avenue would be someone (like Mint folk) initiating a GTK fork and then cherry-picking commits from mainline GTK so that it retains backward compatibility. However i did not find much of it, and here your are silent about it too, so i cinclude this idea did not live up.

GTK3 support is necessary, because distros start to drop GTK2 support.

3. Well, as soon as GTK2 is supported by LCL, any change of LCL has to be changed on it, at least by someone.  I didn't found GTK2/Win32 binaries any more, but GTK2/Win64 still are compiled. And polished old project can live long despite bit rot. Especially that Windows used to be doing lots for backward compatibility. But this is saying it again, that LCL/GTK2 could be more practically mantainable target than LCL/GTK3

GTK2 is supported by the LCL, it's the main widgetset beside Qt on *nix systems except macOS after all.

I personally wouldn't give any thought about GTK2 support on Windows however. If one needs an alternative to the native WinAPI widgetset one should go with Qt, cause they definitely and officially provide Windows support and care about it.