![]() Hopefully it contains some useful thoughts, feel free to take it apart.Transcribed from Dmitri Popov's blog, 27 June, 2011 a deleted tag)? The order identifier to this reference set would become obsolete and should be deleted. Some further thoughts: What happens when the reference set doesn't exist anymore (e.g. We can store the order identifier in the meta data of the image and restore the manual sort order by parsing the meta data (in the case we lose the db or we just copy a picture folder). When we add pictures to our reference set they get automatically incorporated in a natural order like discussed above. ![]() This approach has following advantages: Moving an images requires only to adapt the identifier of this particular image. Manually sorting goes then by date or the pseudo date of the identifier if the prefix matches the current view. For example, we start with an album (album id=17) which is sorted by date. A possible identifier could be constructed as follows (although their may be more SQLish ways to organize it): As soon as a picture is moved manually it gets an order identifier like This gives us three attributes for our order identifier: reference set, original sort order and the picture position. That means use the pictures which weren't moved as a frame and place the new ones accordingly. Probably the most natural way would be to follow the original order of the set (date, filename,size. This may be defined by an album or by tags (or by a time interval, but I'm not sure about this yet).Ġ) it meets the most frequent usage case: people choose a certain set of pictures and then start arranging themġ) it allows different subsets with common pictures to have their own order without influencing each otherĢ) all other views and search results can be mapped into an album or tag and than arrangedģ) it probably makes implementing it much easierĪnother question is what happens when items are added to the reference set? We need a way to incorporate them into our manual order. In my opinion, a manual sort order makes only sense, if it's linked to a reference set of pictures. So I'm throwing in some comments to keep at least the discussion alive. I would really like to see this feature implemented in the near future. ORDER BY (o.`view kind` = ?view_kind) DESC Speaking of sql the only way I can think of it is a subquery which could look like this (mysql dialect):ĪND o.`view kind` IN ("default", ?view_kind) Image id and z index are obvious, view kind could be of two types, "default" or a specific view descriptor this way we can:Ī) chose to give or not a default order for the imageī) use the view order and fallback to a default one Z index (or x,y,z for a spatial conscious album ) This way we can hope the order make sense also if the views are different, if this is too far fetched then we can keeping the previous assumptions:Ĭreate a table for sorting the images with the following properties: > with a defined group of neighboring images, but can be completely off in theġ) the order should be unique in the whole collection, cross all the albums.Ģ) Only user marked images have an order, the other are neutral. > If we store an order like a z-level per picture, it works in one view (album) > allowing a picture to be member of multiple presentations with different > rather the order of a group of pictures the property of a presentation, > I'm a bit skeptical to regard the order as a single property of a picture. > Apart from that, I'm lov'n digikam, keep up the good work. Considering that this is among the three highest rated digiKam feature request, I wonder when it will be implemented? It was planned to introduce this patch in (I think) the 0.8 series of digiKam, but this hasn't happened yet - in spite of the fact that we have 0.9.2 already. If I recall correctly, a patch implementing a sorting feature exactly the way your propose had been submitted years ago, but has initially been rejected since it would require a change in the database schema (though I don't believe adding a column should pose a big problem.). > which in most cases should be file name or file creation date. > populated by the order in which the images are added to an album, > as simple as adding an order by column, and all queries could use > I've not looked at the schema of the database, but assume it would be for HTML export) is to manually mess around with filenames, dates, and the like. > a new position in the album would be a great feature.ĭefinitely! I've desperately been wating for years for this feature to be introduced! It's really such a pain that currently the only way to re-order images within an album (e.g. I think being able to reorder images, preferably by dragging them to
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |