Forum > GTK
GTK2 ABI seems broken, at least on Windows
Arioch:
--- Quote ---The application which created it uses ISO-8859-1 for its encoding.
--- End quote ---
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.
---------
--- Quote ---An application creates a file named "Tést". The application which created it uses ISO-8859-1 for its encoding.
--- End quote ---
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).
--- Quote ---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.
--- End quote ---
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:
--- Quote from: marcov on September 11, 2022, 03:37:13 pm ---Is GTK2 (let alone GTK1) still supported as LCL backend for Windows ?
--- End quote ---
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:
--- Quote from: Arioch on September 11, 2022, 08:32:51 pm ---
--- Quote from: marcov on September 11, 2022, 03:37:13 pm ---Is GTK2 (let alone GTK1) still supported as LCL backend for Windows ?
--- End quote ---
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
--- End quote ---
But I wonder who used them after 2008.
--- Quote ---Also, what can GTK3 be safely used ? Google safe their API was so unstable as to unreliable.
--- End quote ---
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.
--- Quote ---But i wanted gtk2 for debug purposes, to be closer to behaviour reported from gtk2/linux
--- End quote ---
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:
--- Quote from: Arioch on September 11, 2022, 10:33:57 pm ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page