Albums/Collections

[m.Th.]

Please add GUI support for Albums/Collections.

The DB backend is ready from 0.60.

Steps for GUI support:

1. Add in the Categories Tree before 'Categories' root node another one root node saying "Albums" and add as child nodes to it all rows to be found in

Code: Select all

select AlbumID, AlbumName from albums where AlbumID>1 order by AlbumName; -- no Tag album (hmmm...)

As an aside, we just forgot: add an index on Albums(AlbumName)

2. Add a right-click menu for 'Albums' node and his children with the following options:

- Add New...
- Delete
- Rename...
- Empty
- Get Tagged Files

Explanations:

Add New...

Add new album. Similar with adding a new category.

Delete

Deletes the album. See the category code.

Rename...

Similar with the category.

Empty

Empties the album. After a confirmation message box ("Do you want to empty the album?") the following is issued:

Code: Select all

DELETE from AlbumsLink WHERE AlbumID = ?CurrentAlbumID

Get Tagged Files

Moves the tag selection to the current album. It needs refresh to clear the tag from the thumbnails (if any tagged file is in the current dir). The query is

Code: Select all

UPDATE AlbumsLink SET AlbumID= ?CurrentAlbumID WHERE AlbumID=1;

3. Also, be sure to implement the drag & drop over the albums nodes in order to add files to the albums.

Something is missing?

...perhaps at the beginning (first run with the new engine) add a 'Unnamed Album' child node in order to invite the users.

Also, does someone feels the need for temporary albums (collections) - ie the ones which are deleted at the end of the session?

[m.Th.]

...see also an older discussion about this here: http://newsgroup.xnview.com/viewtopic.php?f=60&t=28196

[oops66]

+1 I support.

[m.Th.]

Another idea is to have exactly the same engine like the one in Categories but in another DB tables. Let's say TagTree1 and Tags1.

And then were is the difference?

The main difference is in the Meaning: Albums / Collections are task oriented cataloging. Categories tree are content oriented cataloging.

This is crucial and that's why any modern DAM has both. Some real life examples:

Albums / Collections: 'Web Site \ Christmas', 'Product ads \ Version 2.0 Pro', 'Temp', 'QuickCollection', 'For export', 'For prepress', 'NatGeo selection' etc. - task related.
Categories / Keywords: 'People \ Pierre Gougelet', 'Animals \ Eagle', 'Genre \ Macro', 'Places \ Remis', 'Objects \ Cars \ Lamborghini' etc. - photo content related.

[orbspider]

I wouldn't think that albums should rest among the hundreds of categories on the categories tree...

they should be on a new "Albums" tree! Because once people get using albums, and not cleaning them up, or adding more and more as a helpful sorting of pictures, the albums could become hundreds, even thousands...

It would be nice to be able to put a star by any album as well, for any reason I'm not sure of yet, perhaps to notify which albums are in use/need work/preparing to upload etc.... click on album and click a coloured star at bottom (similar to the preview pane)...

and then a search field at top, which auto-filters as type some letters....

and would we have a toolbar button to show albums in the browser tree???? er, for those who don't use a folder/albums tree.

and a right-click menu item "add to album >

• |new album" - which could be a toolbar button too (click "select tagged", click "add to album > .."
  
  I remember using Picasa many many days ago... there was a selected tray and we could add all selected to an album by a button near the tray.

[oops66]

... In fact, it's already possible to have such albums (album001, album002,...,album00n) just by adding an IPTC keywords (for example: album001 for album1, etc...) for the related jpg files (but only for images files that support the IPTC metadata) ... the advantage of this solution is: even if the db is corrupted, the embedded data are safe into the files, then it's possible to rebuild the xnview db albums data (for more efficiency)... But the other solution with some news albums names is interesting too (for other files that does not support IPTC keywords) ... ex: TAG , ALBUM1, ALBUM2, ALBUMn (the "TAG" album is in fact a temporary Album0)

[m.Th.]

I wouldn't think that albums should rest among the hundreds of categories on the categories tree...

they should be on a new "Albums" tree! Because once people get using albums, and not cleaning them up, or adding more and more as a helpful sorting of pictures, the albums could become hundreds, even thousands...

(blue mark is mine)

