DevHeads.net

KImageIO::mimeTypes and SVG/SVGZ Files

Hi,

In my application I use KImageIO::mimeTypes to determine which formats I can load
(e.g. the output of it is used in my .desktop file to fill in the MimeType definition).

However I see that obviously Qt can already (to some degree) load .svg and .svgz files,
but KImageIO::mimeTypes does not return
image/svg+xml
image/svg+xml-compressed

The solution would be to add 2 new desktop files in kdelibs/kimgio (attached).
This would automatically allow all image applications to also load these file types,
as they are then allowed in the file selector as "supported format".

However, Qt can not load all SVG files correctly ...

Despite this fact, gwenview added these 2 MimeTypes as supported formats in the .desktop file,
so I wonder if we can add these generally.

Opinions ?

Comments

Re: KImageIO::mimeTypes and SVG/SVGZ Files

By Allan Sandfeld ... at 08/31/2011 - 07:03

On Tuesday 30 August 2011, Martin Koller wrote:
You should remember to also make the compressed type a subtype of the correct
compressed archive type. This way the file can be recognized and decompressed
even if no direct image/svg+xml-compressed handler is registered.

Regards
`Allan

Re: KImageIO::mimeTypes and SVG/SVGZ Files

By Martin Koller at 08/31/2011 - 09:14

Hmmm... not sure if I understand.
In the shared-mime-info database file
/usr/share/mime/image/svg+xml-compressed.xml
there is already
<sub-class-of type="application/x-gzip"/>

Is this information not used already ?

Re: KImageIO::mimeTypes and SVG/SVGZ Files

By David Faure at 08/31/2011 - 10:55

On Wednesday 31 August 2011 16:14:34 Martin Koller wrote:
Yes.
I think Allan too, confused a "kimgio plugin description file" with a
"mimetype definition file" :-)

Re: KImageIO::mimeTypes and SVG/SVGZ Files

By Allan Sandfeld ... at 08/31/2011 - 12:57

On Wednesday 31 August 2011, David Faure wrote:
Yes, yes I did :-)

`Allan

Re: KImageIO::mimeTypes and SVG/SVGZ Files

By Christoph Feck at 08/30/2011 - 18:59

On Tuesday 30 August 2011 23:50:14 Martin Koller wrote:
Another follow up... since we currently have no "master" kdelibs, you
would have to clarify with i18n team if you can commit the new
"strings" to 4.7 branch after 4.7.1 is released.

Re: KImageIO::mimeTypes and SVG/SVGZ Files

By Christoph Feck at 08/30/2011 - 18:53

On Tuesday 30 August 2011 23:50:14 Martin Koller wrote:
I think you don't need to add the [x-test] lines, they are generated
by scripty, as far as I know. Albert knows better.

Otherwise, no objections, people are still able to change application
order, so that SVG is opened with Karbon or Inkscape.

Christoph Feck (kdepepo)
KDE Quality Team

Re: Re: KImageIO::mimeTypes and SVG/SVGZ Files

By Albert Astals Cid at 08/31/2011 - 04:13

A Dimecres, 31 d'agost de 2011, Christoph Feck vàreu escriure:
That's correct.

Albert

Re: KImageIO::mimeTypes and SVG/SVGZ Files

By Martin Koller at 08/31/2011 - 09:12

ok, removed.

But I have a general question: Why is there a "Name[lang]=" field at all ?
The translation for the mime types is already given in the shared-mime-info database.

Re: Re: KImageIO::mimeTypes and SVG/SVGZ Files

By Albert Astals Cid at 08/31/2011 - 09:20

A Dimecres, 31 d'agost de 2011, vàreu escriure:
Because it is a .desktop file and .desktop Name fields are translated.

Albert

Re: Re: KImageIO::mimeTypes and SVG/SVGZ Files

By Stefan Majewsky at 08/31/2011 - 09:33

On Wed, Aug 31, 2011 at 4:20 PM, Albert Astals Cid < ... at kde dot org> wrote:
I think the question is, why is there a Name field in the desktop file
when the shared-mime-info database has that data already?

