[Interest] Guide me through the Qt offerings for GUIs

[Rui Oliveira]

To make a webserver as a backend, one might as well use React.js or 
something for the frontend hehe.

I'm sorry to insist but again, an architecture like that doesn't allow 
for a very dynamic system, where you don't want to know all possible 
controls beforehand.

Audio applications, like DAWs solve this by just allowing VST developers 
to bring their own UI at their will, on a separate window. But I have an 
app I want to create a space for the plugin/module to display it's 
controller for it's own hardware... How?

Rui

Em 23/04/2021 14:28, Jason H escreveu:
> I highly recommend using QHttpServer or QWebSocketServer to create a 
> backend for your application. You can then have web clients target 
> your logic, swap your server for some other tech Node.JS, etc) or 
> serve local and Qt/WebGL UIs. It forces you into that paradigm. The 
> Websocket version plays a bit better with async. updates though.
> *Sent:* Thursday, April 22, 2021 at 11:25 AM
> *From:* "Konstantin Shegunov" <kshegunov at gmail.com>
> *To:* "Rui Oliveira" <ruilvo at hotmail.com>
> *Cc:* "Interests Qt" <interest at qt-project.org>
> *Subject:* Re: [Interest] Guide me through the Qt offerings for GUIs
> On Thu, Apr 22, 2021 at 6:10 PM Rui Oliveira <ruilvo at hotmail.com 
> <mailto:ruilvo at hotmail.com>> wrote:
>
>     Basically we're coupling the whole backend to the GUI framework.
>
> You always have some coupling between the logic and the GUI, no matter 
> what you use, but I do get the gist.
>
>     I'd prefer to write C++ than to learn Loaders and whatever else
>     there is... But seems that people do love QML a lot (again, shouts
>     out to KDE).
>
> Funny that you mentione the `Loader`, which is sort of no-op item from 
> the C++/desktop dev perspective. What I mean by that is that the 
> `Loader` is the archetype of the 'QML engine is really a glorified 
> object factory', which I mentioned. The only reason it is there is to 
> delay the creation of a QtQuick item. This would've been rather 
> trivial to do in a C++ environment, you just create and add the object 
> to the scene whenever it's needed, no need to wrap this in a 
> `QObject`, but not so trivial to do if you want to leverage it in a 
> 'declarative' (or rather JS) context. Note that the component doesn't 
> go away too, because at some point you may want to unload said scene 
> item, which instead of just deleting, being the obvious choice, you 
> set the relevant property to the loader, which detaches it from the scene.
>
>     Opinions, I guess.
>
> I don't see anything wrong with that, as long as we have a civil 
> discussion (not a troll fest) about it.
> _______________________________________________ Interest mailing list 
> Interest at qt-project.org https://lists.qt-project.org/listinfo/interest 
> <https://lists.qt-project.org/listinfo/interest>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210424/d65cba2c/attachment.html>