Christopher Beland wrote: > 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.)
This really depends on who the intended audience or geeqie is. Mentally, I currently think of it as more for power users. Now, don't get me wrong — sane defaults are always the way to go. But I would rather have a convoluted preference pane than not be able to configure certain things how I want. There are tons of other image viewers out there for people who are looking for fewer features. Geeqie (and GQview before it) is certainly the only one that does the things I'm looking for. > 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. Symlinks are essential. Period. There are certainly folks who don't know how to use them, but for the ones that do, there is no alternative. As for configurable `mv` and `cp`, it seems reasonably plausible that someone will want to hard-link instead of copy, if they know all their images will be on the same filesystem, and they know that they do want them to be the same. No, this use case isn't very large. But again, this is flexibility that other viewers don't offer, and for someone who wants this functionality, it is essential. > 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. %v by default might be a poor choice. Of course, when you're shelling out to some other command, it might be hard to determine when there's a message that the user needs to read. For instance, what if the command spouts an important warning that doesn't actually cause it to fail? Return value would still be 0, but you'd want the user to get the message regardless. > 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. How does this work for people (like me) who compile their own versions of Gimp and UFRaw? What if we have multiple versions installed, and might want to choose which one we use? What about people who want to run random shell scripts as external commands (for instance, I have used an "Editor" entry to append the filename into a text file, which I then used to upload the appropriate images to some web photo gallery software I wrote). Parsing .desktop files is nice, certainly. Not having to create an entire .desktop file for something that will already have its own shell script would also be nice. > 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. In many cases, this isn't knowable a priori. Does Gimp support opening RAW files? The answer is "yes, if you've got a plugin that does it, but otherwise no." > 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.) I think the upshot is that "users may not want geeqie to litter their .thumbnails cache." Each thumbnail gets its own file. This means that if you've got a lot of images, you've got a lot of files, and that much more directory-read overhead. For example, on my machine, I have 88,000 NEFs and 122,000 JPGs. That's 210,000 images. If I even look at _a quarter_ of those, that's over 50,000 entries in my .thumbnails directory. Which means that _any application_ that uses the shared .thumbnails will be slow. As for actual facts: $ls -ld ~/.thumbnails/normal/; ls ~/.thumbnails/normal/ | wc -l drwx------ 2 xsdg xsdg 4161536 2009-01-24 23:29 /home/xsdg/.thumbnails/normal// 61929 That's right, that's a 4-meg directory entry. The first time I tried to list the files (before it was cached), it took 5 seconds. So I think this is a reasonable option to have, even though having a radio button or something might be a better UI. Of course, what if you want geeqie to read the shared .thumbnails but not write to it? > 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?) This certainly doesn't need a tab. I think that something akin to the EXIF sidebar's UI (where you can show all, hit a checkbox for the ones you want to keep, then disable show all) would be better. > 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. Yeah, I think these names are reversed. > 5.) I cannot discern any difference between "View -> Zoom" and "View > -> Connected Zoom". Split the window. Connected zoom zooms both of the sub-windows at the same time. Normal zoom does not. Connected pan, which is Shift+Drag, needs to be documented somewhere > 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. This makes no sense as menu items, but makes perfect sense if you use the keyboard shortcuts. Hit "i" once for EXIF data, hit it again to add the histogram, and then it again to make it go away. It's easy and consistent. While Channels and Log mode really are preferences, it is nonetheless crucial that you be able to switch them easily and without leaving full-screen mode, which is why the keyboard shortcuts work so well. I'm not sure what the best mouse interface for them is, though. > 7.) "File -> Pan view" should probably be "View -> Pan view". This is > a neat feature, by the way. I think the current layout is reasonable if you think of the View menu as "different ways to look at the currently-visible image(s)" and the File menu as "different ways to look at images which aren't currently visible." > 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. Sounds good to me > 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. Oh, goodness. Geeqie is my last bastion of sanity. The Gnome file selectors suck. They may be standardized, but they suck royally. Geeqie's file selectors are actually useful and aren't a pain to use and don't suck. Please, please, please don't take them away. As one example, I have a very-commonly-traversed directory (~/files/media/graphics/photos/) with 524 sub-directories. With the geeqie file selector, it takes zero time to generate and show the listing, just like every other directory. With the Gnome file selector, it takes a full second _every single time_. So, let's say I'm looking at ~/files/media/graphics/photos/2009-01-12/ in the Gnome file selector. I click the "photos" button. 1 second passes, and then I can do something. I click the "2009-01-12" button. Now I click the "photos" button again. It _again_ takes an entire second before I can do something. So, for example, if I'm searching for the right date to put a file under, this starts to get on my nerves _really fast_. --xsdg ------------------------------------------------------------------------------ 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
