MIME type support in Qt5

[w***@nokia.com]

Hi,

I'd like to work with you on MIME type support for Qt5. To avoid discussing in thin air you can find an initial proposal under ssh://***@codereview.qt-project.org:29418/qt-labs/qtaddonmimetype.git. The purpose of the typedefs in the code is to make later refactoring easier. During cleanup for a final version, these can all go away if that is the general consensus.

Alongside with the API, the code includes a pseudo platform implementation, some documentation and unit tests for both C++ and QML which both fail in areas that require a proper backend implementation.

The proposal consists of the classes QMimeType, QServiceAction and QMimeTypeRegistry.

QMimeType is a value class that contains the actual MIME type e.g. image/png

QServiceAction is a way to specify a user action on a file e.g. open.

QMimeTypeRegistry finally allows MIME types, actions and applications to register, and to perform queries on the registry. While the queries are straightforward, I am beginning to wonder if the registration part isn't actually to system specific to be part of this API.

I am looking forward to your feedback and suggestions.

Michael

PS: Sorry about the previous attempts without subject. I had a fight with Outlook Web App under Linux.

[Thiago Macieira]

On Wednesday, 14 de September de 2011 15.41.25, wolf-***@nokia.com
wrote:
> I'd like to work with you on MIME type support for Qt5. To avoid discussing
> in thin air you can find an initial proposal under
> ssh://***@codereview.qt-project.org:29418/qt-labs/qtaddonmimetype.git.

Michael, we cannot access the new website. It's still firewalled.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Oswald Buddenhagen]

On Wed, Sep 14, 2011 at 06:54:48PM +0300, ext Thiago Macieira wrote:
> On Wednesday, 14 de September de 2011 15.41.25, wolf-***@nokia.com
> wrote:
> > I'd like to work with you on MIME type support for Qt5. To avoid discussing
> > in thin air you can find an initial proposal under
> > ssh://***@codereview.qt-project.org:29418/qt-labs/qtaddonmimetype.git.
>
> Michael, we cannot access the new website. It's still firewalled.
>
it's mirrored on gitorious under the same path. of course it was not too
helpful to post the so far internal url in the first place. ;)

[w***@nokia.com]

Hi,

Thanks for the friendly words. I would used have used much stronger language. ;-)

In any case the mirror is can be found under git://gitorious.org/qt-labs/qtaddonmimetype.git

Michael

________________________________________
From: qt5-feedback-bounces+wolf-michael.bolle=***@qt.nokia.com [qt5-feedback-bounces+wolf-michael.bolle=***@qt.nokia.com] on behalf of Buddenhagen Oswald (Nokia-MP-Qt/Berlin)
Sent: Wednesday, September 14, 2011 6:46 PM
To: qt5-***@qt.nokia.com
Subject: Re: [Qt5-feedback] MIME type support in Qt5

On Wed, Sep 14, 2011 at 06:54:48PM +0300, ext Thiago Macieira wrote:
> On Wednesday, 14 de September de 2011 15.41.25, wolf-***@nokia.com
> wrote:
> > I'd like to work with you on MIME type support for Qt5. To avoid discussing
> > in thin air you can find an initial proposal under
> > ssh://***@codereview.qt-project.org:29418/qt-labs/qtaddonmimetype.git.
>
> Michael, we cannot access the new website. It's still firewalled.
>
it's mirrored on gitorious under the same path. of course it was not too
helpful to post the so far internal url in the first place. ;)

[Иван Комиссаров]

Michael, take a look at https://gitorious.org/qmime it almost finished. Can' look at what progress you have, but if you want to start from scratch i don't think it is a good idea.

14.09.2011, × 19:41, <wolf-***@nokia.com> <wolf-***@nokia.com> ÎÁÐÉÓÁÌ(Á):

Hi,

I'd like to work with you on MIME type support for Qt5. To avoid discussing in thin air you can find an initial proposal underssh://***@codereview.qt-project.org:29418/qt-labs/qtaddonmimetype.git. The purpose of the typedefs in the code is to make later refactoring easier. During cleanup for a final version, these can all go away if that is the general consensus.

Alongside with the API, the code includes a pseudo platform implementation, some documentation and unit tests for both C++ and QML which both fail in areas that require a proper backend implementation.

The proposal consists of the classes QMimeType, QServiceAction and QMimeTypeRegistry.

QMimeType is a value class that contains the actual MIME type e.g. image/png

QServiceAction is a way to specify a user action on a file e.g. open.

QMimeTypeRegistry finally allows MIME types, actions and applications to register, and to perform queries on the registry. While the queries are straightforward, I am beginning to wonder if the registration part isn't actually to system specific to be part of this API.

I am looking forward to your feedback and suggestions.

Michael

PS: Sorry about the previous attempts without subject. I had a fight with Outlook Web App under Linux.

[John Layt]

On Wednesday 14 Sep 2011 17:01:10 Иван Комиссаров wrote:
> Michael, take a look at https://gitorious.org/qmime it almost finished.
> Can' look at what progress you have, but if you want to start from scratch
> i don't think it is a good idea.
>
> 14.09.2011, в 19:41, <wolf-***@nokia.com>
> <wolf-***@nokia.com> написал(а):
>
> > Hi,
> >
> > I'd like to work with you on MIME type support for Qt5. To avoid
> > discussing in thin air you can find an initial proposal
> > underssh://***@codereview.qt-project.org:29418/qt-labs/qtaddonmimetype.gi
> > t. The purpose of the typedefs in the code is to make later refactoring
> > easier. During cleanup for a final version, these can all go away if that
> > is the general consensus.

Hi,

Isn't David Faure also working on a QMimeType proposal based on KMimeType? It
would be good to co-ordinate all these efforts, especially as David has
considerable knowledge gained from maintaining KMimeType for many years.

John.

[Иван Комиссаров]

Yes, he did. However, i didn't had time at that time and worked stopped.
Just to be clear - what format we should store mime types? I think we have to use xml format (due to existing database in linux) and binary format to spread it with Qt on win/mac.

15.09.2011, в 0:46, John Layt написал(а):

On Wednesday 14 Sep 2011 17:01:10 Иван Комиссаров wrote:
> Michael, take a look at https://gitorious.org/qmime it almost finished.
> Can' look at what progress you have, but if you want to start from scratch
> i don't think it is a good idea.
>
> 14.09.2011, в 19:41, <wolf-***@nokia.com>
> <wolf-***@nokia.com> написал(а):
>
>> Hi,
>>
>> I'd like to work with you on MIME type support for Qt5. To avoid
>> discussing in thin air you can find an initial proposal
>> underssh://***@codereview.qt-project.org:29418/qt-labs/qtaddonmimetype.gi
>> t. The purpose of the typedefs in the code is to make later refactoring
>> easier. During cleanup for a final version, these can all go away if that
>> is the general consensus.

Hi,

Isn't David Faure also working on a QMimeType proposal based on KMimeType? It
would be good to co-ordinate all these efforts, especially as David has
considerable knowledge gained from maintaining KMimeType for many years.

John.
_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[w***@nokia.com]

I believe the storage is something that we will have to leave to the actual backend. As you said, Windows and Mac already have their own storage system in place. Under Linux, we have the existing database in XML format. Other platforms might require a completely different storage.

I just cloned David's work. It looks like we should merge our efforts.

________________________________________
From: qt5-feedback-bounces+wolf-michael.bolle=***@qt.nokia.com [qt5-feedback-bounces+wolf-michael.bolle=***@qt.nokia.com] on behalf of ext Иван Комиссаров [***@gmail.com]
Sent: Wednesday, September 14, 2011 10:56 PM
To: qt5-***@qt.nokia.com
Subject: Re: [Qt5-feedback] MIME type support in Qt5

Yes, he did. However, i didn't had time at that time and worked stopped.
Just to be clear - what format we should store mime types? I think we have to use xml format (due to existing database in linux) and binary format to spread it with Qt on win/mac.

15.09.2011, в 0:46, John Layt написал(а):

On Wednesday 14 Sep 2011 17:01:10 Иван Комиссаров wrote:
> Michael, take a look at https://gitorious.org/qmime it almost finished.
> Can' look at what progress you have, but if you want to start from scratch
> i don't think it is a good idea.
>
> 14.09.2011, в 19:41, <wolf-***@nokia.com>
> <wolf-***@nokia.com> написал(а):
>
>> Hi,
>>
>> I'd like to work with you on MIME type support for Qt5. To avoid
>> discussing in thin air you can find an initial proposal
>> underssh://***@codereview.qt-project.org:29418/qt-labs/qtaddonmimetype.gi
>> t. The purpose of the typedefs in the code is to make later refactoring
>> easier. During cleanup for a final version, these can all go away if that
>> is the general consensus.

Hi,

Isn't David Faure also working on a QMimeType proposal based on KMimeType? It
would be good to co-ordinate all these efforts, especially as David has
considerable knowledge gained from maintaining KMimeType for many years.

John.
_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[David Faure]

On Wednesday 14 September 2011 20:01:10 Иван Комиссаров wrote:
> Michael, take a look at https://gitorious.org/qmime it almost finished. Can'
> look at what progress you have, but if you want to start from scratch i
> don't think it is a good idea.

It is definitely not "almost finished". It parses the raw XML instead of
parsing the generated plain text files, and it has its own copy of the
freedesktop.org.xml instead of looking up the system files (which should be
done with the QStandardPaths class I finished the MR for, yesterday).
(https://qt.gitorious.org/qt/qtbase/merge_requests/50)

Also, it exposes too much internals of the spec, such as the various fields
for magic (content-based) matching; this is all because QtCreator has a GUI
for defining your own mimetypes, but I can't think of any use case for a user
defining his own magic rules...

I think starting from a clean "this is what we want" API like Wolf-Michael is
doing is a better idea.
As Wolf-Michael noted, the API for creating mimetypes doesn't really belong in
there; that's far too system-dependent, and far too "rare" compared to
queries.

And the implementation should parse the files generated by update-mime-
database, which is much faster -- and I can provide the code for that, having
already written all that code for KDE.

So, from qmime.git, neither the API nor the implementation make much sense to
me, only the unit tests are reusable. Well, the API can still provide input
for qtaddonmimetype.git of course.


On the other hand I'm not sure that querying the association with applications
and the open/view/edit distinction belongs there, it doesn't seem very cross-
platform -- but that's a separate discussion.

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Konstantin Tokarev]

15.09.2011, 11:50, "David Faure" <***@kde.org>:
> Also, it exposes too much internals of the spec, such as the various fields
> for magic (content-based) matching; this is all because QtCreator has a GUI
> for defining your own mimetypes, but I can't think of any use case for a user
> defining his own magic rules...

Why can't you think of MIME type editor, e.g. like one in ROX Filer?

--
Regards,
Konstantin

[l***@nokia.com]

On 9/15/11 10:13 AM, "ext Konstantin Tokarev" <***@yandex.ru> wrote:

>
>
>15.09.2011, 11:50, "David Faure" <***@kde.org>:
>> Also, it exposes too much internals of the spec, such as the various
>>fields
>> for magic (content-based) matching; this is all because QtCreator has a
>>GUI
>> for defining your own mimetypes, but I can't think of any use case for
>>a user
>> defining his own magic rules...
>
>Why can't you think of MIME type editor, e.g. like one in ROX Filer?

And the question is whether this is a usecase that should be supported by
Qt essentials. I don't think so.

Mimetype handling should become part of the basic offering. But only for
the common use case of reading them and figuring out themimetype of files
and data.

Cheers,
Lars

[Thiago Macieira]

On Thursday, 15 de September de 2011 08.34.10, ***@nokia.com wrote:
> >Why can't you think of MIME type editor, e.g. like one in ROX Filer?
>
> And the question is whether this is a usecase that should be supported by
> Qt essentials. I don't think so.
>
> Mimetype handling should become part of the basic offering. But only for
> the common use case of reading them and figuring out themimetype of files
> and data.

I'm of the same opinion.

Writing Qt functionality that benefits one application in the system seems
superfluous. We're trying to resolve the common case here.

If editing MIME types turns out to be a common task, then we can revisit.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Wolf-Michael Bolle]

On Thursday 15 September 2011 11:45:30 ext Thiago Macieira wrote:
> > > Why can't you think of MIME type editor, e.g. like one in ROX Filer?
> >
> > And the question is whether this is a usecase that should be supported by
> > Qt essentials. I don't think so.
> >
> > Mimetype handling should become part of the basic offering. But only for
> > the common use case of reading them and figuring out themimetype of files
> > and data.
>
> I'm of the same opinion.
>
> Writing Qt functionality that benefits one application in the system seems
> superfluous. We're trying to resolve the common case here.
>
> If editing MIME types turns out to be a common task, then we can revisit.

In the spirit of this discussion I'd like to point out that I need a way to
create QMimeType objects with all their properties set. Can we add
constructors to QMimeTypeData and QMimeType like this:

QMimeTypeData::QMimeTypeData(
const QString &theType,
const QString &theComment,
const LocaleHash &theLocaleComments,
const QStringList &theAliases,
const QString &theGenericIconName,
const QList< QMimeGlobPattern > &theGlobPatterns,
const QStringList &theSubClassOf,
const QString &thePreferredSuffix,
const QStringList &theSuffixes,
const QList< QMimeMagicRuleMatcher > &theMagicMatchers)
: suffixPattern(QLatin1String("^\\*\\.[\\w+]+$")),
, type(theType)
, comment(theComment)
, localeComments(theLocaleComments)
, aliases(theAliases)
, genericIconName(theGenericIconName)
, globPattterns(theGlobPatterns)
, subClassOf(theSubClassOf)
, preferredSuffix(thePreferredSuffix)
, suffixes(theSuffixes)
, magicMatchers(theMagicMatchers)
{
if (!suffixPattern.isValid())
qWarning("MimeTypeData(): invalid suffixPattern");
}

QMimeType::QMimeType(
const QString &theType,
const QString &theComment,
const LocaleHash &theLocaleComments,
const QStringList &theAliases,
const QString &theGenericIconName,
const QList< QMimeGlobPattern > &theGlobPatterns,
const QStringList &theSubClassOf,
const QString &thePreferredSuffix,
const QStringList &theSuffixes,
const QList< QMimeMagicRuleMatcher > &theMagicMatchers)
: d(new QMimeTypeData(...))
{}

[Robin Burchell]

On Mon, Sep 19, 2011 at 11:57 AM, Wolf-Michael Bolle
<wolf-***@nokia.com> wrote:
> In the spirit of this discussion I'd like to point out that I need a way to
> create QMimeType objects with all their properties set. Can we add
> constructors to QMimeTypeData and QMimeType like this:

why do you need this done in the constructor? this is, to me, really
not good API. it's one of my pet peeves.

worth mentioning is that this is also mentioned in the Little Manual
of API Design: http://chaos.troll.no/~shausman/api-design/api-design.pdf,
section 4.11 "Strive for property-based APIs"

[Wolf-Michael Bolle]

On Monday 19 September 2011 12:04:01 ext Robin Burchell wrote:

> > In the spirit of this discussion I'd like to point out that I need a way
> > to create QMimeType objects with all their properties set. Can we add
> > constructors to QMimeTypeData and QMimeType like this:
>
> why do you need this done in the constructor? this is, to me, really
> not good API. it's one of my pet peeves.

I want this class to be immutable. Such a class needs a way to get its
properties initialized. Please explain why that is in your opinion a bad API.

> worth mentioning is that this is also mentioned in the Little Manual
> of API Design: http://chaos.troll.no/~shausman/api-design/api-design.pdf,
> section 4.11 "Strive for property-based APIs"

Thanks for the link.

[Иван Комиссаров]

19.09.2011, в 14:18, Wolf-Michael Bolle написал(а):

> On Monday 19 September 2011 12:04:01 ext Robin Burchell wrote:
>
>>> In the spirit of this discussion I'd like to point out that I need a way
>>> to create QMimeType objects with all their properties set. Can we add
>>> constructors to QMimeTypeData and QMimeType like this:
>>
>> why do you need this done in the constructor? this is, to me, really
>> not good API. it's one of my pet peeves.
>
> I want this class to be immutable. Such a class needs a way to get its
> properties initialized. Please explain why that is in your opinion a bad API.

Yes, QMimeType should be immutable; if user need to create type in code, he should use QMutableMimeType.

So, as long as user shouldn't use QMimeType for creation of mime types, we can use protected constructor that takes QMimeTypeData instead.

[Wolf-Michael Bolle]

On Monday 19 September 2011 12:39:20 ext Иван Комиссаров wrote:

