On 06 Dec 2013, at 17:46, Marcin M. <marmistrz...@gmail.com> wrote:
> 2013/12/6 Wim de Vries <wsvr...@xs4all.nl>
> On 12/05/2013 06:41 PM, Marcin M. wrote:
>> A style for plain Qt which would display with the native look & feel
>> (compare the unsupported and buggy meegotouch-qt-style) would be great too!
> > Do you mean QML or QWidgets look&feel?
>
> I mean: use plain Qt, get Silica look&feel. Just like on Fremantle: you use
> Qt, but get the gtk theme look & feel.
(walls of text here again; tl;dr: try QML, you’ll like it, it is better [easier
to write + faster to render] than QWidgets for implementing UIs)
No, that won’t be possible, and even if someone were to try and replicate it
(with much time and dedication, one can “fake” enough of it to look almost like
Sailfish Silica, I’m sure), you wouldn’t achieve the same visual quality (note
how the pattern of e.g. buttons and switches is not tied to the button and
switch, but rather “lights up” the background when you scroll? cannot see that
in screenshots, but only when you try it in the emulator / on the device) and
performance (QML2 with the Qt Scene Graph can utilize the GPU quite well, and
from what I’ve seen with Qt 5.2, this is only getting better).
QML is actually quite nice for defining how the UI looks. See it as (in
QWidgets terms) “more powerful versions of .ui files”. And don’t see it as “now
I have to code my app in JavaScript”, that’s not the case - you can use as much
or as little JavaScript as you want, and do the important stuff in C++.
Granted, most of the time you actually have to use JavaScript expressions to
set some property values, but the expressions look syntactically not much
different from their C++ counterparts, and you get the property binding
(automatic recalculation + update when a value the expression depends on) for
free. And that’s also the reason why (short from moc-style pre-processing and
custom language extensions on the C++ side) there is an actual need for dynamic
languages like JavaScript in QML - you can’t do property bindings in “pure” C++
code, as the AST of the expression is lost after compile time.
Yes, it requires you to learn something new, and yes, it’s hard in the
beginning (it was for me) until you start realizing that you’re not modifying
the UI tree from your C++ code anymore, but rather, you access the C++
code/state from your UI. The C++ code only needs to expose the state / content
/ database in a nice way (Qt models, invokables, properties, signals and slots,
etc..) and then you can access these from the UI whenever you want.
And if you get the properties on your C++ objects right, with notifications and
all, you never have to worry when (for example) to set your button to enabled /
disabled manually (mybutton.setEnabled(true), etc..), because you only define
e.g. on the C++ side a property that tells you if you’re currently processing
something or not (say a boolean property “processing”) and then on the QML
side, you can easily say “Button { enabled: !myobject.processing }” and the
button enabled state will always be right, and will be recalculated accordingly
when the "processing" property’s value changes. This provides a nice way to
split your backend from the UI and not worry about keeping your UI state in
sync. You can even use that property in multiple places in the UI or not at all
- the C++ side doesn’t change, which is nice (so you can e.g. have the same C++
backend for different QML UIs - one for phone, one for tablet, one for desktop,
etc..)
If that little JavaScript running there every time something changes sounds
like too much overhead for you, think of it this way: The amount of CPU
“wasted” by running JS in the QML case is saved (and paid back multiple times)
by offloading big parts (not all) of the rendering from the CPU to the GPU.
HTH :)
Thomas
_______________________________________________
SailfishOS.org Devel mailing list
