Hi, Some of your needs are already work in progress.
Check http://bugzilla.gnome.org/show_bug.cgi?id=338558 for fully-qualified tag uniqueness, it's a strong request but solving it will require re-coding the 'Tag Typing'. Check http://bugzilla.gnome.org/show_bug.cgi?id=139796 for advanced queries. It's one of the oldest bug request / patch in f-spot. You can CC your email address to follow the discussion about them. I like the idea of displaying more info about the selection (items per tag, ...). You can probably submit a enhancement request in bugzilla and attach a mockup of the UI. As always in F-Spot, the problem is not writing code to solve an issue, it's about writing good code and give the user a nice experience. Thanks for your report, Stephane On Tue, 2006-06-20 at 11:12 +0200, Neilen Marais wrote: > Hi > > I have a pretty big image database (about 12k photos) with fairly > complex meta-data maintained in KPhotoAlbum. I've been eying F-spot for > a while, since it has a very active community, looks pretty and seems > quite nice to use. I'm quite excited by F-spot's ability to handle > picture versions and RAW files. I also prefer GNOME apps all else being > equal. > > KPhotoAlbum is not quite as smooth, but it's interface seems more > "scalable" to me, while F-spot tries (and manages very well) to make > easy stuff easy. I don't think scalable and easy need to be mutually > exclusive though. > > I'll list some features in KPhotoAlbum that I find makes it very useful > for large/complex collections, and why they are useful. Perhaps I can > convince the right people that it may be useful to implement something > similar (if not identical) in F-Spot. > > These comments refer to F-Spot 0.1.11, as shipped with Ubuntu Dapper. > I'll refer to KPhotoAlbum as KP from here on to save typing. > > Separate "Namespaces" > ===================== > > F-spot seems to require the last level of a tag to be unique. Besides > offending my personal sense of logical aesthetics, it also poses > practical problems ;P > > In KP, each top-level tag is called a Category, and the tags within each > Category are completely independent. In my KP database I have a "People" > category for people visible in the photo, and a "Photographer" category > for the person who took the picture. Of course People can also be > Photographers, but usually not at the same time. Also the total number > of photographers aren't the same as the total number of people. > > It's also possible that unrelated tags can coincidentally have the same > name. E.g. if you travel all over the world and meet people from all > over the world, it's not unlikely that some placename in one country may > be the same as someones name in another. > > In fact, identical placenames are quite common. > Places.USA.Alabama.Greenville is not the same as > Places.USA.California.Greenville (see > http://en.wikipedia.org/wiki/American_cities#Most_common_city_names for > more fun.) One can disambiguate by having Greenville_CA, but I already > told you it's in California, damnit ;) > > Actually this is a problem in KP as well, since it's doesn't do any > hierarchy within a category. It does have membership groups that does > something similar, but that does not solve this problem. > > Membership Groups > ----------------- > > I think F-Spot's hierarchical tags can fill the same need, but I'll > describe them so its clear what I'm talking about. > > I'll use the Places category as an example. Say the location is > "Friendly Bob's House" in Pinelands (the town), Western Cape (the > state), South Africa. In KP I can make the location "South Africa" a > membership group. Then I can assign all the states in South Africa (that > I have in my DB anyway) to this group (e.g. Western Cape, Gauteng, > etc.). Then I make Western Cape another membership group, and assign all > the cities to it (e.g. Pinelands, Cape Town, etc.). I make Pinelands a > membership group, and add "Friendly Bob's house" to it. > > Now I tag the picture with only "Friendly Bob's house". Because of the > membership groups, KP knows the picture also belongs to "Pinelands", > "Western Cape" and "South Africa", and will be found by searches on any > of those 4 locations. > > Of course, Locations.South Africa.Western Cape.Pinelands would do just > as well. It will also be more explicit (good), and if F-Spot supported > it, would be separate from Locations.South Africa.Kwazulu > Natal.Pinelands (which also exists!) > > Default "And" searching > ======================= > > >From reading the list it seems that F-Spot will get more searching > options soon, but IMHO if you can have only one choice, "and" would be > better than "or". I hope that when the more featureful searching comes, > there will be an easy way to make the default "and". > > Restrict Tags when Searching > ============================ > > This kind of goes together with the default "and" searching. KP's main > interface shows you a list of top level tags, along with how many > entries each has. e.g. > > Locations - 10 > People - 6 > > Then you select People -> "Friendly Bob" > > You can then look at all the pictures containing Bob, or keep selecting > search tags. However, all the tags that never occur with Bob are > removed, e.g. > > Locations - 4 > People - 3 > > I.o.w. you see only the Locations that Bob's been photographed at and > only the people that have been photographed with Bob. > > Now select Locations -> "Friendly Bob's House", > > and look at the pictures of Bob at his house, or continue: > > Locations (greyed out, since there are no others) > People - 2 > > Then you could choose to look at pictures of Bob with his wife, or Bob > with his son. > > I like this feature for two reasons. > > 1) If you're and-searching, there's no point in seeing the tags that > will result in no pictures being found. > 2) Its nice to see, for instance, how many people you have photographed > at a certain location. > > Scalable Tag Selection > ====================== > > It's hard to compare KP directly to F-Spot here, since the > interface paradigms are quite different, so I'll just sketch my problem. > In KP I have 9 Categories (i.e. top level tags), and some of them have > many subtags. E.g. > > Events - 143 > Keywords - 21 > Locations - 237 > Persons - 203 > Photographer - 33 > > I've only had a camera for about two years, but found I like both > photography and detailed tagging. I'm sure these numbers will have grown > considerably in 10 years time! > > I will always have at least one tag from each of the 5 categories I > listed here attached to every picture, so it is critical that tags can > be selected from a large selection easily. KP makes the default way of > finding a tag incremental search, and also sorts tags in order of last > use by default. It also manages each category completely separately > which means the 100's of "Persons" tags don't make it hard to pick a tag > from the "Keywords" category. > > While I haven't dealt with that many tags in F-Spot, my feeling is the > tag toolbar/tree on the left of F-Spot will be fairly well suited to > dealing with many tags. Other places, where there are flat lists with > all tag hierarchies exploded, will probably be unpleasant to use. > > What I'd need to switch > ======================= > > Like you care ;P Anyway, my needs in order of priority are > > 1) "Fully qualified" tag uniqueness (i.e. People.A != Places.A) > 2) "And" searching > 3) Tag Restrictions while and-searching > 4) Improved UI for selecting from large numbers of tags > > 1) is completely critical, since I can't losslesly move my current data > into F-Spot without it. > 2) is pretty important. > > 3) and 4) would be nice to have, but not that important. > > If other people think it's a good idea, should I make feature requests > on the F-spot bugzilla, or how should I go ahead? > > Thanks for listening > Neilen > -- Stephane Delcroix [EMAIL PROTECTED] _______________________________________________ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
