tumme directory

tumme directory

[Chong Yidong]

I noticed that tumme.el has been checked into Emacs.  In the interest
of minimizing the number of dotfiles in the user's home directory, I
propose changing tumme-dir default from "~/.tumme/" to
"~/.emacs.d/tumme", and changing tumme-db-file, tumme-temp-image-file,
and tumme-gallery-dir accordingly.  Any objections?

Re: tumme directory

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> I noticed that tumme.el has been checked into Emacs.  In the
> interest of minimizing the number of dotfiles in the user's home
> directory, I propose changing tumme-dir default from "~/.tumme/" to
> "~/.emacs.d/tumme", and changing tumme-db-file,
> tumme-temp-image-file, and tumme-gallery-dir accordingly.  Any
> objections?

This would not make sense when tumme is also used with XEmacs.  A
similar objection would hold with .gnus and similar.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: tumme directory

[Mathias Dahl]

David Kastrup <dak@gnu.org> writes:

>> I noticed that tumme.el has been checked into Emacs.  In the
>> interest of minimizing the number of dotfiles in the user's home
>> directory, I propose changing tumme-dir default from "~/.tumme/" to
>> "~/.emacs.d/tumme", and changing tumme-db-file,
>> tumme-temp-image-file, and tumme-gallery-dir accordingly.  Any
>> objections?
>
> This would not make sense when tumme is also used with XEmacs.  A
> similar objection would hold with .gnus and similar.

I'm not sure tumme would work with XEmacs. If IIRC XEmacs handled
inserting of images differently. Of course, it could probably be
fixed, but I just wanted to mention that such a limitation currently
exists. I don't use XEmacs.

I would not have anything against changing the default value to
"~/.emacs.d/tumme" if people find it makes their home directory less
cluttered.

Re: tumme directory

[Richard M. Stallman]

    This would not make sense when tumme is also used with XEmacs.

That isn't a crucial problem for us.

Re: tumme directory

[Richard M. Stallman]

    I noticed that tumme.el has been checked into Emacs.  In the interest
    of minimizing the number of dotfiles in the user's home directory, I
    propose changing tumme-dir default from "~/.tumme/" to
    "~/.emacs.d/tumme", and changing tumme-db-file, tumme-temp-image-file,
    and tumme-gallery-dir accordingly.  Any objections?

It should follow the usual convention of using .emacs.d
if it exists, etc., the same way other uses of .emacs.d do.

Re: tumme directory

[Mathias Dahl]

"Richard M. Stallman" <rms@gnu.org> writes:

>     I noticed that tumme.el has been checked into Emacs.  In the interest
>     of minimizing the number of dotfiles in the user's home directory, I
>     propose changing tumme-dir default from "~/.tumme/" to
>     "~/.emacs.d/tumme", and changing tumme-db-file, tumme-temp-image-file,
>     and tumme-gallery-dir accordingly.  Any objections?
>
> It should follow the usual convention of using .emacs.d
> if it exists, etc., the same way other uses of .emacs.d do.

Does that mean that we should accept Chong's fix? I know too little
about how .emacs.d is used.

Re: tumme directory

[Richard M. Stallman]

    > It should follow the usual convention of using .emacs.d
    > if it exists, etc., the same way other uses of .emacs.d do.

    Does that mean that we should accept Chong's fix? I know too little
    about how .emacs.d is used.

We should install a change to use .emacs.d
in accord with the standard conventions for using it.

Re: tumme directory

[Mathias Dahl]

"Richard M. Stallman" <rms@gnu.org> writes:

>     > It should follow the usual convention of using .emacs.d
>     > if it exists, etc., the same way other uses of .emacs.d do.
>
>     Does that mean that we should accept Chong's fix? I know too little
>     about how .emacs.d is used.
>
> We should install a change to use .emacs.d
> in accord with the standard conventions for using it.

Okay, than I guess I have to read up on what this standard is. Or,
maybe someone here will tell me... :)

Re: tumme directory

[Mattis]

>     > It should follow the usual convention of using .emacs.d
>     > if it exists, etc., the same way other uses of .emacs.d do.
>
>     Does that mean that we should accept Chong's fix? I know too little
>     about how .emacs.d is used.
>
> We should install a change to use .emacs.d
> in accord with the standard conventions for using it.

I have tried to understand what this convention is, and I don't like
to guess so I'd like to ask a simple yes/no question:

Should tumme's default thumbnail directory be ~/.tumme if there is no
~/.emacs.d and ~/.emacs.d/tumme, if it does? If yes, how do we let the
user configure this? Today, the configuration is as simple as this:

