Suggest: Categories and Folders can exist side-by-side

[orbspider]

For me there's one feature that I would REALLY like to see come to XnviewMP, and that's...

for Categories selection in Tree pane to open under Folders in Tree pane, and NOT replace the folders or Favorites tree.

That way, I can
1. select a category (or multiple) plus a rating, or colour rating, AND THEN
2. navigate any folder by selecting in Tree pane, and
3. the selected category/rating/col-rating will be ACTIVE for any folder I open.

Selected category/rating/col-rating can be canceled by clicking on any header of categories (as currently can do)

For example, I have certain images with the category "abc" and these images have been copied to other locations, so running a database search on "abc" will show original images/copied images all together which is not helpful. But if I can search folder-by-folder with a category, this would be more useful.

The other thing, which I mentioned before, is for category search (database result) to have option "divide by folders" or "flat list" (no divides -as current).

Perhaps this needs more time to implement, but I'll welcome it for sure!
cheers

[m.Th.]

IIUC, do you want to have a multi-layered filter engine. IOW, 'filter by {folder name}' AND ('filter by {rating}' AND/OR 'filter by {color}' AND/OR 'filter by {category/keyword}' etc. where the {folder name} would came from another GUI widget (in your opinion the Folders Tree).

Well, the thing looks good and is rather easy to do from programming / DB POV. However we have a small problem here: The usability problems. Having a persistent DB filter (ratings/colors etc.) over a persistent Disk filter (our Folders tree) can very easy nullify the result. There will be many cases in which the folder will appear empty because the folder which the user just clicked isn't already in the DB and hence doesn't have assigned the ratings/colors etc. If instead of Folders tree, we'll have the Catalog Tree, then the things change. In fact, in this way the filters are applied in many DAMs out there. It is a common feature.

PS: IMHO, it would be better to write your text in normal size. Making such a big portion of text with a large font it is like you're yelling and OTOH affects readability.

For me there's one feature that I would REALLY like to see come to XnviewMP, and that's...

for Categories selection in Tree pane to open under Folders in Tree pane, and NOT replace the folders or Favorites tree.

That way, I can
1. select a category (or multiple) plus a rating, or colour rating, AND THEN
2. navigate any folder by selecting in Tree pane, and
3. the selected category/rating/col-rating will be ACTIVE for any folder I open.

Selected category/rating/col-rating can be canceled by clicking on any header of categories (as currently can do)

For example, I have certain images with the category "abc" and these images have been copied to other locations, so running a database search on "abc" will show original images/copied images all together which is not helpful. But if I can search folder-by-folder with a category, this would be more useful.

The other thing, which I mentioned before, is for category search (database result) to have option "divide by folders" or "flat list" (no divides -as current).

Perhaps this needs more time to implement, but I'll welcome it for sure!
cheers

[orbspider]

Yes, usability needs to be thought through in more detail... and it's not easy to make it look intuitive..

A "Filter Active" button highlighted above Browser to remind that the filter is set? And can be unset by clicking the button.

For me, that the filter has to search the entire database is like over-kill, when sometimes I only want images from a certain folder or group of folders.

With Digikam, there's the initial filter on the left pane, such as folders, tags (categories), face rec, geo-position, etc, and then on the right pane, there are more (secondary) filters, so the browser results can be further filtered by tag, color rating, and what-not. The active filter is displayed in the info bar under browser, along with button to cancel all. The right-side pane is selected by tabs, for filtering, for applying tags, for comments etc, or for viewing details.
Plus the browser thumbs can be sorted flat list or divided by folders, and cna show sub-folder images. Which means a folder with all its sub-folder images can be shown all together. This usability worked for me. But I could use folder tree + categories/rating together on the left.

Your "Catalog Tree" link goes to this thread??

[m.Th.]

Yes, usability needs to be thought through in more detail... and it's not easy to make it look intuitive..

A "Filter Active" button highlighted above Browser to remind that the filter is set? And can be unset by clicking the button.

Sure. Not necessary but very useful. However, if Pierre does not have a central point to apply the filter(s) then it will be a little bit difficult to do it. Anyway, a 'Show All'/'Reset Filters' is done now by changing the folder.

For me, that the filter has to search the entire database is like over-kill, when sometimes I only want images from a certain folder or group of folders.

ANY program works internally like this.

Including digiKam. It is the fastest way to do it. Otherwise it implies to have a separate "database" for each folder and this is an overkill for cross-folder searches. In fact exactly in this 'over-kill' way the file systems works. (for ex. FAT / FAT32 / exFAT / NTFS). Each directory is a small "database" with links to other "databases". Very fast when one works inside of 'databases'(=folder) but slow on cross-folder search. Exactly that's why we use databases (eg. SQLite) to organize our ratings / keywords etc.

With Digikam, there's the initial filter on the left pane, such as folders, tags (categories), face rec, geo-position, etc, and then on the right pane, there are more (secondary) filters, so the browser results can be further filtered by tag, color rating, and what-not. The active filter is displayed in the info bar under browser, along with button to cancel all. The right-side pane is selected by tabs, for filtering, for applying tags, for comments etc, or for viewing details.
Plus the browser thumbs can be sorted flat list or divided by folders, and cna show sub-folder images. Which means a folder with all its sub-folder images can be shown all together. This usability worked for me. But I could use folder tree + categories/rating together on the left.

Yes, GUI organization / GUI metaphor. This is called incremental filtering. Eg. Lightroom has something similar. Istm that the main problem is that here the 'normal' state (IOW unfiltered) is to have all the thumbs together which means to 'quickly load' all the thumbs from the DB which nowadays can easily reach till to 0.5 million for a photographer with several years of experience. There are solutions for this (eg. incremental / on-demand loading of thumbs) but AFAIK Pierre must rewrite a little his thumb loading engine. Also, the usability of a 'sea' of 0.5 million thumbs it is questionable.

I rather prefer the XnView/ACDSee/ASP approach in which is hard to see them 'all'. However I do agree that it is needed to have the possibility to see your 5-star thumbs only for '/root//home/foo/blah/' folder.

Your "Catalog Tree" link goes to this thread??

Sorry, Fixed.

The main advantage in your case is to NOT have the entire directory tree in which you must search for the desired one to filter (because the informational noise is high - 95% from branches there are outside of program's scope) but only the cataloged folders. Much more usable because the noise (ie. unusefull folders) is thrown out.

[orbspider]

OK, I realise that the program has to filter the whole database (leading to very slow start-ups in some, like dk)

but I seem to remember that digikam's search result for a single folder or folder with sub-folders was quite a lot swifter than running the search on the whole collection.

So what I meant by overkill, is the time taken to show what I need - which if it's only images with categories in a few folders, it's kind of painful to wait for the whole database result to show up each time, and especially if the results are not folder-divided (duplicate images from different folders!!) But maybe there's no other way to do it at the present.

Am I clearer or am I still thinking wrongly about this?

cheers

[m.Th.]

OK, I realise that the program has to filter the whole database (leading to very slow start-ups in some, like dk)

but I seem to remember that digikam's search result for a single folder or folder with sub-folders was quite a lot swifter than running the search on the whole collection.

So what I meant by overkill, is the time taken to show what I need - which if it's only images with categories in a few folders, it's kind of painful to wait for the whole database result to show up each time, and especially if the results are not folder-divided (duplicate images from different folders!!) But maybe there's no other way to do it at the present.

Am I clearer or am I still thinking wrongly about this?

cheers

...please note that I'm not against on filter by folder. On contrary, I fully support by-folder filter refinement feature by using the Catalog window (as per why, I described somewhere else - more details upon request).

And now some details:

The dk's search was much faster when your filter was refined with a folder NOT because searching on whole collection (or not) but, by far, because of thumbnail fetching. The thumbnails are much bigger (due of their very nature) than the data which must be crunched in order to show them.

....Of course this is if they got right their *cough* DB schema *cough*. There are/were a generation of DAMs which (IMHO) show an enthusiasm vs SQLite / Visual FoxPro (ACDSee's DB backend) thinking that they can cope with 'everything' and hence they had a lousy, hairy, fat tables in order to provide a bunch of features to the users. However, the photo madness which we see today caught those otherwise smart developers a little bit unprepared (again IMHO) and hence there is a tendency of slowness in these programs.

So, yes, we need a by-folder filter refinement but the folder will be chosen from the Catalog (ie. a folder which is already in the database) and, also, the reasons are the ones above.

OTOH, you do have a point about database partitioning (see http://newsgroup.xnview.com/viewtopic.p ... 93#p112193). However the granularity is different. It is an "overkill" (to use your word ) to have one DB for each folder - it is better to have a DB / Catalog for much more folders, grouped on human meaning. (Archive, Collections etc.)

[orbspider]

Hi m. Th.

just to say I most definitely 1+ your speak about cataloging.

Yes, digikam brings up searches from db, and normally on start-up the db is refreshed (for new files to be seen). Usually, files put in folders in the collection (via external file manager) didn't show up until a (time costly) db refresh.

Oh (and I haven't had digikam for a long time) I remember now, dk didn't browse the file system at all, but folders were selected and added to the collection, through collection manager or something. So that mean's your quite right.

Hope things will develop along these lines then, for the better!