Porting Softimage PIC loader to KDE4 / gwenview

Post by Ruben Lopez
Hi,
I'm porting the Softimage PIC loader to KDE 4. I made it work with most
applications just with the QImageIOPlugin / Handler pair, and now I am
trying to make it work with gwenview also.
Just with the QImageIOPlugin, PIC images work in the thumbnails view,
but it is not possible to open the images or view then in full screen
view. The error is "Loading meta information failed". I read a bit about
new KDE4 technologies and it seems that KFilePlugins were replaced by
strigi-analyzers.

Ruben Lopez

2009-07-08 15:37:59 UTC

Hi Aurélien,

Attached you will find the output of gwenview with this logging enabled.
This output happens when I'm seeing the thumbnail view, if I click on
the first image (the selected one), there is no extra output (I assume
that it is preloaded). If I click on the second thumbnail, then the
output repeats. In any case, I get the same message:

"Loading meta information failed"

I only see problems with "nepomuk", but the same errors are shown when I
go to a folder with png files, and they work just nice in all the views :(

Any idea?

PS: Sorry for the duplication of the previous mail, I have discovered
this morning that gwenview was moved to kdegraphics and I thought that I
should send the emails to the kde-imaging list instead.

Thanks

I am not sure strigi is the problem here. Is there anything interesting
in the console? If not, can you enable logging for document loading? To
do so you have to edit lib/document/loadingdocumentimpl.cpp and
uncomment the "#define ENABLE_LOG" line.
Aurélien
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Gwenview-general mailing list
https://lists.sourceforge.net/lists/listinfo/gwenview-general

Aurélien Gâteau

2009-07-10 08:52:52 UTC

Post by Ruben Lopez
I only see problems with "nepomuk", but the same errors are shown when I
go to a folder with png files, and they work just nice in all the views :(

The Nepomuk errors can be ignored (I need to find a way to avoid those).
What's interesting is this part:

gwenview(5570) Gwenview::LoadingDocumentImplPrivate::startLoading:
mimeType: "image/x-hdr"
gwenview(5570) Gwenview::LoadingDocumentImplPrivate::startLoading: kind: 4

4 means that the MimeTypeUtils::mimeTypeKind() method recognized the
image as an archive... This happens when the .desktop file describing
the mimetype contains some special entries. Can you send this .destop file?

Post by Ruben Lopez
Any idea?
PS: Sorry for the duplication of the previous mail, I have discovered
this morning that gwenview was moved to kdegraphics and I thought that I
should send the emails to the kde-imaging list instead.

No problem, I was quite slow to answer.

Aurélien

Ruben Lopez

2009-07-20 14:46:28 UTC

Post by Ruben Lopez
I only see problems with "nepomuk", but the same errors are shown when I
go to a folder with png files, and they work just nice in all the views :(

The Nepomuk errors can be ignored (I need to find a way to avoid those).
mimeType: "image/x-hdr"
gwenview(5570) Gwenview::LoadingDocumentImplPrivate::startLoading: kind: 4
4 means that the MimeTypeUtils::mimeTypeKind() method recognized the
image as an archive... This happens when the .desktop file describing
the mimetype contains some special entries. Can you send this .destop file?

It seems that gwenview or KDE is using the wrong desktop file. The
x-hdr.desktop file matches both .hdr and .pic extensions. I have
installed an x-pic.desktop (attached) that matches *.pic, but the other
one is being used instead. Can I write something in the .desktop file to
help gwenview differentiate between HDR pic and Softimage pic?

At this moment I can't remove the *.pic pattern from the x-hdr desktop
file, but I will be able in a couple of days, when the systems
administrator is back. This may be enough for us.

Thanks

No problem, I was quite slow to answer.

I was on holidays last week also, sorry.

Aurélien Gâteau

2009-07-20 21:33:55 UTC

Post by Ruben Lopez
I only see problems with "nepomuk", but the same errors are shown when I
go to a folder with png files, and they work just nice in all the views :(

One thing you can try is to open lib/mimetypeutils.cpp, go to the
mimeTypeKind() function, and move the if which returns KIND_DIR and
KIND_ARCHIVE to the end of the function.

But I do not understand why Gwenview would consider image/x-hdr to be an
archive. Even if it's the wrong mimetype, it's an image mimetype, so it
should return KIND_RASTER_IMAGE.

Post by Ruben Lopez
At this moment I can't remove the *.pic pattern from the x-hdr desktop
file, but I will be able in a couple of days, when the systems
administrator is back. This may be enough for us.

In case you are still stuck with that problem, you can try to copy the
x-hdr desktop file to the appropriate subdir of your .kde folder and
remove the "*.pic" from it. This should overload the system one.

Aurélien

Ruben Lopez

2009-07-21 12:04:30 UTC

Post by AurÃ©lien GÃ¢teau
mimeType: "image/x-hdr"
gwenview(5570) Gwenview::LoadingDocumentImplPrivate::startLoading: kind: 4
4 means that the MimeTypeUtils::mimeTypeKind() method recognized the
image as an archive... This happens when the .desktop file describing
the mimetype contains some special entries. Can you send this .destop file?

One thing you can try is to open lib/mimetypeutils.cpp, go to the
mimeTypeKind() function, and move the if which returns KIND_DIR and
KIND_ARCHIVE to the end of the function.
But I do not understand why Gwenview would consider image/x-hdr to be an
archive. Even if it's the wrong mimetype, it's an image mimetype, so it
should return KIND_RASTER_IMAGE.

I think that this is OK:
enum Kind { KIND_UNKNOWN, KIND_DIR, KIND_ARCHIVE, KIND_FILE,
KIND_RASTER_IMAGE, KIND_SVG_IMAGE };

So 4 is actually KIND_RASTER_IMAGE. In fact, png files also return 4.

I already did this, with no success. I have this directory structure:
/home/rlopez/.kde/share/mimelnk/image
x-hdr.desktop
x-pic.desktop

With .pic and .PIC removed from x-hdr.desktop
But it still recognizes the image as x-hdr :(

I have modified the gwenview sources to force the x-pic mime type, but
then it doesn't recognize it as a raster image, but a generic file
instead. It seems that gwenview is still using the old KImageIO plugin
architecture instead of the strigi analyzers to find out which raster
image formats are supported. I am using the version from kdegraphics
4.2.4. Is there a newer stable version with support for the strigi
analyzers? If not, I can rescue the old KImageIO plugin and port it.

I imagine that gwenview is using KImageIO because most file formats
aren't still ported to strigi analyzers, as the cmake says when you run
it on kdegraphics sources. Would it make sense to use an hybrid
solution, asking to KImageIO and the strigi analyzers and joining both
lists?

Thanks

Rubén

Aurélien Gâteau

2009-07-21 20:49:19 UTC

One thing you can try is to open lib/mimetypeutils.cpp, go to the
mimeTypeKind() function, and move the if which returns KIND_DIR and
KIND_ARCHIVE to the end of the function.
But I do not understand why Gwenview would consider image/x-hdr to be an
archive. Even if it's the wrong mimetype, it's an image mimetype, so it
should return KIND_RASTER_IMAGE.

enum Kind { KIND_UNKNOWN, KIND_DIR, KIND_ARCHIVE, KIND_FILE,
KIND_RASTER_IMAGE, KIND_SVG_IMAGE };
So 4 is actually KIND_RASTER_IMAGE. In fact, png files also return 4.

Oh... I must have reordered the enum between version... it makes sense now.

Post by Ruben Lopez
I have modified the gwenview sources to force the x-pic mime type, but
then it doesn't recognize it as a raster image, but a generic file
instead. It seems that gwenview is still using the old KImageIO plugin
architecture instead of the strigi analyzers to find out which raster
image formats are supported. I am using the version from kdegraphics
4.2.4. Is there a newer stable version with support for the strigi
analyzers? If not, I can rescue the old KImageIO plugin and port it.

I have never heard about using strigi analyzers to determine image
formats. Can you tell me more about this?

Post by Ruben Lopez
I imagine that gwenview is using KImageIO because most file formats
aren't still ported to strigi analyzers, as the cmake says when you run
it on kdegraphics sources. Would it make sense to use an hybrid
solution, asking to KImageIO and the strigi analyzers and joining both
lists?

As I said, I don't know much about using strigi analyzers this way, but
I am interested in what you can suggest here, so patches are welcomed!

Aurélien

------------------------------------------------------------------------------

Ruben Lopez

2009-07-23 15:08:36 UTC

I have never heard about using strigi analyzers to determine image
formats. Can you tell me more about this?

In fact, not. I thought that this could be possible. But it seems that
it is not. The existing strigi analyzers fail to provide even the mime
type. I finally have made it work without the strigi analyzer at all. It
was a bug in my code that only showed up when the image was loaded from
a memory buffer. The tutorials that I have found in Internet, didn't
took into account this case either, and didn't setted the format of the
image manually. Because of this, gwenview wasn't able to compute the
image size.

Thanks for your support, I will try to contribute the new loader to the
kdegraphics team.

------------------------------------------------------------------------------

Aurélien Gâteau

2009-07-27 07:39:37 UTC