Re: Loading images with bad extensions
- From: Felix Riemann <friemann gnome org>
- To: Fred H Olson <fholson cohousing org>
- Cc: eog-list gnome org
- Subject: Re: Loading images with bad extensions
- Date: Mon, 21 Nov 2011 20:36:01 +0100
Hi Fred,
sorry for taking me so long to reply, but life's been quite hectic
lately.
Am Dienstag, den 25.10.2011, 09:01 -0500 schrieb Fred H Olson:
> I suspect the behavior I've come across is related to that in the
> 06 Feb 2009 post:
> Re: Loading images with bad extensions
> http://mail.gnome.org/archives/eog-list/2009-February/msg00005.html
> It refers to:
> Bug 490067 - eog does not sniff mime type
> which is still listed as new.
>
> But since it is another reason for maybe changing the code I'll
> describe my situation.
>
> I keep most of my pictures in one folder that I call "1pix" when I
> use an image on my web pages I use a script that moves it to the
> folder that is echoed to the web, checks permissions and creates a
> link in 1pix to it. The link is named <filename>.<ext>.lnk
> where <ext> is JPG or png etc.
>
> This results in not having two copies of the picture taking up space
> and yet I can find the picture in 1pix and indicates which images are
> on the web.
>
> If I click on <filename>.<ext>.lnk in Nautilus it gets displayed in
> EOG. However if I click on next while viewing an image alphabetically
> just before <filename>.<ext>.lnk , it gets skipped. I regret this
> behavior.
Hmm, I guess you made eog the default handler for .lnk-files as it
wouldn't open the file from nautilus otherwise.
Anyway, your problem is not exactly bug 490067, which is about using the
wrong loader plugin if the file extension is not the correct one. Your
problem is actually about determining that the .lnk-file is a supported
image. This however would require eog to check each image in a folder if
it's supported before adding it to the list of images that can be
browsed. That's unfortunately a rather time consuming process, which we
already had in eog-2.18 and earlier.
So, the only way this could return is after we refactor the list
generation process to be more async. The list would then only be filled
once the first image is shown. But that's unfortunately not trivial
either.
> I'm thinking about changing the names of the links to be
> <filename>.lnk.<ext> but I prefer having .lnk at the end which for
> example allows for searching for <filename>.<ext> and finding either a
> link or a picture (tho searching for <filename>. would still do that).
It would at least be a workaround. And depending on how you search for a
file, one could still make it possible to search for a file together
with it's extension.
Regards,
Felix
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]