I'm tasked with developing a commercial closed-source application for desktop with GUI. I'm looking for a framework I could use.
Must have:
- Free or very cheap to use (Qt is not an option)
- Fast to execute, one execution of some external tools that need to be monitored may take days, hence fast execution is invaluable.
- Allow Protecting source code: I'll be importing proprietary third party software (even if possibly refactored to a different language) that can only be distributed in protected format. I also don't want customers to see implementation details.
- Allow creating GUIs
- Allow creating and updating scientific graphs.
- Allows developing for Linux
Nice to have:
- C++ as language
- Good documentation
- Widely used on GitHub/StackExchange
- Allow displaying and updating simple 3D graphics.
- Allowing to develop for multiple platforms.
- Statically linked libraries preferred, so I can have a single executable for the whole app.
Context: I've been working with wxWidgets, but I don't seem to find many questions on SO, nor plenty of code on GitHub, plus the documentation is confusion for me, and everything seems to have been made more than 5 years ago. I've considered using Qt, but my company does not qualify for their small-business plan, so it would end up being too expensive for starters.
The app I'm developing will interact with a lot of C code, and should run "fast" (which makes python a little undesirable), have a GUI and be preferably complied in a stand-alone executable. I cannot create a server-based application to run as a service, I need to deliver to the customer's PC, which will be used in locations where internet access may be limited or non-existent.
.a
) and provide a minimal script which links it with a static Qt. If you want to provide a 100% proof, you can distribute a Docker image which recompiles an official Qt and links it to your app (distributed as a.a
). If you want for sure protect your app details, you can also link your app into a single object (.o
) with some ld commands. This.o
is nearly so un-decompilable as your final binary. – peterh - Reinstate Monica Jul 24 '20 at 15:32