Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

• linux: https://make.mudlet.org/snapshots/8f04f1/Mudlet-4.1.2-testing-PR3208-f30c365-linux-x64.AppImage.tar
• osx: https://make.mudlet.org/snapshots/4747c5/Mudlet-4.1.2-testing-PR3208-f30c365.dmg
• windows: not available from normal location, instead download the archive direct from Appyveyor CI (for next 6 months)
  • windows 32 Bits: https://ci.appveyor.com/api/buildjobs/g4adxynl56ihnyfy/artifacts/package%2FMudlet--testing-1dbf977d-win32.zip
  • windows 64 Bits: https://ci.appveyor.com/api/buildjobs/cpgpm63up7f934cc/artifacts/package%2FMudlet--testing-1dbf977d-win64.zip

No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

I don't think any of the changes in TLuaI terpreter are relevant to the PR's scope. It should be able to load Mudlet libs as-is!

(Messing around with strings like that just makes work for translators, remember!)

I don't think any of the changes in TLuaI terpreter are relevant to the PR's scope. It should be able to load Mudlet libs as-is!

I was getting errors in that area and the messages were coming out a bit mangled, one of them was consistently moaning about Lua error:%1 is not a valid Win32 program. - notice the missing space and the unreplaced parameter. I fixed the space but eventually found out that the %1 was coming from an internal error in zip.dll because of a missing libzzip-0-13.dll and not because of a mistake I had found in our processing of the text.

For the record those libs are no longer ones we download from source and compile ourselves but instead copied from the MSYS2 (32 or 64 bit as appropriate) system ones.

I did have to merge in #3200 because I needed the 64Bit Discord library - and in doing so found out that I hadn't uploaded the correct one but a copy of the 32Bit one.

Damn, all the CMake builds are failing on Travis...

This is why:

CMake Error at src/CMakeLists.txt:255 (add_executable):
  Cannot find source file:
    mudlet_fonts.qrc
  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx

🤦‍♂ Oh, of course, as it proved not possible to compile the mudlet_fonts.qrc file for 32-Bit Windows as the amount of memory needed exceeded 4GB {and mingw32-make would consistently crash out} and I am not sure that amount is available within a MINGW32 environment. Given that we have done 32-Bit build using a different compiler it is not entire sure whether there might be just a bug in the one being used in this new arrangement.

As I had already pointed out to @vadi2 Windows cannot use the Noto Color Emoji fonts in even the latest Windows 10 version (except within the Edge and Chrome web-browsers) so it is pointless bundling it with that OSes packages. I took the step of making two resource files ./src/mudlet_fonts_linux.qrc - which is a rename of the existing one and ./src/mudlet_fonts_windows.qrc and I fixed the qmake project file to include the latter on Windows and the former everywhere else.

However, I forgot the CMake project files...!

Given that Color emojis are handled differently on the different OSes does our current forcing of the Noto Color Emoji font actually work on MacOs? I have some prototype code that instead of uniformly trying to force that font to be used as a substitute on all OS of all VERSIONS it tries to make a more nuanced selection and allow some flexibility for those users stuck in corner cases, however it is not clear what the Apple OS option should be...

It's definitely not something that this PR should worry about, lets talk in #mudlet-development?

Given the size of this PR I will not attempt to convert it from the Draft that it is currently. Instead, once the kinks have been ironed out I will try and squash all the experimental stuff down locally and then try and implement pieces in the smaller chunks that I know Vadim would prefer.

I suspect that, as we are including various libraries in the Windows package, either ones we compile ourselves (as at present) or provided by MSYS2 (as in this PR) we need to include all the licence documentation for the NON-GPLed free code that demands that they are mentioned as part of their terms of use, i.e. with MIT or BSD x clause or other licences!

Squashed down and rebased off a later start point in the development branch as #3255 - closing this draft...