I'm afraid I still get the following errors when trying to run the installed Geany (to be sure something isn't broken on my system I also tried to install Geany 2.0 release which worked alright):

GCC version mismatch? What is the GCC version of the MinGW-w64 cross compiler on Linux? MSYS2 UCRT64 GCC is 14.2.0

@eht16 @techee Look at the PKGBUILD of mingw-w64-libtiff:

https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-libtiff/PKGBUILD

You don't have to resolve the conflicts between the two libstdc++ libraries. You only have to build your own libtiff.

This is how I configure it:

./configure --prefix=$HOME/tiff --disable-static --enable-shared --disable-cxx --disable-jbig --disable-lerc --disable-libdeflate --disable-lzma --disable-zstd --disable-webp

The resulted $HOME/tiff/libtiff-6.dll is very small. The only dependency is libjpeg-8.dll.

Note: I'm using MSYS2 UCRT64.

After adding libjpeg-8.dll from MSYS2 UCRT64 and my own libtiff-6.dll, Geany runs just fine.

You don't have to go as minimal as me. You only need --disable-lerc, this will enough to get rid of the annoying libstdc++ issue.

BTW, the issue of SVG images still remains:

#4094 (comment)

You don't have to resolve the conflicts between the two libstdc++ libraries. You only have to build your own libtiff.

OK, that's one option too. Probably pretty much the same result as building liblerc against the libstdc++ that Geany uses as I suggested in #4094 (comment) and which works as well.

@chadchoi Anyway, since you got the latest version of Geany running, you should be able to test the LSP plugin by getting the artifact from

https://github.com/geany/geany-plugins/actions/runs/12283983695/

