"Fossies" - the Fresh Open Source Software Archive

Member "xzgv-0.9.2/TODO" (3 Sep 2017, 7490 Bytes) of package /linux/misc/old/xzgv-0.9.2.tar.gz:

    1 * TODO list		-*- mode:indented-text; mode:outline-minor -*-
    2 
    3 This file documents planned future features, known bugs, and that sort
    4 of thing.
    5 
    6 
    7 * Important in short-term
    8 
    9 Add an optional confirm-on-quit dialog, to appear if any files are
   10 tagged (on the assumption that you might have wanted to do something
   11 with the tagged files). Might be best not to make this default, not
   12 sure. (Suggested by Brad Templeton.)
   13 
   14 Document the way thin-rows mode is always enabled when files are
   15 specified on the command-line. The "Invoking xzgv" node already has a
   16 bit about files-on-cmdline, so probably best to add it there.
   17 
   18 Renaming a file should give the current filename as a default.
   19 (Suggested by "Micha".)
   20 
   21 Slideshow. I've put this off for ages, and it shouldn't be *that*
   22 hard... right? :-) But one problem wrt zgv similiarity is that I can't
   23 really put it on Tab.
   24 
   25 You should be able to choose what command gets run for help, such that
   26 e.g. the default one would be "xterm -e info '(xzgv)%s'".
   27 
   28 Dest for copy/move should accept "-" for most-recently-entered dir, by
   29 analogy with `cd -'. Goto-dir dialog should probably also accept it,
   30 but have independent `history'.
   31 
   32 Add toolbar-ish thing (which should be disabled by default, but appear
   33 at top of viewer window when enabled; could use alt-t for the toggle,
   34 that's available) for general viewer stuff.
   35 
   36 [was going to do this for 0.6 but need to think about it a bit more]
   37 Look into sane ways to add shift-click behaviour for tagging multiple
   38 files with the mouse. The main difficulty is in where you consider the
   39 other end of the region to be - focus row seems bogus, selected row is
   40 similarly bad, and last ctrl-click should be tolerable but is still a
   41 bit odd. Thinking about it, I'm pretty sure it *has* to be last
   42 ctrl-click/shift-click to be at all usable.
   43 
   44 want an option to fit the viewer (and thus the window) to the size of
   45 the first image loaded if one or more images are specified on the
   46 cmdline. Also (this suggested by Wolfram Kleff) a
   47 fit-viewer-to-current-pic option; not a toggle, but a one-off `resize
   48 now' kind of thing like (IIRC) ^e in the Gimp.
   49 
   50 Need to *properly* block keyboard input to selector while loading an
   51 image - I probably need to catch key_release, but it's not too clear.
   52 Here's why - do mouse click in viewer to load an image, and press
   53 space while it's loading. Often you'll end up with one file apparently
   54 selected, but another file being viewed.
   55 
   56 Document the way the keyboard cursor follows last-selected dir when
   57 returning to a previously-visited one. (The logical place to document
   58 this is in the "changing dir" node.) This is important for mouse-happy
   59 users, who could conceivably not otherwise notice. [Perhaps not so
   60 important since selector focus fix, but still worth pointing out.]
   61 
   62 Some way to set the background colour in the viewer. Should make sure
   63 it overrides any pixmaps in the theme. [Obvious approaches didn't
   64 work; RTFS job on GTK+, I think...]
   65 
   66 
   67 * Important in long-term
   68 
   69 Have thumbnails in the selector only read/rendered/stored-as-pixmap
   70 *when displayed*, like zgv. I think overall this would be a win, and
   71 it would be much less demanding of pixmap resources in the X server.
   72 The only question is whether I can manage this without display
   73 glitches; should be possible if non-visible rows are kept pixmapless.
   74 
   75 Make help suck less. And I think viewing HTML would suck *more* in
   76 most cases, so this is going to be a bit tricky.
   77 
   78 Cursor left/right in selector (when filenames are longer than can fit)
   79 don't work that well. Should take these over and tweak the hadj
   80 manually, if possible (but IIRC it may not be easy :-/). Should also
   81 add h/l equivalents if I do this.
   82 
   83 The goto-dir dialog (and copy/move) should use a GUI directory
   84 chooser, in addition to the text-entry widget; but ensure you can
   85 always just do `G', type in the name, then enter (like you can now).
   86 
   87 
   88 * Wishlist features (not too important)
   89 
   90 Something to put current-file-or-tagged onto the clipboard would be
   91 really neat. (Just the (full) filenames, not the contents.) A bit like
   92 a more GUIfied version of `-T'. :-) (Good-ish name would be `copy file
   93 location' or similar, as used in Netscape.)
   94 
   95 `--selector-width' doesn't allow percentages. Should add that. This is
   96 slightly hairy as we have to leave it as a float percentage until we
   97 know we've got the actual window width. Also, it implies that the
   98 percentage should be recalculated every time we resize the window!
   99 (Not that we *set the selector* to the new size, just that we
  100 recalculate the default setting for `~'.)
  101 
  102 It might be nice if viewer shift-click changed scaling *around the
  103 point clicked on* (rather than always the centre of the window). This
  104 would be a bit hairy though, and since I tend to use the keyboard for
  105 scaling anyway I'm not sure I'm likely to bother. :-)
  106 
  107 Currently always uses a 48x48 icon pixmap. Should look into what hints
  108 are available about icon size, and should also offer overrides in case
  109 that's useless or whatever. :-)
  110 
  111 main() has got a bit ugly, that could do with cleaning up. Actually,
  112 main.c as a whole is a bit of a mess. :-)
  113 
  114 
  115 * Trivia
  116 
  117 When you delete a file from the viewer (ctrl-d works there too), it
  118 works fine, but the deleted picture stays in the viewer. It might be
  119 better if it auto-closed the file (though this may be somewhat
  120 disturbing visually, which is why I've not taken this approach
  121 currently). (This suggested by Wolfram Kleff.)
  122 
  123 
  124 * Known bugs
  125 
  126 - when you delete a file at the cursor, if it's at the end of the file
  127   list the cursor disappears. Should make it move the cursor back
  128   before removing the entry. [This could well be a GTK+ bug in late
  129   1.2.x versions, IIRC it didn't happen with 1.2.7 or thereabouts.]
  130 
  131 - callback routines which call render_pixmap() should really be
  132   protected against recursion. Ok, this is basically done now, but the
  133   protections are independent - so e.g. do a mirror and flip at about
  134   the same time and it can still mess up. I expect I need to have a
  135   general `stop listening to the user' callback-defending thing to get
  136   this stuff truly fixed.
  137 
  138 - If you change themes, the current picture isn't updated (more
  139   precisely, if you expose it afterwards it's not redrawn). This
  140   happens when `normal' and zoomed, but *not* when scaling up. You
  141   also get a GTK+ error of some kind IIRC.
  142 
  143 - in zoom mode, it copes with resizing the window as a whole, but
  144   *doesn't* when you change the size of the pane (apart from when
  145   hiding/showing selector or resizing from keyboard, but that's only
  146   'cos I kludged it :-)). Might be fixable by catching configure
  147   events on an event box containing sw_for_pic? [Tried it on clist
  148   ebox, which is resized whenever viewer win is, but it didn't seem to
  149   work...]
  150 
  151 - tagged filenames only appear in red when not selected. This doesn't
  152   appear to be trivial to work around, unfortunately, and I can't
  153   really see any other way of showing tagging which wouldn't look
  154   nasty or take up loads of room.
  155 
  156 - Thumbnails are given an accurate width/height `IMGINFO' comment, but
  157   are always claimed to be "RGB", as Imlib doesn't provide any way for
  158   us to find out what type they are (other Gimp-style types are
  159   "Grayscale" and "Indexed", IIRC). I could possibly kludge this for
  160   common file types by reading the file's header, but this would be
  161   really ugly - is it worth it or not? (An xv-ish file type after the
  162   width/height would be easier, but still kludgey, and I'd much rather
  163   be Gimp-friendly than xv-friendly.)