[ViewVC] Diff of: cvs/CV/bin/cv

Comparing CV/bin/cv (file contents):
Revision 1.52 by root, Sun Aug 14 19:07:15 2005 UTC vs.
Revision 1.58 by root, Wed Sep 7 20:17:25 2005 UTC

       $viewer->load_image ($_[1]);
    });
    Gtk2::CV::Plugin->call (new_schnauzer => $s);
-   $s;
+   $s
 }
 sub std_keys {
    my $key = $_[1]->keyval;
    my $state = $_[1]->state;
    $viewer->signal_connect (button3_press_event => sub {
       $mainwin->visible
          ? $mainwin->hide
          : $mainwin->show_all;
-      1;
+      1
    });
    Gtk2::CV::Plugin->call (new_imagewindow => $viewer);
    $schnauzer = new_schnauzer;
    $mainwin = new Gtk2::Window;
    $mainwin->set_title ("CV");
    $mainwin->add (my $vbox = new Gtk2::VBox);
-   $mainwin->signal_connect (delete_event => sub { $mainwin->hide; 1; });
+   $mainwin->signal_connect (delete_event => sub { $mainwin->hide; 1 });
    $vbox->add ($schnauzer);
    $vbox->pack_end (my $frame = new Gtk2::Frame, 0, 0, 0);
    $frame->add (my $hbox = new Gtk2::HBox 0, 0);
    $hbox->pack_start ((new Gtk2::Label "Info: "), 0, 0, 0);
 main Gtk2;
 __DATA__
+=encoding utf-8
 =head1 NAME
 cv - a fast gtk+ image viewer loosely modeled after XV
 =head1 SYNOPSIS
 =over 4
 =item * optimized directory scanning algorithm
-The directory scanning in CV plays some tricks that - on most modern
+The directory scanning in CV uses some tricks that - on most modern
 filesystems - makes it possible to detect filetypes faster than stat()'ing
 every file. This makes CV suitable for directories with lots of files
 (10000+).
 This algorithm is quite unprecise - it doesn't make a difference between
 files, device nodes, symlinks and the like, and filetype detection is done
 using the file extension only.
+On the positive side, it is usually many orders of magnitude faster than
+traditional scanning techniques (good for directories with 10000 or
+100000+ files).
+=item * queuing for all time-consuming background tasks
+All tasks, such as unlinking files or generating thumbnails, that can be
+done in the background will be done so - no waiting required, even when
+changing directories.
 =item * use of asynchronous I/O
 CV tries to use asynchronous I/O whereever it makes sense, for example
-while scanning directories, waiting for stat data or unlinking files. This
+while scanning directories, waiting for stat data, unlinking files or
-usually decreases scanning times for large directories a bit (especially
+generating thumbnails. This usually decreases scanning times for large
-on RAID devices and over NFS).
+directories a bit (especially on RAID devices and over NFS) and makes CV
+much more interactive.
 =item * fast image loading
 The time span between the user issuing a command and displaying the new
 image should be as small as possible. CV uses optimized (especially
 for JPEG) loading functions and sacrifices some quality (e.g no gamma
-correction) to achieve this speed.
+correction, although this might change) to achieve this speed.
 =item * fast thumbnail creation
-Thumbnail creation is crucial for me, so it's better be fast. Thumbnail
+Thumbnail creation uses both CPU and Disk-I/O. CV interleaves both, so
+on modern CPUs, thumbnailing is usually limited by I/O speed. Thumbnail
-creation for JPEGs has been specially optimized.
+creation for JPEGs has been specially optimized and can even take
+advantage of multiple CPUs.
 =item * minimum optical clutter
 CV has no menus or other user interface elements that take up a lot of
-screen space. The schnauzer windows can also be somewhat crowded.
+screen space (or are useful for beginning users). The schnauzer windows
+can also be somewhat crowded.
 The point of an image viewer is viewing images, not a nice GUI. This is
 similar to XV's behaviour.
 =item * efficient (and hard to learn) user interface
 CV uses key combinations. A lot. If you are an experienced XV user, you
 will find most of these keys familiar. If not, CV might be hard to use at
 first, but will be an efficient tool later.
+=item * multi-window GUI
+CV doesn't force you to use a specific layout, instead it relies on your
+window manager, thus enabling you to chose whatever layout that suits you
+most.
 =item * i18n'ed filename handling throughout
 As long as glib can recognize your filename encoding (either UTF-8 or
-locale-specific, depending on your settings) and you have the relevant
+locale-specific, depending on the setting of G_BROKEN_FILENAMES) and you
-fonts, CV will display your filenames correctly.
+have the relevant fonts, CV will display your filenames correctly.
 =item * extensible through plug-ins
 I have weird plug-ins that access remote databases to find a
 directory. This is not likely to be of any use to other people. Likewise,
  shift-s      set scaling mode to 'hyper' (slowest)
  t            rotate clockwise 90°
  T            rotate counterclockwise°
  ctrl-v       open a new visual schnauzer window for the current dir
  ctrl-e       run an editor ($CV_EDITOR or "gimp") on the current image
- ctrl-p       fire up the print fialog
+ ctrl-p       fire up the print dialog
  escape       cancel a crop action
 And when playing movies, these additional keys are active:
  left         rewind by 10 seconds
  ctrl-g       force generation of thumbnais for the selected files
  ctrl-s       rescan current direcory or files updates/deletes etc.
  ctrl-u       update selected (or all) icons if neccessary
  ctrl-l       don't use, will become a plug-in eventually
+ ^            go to parent directory (caret).
  0-9,
  a-z          find the first filename beginning with this letter
 Right-clicking into the schnauzer window displays a pop-up menu with
 additional actions.
 =back
 =head1 SECURITY CONSIDERATIONS
-CV uses Pixbuf to load images. Pixbuf is not considered safe for this
+CV uses Pixbuf to load non-JPEG images. Pixbuf is not considered safe for
-purpose, though (from the gtk-2.2 release notes):
+this purpose, though (from the gtk-2.2 release notes):
 "While efforts have been made to make gdk-pixbuf robust against invalid
 images, using gdk-pixbuf to load untrusted data is not recommended, due to
 the likelyhood that there are additional problems where an invalid image
 could cause gdk-pixbuf to crash or worse."
 =head1 BUGS/TODO
  Lots of functionality is missing.
  Pixbuf doesn't always honor G_BROKEN_FILENAMES, so accessing files with
- names incompatible might utf-8 fail.
+ names incompatible with utf-8 might fail.
  rotate on disk
  lots of ui issues
  save(?)
  preferences
- shift-cursor in schnauzer
 =head1 AUTHOR
 Marc Lehmann <cv@plan9.de>.

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing CV/bin/cv (file contents): Revision 1.52 by root, Sun Aug 14 19:07:15 2005 UTC vs. Revision 1.58 by root, Wed Sep 7 20:17:25 2005 UTC

Diff Legend

Comparing CV/bin/cv (file contents):
Revision 1.52 by root, Sun Aug 14 19:07:15 2005 UTC vs.
Revision 1.58 by root, Wed Sep 7 20:17:25 2005 UTC