4 ms·
HTML painter? you mean how QLabel supports rich text via. HTML tags? Not sure what you are getting at with the "ideas are obfuscated to call it something else"
by saidinesh5 3y ago
HTML painter? you mean how QLabel supports rich text via. HTML tags?
Not sure what you are getting at with the "ideas are obfuscated to call it something else". You'd have a widget tree/graph even with QWidgets/QObjects. Would you call any QWidget program that uses QJsEngine "a browser stack"?. QML is just a declarative programming language, that lets you script QObject properties/react to signals/property changes.
NumberInput { id: width }
NumberInput { id: height }
Label {
text: "Area value is: " + width.value * height.value // automatically gets updated
}
All expressions in the above snippet of code are basically Javascript expressions. To accomplish the same in pure C++, you'd need to implement some kind of observer pattern/manually connect signals and slots across objects to allow for updates of dependent values (Label's text).
QtQuick is a scenegraph that uses QML to render a GPU accelerated UI. Which is what is needed on embedded/mobile UIs to get smooth high performant animated GUIs. That'd be too ineffecient and cumbersome to accomplish with QWidget/C++.
- righthand 3y agoIn QWidget if you use it then it’s compiled into the application. If you use QML it’s always there as far as I understand. Please review this post which seems to indicate that JS and HTML components are added to a project when QML is used.[0] It may not be a full engine but as I’ve previously stated I’m not interested in writing things in multiple languages. I want as few extra languages as possible. To tell me it’s not a browser stack then go on about how to use QML you can declare pages in HTML and JS that are then compiled into the binary that passes data between C++ and JS is entirely ignorant of my initial goals. If I wanted to use browser technology and JS I would build my app for a browser. > To accomplish the same in pure C++, you'd need to implement some kind of observer pattern/manually connect signals and slots across objects to allow for updates of dependent values (Label's text). I do not find that extra work because it’s represented in the class itself and the observer pattern maintains my preferences. Perhaps these technologies are useful for those who want to quickly write a mobile app with slick animations. Indeed it is a easy way for Qt to gain audience for those types of apps especially for people who aren’t able to learn C++. For my intentions I am looking for less overhead overall to keep files as pure C++ as possible to ensure that a class I’m writing represents the full scope of it’s functionality and domain. [0] https://news.ycombinator.com/item?id=38395603 https://news.ycombinator.com/item?id=38395603
- j1elo 3y ago> [0] https://news.ycombinator.com/item?id=38395603 https://news.ycombinator.com/item?id=38395603 In that post, I was just drawing a parallel to try and compare QML with some other better known technology. My point was not to say that it is actually HTML that goes into the program. I'm sorry if it caused confusion. My message was meant as a bird's eye technology comparison, ignoring the fine details. A different, more to the point take is: just like a web browser reads HTML and ends up interpreting a visual representation of a page, the QML engine will read a QML file and end up with a hardware-accelerated visualization of it. Qt just gives you the tools for that. If you don't need a hardware-accelerated rendering of a UI, working smoothly at 60fps in consumer devices, then probably QML wouldn't bring much to the table anyway.
- saidinesh5 3y ago> In QWidget if you use it then it’s compiled into the application. Same thing with QML. QML files get compiled into the application. The QQmlEngine then interprets various expressions/actions at runtime. Just like scripting a QWidget/QDeclarativeView based application with QtScript. I think the post you have linked to was simply comparing QML as a language to a HTML and how Javascript can be used as glue code to script various actions, and how you can expose business logic to javascript via. FFI. <button onClick="console.log('hello')" /> vs. Button { onClick: console.log('hello') } vs. Button *button = new Button(parent); connect(button, &Button::clicked, [](){ qDebug() << "hello" }); > I want as few extra languages as possible. I do not find that extra work because it’s represented in the class itself and the observer pattern maintains my preferences... For my intentions I am looking for less overhead overall to keep files as pure C++ as possible to ensure that a class I’m writing represents the full scope of it’s functionality and domain. I know where you're coming from. What I am saying was it is less about preferences and more about separation of concerns. "What the UI should look like" vs. "What the UI should do". The latter usually needs to happen in C++ anyways. But the former - there are better tools/ways to describe that. Most of the time "What the UI should look like" probably gets described in your constructors. It probably takes a few write/compile/test iterations to get what you want. That works well enough for simpler uis. When things get more complex... that's when other tools can simplify your work. With UIC, you (or an actual designer) can visually edit the ui in QtDesigner and give you the ui files. All the UI description gets compiled to it's own class. Your business logic code wouldn't have to worry about details of layouts, positions, colors etc... It wouldn't have to be modified whenever you want to change the position of a button. fwiw I started appreciating the designer only after going back to writing QWidgets code after a few years of break