> > > > In the spirit of this discussion I'd like to point out that I need a
> > > > way to create QMimeType objects with all their properties set. Can we
> > > > add constructors to QMimeTypeData and QMimeType like this:
> > >
> > > why do you need this done in the constructor? this is, to me, really
> > > not good API. it's one of my pet peeves.
> >
> > I want this class to be immutable. Such a class needs a way to get its
> > properties initialized. Please explain why that is in your opinion a bad
> > API.
>
> Yes, QMimeType should be immutable; if user need to create type in code, he
> should use QMutableMimeType.
>
> So, as long as user shouldn't use QMimeType for creation of mime types, we
> can use protected constructor that takes QMimeTypeData instead.

I actually dislike the inheritance. It screams for a virtual destructor when
the API really doesn't need one.

How about a QMimeTypeBuilder, instead?

class QMimeTypeBuilder
{
public:
QMimeTypeBuilder();
void setType(...);
...
void setMagicMarkers(...);
QMimeType result() const { return QMimeType(d); }
private:
QExplicitlySharedDataPointer<QMimeTypeData> d; // Same as QMimeType
};

[Иван Комиссаров]

19.09.2011, в 16:59, Wolf-Michael Bolle написал(а):

> On Monday 19 September 2011 12:39:20 ext Иван Комиссаров wrote:
>
>>>>> In the spirit of this discussion I'd like to point out that I need a
>>>>> way to create QMimeType objects with all their properties set. Can we
>>>>> add constructors to QMimeTypeData and QMimeType like this:
>>>>
>>>> why do you need this done in the constructor? this is, to me, really
>>>> not good API. it's one of my pet peeves.
>>>
>>> I want this class to be immutable. Such a class needs a way to get its
>>> properties initialized. Please explain why that is in your opinion a bad
>>> API.
>>
>> Yes, QMimeType should be immutable; if user need to create type in code, he
>> should use QMutableMimeType.
>>
>> So, as long as user shouldn't use QMimeType for creation of mime types, we
>> can use protected constructor that takes QMimeTypeData instead.
>
> I actually dislike the inheritance. It screams for a virtual destructor when
> the API really doesn't need one.
>
> How about a QMimeTypeBuilder, instead?
>
> class QMimeTypeBuilder
> {
> public:
> QMimeTypeBuilder();
> void setType(...);
> ...
> void setMagicMarkers(...);
> QMimeType result() const { return QMimeType(d); }
> private:
> QExplicitlySharedDataPointer<QMimeTypeData> d; // Same as QMimeType
> };

Yes, that is acceptable for me.

[l***@nokia.com]

On 9/19/11 2:59 PM, "ext Wolf-Michael Bolle"
<wolf-***@nokia.com> wrote:

>On Monday 19 September 2011 12:39:20 ext Иван Комиссаров wrote:
>
>> > > > In the spirit of this discussion I'd like to point out that I
>>need a
>> > > > way to create QMimeType objects with all their properties set.
>>Can we
>> > > > add constructors to QMimeTypeData and QMimeType like this:
>> > >
>> > > why do you need this done in the constructor? this is, to me, really
>> > > not good API. it's one of my pet peeves.
>> >
>> > I want this class to be immutable. Such a class needs a way to get its
>> > properties initialized. Please explain why that is in your opinion a
>>bad
>> > API.
>>
>> Yes, QMimeType should be immutable; if user need to create type in
>>code, he
>> should use QMutableMimeType.
>>
>> So, as long as user shouldn't use QMimeType for creation of mime types,
>>we
>> can use protected constructor that takes QMimeTypeData instead.
>
>I actually dislike the inheritance. It screams for a virtual destructor
>when
>the API really doesn't need one.
>
>How about a QMimeTypeBuilder, instead?
>
>class QMimeTypeBuilder
>{
>public:
> QMimeTypeBuilder();
> void setType(...);
> ...
> void setMagicMarkers(...);
> QMimeType result() const { return QMimeType(d); }
>private:
> QExplicitlySharedDataPointer<QMimeTypeData> d; // Same as QMimeType
>};

If QMimeType is immutable and the only place where QMimeType objects get
created is within the module (ie. users can't create QMimeType objects),
I'd simply go for one constructor that takes a QMimeTypePrivate.

class QMimeType
{
QMimeType(QMimeTypePrivate *dd) : d(dd) { /* maybe d->ref() if it's
copyable */ }
...
};

and QMTPrivate in qmimetype_p.h can be a simple structure:

class QMimeTypePrivate
{
public:
QString type;
QString comment;
....
};

Cheers,
Lars

[Till Oliver Knoll]

Am 19.09.2011 um 12:18 schrieb Wolf-Michael Bolle <wolf-***@nokia.com>:

> On Monday 19 September 2011 12:04:01 ext Robin Burchell wrote:
>
>>> In the spirit of this discussion I'd like to point out that I need a way
>>> to create QMimeType objects with all their properties set. Can we add
>>> constructors to QMimeTypeData and QMimeType like this:
>>
>> why do you need this done in the constructor? this is, to me, really
>> not good API. it's one of my pet peeves.
>
> I want this class to be immutable.

Provide a c'tor which takes another "raw data" object as single parameter or provide your own "factory" method which sets all values as desired and then returns a const instance.


> Such a class needs a way to get its
> properties initialized. Please explain why that is in your opinion a bad API.

Answer answer *a = new Answer("Because", this, "is", "hard", 2, QIODevice::Read, true, true, false, 42);

;)

Cheers, Oliver

[Иван Комиссаров]

Well, i had such constructor, but removed it due to Qt-Coding style:) As far as i know, you, trolls, avoid using constructors with millions of parameters. The argumentation is that nobody remembers what means 7th string in method call.

You can return it for convenience if you want.

Do you work with qmime.git repo? Should i give you access to it?

19.09.2011, в 13:57, Wolf-Michael Bolle написал(а):

On Thursday 15 September 2011 11:45:30 ext Thiago Macieira wrote:
>>> Why can't you think of MIME type editor, e.g. like one in ROX Filer?
>>
>> And the question is whether this is a usecase that should be supported by
>> Qt essentials. I don't think so.
>>
>> Mimetype handling should become part of the basic offering. But only for
>> the common use case of reading them and figuring out themimetype of files
>> and data.
>
> I'm of the same opinion.
>
> Writing Qt functionality that benefits one application in the system seems
> superfluous. We're trying to resolve the common case here.
>
> If editing MIME types turns out to be a common task, then we can revisit.

In the spirit of this discussion I'd like to point out that I need a way to
create QMimeType objects with all their properties set. Can we add
constructors to QMimeTypeData and QMimeType like this:

QMimeTypeData::QMimeTypeData(
const QString &theType,
const QString &theComment,
const LocaleHash &theLocaleComments,
const QStringList &theAliases,
const QString &theGenericIconName,
const QList< QMimeGlobPattern > &theGlobPatterns,
const QStringList &theSubClassOf,
const QString &thePreferredSuffix,
const QStringList &theSuffixes,
const QList< QMimeMagicRuleMatcher > &theMagicMatchers)
: suffixPattern(QLatin1String("^\\*\\.[\\w+]+$")),
, type(theType)
, comment(theComment)
, localeComments(theLocaleComments)
, aliases(theAliases)
, genericIconName(theGenericIconName)
, globPattterns(theGlobPatterns)
, subClassOf(theSubClassOf)
, preferredSuffix(thePreferredSuffix)
, suffixes(theSuffixes)
, magicMatchers(theMagicMatchers)
{
if (!suffixPattern.isValid())
qWarning("MimeTypeData(): invalid suffixPattern");
}

QMimeType::QMimeType(
const QString &theType,
const QString &theComment,
const LocaleHash &theLocaleComments,
const QStringList &theAliases,
const QString &theGenericIconName,
const QList< QMimeGlobPattern > &theGlobPatterns,
const QStringList &theSubClassOf,
const QString &thePreferredSuffix,
const QStringList &theSuffixes,
const QList< QMimeMagicRuleMatcher > &theMagicMatchers)
: d(new QMimeTypeData(...))
{}
_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Wolf-Michael Bolle]

Hi Иван,

On Monday 19 September 2011 12:10:31 ext Иван Комиссаров wrote:

> Do you work with qmime.git repo? Should i give you access to it?

I am documenting the code, that's true. Having write access would of course
make it easier for me.

Sure, if nobody else is working with it at the moment I'd like to get write
access.

Thanks

Michael

[Thiago Macieira]

On Monday, 19 de September de 2011 11:57:51 Wolf-Michael Bolle wrote:
> Can we add
> constructors to QMimeTypeData and QMimeType like this:
>
> QMimeTypeData::QMimeTypeData(
> const QString &theType,
> const QString &theComment,
> const LocaleHash &theLocaleComments,
> const QStringList &theAliases,
> const QString &theGenericIconName,
> const QList< QMimeGlobPattern > &theGlobPatterns,
> const QStringList &theSubClassOf,
> const QString &thePreferredSuffix,
> const QStringList &theSuffixes,
> const QList< QMimeMagicRuleMatcher > &theMagicMatchers)

No.

Remove 70% of the arguments there and it should be mostly ok. The rest should
be setters and getters.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[s***@accenture.com]

> -----Original Message-----
> From: qt5-feedback-bounces+shane.kearns=***@qt.nokia.com
> [mailto:qt5-feedback-bounces+shane.kearns=***@qt.nokia.com]
> On Behalf Of ***@nokia.com
> Sent: Thursday, September 15, 2011 09:34
> To: ***@yandex.ru; ***@kde.org
> Cc: qt5-***@qt.nokia.com
> Subject: Re: [Qt5-feedback] MIME type support in Qt5
>
>
> Mimetype handling should become part of the basic offering. But only
> for
> the common use case of reading them and figuring out themimetype of
> files
> and data.
>
> Cheers,
> Lars
>

So does this module need an API for determining mime type from data?
e.g. something like:

static QMimeType determineMimeType(QIODevice* device, QString fileNameHint);
static QMimeType determineMimeType(QFile file); //convenience wrapper for common case

Given a known filename, the type can be guessed if the extension is unambiguous (e.g. "picture.jpg" is probably "image/jpeg")
Given an unknown filename or ambiguous extension, the type can be guessed by reading & parsing the file header (e.g. a binary file with "JFIF" in the right place in the first 16 bytes is probably "image/jpeg")

