ubuntu-phone team mailing list archive

[Timo Jyrinki <timo.jyrinki@xxxxxxxxx>]

2014-06-23 17:22 GMT+03:00 Sebastien Bacher <seb128@xxxxxxxxxx>:
> I've discussed the topic a bit on IRC and the advices/replies include:
> - qmlscene is a dev tools and shouldn't be used by those applications
> - you should change the environment/export a variable to make qt5 the
> default (seems to be what ubuntu-touch does)
> - install qt5-default ... but that would bring some extra 50MB on the iso

The discussion has come up earlier, but we've stuck with qmlscene
because we haven't had big enough problems to get eg. SDK team to
write our own wrapper. For a brief moment we had 'qmlrunner' symlink
idea but that was backed out when the problem at hand was solved in
another way.

As mentioned in the Dmitry's codereview link, upstream thinks Qt
Creator is the only user tool and and the rest are development tools.
Qtchooser is meant for using the development tools, which don't want
automatic fallbacks. You don't want to accidentally use Qt 5's qmake
when you have selected to use Qt 4. KDE is having a similar problem
since they use qdbus. Even though Qt 4 is the default if no selection
has been made, an user might install qt5-default or set an environment
variable, and so KDE has resorted to workarounds too.

A direction worth going towards in Ubuntu at least would be to get rid
of hard-coded 'qmlscene' calls. If eg. ubuntu-app-launch would be the
only place that launches apps, and it would know how to launch
QML-only apps (file.qml) by using a launcher instead of calling an
executable directly, then we could more easily switch between
launchers. It doesn't solve eg. the SDK Gallery problem on the desktop
before we have that alternative launcher, but it's a necessary step to
consider switching away to our own wrapper.

Both 'qmlscene' and its successor 'qml' are around 400 lines of code,
so they should be simple to replace with another one. Unity8 already
has 'uqmlscene' modified from qmlscene in their tests, maybe that's a
good name :) There shouldn't be a problem in using two wrappers in
parallel for some time, although I'm currently running my mako with
'qml' (I overwrote 'qmlscene' with it) and there seem to be small
layout differences in eg. clock. So apparently the scene is set up in
a bit different way from qmlscene.

We could survive a bit longer by distro patching qtchooser (another
workaround), but I feel that eventually we'd like to have more control
on the QML app startups and have a simple binary location instead of
the workarounds? For example in case any startup time optimizations
would require hooking into it. There are some old requests too, I used
the 'qmlscene' tag:
https://bugs.launchpad.net/bugs/+bugs?field.tag=qmlscene

-Timo