Thread: QT5 for GUI programming or?

I currently use Qt (which is very poor in my opinion) because I don't know of any better frameworks at the moment.

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.

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.

Originally Posted by Dave11

well, JUCE is A platform , not only GUI platform like QT.

Qt is not just a GUI platform. It's a jack-of-all-trades too.

EDIT: As far as JUCE goes, it's licensed under GPL or AGPL which makes it useless IMO.

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.

Originally Posted by Elysia

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.

now = not.
LPGL = LGPL.

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.

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:

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.

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.

Originally Posted by Elysia

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

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

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.

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.