[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:       Andreas Pakulat <apaku () gmx ! de>
Date:       2007-12-28 12:49:40
Message-ID: 20071228124940.GC15591 () morpheus ! apaku ! dnsalias ! org
[Download RAW message or body]

On 27.12.07 22:44:16, James Richard Tyrer wrote:
> Andreas Pakulat wrote:
> > On 27.12.07 18:06:50, James Richard Tyrer wrote:
> >> Since both Okular (front end -- the app) and GwenView can 
> >> properly open the JPEG file with NO file extension, there is probably 
> >> only a small difference which I consider a bug and would suggest that 
> >> you fix it.
> > 
> > Okular sits on top of a few backends that do the actual work. That means
> > it has to decide which backend to use when it shall open a file. Now if
> > KMimeType reports the file type to be tiff, it uses the tiff backedn and
> > of course that fails to load the file because the file doesn't have tiff
> > data. 
> 
> Somewhere in this convoluted discussion, I think that I said that there 
> were probably issues with the Okular architecture.  I am not saying that 
> there is anything bad about it but only that it is different than what 
> we have had in KDE3.

Right, its totally different from the Okular architecture in KDE3,
because there is _NONE_. The reason you can open that file in
konqueror/kde3 is simply because kuickshow as an image viewer works the
same way as Gwenview, it simply throws a filename at Qt's QImageReader
(or some own code for reading images) and that finds the right way to
display the image depending on the content.

> To resolve this, I think that there are probably issues with both
> Okular and the KDE MIME system to resolve this.

I don't see any issue with Okular, at least not from an "outside" pov.

> > You see there's simply no way for okular to "fix" this, apart from
> > reading the file, then using KMimeType::findByContent() on the binary
> > data and then choosing the backend based on the result. However this
> > means reading the file from disk 2 times, which is quite some overhead
> > and should be thought about really well.
> 
> I wouldn't worry about the extra disk read because hardware is getting 
> faster as we speak.

Oh, right, just ignore those people that can only buy old hardware you
don't want. Apart from that since when has KDE become a toolkit that
doesn't care about limiting resource usage?

> 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.

There is already, but as Thiago states it can't be used if KDE follows
the mimetype spec.

Andreas

-- 
You will obey or molten silver will be poured into your ears.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]