There are some edge cases e.g. a file called "image.jpg" that actually contains data of the "image/tiff" type.
Also, the IO device may be unavailable (e.g. you have the filename but no permission to open the file)
Or the file name may be unknown (e.g. you don't have a file, just a data stream from the network)

________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

[Иван Комиссаров]

Do not guess what should happen - it is all mentioned in shared mime info spec and mostly implemented in qmime.
I pass QByteArray to method findByData().
API is almost same as in QtCreator mime (i didn't changed it lot when i refactored code)

> 15.09.2011, в 17:55, <***@accenture.com> написал(а):
>
> So does this module need an API for determining mime type from data?
> e.g. something like:
>
> static QMimeType determineMimeType(QIODevice* device, QString fileNameHint);
> static QMimeType determineMimeType(QFile file); //convenience wrapper for common case
>
> Given a known filename, the type can be guessed if the extension is unambiguous (e.g. "picture.jpg" is probably "image/jpeg")
> Given an unknown filename or ambiguous extension, the type can be guessed by reading & parsing the file header (e.g. a binary file with "JFIF" in the right place in the first 16 bytes is probably "image/jpeg")
>
> There are some edge cases e.g. a file called "image.jpg" that actually contains data of the "image/tiff" type.
> Also, the IO device may be unavailable (e.g. you have the filename but no permission to open the file)
> Or the file name may be unknown (e.g. you don't have a file, just a data stream from the network)
>

[s***@accenture.com]

OK, the qmime module already has a suitable API.
Is a "best match" API that returns the QMimeType with the best match score useful, or should it be left to applications?

> -----Original Message-----
> From: qt5-feedback-bounces+shane.kearns=***@qt.nokia.com
> [mailto:qt5-feedback-bounces+shane.kearns=***@qt.nokia.com]
> On Behalf Of ???? ??????????
> Sent: Thursday, September 15, 2011 15:03
> To: qt5-***@qt.nokia.com
> Subject: Re: [Qt5-feedback] MIME type support in Qt5
>
> Do not guess what should happen - it is all mentioned in shared mime
> info spec and mostly implemented in qmime.
> I pass QByteArray to method findByData().
> API is almost same as in QtCreator mime (i didn't changed it lot when i
> refactored code)
>
> > 15.09.2011, в 17:55, <***@accenture.com> написал(а):
> >
> > So does this module need an API for determining mime type from data?
> > e.g. something like:
> >
> > static QMimeType determineMimeType(QIODevice* device, QString
> fileNameHint);
> > static QMimeType determineMimeType(QFile file); //convenience wrapper
> for common case
> >
> > Given a known filename, the type can be guessed if the extension is
> unambiguous (e.g. "picture.jpg" is probably "image/jpeg")
> > Given an unknown filename or ambiguous extension, the type can be
> guessed by reading & parsing the file header (e.g. a binary file with
> "JFIF" in the right place in the first 16 bytes is probably
> "image/jpeg")
> >
> > There are some edge cases e.g. a file called "image.jpg" that
> actually contains data of the "image/tiff" type.
> > Also, the IO device may be unavailable (e.g. you have the filename
> but no permission to open the file)
> > Or the file name may be unknown (e.g. you don't have a file, just a
> data stream from the network)
> >
> _______________________________________________
> Qt5-feedback mailing list
> Qt5-***@qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

[s***@accenture.com]

Sorry, QMimeDatabase::findByXXXX already implements what I was asking about - please ignore the previous reply.
> -----Original Message-----
> From: qt5-feedback-bounces+shane.kearns=***@qt.nokia.com
> [mailto:qt5-feedback-bounces+shane.kearns=***@qt.nokia.com]
> On Behalf Of ???? ??????????
> Sent: Thursday, September 15, 2011 15:03
> To: qt5-***@qt.nokia.com
> Subject: Re: [Qt5-feedback] MIME type support in Qt5
>
> Do not guess what should happen - it is all mentioned in shared mime
> info spec and mostly implemented in qmime.
> I pass QByteArray to method findByData().
> API is almost same as in QtCreator mime (i didn't changed it lot when i
> refactored code)
>

________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

[Wolf-Michael Bolle]

On Thursday 15 September 2011 09:50:02 ext David Faure wrote:

> As Wolf-Michael noted, the API for creating mimetypes doesn't really belong
> in there; that's far too system-dependent, and far too "rare" compared to
> queries.

If there are no objections then I will go ahead and remove
- QMimeTypeRegistry::insertMimeType()
- QMimeTypeRegistry::insertServiceAction()
- QMimeTypeRegistry::iregisterApplication()
- QMimeTypeRegistry::iunregisterApplication()

> And the implementation should parse the files generated by update-mime-
> database, which is much faster -- and I can provide the code for that,
> having already written all that code for KDE.

That sound to me like the starting point for the Linux backend.

> So, from qmime.git, neither the API nor the implementation make much sense
> to me, only the unit tests are reusable. Well, the API can still provide
> input for qtaddonmimetype.git of course.

I will see if I can integrate the unit tests into mine.

> On the other hand I'm not sure that querying the association with
> applications and the open/view/edit distinction belongs there, it doesn't
> seem very cross- platform -- but that's a separate discussion.

Similar to KDE, I wanted to express the difference between open/view and edit,
and also leave room for potential other uses.

[David Faure]

On Thursday 15 September 2011 10:35:20 Wolf-Michael Bolle wrote:
> > And the implementation should parse the files generated by update-mime-
> > database, which is much faster -- and I can provide the code for that,
> > having already written all that code for KDE.
>
> That sound to me like the starting point for the Linux backend.

Is the native mimetype support on Mac and Windows good enough, or should Qt
use shared-mime-info on these platforms too, like KDE currently does?

> > On the other hand I'm not sure that querying the association with
> > applications and the open/view/edit distinction belongs there, it
> > doesn't
> > seem very cross- platform -- but that's a separate discussion.
>
> Similar to KDE, I wanted to express the difference between open/view and
> edit, and also leave room for potential other uses.

KDE doesn't do that, actually :-)

The desktop entry standard says: in the .desktop file of the application, list
the mimetypes it supports. This doesn't leave room for open/edit distinctions.

We use "service menus" (a different kind of .desktop file, filemanager-
specific) to complement that and offer additional context-menu actions.

But I think determining mimetypes is a big enough job in itself, and the
relation to applications shouldn't be rushed in with it. We might even have to
get more freedesktop.org standards about this first, the current solution for
determining the default application preference order is different between KDE
and gnome, as well as the extra stuff like open/edit and service menus.

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[l***@nokia.com]

On 9/15/11 10:55 AM, "ext David Faure" <***@kde.org> wrote:

>On Thursday 15 September 2011 10:35:20 Wolf-Michael Bolle wrote:
>> > And the implementation should parse the files generated by
>>update-mime-
>> > database, which is much faster -- and I can provide the code for that,
>> > having already written all that code for KDE.
>>
>> That sound to me like the starting point for the Linux backend.
>
>Is the native mimetype support on Mac and Windows good enough, or should
>Qt
>use shared-mime-info on these platforms too, like KDE currently does?

Not sure, but I'd go for using shared-mime-info in a first implementation
(ie use the Linux code). But having the backend separated so that we can
easily exchange it against a more native implementation is probably a good
thing.

Cheers,
Lars

>
>> > On the other hand I'm not sure that querying the association with
>> > applications and the open/view/edit distinction belongs there, it
>> > doesn't
>> > seem very cross- platform -- but that's a separate discussion.
>>
>> Similar to KDE, I wanted to express the difference between open/view and
>> edit, and also leave room for potential other uses.
>
>KDE doesn't do that, actually :-)
>
>The desktop entry standard says: in the .desktop file of the application,
>list
>the mimetypes it supports. This doesn't leave room for open/edit
>distinctions.
>
>We use "service menus" (a different kind of .desktop file, filemanager-
>specific) to complement that and offer additional context-menu actions.
>
>But I think determining mimetypes is a big enough job in itself, and the
>relation to applications shouldn't be rushed in with it. We might even
>have to
>get more freedesktop.org standards about this first, the current solution
>for
>determining the default application preference order is different between
>KDE
>and gnome, as well as the extra stuff like open/edit and service menus.
>
>--
>David Faure, ***@kde.org, http://www.davidfaure.fr
>Sponsored by Nokia to work on KDE, incl. Konqueror
>(http://www.konqueror.org).
>
>_______________________________________________
>Qt5-feedback mailing list
>Qt5-***@qt.nokia.com
>http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Wolf-Michael Bolle]

On Thursday 15 September 2011 10:55:41 ext David Faure wrote:

> > > On the other hand I'm not sure that querying the association with
> > > applications and the open/view/edit distinction belongs there, it
> > > doesn't
> > > seem very cross- platform -- but that's a separate discussion.
> >
> > Similar to KDE, I wanted to express the difference between open/view and
> > edit, and also leave room for potential other uses.
>
> KDE doesn't do that, actually :-)

I was referring to the second parameter of KMimeTypeTrader::query() which is
genericServiceType. It is either 'KParts/ReadOnlyPart' or 'Application'. The
KEditFileType utility exposes that as 'Embedding' and 'General' tabs. I
creatively translated that into open/view and edit.

> The desktop entry standard says: in the .desktop file of the application,
> list the mimetypes it supports. This doesn't leave room for open/edit
> distinctions.
>
> We use "service menus" (a different kind of .desktop file, filemanager-
> specific) to complement that and offer additional context-menu actions.

Thanks for that input. I see that now in my
/usr/share/kde4/services/katepart.desktop.

> But I think determining mimetypes is a big enough job in itself, and the
> relation to applications shouldn't be rushed in with it. We might even have
> to get more freedesktop.org standards about this first, the current
> solution for determining the default application preference order is
> different between KDE and gnome, as well as the extra stuff like open/edit
> and service menus.

I see where you are going. We'll need to provide libQtCore.so for either
Gnome, KDE or whatever else, then. Mark Shuttleworth might appreciate that
though.

To make the discussion about an API easier I could separate the applications
out into a seperate class QMimeTypeHandling. What do you think?

[David Faure]

On Thursday 15 September 2011 13:52:49 Wolf-Michael Bolle wrote:
> On Thursday 15 September 2011 10:55:41 ext David Faure wrote:
> > > > On the other hand I'm not sure that querying the association
> > > > with
> > > > applications and the open/view/edit distinction belongs there,
> > > > it
> > > > doesn't
> > > > seem very cross- platform -- but that's a separate discussion.
> > >
> > > Similar to KDE, I wanted to express the difference between open/view
> > > and edit, and also leave room for potential other uses.
> >
> > KDE doesn't do that, actually :-)
>
> I was referring to the second parameter of KMimeTypeTrader::query() which is
> genericServiceType. It is either 'KParts/ReadOnlyPart' or 'Application'.
> The KEditFileType utility exposes that as 'Embedding' and 'General' tabs. I
> creatively translated that into open/view and edit.

That's very different.
A part is a *component* used by e.g. konqueror and other programs.
But when the user selects "view" in an hypothetical file manager that allows
to choose between "view" and "edit", he expects an application to be started.
A part alone isn't an executable, it can't be started.

But the association between mimetypes and parts is IMHO not something that Qt
should take care of - these "parts" are very specific to one platform, there
is no cross-platform component technology ("QLibrary and a factory for a
QWidget" would only be a very rough approximation).

> > The desktop entry standard says: in the .desktop file of the
> > application,
> > list the mimetypes it supports. This doesn't leave room for open/edit
> > distinctions.
> >
> > We use "service menus" (a different kind of .desktop file, filemanager-
> > specific) to complement that and offer additional context-menu actions.
>
> Thanks for that input. I see that now in my
> /usr/share/kde4/services/katepart.desktop.

That's a part, not a service menu :-)
I see the confusion (coming from the "services" directory).

A .desktop file can define:
* an application (Type=Application) (freedesktop.org standard)
* a plugin (Type=Service) (KDE-specific)
The ServiceTypes entry defines the kind of plugin:
- KParts/ReadOnlyPart for parts (viewer components).
- KFileItemAction/Plugin for contextual menu actions
- anything else goes here, application-specific plugins, framework
plugins.

> > But I think determining mimetypes is a big enough job in itself, and the
> > relation to applications shouldn't be rushed in with it. We might even
> > have to get more freedesktop.org standards about this first, the
> > current solution for determining the default application preference
> > order is different between KDE and gnome, as well as the extra stuff
> > like open/edit and service menus.
>
> I see where you are going. We'll need to provide libQtCore.so for either
> Gnome, KDE or whatever else, then.

Well, I thought you were planning on doing this with plugins instead...

> To make the discussion about an API easier I could separate the applications
> out into a seperate class QMimeTypeHandling. What do you think?

Separating out the application stuff is most definitely needed.
"Handling" isn't a great name though.

The real question is whether this should be in Qt. Up to now I don't see a way
to implement "querying 1000 .desktop files for a given mimetype" without some
kind of cache, and an on-disk cache (ksycoca) is much preferrable to an in-
memory cache (which would mean that each and every application has to parse
all these files). So either Qt gets an equivalent of KSycoca or
KSharedDataCache, or this isn't something that Qt should implement.
The kservice framework that will soon be available as part of the "kde
frameworks" modularization effort could be used instead. All this on top of
QMimeType of course.
The most common case of "open this url in the associated application" being
already covered in QDesktopServices (by calling platform-specific
executables), I wonder if there is a use case in Qt for "give me all the
applications associated with this mimetype"?

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Thiago Macieira]

On Thursday, 15 de September de 2011 17.49.11, David Faure wrote:
> The most common case of "open this url in the associated application" being
> already covered in QDesktopServices (by calling platform-specific
> executables), I wonder if there is a use case in Qt for "give me all the
> applications associated with this mimetype"?

Can I answer "no"?

Listing all applications for a given MIME type is useful for the file
associations editor. I see little use for a generic application, other than
allowing the user to choose a non-default application (like KDE's
Open/Save/Cancel dialog being extended with Open With).

However, before we could list the applications for a MIME type, we need to be
able to list applications in the first place, launch them and maybe even
control them. This might be an interesting feature, but it is definitely not
something we should rush now.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[David Faure]

On Friday 16 September 2011 09:22:49 Thiago Macieira wrote:
> On Thursday, 15 de September de 2011 17.49.11, David Faure wrote:
> > The most common case of "open this url in the associated application"
> > being already covered in QDesktopServices (by calling platform-specific
> > executables), I wonder if there is a use case in Qt for "give me all
> > the applications associated with this mimetype"?
>
> Can I answer "no"?
>
> Listing all applications for a given MIME type is useful for the file
> associations editor.

To be fair, it's also useful for file managers (RMB menu).

> I see little use for a generic application, other than
> allowing the user to choose a non-default application (like KDE's
> Open/Save/Cancel dialog being extended with Open With).

Right: and web browsers, then.

> However, before we could list the applications for a MIME type, we need to
> be able to list applications in the first place, launch them and maybe even
> control them. This might be an interesting feature, but it is definitely
> not something we should rush now.

I completely agree. One step at a time.

Wolf-Michael: is there a chance that if I implement shared-mime-info in
qmime.git, this could be the code that goes into Qt, and qtaddonmimetype.git
would be discarded? In that case I'll do that. But I definitely don't want to
work on something that will be discarded because the other repo
(qtaddonmimetype.git) "comes from nokia so it's the one that will go into Qt".

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Diego Iastrubni]

Č

On Friday, September 16, 2011, David Faure <***@kde.org> wrote:
> On Friday 16 September 2011 09:22:49 Thiago Macieira wrote:
>> On Thursday, 15 de September de 2011 17.49.11, David Faure wrote:
>> > The most common case of "open this url in the associated application"
>> > being already covered in QDesktopServices (by calling platform-specific
>> > executables), I wonder if there is a use case in Qt for "give me all
>> > the applications associated with this mimetype"?
>>
>> Can I answer "no"?
>>
>> Listing all applications for a given MIME type is useful for the file
>> associations editor.
>
> To be fair, it's also useful for file managers (RMB menu).
>
>> I see little use for a generic application, other than
>> allowing the user to choose a non-default application (like KDE's
>> Open/Save/Cancel dialog being extended with Open With).
>
> Right: and web browsers, then.
>
>> However, before we could list the applications for a MIME type, we need
to
>> be able to list applications in the first place, launch them and maybe
even
>> control them. This might be an interesting feature, but it is definitely
>> not something we should rush now.
>
> I completely agree. One step at a time.
>
> Wolf-Michael: is there a chance that if I implement shared-mime-info in
> qmime.git, this could be the code that goes into Qt, and
qtaddonmimetype.git
> would be discarded? In that case I'll do that. But I definitely don't want
to
> work on something that will be discarded because the other repo
> (qtaddonmimetype.git) "comes from nokia so it's the one that will go into
Qt".
>
> --
> David Faure, ***@kde.org, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. Konqueror (
http://www.konqueror.org).
>
> _______________________________________________
> Qt5-feedback mailing list
> Qt5-***@qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
>

[Wolf-Michael Bolle]

On Friday 16 September 2011 10:09:44 ext David Faure wrote:

> Wolf-Michael: is there a chance that if I implement shared-mime-info in
> qmime.git, this could be the code that goes into Qt, and
> qtaddonmimetype.git would be discarded? In that case I'll do that. But I
> definitely don't want to work on something that will be discarded because
> the other repo
> (qtaddonmimetype.git) "comes from nokia so it's the one that will go into
> Qt".

I really liked Lars' suggestion about separating the code based on update-
mime-database and shared-mime-info into a backend so that from day 1
individual platforms can have their potentially very different implementations
either because the platform already has sufficient support or the platform needs
something smaller.

[Wolf-Michael Bolle]

On Thursday 15 September 2011 17:49:11 ext David Faure wrote:
> The real question is whether this should be in Qt. Up to now I don't see a
> way to implement "querying 1000 .desktop files for a given mimetype"
> without some kind of cache, and an on-disk cache (ksycoca) is much
> preferrable to an in- memory cache (which would mean that each and every
> application has to parse all these files). So either Qt gets an equivalent
> of KSycoca or
> KSharedDataCache, or this isn't something that Qt should implement.
> The kservice framework that will soon be available as part of the "kde
> frameworks" modularization effort could be used instead. All this on top of
> QMimeType of course.

Why not leave this problem to the actual backend? KDE can implement a solution
based on KSycoca or KSharedDataCache. Other platforms like Windows will aready
have their own storage that the backend can tap into.

[Иван Комиссаров]

As far as i remember, i asked David to use kde code to read mime types… Dunno why it is still not in repo:)

About editing mimetypes - as far as QtCreator use editing it is good not to duplicate 2 databases - one 1 in Qt (read-only), other in Qt creator (with ability to add custom mime types).

> " it exposes too much internals of the spec, such as the various fields for magic (content-based) matching"

It is just 2 (two) methods in QMimeType… "too much", yes… Besides, they can be moved to QMutableMimeType (class for constructing new mime types) and most users won't see this details. Also, as far i have two classes, no problems for supporting editable mime types from API point of view - creating new mime types is already separated from reading/searching them.

In windows and mac native databases differ from shared mime info database - in win you can't search for mime type by content, only by extension; as for mac, names for mime type differs from shared mime info spec - for example "mkv" is something like "movie", not "video/x-matroska". As you support shared mime info names in QMimeData, you have to map mac mime names into shared mime info names.

I don't see any reasons to throw out mostly working code, except for searching algorithm, which can be replaced by kde one (10 minutes of work) and reading database, which is not exist in both implementations.

So, we also have open question about storing mime types under mac/win - user won't copy million text/xml files to deploy his program.

[David Faure]

On Thursday 15 September 2011 14:22:26 Иван Комиссаров wrote:
> As far as i remember, i asked David to use kde code to read mime types…
> Dunno why it is still not in repo:)

Well the very first step was to get QStandardPaths into Qt, so that we can
locate the files generated by shared-mime-info on disk.

It took a long time (due to 3 platforms, due to review process, and due to the
refactor branch being merged into master), but it's finally ready.
Not merged yet, though.

Also, my first commits to qmime.git were moved to a branch and never merged
in, I don't take that as a sign of fruitful collaboration...

> About editing mimetypes - as far as QtCreator use editing it is good not to
> duplicate 2 databases - one 1 in Qt (read-only), other in Qt creator (with
> ability to add custom mime types).

IMHO the editing of mimetypes in Qt Creator should be removed.
I asked danimo and he was very surprised to hear that such a thing existed.
But if Qt creator should really allow editing of mimetypes, then it should
edit the system mimetypes (I have code for that too...). The concept of per-
application mimetypes breaks the concept of shared-mime-info.

> > " it exposes too much internals of the spec, such as the various
> > fields for magic (content-based) matching"
> It is just 2 (two) methods in QMimeType… "too much", yes… Besides, they can
> be moved to QMutableMimeType (class for constructing new mime types) and
> most users won't see this details.

Moving to another public class doesn't change the issue: if it's in the API,
it can't be changed later.

Same thing with the glob weights -- this shouldn't appear in the API, because
that makes it impossible to change if the spec changes. In fact this wasn't in
the spec initially... these things -can- change.

> In windows and mac native databases differ from shared mime info database -
> in win you can't search for mime type by content, only by extension; as for
> mac, names for mime type differs from shared mime info spec - for example
> "mkv" is something like "movie", not "video/x-matroska". As you support
> shared mime info names in QMimeData, you have to map mac mime names into
> shared mime info names.
>
> I don't see any reasons to throw out mostly working code, except for
> searching algorithm, which can be replaced by kde one (10 minutes of work)
> and reading database, which is not exist in both implementations.

Well, apart from the "too many details about the spec" the API in qmime.git is
mostly good, I like QMimeDatabase.

But the code is mostly about parsing XML files...

Well, anyway. I'll let you and Wolf-Michael debate about which API is chosen
for inclusion into Qt, and only then I'll implement the shared-mime-info
backend into the chosen repository. Better not do it twice.

> So, we also have open question about storing mime types under mac/win - user
> won't copy million text/xml files to deploy his program.

There is just one xml file to copy. The rest is generated by update-mime-
database. But I can see that given Windows's non-existing dependency handling,
this might not be a great solution ;)

An alternative could be that Qt ships the files generated from
freedesktop.org.xml, and [on any platform] if shared-mime-info is installed we
don't use those.

Note however that without shared-mime-info's update-mime-database program
there is no chance of defining new mimetypes (which is fine IMHO, it's not
needed by typical Qt apps).

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Иван Комиссаров]

15.09.2011, â 21:12, David Faure íàïèñàë(à):

> Well the very first step was to get QStandardPaths into Qt, so that we can
> locate the files generated by shared-mime-info on disk.
>
> It took a long time (due to 3 platforms, due to review process, and due to the
> refactor branch being merged into master), but it's finally ready.
> Not merged yet, though.

Ah, i see… Is that means that you want to store same text files (generated by update-mime-database command) in windows/mac too?
>
> Also, my first commits to qmime.git were moved to a branch and never merged
> in, I don't take that as a sign of fruitful collaboration...

I move them to separate branch because when i worked with Konstantin, we discussed everything before writing code. If we don't discuss first, we need code review instead - that's why i created branches for you and me.

