[Development] Pending decisions on co-installation

[Chris Adams]

Hi,

On Wed, Oct 31, 2012 at 8:17 PM, Sune Vuorela <nospam at vuorela.dk> wrote:

> On 2012-10-30, Thiago Macieira <thiago.macieira at intel.com> wrote:
> > 1) QML environment variables
> > The variable for import paths has been versioned from QML_IMPORT_PATH to
> > QML2_IMPORT_PATH. But I have not changed any of the other variables. We
> need a
> > decision from the team familiar with the engines and the meanings of
> those
> > variables to know which ones should be versioned too.
> >
> > They need to be versioned if having a value set in it applies to one QML
> > engine but has ill-effects for the other.
>
> isn't 'not versioning this' a recipe for disaster for both end users of
> applications and for developers of applications if we don't do something
>

Only if the meaning of the variable or config option changes in different
versions.  Most of the ones that I can think of from the top of my head are
applicable in the same way to both QML1 and QML2 (for example,
QML_COMPILER_STATS, QML_COMPILER_DUMP, QML_IMPORT_TRACE are all just
debugging helpers which cause statistics or extra information to be emitted
from the engine), however some others deserve closer inspection:

Compiler / Bindings / VM / JS:
QML_DISABLE_OPTIMIZER: disables v4 in QML2, disables "compiledbindings" in
QML1.  In the future, with v4vm or similar, this might mean "use v8 instead
of v4vm" in QML2...
QML_DISABLE_FAST_PROPERTIES: this config option was QML1 only, and
determined whether fast JS accessors for QObject properties were installed,
I believe.
QML_VERBOSE_COMPILER: verbose output from v4 in QML2 when building the IR
QML_BINDINGS_TEST: verbose output from v4 in QML2 creating binding
assignments
QML_REWRITE_DUMP: verbose output from bindings/signal handlers expression
rewriter in both QML1 and QML2
QML_BINDINGS_DUMP: verbose output from compiler in QML1 only
QML_CHECK_TYPES: check for typename clashes in both QML1 and QML2
QML_DUMP_ERRORS: output any errors which occurred during typeloading in
QML2 instead of just appending to engine's warning list

Other:
QML_DISABLE_DISTANCEFIELD: the distancefield text rendering is new to Qt5,
I believe, so this config option was added in QML2.
QML_ENABLE_TEXT_IMAGE_CACHE: in QML1 only, although we still do text image
caching in some situations in QML2
QML_FBO_OVERLAY: QML2 only, related to shaders
QML_XHR_DUMP: QML1 and QML2, for debugging xml http requests
QML_VISUAL_TOUCH_DEBUGGING: QML2 only, for debugging touch and mouse events

Scene graph related (QML2 only) - I don't really know what these do in
detail, although most seem fairly self explanatory:
QML_FLASH_MODE
QML_TRANSLUCENT_MODE
QML_DEBUG_LEAK_BACKTRACE
QML_FORCE_THREADED_RENDERER and its amusing twin QML_BAD_GUI_RENDER_LOOP
QML_RENDERER_TIMING
QML_FIXED_ANIMATION_STEP
QMLSCENE_DEVICE

and finally the infamous QML_IMPORT_PATH.

Regarding QML_IMPORT_PATH, I discussed this yesterday and this morning with
Martin Jones and Andrew den Exter, and a couple of things deserve
mentioning:
1) through the versioning of imports (ie, the path lookup with major/minor
version appended to module name) a client can create a QML1
(QDeclarativeExtensionPlugin) module plugin and install it into, say,
"$QML_IMPORT_PATH/com/examplecompany/examplemodule1/" and then create a
QML2 (QQmlExtensionPlugin) module plugin and install it into
"$QML_IMPORT_PATH/com/examplecompany/examplemodule2/", and this will work
fine.

That is, the QML_IMPORT_PATH need not be different (or set differently)
between applications using QML1 and QML2, so long as they import the
modules of the correct version (ie, for the version of QML against which
their application is written).

So, I'm not sure that QML_IMPORT_PATH needs to be versioned, so long as
QML's imports versioning system works as expected in future versions.
I'm not sure that we need to have a qt5/imports dir for QML1 plugins and a
separate qt5/qml dir for QML2 plugins, since coexisting qq1/qq2 plugins
worked previously according to versioning, with the same import path.  A
problem might occur if you set QML_IMPORT_PATH to point to a qt4 (QML1)
import path, and then run a qt5 QML1 application - it'll be trying to load
QML1 plugins built against qt4, which will fail.

Anyway, the long and short of it is -- these variables / configure options
are all developer-facing, so to be honest, we don't think it's a huge issue
to change them if we want to, or leave them (and document the differences
if required) if that is simpler or less confusing.


>
> >
> > 2) QML tool names
> > Kai raised the point that many of the QML 2 tools work for QML 1 too and
> maybe
> > even for Qt 4's QML 1. We need confirmation on that as well as the
> willingness
> > to keep them that way for one or two years at least. For the tools that
> work
> > on both QML engines, we can drop the version number from their names.
>
> ack.
>

Again, most of these tools are developer-facing, so renaming them isn't a
huge issue, in our opinion.
I think it is a bit ugly that you can't tell from the name whether
something is QML1 or QML2 only (eg, qmlviewer and qmlbundle), so including
version numbers in tools that don't work for both versions seems like a
good idea (but then you have the problem that they might work in future
versions, but we can cross that bridge when we get to it).  I also think
that qmlscene and qmlviewer do somewhat different things (apart from
working with different versions of QML) which is why I personally prefer
qml2scene over qml2viewer, but that's just an opinion and my reasoning
isn't too concrete there.  For tools which work in both, dropping the
version number seems fine.

To summarise: renaming config options, env vars and tools seems ok, because
they're developer-facing only, for the most part.  Whichever seems
cleanest, and least confusing, we should do.

Cheers,
Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121101/13b8ceac/attachment.html>