Thanks for elaborating! :)
Btw. will this payback always in QML (so let's assume Fremantle Qt 4.7.4)
or only on Sailfish?
--
Marcin
2013/12/7 Thomas Perl <th.p...@gmail.com>
> 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
>
_______________________________________________
SailfishOS.org Devel mailing list
