Widgets vs. QML: Choose A Side — and Prepare to Lose Friends
-
I am QML side, I do not remember the last time I used QWidgets.
I would say I can do whatever I want/think with QML.
It is a shame people still do not understand how one can produce cross-platform reusable GUI components with the mix of CMake, C++, and QML. The latter components can be plug and play in your application.
Also, QML is a declarative language that makes it cleaner than C++ for UI interfaces.
Now with tools like qmllint, it is quite easy to find errors before they happen at runtime.
QWidgets is C, and QML is C++ in the sense that if you want a fast thing done, you use QWidgets; if you want to design a reusable, nice-to-use interface, you use QML. -
There used to be a case for consistency between applications. Did you know that IBM held a patent for the progress bar? Luckily for us they never enforced it. It would have been really bad for them because if just their apps had used progress bars they would have been the non-conforming ones. (At least, progress bars are easily understandable so that they would not have startled users.)
QWidgets provide a constistent interface for each (desktop) platform. It also provide only widgets that everybody knows. QML on the other hand is more like an interface to go crazy with design. Every app looks different (if you don't just use the basic design elements) and works slightly differently. It is easy for designers to make something beautiful that has terrible UX. I do understand the practicability of QML for large project teams that have dedicated designers. For a designer QML is the better choice because they don't have to learn C++. However, I mostly work on small projects with two or three C++ programmers. Non of these projects use QML because we don't have a designer at hand.
I do understand that QtC wants to make money and the money seems to be in automotive using QML. But, for hobby projects C++ programmers just need an easy interface. And honestly, QWidgets is the easier alternative to quickly put up a UI if you are a C++ programmer. I personally prefer to write QWidgets in C++ code and not using the Qt Designer (though my colleague is the opposite). Using the Designer needs a lot of work arounds when you want to rearrange widgets (and sometimes you get empty cells in grid layouts that you need to clean up). I find it a lot easier to just rearrange the lines for
layout->addWidget(w);. Also, writing C++ gives a lot better overview which of the default parameters have been changed. I'd rather type on my keyboard than use the mouse (and my colleague is the exact opposite).(Though the idea of the Designer is enticing: There are interesting videos on YouTube where Steve Jobs does something quite similar using his NextSTEP instead of Qt: Just clicking a few widgets and connecting their slots.)
I would wish, though, to have a more modern looking interface with QWidgets and to have things like transitions and animations similar to QML a lot easier. (Though, there's already QPropertyAnimation.)
@SimonSchroeder said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
QWidgets provide a constistent interface for each (desktop) platform. It also provide only widgets that everybody knows. QML on the other hand is more like an interface to go crazy with design.
Qt Quick Controls have native styles now.
-
I am QML side, I do not remember the last time I used QWidgets.
I would say I can do whatever I want/think with QML.
It is a shame people still do not understand how one can produce cross-platform reusable GUI components with the mix of CMake, C++, and QML. The latter components can be plug and play in your application.
Also, QML is a declarative language that makes it cleaner than C++ for UI interfaces.
Now with tools like qmllint, it is quite easy to find errors before they happen at runtime.
QWidgets is C, and QML is C++ in the sense that if you want a fast thing done, you use QWidgets; if you want to design a reusable, nice-to-use interface, you use QML.@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
I would say I can do whatever I want/think with QML.
I'm not debating that. My claim is not that QML is not powerful enough, but that it maybe is too powerful 😉. (I would've preferred some more development on the QWidgets front instead.)
@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
It is a shame people still do not understand how one can produce cross-platform reusable GUI components with the mix of CMake, C++, and QML. The latter components can be plug and play in your application.
I doubt this is the reason why people are sticking to QWidgets. Everyone who managed to understand C++ would be able to include QML by putting in very little effort in how to do this. However, QML is a little closer to web development and I have concentrated on desktop applications and programming algorithms. I do know C++ which makes it easy to write code for QWidgets. Sure, I can learn QML, but my main goal is not UI design, but a working application.
@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
Also, QML is a declarative language that makes it cleaner than C++ for UI interfaces.
This arguments is not about C++, but only about QWidgets. C++ is a multiparadigm language. A quick google shows that it is possible to write a UI library for C++ which is declarative (this was my first hit: https://github.com/aui-framework/aui). C++ does not stand in the way of a declarative UI.
@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
if you want to design a reusable, nice-to-use interface, you use QML.
I don't see how that is not possible with QWidgets... (I'm writing desktop applications–if that matters for this discussion)
-
-
@Axel-Spoerl is there any way we could get some kind of usage statistics? For example the % of people using QML, QWidgets or both? Not sure if such a thing is actually tracked. I would imagine yes, to determine future development investments at Qt.
But it would be really cool to know this, especially a back then to now comparison!
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
I cloned the code, opened a Claude code session in the project's directory and asked Claude "Convert the project to use Qt Widgets. Exact visual equivalence is not needed, just keep the rough nesting."
This produced a runnable and apparently working executable.
Some numbers, that may or may not be relevant:
QML Widgets wc -l *.{qml,cpp,h} 2004 1777 (89%) wc -c appGerritWizard 568.928 352.280 (62%) pmap -x (RSS) 154.860 56.880 (37%) startup (avg of 5 runs) 293ms 76ms (26%) -
@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
I would say I can do whatever I want/think with QML.
I'm not debating that. My claim is not that QML is not powerful enough, but that it maybe is too powerful 😉. (I would've preferred some more development on the QWidgets front instead.)
@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
It is a shame people still do not understand how one can produce cross-platform reusable GUI components with the mix of CMake, C++, and QML. The latter components can be plug and play in your application.
I doubt this is the reason why people are sticking to QWidgets. Everyone who managed to understand C++ would be able to include QML by putting in very little effort in how to do this. However, QML is a little closer to web development and I have concentrated on desktop applications and programming algorithms. I do know C++ which makes it easy to write code for QWidgets. Sure, I can learn QML, but my main goal is not UI design, but a working application.
@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
Also, QML is a declarative language that makes it cleaner than C++ for UI interfaces.
This arguments is not about C++, but only about QWidgets. C++ is a multiparadigm language. A quick google shows that it is possible to write a UI library for C++ which is declarative (this was my first hit: https://github.com/aui-framework/aui). C++ does not stand in the way of a declarative UI.
@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
if you want to design a reusable, nice-to-use interface, you use QML.
I don't see how that is not possible with QWidgets... (I'm writing desktop applications–if that matters for this discussion)
@SimonSchroeder said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
I'm not debating that. My claim is not that QML is not powerful enough, but that it maybe is too powerful 😉. (I would've preferred some more development on the QWidgets front instead.)
That's a valid point but can be partly solved by restricting you to a subset of QML, where you just use Qt Quick Controls element without customizing them and views/containers from Qt Quick. The same is often applied to c++, we most of the time restrain ourself to a subset of it and don't use all its features.
@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
I doubt this is the reason why people are sticking to QWidgets. Everyone who managed to understand C++ would be able to include QML by putting in very little effort in how to do this. However, QML is a little closer to web development and I have concentrated on desktop applications and programming algorithms. I do know C++ which makes it easy to write code for QWidgets. Sure, I can learn QML, but my main goal is not UI design, but a working application.That's personal but I feel like not doing my UI in C++ brings me faster to a working application and allows me to then provide a good UX and thus a desirable product. I also write desktop applications at work (for professionals and not consumer apps if that makes a difference).
@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
This arguments is not about C++, but only about QWidgets. C++ is a multiparadigm language. A quick google shows that it is possible to write a UI library for C++ which is declarative (this was my first hit: https://github.com/aui-framework/aui). C++ does not stand in the way of a declarative UI.It kinda does though, I don't find easily understandable https://github.com/aui-framework/telegram_client/blob/master/src/view/ChatView.cpp
I believe the language frontier/interface between QML and C++ allows us to implement useful abstractions to ultimately have more expressive code. Stuff I couldn't do if I was only using one or the other language.@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
if you want to design a reusable, nice-to-use interface, you use QML.
I don't see how that is not possible with QWidgets... (I'm writing desktop applications–if that matters for this discussion)
That's not impossible to do with QWidgets but composability and easy implementation of properties are strong points of QML.
-
@Axel-Spoerl is there any way we could get some kind of usage statistics? For example the % of people using QML, QWidgets or both? Not sure if such a thing is actually tracked. I would imagine yes, to determine future development investments at Qt.
But it would be really cool to know this, especially a back then to now comparison!
-
@SimonSchroeder said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
I'm not debating that. My claim is not that QML is not powerful enough, but that it maybe is too powerful 😉. (I would've preferred some more development on the QWidgets front instead.)
That's a valid point but can be partly solved by restricting you to a subset of QML, where you just use Qt Quick Controls element without customizing them and views/containers from Qt Quick. The same is often applied to c++, we most of the time restrain ourself to a subset of it and don't use all its features.
@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
I doubt this is the reason why people are sticking to QWidgets. Everyone who managed to understand C++ would be able to include QML by putting in very little effort in how to do this. However, QML is a little closer to web development and I have concentrated on desktop applications and programming algorithms. I do know C++ which makes it easy to write code for QWidgets. Sure, I can learn QML, but my main goal is not UI design, but a working application.That's personal but I feel like not doing my UI in C++ brings me faster to a working application and allows me to then provide a good UX and thus a desirable product. I also write desktop applications at work (for professionals and not consumer apps if that makes a difference).
@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
This arguments is not about C++, but only about QWidgets. C++ is a multiparadigm language. A quick google shows that it is possible to write a UI library for C++ which is declarative (this was my first hit: https://github.com/aui-framework/aui). C++ does not stand in the way of a declarative UI.It kinda does though, I don't find easily understandable https://github.com/aui-framework/telegram_client/blob/master/src/view/ChatView.cpp
I believe the language frontier/interface between QML and C++ allows us to implement useful abstractions to ultimately have more expressive code. Stuff I couldn't do if I was only using one or the other language.@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
if you want to design a reusable, nice-to-use interface, you use QML.
I don't see how that is not possible with QWidgets... (I'm writing desktop applications–if that matters for this discussion)
That's not impossible to do with QWidgets but composability and easy implementation of properties are strong points of QML.
@GrecKo said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
It kinda does though, I don't find easily understandable https://github.com/aui-framework/telegram_client/blob/master/src/view/ChatView.cpp
Also to me this does not look extremely simple, but that's just one approach. I believe "declarative" widget code can generally be made as simple as QML, give or take a few syntax quirks. Proabably also not the best example, but e.g.. https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/texteditor/completionsettings.cpp#n130 looks rather straightforward to me, or with a bit more functionality https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/help/localhelpmanager.cpp#n240
I believe the language frontier/interface between QML and C++ allows us to implement useful abstractions to ultimately have more expressive code. Stuff I couldn't do if I was only using one or the other language.
For me personally, the language frontier is not a boon, but actually my biggest pain point: Code that started "on the wrong side", or where the environment has changed so that it should better be shifted to the other side now, cannot easily be shifted, but needs some actual translation, and given the different language paradigms that's not just some mechanical syntactic fixes but typically ends up effectively in a rewrite of the "shifted" code. It is much easier to shift blob of codes across interfaces if the implementation language can stay the same (what that language is kind of secondary, as long as it's the same on both sides)
-
@Axel-Spoerl is there any way we could get some kind of usage statistics? For example the % of people using QML, QWidgets or both? Not sure if such a thing is actually tracked. I would imagine yes, to determine future development investments at Qt.
But it would be really cool to know this, especially a back then to now comparison!
@J.Hilk said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
is there any way we could get some kind of usage statistics?
Not that I know of, unfortunately.
A recent survey has shown that just below 90% of Qt developers use C++ and roughly a third of Qt developers use QML. It would be wrong to conclude though that only a third of Qt users use QML, while the majority hangs on to widgets. A C++er with no QML connection could be a backend developer. And designers using QML weren't counted in this survey AFAIK.
So It's hard to say, really.
Software Engineer
The Qt Company, Oslo -
@J.Hilk said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
is there any way we could get some kind of usage statistics?
Not that I know of, unfortunately.
A recent survey has shown that just below 90% of Qt developers use C++ and roughly a third of Qt developers use QML. It would be wrong to conclude though that only a third of Qt users use QML, while the majority hangs on to widgets. A C++er with no QML connection could be a backend developer. And designers using QML weren't counted in this survey AFAIK.
So It's hard to say, really.
@Axel-Spoerl I use QML for all new projects. But we have to stick with Widgets in the old projects.
-
I don't have an opinion on which is better currently, because I don't have any significant practical experience with QML outside of some playing around, but I've seen QML's evolution over the almost two decades now and it certainly was a wild ride. It certainly tainted my perception of that tech. The fact that after all those years this discussion is still very much relevant and the choice for new projects is not always obvious speaks for itself.
At the announcement time the promise of QML looked interesting to me - simple, declarative syntax understandable to non-programmers and (big one for me) the hardware accelerated nature of it. 4K monitors were just entering the mass market, and fluid, animated UIs were getting popular too. Doing a 4K animation of a complex UI with widgets on the CPU is just painful to code and pretty choppy in use to this day.
But, as with all new technologies, QML had (a lot!) of teething problems. No visual editor (at that time), no platform styling, missing basic controls, had no docking capability and couldn't even show a dialog/popup window. There was no RHI backend at that time either, so my specific case of embedding a DirectX rendering window into the app made using heavily OpenGL bound QML a non starter. The long lasting mixed messaging on what should be in QML, JavaScript and C++ certainly didn't help. I'm a bit ashamed to admit that I still don't fully understand what the exact relation between Qt Quick and QML is. Then there was the issue of writing logic in JavaScript and the incredible bloat and performance issues that came with it. Took years to create proper tools to avoid that and establish some good practices.
Over the years those issues were being slowly addressed, but focus clearly shifted towards mobile/embedded use cases and there was this unspoken understanding that QML is for those platforms and widgets are for desktop. Stuff like multi-monitor, high DPI and font antialiasing were giant issues for years too, and, looking at topics that pop-up, they are not entirely solved to this day. There was also licensing and deployment issues on some QML stuff, etc. etc. It all improved of course later on, but using QML on desktop went through some real pains.
Overall I think it's a lot easier for new Qt users to adopt QML, as they are not tainted by the knowledge of really difficult road this tech walked. In my mind it was this convoluted mess of direction changes, panic patch work release to release, multiple misfires and incompatibilities (Qt Quick Controls 1 for example - an entire suit of components that went to trash). It seemed to pull the developers into this messy, incomplete, web development like environment and shifted from native code into the JavaScript land. That was hard to stomach for me. As a widgets user, I've seen it as this broken, unproven alpha quality tech that took all the attention and development time away from widgets - which powered real, deployed apps at that moment, so some bad blood was definitely created.
Having said that, a lot of time passed and a lot of things changed. Having distanced myself from all that mess a bit I would be curious to try and develop something with QML now, just to see where it stands, if not for any other reason.
-
@SimonSchroeder said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
I'm not debating that. My claim is not that QML is not powerful enough, but that it maybe is too powerful 😉. (I would've preferred some more development on the QWidgets front instead.)
That's a valid point but can be partly solved by restricting you to a subset of QML, where you just use Qt Quick Controls element without customizing them and views/containers from Qt Quick. The same is often applied to c++, we most of the time restrain ourself to a subset of it and don't use all its features.
@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
I doubt this is the reason why people are sticking to QWidgets. Everyone who managed to understand C++ would be able to include QML by putting in very little effort in how to do this. However, QML is a little closer to web development and I have concentrated on desktop applications and programming algorithms. I do know C++ which makes it easy to write code for QWidgets. Sure, I can learn QML, but my main goal is not UI design, but a working application.That's personal but I feel like not doing my UI in C++ brings me faster to a working application and allows me to then provide a good UX and thus a desirable product. I also write desktop applications at work (for professionals and not consumer apps if that makes a difference).
@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
This arguments is not about C++, but only about QWidgets. C++ is a multiparadigm language. A quick google shows that it is possible to write a UI library for C++ which is declarative (this was my first hit: https://github.com/aui-framework/aui). C++ does not stand in the way of a declarative UI.It kinda does though, I don't find easily understandable https://github.com/aui-framework/telegram_client/blob/master/src/view/ChatView.cpp
I believe the language frontier/interface between QML and C++ allows us to implement useful abstractions to ultimately have more expressive code. Stuff I couldn't do if I was only using one or the other language.@EduardoQtDev said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
if you want to design a reusable, nice-to-use interface, you use QML.
I don't see how that is not possible with QWidgets... (I'm writing desktop applications–if that matters for this discussion)
That's not impossible to do with QWidgets but composability and easy implementation of properties are strong points of QML.
@GrecKo said in Widgets vs. QML: Choose A Side — and Prepare to Lose Friends:
That's not impossible to do with QWidgets but composability and easy implementation of properties are strong points of QML.
I guess that "easy implementation" depends on the experience of the programmer with either QWidgets or QML. I'm very familiar with QWidgets and find that it has good composability and is easy to implement. I don't know QML (but I try to follow along with new developments on that front), so using QML is not easy for me. Both QWidgets and QML have several corner cases that need tricky workarounds. This means that you need lots of experience with both QWidgets and QML to become good at it.
-
I have been using Qt widgets to write Windows and Mac desktop software since Qt v1, back in the last century. I don't see any compelling reason to change to QML. I just wish the widgets got a bit more attention. For example, it would be nice to have the option to freeze the vertical or horizontal header in a QTableView without reams of code.
-
I don't have an opinion on which is better currently, because I don't have any significant practical experience with QML outside of some playing around, but I've seen QML's evolution over the almost two decades now and it certainly was a wild ride. It certainly tainted my perception of that tech. The fact that after all those years this discussion is still very much relevant and the choice for new projects is not always obvious speaks for itself.
At the announcement time the promise of QML looked interesting to me - simple, declarative syntax understandable to non-programmers and (big one for me) the hardware accelerated nature of it. 4K monitors were just entering the mass market, and fluid, animated UIs were getting popular too. Doing a 4K animation of a complex UI with widgets on the CPU is just painful to code and pretty choppy in use to this day.
But, as with all new technologies, QML had (a lot!) of teething problems. No visual editor (at that time), no platform styling, missing basic controls, had no docking capability and couldn't even show a dialog/popup window. There was no RHI backend at that time either, so my specific case of embedding a DirectX rendering window into the app made using heavily OpenGL bound QML a non starter. The long lasting mixed messaging on what should be in QML, JavaScript and C++ certainly didn't help. I'm a bit ashamed to admit that I still don't fully understand what the exact relation between Qt Quick and QML is. Then there was the issue of writing logic in JavaScript and the incredible bloat and performance issues that came with it. Took years to create proper tools to avoid that and establish some good practices.
Over the years those issues were being slowly addressed, but focus clearly shifted towards mobile/embedded use cases and there was this unspoken understanding that QML is for those platforms and widgets are for desktop. Stuff like multi-monitor, high DPI and font antialiasing were giant issues for years too, and, looking at topics that pop-up, they are not entirely solved to this day. There was also licensing and deployment issues on some QML stuff, etc. etc. It all improved of course later on, but using QML on desktop went through some real pains.
Overall I think it's a lot easier for new Qt users to adopt QML, as they are not tainted by the knowledge of really difficult road this tech walked. In my mind it was this convoluted mess of direction changes, panic patch work release to release, multiple misfires and incompatibilities (Qt Quick Controls 1 for example - an entire suit of components that went to trash). It seemed to pull the developers into this messy, incomplete, web development like environment and shifted from native code into the JavaScript land. That was hard to stomach for me. As a widgets user, I've seen it as this broken, unproven alpha quality tech that took all the attention and development time away from widgets - which powered real, deployed apps at that moment, so some bad blood was definitely created.
Having said that, a lot of time passed and a lot of things changed. Having distanced myself from all that mess a bit I would be curious to try and develop something with QML now, just to see where it stands, if not for any other reason.
@Chris-Kawa I would chalk a lot of your commentary up to marketing missteps.
QML is the json-link language. Quick is the graphic items. Each are usable to some degree on their own, eg qbs for QML, or QtSkinny for Quick.
Quick 1 was built on graphics view. Drawing wasn't generally hardware accelerated. From what I recall of discussions on the run-up to the initial announcement, development goals were heavily influenced by the lack of success of Qtopia. Make it easy to develop reasonably performant applications for small embedded devices. A
Buttonis aRectanglecontainingTextand aMouseArea. That sort of compositing went pretty far in the target market.In a way, it was the user interface equivalent to the project that became QPA. Rather than implementing a full port of Qt including the windowing system interface and widget styling, a device developer could get away with relatively little work at each end of the stack.
Quick 2 was born of a larger effort to define a new platform with hardware acceleration and a developer pool that would benefit from defined widget-like UI elements.
Controls 1 and 2 came later. I don't think that they are required reading to be effective. I've used them on occasion. As often as not, this was limited to API inspiration.
For the nostalgia:
Asking a question about code? http://eel.is/iso-c++/testcase/
-
@Chris-Kawa I would chalk a lot of your commentary up to marketing missteps.
QML is the json-link language. Quick is the graphic items. Each are usable to some degree on their own, eg qbs for QML, or QtSkinny for Quick.
Quick 1 was built on graphics view. Drawing wasn't generally hardware accelerated. From what I recall of discussions on the run-up to the initial announcement, development goals were heavily influenced by the lack of success of Qtopia. Make it easy to develop reasonably performant applications for small embedded devices. A
Buttonis aRectanglecontainingTextand aMouseArea. That sort of compositing went pretty far in the target market.In a way, it was the user interface equivalent to the project that became QPA. Rather than implementing a full port of Qt including the windowing system interface and widget styling, a device developer could get away with relatively little work at each end of the stack.
Quick 2 was born of a larger effort to define a new platform with hardware acceleration and a developer pool that would benefit from defined widget-like UI elements.
Controls 1 and 2 came later. I don't think that they are required reading to be effective. I've used them on occasion. As often as not, this was limited to API inspiration.
For the nostalgia:
@jeremy_k You're making me feel old... I wrote stuff for Qtopia for a custom embedded system back in the days when cross-compiling to arm was often an exercise in frustration because some of the software were not ready for that so you either had to fix them, fix their build system or sometime build them natively (hello 200MHz overclocked CPU, I remember you, fun times) to be able to debug the issues.
-
For both Widgets and Quick, we shouldn't need to be writing UI's from C++. I think this an indication of broken tooling, especially the Quick designer (which is powered by three different plugins in Creator?). Design Studio doesn't fix the issue, it seems like a mistake. At least with the Widgets designer, you get a more accurate representation of how a widget will appear at runtime.
