thumbs.el and transparency

thumbs.el and transparency

[Nick Roberts]

Currently thumbs.el stores all thumbnails as jpeg images.  Some image formats
such as xpm allow transparency (do M-x thumbs on emacs/etc/images, for
example).  When converted to jpeg a transparent background is converted to a
black one, so if the foreground is also black you see nothing.

There has been a discussion about formats before and I don't wan't to undo
any of that.  How about the change below which creates thumbnails in the
same format as the image when its xpm xbm or pbm, and uses jpeg otherwise?

Nick


*** thumbs.el	24 Jan 2006 22:18:53 +1300	1.26
--- thumbs.el	25 Jan 2006 13:57:39 +1300	
***************
*** 195,201 ****
  
  (defun thumbs-temp-file ()
    "Return a unique temporary filename for an image."
!   (format "%s%s-%s.jpg"
            (thumbs-temp-dir)
            thumbs-temp-prefix
            (thumbs-gensym "T")))
--- 195,201 ----
  
  (defun thumbs-temp-file ()
    "Return a unique temporary filename for an image."
!   (format "%s%s-%s."
            (thumbs-temp-dir)
            thumbs-temp-prefix
            (thumbs-gensym "T")))
***************
*** 236,249 ****
    (thumbs-cleanup-thumbsdir))
  
  (defun thumbs-call-convert (filein fileout action
! 				   &optional arg output-format action-prefix)
    "Call the convert program.
  FILEIN is the input file,
  FILEOUT is the output file,
  ACTION is the command to send to convert.
  Optional arguments are:
  ARG any arguments to the ACTION command,
- OUTPUT-FORMAT is the file format to output (default is jpeg),
  ACTION-PREFIX is the symbol to place before the ACTION command
                (defaults to '-' but can sometimes be '+')."
    (let ((command (format "%s %s%s %s \"%s\" \"%s:%s\""
--- 236,248 ----
    (thumbs-cleanup-thumbsdir))
  
  (defun thumbs-call-convert (filein fileout action
! 				   &optional arg action-prefix)
    "Call the convert program.
  FILEIN is the input file,
  FILEOUT is the output file,
  ACTION is the command to send to convert.
  Optional arguments are:
  ARG any arguments to the ACTION command,
  ACTION-PREFIX is the symbol to place before the ACTION command
                (defaults to '-' but can sometimes be '+')."
    (let ((command (format "%s %s%s %s \"%s\" \"%s:%s\""
***************
*** 252,258 ****
  			 action
  			 (or arg "")
  			 filein
! 			 (or output-format "jpeg")
  			 fileout)))
      (call-process shell-file-name nil nil nil "-c" command)))
  
--- 251,257 ----
  			 action
  			 (or arg "")
  			 filein
! 			 (symbol-name (thumbs-image-thumb-type filein))
  			 fileout)))
      (call-process shell-file-name nil nil nil "-c" command)))
  
