Hello,
I'm new to this list, so I missed the beginning of the thread,
but I also have some suggestions.
Maybe they are already in discussion, then please forget it.
Maybe they are new suggestions, then I would like to have
some attention on those points.
Here my list of suggestions, which are rather feature wishes:
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"?? ]
Data-Export:
- Export of Star-Numbers and Tags (and other kind of information?) for the
files
(possibly as *.txt, *.csv, *.xml)
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 ]
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)
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) ]
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 :-)) )
I hope this makes sense to you, and may also be worth becoming implemented.
Even I used shotwell just once and experimental (just to classify
some pictures (here the stars-/tags-export feature mentioned above would be
fine)),
it looks to me as the MOST-PROMISING OSS software around, to handle
picture collections. (The editing features are not so important for me,
because for that there are a lot of other programs out there. But the
handling/managing,
storing, retrieving and tagging and judging issue is not very well done in the
other software
which I saw so far. here shotwell does it much better.)
To be here on the list means: shotwell really makes sense to me.
It uses concepts (like keyboard-oriented handling) which makes the work easier.
So, that I come up with so much suggestions is not to mourn about shotwell,
but to see that there is a good piece of software, which can be enhanced even
more.
(I have not decided to switch to shotwell so far; I'm exploring...)
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.
(I toggled between digikam and f-spot more than once; I hope shotwell
makes it better; I now have too much files for changing the tools
too often.)
If shotwell will not scale good, it might be enhanced.
(And maybe - under certain circumstances I even could help coding, but at the
moment
I'm just a user who wants to help the shotwel-project to become better by
doing some suggestions/feature-wishes. I hope this is OK for the developers.
At the moment I just want to thank the shotwell-developers for their great
work.
Shotwell is so much easier to use than all those mouse-oriented programs.
I hope at the other points (scalability, usability, new features) it will also
be on top....)
Best wishes,
Oliver
_______________________________________________
Shotwell mailing list
[email protected]
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