and installing geany-plugins from there (no need to install Geany itself, you'd have to fight with the libstdc++ problem again).

As far as I can tell, it works, but I didn't use it for real development so I'm interested in any feedback.

@chadchoi Anyway, since you got the latest version of Geany running, you should be able to test the LSP plugin by getting the artifact from

https://github.com/geany/geany-plugins/actions/runs/12283983695/

and installing geany-plugins from there (no need to install Geany itself, you'd have to fight with the libstdc++ problem again).

As far as I can tell, it works, but I didn't use it for real development so I'm interested in any feedback.

I have your version up and running. We should continue the discussion about it on #4082.

We use the debian cross-compiler

https://salsa.debian.org/mingw-w64-team/gcc-mingw-w64/-/tree/master/debian?ref_type=heads

for the nightly builds and CI and have to use whatever it ships. I'm actually not sure what variant it is.

@techee It turns out that I was right.

GCC version mismatch? What is the GCC version of the MinGW-w64 cross compiler on Linux? MSYS2 UCRT64 GCC is 14.2.0

MSYS2 UCRT64 GCC is 14.2.0, the latest version of MinGW-w64 cross compiler on Debian is 12.0, see:

https://packages.debian.org/search?keywords=mingw-w64

@techee It turns out that I was right.

But how does it matter to the actual problem? The discussion in msys2/MINGW-packages#22847 and your various comments are pretty off topic. Do you know how to fix the CI builders and fix the librsvg problem or do you have any insight into the problem? If so, I'm all ears. If not, please reduce the amount of noise around.

@techee It turns out that I was right.

But how does it matter to the actual problem? The discussion in msys2/MINGW-packages#22847 and your various comments are pretty off topic. Do you know how to fix the CI builders and fix the librsvg problem or do you have any insight into the problem? If so, I'm all ears. If not, please reduce the amount of noise around.

Which noise? This PR is about fixing the problems of missing dlls, isn't it? We are discussing the problem of the mismatch of two versions of libstdc++. It has nothing to do with the malfunctioning of librsvg!

This PR is about fixing the problems of missing dlls, isn't it?

I think you don't understand what's going on. There are 2 problems:

1. Red squares instead of icons - this is caused by the librsvg problem I reported in [librsvg] svg GDK pixbuf loader doesn't work since October 15 msys2/MINGW-packages#22847. It got introduced by the commit I reported there and I'd like to get a feedback from someone who made the commit or knows more about the build options used. It has nothing to do with "missing librsvg", using, ucrt variant of mingw or whether it works locally on my machine or not.
2. Two conflicting versions of libstdc++ - we need the "posix" variant of threads for Geany itself, but the libLerc library, which is now required as a dependency of Geany (which didn't use to be the case before so this problem didn't exist in the past), is built against the win32 thread variant. So we either rebuild libLerc against the "posix thread" variant or, as you suggested, rebuild libtiff without libLerc (or find some other solution). I find it safer to rebuild libLerc because it has no additional dependencies and it's mostly "dead" compared to libtiff which is actively developed and whose development might introduce more problems for us in the future. This is clearly our own problem and I didn't report it to mingw.

This PR is about fixing the problems of missing dlls, isn't it?

I think you don't understand what's going on. There are 2 problems:

I think it's you that mixing different problems. The problem with librsvg should have its own issue and its own PR. You are reusing this unrelated PR to discussion about it. The discussion about librsvg here is off-topic and you are wrong!

1. Red squares instead of icons - this is caused by the librsvg problem I reported in [librsvg] svg GDK pixbuf loader doesn't work since October 15 msys2/MINGW-packages#22847. It got introduced by the commit I reported there and I'd like to get a feedback from someone who made the commit or knows more about the build options used. It has nothing to do with "missing librsvg", using, ucrt variant of mingw or whether it works locally on my machine or not.

And it's completely unrelated. The issue I posted, #4084, is about missing of dlls caused Geany to fail to run. This PR is supposed to solve that. This means on this PR you only need to care about the missing dlls to have Geany running. The red squares caused by librsvg is completely unrelated and deserves its own issue and its own PR!

2. Two conflicting versions of libstdc++ - we need the "posix" variant of threads for Geany itself, but the libLerc library, which is now required as a dependency of Geany (which didn't use to be the case before so this problem didn't exist in the past), is built against the win32 thread variant. So we either rebuild libLerc against the "posix thread" variant or, as you suggested, rebuild libtiff without libLerc (or find some other solution). I find it safer to rebuild libLerc because it has no additional dependencies and it's mostly "dead" compared to libtiff which is actively developed and whose development might introduce more problems for us in the future. This is clearly our own problem and I didn't report it to mingw.

Nonsense. The MSYS2 MinGW-w64 are all using POSIX thread model. The mismatch is about different GCC versions, not different thread models!

Isn't it clear that if Geany uses libraries using msys/mingw then any problems in that are not part of Geany and should be raised at that project, not part of Geany?

And it's completely unrelated. The issue I posted, #4084, is about missing of dlls caused Geany to fail to run. This PR is supposed to solve that. This means on this PR you only need to care about the missing dlls to have Geany running. The red squares caused by librsvg is completely unrelated and deserves its own issue and its own PR!

Well, we don't have a separate issue for that so I discussed it here.

Nonsense. The MSYS2 MinGW-w64 are all using POSIX thread model. The mismatch is about different GCC versions, not different thread models!

You are simply wrong. By default, mingw libstdc++ uses the win32 thread model. @eht16 had to start using the "posix" variant of libstdc++ in 354c7ba because Scintilla started using some features that require it. However, now, Geany also has the libLerc dependency and that library was build against the standard win32 thread libstdc++ so there are mismatches between symbols. For more, see e.g.

https://stackoverflow.com/questions/17242516/mingw-w64-threads-posix-vs-win32

@chadchoi I'm ending all discussions with you by this - explaining things over and over to you is tedious and, more importantly, I don't like your behavior. You simply don't know much, based on your github profile you are very new to open source development but behave as if you knew everything best (typical sign of not knowing much). My advice to you is to change your behavior, otherwise you won't be taken seriously anywhere. Or instead of kicking around, start doing something useful and e.g. provide a patch fixing the problems.

@elextr Good to see you!

I have unsubscribed. Please don't tag me anymore. Thanks.

Nonsense. The MSYS2 MinGW-w64 are all using POSIX thread model. The mismatch is about different GCC versions, not different thread models!

You are simply wrong. By default, mingw libstdc++ uses the win32 thread model. @eht16 had to start using the "posix" variant of libstdc++ in 354c7ba because Scintilla started using some features that require it. However, now, Geany also has the libLerc dependency and that library was build against the standard win32 thread libstdc++ so there are mismatches between symbols. For more, see e.g.

https://stackoverflow.com/questions/17242516/mingw-w64-threads-posix-vs-win32

Debian offers the MinGW-w64 cross compiler in both POSIX and Win32 thread model variants, and you chose to use the Win32 variant? Well, this is simple. You simply need to switch to use the POSIX variant of the MinGW-w64 cross compiler, easy peasy.

Your wording is wrong. You said By default, mingw libstdc++ uses the win32 thread model.. This is simply wrong. The MinGW-w64 cross compiler you chose to use is targeting the Win32 thread model? Right. But MinGW-w64 in general? Nope.

I have no idea why you chose the Win32 thread model variant from the beginning. It's very unpopular. No one uses it. Popular MinGW-w64 distros like winlibs.com doesn't even provide Win32 thread model builds. People all use POSIX thread model for maximum compatibility.

BTW, Github Actions does provide MSYS2 in their CI. Why don't you simply use that for your Windows builds? Why cross compile from Linux but still need to grab MSYS2 packages to extract for libraries? If you managed to cross compile from Linux, why don't you cross compile everything you need instead of stealing prebuilt libraries from MSYS2 packages?

Why do you make everything that complicated? I can't get it.

BTW, MSYS2 in CI: https://www.msys2.org/docs/ci/

Note: The gdk-pixbuf-query-loaders.exe you cross compiled is a Windows binary, you can't run it on Linux so it seems Wine is used. But Wine has problems with bcryptPrimitives.dll. The result is it can't be used to regenerate the loaders cache. If you continue to cross compile from Linux, the only solution is the hack to manually append to loaders.cache you have described.

Debian offers the MinGW-w64 cross compiler in both POSIX and Win32 thread model variants, and you chose to use the Win32 variant? Well, this is simple. You simply need to switch to use the POSIX variant of the MinGW-w64 cross compiler, easy peasy.

You got it wrong - it's the other way round - we use the posix variant.

Your wording is wrong. You said By default, mingw libstdc++ uses the win32 thread model.. This is simply wrong. The MinGW-w64 cross compiler you chose to use is targeting the Win32 thread model? Right.

No, once again, we use the posix variant.

But MinGW-w64 in general? Nope.

If so, libLerc coming from mingw should work out of the box with Geany's posix libstd++, shouldn't it? Instead, I had to recompile it against the posix libstdc++ to make it work. So I assumed that mingw uses the win32 variant by default. Do you have any link to some official msys2 documentation stating that the "posix" variant is default?

I have no idea why you chose the Win32 thread model variant from the beginning. It's very unpopular. No one uses it. Popular MinGW-w64 distros like winlibs.com doesn't even provide Win32 thread model builds. People all use POSIX thread model for maximum compatibility.

Let's repeat the same sentence again: we don't use the win32 variant.

BTW, Github Actions does provide MSYS2 in their CI. Why don't you simply use that for your Windows builds?

Probably a question for @eht16 (I'm not a maintainer of the Windows build, I don't know much about it. I maintain the macOS port). I assume the build time is lower (see below). Also, we are not Windows developers but Linux developers. The Windows variant in Geany is just a "bonus" and I think anyone here tries to avoid Windows as much as possible.

If you managed to cross compile from Linux, why don't you cross compile everything you need instead of stealing prebuilt libraries from MSYS2 packages?

That's pretty simple - compilation time. We create the Windows installer as part of our CI so every pull request builds the Windows binaries. Imagine how long it would take to cross-compile all the dependencies and we'd probably have to start paying for the CPU time.

Note: The gdk-pixbuf-query-loaders.exe you cross compiled is a Windows binary, you can't run it on Linux so it seems Wine is used.

Yes.

But Wine has problems with bcryptPrimitives.dll. The result is it can't be used to regenerate the loaders cache. If you continue to cross compile from Linux, the only solution is the hack to manually append to loaders.cache you have described.

I don't think there's some general problem with the loaders - the cache-generating binary works all right for all other loaders and there was no problem before for SVG either. But after the October 16 commit I mentioned, this stopped working. What I suspect is going on is this:

msys2/MINGW-packages#22880 (comment)

i.e. that the actual librsvg library gets statically linked to the loader. That explains the huge binary size and also the sudden
bcryptPrimitives.dll dependency which wasn't present before (and was probably only present in the actual librsvg library but not present in the loader).

So I'd like to learn why such a change was made and whether it was intentional. On linux (and macOS too) loaders are small libraries that don't contain the actual library code so this is definitely not a standard way to create them.

Do you have any link to some official msys2 documentation stating that the "posix" variant is default?

It really seems to be the case:

https://github.com/msys2/MINGW-packages/blob/9f766f74cef87296b08c4508e12f600f19ef6a4c/mingw-w64-gcc/PKGBUILD#L20

But the libstdc++ coming from the debian cross compiler differs from the libstdc++ coming from mingw. Not really sure what's going on. In any case we will probably have to compile libLerc by ourselves unless someone has a better solution.

Do you have any link to some official msys2 documentation stating that the "posix" variant is default?

It really seems to be the case:

https://github.com/msys2/MINGW-packages/blob/9f766f74cef87296b08c4508e12f600f19ef6a4c/mingw-w64-gcc/PKGBUILD#L20

But the libstdc++ coming from the debian cross compiler differs from the libstdc++ coming from mingw. Not really sure what's going on. In any case we will probably have to compile libLerc by ourselves unless someone has a better solution.

So Github user @chadchoi was right. They said it's not thread models mismatch but libstdc++ versions mismatch. As I know, you can't upgrade your cross compiler because Debian is Debian, they never provide up-to-date packages. Building your own libLerc with your cross compiler is the only solution.

Please keep in mind that the pixbuf loader for SVG is developed by librsvg and not the gdk-pixbuf project. This is the reason why it looks odd compared to other pixbuf loaders.

librsvg is written in Rust. This is what happens when you introduce Rust into a C project. The binary generated by Rust tends to boom in size. This is normal. I don't think librsvg was linked statically into the loader as you have guessed.

So Github user @chadchoi was right. They said it's not thread models mismatch but libstdc++ versions mismatch.

I was apparently wrong in this case, sorry.

librsvg is written in Rust. This is what happens when you introduce Rust into a C project. The binary generated by Rust tends to boom in size. This is normal. I don't think librsvg was linked statically into the loader as you have guessed.

That's clear (I already had my share of issues with this particular library and the macOS port). But there are 2 libraries - the actual librsvg library and the loader which is just a very thin library. I haven't checked in what language the loader is written but on my Debian linux it looks this way - pretty much like all the rest:

-rw-r--r-- 1 root root 67640 Jun 13  2024 libpixbufloader-ani.so
-rw-r--r-- 1 root root 67656 Jun 13  2024 libpixbufloader-bmp.so
-rw-r--r-- 1 root root 67640 Jun 13  2024 libpixbufloader-gif.so
-rw-r--r-- 1 root root 67640 Jun 13  2024 libpixbufloader-icns.so
-rw-r--r-- 1 root root 67712 Jun 13  2024 libpixbufloader-ico.so
-rw-r--r-- 1 root root 67696 Jun 13  2024 libpixbufloader-pnm.so
-rw-r--r-- 1 root root 67664 Jun 13  2024 libpixbufloader-qtif.so
-rw-r--r-- 1 root root 67376 Jul 30  2023 libpixbufloader-svg.so
-rw-r--r-- 1 root root 67648 Jun 13  2024 libpixbufloader-tga.so
-rw-r--r-- 1 root root 67648 Jun 13  2024 libpixbufloader-tiff.so
-rw-r--r-- 1 root root 67536 Mar  4  2023 libpixbufloader-webp.so
-rw-r--r-- 1 root root 67640 Jun 13  2024 libpixbufloader-xbm.so
-rw-r--r-- 1 root root 67640 Jun 13  2024 libpixbufloader-xpm.so

But of course it's hard to compare, maybe on Windows there's some extra boilerplate code that has to be added.

After checking msys2/MINGW-packages@a2aaa55#diff-0db33fcf01a542992efe526a1612edefac816309632a06fc2b7348ce2ae5b66c and subsequent commits in more detail, they switch from autotools to meson and there may be so many things that meson does differently that there's probably no easy way to figure out, what it is.

So while hacky, updating the cache manually will probably be the only option for now.

Oh, what a fun.
@techee I'm sorry that you got so in deep into the Windows build "fun" :(.
And probably because of some of my past decisions on the build setup which might not be the best ones.
Thank you for debugging all these issues, talking to the MSYS2 guys and sorting everything out.

I'll try to answer the questions raised in the various issues:

Why not using the native MSYS2 Github actions?

At the time of creating the current setup, the MSYS2 Github action didn't exist yet or at least I wasn't aware of it.
I think it might be totally possible to port the current setup but it needs to be done and might cause some efforts.
I won't work on this.

Additionally, we would rely even more on the Github infrastructure.
The current setup is just a shell script which starts a Docker container which can be run basically everywhere. The MSYS2 Github action can only be used with Github Actions.

This might be ok but should be considered at least.

Why do you use "mingw64" and not "ucrt"?

Because we always built with mingw64, I think even before "ucrt" existed.
We could switch now but the current cross-compile setup based on the Debian mingw64 toolchain offers "ucrt" only in the "experimental" distribution and is probably not yet ready to use.
So we could keep this in mind for the future or switch away from cross-compilation (see above) and then use "ucrt".

Why do you use the "posix" variant of the toolchain and not "win32"?

See my (not so :D) famous change in 110c7b4 when we had trouble with newer C++ features used in Scintilla but not support by the "win32" variant.
This might have changed in the meantime by newer toolchain versions and so let's try it.

The SVG red squares issue

I updated the Docker base image used for the cross compilation to Debian Trixie (this is not yet officially released, it's the Debian Testing version) as it offers newer Wine and mingw64 toolchain versions.
With the included newer Wine version, it seems "gdk-pixbuf-query-loaders.exe" updates the cache properly and the "pixbufloader_svg.dll" is included.

If we want to go this way, this might be an alternative to manually updating the cache file.

To test this, I created (and merged to get a new Docker base image) geany/infrastructure#12 and updated this PR with the necessary changes (576540c).
I didn't update G-P yet which I would do if we want to use the newer base image version.

The Lerc and stdc++ incompatibility

As said above, it might be the necessity for the "posix" version of the stdc++ library is gone and we can use the default variant.
Let's test this with geany/infrastructure#13 and the corresponding changes in in this PR (7bc4838).

Unfortunately, I cannot test these changes on Windows. Even only the first change (update of the base image) crashes on startup with the following error:

I'm not sure if this happens because of the change or because of my old Windows 7 machine which might be finally too old for recent builds. This would be ok if it works on newer systems.
So, @techee could you maybe test the builds:

• https://github.com/geany/geany/actions/runs/12570600682 (base image update with newer Wine and toolchain, should contain a proper Pixbuf loader cache file)
• https://github.com/geany/geany/actions/runs/12570886835 (removal of explicitly using the "posix" stdc++ library)

I hope I didn't miss to address any important question. Otherwise, just ask.

@techee I'm sorry that you got so in deep into the Windows build "fun" :(.

Yeah, in the future I'm leaving this to our official Windows expert - you :-)

I updated the Docker base image used for the cross compilation to Debian Trixie (this is not yet officially released, it's the Debian Testing version) as it offers newer Wine and mingw64 toolchain versions.
With the included newer Wine version, it seems "gdk-pixbuf-query-loaders.exe" updates the cache properly and the "pixbufloader_svg.dll" is included.

If we want to go this way, this might be an alternative to manually updating the cache file.

I'd say we want to go this way because this really fixes all of our issues - not only SVG (which works now), but the libstdc++ problem as well, see below.

I didn't update G-P yet which I would do if we want to use the newer base image version.

Would probably be good.

So, @techee could you maybe test the builds:

Victory! Both of the builds work on my machine!

So yeah, the libLerc (and previous "win32 vs posix" Geany issue) were probably just caused by old libstdc++ libraries used by the cross compiler. Since both of the versions work, I think it would be better to use the second version (i.e. without the copy of the posix libstdc++ from the cross-compiler).

I'm not sure if this happens because of the change or because of my old Windows 7 machine which might be finally too old for recent builds.

Just wondering, have you tried https://reactos.org ? I haven't but if you manage to get it running, it might offer a more usable environment than the old Windows 7.

I updated the Docker base image used for the cross compilation to Debian Trixie (this is not yet officially released, it's the Debian Testing version) as it offers newer Wine and mingw64 toolchain versions.
With the included newer Wine version, it seems "gdk-pixbuf-query-loaders.exe" updates the cache properly and the "pixbufloader_svg.dll" is included.

If we want to go this way, this might be an alternative to manually updating the cache file.

I'd say we want to go this way because this really fixes all of our issues - not only SVG (which works now), but the libstdc++ problem as well, see below.

Fine, still a little hacky as Debian Trixie is not yet released but better than our existing and maybe coming workarounds :).
I saw the first alpha installer for Trixie these days, so it might be released within the next months anyway.

I didn't update G-P yet which I would do if we want to use the newer base image version.

Would probably be good.

Will do tomorrow.

So, @techee could you maybe test the builds:

Victory! Both of the builds work on my machine!

Yeah, finally :).

So yeah, the libLerc (and previous "win32 vs posix" Geany issue) were probably just caused by old libstdc++ libraries used by the cross compiler. Since both of the versions work, I think it would be better to use the second version (i.e. without the copy of the posix libstdc++ from the cross-compiler).

In #4094, you added even more dependencies. Those are not necessary now?

I'm not sure if this happens because of the change or because of my old Windows 7 machine which might be finally too old for recent builds.

Just wondering, have you tried https://reactos.org ? I haven't but if you manage to get it running, it might offer a more usable environment than the old Windows 7.

I did, maybe two years ago. At that time, the installer didn't start or something like that. But I'll give it another chance, good idea.

The good thing is, I can finally burn down that Windows 7 VM. The only reason for its existance is gone :).

In #4094, you added even more dependencies. Those are not necessary now?

I don't remember what I was doing or trying to do :-). These

techee@7d7ec4a

should be enough.

Maybe one dependency you might consider is shared-mime-info - I use it for the macOS build too. It allows to determine the right icon for a file type based on its mime type. This then works e.g. with the file browser plugin (but the result also depends on the used icon theme if it provides corresponding filetype icons).

The good thing is, I can finally burn down that Windows 7 VM. The only reason for its existance is gone :).

The bad thing is that I would become the only guy around with working Windows, making me "the official Windows tester" ;-)

