Open kapitainsky opened 1 year ago
Don't forget that NPBackup is a GUI ... and CLI application. If you remove the console, you won't get parameters to work anymore. On Windows, I minimize the console. What will be the effect of creating an application bundle ? Will console arguments still work ?
hmmm... good point. I have to think about it and do some experiments.
OK I think we can forget about it for now.
However I think it would be better to have npbackup-cli and npbackup-gui as separate binaries.
GUI based app should be just GUI based app IMHO with all configuration and options done in UI. Most people expect to click at icon and start app.
I already have a "in program" separation of cli and gui somehow, but here's the problem:
On Windows, I use the GUI to create scheduled tasks, which obviously work as CLI. Having two different executables will double the size of the distribution and duplicate code.
I'll think about it, maybe have the GUI program just call the CLI to do the actual work.
Until now, I've asked @kayhayen at Nuitka compiler if it would be possible to hide/lower the console window, but it's not as easy AFAIK. I've managed this for Windows, but not macOS.
Mac developer here.
If you're going to bring this to the Mac, I would suggest doing it as a GUI app (the word "program" isn't used on the Mac - we use the term "app" for GUI programs and "tool" for CLI programs). Users need to know it's running - and they should be able to either click the icon in the dock or an icon in the top right menu bar to check the status of the latest backup (the icons should also change if backups failed, or just haven't run for a long time).
Most "background" GUI apps have a setting to enable/disable both the dock icon and the menu bar icon (you wouldn't be able to disable both, but they might both be enabled by default). Disabling the dock icon will also remove your app from the Command Tab app switcher. Most power users probably won't want visible there.
The CLI tool should be entirely separate - either a separate download or inside the bundle for the GUI app. It's pretty common these days for it to be a separate download.
You normally wouldn't compile much logic in the CLI. It should use XPC (or alternatively you could simply use HTTP) to talk to the GUI app. If the GUI isn't running, it should be launched when the CLI tool is run.
The CLI tool shouldn't be large - the one for Visual Studio Code is only a thousand bytes for example - and it's probably more complex than yours would need to be. You could probably just make it a 50 line shell script or something.
@deajan with an application bundle, you can choose console or not on macOS these days
@abhibeckert
Thanks for your Mac OS insight. But I'm not planning on full macos support since I don't own any mac.
You could probably just make it a 50 line shell script or something. Not really portable. The goal is to run on most platforms.
I've implemented separate GUI, CLI and viewer apps. I'd love someone to guide me how to create MacOS application bundles.
@kapitainsky I've re-read of previous exchanges were you said you could create an icns file from a bitmap. Is that still a going thing ? Since my project now has fully separate CLI and GUI (which can also act as CLI), that would be great. Thanks.
@kapitainsky I've re-read of previous exchanges were you said you could create an icns file from a bitmap.
Sure. But for the best results I suggest svg file as the source. icns
contains multiple image sizes (512 256 128 64 32 16) and it is much better to create them from vector format - quality will be better. If not available we can work with bitmap too.
I will also send you procedure for generating icns files using open source programs- when back at the computer. Might be tomorrow.
Sure. But for the best results I suggest svg file as the source.
Thank you ;)
I have tried but results were not good... Your svg file is very imperfect and few methods I know result always with very ugly png files full of artifacts...
See below some of your svg issues - they make visibly awful artifacts in created bitmaps:
But let's forget about it for a moment - I am sure you can produce better png files. Maybe you actually have perfect png? and only created svg using some bitmap to vector program? I like to use svg as a source as it scales very nicely to whatever resolution I want - it is not as nice when scaling bitmaps.
Back to icns file. What you need is:
Then it is simple one command to produce icns
file:
makeicns -out ../icon.icns -512 image-512x512.png -256 rimage-256x256.png -128 image-128x128.png -64 imager-64x64.png -32 image-32x32.png -16 image-16x16.png
and voila icon.icns
is ready. I used this method for multiple macOS programs with always good looking and working icons.
If you do not have macOS to run makeicns
just send me either good svg or 6 png files in mentioned resolutions and I will bake it for you:)
Hmm... Quite strange, since my SVG has been produced by Adobe Illustrator. Let me check what kind of SVG I could produce and come back to you. I definitly don't own a mac. Thanks for your time.
Now when I think that macOS compiled application works it is time to make it proper macOS native application bundle.
At the moment binary is generated but when running with GUI it results with opening console (terminal) window - it is ok for debugging but not for normal use.
I have found the way to produce proper macOS style application bundle but in order to make it work I need macOS compatible icon file.
Could you please provide npbackup_icon.ico as ideally svg image format or at least 512x512 bitmap? This is what is required to create icns file. When I have svg or 512x512 bitmap I will create icns and finalize apple app build.