RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

Gimp 2.0 reading .xvpics

This discussion is connected to the gimp-user-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.
Gimp 2.0 reading .xvpics Obi-Wan 18 Apr 10:02
  Gimp 2.0 reading .xvpics Sven Neumann 18 Apr 12:15
Obi-Wan
2004-04-18 10:02:16 UTC (about 20 years ago)

Gimp 2.0 reading .xvpics

I recently "upgraded" to gimp 2.0. After a bit of confusion, I finally realized that gimp now stores its thumbnails in ~/.thumbnails rather than in ./.xvpics. This is an enormous annoyance for me, since I have many CD's of images, all organized in directories with thumbs stored in the respective .xvpics directories so that they don't have to be regenerated each time a user pops the CD into their drive.

The new ~/.thumbnails setup is unacceptable for this use, since the last thing I want is for every user to have to store hundreds of MB of thumbnails of every image in their home directories.

I can use the "makexvpics" package to generate the .xvpics directories in lieu of gimp, but that's only half the battle.

Is there any way to make gimp 2.0's "open file" dialog read the .xvpics thumbnail if one exists, then fall back to the ~/.thumbnails version if it's not there (or even vice versa)? This seems like a logical feature, given gimp's history of creating .xvpics directories.

If not, I'm gonna have to drop back to gimp v1 or switch to some other package that still uses .xvpics thumbs.

-- Obi-Wan

Sven Neumann
2004-04-18 12:15:29 UTC (about 20 years ago)

Gimp 2.0 reading .xvpics

Hi,

Obi-Wan writes:

I recently "upgraded" to gimp 2.0. After a bit of confusion, I finally realized that gimp now stores its thumbnails in ~/.thumbnails rather than in ./.xvpics. This is an enormous annoyance for me, since I have many CD's of images, all organized in directories with thumbs stored in the respective .xvpics directories so that they don't have to be regenerated each time a user pops the CD into their drive.

The new ~/.thumbnails setup is unacceptable for this use, since the last thing I want is for every user to have to store hundreds of MB of thumbnails of every image in their home directories.

The thumbnail spec could easily be extended to support this. I've already written the libgimpthumb API in a way that allows thumbnails to be read from other places than ~/.thumbnails.

Now this is a good chance for you to contribute. Please make yourself familiar with the thumbnail managing spec:

http://triq.net/~jens/thumbnail-spec/index.html

Then subscribe to the mailing-list (xdg-list@freedesktop.org) where the specs are being discussed and bring up your issues with the spec. See http://freedesktop.org/mailman/listinfo/xdg

I am perfectly willing to change thumbnail handling but only after the spec has been changed. The spec isn't final yet and it shouldn't be a problem to see it extended.

Is there any way to make gimp 2.0's "open file" dialog read the .xvpics thumbnail if one exists, then fall back to the ~/.thumbnails version if it's not there (or even vice versa)? This seems like a logical feature, given gimp's history of creating .xvpics directories.

No, there's no way. The .xvpics concept sucked and the quality of the previews was unacceptable. So we dropped support for it.

Sven