(defcustom tumme-dir "~/.tumme/"
  "*Directory where thumbnail images for are stored."
  :type 'string
  :group 'tumme)

How would it be changed?

Re: tumme directory

[Nick Roberts]

 > I have tried to understand what this convention is, and I don't like
 > to guess so I'd like to ask a simple yes/no question:
 > 
 > Should tumme's default thumbnail directory be ~/.tumme if there is no
 > ~/.emacs.d and ~/.emacs.d/tumme, if it does? If yes, how do we let the
 > user configure this? Today, the configuration is as simple as this:
 > 
 > (defcustom tumme-dir "~/.tumme/"
 >   "*Directory where thumbnail images for are stored."
 >   :type 'string
 >   :group 'tumme)
 > 
 > How would it be changed?

I don't know what the convention is either, but I would borrow from thumbs.el:

(defcustom thumbs-thumbsdir "~/.emacs.d/thumbs"
  "*Directory to store thumbnails."
  :type 'directory
  :group 'thumbs)

(defun thumbs-thumbsdir ()
  "Return the current thumbnails directory (from `thumbs-thumbsdir').
Create the thumbnails directory if it does not exist."
  (let ((thumbs-thumbsdir (file-name-as-directory
                           (expand-file-name thumbs-thumbsdir))))
    (unless (file-directory-p thumbs-thumbsdir)
      (make-directory thumbs-thumbsdir t)
      (message "Creating thumbnails directory"))
    thumbs-thumbsdir))

etc...

Nick

Re: tumme directory

[Mathias Dahl]

Nick Roberts <nickrob@snap.net.nz> writes:

> I don't know what the convention is either, but I would borrow from thumbs.el:
>
> (defcustom thumbs-thumbsdir "~/.emacs.d/thumbs"
>   "*Directory to store thumbnails."
>   :type 'directory
>   :group 'thumbs)
>
> (defun thumbs-thumbsdir ()
>   "Return the current thumbnails directory (from `thumbs-thumbsdir').
> Create the thumbnails directory if it does not exist."
>   (let ((thumbs-thumbsdir (file-name-as-directory
>                            (expand-file-name thumbs-thumbsdir))))
>     (unless (file-directory-p thumbs-thumbsdir)
>       (make-directory thumbs-thumbsdir t)
>       (message "Creating thumbnails directory"))
>     thumbs-thumbsdir))

That looks OK to me, as long as it is OK to "force" this .emacs.d
directory upon the user. Someone said "use .emacs.d if it exists" and
I interpreted that as one should always use it if it exists, else use
another one.

Again, I think the code abobe looks good.

Re: tumme directory

[Stefan Monnier]

> (defcustom tumme-dir "~/.tumme/"
>   "*Directory where thumbnail images for are stored."
>   :type 'string
>   :group 'tumme)

A grep for ".emacs.d" in the Lisp sources will probably give you
some answer.  What I'd do is:

(defcustom tumme-dir
  (cond
    ((file-directory-p "~/.tumme/") "~/.tumme/")
    ((file-directory-p "~/.emacs.d/") "~/.emacs.d/tumme/")
    (t "~/.tumme/"))
  "Directory where thumbnail images for are stored."
  :type 'string
  :group 'tumme)


-- Stefan

Re: tumme directory

[Mattis]

> A grep for ".emacs.d" in the Lisp sources will probably give you
> some answer.  What I'd do is:
>
> (defcustom tumme-dir
>   (cond
>     ((file-directory-p "~/.tumme/") "~/.tumme/")
>     ((file-directory-p "~/.emacs.d/") "~/.emacs.d/tumme/")
>     (t "~/.tumme/"))
>   "Directory where thumbnail images for are stored."
>   :type 'string
>   :group 'tumme)

:)

I just commited the changed suggested by Nick. Now it works the same
way thumbs.el does. It could easily be changed again though, but this
seems to work nicely. I just moved my thumbnails to the new dir and it
works well:

 $ mkdir ~/.emacs.d/tumme
 $ mv ~/.tumme/*.thumb.jpg ~/.emacs.d/tumme/

Re: tumme directory

[Juri Linkov]

> I just commited the changed suggested by Nick. Now it works the same
> way thumbs.el does. It could easily be changed again though, but this
> seems to work nicely. I just moved my thumbnails to the new dir and it
> works well:
>
>  $ mkdir ~/.emacs.d/tumme
>  $ mv ~/.tumme/*.thumb.jpg ~/.emacs.d/tumme/

Do you have a TODO item for sharing thumbnails with other GNU programs?

I could send you command examples that produce impressive results.
The thumbnail PNG file sizes are much smaller than generated by other
programs, but still are readable by them.  For example, gqview has
noticeable delays while reading its own thumbnails generated earlier.
But when I regenerate them with a set of PNG optimizing utilities,
it reads them instantly.  And disk space saving is almost three-fold
which is significant with a large thumbnail collection.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: tumme directory

[Mathias Dahl]

Juri Linkov <juri@jurta.org> writes:

> Do you have a TODO item for sharing thumbnails with other GNU
> programs?

It's not on the list, no. We have discussed this before and my
standpoint is that I like the idea of following this standard, but I
cannot see through if there would be any drawbacks from doing this.

> I could send you command examples that produce impressive results.

Sure!

> The thumbnail PNG file sizes are much smaller than generated by other
> programs, but still are readable by them.

Are they still conforming to the standard?

> But when I regenerate them with a set of PNG optimizing utilities,
> it reads them instantly.  And disk space saving is almost three-fold
> which is significant with a large thumbnail collection.

It seems to me that you should dive into tumme.el and start hacking :)

Re: tumme directory

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> I could send you command examples that produce impressive results.
> The thumbnail PNG file sizes are much smaller than generated by other
> programs, but still are readable by them.

Er, can you at least give a hint what you used...?

-miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: tumme directory

[Juri Linkov]

>> I could send you command examples that produce impressive results.
>> The thumbnail PNG file sizes are much smaller than generated by other
>> programs, but still are readable by them.
>
> Er, can you at least give a hint what you used...?

The first program in the sequence I used was `convert':

  convert -size 128x128 image.jpg -thumbnail 128x128 ~/.thumbnails/normal/md5.png

The second was `pngnq'.  It optimizes PNG images using the neural net based
color quantization algorithm.  It can quantize images down to 256 colors
with much better results than other color optimization algorithms.
So, for instance, it can reduce a thumbnail PNG file generated by
`convert' with the size 18995 down to 8280 bytes almost without affecting
the quality of the original image.

The third program was `pngcrush'.  It optimizes the compression trying
various compression levels and selecting the best one.  It reduces the
size of the sample file mentioned above further down to 6877 bytes.

`pngcrush' also can add PNG textual chunks with the information
necessary for other GNU programs that support the Thumbnail Managing Standard
to use them.

All programs are available as Debian packages (imagemagick.deb, pngnq.deb,
pngcrush.deb).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: tumme directory

[Juri Linkov]

>> The thumbnail PNG file sizes are much smaller than generated by other
>> programs, but still are readable by them.
>
> Are they still conforming to the standard?

Yes.  `pngcrush' can add textual chunks (either compressed or not) with
the prefix `Thumb::Image::' that make generated thumbnails perfectly
readable by other programs.

However, there is one problem with textual chunks added by `convert'.
Its `-set attr value' command option adds only compressed textual chunks,
and GQview (a GTK image viewer) can't read compressed chunks.  So if
`pngcrush' is not installed on the system, then thumbnails we can produce
with `convert' will be unreadable by GQview.  This is not a problem
since when GQview can't recognize the thumbnail it overwrites it with its
own version.  A later versions of GQview might fix this shortcoming.
And Gimp reads compressed chunks just fine.

>> But when I regenerate them with a set of PNG optimizing utilities,
>> it reads them instantly.  And disk space saving is almost three-fold
>> which is significant with a large thumbnail collection.
>
> It seems to me that you should dive into tumme.el and start hacking :)

Well.  I've added support for the Thumbnail Managing Standard to tumme.el.
It adds all required attributes, but still misses some additional attributes
(like original dimensions).  Since the same attributes should be displayed
in the *tumme* buffer, I expect more discussion how to extract these
attributes from original images.  I'd like to add

(defcustom tumme-cmd-read-info-program
  "identify"
  "*Executable used to get information about original images.
Used together with `tumme-cmd-read-info-options'."
  :type 'string
  :group 'tumme)

(defcustom tumme-cmd-read-info-options
  "%p -format \"%%f %%wx%%h %%b\n\" %f"
  "*Format of command used to get information about original images.
Available options are %p which is replaced by
`tumme-cmd-read-info-program', %f which is replaced by the file name
of the original image."
  :type 'string
  :group 'tumme)

and use it to extract image information.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: tumme directory

[Mathias Dahl]

> The first program in the sequence I used was `convert':
> ...
> The second was `pngnq'.  It optimizes PNG images using the neural net based
> color quantization algorithm.  It can quantize images down to 256 colors
> with much better results than other color optimization algorithms.

We should mention that using `pngnq' generates uglier thumbnails. :)
Really, they are. IMHO, of course. But I guess it is the price we have
to pay for getting the file size down. Personally, I will probably
stick to using JPEG thumbnails until I feel an urge to be able to
reuse the thumbnails tumme creates in other programs, which is what
the Thumbnail Managing Standard is about, basically.

Re: tumme directory

[Mathias Dahl]

> It adds all required attributes, but still misses some additional attributes
> (like original dimensions).  Since the same attributes should be displayed
> in the *tumme* buffer, I expect more discussion how to extract these
> attributes from original images.  I'd like to add
>
> (defcustom tumme-cmd-read-info-program
>   "identify"
>   "*Executable used to get information about original images.
> Used together with `tumme-cmd-read-info-options'."
>   :type 'string
>   :group 'tumme)
>
> (defcustom tumme-cmd-read-info-options
>   "%p -format \"%%f %%wx%%h %%b\n\" %f"
>   "*Format of command used to get information about original images.
> Available options are %p which is replaced by
> `tumme-cmd-read-info-program', %f which is replaced by the file name
> of the original image."
>   :type 'string
>   :group 'tumme)
>
> and use it to extract image information.

That seems useful, I have nothing against adding it.