-
Hi,
I need to make a very simple app that needs to run on PC and mobile (mostly Android but possibly also iOS) and it needs display a couple of simple 2D and 3D graphs.
Also it needs to interface via USB, Bluetooth and WiFi to some PCBs I designed.
I am looking for some C++ IDE/framework that:
- can deploy onto multiple platforms (Windows and Android at least)
- relatively quick and simple to learn
- preferably free
Few questions:
1) I came across Embarcadero C++ builder. Is that a good solution?
2) How does that compare to Visual Studio (I used that years ago)
3) Are there other/better ones perhaps more focused to interfacing with IoT and Embedded systems?
4) is there any way or system/solution that allow you to upload the code directly to an Android device without going through the Google store or opening any Google accounts? i.e. downloading the app directly onto the Andoid device via USB?
Thank you
-
C++Builder was pretty good back in the day (and the only way to do VB-style drag'n'drop UI programming on win32 for C++). However, it's now vastly overpriced and a dying market - Embarcadero basically bought it off Borland because they use it extensively, and they sell it to recoup some costs. Support is thus dropping as the userbase dies out, so it's a dead end.
Someone else will no doubt pop up re VS and the like
-
1) I came across Embarcadero C++ builder. Is that a good solution?
i've been looking for VB5 like easy RAD programming, ie we design a button, double click it and the IDE bring us to the code. Embarcadero C++ builder seems to do that which made me excited, but then when i tried to download or buy, its $1K+ tag cheapest, and then it doesnt show it can support Linux, so... how about Qt4,5? now 6. it has GUI designer but it doesnt link the GUI elements to the code as good as i mentioned, we need to do it manually (can be a good thing? esp on bigger projects with many sub modules). it also supports Linux development beside what you mentioned, and totally free and open source. -
Embarcadero stuff is definitely good.
Now if you're using it for its cross-platform features, keep in mind you're going to get "locked in". Not necessarily a problem - it's up to you.
With that said, a "small" detail: from what I've seen (so at least please check), Embarcadero C++Builder only targets Windows and iOS. You'd need their RAD Studio product to get Android as a target. Or, use Delphi.
I thought it was worth mentioning, because the license for RAD Studio is much more expensive than for C++ Builder. Delphi is cheaper than RAD Studio but still more expensive than C++ Builder.
-
Thank you all
I just had a look at Qt and seems a widely used and nice platform. But came across some comments that its debugger is not at all user friendly nor does it have all the functionality you would expect or which Visual Studio does provide (although apparently it uses some version of VS Debugger).
What about Visual Studio? I see it supports iOS and Android, why not many people use that? Does it have some issues or does it make things more complicated when developing for multiple platforms?
Thank you -
Qt supports all those platforms including iOS, but building for all targets maybe prove a bit cumbersome.
For instance, the supported build environment for iOS is XCode: https://doc.qt.io/qt-5/ios.html
I'm pretty sure you can do all of that on the command line with GCC or Clang, but then don't expect a click-and-point experience. You can probably set up VS as well to trigger the build for all targets including Android and iOS, but it's probably going to take you a while to figure out how to do it.
-
Quote
What about Visual Studio? I see it supports iOS and Android, why not many people use that?
Apparently a lot of people use it. Personally, I hate it - it is Microsoft and thus will gain or lose features depending one what they want you to do. I am reasonably certain that if they thought they could get away with it you'd only be able to run on W11 right now. Note that I did point out that for a long time the cool UI designer couldn't be used for win32 because they wanted developers to move to C#.
And... installation sucks. Ask it to install on, say, drive D: and it will put maybe 400MB of a a 5GB install there, and the rest goes on your C: drive without so much as a 'by your leave'.
I'd rather use Eclipse than VS, but that's just me
-
I just had a look at Qt and seems a widely used and nice platform. But came across some comments that its debugger is not at all user friendly nor does it have all the functionality you would expect or which Visual Studio does provide (although apparently it uses some version of VS Debugger).
What is supposed to be lacking in Qt Creator that VS has? You can us VS compiler and debugger, or GCC. Clang is in there also. Qt has some of the best documentation you will find if you are not sure how something works. And a helpful forum for asking questions.
If you are targeting mobile, you will want to use QtQuick/QML instead of widgets. Widgets do not play well with mobile devices.
This is a good intro, but it only covers widgets so far.
This covers QML pretty thoroughly.
Between the two you can get a good start and be able to ask the right questions when you get stuck on something. -
Thank you all
Mechatrommer mentioned that Qt is free and open source but as I was looking at Qt's website I saw they at least some parts are not free: https://www.qt.io/pricing
I am not sure which parts I would need and don't want to risk spending time learning it and developing my app only to find out that later on I need some parts of Qt that need purchasing.
Could someone give a brief guidance of what is free and what is not which I might need to develop a simple app as mentioned in the O.P.?
Many thanks
-
Mechatrommer mentioned that Qt is free and open source but as I was looking at Qt's website I saw they at least some parts are not free: https://www.qt.io/pricing
Not this again...
Qt has some additional modules that are proprietary, but you're not going to need or use them in application development.
Please read this: the second-to-last paragraph contains the list of LGPL'd Qt modules, and a link to where you can check.
I have done both open source and proprietary software development. (Tux, the Linux penguin, is my mascot and not my idol.)
If you have specific questions about licensing, and how to safely, robustly, most of all legally, and in a way that keeps you in good standing with the upstream developers, to develop/implement your own applications, I can help. It isn't difficult at all; the only hard part is getting ones mind see from a different viewpoint.
Many I've helped initially really dislike my suggestions and my demands of how they need to see things from a certain perspective (commonly with a complaint that "there should be a much easier way, something that is much easier for me to accept"), but in the end, it works, and you get pretty comfortable with the approach.
Those with lots of Windows development experience seem to have the hardest time to switch to cross-platform development.
That said, I haven't written any software for windows in a decade and a half, so I'm most comfortable in POSIX-like systems (Linux, BSDs, Mac OS) myself. Hey, we all have our limitations.
Qt is also nice in that it isn't an exclusive framework. You can implement what you need yourself. There is even QtUsb (LPGL) for cross-platform USB HID and bulk transfers; the built-in QtSerialPort can be used for both serial port and USB serial. (When using USB Serial, on Windows the device you're using must have serial drivers installed; on other systems, no special drivers are needed since USB Serial is a standard interface supported by generic drivers.)Could someone give a brief guidance of what is free and what is not which I might need to develop a simple app as mentioned in the O.P.?
You asked about IDE (which means integrated development editor), and Qt is a framework.
You can use Qt with any IDE you wish: Visual Code, Qt Creator, et cetera. Different ones have different level of support. As Qt is really just a library, you can use whatever debugging methods you like. (If you want to debug Qt internals, you will need to get or compile versions of the Qt library that contain debugging symbols.)
Even if you use the GUI designer part of Qt Creator, you don't need to use Qt Creator as your IDE. It's pretty modular stuff. It's also one of the libraries that are commonly cross-compiled, so as long as you get a suitably new toolchain, you shouldn't have much trouble.
I personally do prefer to write the actual UI part in Python 3 (Python 3 and Qt 5, to be specific), keeping the UI license permissive, and only the (proprietary) innards in C. That way the UI can be developed separately, and even end users can make small changes and play with it, without having any kind of development environment at all.
It is quite easy to interface to C/C++ code from Python, using just Python code. (Besides, if you do any kind of heavy computation, you'll want to do it in native code anyway, for performance reasons.) -
I have used Qt for cross-platform development for the last 20 years for a large-ish application (20 modules and several hundred thousand lines of code). I only target Windows, Linux and Mac so can't comment on Android. Some reasons why Qt is good for me are:
- You can use if for free for opensource projects, or you can also get a small business license for $500/yr if not, and you meet the requirements (less than a certain turnover which I believe is $250k/yr but note you can't start on the free version if you plan to go commercial later).
- Has its own IDE (Qt Creator) but you can use other IDEs if you want. I use VS on Windows and Qt Creator on Linux/Mac.
- Has excellent documentation and examples
- supports up to date C++ language features
- drag and drop tool for ui development (Qt Designer) although you can hand code dialogs if you want to do something more advanced.
-
Mechatrommer mentioned that Qt is free and open source but as I was looking at Qt's website I saw they at least some parts are not free: https://www.qt.io/pricing
for developing your own "free OSS" software, thats a clear cut its free (with some rules obligation)... but if its for your butter and bread, you need to pay, and yearly or monthly basis payment is suck. whats not really clear is if we want to develop paid softwares and projected profit is only like $100/year. paying for qt monthly fee will be a total loss, i've sent them a PM to clear this up again. no reply so far... btw, if VS has GUI Designer like Qt has, i'm willing to switch to VS again and abandon my dream about developing SW capable in Linux... -
No.Mechatrommer mentioned that Qt is free and open source but as I was looking at Qt's website I saw they at least some parts are not free: https://www.qt.io/pricing
for developing your own "free OSS" software, thats a clear cut its free (with some rules obligation)... but if its for your butter and bread, you need to pay
If you limit to the LGPL-licensed modules, even if you made millions each month, you wouldn't need to pay anyone a single cent.
God damned I hate these misguided advice about licensing. Just because the Qt Company wants you to pay, does not make it a legal obligation. -
God damned I hate these misguided advice about licensing.
https://www.qt.io/download-open-source?hsCtaTracking=9f6a2170-a938-42df-a8e2-a9f0b1d6cdce%7C6cb0de4f-9bb5-4778-ab02-bfb62735f3e5#obligations
maybe i misunderstood this clause?
"GPL – All users have the rights to obtain, modify and redistribute the full source code of your application..."
how can i make a few cents out of my SW if someone can get its source code and compile them themselves?
-
GPL is not LGPL.God damned I hate these misguided advice about licensing.
https://www.qt.io/download-open-source?hsCtaTracking=9f6a2170-a938-42df-a8e2-a9f0b1d6cdce%7C6cb0de4f-9bb5-4778-ab02-bfb62735f3e5#obligations
maybe i misunderstood this clause?
"GPL – All users have the rights to obtain, modify and redistribute the full source code of your application..." -
Mechatrommer, I may have been a bit too harsh; I've been in a bad mood. Apologies.
GPL (3 and 2) are different licenses to LGPL (3 and 2.1).
The main difference is that LGPL – which originally signified "Library General Public License" (and is listed as such in e.g. Qt sources), but nowadays the name "Lesser General Public License" is used; all these variants share the same difference to GPL – is that dynamically linking to an LGPL-licensed library does not make the combined application a derivative of said library. This is intrinsic to the LGPL, and is the main difference to GPL. The Wikipedia LGPL article describes the differences quite succinctly, with proper references.
In explicit terms, a proprietary application is allowed to dynamically link to an LGPL-licensed library, without having to be LGPL-licensed itself.
In other words, I'm describing a way here that does not require you to divulge any of your own proprietary source code at all.
This does mean that when shipping a proprietary application that uses Qt licensed under LGPL, the LGPL license does apply to Qt (but only to Qt!)f. You do need to provide the sources for Qt, although if you use pure/unmodified upstream sources (at qt.io), a link to them should suffice. (To keep developers happy, you should also provide the full compilation information of the toolchain used to compile the sources, if you compile them yourself: compilers and versions used, configuration (./configure parameters used), and so on. This has zero cost to you, but may help end users and Qt developers debug issues that happen across a set of Qt-using software, but not in all Qt-using software. Things like high-DPI display bugs and such. It also makes it trivial for anyone to check that you are complying with LGPL, and have not made any custom changes to the Qt libraries without providing the corresponding sources.)
Do not hide the Qt use, be proud of it, and whenever you mention Qt, explicitly list the Qt modules and the fact that they're used under the LGPL license, and that "Qt is a registered trademark of the Qt Company Ltd in Finland and/or other countries worldwide". This keeps everyone happy.
As long as the proprietary application only contains code you either own the copyrights to or have a suitable license to, you can choose whatever license you wish for the application part.
If you find you need to extend Qt itself, make it a Qt module, and contribute it back upstream (under the various Qt licenses, preferably). Such a module could be seen as a Qt derivative, so making it too LGPL-licensed, and providing the sources for the new Qt module, would be the most sensible option.
(This is extremely rare, however. The current Qt 5 modules contain a full gamut of functionality. In the module list, you do need to click each one separately, to see the licenses the module is available under. For Qt 5.12 and 5.15 (Qt 5.4 and later), look for LGPL 3, "GNU Lesser General Public License, version 3".)
It may feel funky to have to consider developing free/open source software to support your own proprietary commercial application, but that seems to be the way these things work best. Best of the both worlds, if you will, in a sense. The biggest hurdle in this is always getting over human preconceptions and misunderstandings, and to see why and how the Free/Libre Open Source licensing works in practice. Technically, it really is very simple. It isn't even hard to keep Qt developers happy, even though you're not paying for a commercial license.
(As I've already mentioned, I do prefer to implement the pure UI part in Python3. It is a clear extension of the above idea: I do want to provide an user interface, but if the end users want to change the UI somehow, without getting/needing access to the business logic (or Sekrit Sauce, like I tend to call it), why not give it to them? Heck, encourage it, and ask them to report any useful customizations, so they can be shared to other customers too. If you are uncomfortable with this idea, you need to examine why you feel that way. You see, it is exactly such human feelings that are the biggest hurdle in realizing how LGPL libraries and proprietary applications can interface in a mutually beneficial manner. Exploitation is not sustainable.)
I do recommend reading my earlier post in another thread about how to use Qt under LGPL with ones own proprietary application; I might have missed something in this post. -
even people with a good mood can get into bad mood if they have to redo all the long typing to explain things over and over again, i know that, been there. so i thank you for your long explanation clearing things up, and a link to older threads can be much usefull. i've read about this sometime ago, about the distinction between Qt module/library that we are basing our SW on, and our own SW itself. our SWs can be proprietary while keeping the Qt part (that came from the factory) open under LGPL or what, correct? but this kind of thing and mechanism can be strange to individual hobbiest like me. maybe now i can be more confidence on Qt to develop my own SWs (small small tools at cheap) in the future (currently no urgency to do so), just think LGPL... not GPL aye? legal terms are my strongest weakness.. i only know making SWs
-
Just adding a small thing to complete Nominal Animal's (clear and precise - but that's a given) explanations:
It is possible to statically link an application towards LGPL code and keep it proprietary.
This is something that's more useful to know for embedded (as in MCU, not embedded Linux or Windows) applications, and it's very seldom used (at least IME).
From LGPLv3, Clause 4, but there's equivalent language in LGPLv2.1, Clause 6,a:Quoted) Do one of the following:
0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
1) [...the usual dynamic linking...]
What this means is that one must provide the object files (not compulsorily the source) and e.g. linker scripts and instructions to relink one's proprietary code with another version of the LGPL code. See also the relevant FAQ
IANAL, TINLA, ça va sans dire. -
Quote
provide the object files (not compulsorily the source)
The object files would contain enough metadata to make reverse engineering pretty simple, so a good way towards the source code, wouldn't they? Without that data, linking would be rather tricky.
-
i've read about this sometime ago, about the distinction between Qt module/library that we are basing our SW on, and our own SW itself. our SWs can be proprietary while keeping the Qt part (that came from the factory) open under LGPL or what, correct?
Yes, exactly.
It is important to note that this is a feature of the LGPL license. There are other licenses that have similar features – MIT, BSD, Apache, etc. – , but is not true in general. The Wikipedia Comparison of free and open source software licenses article contains a table of licenses, with the Linking column containing the stance of the license in this regard.
Also note that different licenses have different requirements. For example, to comply with the MIT and most variants of the BSD license, you need to include the licenses in the source and documentation. You could say qualitatively that these licenses are more about attribution than "rights".
Some people also have quite emotional relationship to particular licenses. I do not: they're just a tool to achieve specific results. Reading a bit of history (behind projects that use the license and the history of the licenses themselves), can help that make clearer, if it does not open to you from the license text itself.
Comparing different licenses is also useful, because then you see how they focus on completely different things.
It certainly makes life easier when you not only follow the "letter" of the license, but its "spirit" as well. Then, if a silly person attacks you about license compliance, you can contact e.g. FSF (or whoever is considered the authority on the license) for help.legal terms are my strongest weakness..
I really don't like "legalese" myself. It's just that when I ran a small IT company producing custom solutions to all sorts of customers (from companies to artists to government organization), I had to learn this stuff. I had a lawyer help me do that; he also taught this stuff to other lawyers.It is possible to statically link an application towards LGPL code and keep it proprietary.
Very true.
I think it may be useful here to show the entire section 4. Combined Works for LGPL-3.0 here:
4. Combined works
You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:- a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License.
- b) Accompany the Combined Work with a copy of the GNU GPL and this license document.
- c) For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document.
- d) Do one of the following:
- 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
- 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.
- 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
- e) Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version.
(If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.)
What it means is that you need to be open (in the product documentation and description) that your application uses the LGPL'd library, and provide web links to GPL and LGPL. You can either use dynamic linking, or provide the proprietary part of the application as an object file. You must not restrict users to use only an unmodified version of the LGPL'd libraries via e.g. checksumming; you must tell the end users how they can use a different version of the LGPL-licensed library with your application. You can either use the LGPL'd libraries installed on the system, or you can provide them yourself if you provide both their sources and detailed information on how they were configured and compiled (detailed enough to make rebuilding them easy).
Providing the exact information on how the LGPL'd libraries were configured and compiled, is not only about fulfilling the LGPL-3.0 requirements, but also about respecting the community and upstream developers. With that information, is a critical bug is discovered in the LGPL'd libraries, anyone can rebuild fixed versions of the LGPL'd libraries and use them with your proprietary application. This is utterly important part of the Free/Open Source community, and if you help make that easier, you garner goodwill; if you make that complicated, you only gain enemies who see you as respecting the letter but not the intent of the license.
Done this way, there should be zero pressure for you to open or relicense your proprietary part.
Sure, there are ideologues who believe everything should be open, and there are silly people who don't understand the license, but they both are trivially handled by sending them a form letter describing how you're following both the letter and the intent of the licenses, as described by FSF and others, so there is no obligation to open-source the proprietary part; and that for business reasons, open-sourcing it at this time is just not possible due to commitments to existing customers.
You may even be contacted by Qt Company salesdroids, but describing the contents of the aforementioned form letter will silence them too; I'd say the danger of a lawsuit is zero. They may offer better terms on a commercial license, and there are non-LGPL'd Qt modules you might wish to use – Qt Quick 3D for example (non-3D Qt Quick is LGPL'd) – so there are cases where getting a commercial license makes a lot of sense.The object files would contain enough metadata to make reverse engineering pretty simple, so a good way towards the source code, wouldn't they? Without that data, linking would be rather tricky.
On Linux, Android, and Mac OS/iOS, no. Also no on GNU- and LLVM/Clang-based toolchains. These all use ELF executables and object files, so technically the object file does not need to expose any more information than the binary would: you can strip off any metadata that would not be also present in a final executable/firmware image, except for the symbol names of the LGPL library.
If your sources comprise of multiple object files linked together, rather than multiple source files compiled and linked to a single object file, it becomes somewhat more work: you need to first compile them into a single object file, and then remove all symbols not needed externally. (Otherwise, the object files would need to expose symbols used across the object files.)
In the case of microcontrollers, the linker script file (specifying the memory ranges etc. on the target MCU) would probably reveal much more than the object files, to be honest. It's not like decompiling executables/firmware files is that difficult, once you get your hands on (unencrypted) binaries.
The major downside in this option, in my opinion, is that it does require at least the linker to be available; on the aforementioned systems and toolchains, that basically means a full (basic) toolchain installed. - a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License.
-
i just know there is free community version of embarcadero
https://www.embarcadero.com/products/cbuilder/starter/free-download
gave me lots of errors while installing, maybe due to Win7 incompatibility...
-
At first glance that looks interesting, but the $5000 cap on entire earnings (even those not involving C++B or even programming at all) pretty much rules out anyone but a hobbyist, and even they can fall foul if they sideline for pin money going.
-
Thank you all as always for all additional infos!
-
Keep in mind, again, that Embarcadero C++ Builder only targets Windows and iOS: https://www.embarcadero.com/fr/products/cbuilder
That's probably not what many people in here are looking for.