>
> IMHO the editing of mimetypes in Qt Creator should be removed.
> I asked danimo and he was very surprised to hear that such a thing existed.
> But if Qt creator should really allow editing of mimetypes, then it should
> edit the system mimetypes (I have code for that too...). The concept of per-
> application mimetypes breaks the concept of shared-mime-info.

Sometimes (quite rare though) application really need it's own format of files for its inner purposes. That's why creating of custom mime types can be useful sometimes.

>
> Moving to another public class doesn't change the issue: if it's in the API,
> it can't be changed later.
>
> Same thing with the glob weights -- this shouldn't appear in the API, because
> that makes it impossible to change if the spec changes. In fact this wasn't in
> the spec initially... these things -can- change.

I don't believe they (freedesktop.org) will change spec - they have big risk to broke something:)

> There is just one xml file to copy. The rest is generated by update-mime-
> database. But I can see that given Windows's non-existing dependency handling,
> this might not be a great solution ;)

Is update-mime-database ported to windows? Where does it store files?

> An alternative could be that Qt ships the files generated from
> freedesktop.org.xml, and [on any platform] if shared-mime-info is installed we
> don't use those.

Is it really best way to deploy million of files on windows/mac? Maybe it is better to use one huge database file? Shared-mime-info describes one binary format for database, but i does not contains strings (descriptions) for mime types. Maybe they can change spec to add these strings? (or ids of mime types to load strings from .qm files, for example)

Btw, i know that my english skills is very bad, so feel free to ask if something is not clear:)

[David Faure]

On Thursday 15 September 2011 23:07:55 Иван Комиссаров wrote:
> 15.09.2011, в 21:12, David Faure написал(а):
> > Well the very first step was to get QStandardPaths into Qt, so that we
> > can locate the files generated by shared-mime-info on disk.
> >
> > It took a long time (due to 3 platforms, due to review process, and due
> > to the refactor branch being merged into master), but it's finally
> > ready. Not merged yet, though.
>
> Ah, i see… Is that means that you want to store same text files (generated
> by update-mime-database command) in windows/mac too?

Store... or generate.

We could provide update-mime-database, it's a very small utility.

> > Also, my first commits to qmime.git were moved to a branch and never
> > merged in, I don't take that as a sign of fruitful collaboration...
>
> I move them to separate branch because when i worked with Konstantin, we
> discussed everything before writing code. If we don't discuss first, we
> need code review instead - that's why i created branches for you and me.

Sure, but the review never happened and the changes were never merged in.

But OK, they were just small steps in the API cleanups, not a complete
"proposal". Catch 22.

> > IMHO the editing of mimetypes in Qt Creator should be removed.
> > I asked danimo and he was very surprised to hear that such a thing
> > existed. But if Qt creator should really allow editing of mimetypes,
> > then it should edit the system mimetypes (I have code for that too...).
> > The concept of per- application mimetypes breaks the concept of
> > shared-mime-info.
>
> Sometimes (quite rare though) application really need it's own format of
> files for its inner purposes. That's why creating of custom mime types can
> be useful sometimes.

Yes, and this can be done by installing an xml file, no api needed.

> > Moving to another public class doesn't change the issue: if it's in the
> > API, it can't be changed later.
> >
> > Same thing with the glob weights -- this shouldn't appear in the API,
> > because that makes it impossible to change if the spec changes. In fact
> > this wasn't in the spec initially... these things -can- change.
>
> I don't believe they (freedesktop.org) will change spec - they have big risk
> to broke something:)

That is definitely not true. New features can always be added, and they have
been, in the (not so long) past.

Initially the spec had no glob weights, for instance.
The earlier version (in kde time) had no range support for magic matching.
Who knows what features might come in, in the future.

And especially if you want to have more backends than shared-mime-info, then
having so many details in the API just won't work. Windows doesn't even have
content matching, I hear.

... But actually that's why I think we would be in a much better position by
using shared-mime-info everywhere. Just yesterday I had the example of someone
on linux sending a PDF file by mail to someone on Windows, and the file had no
extension (openoffice checkbox in file dialog was unchecked for some reason).
As a result, the file was opened in notepad by Windows.
If that application was using shared-mime-info, the content matching would
have immediately detected that it was a PDF file.

And by using shared-mime-info everywhere, we solve the problem of "how does an
app define new mimetypes" : with an xml file. And with the same features
everywhere, as a result.

Think about the typical case of
QMimeType mime = QMimeDatabase::findByName(fileName);
if (mime.inherits("application/xml")) {
// then use an xml viewer, or whatever.
}
If the mimetype name on Windows or mac is not application/xml but something
else, then the application needs to know about that and check for all these
names? That's very fragile and not really what you expect from cross-platform
framework. The advantage of using shared-mime-info everywhere is not only
"same features everywhere", but also and mainly "same mimetype names
everywhere".

The main issue is how to use the mime-apps associations for the existing
Windows or Mac apps, this is where Qt itself might have to do some mapping --
but that's for the separate discussion of mime-apps associations.

> > There is just one xml file to copy. The rest is generated by
> > update-mime-
> > database. But I can see that given Windows's non-existing dependency
> > handling, this might not be a great solution ;)
>
> Is update-mime-database ported to windows? Where does it store files?

Yes, KDE uses it on Windows too.
It stores files in XDG_DATA_DIRS/mime I presume. I'll double-check with the
KDE-on-windows guys. In any case we can set things up so that it uses
QStandardPaths::GenericDataLocation + "/mime" everywhere, which is on Windows
CSIDL_COMMON_APPDATA + "/mime" and CSIDL_LOCAL_APPDATA + "/mime".

> > An alternative could be that Qt ships the files generated from
> > freedesktop.org.xml, and [on any platform] if shared-mime-info is
> > installed we don't use those.
>
> Is it really best way to deploy million of files on windows/mac? Maybe it is
> better to use one huge database file?

With a single file, other apps cannot install their own description files.
This is a very practical need, look at how many apps install additional
mimetype definitions here on linux:

-Asterix.site- dfaure 10:22 /k>ls -l /usr/share/mime/packages
total 1684
-rw-r--r-- 1 root root 1285 Jan 22 2011 akonadi-mime.xml
-rw-r--r-- 1 root root 1264 Feb 1 2011 bluedevil-mime.xml
-rw-r--r-- 1 root root 292 Aug 19 19:58 firefox.xml
-rw-r--r-- 1 root root 1615319 Feb 19 2011 freedesktop.org.xml
-rw-r--r-- 1 root root 749 Jan 18 2011 kdepimlibs-mime.xml
-rw-r--r-- 1 root root 875 Jan 27 2011 kdepim-mime.xml
-rw-r--r-- 1 root root 14314 Jan 19 2011 kde.xml
-rw-r--r-- 1 root root 285 Jan 19 2011 lancelotpart-mime.xml
-rw-r--r-- 1 root root 18361 Jan 19 2011 network.xml
-rw-r--r-- 1 root root 8821 Feb 22 2011 openoffice.xml
-rw-r--r-- 1 root root 2971 May 20 17:37 packagekit-catalog.xml
-rw-r--r-- 1 root root 3428 May 20 17:37 packagekit-package-list.xml
-rw-r--r-- 1 root root 3345 May 20 17:37 packagekit-servicepack.xml
-rw-r--r-- 1 root root 1857 Jul 19 16:19 vmware-player.xml
-rw-r--r-- 1 root root 283 May 18 21:33 xine-ui.xml
-rw-r--r-- 1 root root 408 Jan 15 2011 x-k3b.xml
-rw-r--r-- 1 root root 225 Jun 19 2008 x-sysinfo.xml
-rw-r--r-- 1 root root 494 Nov 10 2009 yast2-metapackage-handler-
mimetypes.xml

> Shared-mime-info describes one binary
> format for database, but i does not contains strings (descriptions) for
> mime types.

Yes, that is an option I haven't really investigated yet. It should be faster,
but indeed it doesn't solve the whole issue. In order to get something earlier
I have the feeling we should start with the existing code, and later look into
binary parsing. But no strong feelings there.

> Maybe they can change spec to add these strings?

I don't think so. It would bloat the size of the binary file, thus making its
parsing slower (think about translations -> huge amounts of data overall,
compared to the current size). And the mimetype descriptions is something that
is very rarely needed. This is why my code parses them (from the standalone
xml files) only on demand, in most cases the apps don't care for that, they
just want to get the mimetype of a file and check if that mimetype is one that
they support (possibly in order to use the right plugin, etc.).

> (or ids of mime types to load strings from .qm files, for example)

Well the id could be the mimetype name, no? Or does it have to be numerical?

> Btw, i know that my english skills is very bad, so feel free to ask if
> something is not clear:)

Your english is perfectly fine, don't worry.

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Иван Комиссаров]

David,

I agree with most arguments, but i have some remarks. Did you though about use case of "portable" application on win (single .exe) and bundles on Mac Os X? How will they install mime types and where? For example, Qt Creator has no installer on OS X and it can't copy xml files to proper location and call update-mime-database.

Only thing can be done is to put xml files into bundle, like current implementation does. Next, we have to put these xml files manually/using script during building app bundle. Much easier to put one huge database near app.

I agree that use-case of "global" mimes types - shared by all applications is quite useful - for example for win-KDE developers.

>From the other side, not so many people use qt-based applications under win/mac and we can't afford to install mime files into filesystem, they should be placed inside bundle.

So we have 2 use-cases - "global" and "local" mime types. I agree, global mime types should be implemented using update-mime-info, but what about local? We can store text files, plain xml files (foo:)), single binary file. I think in perspective we have to support all 3 ways.

Next, about in-memory mime types. How can we have to support plugin architecture? If i developed plugin for QtCreator that handles some specific mime type - "image/blp", for example. In my opinion, user should install single *.dll as a plugin and he shouldn't manually copy xml description for image/blp with it to let Creator know how to open this format. The workaround here is to use 3rd location and store xml/plain text files in Qt resources (and store file within .dll), but i really dislike this way, better in-memory mime types.

[Иван Комиссаров]

Ah, forgot to say - in my opinion we should not support native mime types at all - better to have one implemetation that works same way everywhere, than to have problems with integration/API changes (in mac it really becomes problem sometimes)

[Wolf-Michael Bolle]

> > So, we also have open question about storing mime types under mac/win -
> > user won't copy million text/xml files to deploy his program.
>
> There is just one xml file to copy. The rest is generated by update-mime-
> database. But I can see that given Windows's non-existing dependency
> handling, this might not be a great solution ;)
>
> An alternative could be that Qt ships the files generated from
> freedesktop.org.xml, and [on any platform] if shared-mime-info is installed
> we don't use those.

I have several questions about that approach. How well does that scale with
smaller devices? What is the footprint of these XML files? What are the
dependencies of update-mime-database and shared-mime-info?

[Wolf-Michael Bolle]

On Thursday 15 September 2011 19:12:56 ext David Faure wrote:

> Well, apart from the "too many details about the spec" the API in qmime.git
> is mostly good, I like QMimeDatabase.
>
> But the code is mostly about parsing XML files...
>
> Well, anyway. I'll let you and Wolf-Michael debate about which API is
> chosen for inclusion into Qt, and only then I'll implement the
> shared-mime-info backend into the chosen repository. Better not do it
> twice.

I took a look at QMimeDatabase, and the first thing that I stumbled over is the
addMimeTypes() method. It creates a dependency on freedesktop.org.xml or
some edited version of it. In my opinion, this will not work on every platform
out there (particulary the smaller ones). The test cases then seem to use the
findByName(), findByData() and findByFile() methods. They look
straightforward to me. The code about user-modified MIME types I don't find
really necessary in the API. Also, can we leave all mutable methods out of the
interface, and let the individual platform deal with the question on how the
data gets into that database? That would match the discussion we had about my
proposal, too.

[David Faure]

On Tuesday 20 September 2011 16:33:37 Wolf-Michael Bolle wrote:
> On Thursday 15 September 2011 19:12:56 ext David Faure wrote:
> > Well, apart from the "too many details about the spec" the API in
> > qmime.git is mostly good, I like QMimeDatabase.
> >
> > But the code is mostly about parsing XML files...
> >
> > Well, anyway. I'll let you and Wolf-Michael debate about which API is
> > chosen for inclusion into Qt, and only then I'll implement the
> > shared-mime-info backend into the chosen repository. Better not do it
> > twice.
>
> I took a look at QMimeDatabase, and the first thing that I stumbled over is
> the addMimeTypes() method. It creates a dependency on freedesktop.org.xml
> or some edited version of it. In my opinion, this will not work on every
> platform out there (particulary the smaller ones). The test cases then seem
> to use the findByName(), findByData() and findByFile() methods. They look
> straightforward to me. The code about user-modified MIME types I don't find
> really necessary in the API. Also, can we leave all mutable methods out of
> the interface, and let the individual platform deal with the question on
> how the data gets into that database? That would match the discussion we
> had about my proposal, too.

I completely agree.

BTW I'm working on fixing the tests in shared-mime-info itself, because
xdgmime is missing a few features.

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Иван Комиссаров]

Why should individual platforms handle adding mime types, if there are only 3 ways to add them - from xml (1 or many), from text files, from binary database?

21.09.2011, в 10:27, David Faure написал(а):

On Tuesday 20 September 2011 16:33:37 Wolf-Michael Bolle wrote:
> On Thursday 15 September 2011 19:12:56 ext David Faure wrote:
>> Well, apart from the "too many details about the spec" the API in
>> qmime.git is mostly good, I like QMimeDatabase.
>>
>> But the code is mostly about parsing XML files...
>>
>> Well, anyway. I'll let you and Wolf-Michael debate about which API is
>> chosen for inclusion into Qt, and only then I'll implement the
>> shared-mime-info backend into the chosen repository. Better not do it
>> twice.
>
> I took a look at QMimeDatabase, and the first thing that I stumbled over is
> the addMimeTypes() method. It creates a dependency on freedesktop.org.xml
> or some edited version of it. In my opinion, this will not work on every
> platform out there (particulary the smaller ones). The test cases then seem
> to use the findByName(), findByData() and findByFile() methods. They look
> straightforward to me. The code about user-modified MIME types I don't find
> really necessary in the API. Also, can we leave all mutable methods out of
> the interface, and let the individual platform deal with the question on
> how the data gets into that database? That would match the discussion we
> had about my proposal, too.

I completely agree.

BTW I'm working on fixing the tests in shared-mime-info itself, because
xdgmime is missing a few features.

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Wolf-Michael Bolle]

On Wednesday 21 September 2011 11:13:31 ext Иван Комиссаров wrote:

> > > I took a look at QMimeDatabase, and the first thing that I stumbled over
> > > is the addMimeTypes() method. It creates a dependency on
> > > freedesktop.org.xml or some edited version of it. In my opinion, this
> > > will not work on every platform out there (particulary the smaller
> > > ones). The test cases then seem to use the findByName(), findByData()
> > > and findByFile() methods. They look straightforward to me. The code
> > > about user-modified MIME types I don't find really necessary in the API.
> > > Also, can we leave all mutable methods out of the interface, and let the
> > > individual platform deal with the question on how the data gets into
> > > that database? That would match the discussion we had about my proposal,
> > > too.
> >
> > I completely agree.
>
> Why should individual platforms handle adding mime types, if there are only
> 3 ways to add them - from xml (1 or many), from text files, from binary
> database?

I don't like the idea of imposing a database seperate from the one the
individual platform already has. Also, I don't believe that on mobile
platforms such as Symbian it is such a good idea to use up valueable flash
memory.

[Thiago Macieira]

On Wednesday, 21 de September de 2011 14.18.49, Wolf-Michael Bolle wrote:
> I don't like the idea of imposing a database seperate from the one the
> individual platform already has. Also, I don't believe that on mobile
> platforms such as Symbian it is such a good idea to use up valueable flash
> memory.

While Symbian is not a target anymore, there are plenty of embedded platforms
with little flash memory available.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Diego Iastrubni]

On Wed, Sep 21, 2011 at 4:22 PM, Thiago Macieira <***@kde.org> wrote:

