Regarding plans to improve usability in the next release, I have a few suggestions.
In general, where possible I prefer to reduce the number of preferences by just having the application do something sensible. It makes it easier to find the preferences people actually do need to adjust, prevents them from adjusting things wrongly, and can also make bug hunting easier if there are fewer permutations to worry about. It's the difference between Mozilla vs. Firefox, and Sawfish vs. Metacity. (Fedora is favoring the latter of each because of that simplicity.) 1.) We were discussing configuration of external move and copy commands in bug 2537129... Is there anyone for whom the internal copy, move, and rename commands would actually be insufficient in practice and not just in theory? I myself was pondering setting up "gvfs-trash" as my standard alternative to "rm", so my command-line and GUI delete commands would be integrated. But I can't think of any case where "mv" and "cp" or their internal equivalents wouldn't suffice. What about symlinks? I expect many GUI users don't (or shouldn't be asked to) know what they are, much less put them to practical use. Will the internal commands be the default in the final release? The reason I filed the bug was that I found it quite annoying to have a %v variant as the default, and it's something that is difficult for many GUI-oriented users to change. I like the idea of moving the "Editors" tab out of the preferences interface entirely; that would put copy, move, delete, and symlink "under the hood" where they wouldn't get in the way. If I understand what you are proposing, it would allow editors like Gimp, UFDraw, etc. to be displayed on menus if and only if they are actually installed? That would be a huge improvement, since it's quite frustrating to select a menu item that doesn't work. It would also be frustrating to use an application to open an image type that it doesn't understand. It would be nice if geeqie could know what file types an editor can handle by looking at one of these drop-in configuration files. 2.) In Edit -> Preferences -> General -> Thumbnails, I don't understand the option "Cache thumbnails into .thumbnails", because that *is* where the shared thumbnail cache is (or at least its subdirectories). I think the optimal thing to do is actually remove *both* of these options, and just always use the industry-standard shared cache. It's unclear from the interface what happens when both of these options are unchecked, which is poor if either is kept. (The answer is that the cache becomes .geeqie/thumbnails.) 3.) Perhaps it would also be possible to eliminate the "Properties" tab in Edit -> Preferences. Instead, in the Edit -> Properties dialog itself, geeqie could present only the Exif tags which were actually set in the image, but have a "show all properties" checkbox that would allow editing of properties that weren't set. This could be sticky; it would stay turned on across all images once it's turned on, and stay turned off across all images once it's turned off. (I'm thinking of people who are going through a collection of images to edit Exif information. Who else would care what empty properties are displayed?) 4.) When I select "View -> Zoom -> Fit horizontal", it does what I would call "Fit vertical" - it sizes large images so I can scroll left or right, but the top and bottom of the image are exactly at the top an bottom of the window. (And the inverse for "View -> Zoom -> Fit vertical".) Compare to "Fit page width" in document-viewing applications. 5.) I cannot discern any difference between "View -> Zoom" and "View -> Connected Zoom". 6.) When I select "View -> Image overlay", I see a text-based image info overlay. When I select it again, I see a histogram. When I select it again, I go back to seeing no overlay. This is weird. Also strange is that "View -> Histogram channels" and "View -> Histogram log mode" don't do anything unless you have already selected "View -> Image overlay" twice. This seems like something that would be seldom used, and perhaps it would be easier to come up with a sane set of radio buttons if this were part of "Edit -> Preferences". I would actually recommend merging this with the section "Edit -> Preferences -> Advanced -> Overlay Screen Display" to make a new tab, "Edit -> Preferences -> Overlays". "Edit -> Preferences -> Advanced -> Full screen" probably belongs under "Edit -> Preferences -> Windows", and "Edit -> Preferences -> Advanced -> Delete" could be filed under "Edit -> Preferences -> General", which would eliminate the "Advanced" tab entirely. 7.) "File -> Pan view" should probably be "View -> Pan view". This is a neat feature, by the way. 8.) It's unclear what the menu item "File -> Copy path" does. Perhaps "File -> Copy filename" would be more clear? 9.) Image rotation commands appear in "Edit -> Rotate jpeg clockwise", "Edit -> Adjust -> Rotate clockwise", "Right-click -> Edit -> Rotate jpeg clockwise" and "Right-click -> Adjust -> Rotate jpeg clockwise". I think the "Adjust" menu is more clear if it's under "View", not "Edit", since these adjustments don't change the file on disk. "Adjust view" instead of just "Adjust" would also make the distinction more clear on the right-click menu. 10.) The standard find-a-folder dialog boxes are different than the ones that other desktop applications use. I'm running Gnome, but non-Gnome applications like Firefox and even Emacs use the standard interface. A few bugs I found while testing: A.) When I hit the Help button on Edit -> Preferences -> Advanced, I get a dialog box that says "Unable to load: /usr/share/doc/geeqie-1.0alpha2/README" and no help appears. I believe the correct file name is: /usr/share/doc/geeqie-1.0alpha3/README B.) "Help -> Release notes" has the same problem. C.) "Help -> Keyboard shortcuts" has the same problem. D.) "Help -> Contents" has the same problem, plus a problem encountered only when running remotely, which I think is firefox's fault: https://bugzilla.redhat.com/show_bug.cgi?id=481542 Thanks for reading, Beland ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