Just wondering, have you tried https://reactos.org/ ? I haven't but if you manage to get it running, it might offer a more usable environment than the old Windows 7.

To save you some time, I just tried it but the default build is 32bit only and doesn't even allow starting the msys2 installer. There seems to be a 64bit nightly version at

https://iso.reactos.org/livecd/

which I haven't tried but I think 64bit is still experimental and possibly not stable.

I didn't update G-P yet which I would do if we want to use the newer base image version.

Would probably be good.

Will do tomorrow.

Done in geany/geany-plugins#1399.
In case you are going to test it, until this PR is merged, you need the Geany build from this PR and the G-P build from the above mentioned PR (and ignore the Geany build included in the G-P build).

Maybe one dependency you might consider is shared-mime-info - I use it for the macOS build too. It allows to determine the right icon for a file type based on its mime type. This then works e.g. with the file browser plugin (but the result also depends on the used icon theme if it provides corresponding filetype icons).

Alright, I just added it. But as you know, I can't test it :).

The good thing is, I can finally burn down that Windows 7 VM. The only reason for its existance is gone :).

The bad thing is that I would become the only guy around with working Windows, making me "the official Windows tester" ;-)

I don't think so.
Your workload is already big enough I guess.

I think I will finally look for a new Windows maintainer. And until one is found or even if not, the quality of the Windows releases might decrease. IMO this is OK as there are probably more users on the other platforms and maintaining the Windows build isn't that easy due to the nature of this system.