Exactly that's why almost any DAM has a different Albums tree / Collection list / Portfolios line of tabs / Image baskets / Image trays (...did I forget something?). Even if underneath the code is quite similar and one would be tempted to put them as a sub-tree in the Categories tree, in the GUI the human differences are big because their human scope are quite different. See my previous post.

For Pierre & programmers: you can use almost the same model for two different views and two different controllers with the same DB schema

It would be nice to be able to put a star by any album as well, for any reason I'm not sure of yet, perhaps to notify which albums are in use/need work/preparing to upload etc.... click on album and click a coloured star at bottom (similar to the preview pane)...

Folder coloring! Yes - a standard feature among DAMs. Yes, I hope that we'll do this. It is very useful in cataloging. But step by step. Perhaps I will make a new thread for this. Till then a screenshot from PhotoSupreme (not the best one but anyway):

PS-Folder States.JPG

and then a search field at top, which auto-filters as type some letters....

hehehe.... As I said, the same model (code, tooling) with Categories but different in human scope. See here the Incremental Search for Categories: http://newsgroup.xnview.com/viewtopic.php?f=60&t=28375

and would we have a toolbar button to show albums in the browser tree???? er, for those who don't use a folder/albums tree.

and a right-click menu item "add to album >

• |new album" - which could be a toolbar button too (click "select tagged", click "add to album > .."
  
  I remember using Picasa many many days ago... there was a selected tray and we could add all selected to an album by a button near the tray.

Yes - sure, standard tooling. But these after Pierre will start to work on this. The Database is more or less implemented from 0.56, I think.

[orbspider]

also +1 for drag n drop photos to albums on the album tree - as a right-click add to album with list through an arrow might get annoying when albums number 100's. though this could be easier to use if the add-to selector could jump to a name when a key is pressed, like a form field drop-down list.

-1 for adding pics to categories with album names, as writing to files is time consuming (bearable when necessary with normal key-word adding) and also all the categories are shown fully expanded in the info pane when we first open XnviewMP, so imagine a nice 250 album names list at the top or middle (or mixed in if some one's not careful to prefix album name with a specific letter) of all the others, quite a mess.

[oops66]

also +1 for drag n drop photos to albums on the album tree ...

+1 too (or Tag photos to an album name)

-1 for adding pics to categories with album names, as writing to files is time consuming (bearable when necessary with normal key-word adding) and also all the categories are shown fully expanded in the info pane when we first open XnviewMP, so imagine a nice 250 album names list at the top or middle (or mixed in if some one's not careful to prefix album name with a specific letter) of all the others, quite a mess.

... Yes but imagine your nice 250 albums full of nice pictures lost just because of a DB corrupted (or hdd) ... This will a lot of "user time" consuming and lost for rebuild them ... In fact, it would be interesting to also have both (so the ability to synchronize albums names with IPTC embedded keywords as option too) because this consuming time but "computer time" instead of the "user time" in case of problem

[orbspider]

perhaps the albums should be saved as text/html files with file name/paths which we could easily back-up any where and restore to a new setup any time!

[oops66]

perhaps the albums should be saved as text/html files with file name/paths which we could easily back-up any where and restore to a new setup any time!

... Yes but if you move or rename files/folders ... lost too ...

[m.Th.]

The solution which almost all the pack follows (Lr, ASP, IDImager, PSupreme, ACDSee etc.) is to backup the DB. And in fact, it is logical. If DB is lost, then a lot of work is lost. Not only the Albums but the entire cataloging info (RCK etc.). Only ZPS is different here by having albums like shortcut links in folders on disk. Bus as oops66 mentioned, this isn't manageable in the case of target files relocation.

The DB engines which these programs have in back-end - usually SQLite, some of them MS SQL Server in some editions and for some DB, TinyDB (FSViewer) or Visual Fox Pro (ACDSee) - are quite solid (except, perhaps TinyDB) and take extensive care to not corrupt the data on disk in any circumstances.

However, nothing excuses a proper backup strategy for DB.

[oops66]

+1, Right ... "However, nothing excuses a proper backup strategy for DB" ... and mostly for pictures.

[PwrSrg]

Did ALBUMS EVER get implemented?? This simple feature has been being requested for almost 18 YEARS now.

This is the #1 reason why I find this software useless.

[xnview]

See issue for current status and some details.