Greetings
Stefan

Re: KImageIO::mimeTypes and SVG/SVGZ Files

By Alex Merry at 08/31/2011 - 10:40

On 31/08/11 15:33, Stefan Majewsky wrote:
Because it's a desktop file and the Name field is required.

Alex

Re: KImageIO::mimeTypes and SVG/SVGZ Files

By Michael Pyne at 08/31/2011 - 10:39

On Wednesday, August 31, 2011 16:33:15 Stefan Majewsky wrote:
The Desktop Entry Spec far predates shared-mime-info IIRC. And besides,
desktop files provide a superset of mime-type info. There's probably a good
underlying question here (such as why use .desktop files for mime types now
that we have shared-mime-info) but the reason Name fields in .desktop files
are translated is an easy enough answer.

Regards,
- Michael Pyne

Re: KImageIO::mimeTypes and SVG/SVGZ Files

By David Faure at 08/31/2011 - 10:54

On Wednesday 31 August 2011 11:39:13 Michael Pyne wrote:
Well, this doesn't define a mimetype, it defines a plugin :-)

(e.g. it defines whether reading or writing is supported, which shared-mime-
info doesn't do).

The translated name is redundant indeed, though, it's not used, except when
looking at the servicetype's associated plugins in keditfiletype.

Re: KImageIO::mimeTypes and SVG/SVGZ Files

By Martin Koller at 08/31/2011 - 12:30

even in keditfiletype I do not see where the name is used.
E.g. using "keditfiletype image/png" I see nowhere only the name "PNG"
which is inside the .desktop file.

So the main question is: can't we simply get rid of the translation lines
in these image.desktop files and save our translators some time ?
(BTW: If the translation is not used/needed, I assume I do not need to ask the translation
team for permission to add these new files in the 4.7 branch, right ?)

Another question: the line X-KDE-ImageFormat seems to be used when I want to pass
this format to e.g. QImage::save().
But I see here inconsistencies in the different .desktop files, where some include
only the lowercase string, e.g.
X-KDE-ImageFormat=gif
others lower and uppercase, e.g.
X-KDE-ImageFormat=eps,EPS,EPSI,epsf,EPSF

(The latter is even more strange as EPSI has no lowercase version)

Can this be simply made consistent so that all files only contain the lowercase version ?

Re: KImageIO::mimeTypes and SVG/SVGZ Files

By David Faure at 09/01/2011 - 06:46

On Wednesday 31 August 2011 19:30:19 Martin Koller wrote:
True, it only shows apps and parts, not plugins. My bad.

But "ktraderclient --servicetype QImageIOPlugins" shows the names :)

Re-reading the code in KService, it allows to have no Name field, actually: it
makes one up from the filename. So if it works, feel free to remove all Name
fields. If I said it was mandatory before, I was wrong.

Hmm, these are the values returned by KImageIO::types() and typeForMime(), but
I have no idea where these are used. Apparently the norm was all-uppercase;
this is a format name, not a file extension.

<a href="http://lxr.kde.org/ident?i=typeForMime" title="http://lxr.kde.org/ident?i=typeForMime">http://lxr.kde.org/ident?i=typeForMime</a>
Hmm, seems this is used for telling the user about supported formats, or for
passing as 2nd argument to QPixmap::save(), probably to trigger the plugin.

I see, so the lowercase/uppercase redundancy is to maximize the chances of
QPixmap::save finding the right plugin when some piece of code somewhere
specifies a format name. Since the author of the plugin doesn't control what
application authors might write in their code, he tends to be inclusive...

OK, except that qimagereader.cpp does format.toLower(), so case doesn't matter
indeed. We can make it all lowercase.

Re: Re: KImageIO::mimeTypes and SVG/SVGZ Files

By Albert Astals Cid at 08/31/2011 - 13:11

A Dimecres, 31 d'agost de 2011, Martin Koller vàreu escriure:
The only way you can do that is removing the Name file in which case it won't
be a valid desktop file anymore (not sure if that matters)

Albert