>NEGATIVES: Booting time quadrupels now under a quad-core Athlon II X 4 640-
>very bad... KDE?

Still globaly around the same here between 1.9.0 (stable) and 2.0.0 (unstable). I use local QSlite database and local repository on my harddisk.

>Need for backported KDE-components forces many useless and potentialls harming
>instances for a stable system. Why is DK still referring on KDE??? For Gods
>sake we should not walk on swampy ground any more!!! 

DigiKam use a lots of KDE components from KDELibs (widgets, containers)

>Under Windows, it does not KDE tooo, or?

It use KDE too.


>POSITIVES:
>- Many jobs running faster, super!

Which one ?

>- Versioning is wonderful. I am so happy!!!

>- Inverse geolocation does run stable- first time geotagging is usable

thanks.

>- Albumview(?) thumbs-window does not refresh (adapt to changing thumb sizes)

It stil some work to do and test in icon view...

>- Batches: if "waiting queus-configs" are _not_ explicitely modified or set, DK
>crashes!!

A GDB backtrace please...

>- Filter-Option is wonderful; maybe it will be modified to set own
>filter-settings (when fotographing with large format cameras, I had about 20
>filters)

>- Lens correction is still humbling, sometimes it works, sometimes it finds
>wrong lenses (would you considers my suggestion of predefined
>pre-setting-profiles?)). It can not correct panorama, while this should be a
>minor correction: just read out metadata from single pics using for the
>panorama!!)

Lens detection is releavant of Exiv2 and Lensfun libraries.

Exiv2 => use last stable 0.21
Lensfun => use digiKam core version, not shared version. digiKam version is current code from svn trunk of Lensfun project, not yet published...

>- Now I feel the need to use a larger screen- overwhelming functions, somewhat
>worse overview.

I use double screen since a long time at home to manage photo. But we always try to adapt GUI for small screen, as for notebook.

>- Batch suggestion block certain manipulation sequences, as signature then
>sizing or sharpening and then sizing. Many operation sequences are (sorry)
>stupid (compare to workflow descriptions). 

Please, gove more details here...

Gilles Caulier

Gilles:

Thanky you for quick response! DK 2.0 is a huge overall feature
extension and improvement, not only in details!

I'll try to answer between your lines.

Am 15.03.2011 10:06, schrieb Gilles Caulier:
> https://bugs.kde.org/show_bug.cgi?id=268542
> 
> 
> Gilles Caulier <caulier.gilles@gmail.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |caulier.gilles@gmail.com
> 
> --- Comment #1 from Gilles Caulier <caulier gilles gmail com>  2011-03-15 10:06:46 ---
>> NEGATIVES: Booting time quadrupels now under a quad-core Athlon II X 4 640-
>> very bad... KDE?
> 
> Still globaly around the same here between 1.9.0 (stable) and 2.0.0 (unstable).
> I use local QSlite database and local repository on my harddisk.
I use sqlite, too... but