> On Wednesday, 21 de September de 2011 14.18.49, Wolf-Michael Bolle wrote:
> > I don't like the idea of imposing a database seperate from the one the
> > individual platform already has. Also, I don't believe that on mobile
> > platforms such as Symbian it is such a good idea to use up valueable
> flash
> > memory.
>
> While Symbian is not a target anymore, there are plenty of embedded
> platforms
> with little flash memory available.
>
> Wait... Symbian is off? What about the next billion devices? Sorry for the
tone (and Thiago, this is not directed to you, nor any of the
Qt/Trolltech/QtSoftware team), but I ask: this promise did not last a
year... Meego (or whatever it's called now) is no longer a player in this
game... so, why are we investing on this thing... why the huge redesign for
mobile if this is not a "real" target...?

Reminder:
http://conversations.nokia.com/2011/02/11/mobile-phones-the-next-billion/

[Thiago Macieira]

On Wednesday, 21 de September de 2011, às 16.30.13, you wrote:
> > While Symbian is not a target anymore, there are plenty of embedded
> > platforms
> > with little flash memory available.
>
> Wait... Symbian is off?

Yes.

> What about the next billion devices?

I guess they won't run Symbian.

> Sorry for the tone (and Thiago, this is not directed to you, nor any of the
> Qt/Trolltech/QtSoftware team), but I ask: this promise did not last a
> year... Meego (or whatever it's called now) is no longer a player in this
> game... so, why are we investing on this thing... why the huge redesign for
> mobile if this is not a "real" target...?

What redesign for mobile are you talking about?

> Reminder:
> http://conversations.nokia.com/2011/02/11/mobile-phones-the-next-billion/

That doesn't say anything about Symbian.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Wolf-Michael Bolle]

Hi David,

On Wednesday 21 September 2011 08:27:52 ext David Faure wrote:

> > > Well, apart from the "too many details about the spec" the API in
> > > qmime.git is mostly good, I like QMimeDatabase.
> > >
> > > But the code is mostly about parsing XML files...
> > >
> > > Well, anyway. I'll let you and Wolf-Michael debate about which API is
> > > chosen for inclusion into Qt, and only then I'll implement the
> > > shared-mime-info backend into the chosen repository. Better not do it
> > > twice.
> >
> > I took a look at QMimeDatabase, and the first thing that I stumbled over
> > is the addMimeTypes() method. It creates a dependency on
> > freedesktop.org.xml or some edited version of it. In my opinion, this
> > will not work on every platform out there (particulary the smaller
> > ones). The test cases then seem to use the findByName(), findByData()
> > and findByFile() methods. They look straightforward to me. The code
> > about user-modified MIME types I don't find really necessary in the API.
> > Also, can we leave all mutable methods out of the interface, and let the
> > individual platform deal with the question on how the data gets into
> > that database? That would match the discussion we had about my proposal,
> > too.
>
> I completely agree.
>
> BTW I'm working on fixing the tests in shared-mime-info itself, because
> xdgmime is missing a few features.

I have done some extensive code cleanup in the "wolf" branch of the qmime
repository. It has reached the point where I would agree to it. If Иван is ok
with this too, then I'd suggest to use this as a starting point for the next
activities:

- Merge my changes into qmime/master.
- Иван could work on necessary changes for qtcreator without which he said
qtcreator will not compile any more.
- David could implement the shared-mime-info backend as suggested in the
qmime repository.
- I could add a QML wrapper based on my previous work.

I still have one question about one of QMimeType's properties,
genericIconName. I'd prefer to change that property into returning the actual
path to the icon file to be more portable. What is the proper way to get an
icon file name from the generic icon name?

Also, why do the glob patterns for *.tar.gz return *.tar.gz *.tgz *.taz when
suffixes only returns tgz and taz?

Finally, who are the people with actual stakes who should be on the list of
reviewers?

[Иван Комиссаров]

I explored native mime database in Windows. It is stored in registry and contains data for most common extensions. It is a map from "*.extension" to mime type name. This mime type name is equal to freedesktop.org, however for most of types it is not set. So, if we will try to generate database from registry, this database will not be complete. Next problem i couldn't find description and icon for mime types. Are they missing? And the last problem that we lose feature of determining mime type by content (i didn't find any magic matchers in registry too). Also we have to forgot about aliases.

We need to have single behavior of a database on all platforms - in particular, we need to have same mime types names. Aliases and content-type spelling will give you headache.

I'm not sure what about other systems that Qt supports, but i think we can't use native database - it is very poor on win and i'm not sure it exists on Symbian (correct me, if i'm wrong). Until we can be sure that we can retrieve ALL information about mime types, including localized comments and icons (on mac and win) i suggest to use freedesktop.org specification on all systems.

If we will use freedesktop.org spec, we need to use rather Qt installer to install mime database or we have to support embedding files in application directory. I think storing mime types with application should be very frequent use case on windows, because we only need small subset of mime types specific for given application. Also it is common way to deploy applications on win - to deploy all tools they depends on with application.

Ivan.

[Wolf-Michael Bolle]

On Wednesday 21 September 2011 15:19:59 ext Иван Комиссаров wrote:

> I explored native mime database in Windows. It is stored in registry and
> contains data for most common extensions. It is a map from "*.extension"
> to mime type name. This mime type name is equal to freedesktop.org,
> however for most of types it is not set.

I wouldn't be surprised if those mappings are added during the installation of
applications.

> So, if we will try to generate database from registry, this database will
not be complete.

Why do we need to duplecate the database?

> Next problem i couldn't find description and icon for mime types. Are they
missing?

The file properties dialog is able to show that kind of information. Also, when
I install the VLC media player all mp3 icons change.

> And the last problem that we lose feature of determining mime type by
> content (i didn't find any magic matchers in registry too).

Would it be an option for platforms to not support that?

> Also we have to forgot about aliases.

Then the Windows platform will not return aliases. No problem.

> We need to have single behavior of a database on all platforms -

I actually disagree. I believe an application needs to perform natively.

> in particular, we need to have same mime types names.

I actually believe that if a platform natvely calls a MIME type something else
than freedesktop.org then we should mess with that. What is worse than an
application that is behaving different than every other application on that
platform?

> Aliases and content-type spelling will give you headache.
>
> I'm not sure what about other systems that Qt supports, but i think we
> can't use native database - it is very poor on win

So be it then. Or, the implementation for the Windows platform could use the
freedesktop.org database and map back the MIME type names.

> and i'm not sure it exists on Symbian (correct me, if i'm wrong).

I honestly don't know yet (I'm still in the process of determining that).
Still, I believe we should leave embedded platforms with ways to preserve
precious flash memory.

> Until we can be sure that we can retrieve ALL information about mime types,
> including localized comments and icons (on mac and win) i suggest to use
> freedesktop.org specification on all systems.

I vote against that.

> If we will use freedesktop.org spec, we need to use rather Qt installer to
> install mime database or we have to support embedding files in application
> directory. I think storing mime types with application should be very
> frequent use case on windows, because we only need small subset of mime
> types specific for given application. Also it is common way to deploy
> applications on win - to deploy all tools they depends on with
> application.

Do we really want to re-implement OS functionality? The VLC media player - a
Qt based application - for example would have to register first with Windows
and then with Qt? That doesn't sound very appealing.

[l***@nokia.com]

On 9/21/11 5:09 PM, "ext Wolf-Michael Bolle"
<wolf-***@nokia.com> wrote:

>On Wednesday 21 September 2011 15:19:59 ext Иван Комиссаров wrote:
>
>> I explored native mime database in Windows. It is stored in registry and
>> contains data for most common extensions. It is a map from "*.extension"
>> to mime type name. This mime type name is equal to freedesktop.org,
>> however for most of types it is not set.
>
>I wouldn't be surprised if those mappings are added during the
>installation of
>applications.
>
>> So, if we will try to generate database from registry, this database
>>will
>not be complete.
>
>Why do we need to duplecate the database?
>
>> Next problem i couldn't find description and icon for mime types. Are
>>they
>missing?
>
>The file properties dialog is able to show that kind of information.
>Also, when
>I install the VLC media player all mp3 icons change.
>
>> And the last problem that we lose feature of determining mime type by
>> content (i didn't find any magic matchers in registry too).
>
>Would it be an option for platforms to not support that?
>
>> Also we have to forgot about aliases.
>
>Then the Windows platform will not return aliases. No problem.
>
>> We need to have single behavior of a database on all platforms -
>
>I actually disagree. I believe an application needs to perform natively.
>
>> in particular, we need to have same mime types names.
>
>I actually believe that if a platform natvely calls a MIME type something
>else
>than freedesktop.org then we should mess with that. What is worse than an
>application that is behaving different than every other application on
>that
>platform?
>
>> Aliases and content-type spelling will give you headache.
>>
>> I'm not sure what about other systems that Qt supports, but i think we
>> can't use native database - it is very poor on win
>
>So be it then. Or, the implementation for the Windows platform could use
>the
>freedesktop.org database and map back the MIME type names.
>
>> and i'm not sure it exists on Symbian (correct me, if i'm wrong).
>
>I honestly don't know yet (I'm still in the process of determining that).
>Still, I believe we should leave embedded platforms with ways to preserve
>precious flash memory.
>
>> Until we can be sure that we can retrieve ALL information about mime
>>types,
>> including localized comments and icons (on mac and win) i suggest to use
>> freedesktop.org specification on all systems.
>
>I vote against that.
>
>> If we will use freedesktop.org spec, we need to use rather Qt installer
>>to
>> install mime database or we have to support embedding files in
>>application
>> directory. I think storing mime types with application should be very
>> frequent use case on windows, because we only need small subset of mime
>> types specific for given application. Also it is common way to deploy
>> applications on win - to deploy all tools they depends on with
>> application.
>
>Do we really want to re-implement OS functionality? The VLC media player
>- a
>Qt based application - for example would have to register first with
>Windows
>and then with Qt? That doesn't sound very appealing.

I agree with you when it comes to registering apps as handlers for
mimetypes. But the more generic extension -> mimetype and file
content/magic -> mimetype mapping could most likely be handled with 100%
platform independent code.

Cheers,
Lars

[Иван Комиссаров]

I agree with Lars. I think we need two tools - one for determining mime types (qmime) which fully accords to freedesktop.org specification and second for settings default application for file path or mime type.

First tool should be platform independent, and second should behave natively, possibly use native database. Structure of the second tool is out scope of this thread.

22.09.2011, в 10:46, <***@nokia.com> <***@nokia.com> написал(а):

> On 9/21/11 5:09 PM, "ext Wolf-Michael Bolle"
> <wolf-***@nokia.com> wrote:
>
>> On Wednesday 21 September 2011 15:19:59 ext Иван Комиссаров wrote:
>>
>>> I explored native mime database in Windows. It is stored in registry and
>>> contains data for most common extensions. It is a map from "*.extension"
>>> to mime type name. This mime type name is equal to freedesktop.org,
>>> however for most of types it is not set.
>>
>> I wouldn't be surprised if those mappings are added during the
>> installation of
>> applications.
>>
>>> So, if we will try to generate database from registry, this database
>>> will
>> not be complete.
>>
>> Why do we need to duplecate the database?
>>
>>> Next problem i couldn't find description and icon for mime types. Are
>>> they
>> missing?
>>
>> The file properties dialog is able to show that kind of information.
>> Also, when
>> I install the VLC media player all mp3 icons change.
>>
>>> And the last problem that we lose feature of determining mime type by
>>> content (i didn't find any magic matchers in registry too).
>>
>> Would it be an option for platforms to not support that?
>>
>>> Also we have to forgot about aliases.
>>
>> Then the Windows platform will not return aliases. No problem.
>>
>>> We need to have single behavior of a database on all platforms -
>>
>> I actually disagree. I believe an application needs to perform natively.
>>
>>> in particular, we need to have same mime types names.
>>
>> I actually believe that if a platform natvely calls a MIME type something
>> else
>> than freedesktop.org then we should mess with that. What is worse than an
>> application that is behaving different than every other application on
>> that
>> platform?
>>
>>> Aliases and content-type spelling will give you headache.
>>>
>>> I'm not sure what about other systems that Qt supports, but i think we
>>> can't use native database - it is very poor on win
>>
>> So be it then. Or, the implementation for the Windows platform could use
>> the
>> freedesktop.org database and map back the MIME type names.
>>
>>> and i'm not sure it exists on Symbian (correct me, if i'm wrong).
>>
>> I honestly don't know yet (I'm still in the process of determining that).
>> Still, I believe we should leave embedded platforms with ways to preserve
>> precious flash memory.
>>
>>> Until we can be sure that we can retrieve ALL information about mime
>>> types,
>>> including localized comments and icons (on mac and win) i suggest to use
>>> freedesktop.org specification on all systems.
>>
>> I vote against that.
>>
>>> If we will use freedesktop.org spec, we need to use rather Qt installer
>>> to
>>> install mime database or we have to support embedding files in
>>> application
>>> directory. I think storing mime types with application should be very
>>> frequent use case on windows, because we only need small subset of mime
>>> types specific for given application. Also it is common way to deploy
>>> applications on win - to deploy all tools they depends on with
>>> application.
>>
>> Do we really want to re-implement OS functionality? The VLC media player
>> - a
>> Qt based application - for example would have to register first with
>> Windows
>> and then with Qt? That doesn't sound very appealing.
>
> I agree with you when it comes to registering apps as handlers for
> mimetypes. But the more generic extension -> mimetype and file
> content/magic -> mimetype mapping could most likely be handled with 100%
> platform independent code.
>
> Cheers,
> Lars

[Petr Vanek]

On Sep 22, 2011 (Thursday), at 3:32 PM, Иван Комиссаров wrote:

> I agree with Lars. I think we need two tools - one for determining mime types (qmime) which fully accords to freedesktop.org specification and second for settings default application for file path or mime type.

exactly, I'd like to have something lowlevel available in Qt too. Just something like: setDefaultApp(), defaultApp(), listAppsForType() etc.

>
> First tool should be platform independent, and second should behave natively, possibly use native database. Structure of the second tool is out scope of this thread.
>
> 22.09.2011, в 10:46, <***@nokia.com> <***@nokia.com> написал(а):
>
>> On 9/21/11 5:09 PM, "ext Wolf-Michael Bolle"
>> <wolf-***@nokia.com> wrote:
>>
>>> On Wednesday 21 September 2011 15:19:59 ext Иван Комиссаров wrote:
>>>
>>>> I explored native mime database in Windows. It is stored in registry and
>>>> contains data for most common extensions. It is a map from "*.extension"
>>>> to mime type name. This mime type name is equal to freedesktop.org,
>>>> however for most of types it is not set.
>>>
>>> I wouldn't be surprised if those mappings are added during the
>>> installation of
>>> applications.
>>>
>>>> So, if we will try to generate database from registry, this database
>>>> will
>>> not be complete.
>>>
>>> Why do we need to duplecate the database?
>>>
>>>> Next problem i couldn't find description and icon for mime types. Are
>>>> they
>>> missing?
>>>
>>> The file properties dialog is able to show that kind of information.
>>> Also, when
>>> I install the VLC media player all mp3 icons change.
>>>
>>>> And the last problem that we lose feature of determining mime type by
>>>> content (i didn't find any magic matchers in registry too).
>>>
>>> Would it be an option for platforms to not support that?
>>>
>>>> Also we have to forgot about aliases.
>>>
>>> Then the Windows platform will not return aliases. No problem.
>>>
>>>> We need to have single behavior of a database on all platforms -
>>>
>>> I actually disagree. I believe an application needs to perform natively.
>>>
>>>> in particular, we need to have same mime types names.
>>>
>>> I actually believe that if a platform natvely calls a MIME type something
>>> else
>>> than freedesktop.org then we should mess with that. What is worse than an
>>> application that is behaving different than every other application on
>>> that
>>> platform?
>>>
>>>> Aliases and content-type spelling will give you headache.
>>>>
>>>> I'm not sure what about other systems that Qt supports, but i think we
>>>> can't use native database - it is very poor on win
>>>
>>> So be it then. Or, the implementation for the Windows platform could use
>>> the
>>> freedesktop.org database and map back the MIME type names.
>>>
>>>> and i'm not sure it exists on Symbian (correct me, if i'm wrong).
>>>
>>> I honestly don't know yet (I'm still in the process of determining that).
>>> Still, I believe we should leave embedded platforms with ways to preserve
>>> precious flash memory.
>>>
>>>> Until we can be sure that we can retrieve ALL information about mime
>>>> types,
>>>> including localized comments and icons (on mac and win) i suggest to use
>>>> freedesktop.org specification on all systems.
>>>
>>> I vote against that.
>>>
>>>> If we will use freedesktop.org spec, we need to use rather Qt installer
>>>> to
>>>> install mime database or we have to support embedding files in
>>>> application
>>>> directory. I think storing mime types with application should be very
>>>> frequent use case on windows, because we only need small subset of mime
>>>> types specific for given application. Also it is common way to deploy
>>>> applications on win - to deploy all tools they depends on with
>>>> application.
>>>
>>> Do we really want to re-implement OS functionality? The VLC media player
>>> - a
>>> Qt based application - for example would have to register first with
>>> Windows
>>> and then with Qt? That doesn't sound very appealing.
>>
>> I agree with you when it comes to registering apps as handlers for
>> mimetypes. But the more generic extension -> mimetype and file
>> content/magic -> mimetype mapping could most likely be handled with 100%
>> platform independent code.
>>
>> Cheers,
>> Lars
>
>
> _______________________________________________
> Qt5-feedback mailing list
> Qt5-***@qt.nokia.com
> http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Иван Комиссаров]

