[Digikam-devel] [Bug 268542] COMMENT: (much) more Pros than Contras !!! :-) :-) :-) ...

Tue Mar 15 13:22:45 GMT 2011

https://bugs.kde.org/show_bug.cgi?id=268542

--- Comment #2 from Axel Krebs <axel krebs t-online de>  2011-03-15 14:22:43 ---
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 at gmail.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |caulier.gilles at 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

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.