Dne středa 28 leden 2009 Omari Stephens napsal(a): > > 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).
My plan is to prefer desktop files from ~/.geeqie Adding new command would mean copying an existing desktop file or a template from documentation and editing it. I agree it is a bit more complicated but it will easier to distribute the commands and share them among users. Another advantage is that the documentation can be put to the template directly. > > 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." > I think that we can rely on the mime types in most cases. For more specialized commands we can add some custom entries. > > 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. > That is true. The original GQview thumbnail cache is significantly faster than the standard. That's why we probably can't drop it completely. > > 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." > We did not touch the pan view yet. I think that it should be more integrated with the rest of Geeqie, but I have no idea how. > > 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_. > Hm, I would incline to a switch to the standard dialog, mostly because the current code is hard to maintain. I will have to think about it. Any other opinions? 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
