[Development] Qml mime types

[Alan Alpert]

On Tue, Dec 11, 2012 at 6:12 AM, Mohamed Fawzi <Fawzi.Mohamed at digia.com> wrote:
> I sort of expected qml-qt-quick to be considered not ok (also Marco Bubke raised that point), which is a fair point, considering BB for example.
> I am open to better naming, still I would like to differentiate
>   "file using qml syntax"
> from
>   ".qml file that is supposed to be loaded in the qml runtime or qmlscene"
> as that is an useful distinction for example to decide how to open such a file, or which search path to consider for modules in an editor.

Maybe it is useful now, but that's not the correct conceptual split.
Firstly QML is a language, not just a syntax. Secondly the runtime
discussion is heading towards the correct conceptual split, so we
probably should too. This would mean that

".qml" means a file written in the QML language that can probably be
loaded with the qml runtime. I say probably because there might be
subcomponents that don't do much on their own, because we encourage
users to split up their code into different files.

".qqk" means a file written for qmlscene because it's an incomplete
QtQuick 2 scene (qmlscene also uses the QML language). I did just make
this extension up, but that's because it only really needs to be
differentiated once we have a real QML runtime.

".qbs" means a file written for qbs (QBS also uses the qml language).

So basically I'd advocate making just .qml mean any file written in
the QML language, and let the specializations like QtQuick 2 scenes
have their own extensions if they want to differentiate themselves.

I understand that the current reality is that virtually all .qml files
use QtQuick, and most of those are still using QtQuick 1. The
important thing to keep in mind is that back in the Qt 4.x days QML
was still a nascent technology and the language was not well separated
from the single use-case. I maintain that is the correct way to start,
because without one stellar use-case implemented then the technology
would never get anywhere. But now QML is starting to develop beyond
the one usecase, and we're only now implementing the proper
abstractions around that (like the QML runtime). We need to move on
from the limitations of QtQuick 1, like the lack of a top-level window
item, as much as possible (without screwing over QQ1 users, as much as
possible), and I think that means the .qml extension needs to move
away from QtQuick-specific as soon as possible. Note that it's not
really possible until we have that QML runtime, so there's still time
to think about that switch ;) .

--
Alan Alpert