23.09.2011, в 11:46, Petr Vanek написал(а):


> On Sep 22, 2011 (Thursday), at 3:32 PM, Иван Комиссаров wrote:
>
>> I agree with Lars. I think we need two tools - one for determining mime types (qmime) which fully accords to freedesktop.org specification and second for settings default application for file path or mime type.
>
> exactly, I'd like to have something lowlevel available in Qt too. Just something like: setDefaultApp(), defaultApp(), listAppsForType() etc.
>

As i already mentioned, i don't want to discuss this tool in current thread; however i have some thoughts about it:)



23.09.2011, в 12:59, Wolf-Michael Bolle написал(а):
>
> Hi Иван,
>
>> I will merge changes to master.
>
> perfect, I just received the changes.
>
>> I will start to work on changes for QtCreator in my branch. Actually,
>> Creator depends on user mime-types and we can't use qmime in QtCreator
>> without this feature.
>
> Is there something I can help you with?
>
> Michael

No, thanks, better implement qml wrappers (i know almost nothing about how they are done:) )

[Иван Комиссаров]

Plan seems ok, if everyone agree that we will use freedesktop.org database. I will merge changes to master.

I will start to work on changes for QtCreator in my branch. Actually, Creator depends on user mime-types and we can't use qmime in QtCreator without this feature.

22.09.2011, в 13:10, Wolf-Michael Bolle написал(а):
>
> Hi Иван,
>
> can you please comment? I sort of need to know how to proceed.
>
> Thanks
>
> Michael

[Wolf-Michael Bolle]

Hi Иван,

> I will merge changes to master.

perfect, I just received the changes.

> I will start to work on changes for QtCreator in my branch. Actually,
> Creator depends on user mime-types and we can't use qmime in QtCreator
> without this feature.

Is there something I can help you with?

Michael

[Wolf-Michael Bolle]

Hi David,

Иван and I have agreed on a codebase on qmime.git. It pretty much matches what
was discussed on the mailing list. I will merge missing features from my
qtaddonmimetype.git repostiory like QML wrappers into qmime.git.

You were offering to implement the shared-mime-info backend. If that offer is
still valid I'd like to ask you to hack away.

Thanks in advance,

Michael

[David Faure]

On Friday 23 September 2011 11:15:29 Wolf-Michael Bolle wrote:
> Hi David,
>
> Иван and I have agreed on a codebase on qmime.git. It pretty much matches
> what was discussed on the mailing list. I will merge missing features from
> my qtaddonmimetype.git repostiory like QML wrappers into qmime.git.

Great!

> You were offering to implement the shared-mime-info backend. If that offer
> is still valid I'd like to ask you to hack away.

Yes, this is definitely still valid. I'm on business travel this week so I
didn't start yet, but I will do that next week hopefully.

I guess I will import QStandardPaths from Qt5 into the sources for now, since
it hasn't been merged into Qt5 yet.

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Иван Комиссаров]

I returned some feature that are needed not to break QtCreator functionality.

This includes:
- "QMimeTypeBuilder" (instead of QMutableMimeType) (as Creator allows to edit mime types)
- "QList<QMimeType> userMimeTypes" getter and setters in QMimeTypeDatabase (API differs from QtCreator, but i don't see any problem here)
- "userMimeTypeFile" getter and setter in QMimeTypeDatabase (to locate where are stored user mime types)
- "QList<QMimeMagicRuleMatcher> magicMatchers" getter in QMimeType (as Creator displays list of magics)
- Code for saving and loading user mime types. I'm not sure, but we can drop this point as it can be implemented in QtCreator using public API

I've dropped support for 'weighted' glob patterns in public API (Builder) as David suggested earlier.

Also i removed "clear" method from QMimeType - i don't see need for it if we suppose QMimeType to be immutable.

I believe all code except reading/writing user mime types to xml should be included in master and this code can be moved to example or unit test.

[Wolf-Michael Bolle]

Hi Иван,

> I returned some feature that are needed not to break QtCreator
> functionality.
>
> This includes:
> - "QMimeTypeBuilder" (instead of QMutableMimeType) (as Creator allows to
> edit mime types) - "QList<QMimeType> userMimeTypes" getter and setters in
> QMimeTypeDatabase (API differs from QtCreator, but i don't see any problem
> here) - "userMimeTypeFile" getter and setter in QMimeTypeDatabase (to
> locate where are stored user mime types) - "QList<QMimeMagicRuleMatcher>
> magicMatchers" getter in QMimeType (as Creator displays list of magics) -
> Code for saving and loading user mime types. I'm not sure, but we can drop
> this point as it can be implemented in QtCreator using public API
>
> I've dropped support for 'weighted' glob patterns in public API (Builder)
> as David suggested earlier.
>
> Also i removed "clear" method from QMimeType - i don't see need for it if
> we suppose QMimeType to be immutable.
>
> I believe all code except reading/writing user mime types to xml should be
> included in master and this code can be moved to example or unit test.

has this already been pushed to master or is it possible to review this, first?
I'd prefer to not see methods reappear in the public API that were removed on
purpose.

Michael

[Иван Комиссаров]

26.09.2011, в 12:46, Wolf-Michael Bolle написал(а):

> The consensus on the list seemed to be that we want
> - to have a clean and minimalistic public API
> - to not support editing / user MIME type use cases

This is your consensus, not mine. I never said we have not to support user mime types, you just removed them without any asking.

> Working code does not make the code a good candidate for a public API in Qt.
> Since I've started with Nokia I've learned that the standards for Qt are
> *very* high. The solution to separate working code that should be in the
> public API of Qt from code that should stay out of it but keep on working is
> to refactor that code out into either an internal API of Qt or even into the
> realm of the actual application.
>
> Let's go though your individual changes:
>
> In BaseMimeTypeParser, you suggest to reintroduce the static methods
> readUserModifiedMimeTypes() and writeUserModifiedMimeTypes(). I don't like
> it. But since it's internal I can probably live with it.

As i said, we can remove writing at all - it uses only public API and can be implemented by user.

> In QMimeDatabase, you suggest to reintroduce userMimeTypes(),
> addUserMimeType(), removeUserMimeType(), userMimeTypeFile(),
> setUserMimeTypeFile(), readUserMimeTypes() and writeUserMimeTypes(). I
> definitely object to those. The public API should not support user MIME types.
> If you want QtCreator to support that I suggest you move that somewhere
> internal. I'd even go as far as to move it back to qtcreator where that code
> came from.

So QtCreator will use private headers, great. File managers should use private headers. They will break any time Qt changes.

> In QMimeDatabasePrivate you suggest to reintroduce userMimeTypes and
> userMimeTypeFile. I suggest to move those together with code above back into
> qtcreator.

We can't. Creator should use private headers.

> In QMimeType you suggest to remove the clear() method. I am fine with that. I
> don't need it.

Ok.

> In QMimeType you suggest to reintroduce the getter magicMatchers(). I
> definitely object to that because it reintroduces the class
> QMimeMagicRuleMatcher into the public API. I removed that dependency on
> purpose. Please make qtcreator use QMimeTypeData to access that data.
>
> You suggest to introduce a QMimeTypeBuilder class to the public API. I
> definitely object to that. Reason #1: All of that is accessible via
> QMimeTypeData, reason #2: Such a class currently should be part of the
> internal API at best, reason #3 Lars Knoll told me personally to not do it.

User can't user private data.

> I hope I didn't scare you off too bad. My offer to help you with qtcreator is
> still valid. Do you have a specific branch of qtcreator that you work with? I'd
> really like to support you with that.

No. The changes i maid to code are very big. I don't want to replace QtCreator's mime types right now.

I don't understand why you afraid of user mime types. Most you arguments can be used to remove dynamic properties from QObject:)

[Wolf-Michael Bolle]

Hi Иван,

> > The consensus on the list seemed to be that we want
> > - to have a clean and minimalistic public API
> > - to not support editing / user MIME type use cases
>
> This is your consensus, not mine.

My understanding is that user-defined MIME types are for supporting editing
MIME types. Please correct me if I'm wrong there.

Maybe in a moment of overexcitement I streched the meaning of consensus. I
didn't means to hurt your feelings.

Still, I believe the subject has been discussed on the list extensively and
resulted in the majority and seniority of the people speaking out against non-
common features in the public API for MIME type support in Qt like editing:

Lars Knoll: "And the question is whether this is a use case that should be
supported by Qt essentials. I don't think so."

Lars Knoll: "MIME type handling should become part of the basic offering. But
only for the common use case of reading them and figuring out the MIME type
of files and data."

Thiago Macieira: "I'm of the same opinion. Writing Qt functionality that
benefits one application in the system seems superfluous. We're trying to
resolve the common case here. If editing MIME types turns out to be a common
task, then we can revisit."

David Faure: "IMHO the editing of MIME types in Qt Creator should be removed.
I asked danimo and he was very surprised to hear that such a thing existed.
But if Qt creator should really allow editing of MIME types, then it should
edit the system MIME types (I have code for that too...). The concept of per-
application MIME types breaks the concept of shared-mime-info."

David Faure: "Yes, and this (Sometimes - quite rare though, an application
really need it's own format of files for its inner purposes. That's why
creating of custom MIME types can be useful sometimes.) can be done by
installing an XML file, no API needed."

David Faure: "Same thing with the glob weights -- this shouldn't appear in the
API"

David Faure: "Applications can define new MIME types by installing an XML file
into a location that will be seen by update-mime-database. This does not
require API with all the little details of the spec, it simply requires one
XML file."

David Faure: "As Wolf-Michael noted, the API for creating MIME types doesn't
really belong in there; that's far too system-dependent, and far too "rare"
compared to queries."

My personal experience and their explanations also lead me to believe that
this is the right way to go.

> I never said we have not to support user mime types, you just removed them
without any asking.

I removed them in my branch as you instructed. Nobody on the list objected to
my changes and I understood your merging of the code into master as
acceptance.

> > In QMimeDatabase, you suggest to reintroduce userMimeTypes(),
> > addUserMimeType(), removeUserMimeType(), userMimeTypeFile(),
> > setUserMimeTypeFile(), readUserMimeTypes() and writeUserMimeTypes(). I
> > definitely object to those. The public API should not support user MIME
> > types. If you want QtCreator to support that I suggest you move that
> > somewhere internal. I'd even go as far as to move it back to qtcreator
> > where that code came from.
>
> So QtCreator will use private headers, great. File managers should use
> private headers. They will break any time Qt changes.

Can you explain what you mean? I don't understand what you are trying to say.

About the usage of private headers I'd like to add the following: If the
internal API of Qt changes in a new release, a new release of Qt Creator as
the user of of that API would be necessary. Since both are currently released
by Nokia (and in the future by some Open Governance body) I see no problem
here.

> > In QMimeDatabasePrivate you suggest to reintroduce userMimeTypes and
> > userMimeTypeFile. I suggest to move those together with code above back
> > into qtcreator.
>
> We can't. Creator should use private headers.

Sorry for my asking but why not?

> > In QMimeType you suggest to reintroduce the getter magicMatchers(). I
> > definitely object to that because it reintroduces the class
> > QMimeMagicRuleMatcher into the public API. I removed that dependency
on
> > purpose. Please make qtcreator use QMimeTypeData to access that data.
> >
> > You suggest to introduce a QMimeTypeBuilder class to the public API. I
> > definitely object to that. Reason #1: All of that is accessible via
> > QMimeTypeData, reason #2: Such a class currently should be part of the
> > internal API at best, reason #3 Lars Knoll told me personally to not do
> > it.
>
> User can't user private data.

Of course the user can. It's part of the internal API. It's not nice but any
Qt code is allowed to use internal APIs.

> > I hope I didn't scare you off too bad. My offer to help you with
> > qtcreator is still valid. Do you have a specific branch of qtcreator
> > that you work with? I'd really like to support you with that.
>
> No. The changes i maid to code are very big. I don't want to replace
> QtCreator's mime types right now.

Are the changes you made to the code related to MIME types or something
completely unrelated? If your branch contains more than just MIME type work
than I suggest we create a branch just for MIME type work that the two of us
can work on. What do you think?

> I don't understand why you afraid of user mime types. Most you arguments
> can be used to remove dynamic properties from QObject:)

IMHO user MIME types do not belong into a public minimalistic Qt API. The
purpose of that API is to support the most pressing and average use cases.
User MIME types belong to a very specialized and if you ask me very rare use
case that the application should handle by itself.

Michael

[Иван Комиссаров]

Seems i'm wasting my time.

I gave you and David administer rights on repo. I don't see what else can i do to qmime. Was glad to work with you.

26.09.2011, в 15:33, Wolf-Michael Bolle написал(а):

Hi Иван,

>> The consensus on the list seemed to be that we want
>> - to have a clean and minimalistic public API
>> - to not support editing / user MIME type use cases
>
> This is your consensus, not mine.

My understanding is that user-defined MIME types are for supporting editing
MIME types. Please correct me if I'm wrong there.

Maybe in a moment of overexcitement I streched the meaning of consensus. I
didn't means to hurt your feelings.

Still, I believe the subject has been discussed on the list extensively and
resulted in the majority and seniority of the people speaking out against non-
common features in the public API for MIME type support in Qt like editing:

Lars Knoll: "And the question is whether this is a use case that should be
supported by Qt essentials. I don't think so."

Lars Knoll: "MIME type handling should become part of the basic offering. But
only for the common use case of reading them and figuring out the MIME type
of files and data."

Thiago Macieira: "I'm of the same opinion. Writing Qt functionality that
benefits one application in the system seems superfluous. We're trying to
resolve the common case here. If editing MIME types turns out to be a common
task, then we can revisit."

David Faure: "IMHO the editing of MIME types in Qt Creator should be removed.
I asked danimo and he was very surprised to hear that such a thing existed.
But if Qt creator should really allow editing of MIME types, then it should
edit the system MIME types (I have code for that too...). The concept of per-
application MIME types breaks the concept of shared-mime-info."

David Faure: "Yes, and this (Sometimes - quite rare though, an application
really need it's own format of files for its inner purposes. That's why
creating of custom MIME types can be useful sometimes.) can be done by
installing an XML file, no API needed."

David Faure: "Same thing with the glob weights -- this shouldn't appear in the
API"

David Faure: "Applications can define new MIME types by installing an XML file
into a location that will be seen by update-mime-database. This does not
require API with all the little details of the spec, it simply requires one
XML file."

David Faure: "As Wolf-Michael noted, the API for creating MIME types doesn't
really belong in there; that's far too system-dependent, and far too "rare"
compared to queries."

My personal experience and their explanations also lead me to believe that
this is the right way to go.

> I never said we have not to support user mime types, you just removed them
without any asking.

I removed them in my branch as you instructed. Nobody on the list objected to
my changes and I understood your merging of the code into master as
acceptance.

>> In QMimeDatabase, you suggest to reintroduce userMimeTypes(),
>> addUserMimeType(), removeUserMimeType(), userMimeTypeFile(),
>> setUserMimeTypeFile(), readUserMimeTypes() and writeUserMimeTypes(). I
>> definitely object to those. The public API should not support user MIME
>> types. If you want QtCreator to support that I suggest you move that
>> somewhere internal. I'd even go as far as to move it back to qtcreator
>> where that code came from.
>
> So QtCreator will use private headers, great. File managers should use
> private headers. They will break any time Qt changes.

Can you explain what you mean? I don't understand what you are trying to say.

About the usage of private headers I'd like to add the following: If the
internal API of Qt changes in a new release, a new release of Qt Creator as
the user of of that API would be necessary. Since both are currently released
by Nokia (and in the future by some Open Governance body) I see no problem
here.

>> In QMimeDatabasePrivate you suggest to reintroduce userMimeTypes and
>> userMimeTypeFile. I suggest to move those together with code above back
>> into qtcreator.
>
> We can't. Creator should use private headers.

Sorry for my asking but why not?

>> In QMimeType you suggest to reintroduce the getter magicMatchers(). I
>> definitely object to that because it reintroduces the class
>> QMimeMagicRuleMatcher into the public API. I removed that dependency
on
>> purpose. Please make qtcreator use QMimeTypeData to access that data.
>>
>> You suggest to introduce a QMimeTypeBuilder class to the public API. I
>> definitely object to that. Reason #1: All of that is accessible via
>> QMimeTypeData, reason #2: Such a class currently should be part of the
>> internal API at best, reason #3 Lars Knoll told me personally to not do
>> it.
>
> User can't user private data.

