Refactoring, starting with folders and a way to create a release

[kanashius]

Description

Create a way to generate releases with the targets portable-x86, portable-x64 and src (the source code).
The result will be put into

• release\FilesAu3-0.4.1-src.zip
• release\FilesAu3-portable-0.4.1-x86.zip
• release\FilesAu3-portable-0.4.1-x64.zip
  Additionally, application resources now have their own folders, as assets contain documentation related things.

🚀 What is the new behavior?

Behaviour of the application is unchanged.
An additional script was added to generate releases.

Type of changes

• 🪲 Bugfix (change which fixes an issue)
• ⭐ New Feature (change which adds functionality)
• 🔒 Security fix (change which improves security)
• 🔮 Code style update (formatting, renaming)
• 🔨 Refactoring (code optimization without functional change)
• 📚 Documentation (updates to README or docs)
• ⚙️ Build or CI related changes
• 🧿 Other type

Breaking changes 🔥

• Yes
• No

How and where was this tested?

🖥️ Describe where you tested your changes

System:

• Windows 11 (x64)
• Windows 10 (x64)
• Windows 10 (x86)
• other Windows version
• other operating system

Context:

• in Browser <name and version>
• with Go <version>
• with Node.js <version>
• with AutoIt v3.3.18.1
• with .NET (C#) <version>
• with ...

🔬 Describe how you tested your changes

• Manually tested in system and context shown above
• Ran automatic tests (unit tests, integration tests, etc.)
• Other ways

Checklist

• I have read and understood the available contributing guidelines.
• I have ensured my code follows the available code conventions.
• I have reviewed my changes.
• I have made corresponding changes to the documentation (if applicable).
• I have added/updated necessary tests to cover the changes (if applicable).
• I have checked for potential security implications.

Additional context

Screenshots

Note to reviewers

[sven-seyfert]

Thank you @kanashius 👌 . I will have a deeper look later today.

Few things to consider:

• The build or release process can be managed by GitHub Actions (CI via yaml files), which is done before by @WildByDesign in others of his projects.
• Modularization ("starting with folders") is already discussed between Dave and me via Discord.
  So you cannot know this 😇 .
  • This will be applied, but maybe not yet fully.

Don't get me wrong, you do a great job and your thoughts are very valuable. I guess we should increase the communication via GitHub issues where we discuss next steps before we introduce a PR 🤔 .

Best regards
Sven

[WildByDesign]

I am not very good when it comes to organizing and refactoring. So I will leave that to you and Sven to figure out.

Most of my AutoIt projects in my repo have a workflow file to build and put releases together.
Example: https://github.com/WildByDesign/ImmersiveUX/blob/main/.github/workflows/main.yml

We can do something similar.

[sven-seyfert]

Hi @kanashius , 🛎️ "ping" .

[kanashius]

Using github to create the release files is a good way to handle public releases, I think.
But I also like the idea to have an additional and local way to generate the executable/release. That's why I added the compile script to the source-release. Nothing against a github flow, which is really nice to have and a good way to genereate the public releases, but in my opinion, everyone should be able to build locally without special github flows,...
A way to locally build also allows for testing things with the release before commiting as well.
(Or maybe there are ways to do that, which I do not know of, I did not really use github flows before)

I am also currently reworking the entire script, based on the original, when I started adding the processing in different processes. I tried to do that for the TreeListExplorer UDF, because that can also block the hole application and got into some issues. So some things have to switch to an event based system to trigger changes and react, when they are done and because I basically touch almost everything, I thought I could do a little restructuring/... as well.
We will see how it turns out, but it will take some time and I make no promises, I just started.
Just as a hint a few things I already added while doing that:

• dpi awarenes per monitor
• themes are supported with an easy way to switch
• a lot of restructuring, putting things in different source files, variable names,... to make it very easy to navigate the source code.
  Hopefully, this will give us a good expandable base to extend upon, where multi processing/themes/resizing/... is a part of the base design.

[WildByDesign]

But I also like the idea to have an additional and local way to generate the executable/release. That's why I added the compile script to the source-release. Nothing against a github flow, which is really nice to have and a good way to genereate the public releases, but in my opinion, everyone should be able to build locally without special github flows,... A way to locally build also allows for testing things with the release before commiting as well.

This is actually a really good idea that I had never really thought about before. Having a local build for testing purposes and a public release flow on Github would both be good options to have.

I tried to do that for the TreeListExplorer UDF, because that can also block the hole application and got into some issues. So some things have to switch to an event based system to trigger changes and react,

This is very intriguing and exciting. This whole multi-process with IPC seems to open up a lot of possibilities. I was wondering if you would attempt to extend that to your TreeListExplorer UDF. I can imagine that is difficult and would require changes. But if successful, in the long run, Files Au3 will have much better performance.

I noticed that loading of folders sometimes causing a flicker with the menubar as well. So I can see how it is sometimes blocking the overall script temporarily. If only AutoIt had multi-threading. But your multi-process can solve this.

Hopefully, this will give us a good expandable base to extend upon, where multi processing/themes/resizing/... is a part of the base design.

This all sounds wonderful. I know from experience with you that when you are quiet for many days, that usually means that you are working very hard on it and don't usually write much until complete. You like to go quiet and come back with surprises and that is all good.

Having a good base design will be important. It will especially help to attract more developers who want to help and make it easier for them to understand the code base. With all of the features that we have now and a restructured code base soon, that will put Files Au3 in good position for the future.

Thank you for all of this work that you are putting into this. It will absolutely be worth it.

[sven-seyfert]

Very nice Patrick 👌 . What do you think - should be keep this PR open or should we close it until you did your refactoring more complete? Both ways are fine in my opinions, but personally I suggest to push many small PRs instead of one big one, when you can do this.

@kanashius