[Digikam-devel] About version numbering schema

[Arnd Baecker]

On Sat, 16 Jun 2007, Mikolaj Machowski wrote:

> Dnia sobota 16 czerwiec 2007, Gilles Caulier napisał:
> > 2007/6/15, Fabien <fabien.ubuntu at gmail.com>:
> > > Hello,
> > >
> > > I sent an email about that a few days ago, see here :
> > > http://mail.kde.org/pipermail/digikam-devel/2007-June/012932.html
> > >
> > > <<
> > > Don't you think it's time to use a new version numbering schema ?
> > > I think digiKam has reached its stability point.
> > > For most people, when you see a 0.9.x version, it means the software
> > > is quite close to a stable 1.0 version.
> > > Using version 0.10 let digiKam looks as an immature software that
> > > lacks reliability and features. And I definitively think it's not the
> > > case !

It certainly does not lack reliability!
Concerning features: well, there are quite a few
high rated wishes in the B.K.O
(Hmm: could not find any way to get the results of search in the
B.K.O. sorted by rating, is there any?)

Generally:
- the workflow of tagging,
- filtering of tags, rating, ...
- searches (related to the previous)
requires a lot of thought and (then) improvement.

Going to 1.0 raises the level of what people expect
("oh, still not as good as ..."), while a number <1.0
makes people more relaxed about things...

Well, apart from this, I personally don't care too much
about version numbers.
Much more important is the list of points you raise below!

> > this is not my viewpoint, but i'm developper. For me these features are
> > important for photograph :
>
> With this attitude there will be always new things to include :)

I like this attitude ;-)

> > XMP is not yet supported.
>
> Make it really simple (as newest XnView): just let read unsolved XML in
> separate tab.
>
> > No batch Queue manager.
>
> Wait for KDE4 and promised tools for recording (although I didn't read
> anything new about them lately).
>
> > No search based on advanced metadata.
> > No DB/pictures backup/restore tool.

all very important!

> > No versionning of pictures.
>
> That is big feature. Implementing it properly may take really long
> time...

It also depends on how it is implemented:
For example in http://bugs.kde.org/show_bug.cgi?id=103350
there is a patch to provide simple "versioning",
by just keeping a hidden copy of old versions ...
(well, I don't like that, because I prefer
if the user consciously decides which files to keep and which not...)

And then there is (in the same BKO)
the discussion of action lists to save modifications
of an image in terms of the actions to be used instead
of the actual modified images.

However, I have to admit, that I am always a bit sceptical,
when too many features are added, which go in the
direction of image editing ...
Personally I would prefer if F4 could bring up krita
in a specialized mode, so that it interconnects with digikam
and only a photograph related subset of menus is
available. Then of course krita would need to
store the actions to modifiy an image in some way
(Unfortunately, this would be a much more complicated
project than action lists on the digikam level alone ...)


> You know, from myself I could add several points:

Mikolaj, these are all very important, some of them
are not yet registered in the B.K.O!
(while I am currently on the quest of reducing the number of BKO entries,
here it would be great if you could add the new points! ;-)

> - multiuser, networked database for work eg. in small photo agency
> - support for archiving on various media (in Digikam store only
>   thumbnails with localizations of real images)
> - scripting backend for more automation and better user expandability

With KDE4 I would hope for a tight integration
of KROSS  http://kross.dipe.org/

> - service menus support

I agree. While one can use the .desktop files to get
additional stuff into the right-click menu,
it would be nice to have additional entries in one
of the menus (so that for example also a shortcut can be associated).
Well, it's all discussed here
http://bugs.kde.org/show_bug.cgi?id=88932
and should not be too difficult to implement ...


> - CD/DVD cover printing (both thumbnails and extended descriptions,
>   basing on metadata, Digikam comments)
> - spread collection (not in one directory)
> - file system browsing

Yes, this would be nice!

> - improved cropping (handling of borders, including rotation)

Oh, yes, rotation, that would be good, indeed!
What do you mean by "handling of borders"?
(Well, first we have to get the aspect ratio cropping
working correctly at all, see
http://bugs.kde.org/show_bug.cgi?id=128293
)

> - non reducting rotation

Sorry, what does this mean?

Best, Arnd