Of course the user can. It's part of the internal API. It's not nice but any
Qt code is allowed to use internal APIs.

>> I hope I didn't scare you off too bad. My offer to help you with
>> qtcreator is still valid. Do you have a specific branch of qtcreator
>> that you work with? I'd really like to support you with that.
>
> No. The changes i maid to code are very big. I don't want to replace
> QtCreator's mime types right now.

Are the changes you made to the code related to MIME types or something
completely unrelated? If your branch contains more than just MIME type work
than I suggest we create a branch just for MIME type work that the two of us
can work on. What do you think?

> I don't understand why you afraid of user mime types. Most you arguments
> can be used to remove dynamic properties from QObject:)

IMHO user MIME types do not belong into a public minimalistic Qt API. The
purpose of that API is to support the most pressing and average use cases.
User MIME types belong to a very specialized and if you ask me very rare use
case that the application should handle by itself.

Michael
_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Wolf-Michael Bolle]

Hi Иван,

> > > I hope I didn't scare you off too bad. My offer to help you with
> > > qtcreator is still valid. Do you have a specific branch of qtcreator
> > > that you work with? I'd really like to support you with that.
> >
> > No. The changes i maid to code are very big. I don't want to replace
> > QtCreator's mime types right now.
>
> Are the changes you made to the code related to MIME types or something
> completely unrelated? If your branch contains more than just MIME type work
> than I suggest we create a branch just for MIME type work that the two of
> us can work on. What do you think?
>
> Seems i'm wasting my time.
>
> I gave you and David administer rights on repo. I don't see what else can i
> do to qmime. Was glad to work with you.

this is not a waste of time. Please let me help you with QtCreator. I'd really
love to support you and your team by making editing / user-defined MIME types
work in QtCreator again based on the current state of the MIME type API in the
qmime repository.

Is the broken state of QtCreator something I can check out from a public
repository or is there a branch we can work with?

Michael

[Иван Комиссаров]

The problem is that QtCreator's interfaces differs from mine. I mean not public API, which almost the same, i mean glob weighted patterns and MagicMatchers. I spent days to refactor them in the assumption that they will be public. Now all that work can be reversed to make changes to Creator easier.

Compare
https://gitorious.org/qmime/qmime/blobs/master/src/magicmatcher.h
and
https://qt.gitorious.org/qt-creator/qt-creator/blobs/master/src/plugins/coreplugin/mimedatabase.h#line102

Sorry, i don't have any desire to do such work again.

26.09.2011, в 18:51, Wolf-Michael Bolle написал(а):

Hi Иван,

>>> I hope I didn't scare you off too bad. My offer to help you with
>>> qtcreator is still valid. Do you have a specific branch of qtcreator
>>> that you work with? I'd really like to support you with that.
>>
>> No. The changes i maid to code are very big. I don't want to replace
>> QtCreator's mime types right now.
>
> Are the changes you made to the code related to MIME types or something
> completely unrelated? If your branch contains more than just MIME type work
> than I suggest we create a branch just for MIME type work that the two of
> us can work on. What do you think?
>
> Seems i'm wasting my time.
>
> I gave you and David administer rights on repo. I don't see what else can i
> do to qmime. Was glad to work with you.

this is not a waste of time. Please let me help you with QtCreator. I'd really
love to support you and your team by making editing / user-defined MIME types
work in QtCreator again based on the current state of the MIME type API in the
qmime repository.

Is the broken state of QtCreator something I can check out from a public
repository or is there a branch we can work with?

Michael

[André Pönitz]

Hi all.

I think Qt Creator is a red herring in this discussion. In case there will
be some incompatible implementation of some feature in Qt 5 it's up to the
Creator folks to handle the "problem". It's all nice that you keep Creator
in mind, but from in my opinion really not needed in this particular case.
Application source code can be changed easily.

Andre'

[Thiago Macieira]

On Monday, 26 de September de 2011 13:33:08 Wolf-Michael Bolle wrote:
> > > The consensus on the list seemed to be that we want
> > > - to have a clean and minimalistic public API
> > > - to not support editing / user MIME type use cases
> >
> >
> >
> > This is your consensus, not mine.
>
> My understanding is that user-defined MIME types are for supporting editing
> MIME types. Please correct me if I'm wrong there.

Wolf-Michael was right: there was a consensus.

Consensus does not require unanimity.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Иван Комиссаров]

I'm tired arguing. If you don't need this code - ok. I stopped working on qmime; i've done everything i want.

But i will not surprised if QtCreator will never use mime.

If you call consensus that you decided at nokia's office - ok.

26.09.2011, в 16:13, Thiago Macieira написал(а):

> On Monday, 26 de September de 2011 13:33:08 Wolf-Michael Bolle wrote:
>>>> The consensus on the list seemed to be that we want
>>>> - to have a clean and minimalistic public API
>>>> - to not support editing / user MIME type use cases
>>>
>>>
>>>
>>> This is your consensus, not mine.
>>
>> My understanding is that user-defined MIME types are for supporting editing
>> MIME types. Please correct me if I'm wrong there.
>
> Wolf-Michael was right: there was a consensus.
>
> Consensus does not require unanimity.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Thiago Macieira]

On Monday, 26 de September de 2011 16:22:41 ИваМ КПЌОссарПв wrote:
> I'm tired arguing. If you don't need this code - ok. I stopped working on
> qmime; i've done everything i want.

You need to stop arguing when the community reaches a consensus. After that
point, you need to accept and move on. If you don't want to work on what was
decided, that's fine, it's your choice.

> But i will not surprised if QtCreator will never use mime.
>
> If you call consensus that you decided at nokia's office - ok.

Do not throw baseless accusations. That just makes you look bad.

Look at my signature. I'm not a Nokia employee anymore. David is mostly
independent too.

Consensus is reached when there are no more facts to be discussed and when a
majority of the people participating in the discussion have reached a
decision. If you have more facts for us, which we haven't yet discussed and
could change the decision, feel free to reopen. But you're not allowed to
rehash old arguments just to get the decision to go your way.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Иван Комиссаров]

One problem that you forgot to ask QtCreator developers.

But at least, it is not my problems anymore.

26.09.2011, в 16:36, Thiago Macieira написал(а):

> On Monday, 26 de September de 2011 16:22:41 Иван Комиссаров wrote:
>> I'm tired arguing. If you don't need this code - ok. I stopped working on
>> qmime; i've done everything i want.
>
> You need to stop arguing when the community reaches a consensus. After that
> point, you need to accept and move on. If you don't want to work on what was
> decided, that's fine, it's your choice.
>
>> But i will not surprised if QtCreator will never use mime.
>>
>> If you call consensus that you decided at nokia's office - ok.
>
> Do not throw baseless accusations. That just makes you look bad.
>
> Look at my signature. I'm not a Nokia employee anymore. David is mostly
> independent too.
>
> Consensus is reached when there are no more facts to be discussed and when a
> majority of the people participating in the discussion have reached a
> decision. If you have more facts for us, which we haven't yet discussed and
> could change the decision, feel free to reopen. But you're not allowed to
> rehash old arguments just to get the decision to go your way.

_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Thiago Macieira]

On Monday, 26 de September de 2011 16:45:39 ИваМ КПЌОссарПв wrote:
> One problem that you forgot to ask QtCreator developers.
>
> But at least, it is not my problems anymore.

No, we didn't.

David Faure: "IMHO the editing of MIME types in Qt Creator should be removed.
I asked danimo and he was very surprised to hear that such a thing existed."

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Иван Комиссаров]

Well, he decided for all QtCreator team.

26.09.2011, в 17:04, Thiago Macieira написал(а):

On Monday, 26 de September de 2011 16:45:39 Иван Комиссаров wrote:
> One problem that you forgot to ask QtCreator developers.
>
> But at least, it is not my problems anymore.

No, we didn't.

David Faure: "IMHO the editing of MIME types in Qt Creator should be removed.
I asked danimo and he was very surprised to hear that such a thing existed."

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Leandro T. C. Melo]

On 9/26/2011 3:04 PM, ext Thiago Macieira wrote:
> On Monday, 26 de September de 2011 16:45:39 Иван Комиссаров wrote:
>> One problem that you forgot to ask QtCreator developers.
>>
>> But at least, it is not my problems anymore.
> No, we didn't.
>
> David Faure: "IMHO the editing of MIME types in Qt Creator should be removed.
> I asked danimo and he was very surprised to hear that such a thing existed."
>

Hi all,

I guess that simply means that danimo was not aware of the mime settings
feature. Maybe because it's a relatively recent one (since the beginning
of the year).

Anyway, we don't have to keep this feature. It's just one alternative we
currently have to solve a few related issues: It allows users who want
to use their own extensions types with our specific editors through a
simple mechanism; The low-level magic matcher interface is particularly
useful for the generic highlighter. Note that, as opposed to Kate, we
don't own the highlight definitions (we ship just a few of them), so we
can't do much beforehand on mime types that we don't know about. At
least, in a generic cross-platform way...

There are other solutions, but in general I think it boils down to the
fact that we don't have a proper mime database (it's really the app
itself). So as Andre pointed, once we have the proper support in Qt we
can implement the necessary changes in Creator.

Cheers,
Leandro

--
Leandro T. C. Melo
Software Engineer
Nokia, Qt Development Frameworks

Nokia gate5 GmbH
Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443B
Umsatzsteueridentifikationsnummer: DE 812 845 193
Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori

[Wolf-Michael Bolle]

Hi Leandro,

> > > One problem that you forgot to ask QtCreator developers.
> > >
> > > But at least, it is not my problems anymore.
> >
> > No, we didn't.
> >
> > David Faure: "IMHO the editing of MIME types in Qt Creator should be
> > removed. I asked danimo and he was very surprised to hear that such a
> > thing existed."
>
> I guess that simply means that danimo was not aware of the mime settings
> feature. Maybe because it's a relatively recent one (since the beginning
> of the year).
>
> Anyway, we don't have to keep this feature. It's just one alternative we
> currently have to solve a few related issues: It allows users who want
> to use their own extensions types with our specific editors through a
> simple mechanism; The low-level magic matcher interface is particularly
> useful for the generic highlighter. Note that, as opposed to Kate, we
> don't own the highlight definitions (we ship just a few of them), so we
> can't do much beforehand on mime types that we don't know about. At
> least, in a generic cross-platform way...
>
> There are other solutions, but in general I think it boils down to the
> fact that we don't have a proper mime database (it's really the app
> itself). So as Andre pointed, once we have the proper support in Qt we
> can implement the necessary changes in Creator.

It took me a while but I have a code base now for QtCreator that keeps all
previous functionality.

For that I separated the MIME type handling code in QtCreator in the stuff that
is also in qmime and the application-specific code that needs to run on top of
that. The continued development in the qmime repository made this task quite
challenging. Until the code in qmime becomes a part of Qt 5 I'd likd to keep
the code synchronzied between the qmime and the QtCreator repository.

Who should I contact about adding my changes into QtCreator? My favorite
scenario would be to add a branch where I add changes step by step. Is there a
review person I should contact? How do you integrate contributors into the
QtCreator team?

Thanks in advance

Michael

[David Faure]

On Friday 30 September 2011 11:11:47 Wolf-Michael Bolle wrote:
> It took me a while but I have a code base now for QtCreator that keeps all�
> previous functionality.
>
> For that I separated the MIME type handling code in QtCreator in the stuff
> that� is also in qmime and the application-specific code that needs to run
> on top of that. The continued development in the qmime repository made this
> task quite challenging. Until the code in qmime becomes a part of Qt 5 I'd
> likd to keep the code synchronzied between the qmime and the QtCreator
> repository.
>
> Who should I contact about adding my changes into QtCreator? My favorite�
> scenario would be to add a branch where I add changes step by step. Is there
> a� review person I should contact? How do you integrate contributors into
> the QtCreator team?
>
> Thanks in advance

IMHO this is premature; at some point I'll change qmime to use QStandardPaths
to locate the mimetype files to read; shouldn't QtCreator simply install XML
files into the right location? That will make its code quite different from
what you probably have right now.
And meanwhile you'll have to keep syncing the two copies and porting the code
all the time...

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Wolf-Michael Bolle]

Hi David,

> > It took me a while but I have a code base now for QtCreator that keeps
> > all previous functionality.
> >
> > For that I separated the MIME type handling code in QtCreator in the
> > stuff that is also in qmime and the application-specific code that
> > needs to run on top of that. The continued development in the qmime
> > repository made this task quite challenging. Until the code in qmime
> > becomes a part of Qt 5 I'd likd to keep the code synchronzied between
> > the qmime and the QtCreator repository.
> >
> > Who should I contact about adding my changes into QtCreator? My favorite
> > scenario would be to add a branch where I add changes step by step. Is
> > there a review person I should contact? How do you integrate
> > contributors into the QtCreator team?
>
> IMHO this is premature; at some point I'll change qmime to use
> QStandardPaths to locate the mimetype files to read; shouldn't QtCreator
> simply install XML files into the right location? That will make its code
> quite different from what you probably have right now.

QtCreator actually provides a UI to modify the MIME type information that
already is in the MIME database.

Unfortunately you just brought up a problem with the approach I have been
following. QtCreator allows you modify the entries in the MIME database. In my
current code I allow that on the contents of the singleton that stores the
information. I need to fix that.

> And meanwhile you'll have to keep syncing the two copies and porting the
> code all the time...

I agree. That will not be nice. I need to cover the time though between now
and when QtCreator may officially depend on a Qt MIME type addon. If I could
add patches to QtCreator until the file structure of qmime could be used then
synching the two copies wouldn't be that hard to maintain. What do you think?

Michael

[David Faure]

On Friday 30 September 2011 15:33:29 Wolf-Michael Bolle wrote:
> QtCreator actually provides a UI to modify the MIME type information that
> already is in the MIME database.

Yes, and so does KDE (keditfiletype).

It's quite simple, when one just has to write an xml file into the user's dir
and re-run update-mime-database.

> Unfortunately you just brought up a problem with the approach I have been
> following. QtCreator allows you modify the entries in the MIME database. In
> my current code I allow that on the contents of the singleton that stores
> the information. I need to fix that.

Not sure I understand the issue.

> > And meanwhile you'll have to keep syncing the two copies and porting the
> > code all the time...
>
> I agree. That will not be nice. I need to cover the time though between now
> and when QtCreator may officially depend on a Qt MIME type addon.

Well we could port QtCreator to qmime once qmime is done; I don't see why we
(well, you) need to port it regularly, that just seems like more work given
that the whole technical solution will change (not just API bits).

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[David Faure]

Hi Wolf-Michael,

I thought a bit more about where to get the mimetype definitions from, and I
can see three "backends":
1) the current "parse the big XML file" backend,
2) the current KDE solution of parsing the generated text files (globs2,
magic, aliases, etc.),
3) and the recommended-but-not-implemented-yet solution of parsing the
generated mime.cache files (in addition to per-mimetype xml files when one
asks for a mimetype's translated comment).

Solution 1 is slow, but has the advantage that it can be more easily deployed,
to Windows, without a dependency on shared-mime-info's "update-mime-database"
program.

As with any computing problem, it could be solved by another layer of
indirection :-)

class QMimeProviderBase
{
public:
QMimeProviderBase();

virtual void parseGlobs() = 0;
[and similar methods, parseMagic(), parseSubclasses(), parseAliases()]
// and virtual QString commentForMime(const QString &type) = 0;
};

class QMimeSystemProvider : public QMimeProviderBase
{
public:
QMimeSystemProvider();
// Parse the generated files (globs2, magic, subclasses) on demand

virtual void parseGlobs();
};

class QMimeXMLProvider : public QMimeProviderBase
{
public:
QMimeXMLProvider();
// Do XML parsing and store the results

virtual void parseGlobs();
};

class QMimeBinaryProvider : public QMimeProviderBase
{
QMimeXMLProvider();
// Parse mime.cache (possibly on demand, for its different areas?)

virtual void parseGlobs();
};

// In QMimeDatabase, we would do
// if system mime.cache found, new QMimeBinaryProvider
// else if system globs file found, new QMimeSystemProvider
// else {
// look for freedesktop.org.xml file in the system
// if not found, use Qt's own copy
// new QMimeXMLProvider
// }


How does this sound?
Useful or over-engineered?
Missing any use case?

This will remove the need for QMimeDatabaseBuilder (I'll just pass the
QMimeDatabasePrivate pointer to the provider), and hide the details of "where
the mimetype definitions come from", from the applications.

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Wolf-Michael Bolle]

Hi David,

