For flatpak, it's done : GitHub - flathub/com.mikrotik.WinBox
Iād say winget is equal priority on Windows.
Read the code and follow the description link in this repo.
I hope when the time comes, there will be DEB and RPM. Other nonsense (AppImage, Flatpak, Snap, Docker, Whatever) - I donāt care as long as those are available.
DEB and RPM are only useful when the provide the proper dependencies for libraries that are assumed to be installed.
But that will make them more fragile as well, there may be subtle changes in the naming.
WinBox currently statically linked to most libraries. So dependency management is simpleā”.
It is the rules to be listed in repos that's are might harder, since WinBox is closed-source. So you'd likely still have to add a MikroTik repo to get a DEB or RPM. Snap and Flatpak aren't as committed to the OSS cause, so those are easier on the "paperwork" and requirements.
And there are third-party packages for many of the systems. For example, I publish a simple .deb package to get icon/.desktop on Ubuntu (and they let WinBox update itself from there). And just used third-party Flatpak, so that seems to work. So there is so charted path for MikroTik to take in most packaging cases, which be better long term to avoid supply chain attacks.
ā” To @pe1chl's point... typically apps when packaged, the final binary is dynamically linked to system libraries. This has pluses and minuses. It's smaller and allows security fixes in used libraries (like Qt) to be independent of WinBox release cycle. But also does contribute to "fragility" since even API compatible changes can still break things if libraries change under an app. Now, MikroTik has been in static binary camp for a long time (which I agree with), so don't see them deciding to dynamically link to random system libraries even if that's the "normal" for a distro.
Maybe you have a different version, my WinBox requires 39 dynamic libraries.
I thought, distribution ways are discussed, when the product is finished, doesn't have any issues and stable...
WinBox 4 is far from this point.
But people want convenient way to use/test beta as well. 
On Mac, with latest beta, I still get the default path in the Mac File dialogs being the root "Macintosh HD", not the User home or Documents or even some sandbox location in ~/Library/.../WinBox.
But I think I know why this happens to me more than others... I use workspace <none> as default. So the default must be saved in a "Workspace", and since I have "none", WinBox never remembers.
Even still, the default logic (when new workspace is initialized) should never choose the top-level root "Macintosh HD", since it's not writable, nor expected. Some sane choice like ~ or ~/Documents should be default location for Files dialogs.
I think the default is, at least under Linux it is, the working directory of the application.
That can usually be set in the shortcut you use to start it (I am not familiar with Mac but this is how it is in Windows and in Linux)
I use āownā as default and this default path issue on Mac is still the sameā¦
You mean an alias? That does nothing different that I know from starting the application, whether MacOS or Linux, GUI or command line. It depends on the applicationās behaviour. Are you setting an environment variable or passing a parameter to Winbox in a script?
The behaviour itself has not bothered me. A single click in the sidebar in the save dialog sets the directory I use universally for new downloads, moving the final version to the correct place later.
I donāt know how that works in MacOS but in Windows and Linux you can make a shortcut, and put it in a menu, the taskbar or the desktop, and configure things like the icon it will show, the program it will start, and also the working directory it will use.
From the above I assumed that he had made a shortcut and not specified the working directory, and it would default to the root directory. I know that WinBox defaults the file selector boxes to the working directory, so I tried to help him with that.
Maybe MacOS does not work at all like that, I donāt know.
MacOS being Unix dressed by Valentino, an alias (ln) is that and nothing more, a separate directory entry to the same file, without additional properties. It is possible to use Shortcuts.app to set a location but the very task of creating is more work than the single click I described above. It is also possible to write an Automator script to automatically move expected file types from a common area to other locations. Again, for my usual workflows that is not worth even minimal work.
Please do something about these warnings being shown on stdout:
Warning: qrc:/qt/qml/WinBoxQml/qml/WTable.qml:1770:25: Unable to assign [undefined] to QString (qrc:/qt/qml/WinBoxQml/qml/WTable.qml:1770, )
Warning: qrc:/qt/qml/WinBoxQml/qml/WTable.qml:1769:25: Unable to assign [undefined] to QString (qrc:/qt/qml/WinBoxQml/qml/WTable.qml:1769, )
Warning: qrc:/qt/qml/WinBoxQml/qml/WTable.qml:1770:25: Unable to assign [undefined] to QString (qrc:/qt/qml/WinBoxQml/qml/WTable.qml:1770, )
Warning: qrc:/qt/qml/WinBoxQml/qml/WTable.qml:1769:25: Unable to assign [undefined] to QString (qrc:/qt/qml/WinBoxQml/qml/WTable.qml:1769, )
Warning: qrc:/qt/qml/WinBoxQml/qml/WTable.qml:1770:25: Unable to assign [undefined] to QString (qrc:/qt/qml/WinBoxQml/qml/WTable.qml:1770, )
In my case on Mac (Intel, Sequoia 15.7.3) and Winbox (4.0beta47) using <own> workspace (not sure if I ever created this workspace), in Files section files dialog always opens OS root dir (Macintosh HD) for Download while for Upload last used dir if Download not opened meanwhile which resets it to root dir.
Thanks! I've never found out why it goes back to top-level "Macintosh HD"... it seemed "random" when it would "save" the last one used.
Nope. It works more like the discussed AppImage. Apps are "bundles" in Apple-terms, or a ZIP file more exactly ending in .app. Mac OS uses the .app to know it's an application, reads a XML file (Info.plist) inside bundle/ZIP to find the executable also inside same bundle/ZIP to start. And the WinBox.dmg (also a ZIP) offered for download contains the WinBox.app bundle/ZIP. When .dmg is opened, an .app in .dmg will trigger Mac OS to prompt to "install", which just a copies the WinBox.app inside the .dmg to /Applications.
I think the issue is more something like WinBox4 uses some Qt class/method to bring up the OS's File Dialog, and provide a null to starting path... and on Windows/Linux it does something reasonable, but on Mac it uses /. I'm thinking they need some #ifdef to set the starting path to, well, ~/Downloads if using File > Download in WinBox.
Not a huge bother either, more "odd"...glad @optio narrowed it down. And, I reserved my "bothered" for the dumb "3 column submenus".
+1000
Well, in Linux there is the problem that the OS itself does not provide a standard file selector dialog, so every application gets a different one, either by copying someone elseās work or by using something from the UI library that is being used (of which there are many). Terrible user experience, of course, but this is called āfreedomā.
Apparently WinBox uses the dialog from QT. It is TERRIBLE. Unusable on my system where e.g. in my home directory there are 140 subdirectories. When opening a file selector starting in my home directory, navigating to a suitable directory is almost impossible. Reasonable file selectors provide a āsort by modification time reversedā option so what you likely want to use is near the top, but this one doesnāt. It also has no option to show more items at a time (e.g. āsmall icons in multiple columnsā.
I cannot understand how someone can release such a thing. But it likely isnāt MikroTikās fault, or is it?