Just wondering, have you tried https://reactos.org/ ? I haven't but if you manage to get it running, it might offer a more usable environment than the old Windows 7.

To save you some time, I just tried it but the default build is 32bit only and doesn't even allow starting the msys2 installer. There seems to be a 64bit nightly version at

https://iso.reactos.org/livecd/

which I haven't tried but I think 64bit is still experimental and possibly not stable.

Ha, noticed the same two hours ago :).
The 64bit variant should not yet be used and even if, it doesn't provide the 32bit compatibility layer and so our 32bit installer can't be used.
At least, the installer works fine on the 32bit variant of ReactOS.

On a side note, in theory we could generate the installer as a 64bit exectuable. Though I didn't find yet a way to also make the included uninstaller 64bit.

Maybe one dependency you might consider is shared-mime-info - I use it for the macOS build too. It allows to determine the right icon for a file type based on its mime type. This then works e.g. with the file browser plugin (but the result also depends on the used icon theme if it provides corresponding filetype icons).

Alright, I just added it. But as you know, I can't test it :).

Hmm, I don't see any difference so it can probably be dropped. I think it's because of the Adwaita icon theme which doesn't provide many mime type icons (the theme I use on macOS has many more mime type icons https://github.com/geany/geany-osx/tree/master/Papirus/16x16/mimetypes)

