[SailfishDevel] Serious request: please let us use C++!

[Wim de Vries]

Thanks Thomas,
Could you elaborate  a bit more on standard QML/openGL and Sailfish.
I did manage to mix non-Sailfish-QML and Sailfish (using QML listViews 
with specialized UIs within a surrounding Sailfish UI [pages]),
but now but QML-openGL won't work within the Sailfish pages (see topic 
"qml and opengl/c++"),
maybe I should have named it "opengl-under-QML within Sailfish".
Thanks.


On 12/07/2013 12:00 PM, Thomas Perl wrote:
> On 06 Dec 2013, at 17:46, Marcin M. <marmistrzmar at gmail.com> wrote:
>> 2013/12/6 Wim de Vries <wsvries at 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
>