Hi Christopher, First of all, thank you for the feedback. This is exactly what we need.
Dne středa 28 leden 2009 Christopher Beland napsal(a): > 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.) > Geeqie is oriented on more experienced users who knows what they want to do and Geeqie should be flexible enough to fit their needs. Therefore reducing the number of options is not a good idea but I agree that the current configuration dialog needs improvements. We should separate the basic and advanced options and improve the description. > > 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. For example to store images in some version control system. > 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. Many people are used to organize their photo collection by symlinks and this feature is mandatory for them. > > Will the internal commands be the default in the final release? No. > 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. > It is rather positive that people complain about annoying popup and not about deadlocks or lost files ;) > 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. Yes this is one of the advantages. > > 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. > The existing desktop files can be filtered by category (graphics, photography) or by mime types. > > 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.) First, it needs a better description and second, it needs to be changed to use the standard too: http://jens.triq.net/thumbnail-spec/local.html > > 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?) > I have to think about this. > 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. Yes, we should change it. > > 5.) I cannot discern any difference between "View -> Zoom" and "View > -> Connected Zoom". Connected Zoom is different only in split image mode. It should be disabled in single image mode. > > 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. > I have to think about this. > 7.) "File -> Pan view" should probably be "View -> Pan view". This is > a neat feature, by the way. I agree. > > 8.) It's unclear what the menu item "File -> Copy path" does. Perhaps > "File -> Copy filename" would be more clear? Better would be "Copy path to clipboard" > > 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. > We actually plan to change the Adjust -> Rotate commands to update the Exif orientation but I am still not sure if it is a good idea. > 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. > We should probably use the standard dialogs but it has relatively low priority because the current dialogs works OK. Vladimir ------------------------------------------------------------------------------ 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
