[Shotwell] some general arguments on devel and unix toolbox and so on (Re: Two features I'm really missing ....)

[oliver]

On Mon, Oct 03, 2011 at 10:07:42PM +0200, pt wrote:
> On 29 September 2011 21:31, Dougie Nisbet <dougie at highmoor.co.uk> wrote:
> >
> > I'm all for innovation and progress and don't want to fall into the 'but
> > software x does it this way' trap, but, er, this is something that f-spot
> > does this really well. Single keypress, (t) for tags, then auto-completion
> > on tab-press, or cycling through valid tags (just like bash shell). It also
> > allows editing (like 'Modify Tag') in the same way as shotwell, by simply
> > deleting a tag from the photo. Elegant and intuitive.
> 
> Dear Dougie, it seems that you and me are the only people with a
> complex tag-tree, or at least we are the most `vocal' ones, at least
> judging from this mailing list ;-)
> 
> I feel your pain, and I am eagerly awaiting for a decent solution for
> the tagging issue.
> 
> F-spot was doing the tagging pretty good. And I would still be using it, but:
> 
> 1. f-spot is SSSSSLLLLLLLLLLLOOOOOOOOOOOOWWWWWWWWWWWW, while shotwell
> seems very fast in comparison;
[...]

If you switch off the slide-show it at least becomes more usable...

[...]
> 4. f-spot is no longer being actively developed, and the current
> version is quite buggy, far from usable.
[...]
Oh, really?

I thought it just became thrown out from Ubuntu-distri.

Didn't know it'a already a dead project.

You could pick it up if you wish to? ;-)




[...]
> 5. last but not least, f-spot is written in C# (or whatever they call
> it) and uses the `mono' libraries, thus I guess one can not easily
> borrow pieces of code from it and using it on other software (I'm not
> developer, so this is just my guess).
[...]

Thats one of the wrongest way to do it?

Picking up M$ crap ideas and port it to the free world.

But it's also wrong doing it the other way around, isn't it?

  http://www.fefe.de/nowindows/




> 
> Bottom line:
> 
> A. I use Geeqie
[...]

Never heard of it before.

[...]
> B. I use ExifTool to do more complex mass-tagging, like conditionally
> removing or renaming a specific tag recursively into directories, or
> adding several tags of copyright informations, locations and such.

Heard of it, but not used it so far.


> 
> C. I use Gimp to edit photos, and I manually keep track of the file
> versioning (that was OK in f-spot, providing you had the `exiflow'
> extension installed).
[...]

I also use Gimp, but it#s a pitty that it does not allow more than 8-Bit
editing so far. But this gap will be changed... just don't know when.


There are some other pic-edtors which do better in this respect.
Just forgot the names. I could look for them if you are interested.



> 
> D. I (will) use Shotwell to *watch* my picture collection and to do
> quick tag-searches/filtering, once the hierarchical tagging will be
> stable enough

I use it for temporarily selecting and showing pics to others, and to select
most interesting pics from the huge number of pics I shot, when I tale my camera with me.

f-spot so far (without slideshow) is my current archive.

But I try to maybe switch to shotwell.

I had testes shotwell with importing one huge (num of files > 100k photos) pic dir.
It behaved not well.
But I'm not sure if this is a shotwell issue or a filesystem issue.
more then num of 100 k files in one dir might also be a problem from the
filesytstem... or from GTK-libs that are above the filesystem.

So I might check that later with more realistic imports, when
files are seperated into many different directories, with one direcxtory per day.

And I'm sure, I will NOT shot 100 k files at one day.

But so far I did not located, where the bottleneck is.
At some of my analyses it looks like database problem.
But i could not go deeper into it.
And since that trial I did not looked at exploring shotwell in detail again.

If it is NOT a shotwell problem, then switching from f-spot to shotwell
would make sense immediately for me, because all the other things like
nested tags seem to be solved, at least in principal (bugs might be there,
but the shotwell-team seems to be interested to make shotwell really becoming good.
So I think it will become better and better. I'm confident here, and hope I
have the right impressions ...)



[...]
> In an ideal Unix-shaped world, we should have *one* application to do
> the tagging, *one* to do photo-collection showing and filtering, *one*
> to edit photos and so on, all *called* from one photo management
> `mainframe', for so to speak.
[...]

Thats the unix-toolbox approach and I really like it.

On the other hand, one application that has access to more than one of those functionalities also is OK.

If the seperated tools are implemented as library PLUS user-interface (CLI,
qand maybe additionally GUI) then a bigger application also could use the
libraries directly, instead of using system() or popen() stuff.

So, if the tools stand-alone but lib-based, then a bigger application could do both:
using it cia system(/)/popen() or fork/exec as well as using the libraries directly.

I think, this would be good design.

At the moment I just want to mention: that shotwell is well supporting
keyboard, makes ist a superior tool to many other picture tools, which do it
rather half-heartedly...


> 
> My heart bleeds seeing that we are wasting precious volunteer
> developers' time trying to reinvent the wheel with every new
> application.

In general I agree here.

Nevertheless as far as I can see it, shotwell really makes it better than f-spot
as well as Digikam.

One strange issue is somehow, that it uses "just another programming language".
vala is not well known.

If I would have to start a new project i would use OCaml.
But Vala might have some advanbtages which I just don't know at the moment.
At least it seems to be good integrated into the Gnome-environment.
So, if thats one mayjor goal for the shotwell development team, and if that
assumption I just mentioned is true, then the decision was a good one.

(I just don't know Vala in detail. On very fast glimpse at least it looked
 ok.)


> Perfect example: DigiKam. It is an over-complicated
> software that does *everything*, including making coffee,

No.
It was emacs that was intende to become a coffee machine ;-)


[...]
> I wish I could help more beside doing bug-spotting, but I'm not a
> developer. Maybe in the future ;-)
[...]

I'm also not a shotwell-developer, but IMHO looking at the dark sides also can
help in development.
Thats, how feedback works: if you find the bugs, they can be corrected.
If bugs are not found or reported to the developers, things can not become
better.

So, even mourning about bugs is helping to make things better.

Thats my opinion.

Ciao,
   Oliver