What is "a local repository on mydesktop"?
> 
>> Need for backported KDE-components forces many useless and potentialls harming
>> instances for a stable system. Why is DK still referring on KDE??? For Gods
>> sake we should not walk on swampy ground any more!!! 
> 
> DigiKam use a lots of KDE components from KDELibs (widgets, containers)
Don't you are powerful enough to get rid of this childish underlay? Why
don`t you define the very request _for_ DK? for my feelimg DK has the
potential to controll KDE development- or does anyone nknows other KDE
progs as important as DK? (my be polemic, a little.)
> 
>> Under Windows, it does not KDE tooo, or?
> It use KDE too.
Gnome, Mac, too?
> 
> 
>> POSITIVES:
>> - Many jobs running faster, super!
"rebuild all thumbnails" PLUS "rebuild fingerprints", better, maybe
since 1.90
"write metadata in pic" still too slowly; it looks like, it still does
wrrite in each pic; I fear there is still no pic-wise check, _before_
time-consuming writing procedure.
I suggested that months ago, already.

> Which one ?
> 
>> - Versioning is wonderful. I am so happy!!!
>> - Inverse geolocation does run stable- first time geotagging is usable
> thanks.
> 
>> - Albumview(?) thumbs-window does not refresh (adapt to changing thumb sizes)
> It stil some work to do and test in icon view...
> 
>> - Batches: if "waiting queus-configs" are _not_ explicitely modified or set, DK
>> crashes!!
> A GDB backtrace please...
I experienced before, that KDE bug-tracking system would not worl
properly.... you told me, thgis is not DK's responsabilty...
(for my opinion, another reason _against_ using KDE base, dependency on
KDE, EXIBLib, LENSFUNF, ...)
> 
>> - Filter-Option is wonderful; maybe it will be modified to set own
>> filter-settings (when fotographing with large format cameras, I had about 20
>> filters)
> 
>> - Lens correction is still humbling, sometimes it works, sometimes it finds
>> wrong lenses (would you considers my suggestion of predefined
>> pre-setting-profiles?)). It can not correct panorama, while this should be a
>> minor correction: just read out metadata from single pics using for the
>> panorama!!)
> 
> Lens detection is releavant of Exiv2 and Lensfun libraries.
please forgive me: when you are in a grocery, the seller is responsible
for his goods, not te producer.

When you use those libs, clarify _all_ the details for _your_ product. I
am so sorry: I can not do this job!
> 
> Exiv2 => use last stable 0.21
Hmmm... I would neither know, where to get it nor to install or even to
configure it. I guess you cannot care for all and everything. But: your
users even less!!!

> Lensfun => use digiKam core version, not shared version. digiKam version is
> current code from svn trunk of Lensfun project, not yet published...
Gilles, please help me: as long as wheather and enough time is given, I
try to take pics. I am engineer and I hope, not to limited concerning
software... the same again: you do know DK and its libraries, its
dependencies, interrelationsships, needed foreign modules and libraries
and so on. Do you really suggest to an interested user(!!) to pack its
own DK-Version?
> 
>> - Now I feel the need to use a larger screen- overwhelming functions, somewhat
>> worse overview.
> 
> I use double screen since a long time at home to manage photo. But we always
> try to adapt GUI for small screen, as for notebook.
That's fine, supposed this ;-) !!

I had some ideas to improve, quite sure. Maybe:
- context-sensitive menues and submenues,
- self-learning submenues,
- predefined, user specific workflows
etc., etc.
> 
>> - Batch suggestion block certain manipulation sequences, as signature then
>> sizing or sharpening and then sizing. Many operation sequences are (sorry)
>> stupid (compare to workflow descriptions). 

In DK Handbook, V 1,2 of 10.02.10 (more than one year old!!) describes:
- "Photographic Editing - Workflow" or
- "RAW File Treatment and Color Management"

They explicitely explain to avoid certain sequeces of workflow.

Maybe stupid examples:
- step 1 sharpen the pic; step 2 smoopthen the pic
- step 1 write the signature; step 2 change pic size (with signature!!)

What I mean: many workflow require an _optimal_ sequence for best
results; if not using these, quality decreases unnoticed (for
non-professionls).
On the other side, one can improve a lot, if knowing and doing right.
Why ot used it standardized within DK?

So, my suggestion is to _predefine_ some workflows (maybe by asking
professionals) and to block quality decreasing sequences.

Of course, one could use even graphical surface and a multi-choice-test
to find our users wishes and to (automatically) suggest optimal pathes
to achieve these (and to avoid risky ways) .

I hope I could clarify a little.
> 
> Please, gove more details here...
> 
> Gilles Caulier
> 


Axel Krebs

P.S.: Two pics for DK splashscreen- you my us them

Uh oh, doesn't it make sense to report each issue in a separate report? If this discussion goes on like this, it becomes very hard to read and follow.

Am 15.03.2011 15:12, schrieb Christoph Feck:
> https://bugs.kde.org/show_bug.cgi?id=268542
> 
> 
> 
> 
> 
> --- Comment #3 from Christoph Feck <christoph maxiom de>  2011-03-15 15:12:43 ---
> Uh oh, doesn't it make sense to report each issue in a separate report? If this
> discussion goes on like this, it becomes very hard to read and follow.
> 
You are certaninly right, thatswhy I send a first very short statement.
And answerded Gilles message (including proposals, requets,..) _not_ "to
the list", but to "sender only".

Sorry, maybe s.th. went wrong.


Axel

(In reply to comment #2)

I'd just like to address this particular comment:

"Don't you are powerful enough to get rid of this childish underlay? Why
don`t you define the very request _for_ DK? for my feelimg DK has the
potential to controll KDE development"

We do not want to control KDE development, nor any other than our own. We are more than happy to build upon KDE technologies, which are by the way the best "underlay" out there as of today. Saying that it is a childish is at least...well, childish. You obviously have no idea what the "underlay" is and what all provides us, for free. Likewise, KDE is proud to have an application like DigiKam on the front line and we have absolutely no intention of breaking up this mutual feeling. DigiKam is a KDE application, always was and always will be. Deal with it. Or fork it and rewrite it ;)

Axel,

There are a lots of demand in this report. This is not adapted to bugzilla. One demand by entry, else it's the hell to manage...

Please open files accordingly...

Gilles Caulier

Gilles:

too many details. It was meant to acknowledge the progress.

Axel
--
Am 12.12.2011 20:08, schrieb Gilles Caulier:
> https://bugs.kde.org/show_bug.cgi?id=268542
> 
> 
> Gilles Caulier <caulier.gilles@gmail.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |RESOLVED
>          Resolution|                            |INVALID
> 
> 
> 
> 
> --- Comment #6 from Gilles Caulier <caulier gilles gmail com>  2011-12-12 19:08:44 ---
> Axel,
> 
> There are a lots of demand in this report. This is not adapted to bugzilla. One
> demand by entry, else it's the hell to manage...
> 
> Please open files accordingly...
> 
> Gilles Caulier
>