***************
*** 269,284 ****
  smaller according to whether INCREMENT is 1 or -1."
    (let* ((buffer-read-only nil)
  	 (old thumbs-current-tmp-filename)
  	 (x (or size
! 		(thumbs-new-image-size thumbs-current-image-size increment)))
! 	 (tmp (thumbs-temp-file)))
      (erase-buffer)
      (thumbs-call-convert (or old thumbs-current-image-filename)
  			 tmp "sample"
  			 (concat (number-to-string (car x)) "x"
  				 (number-to-string (cdr x))))
      (save-excursion
!       (thumbs-insert-image tmp 'jpeg 0))
      (setq thumbs-current-tmp-filename tmp)))
  
  (defun thumbs-resize-image (width height)
--- 268,284 ----
  smaller according to whether INCREMENT is 1 or -1."
    (let* ((buffer-read-only nil)
  	 (old thumbs-current-tmp-filename)
+ 	 (type (thumbs-image-thumb-type thumbs-current-image-filename))
+ 	 (tmp (concat (thumbs-temp-file) (symbol-name type)))
  	 (x (or size
! 		(thumbs-new-image-size thumbs-current-image-size increment))))
      (erase-buffer)
      (thumbs-call-convert (or old thumbs-current-image-filename)
  			 tmp "sample"
  			 (concat (number-to-string (car x)) "x"
  				 (number-to-string (cdr x))))
      (save-excursion
!       (thumbs-insert-image tmp type 0))
      (setq thumbs-current-tmp-filename tmp)))
  
  (defun thumbs-resize-image (width height)
***************
*** 300,306 ****
    "Return a thumbnail name for the image IMG."
    (convert-standard-filename
     (let ((filename (expand-file-name img)))
!      (format "%s%08x-%s.jpg"
               (thumbs-thumbsdir)
               (sxhash filename)
               (subst-char-in-string
--- 300,306 ----
    "Return a thumbnail name for the image IMG."
    (convert-standard-filename
     (let ((filename (expand-file-name img)))
!      (format (concat "%s%08x-%s." (symbol-name (thumbs-image-thumb-type img)))
               (thumbs-thumbsdir)
               (sxhash filename)
               (subst-char-in-string
***************
*** 333,338 ****
--- 333,344 ----
  	((string-match ".*\\.png\\'" img) 'png)
  	((string-match ".*\\.tiff?\\'" img) 'tiff)))
  
+ (defun thumbs-image-thumb-type (img)
+   (let ((type (thumbs-image-type img)))
+     (if (and (image-type-available-p type) (memq type '(xpm xbm pbm)))
+ 	type
+       'jpeg)))
+ 
  (defun thumbs-file-size (img)
    (let ((i (image-size (find-image `((:type ,(thumbs-image-type img) :file ,img))) t)))
      (concat (number-to-string (round (car i)))
***************
*** 363,369 ****
    "Insert the thumbnail for IMG at point.
  If MARKED is non-nil, the image is marked."
    (thumbs-insert-image
!    (thumbs-make-thumb img) 'jpeg thumbs-relief marked)
    (add-text-properties (1- (point)) (point)
  		     `(thumb-image-file ,img
  		       help-echo ,(file-name-nondirectory img))))
--- 369,375 ----
    "Insert the thumbnail for IMG at point.
  If MARKED is non-nil, the image is marked."
    (thumbs-insert-image
!    (thumbs-make-thumb img) (thumbs-image-thumb-type img) thumbs-relief marked)
    (add-text-properties (1- (point)) (point)
  		     `(thumb-image-file ,img
  		       help-echo ,(file-name-nondirectory img))))
***************
*** 623,630 ****
      (push elt thumbs-marked-list)
      (let ((inhibit-read-only t))
        (delete-char 1)
!       (save-excursion
! 	(thumbs-insert-thumb elt t))))
    (when (eolp) (forward-char)))
  
  (defun thumbs-unmark ()
--- 629,635 ----
      (push elt thumbs-marked-list)
      (let ((inhibit-read-only t))
        (delete-char 1)
!       (thumbs-insert-thumb elt t)))
    (when (eolp) (forward-char)))
  
  (defun thumbs-unmark ()
***************
*** 636,646 ****
      (setq thumbs-marked-list (delete elt thumbs-marked-list))
      (let ((inhibit-read-only t))
        (delete-char 1)
!       (save-excursion
! 	(thumbs-insert-thumb elt nil))))
    (when (eolp) (forward-char)))
  
- 
  ;; cleaning of old temp files
  (mapc 'delete-file
        (directory-files (thumbs-temp-dir) t thumbs-temp-prefix))
--- 641,649 ----
      (setq thumbs-marked-list (delete elt thumbs-marked-list))
      (let ((inhibit-read-only t))
        (delete-char 1)
!       (thumbs-insert-thumb elt nil)))
    (when (eolp) (forward-char)))
  
  ;; cleaning of old temp files
  (mapc 'delete-file
        (directory-files (thumbs-temp-dir) t thumbs-temp-prefix))
***************
*** 653,666 ****
    (interactive "sAction: \nsValue: ")
    (let* ((buffer-read-only nil)
  	 (old thumbs-current-tmp-filename)
! 	 (tmp (thumbs-temp-file)))
      (erase-buffer)
      (thumbs-call-convert (or old thumbs-current-image-filename)
  			 tmp
  			 action
  			 (or arg ""))
      (save-excursion
!       (thumbs-insert-image tmp 'jpeg 0))
      (setq thumbs-current-tmp-filename tmp)))
  
  (defun thumbs-emboss-image (emboss)
--- 656,670 ----
    (interactive "sAction: \nsValue: ")
    (let* ((buffer-read-only nil)
  	 (old thumbs-current-tmp-filename)
! 	 (type (thumbs-image-thumb-type thumbs-current-image-filename))
! 	 (tmp (concat (thumbs-temp-file) (symbol-name type))))
      (erase-buffer)
      (thumbs-call-convert (or old thumbs-current-image-filename)
  			 tmp
  			 action
  			 (or arg ""))
      (save-excursion
!       (thumbs-insert-image tmp type 0))
      (setq thumbs-current-tmp-filename tmp)))
  
  (defun thumbs-emboss-image (emboss)

Re: thumbs.el and transparency

[Juri Linkov]

> Currently thumbs.el stores all thumbnails as jpeg images.  Some image formats
> such as xpm allow transparency (do M-x thumbs on emacs/etc/images, for
> example).  When converted to jpeg a transparent background is converted to a
> black one, so if the foreground is also black you see nothing.
>
> There has been a discussion about formats before and I don't wan't to undo
> any of that.  How about the change below which creates thumbnails in the
> same format as the image when its xpm xbm or pbm, and uses jpeg otherwise?

Could you change it to generate thumbnail images according to the
Thumbnail Managing Standard?

I now have 4 (!) thumbnail directories that all share the same purpose:

~/.emacs-thumbs
~/.emacs.d/thumbs
~/.thumbnails
~/.tumme

This is ridiculous.  Let's unify them all before the release.

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

Re: thumbs.el and transparency

[Nick Roberts]

 > > Currently thumbs.el stores all thumbnails as jpeg images.  Some image
 > > formats such as xpm allow transparency (do M-x thumbs on
 > > emacs/etc/images, for example).  When converted to jpeg a transparent
 > > background is converted to a black one, so if the foreground is also
 > > black you see nothing.
 > >
 > > There has been a discussion about formats before and I don't wan't to undo
 > > any of that.  How about the change below which creates thumbnails in the
 > > same format as the image when its xpm xbm or pbm, and uses jpeg otherwise?
 > 
 > Could you change it to generate thumbnail images according to the
 > Thumbnail Managing Standard?

I've not even heard of the Thumbnail Managing Standard.  Does it deal with
transparency?  Or is it a tangential question?

 > I now have 4 (!) thumbnail directories that all share the same purpose:
 > 
 > ~/.emacs-thumbs
 > ~/.emacs.d/thumbs
 > ~/.thumbnails
 > ~/.tumme
 > 
 > This is ridiculous.  Let's unify them all before the release.

I guess you can delete ~/.emacs-thumbs since thats no longer used by
thumbs.el.  Unifying them presupposes an understanding of the requirements.
By all accounts both thumbs and tumme are immature, so I'm not sure that we're
at that stage yet (I'm certainly not).

Nick

Re: thumbs.el and transparency

[Mathias Dahl]

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

>  > Could you change it to generate thumbnail images according to the
>  > Thumbnail Managing Standard?
>
> I've not even heard of the Thumbnail Managing Standard.  Does it deal with
> transparency?  Or is it a tangential question?

>From what I remember the standard uses PNG files only, and as far as I
know, PNG supports 

>  > I now have 4 (!) thumbnail directories that all share the same purpose:
>  > 
>  > ~/.emacs-thumbs
>  > ~/.emacs.d/thumbs
>  > ~/.thumbnails
>  > ~/.tumme
>  > 
>  > This is ridiculous.  Let's unify them all before the release.

I think it's fun! :)

Seriously, yes, it is kinda silly.

> Unifying them presupposes an understanding of the requirements.
> By all accounts both thumbs and tumme are immature, so I'm not sure that we're
> at that stage yet (I'm certainly not).

Before Richard allowed tumme.el into Emacs I tried to copy as many
features from thumbs.el as possible into tumme.el. Everything is not
there yet, but its on the todo-list.

Tumme and thumbs are in many ways very similar. They display
thumbnails of pictures, you can act on those thumbnails to do various
things (display, manipulate etc), they are somewhat integrated in
dired etc. Why do we need two packages for doing this? Of course, I
like tumme better, else I wouldn't have written it, but this isn't
some ego-thing, if someone thought that. I would be equally glad to
merge tumme stuff into thumbs and make that the main thumbnial/image
viewer, although for me that would be harder to do then the other way
around.

What I would like is much more input from a user's perspective, in
what areas tumme lacks compared to thumbs.

OK, I better stop now, don't want to start one of those long
threads...

Re: thumbs.el and transparency

[Nick Roberts]

 > Nick Roberts <nickrob@snap.net.nz> writes:
 > 
 > >  > Could you change it to generate thumbnail images according to the
 > >  > Thumbnail Managing Standard?
 > >
 > > I've not even heard of the Thumbnail Managing Standard.  Does it deal with
 > > transparency?  Or is it a tangential question?
 > 
 > From what I remember the standard uses PNG files only, and as far as I
 > know, PNG supports 

I think Richard's point is that we should only follow a standard that does
what we want.  If the Thumbnail Managing Standard doesn't deal with
transparency, then it seems unsuitable (the toolbar icons in the images
directory have transparency, for example). 

 > >  > I now have 4 (!) thumbnail directories that all share the same purpose:
 > >  > 
 > >  > ~/.emacs-thumbs
 > >  > ~/.emacs.d/thumbs
 > >  > ~/.thumbnails
 > >  > ~/.tumme
 > >  > 
 > >  > This is ridiculous.  Let's unify them all before the release.
 > 
 > I think it's fun! :)
 > 
 > Seriously, yes, it is kinda silly.

~/.emacs-thumbs is redundant now.  An individual user will probably just
use one primarily, so although not desirable, it may not be critical.

 > > Unifying them presupposes an understanding of the requirements.  By all
 > > accounts both thumbs and tumme are immature, so I'm not sure that we're
 > > at that stage yet (I'm certainly not).
 > 
 > Before Richard allowed tumme.el into Emacs I tried to copy as many
 > features from thumbs.el as possible into tumme.el. Everything is not
 > there yet, but its on the todo-list.

I mean unifying the thumbnail directories not thumbs.el and tumme.el.

 > Tumme and thumbs are in many ways very similar. They display
 > thumbnails of pictures, you can act on those thumbnails to do various
 > things (display, manipulate etc), they are somewhat integrated in
 > dired etc. Why do we need two packages for doing this?

We've covered this before: thumbs is simpler and best suited for basic tasks,
tumme for more complex ones.

 >                                                      Of course, I
 > like tumme better, else I wouldn't have written it, but this isn't
 > some ego-thing, if someone thought that. I would be equally glad to
 > merge tumme stuff into thumbs and make that the main thumbnial/image
 > viewer, although for me that would be harder to do then the other way
 > around.

I think they should be seen as complementary, not competing.

 > What I would like is much more input from a user's perspective, in
 > what areas tumme lacks compared to thumbs.

I don't think you'll get much feedback until Emacs is released.  tumme is a
specialist package and those on emacs-devel generally don't have that
specialism.

Nick

Re: thumbs.el and transparency

[Miles Bader]

2006/1/27, Nick Roberts <nickrob@snap.net.nz>:
> > Tumme and thumbs are in many ways very similar. They display
> > thumbnails of pictures, you can act on those thumbnails to do various
> > things (display, manipulate etc), they are somewhat integrated in
> > dired etc. Why do we need two packages for doing this?
>
> We've covered this before: thumbs is simpler and best suited for basic tasks,
> tumme for more complex ones.

I've not seen much consensus on that point (indeed the consensus
_seemed_ to say that tumme will replace thumbs), but I must admit: I
couldn't figure out how to make tumme do anything remotely useful in
the 10 minutes I spent trying it out.  There are lots of provocatively
named commands -- tumme-dired, tumme-gallery-generate,
tumme-slideshow-start -- but they never seem to _do_ anything other
than rearrange my windows a bit or display cryptic messages. 
Certainly I never saw an image show up.

I did get the impression that tumme is somewhat heavy-weight and modal
though, that many of the commands I tried _might_ have done something
if things (windows, buffers, files, etc) were setup properly.  Perhaps
it's simply a measure of tumme's immaturity that these commands didn't
make sure things were setup properly first, or at least display a
message to that effect.

Thumbs operation on the other hand is er, pretty obvious and
straight-forward, and it seems reasonably useful for what it does...
At the least, I got a buffer full of thumbnails with the first command
I tried.  I never did figure out how to make tumme do that.

-miles

--
Do not taunt Happy Fun Ball.

Re: thumbs.el and transparency

[Nick Roberts]

 > > We've covered this before: thumbs is simpler and best suited for basic
 > > tasks, tumme for more complex ones.
 > 
 > I've not seen much consensus on that point

I didn't say there was, but it was a viewpoint expressed by more than one
person.

 >                                                (indeed the consensus
 > _seemed_ to say that tumme will replace thumbs), 

I think that only Richard has said that, but since he makes the decisions and
they are not made by consensus, that may be more more crucial.  I would seem
odd though, given that tumme is a package that was added 18 months after the
start of the feature freeze.

 >                                                  but I must admit: I
 > couldn't figure out how to make tumme do anything remotely useful in
 > the 10 minutes I spent trying it out.
 ...
 > Thumbs operation on the other hand is er, pretty obvious and
 > straight-forward, and it seems reasonably useful for what it does...

That's almost a consensus then :)

Nick

Re: thumbs.el and transparency

[Richard M. Stallman]

I don't like having two different thumbnail viewing packages;
and the fact that they are not particularly coherent makes
it even worse, by increasing the amount that users have to learn
and remember in order to use them both.

What I want to see is one thumbnail viewing package
that is easy to learn to use in a simple fashion,
and is also powerful.

Re: thumbs.el and transparency

[Nick Roberts]

 > What I want to see is one thumbnail viewing package
 > that is easy to learn to use in a simple fashion,
 > and is also powerful.

Yes, and I want world peace and racial harmony.  Your expectations are always
high and IMHO, sometimes unrealistic, particularly if you want all this for
Emacs 22.

Nick

Re: thumbs.el and transparency

[Mathias Dahl]

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

>  > What I want to see is one thumbnail viewing package that is easy
>  > to learn to use in a simple fashion, and is also powerful.
>
> Yes, and I want world peace and racial harmony.  Your expectations
> are always high and IMHO, sometimes unrealistic, particularly if you
> want all this for Emacs 22.

But in this case that goal is not unrealistic at all, IMHO.

Re: thumbs.el and transparency

[Nick Roberts]

 > >  > What I want to see is one thumbnail viewing package that is easy
 > >  > to learn to use in a simple fashion, and is also powerful.
 > >
 > > Yes, and I want world peace and racial harmony.  Your expectations
 > > are always high and IMHO, sometimes unrealistic, particularly if you
 > > want all this for Emacs 22.
 > 
 > But in this case that goal is not unrealistic at all, IMHO.

You're right.  We can always further delay the release.

Nick

Re: thumbs.el and transparency

[Mathias Dahl]

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

>  > >  > What I want to see is one thumbnail viewing package that is easy
>  > >  > to learn to use in a simple fashion, and is also powerful.
>  > >
>  > > Yes, and I want world peace and racial harmony.  Your expectations
>  > > are always high and IMHO, sometimes unrealistic, particularly if you
>  > > want all this for Emacs 22.
>  > 
>  > But in this case that goal is not unrealistic at all, IMHO.
>
> You're right.  We can always further delay the release.

A bit unfair. but I guess I have myself to blame for not being as
specific as I should have been. What I meant was that adding/merging
the last few missing things from thumbs.el into tumme.el is quite
easy, once we decide what those things would be.

I know the release is eagerly awaited by all.

Re: thumbs.el and transparency

[Kim F. Storm]

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

>  > What I want to see is one thumbnail viewing package
>  > that is easy to learn to use in a simple fashion,
>  > and is also powerful.
>
> Yes, and I want world peace and racial harmony.  Your expectations are always
> high and IMHO, sometimes unrealistic, particularly if you want all this for
> Emacs 22.

Really? Nobody promised that emacs 22.1 would get released in 2006.  

Nothing indicates it will happen...  

E.g. tumme.el (which even the author says is "not complete") was added
in December 2005 -- who knows when _that_ is ready for release?  If
tumme is not ready for release, neither is emacs 22.1!

Actually, nobody promised that 22.1 will ever be released!

But who cares?  Somebody already released 23.1 months ago :-/

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: thumbs.el and transparency

[Juanma Barranquero]

On 1/30/06, Kim F. Storm <storm@cua.dk> wrote:

> E.g. tumme.el (which even the author says is "not complete") was added
> in December 2005 -- who knows when _that_ is ready for release?

I've been hesitating to add a tiny feature^ to bs.el... and suddenly
rcirc.el (75 KiB, 1,672 non-comment, non-blank lines) is included.
Then tumme.el (99 KiB, 1,783 lines). Then erc, with a whopping 35
files, 657 KiB and 13,818 lines of code... Note: I have nothing
against these packages, they seem to be fine pieces of code; it's just
that adding them does not seem very consistent with having a feature
freeze.

I suppose we're due for another round of the same discussion (or
perhaps not). Sorry, but the old arguments are progressively less and
less convincing to me. I'm unable to find a definition of "freeze"
that's both meaningful and representative of what's happening on the
Emacs CVS trunk.

                    /L/e/k/t/u


^Using header-line-format to display the *buffer-selection* header,
instead of (or additionally to) the current method of inserting the
headers as text in the selection buffer.

Re: thumbs.el and transparency

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

>> E.g. tumme.el (which even the author says is "not complete") was added
>> in December 2005 -- who knows when _that_ is ready for release?
>
> I've been hesitating to add a tiny feature^ to bs.el... and suddenly
> rcirc.el (75 KiB, 1,672 non-comment, non-blank lines) is included.
> Then tumme.el (99 KiB, 1,783 lines). Then erc, with a whopping 35
> files, 657 KiB and 13,818 lines of code... Note: I have nothing
> against these packages, they seem to be fine pieces of code; it's just
> that adding them does not seem very consistent with having a feature
> freeze.

Maybe the rationale was that the CVS tree was getting a little too
stable ;-)

Re: thumbs.el and transparency

[Juanma Barranquero]

On 1/30/06, Chong Yidong <cyd@stupidchicken.com> wrote:

> Maybe the rationale was that the CVS tree was getting a little too
> stable ;-)

Perhaps, but, it was? Really?

I come back after a few months hiatus, fire up Emacs... and I
immediately stumble upon three or four problems (mostly small, but
problems nonetheless):

  - My modeline does not look right (apparently some new mode-line
faces were introduced)
  - With cua-mode, I suddenly can not force `transient-mark-mode' to
stay nil (I'm still investigating that one)
 - On my configuration at home, font-locked text with a bold face seem
to be being "shaved" a few pixels on the right (so the last char of
the string, keyword, etc. looks weird)
  - I got warnings on loading .emacs.el because bindings for [home]
and [end] have changed...

I would've expected to start Emacs and find nothing changed, other
than a few bugs missing...

--
                    /L/e/k/t/u

Re: thumbs.el and transparency

[Chong Yidong]

> I would've expected to start Emacs and find nothing changed, other
> than a few bugs missing...

I think we've already established that there is no sort of feature
freeze going on.  Holding your breath waiting for the Emacs 22 release
would be a fatal move.

CUA-related problem (was: Re: thumbs.el and transparency)

[Kim F. Storm]

Juanma Barranquero <lekktu@gmail.com> writes:

>   - With cua-mode, I suddenly can not force `transient-mark-mode' to
> stay nil (I'm still investigating that one)

I don't recall changing anything like that.

What setting do you use to force it off?
     cua-highlight-region-shift-only=t ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: CUA-related problem (was: Re: thumbs.el and transparency)

[Juanma Barranquero]

> I don't recall changing anything like that.
>
> What setting do you use to force it off?
>      cua-highlight-region-shift-only=t ?

Perhaps it is a misunderstanding on my part, but I find this weird:

ELISP> (setq transient-mark-mode nil)
nil
ELISP> transient-mark-mode
nil
ELISP> (cua-mode 1)
t
ELISP> transient-mark-mode
t
ELISP> (cua-selection-mode 1)
t
ELISP> transient-mark-mode
t
ELISP> (setq transient-mark-mode nil)
nil
ELISP> transient-mark-mode
t
ELISP> (setq cua-highlight-region-shift-only t)
t
ELISP> transient-mark-mode
t
ELISP> (setq transient-mark-mode nil)
nil
ELISP> transient-mark-mode
t
ELISP>

Is that the expected behaviour?

--
                    /L/e/k/t/u

Re: CUA-related problem (was: Re: thumbs.el and transparency)

[Luc Teirlinck]

Juanma Barranquero wrote:

   Is that the expected behaviour?

Obviously, Kim should say whether it is intended behavior, but it is
certainly expected and _looks_ intentional.

cua-mode adds cua--post-command-handler to post-command-hook.  This
calls cua--post-command-handler-1 which very explicitly sets
transient-mark-mode to whatever cua-mode wants to set it (which is not
_always_ t).

The doc of cua-highlight-region-shift-only also suggests that it is
intentional.

Sincerely,

Luc.

Re: CUA-related problem (was: Re: thumbs.el and transparency)

[Juanma Barranquero]

On 1/31/06, Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> The doc of cua-highlight-region-shift-only also suggests that it is
> intentional.

c-h-r-s-o's doc talks about what happens when the region is marked
with or without shifted movement keys. I don't find weird that
cua-mode manipulates transient-mark-mode; just that it forces it to be
t at all times.

--
                    /L/e/k/t/u

Re: thumbs.el and transparency

[Richard M. Stallman]

      - With cua-mode, I suddenly can not force `transient-mark-mode' to
    stay nil (I'm still investigating that one)

That must just be a bug.  Have you tracked it down?

     - On my configuration at home, font-locked text with a bold face seem
    to be being "shaved" a few pixels on the right (so the last char of
    the string, keyword, etc. looks weird)

That seems strange.  Can you send a clear bug report.

      - I got warnings on loading .emacs.el because bindings for [home]
    and [end] have changed...

Yes, we fixed a bug that required making new commands for these.

Re: thumbs.el and transparency

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

On 1/31/06, Richard M. Stallman <rms@gnu.org> wrote:

> That must just be a bug.  Have you tracked it down?

Kim and Luc are taking a look at it.

> That seems strange.  Can you send a clear bug report.

My face for font-lock-function-definition-face (for example) has
everything "unspecified" except the color (deepskyblue) and the weight
(bold). When I view a font-locked file, the function names show as
expected (in the right color and weight), but the last character of
the function name is truncated at the right, by a few pixels.

The problem is not specific to font-locking; I use some bold fields on
the modeline and they're suffering the same problem.


--
                    /L/e/k/t/u

[-- Attachment #2: function.jpg --]
[-- Type: image/jpeg, Size: 3671 bytes --]

[-- Attachment #3: modeline.JPG --]
[-- Type: image/jpeg, Size: 1116 bytes --]

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: thumbs.el and transparency

[Luc Teirlinck]

Juanma Barranquero wrote:

   Kim and Luc are taking a look at it.

Well, Kim will need to fix it _if_ it needs fixing.  I do not even use
cua-mode.  All I did was track down the place where cua-mode forces
transient-mark-mode to the value cua-mode apparently wants.  But I do
not even know whether it is intentional (although I believe it is).

Sincerely,

Luc.

Re: thumbs.el and transparency

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Juanma Barranquero wrote:
>
>    Kim and Luc are taking a look at it.
>
> Well, Kim will need to fix it _if_ it needs fixing.  I do not even use
> cua-mode.  All I did was track down the place where cua-mode forces
> transient-mark-mode to the value cua-mode apparently wants.  But I do
> not even know whether it is intentional (although I believe it is).

Luc, thanks for the precise analysis!!

Yes, cua-mode relies on transient-mark-mode to highlight the selected
region, but since it uses other methods to highlight a selected
rectangle, it needs to turn off transient-mark-mode temporarily when
it highlights a rectangle.  That is why it automatically turns it
(back) on when no rectangle is selected.

There is no option to disable transient-mark-mode completely with cua,
but isn't cua-highlight-region-shift-only sufficient?

Of course, cua could turn on transient-mark-mode just in case
mark-active is t, but that wouldn't make any difference, as
transient-mark-mode is only looked at when mark-active is t.

BTW, the code in question hasn't changed since 2002, so I'm puzzled
why you think this is a new "problem"!?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: thumbs.el and transparency

[Luc Teirlinck]

Kim Storm wrote:

   BTW, the code in question hasn't changed since 2002, so I'm puzzled
   why you think this is a new "problem"!?

I do not think it is a new problem.  An old Emacs CVS version from
February 7, 2005, which I still have around, apparently exhibits the
same behavior.  But apparently Juanma believes it is a new problem.

Maybe you could add something to the end of the cua-mode docstring
saying that trying to en/disable Transient Mark mode directly while
cua-mode is enabled has no effect, because cua-mode overrides it.

Sincerely,

Luc.

Re: thumbs.el and transparency

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kim Storm wrote:
>
>    BTW, the code in question hasn't changed since 2002, so I'm puzzled
>    why you think this is a new "problem"!?
>
> I do not think it is a new problem.  An old Emacs CVS version from
> February 7, 2005, which I still have around, apparently exhibits the
> same behavior.  But apparently Juanma believes it is a new problem.
>
> Maybe you could add something to the end of the cua-mode docstring
> saying that trying to en/disable Transient Mark mode directly while
> cua-mode is enabled has no effect, because cua-mode overrides it.

Good idea.  I just added this.

Notice that on the Options menu, the "Active Region highlighting" option
(transient-mark-mode) is shaded (and enabled) when cua mode is enabled.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: thumbs.el and transparency

[Luc Teirlinck]

Kim Storm wrote:

   > Maybe you could add something to the end of the cua-mode docstring
   > saying that trying to en/disable Transient Mark mode directly while
   > cua-mode is enabled has no effect, because cua-mode overrides it.

   Good idea.  I just added this.

The docstring already mentioned in the first paragraph that enabling
CUA mode does enable Transient mark mode.  I believe that the
potential confusion that remains is that people might think that if
they do not like this, they can override this aspect of CUA mode by
turning off Transient Mark mode back again after enabling CUA mode.
That was apparently what Juanma expected.  So I believe that the
following might be clearer:

*** cua-base.el	01 Feb 2006 08:00:14 -0600	1.66
--- cua-base.el	01 Feb 2006 19:58:57 -0600	
***************
*** 1395,1401 ****
  CUA bindings, or `cua-prefix-override-inhibit-delay' to change
  the prefix fallback behavior.
  
! CUA enables `transient-mark-mode' to highlight the region; if you
  only want to highlight the region when it is selected using a
  shifted movement key, set `cua-highlight-region-shift-only'."
    :global t
--- 1395,1402 ----
  CUA bindings, or `cua-prefix-override-inhibit-delay' to change
  the prefix fallback behavior.
  
! CUA mode manages Transient Mark mode internally.  Trying to disable
! Transient Mark mode while CUA mode is enabled does not work; if you
  only want to highlight the region when it is selected using a
  shifted movement key, set `cua-highlight-region-shift-only'."
    :global t

Re: thumbs.el and transparency

[Juanma Barranquero]

On 2/2/06, Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> people might think that if
> they do not like this, they can override this aspect of CUA
> mode by turning off Transient Mark mode back again after
> enabling CUA mode. That was apparently what Juanma expected.

Yeah, more or less. I don't use CUA for the C-z/C-x/C-x keybindings or
the shift-selection, but mostly for the wonderful rectangle support.

--
                    /L/e/k/t/u

Re: thumbs.el and transparency

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> The docstring already mentioned in the first paragraph that enabling
> CUA mode does enable Transient mark mode.  I believe that the
> potential confusion that remains is that people might think that if
> they do not like this, they can override this aspect of CUA mode by
> turning off Transient Mark mode back again after enabling CUA mode.
> That was apparently what Juanma expected.  So I believe that the
> following might be clearer:

Indeed.  Please install your change.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: thumbs.el and transparency

[Luc Teirlinck]

>From my previous reply:

   Maybe you could add something to the end of the cua-mode docstring
   saying that trying to en/disable Transient Mark mode directly while
   cua-mode is enabled has no effect, because cua-mode overrides it.

As well as mention which other (if any) customizable variables or
minor modes people are not supposed to play around with while Cua mode
is enabled.

Sincerely,

Luc.

Re: thumbs.el and transparency

[Juanma Barranquero]

On 2/1/06, Kim F. Storm <storm@cua.dk> wrote:

> BTW, the code in question hasn't changed since 2002, so I'm puzzled
> why you think this is a new "problem"!?

I honestly don't know. I suddenly had the feeling that something was
different, but I think my fingers must have been typing C-M-S-a and
C-M-S-e instead of C-M-a and C-M-e.

So, sorry for the noise.

--
                    /L/e/k/t/u

Re: thumbs.el and transparency

[Richard M. Stallman]

Adding a package that has been working fine on its own
is a pretty safe change.

Re: thumbs.el and transparency

[Juanma Barranquero]

> Adding a package that has been working fine on its own
> is a pretty safe change.

Perhaps. Or perhaps we will find during the pretest (should it happen)
that it has its own set of problems.

But that does not invalidate what I said: we have lengthy discussions
for small featurettes involving twenty lines of code, and suddenly we
add almost 14,000. That's not a freeze. Or, if *is* a freeze by your
definition, I don't find it a very consistent definition.

I have nothing against erc, nor against its inclusion in Emacs. I just
would like to see a real freeze, and a planned date of release (not
necessarily public), even if we miss it by a mile. We've "missed" it
already by two or three years, I'd say.

A few months ago I joked that I would eat my Emacs reference card if
we get to release 22.1 before 2007. Suddenly it seems less and less
like a joke to me...

--
                    /L/e/k/t/u

Re: thumbs.el and transparency

[Sascha Wilde]

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

> What I want to see is one thumbnail viewing package
> that is easy to learn to use in a simple fashion,
> and is also powerful.

I would like to see a command like `thumbs' in tumme, a quick way to
open a directory and display thumbs for everything in it in one step.
Having to setup tumme key bindings, starting tumme-dired, marking
files and pressing C-t d, just to get a thumbnailed look at a dir is
to cumbersome.

Another important thing:
The comment in tumme states:

;; * In order to work well, `tumme' require that all your images have
;; unique names.  The reason is the way thumbnail file names are
;; generated.  I will probably not fix this problem as my images all
;; have unique names.

if this is still true, this would be a _very_ serious limitation.

cheers
sascha
-- 
Sascha Wilde : "Lies, was ich meine, nicht, was ich schreibe."
             : (Urs Traenkner in de.alt.admin)

Re: thumbs.el and transparency

[Mathias Dahl]

Sascha Wilde <wilde@sha-bang.de> writes:

> I would like to see a command like `thumbs' in tumme, a quick way to
> open a directory and display thumbs for everything in it in one
> step.  Having to setup tumme key bindings, starting tumme-dired,
> marking files and pressing C-t d, just to get a thumbnailed look at
> a dir is to cumbersome.

That would be quite easy to implement. The reason it is not there is
that I never needed it. I have nothing against adding it and I know
that Richard too want this.

Such a command would need to check how many images the directory
contains and warn the user if the number of files exeeds a certain,
configurable, limit (say 50 or something like that as default).

> Another important thing:
> The comment in tumme states:
>
> ;; * In order to work well, `tumme' require that all your images have
> ;; unique names.  The reason is the way thumbnail file names are
> ;; generated.  I will probably not fix this problem as my images all
> ;; have unique names.
>
> if this is still true, this would be a _very_ serious limitation.

That was once true and the reason was that the thumbnail file names
used the original file name as part of it. That is now changed, so
that comment should be removed.

It seems I should get myself CVS access and start doing some
changes...

Re: thumbs.el and transparency

[Miles Bader]

2006/1/29, Mathias Dahl <brakjoller@gmail.com>:
> Such a command would need to check how many images the directory
> contains and warn the user if the number of files exeeds a certain,
> configurable, limit (say 50 or something like that as default).

How hard would it be to have it do the thumb-ification in the
background, so that it wouldn't really matter if there were many image
files (the user would see them being added, and could use those that
were available)?  This is the way many image browsing programs work,
and it's a very nice way of dealing with the delay of
thumb-conversion.

-Miles
--
Do not taunt Happy Fun Ball.

Re: thumbs.el and transparency

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> 2006/1/29, Mathias Dahl <brakjoller@gmail.com>:
>> Such a command would need to check how many images the directory
>> contains and warn the user if the number of files exeeds a certain,
>> configurable, limit (say 50 or something like that as default).
>
> How hard would it be to have it do the thumb-ification in the
> background, so that it wouldn't really matter if there were many image
> files (the user would see them being added, and could use those that
> were available)?  This is the way many image browsing programs work,
> and it's a very nice way of dealing with the delay of
> thumb-conversion.

I'd like to mention how preview-latex does this sort of background
rendering in order to have it least offensive: it keeps a queue of
images that still may have to be processed.  Then it uses a
conditional display property (the importance is not the condition,
which needs to evaluate to t, but the side effect from evaluating the
condition) for showing on-screen stuff first with the help of the
following two functions:

(defun preview-add-urgentization (fun ov &rest rest)
  "Cause FUN (function call form) to be called when redisplayed.
FUN must be a form with OV as first argument,
REST as the remainder, returning T."
  (let ((dispro (overlay-get ov 'display)))
    (unless (eq (car dispro) 'when)
      (overlay-put ov 'display `(when (,fun ,ov ,@rest)  . ,dispro)))))

(defun preview-remove-urgentization (ov)
  "Undo urgentization of OV by `preview-add-urgentization'.
Returns the old arguments to `preview-add-urgentization'
if there was any urgentization."
  (let ((dispro (overlay-get ov 'display)))
    (when (eq (car dispro) 'when)
      (prog1
	  (car (cdr dispro))
	(overlay-put ov 'display (cdr (cdr dispro)))))))

(this is in preview/prv-emacs.el, since the variant for XEmacs looks
quite different).

This is used as

  (preview-add-urgentization #'preview-gs-urgentize ov run-buffer)

when the overlay is pushed into preview-gs-queue.
preview-gs-urgentize then does the following:

(defun preview-gs-urgentize (ov buff)
  "Make a displayed overlay render with higher priority.
This function is used in fake conditional display properties
for reordering the conversion order to prioritize on-screen
images.  OV is the overlay in question, and BUFF is the
Ghostscript process buffer where the buffer-local queue
is located."
  ;; It does not matter that ov gets queued twice in that process: the
  ;; first version to get rendered will clear the 'queued property.
  ;; It cannot get queued more than twice since we remove the
  ;; conditional display property responsible for requeuing here.
  ;; We don't requeue if the overlay has been killed (its buffer made
  ;; nil).  Not necessary, but while we are checking...
  ;; We must return t.
  (preview-remove-urgentization ov)
  (when (and (overlay-get ov 'queued)
	     (overlay-buffer ov))
    (with-current-buffer buff
      (push ov preview-gs-queue)))
  t)


Ok, the net effect is that stuff that is on-screen will get pushed to
the front of the queue.  That means when moving around in the buffer,
first the on-screen stuff gets done, afterwards the non-visible stuff
gets done in background.

I think this would be a reasonable way of proceeding with large
directory listings, too.

If it is any help: those parts are written by myself and a part of
AUCTeX for which I have assigned papers.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: thumbs.el and transparency

[Mathias Dahl]

Miles Bader <miles@gnu.org> writes:

> How hard would it be to have it do the thumb-ification in the
> background, so that it wouldn't really matter if there were many
> image files (the user would see them being added, and could use
> those that were available)?  This is the way many image browsing
> programs work, and it's a very nice way of dealing with the delay of
> thumb-conversion.

I don't know how hard that would be. Richard wanted it too so it is on
tumme's todo-list. I have currently no idea on how to do it, but I saw
a later post with some ideas, which I will look into.

Re: thumbs.el and transparency

[David Kastrup]

Mathias Dahl <brakjoller@gmail.com> writes:

> It seems I should get myself CVS access and start doing some
> changes...

That's the most sensible course of action, anyway, since it causes
small efforts for small changes and fixes.  When the principal
author/maintainer has to ask for every small bit to be put into the
CVS, this tends to cause more work and delay than desirable.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: thumbs.el and transparency

[Mathias Dahl]

David Kastrup <dak@gnu.org> writes:

>> It seems I should get myself CVS access and start doing some
>> changes...
>
> That's the most sensible course of action, anyway, since it causes
> small efforts for small changes and fixes.  When the principal
> author/maintainer has to ask for every small bit to be put into the
> CVS, this tends to cause more work and delay than desirable.

How do one get write access to CVS Emacs then? I am quite incompetent
when it comes to using CVS, but I am sure I can learn. Or, I can post
the results here and sometime else can check it in? (I don't want to
give someone else work but I don't want to mess upp either).

Re: thumbs.el and transparency

[Mathias Dahl]

Miles Bader <miles@gnu.org> writes:

> I've not seen much consensus on that point (indeed the consensus
> _seemed_ to say that tumme will replace thumbs), but I must admit: I
> couldn't figure out how to make tumme do anything remotely useful in
> the 10 minutes I spent trying it out.  There are lots of provocatively
> named commands -- tumme-dired, tumme-gallery-generate,
> tumme-slideshow-start -- but they never seem to _do_ anything other
> than rearrange my windows a bit or display cryptic messages. 
> Certainly I never saw an image show up.

Again, I it is a bit unpolished and the documentation (the Commentary
in tumme.el) could need some work.

This is what I did (running under Windows XP):

Start emacs -q

(load-file "~/elisp/tumme.el") ;; My emacs does not have tumme.el

(tumme-setup-dired-keybindings) ;; Well...

M-x tumme-dired RET some-directory-with-images RET

Some might think that what tumme does now is very intrusive, it sets
up a window configuration that I personally think is suitable for the
task at hand. Whatever your reaction is, please follow:

If all goes well, you should have a window config like this:

     +---------+---------+
     |         |         |
     |         |    2    |
     |         |         |
     |    1    +---------+
     |         |         |
     |         |    3    |
     |         |         |
     +---------+---------+

You need not have a window configuration like this, you can have only
one window if you want, but I find it easier to work with this
setup. You can have each buffer in its own frame or keep the buffers
all in one frame. It'll be a lot of jumping back and forth if you only
use one window though.

1 is a dired listing of the dir you specified. 2 is where the
thumbnails will be displayed (buffer is in tumme-mode) and 3 is where
a sized version of the image will be displayed.

In dired window/buffer, mark some files.

Next, press C-t d (`tumme-display-thumbs'). Tumme should now generate
thumbnail images and display them in the thumbnail buffer.

To jump to the thumbnail buffer, either use TAB (switched back and
worth between dired and thumbnail mode) or C-x o, as you are probably
used to.

Use the arrow keys to move around the thumbnails. To display an image,
press RET on the thumbnail. This will display a sized version in the
display buffer. Move some more, press RET again to change the
displayed image.

Convenience commands: use SPC to advanced and display, use DEL
(backspace) to back up and display previous picture. The mouse can
also be used to display the images.

If you enable "tracking of movement" (its in the Tumme menu), the
cursor in the dired buffer will "follow" the cursor movement you do in
the thumbnail buffer.

If you want to see the full size image, either use C-x o to jump to
the display buffer and then press "f" (full) there, or press C-return
to display image in an external viewer (which must be
configured). Press "s" to again display a sized version.

I won't go into describing more commands available in the thumbnail or
dired buffer (mark-commands, tag commands etc), they should all be
seen from the Tumme menu.

I would love to have feedback on how to make this process easier on
the user, especially how to get him/her up to speed quicker. All basic
stuff is in there, building "conveniece-commands" is just a matter of
wrapping some of those basic methods in new commands.

Re: thumbs.el and transparency

[Nick Roberts]

 > Again, I it is a bit unpolished and the documentation (the Commentary
 > in tumme.el) could need some work.
 > 
 > This is what I did (running under Windows XP):
 > 
 > Start emacs -q
 > 
 > (load-file "~/elisp/tumme.el") ;; My emacs does not have tumme.el
 > 
 > (tumme-setup-dired-keybindings) ;; Well...
 ...

 > I would love to have feedback on how to make this process easier on
 > the user, especially how to get him/her up to speed quicker.


I think it would be helpful to have a description like you have given in the
Emacs manual.

Nick

Re: thumbs.el and transparency

[Richard M. Stallman]

Why is it necessary to call tumme-setup-dired-keybindings?
It would be nice to make that unnecessary.

Then renaming tumme-dired to thumbnail-dired would make
it convenient to start tumme.

Re: thumbs.el and transparency

[Mathias Dahl]

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

> Why is it necessary to call tumme-setup-dired-keybindings?
> It would be nice to make that unnecessary.
>
> Then renaming tumme-dired to thumbnail-dired would make
> it convenient to start tumme.

The only reason it is necessary is that I did not yet want to make
tumme's bindings on by default. Me and you discussed this and you said
that having the C-t prefix in dired bound to tumme commands would be
harmless as C-t currently does not mean anything in dired. That is
probably easy to fix and if people is OK with it I think we should do
it.

The other issue was the commands to go to next and previous line, on
the same time advancing the thumbnail displays. These are currently
bound to S-C-down and S-C-up. What you suggeste here was to try and
make dired-next/previous-line check if tumme was active or not, and do
the right thing.

None of the above is done yet.

Re: thumbs.el and transparency

[Miles Bader]

2006/1/28, Mathias Dahl <brakjoller@gmail.com>:
> Some might think that what tumme does now is very intrusive, it sets
> up a window configuration that I personally think is suitable for the
> task at hand. Whatever your reaction is, please follow:

Thanks, I could get it to work with those instructions.

I think the more complex the required window configuration, the more
annoying -- unlike traditional applications, users usually freely do
multiple things at once in emacs, and carefully crafted window setups
tend to quickly get messed up and/or interfere with the user's other
tasks.

Having one "primary window" where the cursor is and another slave
window that gets popped up is manageable enough, and the most common
model in emacs; is there a command to invoke tumme that just give you
the "thumbnails" window, without requiring the "window configuration"
and "dired" steps?

If the thumbnails could actually be inserted in the dired window that
would be coolest of all... then tumme would feel much more integrated
(at the expensive of requiring more space for lots of thumbnails).

[BTW, it seems to display lots of gratitous messages in the buffer
when generating the thumbnails, like:

  (Shell command succeeded with no output)
  (New file) [2 times]
  (Shell command succeeded with no output)
  (New file) [2 times]

Maybe it's using a high-level function where it should be using
something lower-level...?]

Thanks,

-Miles

--
Do not taunt Happy Fun Ball.

Re: thumbs.el and transparency

[Mathias Dahl]

Miles Bader <miles@gnu.org> writes:

> I think the more complex the required window configuration, the more
> annoying -- unlike traditional applications, users usually freely do
> multiple things at once in emacs, and carefully crafted window
> setups tend to quickly get messed up and/or interfere with the
> user's other tasks.

I agree, and as I said tumme will work without any special window
configuration at all, but you would have to switch back and forth
between buffers instead. I'd love to see suggestion on how to handle
the different "views" without sacrificing usability. For example, when
the user press RET on a thumbnail image, where should the sized (or
full) image appear? Same window? "other-window"?

What I often do is to set up two windows, one above the other and keep
the thumbnail buffer on top and the image display buffer below:

  +---------------+
  |  thumbnails   |
  |               |
  +---------------+
  |               |
  | image displ.  |
  |               |
  +---------------+

That lets me see all thumbnails, move around them and easily display
an image in the other window at the same time. Of course, this fits
well with my needs and your milage will vary.

> Having one "primary window" where the cursor is and another slave
> window that gets popped up is manageable enough, and the most common
> model in emacs; is there a command to invoke tumme that just give you
> the "thumbnails" window, without requiring the "window configuration"
> and "dired" steps?

Not yet. When you call `tumme-display-thumbs', the thumbnail buffer is
created and all thumbnails that was marked in dired will be displayed
there, but the buffer is not opened. Maybe a simple `display-buffer'
would do? This function does exactly that:

(defun tumme-display-thumbs-and-buffer (&optional arg append)
  "Call `tumme-display-thumbs-and-open' and display thumbnail buffer.
See command `tumme-display-thumbs-and-open' for details about the
arguments.
"
  (interactive)
  (tumme-display-thumbs arg append)
  (display-buffer tumme-thumbnail-buffer))

or, add the call to `display-buffer' last in `tumme-display-thumbs',
which should probably be customizable.

Does that work?

> If the thumbnails could actually be inserted in the dired window that
> would be coolest of all... then tumme would feel much more integrated
> (at the expensive of requiring more space for lots of thumbnails).

Agree, but that felt too advanced for me.

> [BTW, it seems to display lots of gratitous messages in the buffer
> when generating the thumbnails, like:
>
>   (Shell command succeeded with no output)
>   (New file) [2 times]
>   (Shell command succeeded with no output)
>   (New file) [2 times]
>
> Maybe it's using a high-level function where it should be using
> something lower-level...?]

I use `shell-command', maybe that is wrong, I don't know. I copied
much ideas and code from thumbs.el in the beginning.

Re: thumbs.el and transparency

[Mathias Dahl]

Miles Bader <miles@gnu.org> writes:

> Having one "primary window" where the cursor is and another slave
> window that gets popped up is manageable enough, and the most common
> model in emacs; is there a command to invoke tumme that just give
> you the "thumbnails" window, without requiring the "window
> configuration" and "dired" steps?

My last post had an error. This should work better:

(defun tumme-display-thumbs-and-buffer (&optional arg)
  "Call `tumme-display-thumbs' and display thumbnail buffer.
See command `tumme-display-thumbs' for details about the
arguments.
"
  (interactive "P")
  (tumme-display-thumbs arg)
  (display-buffer tumme-thumbnail-buffer))

Similarily, this new command used from the thumbnail buffer will
split the window and show the image display buffer:

(defun tumme-display-thumbnail-original-image-and-buffer (&optional arg)
  "Call `tumme-display-thumbnail-original-image' and display display buffer.
See command `tumme-display-thumbnail-original-image' for
details."
  (interactive "P")
  (tumme-display-thumbnail-original-image arg)
  (display-buffer tumme-display-image-buffer))

Try binding RET to it instead of the usual
`tumme-display-thumbnail-original-image'. Optional prefix argument
turns off image sizing.

Again, the call to `display-buffer' could be baked into the original
functions but we would need an option to control the behaviour then,
IMHO.

Re: thumbs.el and transparency

[Robert J. Chassell]

Here is a report on my attempt to use Tumme Thumbnail mode.

My conclusion:  Please combine Tumme Thumbnail mode with the current
Thumbs mode, which is inadaquate as is.  For the most common
invocation, please deploy one window in a frame that does not need to
be widened.  This window should be a dired buffer.  It should show all
the usual dired information (except maybe the links info) as well as
the thumbnail images.  You should be able to invoke it when typing
`M-x thumb'.  Also, the command `dired-thumb' should be aliased to
`thumb'.

Here is the report:

   If all goes well, you should have a window config like this:

        +---------+---------+
        |         |         |
        |         |    2    |
        |         |         |
        |    1    +---------+
        |         |         |
        |         |    3    |
        |         |         |
        +---------+---------+

That makes my dired window too narrow.  My default windows frame, run
under X, produces a window that is eighty characters wide.  This works
fine.  In a regular instance of Emacs with this Tummes configuration,
I cannot see the endings of file in dired.  The window becomes 37
characters wide.  I had to widen the whole frame before I could even
begin to mark files.

Also, I currently have 86 open buffers in this instance of Emacs, and
do many different things.  So I did not want a program that adds too
many windows.  I started a separate instance.

As a practical matter, I would prefer one window with the option of
creating others.  The one window beginning should be a dired window
that also shows thumbnail images.  It should be invoked when you type
`M-x thumb' or `M-x dired-thumb'.

In another instance, I tried `M-x thumbs'.  Tumme Thumbnail mode is
not like Thumbs mode.

By default, Thumbs mode initially shows only thumbnails, not dired
information plus thumbnails.  However, Tumme Thumbnail mode does not
show any images at all when you type `M-x tumme-dired'.

Please combine the two modes.  A good name is `thumbs'.  It could run
Thumbs mode.  The dired information for `M-x dired-thumb' should
contain at least:  permissions, users, size, date, name, just like the
current dired.

Without the links info, we should be able to see a whole name up to 21
characters long, including the four characters for the dot and three
letter extension (i.e., a name itself of 17 characters).  Or put the
thumbnail on a separate line from the dired info, directly above the
name, which currently starts at column 48.  (I think I would prefer
this latter format.  Some of my image names are quite long.  In the
default, this format permits fully visible image names up to 32
characters long.)

Obviously, `dired-thumb' should show a line without an image for
non-image files and for image files that cannot be displayed.  Showing
images makes the buffer longer, but that can be done.

   Use the arrow keys to move around the thumbnails. To display an
   image, press RET on the thumbnail. This will display a sized
   version in the display buffer.

This is good!  I like the convenience of displaying what in this case
looks like a not quite double-sized thumbnail, smaller than the
original.

How do I save such a resized image?  Using the normal commands, C-x h
(`mark-whole-buffer') and M-w (`kill-ring-save'), I tried saving the
smaller image as foo.jpg, but that did not work.  The file contained
only two bytes, 0x20 0x0a, and the ImageMagick `display' program said
it was not a JPEG file.

   If you want to see the full size image, either use C-x o to jump to
   the display buffer and then press "f" (full) there, or press C-return
   to display image in an external viewer (which must be
   configured). Press "s" to again display a sized version.

Neither succeeded in this instance of my regular Emacs.  (But see
below.)  `f' (tumme-display-current-image-full) just displayed a
small, empty box.

Also, `s' (tumme-display-current-image-sized) failed.  All I could see
was the small, empty box and an error message that said "No original
file name at point".

Ack!  I just deleted the tumme related buffers, ran `M-x tumme-dired',
marked an image, moved dot to the *tumme* buffer by moving the mouse,
pressed C-t d (`tumme-display-thumbs').  I do not see a thumb.  (For
this instance, I have `mouse-autoselect-window' set to t in my
initialization file, but that turns out to be irrelevant.)

OK, I start an other instance, this time using
    today's GNU Emacs CVS snapshot, Sun, 2006 Jan 29  11:42 UTC
    GNU Emacs 22.0.50.15 (i686-pc-linux-gnu, GTK+ Version 2.8.10) 
    started with

        emacs/src/emacs -Q -D

Evaluate

    (progn
      (load-file "/usr/local/src/emacs/lisp/tumme.elc")
      (tumme-setup-dired-keybindings))

Widen frame.  Execute `M-x tumme-dired' on the same directory as
before, mark the same two files.  

First I switch to the *tumme* buffer but `C-t d'
(tumme-display-thumbs) fails.  So switch back to the dired buffer and
run `C-t d' there.  That succeeds.  (So my earlier failure was not due
to Mouse Autoselect mode, as I thought earlier.)

Good, this time both `f' (tumme-display-current-image-full) and
`C-RET' (tumme-thumbnail-display-external) succeed.

So does `s' (tumme-display-current-image-sized). 

--
    Robert J. Chassell
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: thumbs.el and transparency

[Chong Yidong]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    If all goes well, you should have a window config like this:
>
>         +---------+---------+
>         |         |         |
>         |         |    2    |
>         |         |         |
>         |    1    +---------+
>         |         |         |
>         |         |    3    |
>         |         |         |
>         +---------+---------+
>
> That makes my dired window too narrow.  My default windows frame, run
> under X, produces a window that is eighty characters wide.  This works
> fine.  In a regular instance of Emacs with this Tummes configuration,
> I cannot see the endings of file in dired.  The window becomes 37
> characters wide.  I had to widen the whole frame before I could even
> begin to mark files.

I agree.  This window configuration is simply impractical.  (BTW, if
you call tumme-dired again, window 1 is split even further, which is
clearly a bug).  I find the current tumme interface rather difficult
to use.

Instead of displaying the thumbnails in a separate window, I'd suggest

 1. Displaying them in a speedbar.

or

 2. Displaying them in a tooltip (I hacked together an implementation
    of this to see what it looks like, and it seems to look OK).

Re: thumbs.el and transparency

[Nick Roberts]

 > Here is a report on my attempt to use Tumme Thumbnail mode.
 > 
 > My conclusion:  Please combine Tumme Thumbnail mode with the current
 > Thumbs mode, which is inadaquate as is.

Inadequate for what purpose.  I find that I can review my images with it
quite easily.

...

Nick

Re: thumbs.el and transparency

[Robert J. Chassell]

     > My conclusion:  Please combine Tumme Thumbnail mode with the current
     > Thumbs mode, which is inadaquate as is.

    Inadequate for what purpose?

Mainly, I review thumbnails in order to discover which image goes with
which name.  Then I edit the full sized image with the GIMP.

By default, `M-x thumbs' does not provide me with names or sizes.  Of
course, I can move my cursor over an image and figure out the name
from that, but that takes more time.

It occurs to me that the relevant size is not that of the thumbnail,
but of the original from which the thumbnail was made.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: thumbs.el and transparency

[Nick Roberts]

Robert J. Chassell writes:
 >      > My conclusion:  Please combine Tumme Thumbnail mode with the current
 >      > Thumbs mode, which is inadaquate as is.
 > 
 >     Inadequate for what purpose?
 > 
 > Mainly, I review thumbnails in order to discover which image goes with
 > which name.  Then I edit the full sized image with the GIMP.

I see.  Inadequate for your purpose.  What about all those who may not want
to edit their images?

Nick

Re: thumbs.el and transparency

[Robert J. Chassell]

    >     Inadequate for what purpose?
    > 
    > Mainly, I review thumbnails in order to discover which image goes with
    > which name.  Then I edit the full sized image with the GIMP.

   I see.  Inadequate for your purpose.  What about all those who may not want
   to edit their images?

Well, there are people who like to sort by one criterion or another.
I cannot speak for others, but merely urge the adoption of features
that already exist in other programs.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: thumbs.el and transparency

[Mathias Dahl]

"Robert J. Chassell" <bob@rattlesnake.com> writes:


> My conclusion: Please combine Tumme Thumbnail mode with the current
> Thumbs mode, which is inadaquate as is.  For the most common
> invocation, please deploy one window in a frame that does not need
> to be widened.  This window should be a dired buffer.  It should
> show all the usual dired information (except maybe the links info)
> as well as the thumbnail images.  You should be able to invoke it
> when typing `M-x thumb'.  Also, the command `dired-thumb' should be
> aliased to `thumb'.

Before we decide any "drastic" solution like The Big Merge, please
consider the small additions and changes from my last couple of posts.

> That makes my dired window too narrow.  My default windows frame,
> run under X, produces a window that is eighty characters wide.  This
> works fine.  In a regular instance of Emacs with this Tummes
> configuration, I cannot see the endings of file in dired.  The
> window becomes 37 characters wide.  I had to widen the whole frame
> before I could even begin to mark files.

I see. Another configuration that I set up manually sometimes, is
this:

 
 +--------------+
 |     D        |
 +------+-------+
 | TB   |  DB   |
 |      |       |
 +------+-------+
                
D = dired
TM = thumbnail buffer
DB = display buffer

It has the advantage of not truncating the dired information.

> Also, I currently have 86 open buffers in this instance of Emacs,
> and do many different things.  So I did not want a program that adds
> too many windows.  I started a separate instance.

I understand.

> The one window beginning should be a dired window that also shows
> thumbnail images.

I like the idea but I'm not sure I would manage buliding such a beast
:)

> In another instance, I tried `M-x thumbs'.  Tumme Thumbnail mode is
> not like Thumbs mode.

No, it's not. :)

> By default, Thumbs mode initially shows only thumbnails, not dired
> information plus thumbnails.  However, Tumme Thumbnail mode does not
> show any images at all when you type `M-x tumme-dired'.

Correct, but the new command I posted earlier in this thread
does. Check it out.

> How do I save such a resized image?  Using the normal commands, C-x
> h (`mark-whole-buffer') and M-w (`kill-ring-save'), I tried saving
> the smaller image as foo.jpg, but that did not work.  The file
> contained only two bytes, 0x20 0x0a, and the ImageMagick `display'
> program said it was not a JPEG file.

The sized image is stored using the file name in variable
`tumme-temp-image-file'. So you could copy that file to a new one, but
it would be better to provide such a command in the display buffer
instead.

>    If you want to see the full size image, either use C-x o to jump to
>    the display buffer and then press "f" (full) there, or press C-return
>    to display image in an external viewer (which must be
>    configured). Press "s" to again display a sized version.
>
> Neither succeeded in this instance of my regular Emacs.  (But see
> below.)  `f' (tumme-display-current-image-full) just displayed a
> small, empty box.

I noticed that box today too and then it was because Emacs does not
handle the image file type. What `f' does, although it just says
"display in full size bla bla) is really to just let Emacs try and
display the file. This could be fixed by converting the full size
original to a full size jpeg (which is what tumme always converts to),
but I am not sure that feels good.

> Also, `s' (tumme-display-current-image-sized) failed.  All I could
> see was the small, empty box and an error message that said "No
> original file name at point".

Hmm, I will try to recreate that, thanks!

> Ack!  I just deleted the tumme related buffers, ran `M-x
> tumme-dired', marked an image, moved dot to the *tumme* buffer by
> moving the mouse, pressed C-t d (`tumme-display-thumbs').  I do not
> see a thumb.  (For this instance, I have `mouse-autoselect-window'
> set to t in my initialization file, but that turns out to be
> irrelevant.)

No no. Don't move to the *tumme* buffer before running that command
(C-t d), run it from the Dired buffer. That should work much much
better! :)

> First I switch to the *tumme* buffer but `C-t d'
> (tumme-display-thumbs) fails.  So switch back to the dired buffer
> and run `C-t d' there.  That succeeds.  (So my earlier failure was
> not due to Mouse Autoselect mode, as I thought earlier.)
>
> Good, this time both `f' (tumme-display-current-image-full) and
> `C-RET' (tumme-thumbnail-display-external) succeed.
>
> So does `s' (tumme-display-current-image-sized).

Ah, good!

Now read my earlier posts too :)

Re: thumbs.el and transparency

[Chong Yidong]

> I see. Another configuration that I set up manually sometimes, is
> this:
>
>  
>  +--------------+
>  |     D        |
>  +------+-------+
>  | TB   |  DB   |
>  |      |       |
>  +------+-------+
>
> It has the advantage of not truncating the dired information.

For the little job that tumme does, it's unreasonable for it to
perform such invasive changes on my window configuration, or to demand
all the Emacs screen "real estate".

But there's no need to reinvent the wheel for tumme.el -- just use the
speedbar!

See the attached preliminary patch.  Do (setq tumme-use-speedbar t),
turn on the speedbar, and open any dired buffer containing images.
Apart from saving real estate, you don't need a keybinding to display
a thumbnail --- the speedbar timer allows you to display the image at
point automatically.

One other thing that this patch demonstrates is the usefulness of a
`tumme-get-thumbnail-image' function, that just takes the original
filename and returns a thumbnail image descriptor.  Then third-party
libraries won't have to muck around with tumme.el's internal functions
like `thumme-thumb-name', `tumme-create-thumb', etc.  You probably
want to add this function to tumme.el in any case.


*** emacs/lisp/tumme.el.~1.3.~	2006-01-27 19:16:46.000000000 -0500
--- emacs/lisp/tumme.el	2006-01-29 17:50:09.000000000 -0500
***************
*** 821,826 ****
--- 821,838 ----
    :type 'string
    :group 'tumme)
  
+ (defun tumme-get-thumbnail-image (file)
+   "Return the image descriptor for a thumbnail of image file FILE."
+   (unless (string-match (image-file-name-regexp) file)
+     (error "%s is not a valid image file."))
+   (let ((thumb-file (tumme-thumb-name file)))
+     (unless (and (file-exists-p thumb-file)
+ 		 (<= (float-time (nth 5 (file-attributes file)))
+ 		     (float-time (nth 5 (file-attributes thumb-file)))))
+       (tumme-create-thumb file thumb-file))
+     (list 'image :type 'jpeg :file thumb-file
+ 	  :relief tumme-thumb-relief :margin tumme-thumb-margin)))
+ 
  (defun tumme-insert-image (file type relief margin)
    "Insert image FILE of image TYPE, using RELIEF and MARGIN, at point."
  
*** emacs/lisp/dired.el.~1.331.~	2006-01-20 10:05:38.000000000 -0500
--- emacs/lisp/dired.el	2006-01-29 17:52:26.000000000 -0500
***************
*** 3266,3271 ****
--- 3266,3284 ----
  	     '(dired-mode . dired-restore-desktop-buffer))
  
  \f
+ (defun dired-speedbar-buttons (dired-buffer)
+   (when (and (boundp 'tumme-use-speedbar)
+ 	     tumme-use-speedbar)
+     (let ((filename (with-current-buffer dired-buffer
+ 		      (dired-get-filename))))
+       (when (and (not (string-equal filename (buffer-string)))
+ 		 (string-match (image-file-name-regexp) filename))
+ 	(erase-buffer)
+ 	(insert (propertize
+ 		 filename
+ 		 'display
+ 		 (tumme-get-thumbnail-image filename)))))))
+ \f
  (if (eq system-type 'vax-vms)
      (load "dired-vms"))

Re: thumbs.el and transparency

[Mathias Dahl]

Chong Yidong <cyd@stupidchicken.com> writes:

>> I see. Another configuration that I set up manually sometimes, is
>> this:
>>
>>  
>>  +--------------+
>>  |     D        |
>>  +------+-------+
>>  | TB   |  DB   |
>>  |      |       |
>>  +------+-------+
>>
>> It has the advantage of not truncating the dired information.
>
> For the little job that tumme does, it's unreasonable for it to
> perform such invasive changes on my window configuration, or to demand
> all the Emacs screen "real estate".

I understand from all the comments that it is intrusive. Still, tumme
does not require any window configuration at all really. It's up to
you how many buffers you want to see, depending on what you want to do
with it. That three window-configuration is very handy when you are
doing certain kinds of work with your images, trust me, but of course
far from all.

Yesterday I posted some small changes to tumme that would make it less
intrusive for a first time user. Try them out.

> But there's no need to reinvent the wheel for tumme.el -- just use
> the speedbar!

Yay! :)

> See the attached preliminary patch.  Do (setq tumme-use-speedbar t),
> turn on the speedbar, and open any dired buffer containing images.
> Apart from saving real estate, you don't need a keybinding to display
> a thumbnail --- the speedbar timer allows you to display the image at
> point automatically.

I will try it!

> One other thing that this patch demonstrates is the usefulness of a
> `tumme-get-thumbnail-image' function, that just takes the original
> filename and returns a thumbnail image descriptor.  Then third-party
> libraries won't have to muck around with tumme.el's internal functions
> like `thumme-thumb-name', `tumme-create-thumb', etc.  You probably
> want to add this function to tumme.el in any case.

Great, thanks!

/Mathias

Re: thumbs.el and transparency

[Mathias Dahl]

Chong Yidong <cyd@stupidchicken.com> writes:

> See the attached preliminary patch.  Do (setq tumme-use-speedbar t),
> turn on the speedbar, and open any dired buffer containing images.
> Apart from saving real estate, you don't need a keybinding to display
> a thumbnail --- the speedbar timer allows you to display the image at
> point automatically.

Tried it and I must say that it is quite cool and that we should keep
it :)

At first I did not understand how it worked, what I needed to do in
order for the image to appear but I noticed that I just needed to go
up/down in dired. Nice! I read in speedbar.el how the magic works,
that it calls a major mode's `foo-speedbar-buttons' etc. Very neat.

For doing the things I do most with tumme, that is, browsing,
categorizing (adding tags) and cleaning out bad images, it is too slow
compared to a dired buffer in one window, tumme's thumbnail in
another, and maybe the display buffer in a third. When "movement
tracking" is enabled, just moving to a row in dired will move the
cursor in the thumbnail buffer to the corresponding thumbnail.

It will be a nice compliment though.

Thanks for the hack!

Re: thumbs.el and transparency

[Robert J. Chassell]

I tried `tumme-show-all-from-dir' but it took a long time.  It was in
a directory with lots of images.  It is vital that you add them
incrementally.  

Your limit makes sense the way the function is written now.  My main
image directory has many images in it.  I do not know how others work,
but if they are like me, then in practice, the function will fail
because of directories with lots of images.

Also, it is no good to click on the image to find its name.  That
takes too long.  And that action did not give me the other information
that comes in dired.


gimv does provide the name, size, and date of the image.  Moreover, it
is quicker and works incrementally.


Later, after trying `M-x tumme-dired' again, I switched to another,
non-tumme buffer.  At that point, I lost the window configuration that
had the three tumme buffers.  As far as I know, there is some way to
save such configurations, but I don't know it.

All the tumme commands should work in all the tumme buffers.

   No no. Don't move to the *tumme* buffer before running that command
   (C-t d), run it from the Dired buffer. That should work much much
   better! :)

`tumme-display-thumbs' should run in a regular dired buffer, calling
whatever is necessary the first time.  Currently, that command is
bound to `C-t d', but might be bound differently in the future, a
keybinding that fits with the other dired commands.  You should not
have to run a special `tumme-dired' command.

The good news is that saving a resized image did work.  On my system,
`tumme-temp-image-file' is ~/.tumme/.tumme_temp, so

    cp ~/.tumme/.tumme_temp ~/foo.jpg

That works fine.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: thumbs.el and transparency

[Mathias Dahl]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> I tried `tumme-show-all-from-dir' but it took a long time.  It was in
> a directory with lots of images.  It is vital that you add them
> incrementally.  

OK.

> Your limit makes sense the way the function is written now.  My main
> image directory has many images in it.

Mine too, so I mark the images I want to look at, using the
window configuration that suits me best at the time, and then use C-t
d. As I use "follow mode", tumme will track the correct thumbnail in
the thumbnail buffer when I go up/down in dired. And the other way
around if I am in thumbnail buffer.

> I do not know how others work,
> but if they are like me, then in practice, the function will fail
> because of directories with lots of images.

People seem to work very differently. I have several thousand images
in my dir, trying to show them all as thumbnail would not be logical
at all for me, even if the thumbnail creation was asynchronous or similar.

> Also, it is no good to click on the image to find its name.  That
> takes too long.  And that action did not give me the other information
> that comes in dired.

See above. The idea is to keep dired buffer open so that you will see
which thumbnail that matches which file in dired.

> gimv does provide the name, size, and date of the image.  Moreover, it
> is quicker and works incrementally.

I wrote tumme because it did a job I could not find in any other image
viewer. If gimv works for you, good!

> Later, after trying `M-x tumme-dired' again, I switched to another,
> non-tumme buffer.  At that point, I lost the window configuration that
> had the three tumme buffers.  As far as I know, there is some way to
> save such configurations, but I don't know it.

You can save a window configuration to a register if you want to,
using `window-configuration-to-register'. Nothing I use myself though.

> All the tumme commands should work in all the tumme buffers.

Can you elaborate? All tumme thumbnail commands work in the thumbnail
buffers, all tumme-commands to be used from dired work in dired and
all commands that should work in the didplay buffer (not many) works
in the display buffer.

> `tumme-display-thumbs' should run in a regular dired buffer, calling
> whatever is necessary the first time.  Currently, that command is
> bound to `C-t d', but might be bound differently in the future, a
> keybinding that fits with the other dired commands.  You should not
> have to run a special `tumme-dired' command.

You don't have to! Load tumme.el and setup the keybindings by calling
`tumme-setup-dired-keybindings'. Then go to ANY dired buffer with
images. Mark some files and do C-t d. Voila! Thumbnail images
displayed in the thumbnail buffer.

But, the thumbnail buffer is not displayed by default. I created a
experimental command that does, however, which I posted yesterday. Try
binding that to C-t d instead and see if it works better for you.

> The good news is that saving a resized image did work.  On my system,
> `tumme-temp-image-file' is ~/.tumme/.tumme_temp, so
>
>     cp ~/.tumme/.tumme_temp ~/foo.jpg
>
> That works fine.

Yes, and there should also probably be a command that does that for
the user.

Thanks for testing, all comments are valuable! A pity that they come
this late though...

Re: thumbs.el and transparency

[Richard M. Stallman]

    Thumbs operation on the other hand is er, pretty obvious and
    straight-forward, and it seems reasonably useful for what it does...
    At the least, I got a buffer full of thumbnails with the first command
    I tried.  I never did figure out how to make tumme do that.

We need to make it tumme simpler to invoke.

Re: thumbs.el and transparency

[Mathias Dahl]

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

>     Thumbs operation on the other hand is er, pretty obvious and
>     straight-forward, and it seems reasonably useful for what it does...
>     At the least, I got a buffer full of thumbnails with the first command
>     I tried.  I never did figure out how to make tumme do that.
>
> We need to make it tumme simpler to invoke.

Here is an example of such a command. It tries to mirror the way the
`thumbs' command works. I added a new defcustom, a new defun with a
defalias and made a slight change to `tumme-display-thumbs'. Basic
code proudly copied from thumbs.el:

(defcustom tumme-show-all-from-dir-max-files 50
  "*Maximum number of files to show using`tumme-show-all-from-dir'.
 before warning the user."
  :type 'integer
  :group 'tumme)

;;;###autoload
(defun tumme-show-all-from-dir (dir)
  "Make a preview buffer for all images in DIR and display it.
If the number of files in DIR that matches
`image-file-name-regexp' exceeds
`tumme-show-all-from-dir-max-files', a warning will be
displayed.

Note: you won't get the same integration (movement tracking,
marking, automatic jumping to the correct dired buffer etc) using
this command as if you had used `tumme-display-thumbs' directly
from a dired buffer, but for basic thumbnail and image viewing it
works well."
  (interactive "DDir: ")
  (let* ((files (directory-files 
                 dir t (image-file-name-regexp))))
    (if (or (<= (length files) tumme-show-all-from-dir-max-files)
            (and (> (length files) tumme-show-all-from-dir-max-files)
                 (y-or-n-p 
                  (format "Directory contains more than %d files. Proceed? " 
                                   tumme-show-all-from-dir-max-files))))
        (progn
          (tumme-display-thumbs nil nil files)
          (switch-to-buffer tumme-thumbnail-buffer))
      (message "Cancelled."))))     

;;;###autoload
(defalias 'tumme 'tumme-show-all-from-dir)

(defun tumme-display-thumbs (&optional arg append files)
  "Display thumbnails of all marked files, in `tumme-thumbnail-buffer'.
If a thumbnail image does not exist for a file, it is created on
the fly.  With prefix argument ARG, display only thumbnail for
file at point (this is useful if you have marked some files but
want to show another one). 

Optional argument FILES is a list of file names that will be used
instead of using file names from dired.

With optional argument APPEND, append thumbnail to thumbnail buffer
instead of erasing it first.

Recommended usage is to split the current frame horizontally so
that you have the dired buffer in the left window and the
`tumme-thumbnail-buffer' buffer in the right window."
  (interactive "P")
  (let ((buf (tumme-create-thumbnail-buffer))
        curr-file thumb-name file-list count dired-buf beg)
    (if files
        (progn
          (setq file-list files)
          (setq dired-buf nil))
      (setq dired-buf (current-buffer))
      (if arg
          (setq files (list (dired-get-filename)))
        (setq files (dired-get-marked-files))))
    (save-excursion
      (set-buffer buf)
      (let ((inhibit-read-only t))
        (if (not append)
            (erase-buffer)
          (goto-char (point-max)))
        (mapcar
         (lambda (curr-file)
           (setq thumb-name (tumme-thumb-name curr-file))
           (if (and (not (file-exists-p thumb-name))
                    (not (= 0 (tumme-create-thumb curr-file thumb-name))))
               (message "Thumb could not be created for file %s" curr-file)
             (tumme-insert-thumbnail thumb-name curr-file dired-buf)))
         file-list))
      (cond ((eq 'dynamic tumme-line-up-method)
             (tumme-line-up-dynamic))
            ((eq 'fixed tumme-line-up-method)
             (tumme-line-up))
            ((eq 'interactive tumme-line-up-method)
             (tumme-line-up-interactive))
            ((eq 'none tumme-line-up-method)
             nil)
            (t
             (tumme-line-up-dynamic))))))

Combined with one of the example defuns I posted earlier I think that this
would indeed be quite easy to use for a beginner, or at least match
the easiness (?) of thumbs:

(defun tumme-display-thumbnail-original-image-and-buffer (&optional arg)
  "Call `tumme-display-thumbnail-original-image' and display display buffer.
See command `tumme-display-thumbnail-original-image' for
details."
  (interactive "P")
  (tumme-display-thumbnail-original-image arg)
  (display-buffer tumme-display-image-buffer))

Rebind RET:

(define-key tumme-thumbnail-mode-map "\C-m"
    'tumme-display-thumbnail-original-image-and-buffer)

It would be great if someone could test the usefullness of this.

/Mathias

Re: thumbs.el and transparency

[Richard M. Stallman]

    (defun tumme-show-all-from-dir (dir)
      "Make a preview buffer for all images in DIR and display it.

I am having trouble following the code of this--it is quite complex.
Does it create a dired buffer?  Or does it create something else
instead of a dired buffer?

Re: thumbs.el and transparency

[Mathias Dahl]

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

>     (defun tumme-show-all-from-dir (dir)
>       "Make a preview buffer for all images in DIR and display it.
>
> I am having trouble following the code of this--it is quite complex.
> Does it create a dired buffer?  Or does it create something else
> instead of a dired buffer?

It creates a buffer called *tumme* with thumbnails of all image files
in DIR, just like what happens if you mark files in dired and press
`C-t d' (`tumme-display-thumbs'), but skipping the dired step, for
convenience. A lot of people, including you, seem to have missed this
feature from thumbs.el and I wanted to make a quick hack to see if it
was possible to do. And it was, quite easily. The "only" problem with
it, which `thumbs' have too AFAIK, is that it does not generate the
thumbnails "in the background" (asynchronously or whatever).

The only comment I got about it was that it wasn't good, because of
the limitation I mentioned above. In my opinion it should cover what
`thumbs' does though. I'll probably add it to tumme as I think it
quite is useful.

Re: thumbs.el and transparency

[Mathias Dahl]

Mathias Dahl <brakjoller@gmail.com> writes:

> "Richard M. Stallman" <rms@gnu.org> writes:
>
>>     (defun tumme-show-all-from-dir (dir)
>>       "Make a preview buffer for all images in DIR and display it.
>>
>> I am having trouble following the code of this--it is quite complex.
>> Does it create a dired buffer?  Or does it create something else
>> instead of a dired buffer?
>
> It creates a buffer called *tumme* with thumbnails of all image files
> in DIR, just like what happens if you mark files in dired and press
> `C-t d' (`tumme-display-thumbs'), but skipping the dired step, for
> convenience. A lot of people, including you, seem to have missed this
> feature from thumbs.el and I wanted to make a quick hack to see if it
> was possible to do. And it was, quite easily. The "only" problem with
> it, which `thumbs' have too AFAIK, is that it does not generate the
> thumbnails "in the background" (asynchronously or whatever).
>

I just wrote another version that did not require any change in
`tumme-display-thumbs' and which also has the benefit of opening
dired, so that you get full integration:

(defcustom tumme-show-all-from-dir-max-files 50
  "*Maximum number of files to show using`tumme-show-all-from-dir'.
 before warning the user."
  :type 'integer
  :group 'tumme)

(defun tumme-show-all-from-dir (dir)
  (interactive "DDir: ")
  ;; Create dired buffer so that we can, if we want
  ;; use the nice integrations between tumme and dired.
  (dired dir)
  (dired-mark-files-regexp (image-file-name-regexp))
  (let ((files (dired-get-marked-files)))
    (if (or (<= (length files) tumme-show-all-from-dir-max-files)
            (and (> (length files) tumme-show-all-from-dir-max-files)
                 (y-or-n-p 
                  (format 
                   "Directory contains more than %d image files. Proceed? " 
                   tumme-show-all-from-dir-max-files))))
        (progn
          (tumme-display-thumbs)
          (switch-to-buffer tumme-thumbnail-buffer))
      (message "Cancelled."))))

/Mathias

Re: thumbs.el and transparency

[Richard M. Stallman]

    It creates a buffer called *tumme* with thumbnails of all image files
    in DIR, just like what happens if you mark files in dired and press
    `C-t d' (`tumme-display-thumbs'), but skipping the dired step, for
    convenience. A lot of people, including you, seem to have missed this
    feature from thumbs.el and I wanted to make a quick hack to see if it
    was possible to do.

That is good.

But I think we should also make it simpler to enter tumme-dired.

Re: thumbs.el and transparency

[Mathias Dahl]

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

>     It creates a buffer called *tumme* with thumbnails of all image files
>     in DIR, just like what happens if you mark files in dired and press
>     `C-t d' (`tumme-display-thumbs'), but skipping the dired step, for
>     convenience. A lot of people, including you, seem to have missed this
>     feature from thumbs.el and I wanted to make a quick hack to see if it
>     was possible to do.
>
> That is good.
>
> But I think we should also make it simpler to enter tumme-dired.

I think we are miscommunicating. I just renamed `tumme-dired' to
`tumme-dired-with-window-configuration', because that is what it
basically does, opens dired in the directory specified by the user and
creates the window configuration that *I* think works quite well, but
which there have been discussions about.

The new command `tumme' will work quite well for beginners or users
that seldom use tumme.

I changed C-t d (`tumme-display-thumbs') so that it does
`pop-to-buffer' after having generated the thumbnails. This is quite
useful as the user ends up in the thumbnail buffer where he can then
just move around and press RET to look at the images.

`tumme-display-thumbnail-original-image', which RET is bound to, now
uses `display-buffer' so that the image display buffer opens
automatically in another window.

So, there is no longer any need for setting up that window
configuration for doing simple image browsing, but using one (for
example the one that `tumme-dired-with-window-configuration' sets up)
should still work the same as before.

I think it works quite well now.

I sent you and a couple of "test pilots" the latest code but haven't
got any response from the others yet. I'd rather way til I do before I
make any changes in this area.

/Mathias

Re: thumbs.el and transparency

[Richard M. Stallman]

    I think we are miscommunicating. I just renamed `tumme-dired' to
    `tumme-dired-with-window-configuration', because that is what it
    basically does, opens dired in the directory specified by the user and
    creates the window configuration that *I* think works quite well, but
    which there have been discussions about.

Are you going to make another way to enter tumme Dired?

    So, there is no longer any need for setting up that window
    configuration for doing simple image browsing, but using one (for
    example the one that `tumme-dired-with-window-configuration' sets up)
    should still work the same as before.

That sounds good.

Re: thumbs.el and transparency

[Mathias Dahl]

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

>     I think we are miscommunicating. I just renamed `tumme-dired' to
>     `tumme-dired-with-window-configuration', because that is what it
>     basically does, opens dired in the directory specified by the user and
>     creates the window configuration that *I* think works quite well, but
>     which there have been discussions about.
>
> Are you going to make another way to enter tumme Dired?

Actually I don't understand what you are asking? Do you? :)

 All `tumme-dired' really did (well it still does, but under a new
name) was to start Dired in a directory specified by the user, create
two new buffers (one for the thumbnails and one for the image display)
and set them up in a "convenient" window configuration.

 Creating those buffers was never been a requirement for tumme to
work, it was just done so that the window configuration could be set
up. Tumme has always created the buffer it needs when it needs it. For
example, `tumme-display-thumbs', that maps over marked files in dired,
will always create the thumbnail buffer if it isnt there, and the
command that displays the image will create the image buffer if it
does not exist.

So, that having said, what *are* you asking? :)

Re: thumbs.el and transparency

[Richard M. Stallman]

    > Are you going to make another way to enter tumme Dired?

    Actually I don't understand what you are asking? Do you? :)

I mean, to make an easy way to enter Tumme to use it thru Dired.

     All `tumme-dired' really did (well it still does, but under a new
    name) was to start Dired in a directory specified by the user, create
    two new buffers (one for the thumbnails and one for the image display)
    and set them up in a "convenient" window configuration.

Are you saying that just plain `dired' will do the job?

Re: thumbs.el and transparency

[Mathias Dahl]

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

>     Actually I don't understand what you are asking? Do you? :)
>
> I mean, to make an easy way to enter Tumme to use it thru Dired.

As long as tumme is loaded there will be a Tumme menu in dired where
you can access all Tumme commands related to Dired.

>
>      All `tumme-dired' really did (well it still does, but under a new
>     name) was to start Dired in a directory specified by the user, create
>     two new buffers (one for the thumbnails and one for the image display)
>     and set them up in a "convenient" window configuration.
>
> Are you saying that just plain `dired' will do the job?

Yes, as long as tumme is loaded and tumme keybindings are set up (this
is currently done using `tumme-setup-dired-keybindings' but we have
discussed moving some, if not all of those, into dired).

Again, what `tumme-dired' did was nothing more then opening a
directory in dired and setup a pre-configured window
confuguration. The need for this is not as strong as before now that
`tumme-display-thumbs' uses `pop-to-buffer' to make sure the thumbnail
buffer becomes visible.

These small changes are not checked in to CVS. I have got a Savannah
account but not learned how to use it yet. And, I would like to have
some feedback on the changes, but it seems I won't get some, so I
better test some more myself first.

Re: thumbs.el and transparency

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

> I would like to have some feedback on the changes, but it seems I won't
> get some, so I better test some more myself first.

Well, the basic thing both thumbs packages are still missing is proper
integration with dired.  The first thing I expect from a thumbs package
is to display a dired buffer with thumbnail images in it.

This can be very easily done with iimage.el, i.e. just open a dired buffer
and type M-x iimage-mode RET and you will see, for example:


[-- Attachment #2: dired1.png --]
[-- Type: image/png, Size: 8274 bytes --]

[-- Attachment #3: Type: text/plain, Size: 784 bytes --]


This doesn't look right yet.  With a simple fix it could preserve file
names in the dired buffer:

--- lisp/iimage.el	6 Aug 2005 22:13:43 -0000	1.6
+++ lisp/iimage.el	5 Feb 2006 20:28:32 -0000
@@ -133,12 +133,43 @@
-		  (add-text-properties (match-beginning 0) (match-end 0)
-				       (list 'display (create-image file)))
-		(remove-text-properties (match-beginning 0) (match-end 0)
-					'(display)))))))
+		  (let ((ov (make-overlay (match-beginning 0) (match-end 0))))
+		    (overlay-put ov 'evaporate t)
+		    (overlay-put ov 'before-string
+				 (propertize " "
+					     'display
+					     (create-image file))))
+		(remove-overlays (match-beginning 0) (match-end 0)
+				 'display))))))

After that, images get added before the file name part in the dired
buffer like:


[-- Attachment #4: dired2.png --]
[-- Type: image/png, Size: 9969 bytes --]

[-- Attachment #5: Type: text/plain, Size: 1841 bytes --]


This is much better, but still doesn't work for large images.  This can be
improved with another fix:

--- lisp/iimage.el	6 Aug 2005 22:13:43 -0000	1.6
+++ lisp/iimage.el	5 Feb 2006 20:29:32 -0000
@@ -133,1 +133,1 @@
-				(create-image file))))
+				(create-image (my-make-thumbnail file)))))

and a new function:

(defun my-make-thumbnail (file)
  (let* ((image-file (concat "file://" (expand-file-name file)))
         (thumb-file (expand-file-name (concat "~/.thumbnails/normal/" (md5 image-file) ".png")))
         (file-attrs (file-attributes file))
         (modif-time (float-time (nth 5 file-attrs))))
    (unless (file-exists-p thumb-file)
      (shell-command
       (mapconcat
        'identity
        (list
         "convert"
         (format "\"%s\"" file)
         (format "-set \"Description\" \"Thumbnail of %s\"" image-file)
         (format "-set \"Software\" \"ImageMagick, GNU Emacs %s\"" emacs-version)
         (format "-set \"Thumb::URI\" \"%s\"" image-file)
         (format "-set \"Thumb::MTime\" \"%.0f\"" modif-time)
         "-set \"Thumb::Size\" \"%b\""
         "-set \"Thumb::Image::Width\" \"%w\""
         "-set \"Thumb::Image::Height\" \"%h\""
         "-set \"Thumb::Image::Mimetype\" \"image/jpeg\""
         "-resize 128x128"
         "+profile \"*\""
         "-type TrueColorMatte"
         (format "png:\"%s\"" thumb-file))
        " ")))
    thumb-file))

This function generates thumbnail files exactly as specified by the
Thumbnail Managing Standard.  It constructs the thumbnail filename,
fills all required attributes, resizes the image, removes EXIF data
and uses -type TrueColorMatte to force the encoder to write an
alpha channel as specified by the standard.  I think this function
should be adopted for all Emacs thumbnail packages.

Given that, the result on large files will look like:


[-- Attachment #6: dired3.png --]
[-- Type: image/png, Size: 31211 bytes --]

[-- Attachment #7: Type: text/plain, Size: 157 bytes --]


Isn't this nice?  I think it is.

This is just one thing that would make Emacs thumbnail packages
more useful.

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

[-- Attachment #8: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: thumbs.el and transparency

[Mathias Dahl]

Juri Linkov <juri@jurta.org> writes:

> This can be very easily done with iimage.el, i.e. just open a dired
> buffer and type M-x iimage-mode RET and you will see, for example:

Oh? I didn't even know about iimage.el.

> After that, images get added before the file name part in the dired
> buffer like:

Cool!

> This is much better, but still doesn't work for large images.  This can be
> improved with another fix:

Even cooler! :)

> This function generates thumbnail files exactly as specified by the
> Thumbnail Managing Standard.  It constructs the thumbnail filename,
> fills all required attributes, resizes the image, removes EXIF data
> and uses -type TrueColorMatte to force the encoder to write an
> alpha channel as specified by the standard.  I think this function
> should be adopted for all Emacs thumbnail packages.
>
> Given that, the result on large files will look like:
>
> Isn't this nice?  I think it is.

For directories with a large amount of images, this simply does not
work, I just tried. Other than that, I like the idea really much and
did never think it was that easy to do.

Personally, I do not like the larger size of the thumbnail files used
by the Thumbnail Managing Standard although I like standards.

I'll play some with this.

Thanks!

Re: thumbs.el and transparency

[Miles Bader]

2006/2/6, Mathias Dahl <brakjoller@gmail.com>:
> For directories with a large amount of images, this simply does not
> work, I just tried.

Why not?  If it's the speed of conversion, that could be handled
nicely by a system such as David Kastrup described (which he uses for
his latex rendering package) earlier (and something like that is
really necessary for large directories, regardless of how you display
the thumbnails).

I think both "dired style" and "photo album" style could be useful in
difference circumstances, depending on what I want to do with the
pics:  if I'm re-arranging the files, deleting etc., dired would be
useful; if I just want to look at pictures, a photo-album style layout
[with slightly larger thumbnails] would be useful...

> Personally, I do not like the larger size of the thumbnail files used
> by the Thumbnail Managing Standard although I like standards.

It seems like it should be user-configurable, and configurable
separately for the different cases (you're right the, in the dired
case, they should be a bit smaller).

Does the "standard" allow for saving thumbs with multiple sizes?  Is
the thumb size encoded in the filename somehow?

-Miles
--
Do not taunt Happy Fun Ball.

Re: thumbs.el and transparency

[Juri Linkov]

> I think both "dired style" and "photo album" style could be useful in
> difference circumstances, depending on what I want to do with the
> pics:  if I'm re-arranging the files, deleting etc., dired would be
> useful; if I just want to look at pictures, a photo-album style layout
> [with slightly larger thumbnails] would be useful...

This is what I expect from a thumbnail package too.  In dired style
I wish small thumbnails to be displayed in dired buffers, and in
photo-album style - larger thumbnails together with captions containing
image attributes like image dimension, size, etc.

Currently neither of Emacs thumbnail packages does this.  A simple way to
imitate photo-album style is to generate a Emacs buffer with a table
with cells like:

  ~/.thumbnails/normal/072fe850fe7459ff797873891fbeb9ab.png
  imgp2017.jpg
  1.9MB  1600x1200

and to invoke `iimage-mode' on it (with making thumbnail file names
invisible).

>> Personally, I do not like the larger size of the thumbnail files used
>> by the Thumbnail Managing Standard although I like standards.
>
> It seems like it should be user-configurable, and configurable
> separately for the different cases (you're right the, in the dired
> case, they should be a bit smaller).
>
> Does the "standard" allow for saving thumbs with multiple sizes?  Is
> the thumb size encoded in the filename somehow?

The Thumbnail Managing Standard defines two sizes for thumbnails: 128x128
and 256x256, and two corresponding directories with the following meaning:

~/.thumbnails/normal/
  The default place for storing thumbnails.  The image size must not exceed
  128x128 pixel.  Programs which need smaller resolutions should read and
  write the 128x128 thumbnails and downscale them afterwards to the desired
  dimension.

~/.thumbnails/large/
  The previous notes apply to this directory too, except that the thumbnail
  size must be 256x256 pixel.

There are also more suggestions in http://jens.triq.net/thumbnail-spec/creation.html:

  If a program uses another size for it's previews it loads one of the
  two versions and scales them down to the desired size.

  However, these are suggestions.  Implementations should cope also with
  images that are smaller than the suggested size for the normal and large
  subdirectories.  Depending on the difference between the actual and the
  desired size, they can either use the smaller one found in the cache and
  scale it down or recreate a thumbnail with the proposed size for
  this directory.

Since Emacs can't scale down images itself, it could create (with the help
of external programs) and use smaller thumbnails in ~/.thumbnails/normal/.
But writing smaller thumbnails to this directory is not a good thing.
I definitely wouldn't like if Gimp (which uses the same directory)
displayed thumbnails smaller than 128x128.

Perhaps we should use third directory ~/.thumbnails/small/ even though
it is not defined by the Thumbnail Managing Standard.

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

Re: thumbs.el and transparency

[Mathias Dahl]

Miles Bader <miles@gnu.org> writes:

> 2006/2/6, Mathias Dahl <brakjoller@gmail.com>:
>> For directories with a large amount of images, this simply does not
>> work, I just tried.
>
> Why not?  If it's the speed of conversion, that could be handled
> nicely by a system such as David Kastrup described (which he uses for
> his latex rendering package) earlier (and something like that is
> really necessary for large directories, regardless of how you display
> the thumbnails).

Okay okay, sorry for not being precise enough, it does not work as it
is *now*, for me. I'd be happy to add some more advanced way of
handling this, later.

> I think both "dired style" and "photo album" style could be useful in
> difference circumstances, depending on what I want to do with the
> pics:  if I'm re-arranging the files, deleting etc., dired would be
> useful; if I just want to look at pictures, a photo-album style layout
> [with slightly larger thumbnails] would be useful...

I agree completely. I use tumme for different purposes. Sometimes just
to browse and find an image, sometime to organize (tag, delete etc).

>> Personally, I do not like the larger size of the thumbnail files used
>> by the Thumbnail Managing Standard although I like standards.
>
> It seems like it should be user-configurable, and configurable
> separately for the different cases (you're right the, in the dired
> case, they should be a bit smaller).

I was referring to the file size. I don't remember how big a
difference there was between a PNG and JPG of the same dimensions but
at least when I created thumbnails for my 3000+ images I found the
difference in file size to be too much.

Now I'd better learn how to check in stuff to CVS...

Re: thumbs.el and transparency

[Juri Linkov]

> Okay okay, sorry for not being precise enough, it does not work as it
> is *now*, for me. I'd be happy to add some more advanced way of
> handling this, later.

But then it does not work for you even now, i.e. after invoking
`tumme-display-thumbs' you should wait the same amount of time.

> I was referring to the file size. I don't remember how big a
> difference there was between a PNG and JPG of the same dimensions but
> at least when I created thumbnails for my 3000+ images I found the
> difference in file size to be too much.

With a good image quantization algorithm (like NeuQuant used in `pngnq')
you can get PNG files with smaller sizes and better quality then JPEG
files with the same dimensions.

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

Re: thumbs.el and transparency

[Mathias Dahl]

Juri Linkov <juri@jurta.org> writes:

>> Okay okay, sorry for not being precise enough, it does not work as it
>> is *now*, for me. I'd be happy to add some more advanced way of
>> handling this, later.
>
> But then it does not work for you even now, i.e. after invoking
> `tumme-display-thumbs' you should wait the same amount of time.

Yes, but I never try to display the thumbnails of all 3000+ image
files.

> With a good image quantization algorithm (like NeuQuant used in `pngnq')
> you can get PNG files with smaller sizes and better quality then JPEG
> files with the same dimensions.

That's very interesting. I have to check that tool out!

Re: thumbs.el and transparency

[Juri Linkov]

>>> Okay okay, sorry for not being precise enough, it does not work as it
>>> is *now*, for me. I'd be happy to add some more advanced way of
>>> handling this, later.
>>
>> But then it does not work for you even now, i.e. after invoking
>> `tumme-display-thumbs' you should wait the same amount of time.
>
> Yes, but I never try to display the thumbnails of all 3000+ image
> files.

Just as now you can mark files in dired to display thumbnails in
a separate window, you can mark files in dired to display their
thumbnails in the same dired buffer with a simple piece of code:

(dired-map-over-marks
 (put-image (create-image (my-make-thumbnail (dired-get-filename t)))
            (dired-move-to-filename)) nil)

where `my-make-thumbnail' is a function I posted earlier for creating
thumbnails according to the Thumbnail Managing Standard.

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

Re: thumbs.el and transparency

[Mathias Dahl]

Juri Linkov <juri@jurta.org> writes:

>>> But then it does not work for you even now, i.e. after invoking
>>> `tumme-display-thumbs' you should wait the same amount of time.
>>
>> Yes, but I never try to display the thumbnails of all 3000+ image
>> files.
>
> Just as now you can mark files in dired to display thumbnails in
> a separate window, you can mark files in dired to display their
> thumbnails in the same dired buffer with a simple piece of code:
>
> (dired-map-over-marks
>  (put-image (create-image (my-make-thumbnail (dired-get-filename t)))
>             (dired-move-to-filename)) nil)
>
> where `my-make-thumbnail' is a function I posted earlier for creating
> thumbnails according to the Thumbnail Managing Standard.

Yes, of course. I was not saying that it was a dead end, I was just
saying that the exact "hack" to iimage did not suit my way of working.

I will try out this code eventually. For now, tumme will have to grow
in the pace I have the time to feed it new stuff. Of course, anyone
can contribute as long as it does not break... :)

/Mathias

Re: thumbs.el and transparency

[Juri Linkov]

> Of course, anyone can contribute as long as it does not break... :)

Since there are two thumbnail packages in Emacs, it would be double
effort to contribute to both.  What do you think about idea to move
the basic things (like creation of thumbnail files to the same directory)
to thumbs.el, and leaving in tumme.el only advanced functionality?

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

Re: thumbs.el and transparency

[Mathias Dahl]

Juri Linkov <juri@jurta.org> writes:

> Since there are two thumbnail packages in Emacs, it would be double
> effort to contribute to both.  What do you think about idea to move
> the basic things (like creation of thumbnail files to the same directory)
> to thumbs.el, and leaving in tumme.el only advanced functionality?

I don't understand the reasoning behind this, or I have a completely
different view point. You say it is hard to contribute to two
thumbnail packages, to which I agree with completely. But you suggest
moving things from tumme to thumbs to make them more different. Still
some things would need to exist in both. Wouldn't the best solution be
to have *one* thumbnail package that handle both basic and advanced
things? In my opinion, tumme is there now and there are very few
things missing in it, that thumbs has.

Maybe you suggest that they are used together, that tumme provides
things that thumbs uses, and the other way around? I don't see much
benefit in that though. Splitting tumme into smaller chunks could be a
good thing to do, to make it more modular, but other than that I don't
see that it is worth doing.

The only problem in moving/copying/duplicating thumbs stuff into tumme
is that tumme becomes bigger, it is quite large already, but I don't
think it is unmanageable. The users would benefit; they would get the
old "simpler" things from thumbs and the "advanced" things from tumme,
all in one package.

I just added two items to tumme's todo-section. There are now only
four todos left to make tumme do everything that thumbs does, and none
of them are very hard to implement. With some help they would be done
in no time and we could have one thumbnail package that we could
continue to work on.

All this said, of course, with my usual disclaimer that I'd be equally
happy to merge tumme stuff into thumbs and make thumbs the default and
only thumbnail package. I would not volunteer to do the work
though... :)

Re: thumbs.el and transparency

[Juri Linkov]

> I don't understand the reasoning behind this, or I have a completely
> different view point. You say it is hard to contribute to two
> thumbnail packages, to which I agree with completely. But you suggest
> moving things from tumme to thumbs to make them more different. Still
> some things would need to exist in both. Wouldn't the best solution be
> to have *one* thumbnail package that handle both basic and advanced
> things?

I thought about sharing common customizable options like `thumbs-per-line'
and `tumme-thumbs-per-row', `thumbs-relief' and `tumme-thumb-relief',
`thumbs-conversion-program' and `tumme-cmd-create-thumbnail-program', etc.
by leaving these options in thumbs.el and allowing tumme.el to use them,
so users could customize both packages with the same options.

I based my reasoning on an opinion expressed on this thread that both
packages should exist in Emacs.  But actually I have no opinion about this.
Given the choice between a simple thumbnail package and more advanced one,
I personally would definitely select the latter.

> In my opinion, tumme is there now and there are very few things missing
> in it, that thumbs has.

I think instead of adding all features of thumbs.el to tumme.el it is more
urgent to make tumme.el more usable, so it would have more than one user ;-)

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

Re: thumbs.el and transparency

[Mathias Dahl]

Juri Linkov <juri@jurta.org> writes:

> I based my reasoning on an opinion expressed on this thread that
> both packages should exist in Emacs.  But actually I have no opinion
> about this.  Given the choice between a simple thumbnail package and
> more advanced one, I personally would definitely select the latter.

We agree then.

> I think instead of adding all features of thumbs.el to tumme.el it
> is more urgent to make tumme.el more usable, so it would have more
> than one user ;-)

Hehe :) Fair enough. I know there are at least one user more than
myself...

I have made some small changes the last couple of weeks and I think it
is quite easy to use now. At least I don't see that it is harder to
use than thumbs.

I'm still waiting for someone else than me to test the latest stuff
though, but there doesn't seem to be a lot of "action" in this
area. :)

Oh well...

Re: thumbs.el and transparency

[Miles Bader]

Mathias Dahl <brakjoller@gmail.com> writes:
> I'm still waiting for someone else than me to test the latest stuff
> though, but there doesn't seem to be a lot of "action" in this
> area. :)

I'll try stuff out this weekend.

[I'm lazy, so by default I tend to wait until changes show up in my
personal branch of emacs before trying them, which usually means about a
week or so lag time.]

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

tumme testing

[Robert J. Chassell]

    I'm still waiting for someone else than me to test the latest
    stuff ...

Today's GNU Emacs CVS snapshot, Fri, 2006 Feb 10  11:04 UTC
GNU Emacs 22.0.50.25 (i686-pc-linux-gnu, GTK+ Version 2.8.10) 
started with

    emacs/src/emacs -Q -D

1. tumme-mark-tagged-files fails

    Using the following regular expression

        \(.*\.gif\|.*\.jpg\|.*\.png\)

    `C-t f' (tumme-mark-tagged-files)
    whose documentation says:

        Use regexp to mark files with matching tag.

    failed to mark any files.  The *Message* buffer said:

        0 files with matching tag marked.

2. dired-mark-files-regexp succeeds

    Using the same regular expression, 

    `% m' (dired-mark-files-regexp)
    whose documentation says:

        Mark all files matching regexp for use in later commands.

    marked all the matching files.  The *Message* buffer said:

        370 matching files marked.
    
3. tumme-display-thumbs displays marked files

    After a long wait, `C-t d' (tumme-display-thumbs) successfully
    displayed the files marked with `% m' in a different buffer.  

4. No loading in background 

    No loading occurred in the background.  Hence, the long wait.

5. No data provided easily

    The new buffer did not display the images with the data provided
    by dired.  In particular, it did not display images with names,
    sizes, and dates.  (You can click on an image to obtain its name
    -- I don't know how to do this while keeping my hands on the
    keyboard -- but compared to other thumbnail programs, that
    clicking does not provide much efficiency when you are looking at
    many images; for one, you must remember which visual image goes
    with which size.)

Query:

    Is there a command in the current CVS that shows the thumbnails
    with information?

Second Query:

    What are its bindings, both mouse and keyboard?

Comment:

    Back on 5 February using iimage.el, Juri Linkov showed what can be
    done to make an Emacs thumbnail packages more useful.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: tumme testing

[Mattis]

> 1. tumme-mark-tagged-files fails
>
>     Using the following regular expression
>
>         \(.*\.gif\|.*\.jpg\|.*\.png\)
>
>     `C-t f' (tumme-mark-tagged-files)
>     whose documentation says:
>
>         Use regexp to mark files with matching tag.
>
>     failed to mark any files.  The *Message* buffer said:
>
>         0 files with matching tag marked.

Clearly that function needs better documentation because from what I
can tell, you have misunderstood its purpose completely. The purpose
is to use tumme's "database" file and mark image files that have a
matching "tag" in the database file. What you *seem* to have tried was
to mark image files with a certain file extension, something that
dired handles very well itself. Did I interpret your intentions
correctly?

> 2. dired-mark-files-regexp succeeds
>
>     Using the same regular expression,
>
>     `% m' (dired-mark-files-regexp)
>     whose documentation says:
>
>         Mark all files matching regexp for use in later commands.
>
>     marked all the matching files.  The *Message* buffer said:
>
>         370 matching files marked.

Did you not ask yourself why tumme would try to provide the exact same thing? :)

> 3. tumme-display-thumbs displays marked files
>
>     After a long wait, `C-t d' (tumme-display-thumbs) successfully
>     displayed the files marked with `% m' in a different buffer.

Great. If you try again it should be quicker, because the thumbnail
files are already created.

> 4. No loading in background
>
>     No loading occurred in the background.  Hence, the long wait.

Yup. No such functionality added yet.

> 5. No data provided easily
>
>     The new buffer did not display the images with the data provided
>     by dired.  In particular, it did not display images with names,
>     sizes, and dates.  (You can click on an image to obtain its name
>     -- I don't know how to do this while keeping my hands on the
>     keyboard -- but compared to other thumbnail programs, that
>     clicking does not provide much efficiency when you are looking at
>     many images; for one, you must remember which visual image goes
>     with which size.)

Correct. That's not implemented yet. Partly because I have dired in
another window, and I am using the "track movement" thing so that I
can see, in dired, which file point is on in the thumbnail buffer. It
would probably be quite easy to add that info to the thumbnail buffer,
but it would require a rewrite of the code that places the thumbnail
files there, and exactly how it should look must be investigated. It
is harder in Emacs to center texts under images and so on.

> Query:
>
>     Is there a command in the current CVS that shows the thumbnails
>     with information?

No.

> Second Query:
>
>     What are its bindings, both mouse and keyboard?

There aren't any.

> Comment:
>
>     Back on 5 February using iimage.el, Juri Linkov showed what can be
>     done to make an Emacs thumbnail packages more useful.

Yes, I saw that too. I'll keep it in mind for future additions of functionality.

Thanks for testing!

/Mathias

Re: tumme testing

[Robert J. Chassell]

    >     `C-t f' (tumme-mark-tagged-files)
    >     whose documentation says:
    >
    >         Use regexp to mark files with matching tag.
    >
    >     failed to mark any files.

    Clearly that function needs better documentation ... you have
    misunderstood its purpose completely ...

That is certainly the case!  

    The purpose is to use tumme's "database" file and mark image files
    that have a matching "tag" in the database file.

I didn't even know about a database file.  That should be mentioned in
the functions document string so describe-function displays it.  (I
had not read the documentation in the Emacs manual.)

    Did you not ask yourself why tumme would try to provide the exact
    same thing [as dired]? :)

Dired provides two different flags, one for deletion, a `D', and the
other for marking, a `*'.  I thought that tumme offered yet another
flag.

Also, I figured that instead of the keybinding being `% t' or
something like that, it was `C-t f' because no one had thought of a
`%' keybinding.

Minor error in Info: 

    (emacs)Tumme

    For easy
    browing, type `SPC' (`tumme-display-next-thumbnail-original') to
    advance and display the next image.  Typing `SPC'
    (`tumme-display-previous-thumbnail-original') backs up to the previous
    thumbnail and displays the image.

The keybinding for `tumme-display-previous-thumbnail-original' is DEL
(which on my system is bound to the key labeled `Backspace').
 
As for tags in the data base, the documentation does not say how to
view just the chosen images (tumme marks only certain files and you
can display them with `C-t d'; but that should be spelled out for the
lackwitted or sleepy among us):

    (emacs)Tumme

    To tag
    image files, mark them in the dired buffer and type `C-t t'
    (`tumme-tag-files').  To mark files having a certain tag, type `C-t f'
    (`tumme-mark-tagged-files').

Also, just now, in one instance of Emacs, I tagged two files using
`C-t t' (tumme-tag-files), but then in another instance of Emacs, when
I used `C-t f' (tumme-mark-tagged-files) to show those files, only one
file was marked.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: tumme testing

[Mattis]

>     Clearly that function needs better documentation ... you have
>     misunderstood its purpose completely ...
>
> That is certainly the case!

I will try to make it better.

> I didn't even know about a database file.  That should be mentioned in
> the functions document string so describe-function displays it.  (I
> had not read the documentation in the Emacs manual.)

Would all "tag commands" need that info? Although there are quite few
of them now, more could be added, and I hate redundant documentation.

> Dired provides two different flags, one for deletion, a `D', and the
> other for marking, a `*'.  I thought that tumme offered yet another
> flag.

Fair enough.

> The keybinding for `tumme-display-previous-thumbnail-original' is DEL
> (which on my system is bound to the key labeled `Backspace').

I will fix it.

> As for tags in the data base, the documentation does not say how to
> view just the chosen images (tumme marks only certain files and you
> can display them with `C-t d'; but that should be spelled out for the
> lackwitted or sleepy among us):
>
>     (emacs)Tumme
>
>     To tag
>     image files, mark them in the dired buffer and type `C-t t'
>     (`tumme-tag-files').  To mark files having a certain tag, type `C-t f'
>     (`tumme-mark-tagged-files').

Sorry, I really tried to understand what you mean above, but it seems
I am the sleepy one right now. Could you maybe suggest a change of the
manual (which, btw, is not done yet).

> Also, just now, in one instance of Emacs, I tagged two files using
> `C-t t' (tumme-tag-files), but then in another instance of Emacs, when
> I used `C-t f' (tumme-mark-tagged-files) to show those files, only one
> file was marked.

Thanks, that might be a bug. I will see if I can recreate it.

Re: tumme testing

[Robert J. Chassell]

   > I didn't even know about a database file.  That should be mentioned in
   > the functions document string so describe-function displays it.  (I
   > had not read the documentation in the Emacs manual.)

   Would all "tag commands" need that info? Although there are quite few
   of them now, more could be added, and I hate redundant documentation.

Please remember, not every one will have read the manual.  Or if they
have, they may not remember it.  

Perhaps they last read the relevant node 20 years ago.  If you do as
well as others, and you should, people for whom Chinese is a second
language will read a translation of your words in 2026.

The doc string and the Texinfo documentation are not redundant; the
purposes of each are different.

As an example, please look at the dired documentation:
`describe-function' provides a long description, not only saying on
one line

    "Edit" directory DIRNAME--delete, rename, print, etc. some files in it.

but also listing some of its commands on additional lines.  

Think of the purpose of this documentation.  Then compare it to the
documentation in Texinfo.

Like the `describe-function' documentation, the (emacs)Dired node also
says that dired is a directory editor.  However, it explains what that
means in different words than `describe-function'.  It takes a
paragraph.

In addition, that Info node contains 15 other nodes that describe
matters such as navigation and deletion.  And that number does not
count the two nodes `wdired' and `tumme'.

Each tag command requires documentation that `describe-function'
displays and, in different and when necessary more words, the Texinfo
file requires documentation, too.

   >     To tag
   >     image files, mark them in the dired buffer and type `C-t t'
   >     (`tumme-tag-files').  To mark files having a certain tag, type `C-t f'
   >     (`tumme-mark-tagged-files').

   Sorry, I really tried to understand what you mean above, but it seems
   I am the sleepy one right now. Could you maybe suggest a change of the
   manual (which, btw, is not done yet).

You simply want to say something like the following (in one filled
paragraph; but at the moment, there is no command to view the image
files as small thumbnails in dired, I am leaving the commands as
ellipses and the paragraph unfilled):

    The viewing commands are the same as before.
    To view those image files as small thumbnails in dired, type ...
    To view those image files as thumbnails in a different buffer,
    type ...

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: tumme testing

[Mathias Dahl]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    Would all "tag commands" need that info? Although there are quite few
>    of them now, more could be added, and I hate redundant documentation.
>
> Please remember, not every one will have read the manual.  Or if they
> have, they may not remember it.  
>
> Perhaps they last read the relevant node 20 years ago.  If you do as
> well as others, and you should, people for whom Chinese is a second
> language will read a translation of your words in 2026.
>
> The doc string and the Texinfo documentation are not redundant; the
> purposes of each are different.

I was referring to the docstrings only and sloppily mentioned
"documentation" as a general word. I know they are separate and have
separate purposes.

> Each tag command requires documentation that `describe-function'
> displays and, in different and when necessary more words, the Texinfo
> file requires documentation, too.

Yes. I am currently trying to update both.

> You simply want to say something like the following (in one filled
> paragraph; but at the moment, there is no command to view the image
> files as small thumbnails in dired, I am leaving the commands as
> ellipses and the paragraph unfilled):
>
>     The viewing commands are the same as before.
>     To view those image files as small thumbnails in dired, type ...
>     To view those image files as thumbnails in a different buffer,
>     type ...

I think I understand what you mean now. I'll look into it.

Re: tumme testing

[Juri Linkov]

>> 5. No data provided easily
>>
>>     The new buffer did not display the images with the data provided
>>     by dired.  In particular, it did not display images with names,
>>     sizes, and dates.  (You can click on an image to obtain its name
>>     -- I don't know how to do this while keeping my hands on the
>>     keyboard -- but compared to other thumbnail programs, that
>>     clicking does not provide much efficiency when you are looking at
>>     many images; for one, you must remember which visual image goes
>>     with which size.)

This is the main drawback of tumme.el now (thumbs.el is not better).
I hope this will be improved ASAP.

> Correct. That's not implemented yet. Partly because I have dired in
> another window, and I am using the "track movement" thing so that I
> can see, in dired, which file point is on in the thumbnail buffer. It
> would probably be quite easy to add that info to the thumbnail buffer,
> but it would require a rewrite of the code that places the thumbnail
> files there, and exactly how it should look must be investigated. It
> is harder in Emacs to center texts under images and so on.

This should be quite easy.  You could try the function `image-size'
which returns the size of the image in characters.

>> Comment:
>>
>>     Back on 5 February using iimage.el, Juri Linkov showed what can be
>>     done to make an Emacs thumbnail packages more useful.
>
> Yes, I saw that too. I'll keep it in mind for future additions
> of functionality.

If not with iimage.el, then at least with `put-image'.  Though `put-image'
currently has one drawback: its created overlays don't evaporate when
relocated to the beginning of the buffer, because `put-image' doesn't put
the property `evaporate' to its overlays.  But adding `evaporate' is not
possible because then the overlay evaporates immediately after its creation,
since its length is 0 initially, due to (make-overlay pos pos buffer),
where `pos pos' creates the 0-length overlay.

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

Re: tumme testing

[Mathias Dahl]

Juri Linkov <juri@jurta.org> writes:

>> Correct. That's not implemented yet. Partly because I have dired in
>> another window, and I am using the "track movement" thing so that I
>> can see, in dired, which file point is on in the thumbnail buffer. It
>> would probably be quite easy to add that info to the thumbnail buffer,
>> but it would require a rewrite of the code that places the thumbnail
>> files there, and exactly how it should look must be investigated. It
>> is harder in Emacs to center texts under images and so on.
>
> This should be quite easy.  You could try the function `image-size'
> which returns the size of the image in characters.

Getting the data is not the problem. What I meant was that it might be
a bit harder to get a good UI layout in a character based
application. I guess what the parent wanted was something like the
following:
                     
      +--------+     
      | THUMB  |     
      |        |     
      +--------+     
                     
  Centered file name   
                       
    (X px x Y px)      
    
I am sure it could be solved in a number of ways. The file name could
be truncated if too long etc etc, but it would require a much smarter
redraw that tumme has now. One thing is sure, it will require much
more space. Of course it should be configurable too; personally, file
name and size is not interesting to me at all, in most cases.

> If not with iimage.el, then at least with `put-image'.  Though `put-image'
> currently has one drawback: its created overlays don't evaporate when
> relocated to the beginning of the buffer, because `put-image' doesn't put
> the property `evaporate' to its overlays.  But adding `evaporate' is not
> possible because then the overlay evaporates immediately after its creation,
> since its length is 0 initially, due to (make-overlay pos pos buffer),
> where `pos pos' creates the 0-length overlay.

I'll take your word for it. :)

So, when will we see your first addition to tumme? :) You have a lot
of ideas and seem to have technical expertice superior to mine.

Re: tumme testing

[Juri Linkov]

> Getting the data is not the problem. What I meant was that it might be
> a bit harder to get a good UI layout in a character based
> application. I guess what the parent wanted was something like the
> following:

I imagine a layout like below would be useful and intuitive:

      +--------+     +--------+
      | THUMB  |     | THUMB  |
      |        |     |        |
      +--------+     +--------+
      filename1.jpg  filename1.jpg
      [1600x1200]    [1600x1200]

where [1600x1200] is a link to the full size version.

> Of course it should be configurable too; personally, file name and size
> is not interesting to me at all, in most cases.

All thumbnail programs I encountered so far display as minimum the file
name, size and image dimensions.

>> If not with iimage.el, then at least with `put-image'.  Though `put-image'
>> currently has one drawback: its created overlays don't evaporate when
>> relocated to the beginning of the buffer, because `put-image' doesn't put
>> the property `evaporate' to its overlays.  But adding `evaporate' is not
>> possible because then the overlay evaporates immediately after its creation,
>> since its length is 0 initially, due to (make-overlay pos pos buffer),
>> where `pos pos' creates the 0-length overlay.
>
> I'll take your word for it. :)
>
> So, when will we see your first addition to tumme? :) You have a lot
> of ideas and seem to have technical expertice superior to mine.

Well.  As the first step, I've added the support for displaying thumbnails
directly in the dired buffer.  The command `tumme-dired-insert-marked-thumbs'
is bound to `C-t C-t' and when invoked on the marked files adds thumbnails
to the dired buffer.  It also takes care of relocating thumbnails after
refreshing the dired buffer or changing the sorting order with `s'.

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

Re: tumme testing

[Mathias Dahl]

> > Of course it should be configurable too; personally, file name and size
> > is not interesting to me at all, in most cases.
>
> All thumbnail programs I encountered so far display as minimum the file
> name, size and image dimensions.

One of the tasks I use tumme for is cleaning out bad or unwanted
digital photographs. In that  case, all I am interested in is getting
as many thumbnails as possible in the thumbnail buffer. I scan through
the images, type RET to display some, type `d' to flag unwanted ones
for deletion, rotate some by typing `L' or `R'. When I'm done I jump
to the dired buffer and execute the deletion, maybe add some tag to
all of the marked files (that was still marked since I told tumme to
display them). Maybe I go back to the thumbnail buffer and add tags
specific to each image. This is just one use case of many, of course
and I am sure many people would like to see some data about the file
in the thumbnail buffer, as in your example.

I'm sure it would be possible to do this dynamic/configurable, to
supportboth my "minimalistic" approach and the more verbose one.

> Well.  As the first step, I've added the support for displaying thumbnails
> directly in the dired buffer.  The command `tumme-dired-insert-marked-thumbs'
> is bound to `C-t C-t' and when invoked on the marked files adds thumbnails
> to the dired buffer.  It also takes care of relocating thumbnails after
> refreshing the dired buffer or changing the sorting order with `s'.

Oh? Exciting news, thanks!

You have to excuse me now, I have some `cvs update':ing to do... :)

Re: tumme testing

[Mathias Dahl]

> > Well.  As the first step, I've added the support for displaying thumbnails
> > directly in the dired buffer.  The command `tumme-dired-insert-marked-thumbs'
> > is bound to `C-t C-t' and when invoked on the marked files adds thumbnails
> > to the dired buffer.  It also takes care of relocating thumbnails after
> > refreshing the dired buffer or changing the sorting order with `s'.
>
> Oh? Exciting news, thanks!
>
> You have to excuse me now, I have some `cvs update':ing to do... :)

It works really well, many will like this feature!

A comment: I see that by using `create-image', there is no way to set
a margin other than 0, is it? I think some space, maybe configurable,
around the images would be nice.

Re: tumme testing

[Robert J. Chassell]

    > The command `tumme-dired-insert-marked-thumbs' is bound to `C-t
    > C-t' and when invoked on the marked files adds thumbnails to the
    > dired buffer.

This works great!  Thank you.

Now for two enhancement requests.  :)

  1. A `very small' image option.  Instead of `tumme-thumb-size' which
     fits the standard, a `tumme-very-small-thumb-size', perhaps only
     32 pixels (or maybe 48; I don't know; the value should be held in
     a variable that has a default but can be set in your .emacs file).

     The function would be

         (tumme-dired-insert-marked-thumbs &optional size)

     and, interactively, would be called for the `very small' size with a
     prefix option.

  2. The ability to put set configurable space around images.  This
     variable would be set in your .emacs file.  It might have some
     default value other than 0; I don't know.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: tumme testing

[Juri Linkov]

>   1. A `very small' image option.  Instead of `tumme-thumb-size' which
>      fits the standard, a `tumme-very-small-thumb-size', perhaps only
>      32 pixels (or maybe 48; I don't know; the value should be held in
>      a variable that has a default but can be set in your .emacs file).
>
>      The function would be
>
>          (tumme-dired-insert-marked-thumbs &optional size)
>
>      and, interactively, would be called for the `very small' size with a
>      prefix option.

Using a different size requires handling it at different levels: how to
specify the size interactively (like a prefix option you proposed above),
how to specify the size statically (with an user option), where to save
thumbnails with different sizes (use some file name convention).

I think it would be good to add a new user option with an alist with the
size-to-geometry mapping where "size" is a subjective word describing
an approximate size:

'(("Very small" . "32x32")
  ("Normal" . "128x128")
  ("Large" . "256x256"))

For example, the Gimp uses the following vocabulary for the size words
describing the preview sizes:

Tiny
Very small
Small
Medium
Large
Very large
Huge
Enormous
Gigantic

>   2. The ability to put set configurable space around images.  This
>      variable would be set in your .emacs file.  It might have some
>      default value other than 0; I don't know.

I like to add two new user options for this:

(defcustom tumme-dired-thumb-relief 0
  "*Size of button-like border around thumbnails in dired buffer."
  :type 'integer
  :group 'tumme)

(defcustom tumme-dired-thumb-margin 1
  "*Size of the margin around thumbnails in dired buffer."
  :type 'integer
  :group 'tumme)

Their default values 0 (relief) and 1 (margin) seems good to me.

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

RE: tumme testing

[Drew Adams]

    '(("Very small" . "32x32")
      ("Normal" . "128x128")
      ("Large" . "256x256"))

Small, Medium, Large.

    For example, the Gimp uses the following vocabulary for the size words
    describing the preview sizes:

    Tiny
    Very small
    Small
    Medium
    Large
    Very large
    Huge
    Enormous
    Gigantic

Quick! - which is bigger, Enormous or Huge? Such names are opaque on their
own - users will need to look up what they mean anyway.

Why not just use the size as the name, without adding the vague translation?
"256x256" is a perfectly good name, and it gives you a clear idea of the
size.

In that case, a list of size-names would suffice: ("32x32" "128x128"
"256x256").

An added benefit would be that any number of sizes could be used, without
resorting to coming up with names like "Super Duper Enormogigantissimo" and
"Itsy Bitsy Teeny Weeny" (which of course could only be used on yellow
polka-dot images).

Re: tumme testing

[Tomas Zerolo]

[-- Attachment #1.1: Type: text/plain, Size: 704 bytes --]

On Mon, Feb 13, 2006 at 10:41:13AM -0800, Drew Adams wrote:

[...]
> Small, Medium, Large.
[...]
> Quick! - which is bigger, Enormous or Huge? Such names are opaque on their
> own - users will need to look up what they mean anyway.

Ot1h you're right...

> Why not just use the size as the name, without adding the vague translation?
> "256x256" is a perfectly good name, and it gives you a clear idea of the
> size.

...otoh, a layer of indirection allows adapting to different screen
resolutions and user preferences with more ease. Personally, I'd prefer
the size names, to be able to change the mapping to real sizes as a
whole.

Matter of taste, I guess...

regards
-- tomás

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: tumme testing

[Juri Linkov]

>> Quick! - which is bigger, Enormous or Huge? Such names are opaque on their
>> own - users will need to look up what they mean anyway.
>
> Ot1h you're right...
>
>> Why not just use the size as the name, without adding the vague translation?
>> "256x256" is a perfectly good name, and it gives you a clear idea of the
>> size.
>
> ...otoh, a layer of indirection allows adapting to different screen
> resolutions and user preferences with more ease. Personally, I'd prefer
> the size names, to be able to change the mapping to real sizes as a
> whole.

Nothing prevents us from having both types of size specifications:

Index: lisp/tumme.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/tumme.el,v
retrieving revision 1.17
diff -c -r1.17 tumme.el
*** lisp/tumme.el	13 Feb 2006 14:45:58 -0000	1.17
--- lisp/tumme.el	14 Feb 2006 17:44:04 -0000
***************
*** 428,447 ****
    :type '(repeat string)
    :group 'tumme)
  
! (defcustom tumme-thumb-size (if (eq 'standard tumme-thumbnail-storage) 128 100)
!   "Size of thumbnails, in pixels.
! This is the default size for both `tumme-thumb-width' and `tumme-thumb-height'."
!   :type 'integer
!   :group 'tumme)
! 
! (defcustom tumme-thumb-width tumme-thumb-size
!   "Width of thumbnails, in pixels."
!   :type 'integer
!   :group 'tumme)
! 
! (defcustom tumme-thumb-height tumme-thumb-size
!   "Height of thumbnails, in pixels."
!   :type 'integer
    :group 'tumme)
  
  (defcustom tumme-thumb-relief 2
--- 428,449 ----
    :type '(repeat string)
    :group 'tumme)
  
! (defvar tumme-thumb-size-name-geometry-alist
!   '(("Very small" .  "32x32")
!     ("Small"      .  "64x64")
!     ("Medium"     . "128x128")
!     ("Normal"     . "128x128")
!     ("Large"      . "256x256"))
!   "Size name to geometry mapping.")
! 
! (defcustom tumme-thumb-geometry "Normal"
!   "Default thumbnail geometry.
! This should have either a form like \"128x128\" where the first number is the
! thumbnail width and the second number is the thumbnail height, or a size name
! matching one of the size names in `tumme-thumb-size-name-geometry-alist'."
!   :type `(choice ,@(mapcar (lambda (e) `(const ,(car e)))
!                            tumme-thumb-size-name-geometry-alist)
!                  (string :tag "Geometry"))
    :group 'tumme)
  
  (defcustom tumme-thumb-relief 2
***************
*** 622,630 ****
                   ;; "cryptographically" good so a faster one could
                   ;; be used here.
                   (md5 (file-name-as-directory (file-name-directory f)))))
!            (format "%s%s%s.thumb.%s"
                     (file-name-as-directory (expand-file-name (tumme-dir)))
                     (file-name-sans-extension (file-name-nondirectory f))
                     (if md5-hash (concat "_" md5-hash) "")
                     (file-name-extension f))))
          ((eq 'per-directory tumme-thumbnail-storage)
--- 624,633 ----
                   ;; "cryptographically" good so a faster one could
                   ;; be used here.
                   (md5 (file-name-as-directory (file-name-directory f)))))
!            (format "%s%s_%s%s.thumb.%s"
                     (file-name-as-directory (expand-file-name (tumme-dir)))
                     (file-name-sans-extension (file-name-nondirectory f))
+                    tumme-thumb-geometry
                     (if md5-hash (concat "_" md5-hash) "")
                     (file-name-extension f))))
          ((eq 'per-directory tumme-thumbnail-storage)
***************
*** 634,643 ****
                     (file-name-sans-extension (file-name-nondirectory f))
                     (file-name-extension f))))))
  
  (defun tumme-create-thumb (original-file thumbnail-file)
    "For ORIGINAL-FILE, create thumbnail image named THUMBNAIL-FILE."
!   (let* ((width (int-to-string tumme-thumb-width))
!          (height (int-to-string tumme-thumb-height))
           (modif-time (format "%.0f" (float-time (nth 5 (file-attributes
                                                          original-file)))))
           (thumbnail-nq8-file (replace-regexp-in-string ".png\\'" "-nq8.png"
--- 637,660 ----
                     (file-name-sans-extension (file-name-nondirectory f))
                     (file-name-extension f))))))
  
+ (defun tumme-thumb-width-and-height (&optional geometry)
+   "Return a cons-cell of pixels for width and height of thumbnail geometry.
+ Extract these numbers either from the optional argument `geometry' or
+ the default value of `tumme-thumb-geometry'.
+ Use `tumme-thumb-size-name-geometry-alist' as the size name to geometry mapping."
+   (setq geometry (or (cdr (assoc (or geometry tumme-thumb-geometry)
+                                  tumme-thumb-size-name-geometry-alist))
+                      (or geometry tumme-thumb-geometry)))
+   (save-match-data
+     (if (string-match "\\([0-9]+\\)x\\([0-9]+\\)" geometry)
+         (cons (match-string 1 geometry)
+               (match-string 2 geometry)))))
+ 
  (defun tumme-create-thumb (original-file thumbnail-file)
    "For ORIGINAL-FILE, create thumbnail image named THUMBNAIL-FILE."
!   (let* ((width-and-height (tumme-thumb-width-and-height))
!          (width (car width-and-height))
!          (height (cdr width-and-height))
           (modif-time (format "%.0f" (float-time (nth 5 (file-attributes
                                                          original-file)))))
           (thumbnail-nq8-file (replace-regexp-in-string ".png\\'" "-nq8.png"
***************
*** 1705,1711 ****
           (/ width
              (+ (* 2 tumme-thumb-relief)
                 (* 2 tumme-thumb-margin)
!                tumme-thumb-width char-width))))
      (tumme-line-up)))
  
  (defun tumme-line-up-interactive ()
--- 1722,1728 ----
           (/ width
              (+ (* 2 tumme-thumb-relief)
                 (* 2 tumme-thumb-margin)
!                (car (tumme-thumb-width-and-height)) char-width))))
      (tumme-line-up)))
  
  (defun tumme-line-up-interactive ()

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

Re: tumme testing

[Mathias Dahl]

> I like to add two new user options for this:
>
> (defcustom tumme-dired-thumb-relief 0
>   "*Size of button-like border around thumbnails in dired buffer."
>   :type 'integer
>   :group 'tumme)
>
> (defcustom tumme-dired-thumb-margin 1
>   "*Size of the margin around thumbnails in dired buffer."
>   :type 'integer
>   :group 'tumme)
>
> Their default values 0 (relief) and 1 (margin) seems good to me.

Those sounds like useful options, if we don't want to use the ones
that is already there for thumbnail mode, that is. We probably want
these as separate options though.

Re: tumme testing

[Mathias Dahl]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> 1. tumme-mark-tagged-files fails
>
>     Using the following regular expression
>
>         \(.*\.gif\|.*\.jpg\|.*\.png\)
>
>     `C-t f' (tumme-mark-tagged-files)
>     whose documentation says:
>
>         Use regexp to mark files with matching tag.
>
>     failed to mark any files.  The *Message* buffer said:
>
>         0 files with matching tag marked.

Clearly that function needs better documentation because from what I
can tell, you have misunderstood its purpose completely. The purpose
is to use tumme's "database" file and mark image files that have a
matching "tag" in the database file. What you *seem* to have tried was
to mark image files with a certain file extension, something that
dired handles very well itself. Did I interpret your intentions
correctly?

> 2. dired-mark-files-regexp succeeds
>
>     Using the same regular expression,
>
>     `% m' (dired-mark-files-regexp)
>     whose documentation says:
>
>         Mark all files matching regexp for use in later commands.
>
>     marked all the matching files.  The *Message* buffer said:
>
>         370 matching files marked.

Did you not stop and ask yourself why tumme would try to provide the
exact same thing dired does? ;-)

> 3. tumme-display-thumbs displays marked files
>
>     After a long wait, `C-t d' (tumme-display-thumbs) successfully
>     displayed the files marked with `% m' in a different buffer.

Great. If you try again it should be quicker, because the thumbnail
files are already created.

> 4. No loading in background
>
>     No loading occurred in the background.  Hence, the long wait.

Yup. No such functionality added yet.

> 5. No data provided easily
>
>     The new buffer did not display the images with the data provided
>     by dired.  In particular, it did not display images with names,
>     sizes, and dates.  (You can click on an image to obtain its name
>     -- I don't know how to do this while keeping my hands on the
>     keyboard -- but compared to other thumbnail programs, that
>     clicking does not provide much efficiency when you are looking at
>     many images; for one, you must remember which visual image goes
>     with which size.)

Correct. That's not implemented yet. Partly because I have dired in
another window, and I am using the "track movement" thing so that I
can see, in dired, which file point is on in the thumbnail buffer. It
would probably be quite easy to add that info to the thumbnail buffer,
but it would require a rewrite of the code that places the thumbnail
files there, and exactly how it should look must be investigated. It
is harder in Emacs to center texts under images and so on.

> Query:
>
>     Is there a command in the current CVS that shows the thumbnails
>     with information?

No.

> Second Query:
>
>     What are its bindings, both mouse and keyboard?

There aren't any.

> Comment:
>
>     Back on 5 February using iimage.el, Juri Linkov showed what can be
>     done to make an Emacs thumbnail packages more useful.

Yes, I saw that too. I'll keep it in mind for future additions of
functionality.

Thanks for testing!

/Mathias

Re: thumbs.el and transparency

[Richard M. Stallman]

    I based my reasoning on an opinion expressed on this thread that both
    packages should exist in Emacs.  But actually I have no opinion about this.
    Given the choice between a simple thumbnail package and more advanced one,
    I personally would definitely select the latter.

I think it should be possible to make tumme do everything that thumbs
can do, and just as conveniently.

    I think instead of adding all features of thumbs.el to tumme.el it is more
    urgent to make tumme.el more usable, so it would have more than one user ;-)

I agree, that is the first thing to be done.  But hasn't a lot of it
been done in the past week?

Re: thumbs.el and transparency

[Miles Bader]

On 2/10/06, Juri Linkov <juri@jurta.org> wrote:
> Since there are two thumbnail packages in Emacs, it would be double
> effort to contribute to both.  What do you think about idea to move
> the basic things (like creation of thumbnail files to the same directory)
> to thumbs.el, and leaving in tumme.el only advanced functionality?

I think things are Not That Simple.  They are two separate packages,
you can't just easily mix and match the code like that.

I think the plan is basically to setup wrappers in tumme.el that
emulate the old thumbs interface and then get rid of thumbs.el.

So if you want to hack, do it on tumme.el.

-miles
--
Do not taunt Happy Fun Ball.

Re: thumbs.el and transparency

[Mathias Dahl]

Miles Bader <miles@gnu.org> writes:

> I think the plan is basically to setup wrappers in tumme.el that
> emulate the old thumbs interface and then get rid of thumbs.el.

That's *exactly* what my plan is, anyway, and what I am trying to do.

> So if you want to hack, do it on tumme.el.

Oh? Someone that agrees with me?! :)

Re: thumbs.el and transparency

[Richard M. Stallman]

    Since there are two thumbnail packages in Emacs, it would be double
    effort to contribute to both.  What do you think about idea to move
    the basic things (like creation of thumbnail files to the same directory)
    to thumbs.el, and leaving in tumme.el only advanced functionality?

Do you mean, make tumme.el use thumbs.el for the simple stuff?
In theory, that is ok, but I don't know whether it is convenient.
And some of the low-level code in thumbs.el needs work.

Re: thumbs.el and transparency

[Mathias Dahl]

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

>     Since there are two thumbnail packages in Emacs, it would be double
>     effort to contribute to both.  What do you think about idea to move
>     the basic things (like creation of thumbnail files to the same directory)
>     to thumbs.el, and leaving in tumme.el only advanced functionality?
>
> Do you mean, make tumme.el use thumbs.el for the simple stuff?
> In theory, that is ok, but I don't know whether it is convenient.

If we wanted to split tumme into smaller files, I guess we should move
the tag functionality to tumme-tag.el, move image manipulation to
tumme-manip.el and so on.  But as long as the size of tumme is
manageable, I think keeping it in one file is more convenient.  I'm
not keen on "littering" the file system with more files.

Re: thumbs.el and transparency

[Juri Linkov]

> If we wanted to split tumme into smaller files, I guess we should move
> the tag functionality to tumme-tag.el, move image manipulation to
> tumme-manip.el and so on.  But as long as the size of tumme is
> manageable, I think keeping it in one file is more convenient.  I'm
> not keen on "littering" the file system with more files.

I think splitting is inevitable because the tag functionality has nothing
to do with thumbnails.  It is a way to associate meta information with any
file in the dired buffer, not just images.

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

Re: thumbs.el and transparency

[Mathias Dahl]

Juri Linkov <juri@jurta.org> writes:

> I think splitting is inevitable because the tag functionality has nothing
> to do with thumbnails.

I see what you mean but I don't agree. In tumme specoficly the tags
has everything to do with the thumbnails and image files.

> It is a way to associate meta information with any > file in the
> dired buffer, not just images.

True, it would be a good idea to have a general `tag' (meta data)
mechanism.

Re: thumbs.el and transparency

[Juri Linkov]

> I see what you mean but I don't agree. In tumme specoficly the tags
> has everything to do with the thumbnails and image files.

Sorry, I was unclear.  I meant the tags functionality is not specific
only to thumbnails.

> True, it would be a good idea to have a general `tag' (meta data)
> mechanism.

It would be convenient to categorize images (i.e. attach categories or tags
via their displayed thumbnails, perform various sortings, regroupings,
and saving to the database) with the Ee information manager.  I will try
to add ee-thumbnails extension and base it on tumme.el.  This may require
changes in tumme.el to support a better program interface to other packages.

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

Re: thumbs.el and transparency

[Mathias Dahl]

> Sorry, I was unclear.  I meant the tags functionality is not specific
> only to thumbnails.

Then we agree.

> It would be convenient to categorize images (i.e. attach categories or tags
> via their displayed thumbnails, perform various sortings, regroupings,
> and saving to the database) with the Ee information manager.  I will try
> to add ee-thumbnails extension and base it on tumme.el.  This may require
> changes in tumme.el to support a better program interface to other packages.

That's interesting! I am sure such changes could be done quite easily.

Re: thumbs.el and transparency

[Richard M. Stallman]

tumme.el is larger than most Lisp source files, but quite a few
are larger.  If you want to split it into 2 or 3 files, please do.
But only do that if you feel that makes it clearer and more
maintainable.

Re: thumbs.el and transparency

[Mattis]

> tumme.el is larger than most Lisp source files, but quite a few
> are larger.  If you want to split it into 2 or 3 files, please do.
> But only do that if you feel that makes it clearer and more
> maintainable.

570+ lines are Commentary and History, but yes, it has 2000+ lines of
code which is quite much. I will think about a split, see if there are
things that could be moved to make it easier to maintain, but I don't
see it as an urgent thing to do right now.

Re: thumbs.el and transparency

[Juri Linkov]

>> tumme.el is larger than most Lisp source files, but quite a few
>> are larger.  If you want to split it into 2 or 3 files, please do.
>> But only do that if you feel that makes it clearer and more
>> maintainable.
>
> 570+ lines are Commentary and History

You can remove History without any doubt.  This is the first thing that
is usually done after importing a new package into Emacs CVS.

> but yes, it has 2000+ lines of code which is quite much. I will think
> about a split, see if there are things that could be moved to make it
> easier to maintain, but I don't see it as an urgent thing to do
> right now.

What is needed to make tumme.el more maintainable right now is regrouping
functions and variables related to separate functionalities within one file.
Currently many related functions and variables are littered to different
parts of tumme.el.  The standard way to group related code is like below:

^L

;;; Generate gallery

(defcustom tumme-gallery-dir ...

(defcustom tumme-gallery-hidden-tags ...

... other gallery user options

... gallery internal variables

...

(defun tumme-gallery-generate ()
...

... other gallery commands

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

Re: thumbs.el and transparency

[Mathias Dahl]

> You can remove History without any doubt.  This is the first thing that
> is usually done after importing a new package into Emacs CVS.

Yeah, I have thought about it. I guess there is no idea keeping it
there now that all stuff will be recorded in the ChangeLog and in CVS
logs. I will remove it.

> Currently many related functions and variables are littered to different
> parts of tumme.el.  The standard way to group related code is like below:

I know that it is not as well organized as it could be. But, I am
wondering, is there a "standard" for where to put the defcustoms and
defvars? Maybe that is something I made up myself (quite possible
actually), but I thought that "settings" (defvars, defcustoms etc) are
commonly placed at the top of the code. I'd have no problem in
"sectionize" (new word?) the code in this context if that is how it is
done in general.

Re: thumbs.el and transparency

[Juri Linkov]

> I know that it is not as well organized as it could be. But, I am
> wondering, is there a "standard" for where to put the defcustoms and
> defvars? Maybe that is something I made up myself (quite possible
> actually), but I thought that "settings" (defvars, defcustoms etc) are
> commonly placed at the top of the code. I'd have no problem in
> "sectionize" (new word?) the code in this context if that is how it is
> done in general.

I can't find such rules written down in the Emacs manuals.  But you could
see how other files in Emacs CVS are organized.

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

Re: thumbs.el and transparency

[Richard M. Stallman]

    Yes, as long as tumme is loaded and tumme keybindings are set up (this
    is currently done using `tumme-setup-dired-keybindings' but we have
    discussed moving some, if not all of those, into dired).

Would you please move them now?

Can someone verify my changes to tumme and dired? (was: thumbs.el and transparency)

[Mathias Dahl]

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

>     Yes, as long as tumme is loaded and tumme keybindings are set up (this
>     is currently done using `tumme-setup-dired-keybindings' but we have
>     discussed moving some, if not all of those, into dired).
>
> Would you please move them now?

I just read the newbie documentation about CVS on Savannah. Just so
that I don't break anything I started out small, by merging in my
latest changes from my local tumme.el into the current one in CVS. I
also added the key binding C-t d, bound to `tumme-display-thumbs', in
dired.el.

I added an autoload cookie to tumme.el and did the "make autoloads"
thing to generate a new loaddefs.el. It seems that loaddefs.el is a
compile- or make-time file that should not be in CVS, right? (I don't
see it when I browse CVS via the web interface).

Can someone verify that this was done correctly? I don't want to make
any more changes before I know how all this works.

Re: Can someone verify my changes to tumme and dired?

[Mathias Dahl]

Mathias Dahl <brakjoller@gmail.com> writes:

> I just read the newbie documentation about CVS on Savannah. Just so
> that I don't break anything I started out small, by merging in my
> latest changes from my local tumme.el into the current one in CVS. I
> also added the key binding C-t d, bound to `tumme-display-thumbs',
> in dired.el.

I forgot to say that I am very proud to have successfully defeated the
"vi-monster" on level "cvs ci filename", getting a correct change log
comment and a level up as reward.

:)

Re: Can someone verify my changes to tumme and dired?

[David Kastrup]

Mathias Dahl <brakjoller@gmail.com> writes:

> Mathias Dahl <brakjoller@gmail.com> writes:
>
>> I just read the newbie documentation about CVS on Savannah. Just so
>> that I don't break anything I started out small, by merging in my
>> latest changes from my local tumme.el into the current one in CVS. I
>> also added the key binding C-t d, bound to `tumme-display-thumbs',
>> in dired.el.
>
> I forgot to say that I am very proud to have successfully defeated the
> "vi-monster" on level "cvs ci filename", getting a correct change log
> comment and a level up as reward.

Just edit the stuff.  When finished with editing, use
C-x v =
in order to get the diff to the original state.

Move around in the diff or the original source, use
C-x 4 a
for adding a change log entry for the current diff.

When you are done with all files and changes, save, then use

M-x cvs-examine RET RET
(assuming you are already in the correct directory)
mark all changed files with m and then commit with C

You'll never get into contact with vi or similar.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Can someone verify my changes to tumme and dired?

[Mathias Dahl]

David Kastrup <dak@gnu.org> writes:

> Just edit the stuff.  When finished with editing, use
> C-x v =
> in order to get the diff to the original state.
>
> Move around in the diff or the original source, use
> C-x 4 a
> for adding a change log entry for the current diff.

Those commands are very useful, thanks!

> When you are done with all files and changes, save, then use
>
> M-x cvs-examine RET RET
> (assuming you are already in the correct directory)
> mark all changed files with m and then commit with C
>
> You'll never get into contact with vi or similar.

The above did not work for me. Got an error about my public key. cvs
ci filename works though, and ask for passphrase etc. I ended up
wrestling with vi again... :) (my EDITOR env variable was empty).

Re: thumbs.el and transparency

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
> I think Richard's point is that we should only follow a standard that does
> what we want.  If the Thumbnail Managing Standard doesn't deal with
> transparency, then it seems unsuitable 

"Not dealing with" transparency doesn't means this standard is useless,
simply that it cannot provide guidance on that particular issue.  
Mathias notes that the standard uses the PNG format, so it would seem to
be compatible with proper handling of transparency.

-miles
-- 
`Life is a boundless sea of bitterness'

Re: thumbs.el and transparency

[Nick Roberts]

Miles Bader writes:
 > Nick Roberts <nickrob@snap.net.nz> writes:
 > > I think Richard's point is that we should only follow a standard that does
 > > what we want.  If the Thumbnail Managing Standard doesn't deal with
 > > transparency, then it seems unsuitable 
 > 
 > "Not dealing with" transparency doesn't means this standard is useless,
 > simply that it cannot provide guidance on that particular issue.  
 > Mathias notes that the standard uses the PNG format, so it would seem to

I didn't say it was useless.  If the PNG format can deal with transpareny, as
you seem to be saying, then I've drawn the wrong conclusion and perhaps the
standard is suitable.

Nick

Re: thumbs.el and transparency

[Xavier Maillard]

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

   I don't like having two different thumbnail viewing packages;
   and the fact that they are not particularly coherent makes
   it even worse, by increasing the amount that users have to learn
   and remember in order to use them both.

That is also my point of view. Can these two modes be "merged" together ? That
would, at least, solve two of our problems.

Xavier

Re: thumbs.el and transparency

[Nick Roberts]

 >    I don't like having two different thumbnail viewing packages;
 >    and the fact that they are not particularly coherent makes
 >    it even worse, by increasing the amount that users have to learn
 >    and remember in order to use them both.
 > 
 > That is also my point of view. Can these two modes be "merged" together ?
 > That would, at least, solve two of our problems.

Clearly merging them together would solve the problem.  The hard part is
working out how to do it and finding someone to invest the time.

Nick

Re: thumbs.el and transparency

[Mathias Dahl]

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

>  > That is also my point of view. Can these two modes be "merged"
>  > together ?  That would, at least, solve two of our problems.
>
> Clearly merging them together would solve the problem.  The hard
> part is working out how to do it and finding someone to invest the
> time.

As I explained earlier, I have tried to put as many features of thumbs
into tumme, as per Richard's request, so that it should be able to
replace it. From a feature-perspective, that is, being able to do X or
Y, it is almost complete. What differs, or is missing, is better
usability, and I hope I have started cover that with the example
additions/changes I posted earlier.

I think we should wait until people have tested and commented on them
before we discuss this merge further.

One more thing: yes, we could do this the other way around, merging
tumme stuff into thumbs, but in my opinion that would take more time
to do. Of course, I am biased.

/Mathias