Out of curiosity, for GUI programming what would be more favorable for the more experienced desktop developers on the forum, and if QT5 is not your prefered choice, would it be ok to give me a quick explanation as to why?
Many thanks in advance.
Out of curiosity, for GUI programming what would be more favorable for the more experienced desktop developers on the forum, and if QT5 is not your prefered choice, would it be ok to give me a quick explanation as to why?
Many thanks in advance.
I recently got to know JUCE C++ platform.
it's modern , intuitive and crossed-platform , meaning you can compile you program to windows, linux , os-X and even android and iOS.
I'd go with that.
well, JUCE is A platform , not only GUI platform like QT.
it definitely has extra stuff related to audio , but it has everything you need for GUI program : windows, button , listboxes etc.
you also have nice api for 2D rendering . take a look at their examples.
Last edited by Dave11; 01-11-2015 at 05:51 AM.
In my opinion Qt is very good, provided you aren't afraid to switch to the Qt framework completly (ie using QString instead of std::string, QFile instead of std::fstream etc.). I haven't dabbled much with QML the but the classical widget style of doing things is very good if you ask me.
STL Util a small headers-only library with various utility functions. Mainly for fun but feedback is welcome.
Shakti, it looks like I will be using QT5.
JUCE really is geard towards VST and I really do like the SIGNAL/SLOT feature of QT including we can use blocks inside the SLOT!
Yes, I'm going for QT5.
There is a difference between being able to use a software freely and having to distribute the source of your own programs that use said software. I'm fine with contributing back any changes to free software I've made, but now distributing the source of my own programs that uses said software. That's why I say GPL and AGPL is useless.
On a side note, LPGL works, but it's annoying as heck since it usually means you have to dynamically link against said software unless you want to distribute your source. That means if you just add the source to your project or statically link against it you have to distribute your source.
I'm no expert in these licenses (who the heck has the desire and time to read through all that legalese!?!), but that's what I've gathered from reading on the web.
Regarding static linking I think (insert normal "not a laywer clause" here, but from what i read on the web) it is enough for you to allow users to relink against another library. So if I have understood everything right you only need to provide compiled (but not linked) code.
STL Util a small headers-only library with various utility functions. Mainly for fun but feedback is welcome.
As far as I know:
- If you use dynamic linking, then you are required to allow people to use your application with another version of the LGPL'd library. At least wikipedia says so, but since I haven't read the license fully, I can't confirm this. Regardless, this poses mostly no problem. Users can simply recompile the library and swap out the .dll or .so file.
- If you use static linking, you must again allow for people to relink against against other versions of the library. This typically means you have to release the source or some compiled versions which users can re-link. This is a fuzzy argument, though, since derivative works fall under the license under section 6. Some say it's allowed; others say it isn't (source).
Quote from source:
So yeah, I'd rather not do that if it's this fuzzy. I guess simply trying to figure out the terms in the license under section 6 might work though.Some people will argue that it is possible to do static linking of LGPL’d code and still be able to abide by the legal terms by providing the necessary binaries to be re-linked. This has no legal precedent and is still a very fuzzy argument. I would rather not bet my company on something so shaky as this.
I find it amazing that so many people, when wondering how to comply with the LGPL for their combined work, seem to rely on word of mouth rather on the license text itself. This is from 4.d. of the version 3 text on https://www.gnu.org/licenses/lgpl-3.0.txt
Obviously not all systems have a suitable shared library mechanism, so systems like iOS/Apple app store may need to find another way to comply. In any case if you are staking your business on such software you should probably have a lawyer on your payroll to minimize risk of liability. But this is true no matter what license the software is under.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.