> I thought a bit more about where to get the mimetype definitions from, and
> I can see three "backends":
> 1) the current "parse the big XML file" backend,
> 2) the current KDE solution of parsing the generated text files (globs2,
> magic, aliases, etc.),
> 3) and the recommended-but-not-implemented-yet solution of parsing the
> generated mime.cache files (in addition to per-mimetype xml files when one
> asks for a mimetype's translated comment).
>
> Solution 1 is slow, but has the advantage that it can be more easily
> deployed, to Windows, without a dependency on shared-mime-info's
> "update-mime-database" program.
>
> As with any computing problem, it could be solved by another layer of
> indirection :-)
>
> class QMimeProviderBase
> {
> public:
> QMimeProviderBase();
>
> virtual void parseGlobs() = 0;
> [and similar methods, parseMagic(), parseSubclasses(), parseAliases()]
> // and virtual QString commentForMime(const QString &type) = 0;
> };
>
> class QMimeSystemProvider : public QMimeProviderBase
> {
> public:
> QMimeSystemProvider();
> // Parse the generated files (globs2, magic, subclasses) on demand
>
> virtual void parseGlobs();
> };
>
> class QMimeXMLProvider : public QMimeProviderBase
> {
> public:
> QMimeXMLProvider();
> // Do XML parsing and store the results
>
> virtual void parseGlobs();
> };
>
> class QMimeBinaryProvider : public QMimeProviderBase
> {
> QMimeXMLProvider();
> // Parse mime.cache (possibly on demand, for its different areas?)
>
> virtual void parseGlobs();
> };
>
> // In QMimeDatabase, we would do
> // if system mime.cache found, new QMimeBinaryProvider
> // else if system globs file found, new QMimeSystemProvider
> // else {
> // look for freedesktop.org.xml file in the system
> // if not found, use Qt's own copy
> // new QMimeXMLProvider
> // }
>
>
> How does this sound?
> Useful or over-engineered?
> Missing any use case?
>
> This will remove the need for QMimeDatabaseBuilder (I'll just pass the
> QMimeDatabasePrivate pointer to the provider), and hide the details of
> "where the mimetype definitions come from", from the applications.

I like your ideas - even though for very different reasons than you. ;-)

I've just finished synching QtCreator with qmime, and as it turns out QtCreator
has some very special requirements for MIME type handling which your
backends could help me solve. I have come to understand that QtCreator is
maintaining a local MIME database that is completely independent from the
system MIME database, and is built from scratch from XML files that are part of
the QtCreator distribution. Your proposal would allow me to have seperate
backends for the system MIME database and QtCreator's local database.

As you can see in my branch I have blown up the interface of
QMimeDatabaseBuilder quite extensivly for QtCreator. If QtCreator got full
access to its backend then almost all of the methods could more or less go
away. We shouldn't kill the class right away though ...

What are your thoughts about binary compatibility? We need to make sure we
don't shoot ourselves in the legs because of vtable changes.

Michael

[David Faure]

On Friday 07 October 2011 18:09:04 Wolf-Michael Bolle wrote:
> I have come to understand that QtCreator is
> maintaining a local MIME database that is completely independent from the
> system MIME database, and is built from scratch from XML files that are part
> of the QtCreator distribution.

Yes but it doesn't have to stay that way!

It was done this way because, well, there was no code for accessing the system
MIME database.

Someone (who I understood to be from the Qt Creator development team) said on
this list earlier that Qt Creator could and should use the system database
once qmime exists.

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Иван Комиссаров]

David, where (and when) this system database should be installed on windows and mac? It is still not clear for me

07.10.2011, в 20:22, David Faure написал(а):

> On Friday 07 October 2011 18:09:04 Wolf-Michael Bolle wrote:
>> I have come to understand that QtCreator is
>> maintaining a local MIME database that is completely independent from the
>> system MIME database, and is built from scratch from XML files that are part
>> of the QtCreator distribution.
>
> Yes but it doesn't have to stay that way!
>
> It was done this way because, well, there was no code for accessing the system
> MIME database.
>
> Someone (who I understood to be from the Qt Creator development team) said on
> this list earlier that Qt Creator could and should use the system database
> once qmime exists.
>
> --
> David Faure, ***@kde.org, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
>

[David Faure]

On Friday 07 October 2011 20:31:49 you wrote:
> David, where (and when) this system database should be installed on windows
> and mac? It is still not clear for me

As I was explaining in my email with the backends, on Windows and Mac Qt could
use its own freedesktop.org.xml file, if no file is found in the standard
paths.

To go even further, Qt could have code to generate the binary mime.cache so
that the next time, it doesn't need to parse the XML, but loads binary data
into memory instead.

In any case I don't see how Qt Creator is special at all, it's just yet
another application that uses qmime, with default mimetypes from the "system"
and user-modified mimetypes in the user's dirs. I see no reason at all for it
to have its own private mimetype database.

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Wolf-Michael Bolle]

Hi David,

> > I have come to understand that QtCreator is
> > maintaining a local MIME database that is completely independent from the
> > system MIME database, and is built from scratch from XML files that are
> > part of the QtCreator distribution.
>
> Yes but it doesn't have to stay that way!
>
> It was done this way because, well, there was no code for accessing the
> system MIME database.
>
> Someone (who I understood to be from the Qt Creator development team)
said
> on this list earlier that Qt Creator could and should use the system
> database once qmime exists.

I didn't feel ready to make such design decisions on them. ;-)

I wanted to preserve their existing functionality and their way to fill their
MIME database.

Michael

[David Faure]

On Monday 10 October 2011 09:08:31 Wolf-Michael Bolle wrote:
> Hi David,
>
> > > I have come to understand that QtCreator is
> > > maintaining a local MIME database that is completely independent
> > > from the system MIME database, and is built from scratch from XML
> > > files that are part of the QtCreator distribution.
> >
> > Yes but it doesn't have to stay that way!
> >
> > It was done this way because, well, there was no code for accessing the
> > system MIME database.
> >
> > Someone (who I understood to be from the Qt Creator development team)
>
> said
>
> > on this list earlier that Qt Creator could and should use the system
> > database once qmime exists.
>
> I didn't feel ready to make such design decisions on them. ;-)
>
> I wanted to preserve their existing functionality and their way to fill
> their MIME database.

Why don't we let the Qt creator guys do the port to QMimeType once it's ready,
then?

I don't understand all this rush in hacking on Qt creator mimetype stuff
before qmime.git is ready, and without any re-thinking of how qt creator
should handle it.

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[André Pönitz]

On Friday 30 September 2011 11:11:47 ext Wolf-Michael Bolle wrote:
> For that I separated the MIME type handling code in QtCreator in the stuff that
> is also in qmime and the application-specific code that needs to run on top of
> that. The continued development in the qmime repository made this task quite
> challenging. Until the code in qmime becomes a part of Qt 5 I'd likd to keep
> the code synchronzied between the qmime and the QtCreator repository.
>
> Who should I contact about adding my changes into QtCreator? My favorite
> scenario would be to add a branch where I add changes step by step. Is there a
> review person I should contact? How do you integrate contributors into the
> QtCreator team?

A merge request on gitorious is currently probably the easiest to handle.

Andre'

[David Faure]

On Monday 26 September 2011 16:22:41 Иван Комиссаров wrote:
> But i will not surprised if QtCreator will never use mime.

For one thing, I can't see why QtCreator has a GUI for editing mimetypes.
But assuming there is really a need for it, it can be done without an API, as
I tried saying earlier in this thread:

Applications can install an XML file (into mime/packages) that describes a
mimetype. Whether we parse the "packages" XML files directly (like the code
currently does) or whether we require that update-mime-database is run
(separate discussion), the point is that apps can define new mimetypes, by
following the spec, and without the need for an API for it.
Most apps will just install a fixed xml file. If QtCreator really wants to let
the user define new mimetypes it can have code that generates these XML files
on the fly, but really, viewing the whole thing from the QtCreator angle gives
a rather skewed view of the overall picture IMHO. We have lived 12 years
without any API in the KDE libraries for creating mimetypes.

In other news, I pushed the code for faster and more accurate glob matching
(currently in the 'david' branch).

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Иван Комиссаров]

I have what to answer but it will be totally useless waste of time.

Please, merge your changes to master, if Michael agreed.

26.09.2011, в 17:30, David Faure написал(а):

> On Monday 26 September 2011 16:22:41 Иван Комиссаров wrote:
>> But i will not surprised if QtCreator will never use mime.
>
> For one thing, I can't see why QtCreator has a GUI for editing mimetypes.
> But assuming there is really a need for it, it can be done without an API, as
> I tried saying earlier in this thread:
>
> Applications can install an XML file (into mime/packages) that describes a
> mimetype. Whether we parse the "packages" XML files directly (like the code
> currently does) or whether we require that update-mime-database is run
> (separate discussion), the point is that apps can define new mimetypes, by
> following the spec, and without the need for an API for it.
> Most apps will just install a fixed xml file. If QtCreator really wants to let
> the user define new mimetypes it can have code that generates these XML files
> on the fly, but really, viewing the whole thing from the QtCreator angle gives
> a rather skewed view of the overall picture IMHO. We have lived 12 years
> without any API in the KDE libraries for creating mimetypes.
>
> In other news, I pushed the code for faster and more accurate glob matching
> (currently in the 'david' branch).

_______________________________________________
Qt5-feedback mailing list
Qt5-***@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

[Wolf-Michael Bolle]

Hi David,

On Monday 26 September 2011 15:46:12 ext Иван Комиссаров wrote:

> > In other news, I pushed the code for faster and more accurate glob
> > matching (currently in the 'david' branch).
>
> Please, merge your changes to master, if Michael agreed.

please do so.

Thanks

Michael

[David Faure]

On Wednesday 21 September 2011 14:34:05 Wolf-Michael Bolle wrote:
> I still have one question about one of QMimeType's properties,
> genericIconName. I'd prefer to change that property into returning the
> actual path to the icon file to be more portable. What is the proper way
> to get an icon file name from the generic icon name?

QIcon::fromTheme(). But I don't think qmime should depend on QtGui, so better
let the app authors do that.

Same for iconName(), which is currently missing (it can either come from a
user-defined mimetype xml, or fallback to the mimetype name with slashes
turned into dashes -- all as per the s-m-i spec).

> Also, why do the glob patterns for *.tar.gz return *.tar.gz *.tgz *.taz
> when suffixes only returns tgz and taz?

That's because of this code (from qt creator I presume)

/*!
\var QMimeTypeData::suffixPattern
\brief Regular expression to match a suffix glob pattern: "*.ext" (and not
sth like "Makefile" or "*.log[1-9]"
*/
: suffixPattern(QLatin1String("^\\*\\.[\\w+]+$"))

So this doesn't match .tar.gz, but I agree that's a bug. I'll convert this to
use my kde code instead.

But honestly I don't see the need for a "list of suffixes" method. In KDE we
only have a "primary suffix" method, for the use case of the checkbox at the
bottom of file dialogs which offers to automatically append an extension. And
shared-mime-info now (since 0.70) ensures that the order of the globs is kept,
so the writer of the XML file can control which suffix is seen as "primary".

Returning a list of suffixes has the risk that people use that for filename
matching :-)

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[David Faure]

On Thursday 15 September 2011 09:00:45 you wrote:
> On 15 September 2011 08:50, David Faure <***@kde.org> wrote:
> > On Wednesday 14 September 2011 20:01:10 Иван Комиссаров wrote:
> >> Michael, take a look at https://gitorious.org/qmime it almost
> >> finished. Can' look at what progress you have, but if you want to
> >> start from scratch i don't think it is a good idea.
> >
> > It is definitely not "almost finished". It parses the raw XML instead of
> > parsing the generated plain text files, and it has its own copy of the
> > freedesktop.org.xml instead of looking up the system files (which should
> > be done with the QStandardPaths class I finished the MR for,
> > yesterday). (https://qt.gitorious.org/qt/qtbase/merge_requests/50)
> >
> > Also, it exposes too much internals of the spec, such as the various
> > fields for magic (content-based) matching; this is all because
> > QtCreator has a GUI for defining your own mimetypes, but I can't think
> > of any use case for a user defining his own magic rules...
>
> Use Case #1: Adding support for detecting new filetypes or filetypes
> not recognised by the system (e.g. the libmagic database and epub
> documents).

That's done by the application, not by the user with a GUI.
Applications can define new mimetypes by installing an xml file into a
location that will be seen by update-mime-datase.
This does not require API with all the little details of the spec, it simply
requires one xml file.

(epub is already in shared-mime-info though)

> Use Case #2: Improving the detection logic to better detect files
> based on content (e.g. the libmagic database rules for detecting zip
> files).

That's already in shared-mime-info.

> Use Case #3: Providing your own alternate file database to detect file
> types supported by your application in a robust, platform independant
> manner. For example, in an application I have, I just want 'xml' to be
> detected and not derived types (such as xhtml and docbook) as I read
> the root node of the xml document and select the appropriate handler
> based on that, using the mimetype logic for top-level content
> detection.

Mimetype inheritance takes care of that, no need to provide an alternate file
database. With something like theMimeType.inherits("application/xml") you
would be able to detect all xml and xml-derived types.

--
David Faure, ***@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

[Wolf-Michael Bolle]

On Thursday 15 September 2011 09:50:02 ext David Faure wrote:

> Also, it exposes too much internals of the spec, such as the various fields
> for magic (content-based) matching; this is all because QtCreator has a GUI
> for defining your own mimetypes, but I can't think of any use case for a
> user defining his own magic rules...

According to the code, the list of attributes in qmime is as follows:

> QString type;

I called that name. The spec calls it type. I should probably change, then.

> QString comment;

I call that displayName. The spec calls it comment. I should probably change,
then.

> LocaleHash localeComments;

I have no name for that because I didn't know where the actual translation
would happen. If the consensus is that the translation should be in here then
I will add that, too.

> QStringList aliases;

I don't have that in my API. What is the use case for that?

> QString genericIconName;

I call that iconURL. Since I am not convinced the generic-icons will be
installed on every platform Qt runs on I favor to return a complete path to
the icon. I should probably change the type from QString to QUrl, right?

> QList<QMimeGlobPattern> globPatterns;

I don't have that in my API. What is the use case for that?

> QStringList subClassOf;

I don't have that in my API. I could add that.

> QString preferredSuffix;

I don't have that in my API. I could add that.

> QStringList suffixes;

With my latest patch that is waiting for the mirror to kick in, I call that
filenameExtension. I can't find it in the spec, though. What does everybody
prefer?

> QList<QMimeMagicRuleMatcher> magicMatchers;

I don't have that in my API. What is the use case for that?

[Иван Комиссаров]

19.09.2011, в 14:14, Wolf-Michael Bolle написал(а):

> On Thursday 15 September 2011 09:50:02 ext David Faure wrote:
>
>> Also, it exposes too much internals of the spec, such as the various fields
>> for magic (content-based) matching; this is all because QtCreator has a GUI
>> for defining your own mimetypes, but I can't think of any use case for a
>> user defining his own magic rules...
>
> According to the code, the list of attributes in qmime is as follows:
>
>> QString type;
>
> I called that name. The spec calls it type. I should probably change, then.
>
>> QString comment;
>
> I call that displayName. The spec calls it comment. I should probably change,
> then.
>
>> LocaleHash localeComments;
>
> I have no name for that because I didn't know where the actual translation
> would happen. If the consensus is that the translation should be in here then
> I will add that, too.

Same reason while it still exists; i think we should always return localized comment for current locale.

>
>> QStringList aliases;
>
> I don't have that in my API. What is the use case for that?

Specification tells that some mime types can be aliases to other types (i.e. 1 type with 2 names), for example "application/mathml+xml" and "text/mahml"

>> QString genericIconName;
>
> I call that iconURL. Since I am not convinced the generic-icons will be
> installed on every platform Qt runs on I favor to return a complete path to
> the icon. I should probably change the type from QString to QUrl, right?
>
>> QList<QMimeGlobPattern> globPatterns;
>
> I don't have that in my API. What is the use case for that?

I think this should be moved to QMutableMimeType; This is "details of implementation" mentioned by David

>> QStringList subClassOf;
>
> I don't have that in my API. I could add that.
>
>> QString preferredSuffix;
>
> I don't have that in my API. I could add that.
>
>> QStringList suffixes;
>
> With my latest patch that is waiting for the mirror to kick in, I call that
> filenameExtension. I can't find it in the spec, though. What does everybody
> prefer?

I used QtCreator names so keeping old name will save them from changing it:)

>> QList<QMimeMagicRuleMatcher> magicMatchers;
>
> I don't have that in my API. What is the use case for that?

Same as globPatterns; useful for constructing mime types, but useless in QMimeType