[Shotwell] Some More Suggestions (Re: suggestions)

[Eric Gregory]

Hi Oliver.

Taking your suggestions one by one...


On Tue, Aug 2, 2011 at 4:38 PM, oliver <oliver at first.in-berlin.de> wrote:

> View:
>  - Rejected-only view  [ at the moment it is All + rejected; btw: "All" is
> a misnomer to be picky;
>                          "All" would of course include "Rejected" ]
>    (that feature makes sense to view again the deselected files only, e.g.
> as last
>    step before deleting them.9
>
>  - n-stars-only view (additionally to >= n-stars view)
>    [ this feature is not as important as the "Rejected-only view";
>      maybe it could be part of an "expert view" or "detailed view menue"??
> ]
>

All of this is already possible using the saved search feature of Shotwell
0.10 or newer.  Open Shotwell, hit Ctrl-S, and you can create just about any
rating search criteria you'd ever need.



> Data-Export:
>  - Export of Star-Numbers and Tags (and other kind of information?) for the
> files
>    (possibly as *.txt, *.csv, *.xml)
>

Agreed, this would be useful. I filed a new ticket on this here:
http://redmine.yorba.org/issues/3909

Also note that some information (tags, titles, etc.) can be stored in the
image files themselves if you enable metadata writing in the preferences.



> File-Comparison:
>  - compare files in the collection based on file-contents (byte-by-byte or
> checksum)
>  - compare data-only (e.g. ignoring jpeg/exif-headers, just comparing the
> picture data)
>    also as byte-by-byte or checksum
>    [ this makes sense for multiple copies of a file, which just have
> different jpeg/exif
>      headers (maybe by adding jpeg-comments), but which is nothing new
> regarding the
>      picture data itself ]


This doesn't seem like something that would typically be found in a photo
manager. We already scan for duplicates when importing. What would the
use-case for this feature be?



> Exporting Path:
>  - Exporting Path of one  or more pictures by drag-and-drop;
>    for example if you drag&drop files into a terminal-application,
>    the terminal-application gets the paths of the files as pasted text.
>    [ This makes possible things like    cp
>  <dragged-and-dropped-list-of-files>  <working_dir> ]
>
>  - The same via menue: "Copy location" (Ctrl-C) for one or more than one
> file and then paste
>    (a la Ctrl-V)
>

We have an open ticket on this:
http://redmine.yorba.org/issues/1563



> Supporting Multiple File-Folders:
>
>  - (1) Support more than one directory as file-repository
>  - (2) Support easy change of such repositories from one place to another
>        (e.g. files must be shipped from one disk to another)
>  - (3) Support changable media
>
>  [ all these three might be possible, if the databases are held locally to
> the
>    folders where the pictures reside; the shotwell-index then is a
> collection
>    of links (or include's) to (of) the many possible picture-directories.
>
>      (1)...(3) can be done via shotwell including/linking-in
> picture-collections
>                as seperated files-plus-database-combinations;
>                shotwell-index then would be a meta-index that points to
>                directories of picture-files and a database in the "root"
>                of each of those picture-directories (like mounting-in a
> complete repository
>                 that also contains the index) ]
>

1. We already support following links, which should be fine for most power
users out there.
2. I'm not entirely certain what you mean by "repository" here.  Are you
referring to the database, the photo files, both...?
3. We have an open ticket for this:
http://redmine.yorba.org/issues/2954


Supporting big number of files efficiently:
>  - some thousands and some tenthousands of files should be handled
> efficiently
>    and with high performance (of course reliable also)
>
>  - to be honest: some hundred-thousand files might be the next step
>
>    (which I did not reached so far; I just started with photography few
> years
>     ago and the delimiting software possibilities were rather blocking easy
> photographing,
>     because software often made me thinking to much about the software, and
> how and where to store
>     the files... but bettr would be: this is transparent and most of the
> time you think about
>     photography and the shot photographs 8which I hope are   shot well :-))
> )
>

"Reliable" or "efficient" aren't very precise terms. If you think there's
something we could optimize more you're probably right! Contributions in
this area, whether tests, code reviews, or patches are always welcome.


One remark on speed/performance: Shotwell seems to be comparingly fast.
> But I have less than 500 pictures used in shotwell, and in my F-Spot
> directory I have  more than 30.000.
>
> If shotwell keeps scaling well, it will be faster than f-spot even with
> that
> number of pictures. I hope this holds true. I'm not sure here, because
> f-spot also was "fast" with just a few files.
>

The startup speed will of course diminish with more files, but it shouldn't
be unacceptably slow with collections of hundreds of thousands of photos. We
know we have users who have this many photos, and no complaints from them
about speed -- so far!


  - Eric