A design question.
-
Hello everyone,
I'm still stumbling in my QML-Adventure and I've come across something strange.
If you create an UI with widgets and use some standart Widgets like a
QComboBox
or aQSpinbox
, it translates to OS specific looks that everyone recognizes.Example: the tumbler that moves up from the bottom of the screen.
If you do the same with the QML-equivalent
SpinBox
orComboBox
You get this:
with a popup menu.
Am I missing some settings here, or is this intended behaviour, and one has to use a Tumbler and customize that?
Position, fade in and out etc.I find this strange, because I thought QML was specifically designed and created with mobile applications in mind.
-
@J.Hilk said in A design question.:
Am I missing some settings here, or is this intended behaviour, and one has to use a Tumbler and customize that?
intended behavior.
Thats why there is a Tumbler element available.And thats good. This way you can have both widget types on all platforms, instead of being forced into using one.
-
That's unfortunate! For me, this complicates things significantly. T_T
-
@J.Hilk
and why?
Maybe you are just dealing with the issue not right -
Ok, a short summary.
I have an App containing a header, a Menu that can be faded in and out and a Stackview displaying different things, depending an the Menu-Selection. All nested in a Scroll area that expands, depending on the height of the qml-file displayed in the stackview and on the visibility of the menu.To garantie that the Tumbler object is like the default Tumbleritem and that it is always at the same spot and with the same size, it has to be part of the root qml file and hast to be feed with content by the stackview and hast to send the information about the selection back again
That means a alot of signals/slots and/or cross file properties etc.
All in all something I have done before, in c++. But a lot of work for an optical gimmick and I'm tempted to leave the defalt
ComboBox
andSpinBox
objects in there, even so it breaks the mobile-immersion