I think I will finally look for a new Windows maintainer.

I don't think there will be crowds of people wanting to do that ;-)

And until one is found or even if not, the quality of the Windows releases might decrease.

I believe there aren't any major problems though - or any new problems at least. Those various things like problems with file encodings have probably always been there and some things are probably GTK related and nothing we can fix in Geany.

So I think the main issue is to have CI running and being able to make releases (which you could also do using CI or a local docker image if you don't have access to a real Windows machine - I can survive testing the result from time to time ;-)

Maybe one dependency you might consider is shared-mime-info - I use it for the macOS build too. It allows to determine the right icon for a file type based on its mime type. This then works e.g. with the file browser plugin (but the result also depends on the used icon theme if it provides corresponding filetype icons).

Alright, I just added it. But as you know, I can't test it :).

Hmm, I don't see any difference so it can probably be dropped. I think it's because of the Adwaita icon theme which doesn't provide many mime type icons (the theme I use on macOS has many more mime type icons https://github.com/geany/geany-osx/tree/master/Papirus/16x16/mimetypes)

Ok. I think we could still keep it in, maybe it gives other advantages as well.

I think I will finally look for a new Windows maintainer.

I don't think there will be crowds of people wanting to do that ;-)

Don't destroy all my hopes to get out of the Windows hell :)

And until one is found or even if not, the quality of the Windows releases might decrease.

I believe there aren't any major problems though - or any new problems at least. Those various things like problems with file encodings have probably always been there and some things are probably GTK related and nothing we can fix in Geany.

So I think the main issue is to have CI running and being able to make releases (which you could also do using CI or a local docker image if you don't have access to a real Windows machine - I can survive testing the result from time to time ;-)

Actually, right now we have to make releases from the CI as I cannot build natively on Windows anymore. And I got it almost running already, will PR it soonish.

ReactOS is a toy. Please don't consider it as something serious.