Test the AAS Manager in various OS

[zrgt]

Currently we AAS Manager only in Windows. We need to test it in MacOS, Linux and other Windows Machines.

Please test the portable version of AAS Manager in the latest release for diff. OS:

• Linux
• MacOS
• Windows

[zrgt]

@monsieuremre please try it on available machines

[monsieuremre]

Does this only cover individual and manual testing of the binaries or also an automated workflow?

[zrgt]

Does this only cover individual and manual testing of the binaries or also an automated workflow?

It should cover only manual testing to identify current problems in the binaries. If you identify any bugs, please open an issue

[monsieuremre]

Primitive manual tests results:

Windows

• No noticeable difference between windows 10 and windows 11.
• Window 10 old versions with old system libraries can't run Qt6. So latest versions of AAS Manager won't work in such releases. This won't be the case for anyone at all almost, maybe some old corporate machines.
• It is evident that the development of this program was primarily on windows. So no problems are apparent.

Linux

• Differentiates from the windows build, but only visually, so no functional differences. The visual elements in the GUI have different defaults than on windows. Probably a Qt6 thing, so has nothing to do with us. It can still be changed manually in settings. But e.g. windows defaults to a vertical grid view, whilst on linux, it defaults to a horizontal one.
• Dialogue window position restoring won't work on Wayland sessions. When using Xorg, it works as expected for Qt5, and also as expected with Qt6, but a really recent version of everything needs to be running. We can't do anything to fix this. This will be fixed as Wayland matures and Qt6 libraries get better Wayland integration. Might add notes for Linux users, to make the situation a bit clearer.

MacOS

• Personally did not do testing, since I have no access to Mac hardware. But I assume on MacOS, the defaults will be the same of that in Linux, as they are both unix-like. This has no effect on usability.
• Binaries are not signed obviously. This will prompt an error for users. Mac users should be made aware of this fact, to avoid any confusions. We should also document how to circumvent this warning and start the application.
• Optionally, we can just sign the binaries. This requires being enrolled in the apple developer program, which is a yearly subscription. So I figured probably not. We better just add some notes for MacOS users.

[monsieuremre]

The issue can be closed as there are no more manual testing that I can do. I have done everything on Linux and Windows. Unfortunately, MacOS is out of my control. So there really is no need for this issue to stay open.

I have reported quite some stuff. I can incorporate this information into the readme file before closing the issue. Should I do that?

[zrgt]

@monsieuremre thank you. Yes, please add the most improtant findings in readme and close the issue after it.