[Digikam-users] Digikam and the KDE

[todd rme]

On Sun, Oct 9, 2011 at 11:10 AM, sleepless <sleeplessregulus at hetnet.nl> wrote:
> Op 09-10-11 09:42, todd rme schreef:
>>
>> On Fri, Oct 7, 2011 at 8:09 PM, sleepless<sleeplessregulus at hetnet.nl>
>>  wrote:
>>>
>>> I thought there was an effort a while ago to port digikam to quicktime to
>>> make it independent from kde, which makes it dependent of quicktime.
>>
>> I think you mean Qt.  Qt is a widget toolkit, quicktime is a (mostly
>> obsolete) multimedia codec and container.
>
> thanks, and where is Qt standing for?

It doesn't stand for anything.

>>> I think it would be great if there came  a fork of digikam that takes the
>>> grandiose, excellent, wonderful, splendid, magnificent, special, unique,
>>> exquisite, exclusive, unparalleled digikam architecture  as a fundament
>>> and
>>> build it up from the ground without all the needless complexities that
>>> makes
>>> it so prone to trouble.
>>
>> And how many years are you willing to wait for that?
>
> I think 20 enthousiasts can do it in 2 years, that would be 1 from each
> 300.000.000.

So 2 years of serious feature regressions and no improvements in
digikam?  Are these 20 enthusiasts experts in hardware management,
filesystems, network handling, or other such tasks like the developers
of their KDE counterparts?  If not then you probably need to add at
least another 6 months to a year just to learn how those systems work
on the various operating systems.

As I said, the modularization of KDE, so that digikam will only pull
in the bits it absolutely needs, will be done before that, letting
digikam focus on doing digikam-specific things.  The end result will
be even better.

And if there are serious problems with KDE, and we do have that many
people willing to spend that much time, why can't they just spend the
time improving KDE?  They would have the benefit of an existing mature
code-base, experts who would be able to help them, and far more users
to help find and isolate bugs.  So, considering KDE is going to be
modularized before digikam can be moved away from KDE, what benefit is
there from starting over from scratch compared to improving what is
already there?

>> That is ignoring the fact that digikam would become far more complex.
>>  Add to that the fact that with far fewer people using it than are
>> using the more general KDE-provided functionality bugs will be more
>> common and harder to track down, and with far fewer developers bugs
>> will take longer to fix.
>
> Bugs should not be there!

They WILL be there, whether you think they should or not.  All complex
software has bugs.  Windows has bugs.  Mac OS X has bugs.  Qt has
bugs.  Digikam has bugs that have nothing to do with KDE.  If digikam
developers cannot make the digikam-specific portions without bugs,
what makes you think they will be able to do other things without
bugs?  Especially considering that many of the components in KDE were
developed by experts in those particular areas of software design,
experts that the Digikam team does not have.

> Imagine the airplane industry worked this way,
> sending the planes in the air and fix bugs after every crash and then with
> every fix introducing three new ones.

Yes, that is why no test pilot ever died in a crash...oh wait.
Aircrafy manufacturers also have the benefit of massive resources for
testing, most of the components are mechanical and thus can be
directly observed, a dynamically stable system them can survive
multiple simultaneous system failures, and highly-trained operators
who understand how the system works know how to handle serious
problems.  Nevertheless "bugs" are still found, and they still kill
people.

Digikam has none of these benefits, it is mostly developed by a small
group of volunteers, the functioning of the components is not visible
to the naked eye, a single serious problem will almost certainly bring
the whole system down, and the users have little, if any, training or
understanding of how it works.

> I have been programming assembly and later on C++. The hardware was the only
> limitation. But after that the higher level languages took over, and every
> next level adds severe limitations. I think kde is in this respect the top
> level programming language.

KDE is not a programming language, it simply provides libraries that
can be used  by other programs written in any combination of a half
dozen other languages.  Qt is much closer to a programming language
than KDE is, since it adds a bunch of fundamental new features to C++
(like signals and slots).  As I keep saying, what KDE does is provides
capabilities that digikam needs.  These capabilities have to be
provided one way or another, either digikam can use capabilities
provided by someone else like KDE, or they can program it themselves,
ultimately digikam needs to do the same things KDE does.  It just
won't be able to do them as well, as cleanly, as quickly, as reliably,
or as soon without using KDE (or something like it).

-Todd