[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [Bug 154698] Won't open some TIFF files
From:       Pino Toscano <toscano.pino () tiscali ! it>
Date:       2007-12-28 10:13:55
Message-ID: 200712281113.59091.toscano.pino () tiscali ! it
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Alle venerd́ 28 dicembre 2007, James Richard Tyrer ha scritto:
> I think that I said that there were probably issues with the Okular
> architecture.

I think not.

> I wouldn't worry about the extra disk read because hardware is getting
> faster as we speak.  It occurs to me that Okular calls some method in
> KMimeType and it returns the MIME type.  Now, if there was a method that
> did *not* consider the extension to determine the MIME type and Okular
> used this method, the issue should be solved.

Why should I workaround some "problems" of KMimeType?
This means that any other application would need to workaround KMimeType 
misdetections in own code -- so instead of fix those problems in *one* place, 
we workaround them all around in KDE applications?
Is your engineering attitude in flavour of this?

> Starting to dig into the code, I find that Okular appears to install a
> lot of unnecessary 'desktop' files -- one for each MIME type or group of
> related MIME types.  This is not needed.

This *is* needed. Each .desktop is addressed to a different subject.
- libokularGenerator_foo.desktop
  Tells _okular_ that foo is a generator available
- okularApplication_foo.desktop
  Tells _KDE_ that okular is an application for the mimetypes the foo
  generator can read
- okularFoo.desktop
  Tells _KDE_ that okular is a KPart for the mimetypes the foo
  generator can read (essential for printing and konqueror embedding)
This was one of the cleanest solution we had so far; other solutions requires 
special threatment in the mimetype handling (like virtual mimetypes). Albert 
and me had a discussion with David Faure about this, and we agreed that _for 
now_ this can be an acceptable (and no-code needed) solution.

> This needs to be done, IAC, since users are going to find all of this rather
> confusing. 

Since when users need to fiddle around with internal .desktop of KDE?
If users == developers, then these .desktop files are explained in the 
documentation, and you create them just *once*.

-- 
Pino Toscano

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]