Add a note about JUCE and Qt to the documentation

[jarkkojs]

Summarizes the discussion in #486.

Closes: #486

[jarkkojs]

Seems that Github recognizes that Closes tag, which I did not know before (shows a tooltip).

[baconpaul]

Yeah looks good.

Redoing zoom without cocoa in AU will be a pain. But otherwise it looks like a fine summary of our discussions.

Wonder if dpf may also be an option?

But I'm happy with your doc!

[jarkkojs]

@baconpaul, maybe so but we still would reduce the amount of specialized code. I don't know what dpf is but I know that Qt is the best application framework available for C++. And the subsection does not dictate to use Qt. It is just the current analysis of it. It is mentioned as a viable option.

[jarkkojs]

@baconpaul, good to here. Lets not create an architecture specification. Lets instead evolve one over time. Otherwise we end up with a document that is both useless and unreadable.

[jarkkojs]

Can we close this now?

[baconpaul]

Yeah sure! Fine with me.

[falkTX]

Huh, Qt for GUIs is a really terrible idea.
It is a huge codebase which we would have to build statically for the plugin, just for a few OS independent things...

[jarkkojs]

@falkTX, there is no roadmap ATM to use Qt. And there is no requirement to link Qt statically even if we end up using it.

[jarkkojs]

Actually Windows would be a problem without static linkage. However, static linking is not by itself is not any kind of problem.

• It does not really matter how fat the resulting binary is. Kernel mm will fault only the pages that it actually uses in Windows, macOS and Linux.
• Huge codebase is not a problem as it is a mature toolkit. We don't care all that much about Qt's source code.
• We are compatible in terms of licensing for static linkage. Qt is licensed with LGPL3 (among some other licensing options).

Only thing that it would affect is that the Qt SDK (which is free) would be required to compile Surge. Not a big deal.