[Development] Qml mime types

[Mohamed Fawzi]

I think it could be useful to do a small recap on mime types, as that is what I am interested in, not extensions (ignore if it is obvious to you):
a mime type identifies a type of file, mime types are hierarchical, i.e. a mime type can be a subclass of another.
For example "text/plain; charset=utf-8" is a superclass to a lot of types.
If you don't know how to handle type x, but you know how to handle its superclass "text/plain; charset=utf-8" then you might handle the file like that.
When you get a file you will have to figure out its mime type.
That might come in a meta data, or be guessed from some "magic" content at the beginning of the file, but very often it is done through the file extension.
Still it is possible for a given mime type to have no, or several extensions (think the "text/plain; charset=utf-8" example).
Mime types are about how to handle the file in a meaningful way.

For an editor that can do syntax highlighting for QML, (the use case at the origin of this whole discussion), knowing that a file is some kind of QML is valuable, and I would argue also to decide what to do when trying to open it on linux for example. If it is a more specific type it knows how to handle it might do better, it might have default imports and search paths.

I would like to register some types now, later we can always extend them with new types.

As said I think that having a type for any file with QML syntax (.qbs and .qmltypes do use the qmlparser, but don't use qdeclarative) is valuable.
What remains to be seen is the type of the current qml files.

I propose the following hierarchy:

text/plain; charset=utf-8
   text/vnd.qt.qml-base : a file using the qml syntax in some context
     text/vnd.qt.qml : the current .qml files
     text/vnd.qt.qbs : a qbs file
     text/vnd.qt.qml-meta-info : qmltypes meta info
     text/vnd.qt.qml-project : a qmlproject file

later we might want to split 
text/vnd.qt.qml in several subtypes (and probably own extensions) for example:
text/vnd.qt.qml-qtquick1
text/vnd.qt.qml-qtquick2
  text/vnd.qt.qml-qq2-partial
  text/vnd.qt.qml-qq2-full

but I think it is better to leave that for another time, we just have to make sure that we can accomodate them in a reasonable way if/when the need arises.

I did think about the +qml, but that did just look strange to me, so I skipped it, but I am willing to reconsider that if someone feels strongly about that.

Fawzi
________________________________________
From: Alan Alpert [416365416c at gmail.com]
Sent: Tuesday, December 11, 2012 9:03 PM
To: Mohamed Fawzi
Cc: Knoll Lars; faure at kde.org; development at qt-project.org
Subject: Re: [Development] Qml mime types

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