[Digikam-users] Digikam and the KDE

[todd rme]

On Fri, Oct 7, 2011 at 8:05 PM, Paul Verizzo <paulv at paulv.net> wrote:
>
>
> David Vincent-Jones wrote:
>
> David, I posed the same question when I started using digiKam via the
> Windows KDE project.  That was before Giles and Friends started compiling DK
> for Windows. It was a monster installation due to all the KDE support
> structure and mandatory inclusion of apps that I would never, ever use like
> a scientific calculator.

If your distribution is pulling in scientific calculators with
kde-runtime  then that is a problem with your distribution, not with
KDE.  KDE has no such requirements.  Looking at my distribution, KDE
has absolutely zero workspace (i.e. plasma) or KDE application
dependencies.  It requires kdelibs, kde-runtime, and some other mostly
independent libraries.

> On a scale of 1 to 100 what I know about programming is about a "2".  And
> I'm very much struggling with all this "desktop environment....but wait,
> it's really an OS or something, too."

I am not sure who told you this.  KDE is far from an OS.  kdelibs
provide various tools that programs could use to provide important
functionality not provided by Qt, but that doesn't make it an OS by
any stretch of the imagination, and much of it is, in fact,
os-independent..  Then there are various other slightly higher-level
tools that use kdelibs but also just provide additional functionality
applications could use.  This includes things like kde-runtime (which
provides things like file system access, file picker dialogs,
removable device handling, and many other core capabilities),
libkgeomap which provides mapping and navigation capabilities, various
tools like nepomuk and libkexiv for metadata handling, and so on.

Then there is the KDE workspace, plasma, which provides a desktop and
panel. Applications that do not go in the desktop or panel (like
digikam) do not depend on the workspace, and if something is trying to
install the workspace with digikam then that is a mistake on the part
of the people who made the package.

Then there are various KDE applications, like digikam, dolphin,
marble, calligra/koffice, and many others that make use of these tools
to provide core functionality.

Without these tools at their disposal, all the things I just listed
would need to be re-written from scratch for each application, which
would be a massive undertaking for an application as complex as
digikam.  We would probably talking years during which digikam would
be missing critical features, not counting how long it would take to
work through all the new bugs a new implementation would require.
With these tools applications can generally largely focus on the user
interaction parts and tasks specific to that application, while stuff
common to many applications is provided for them.

Looking at digikam dependencies, it uses KDE libraries (kdelibs,
kde-runtime, or more fine-grained libraries) for these tasks at least:
local and remote file access, web handling, mapping, addressbook,
tags, video playing, and raw image handling.  All of these features
would need to be re-implemented or ported to other libraries.

> But I do know this: I see a lot of
> programs out there that furnish apps for all of the Big Three OS's. Off the
> top of my head, most browsers except IE, Picasa, and Xnview.

The lack of windows support is not so much a fundamental problem with
KDE, it is a problem that there just aren't enough people interested
in getting it working.  Dropping KDE would make this far worse, since
digikam developers would have to re-implement everything for each OS.
And you would still have the problem that there aren't enough people
interested in getting it working, but the people who are interested
would find themselves with many times more work to do, so support on
OS's other than Linux would get far worse rather than better.

> The culprit in Windows is repeated sessions of
> "kioslave.exe" running, which - I think - come and go with photos or
> processes.

That is exactly my point.  kioslave.exe is something provided by KDE
for accessing files in a transparent manner.  As far as the
application is concerned accessing file on a local filesystem, a
remote filesystem, even a website is identical.  It is all hidden from
the application so it doesn't need to know or care where the file came
from.  If digikam ditched KDE, they would have to re-implement, from
scratch, all of those features.  Do you really think they, working
alone, would be able to make an implementation that works across all
desktop environments and requires less resources than the KDE
implementation?

So to put it simply, kioslave.exe is what lets you access your files.
Without that, or something like it, digikam would not be able to
access pictures at all.

> Charles Kettering, inventory of the electric starter and the diesel electric
> locomotive, is famously quoted today still as a reminder for engineers:
> "Parts that aren't there cost nothing and never go wrong."  Decades later
> and with computers I very much see how lots of code tends to lead to lots of
> things going wrong.

Except the only thing that you can cite going wrong is absolutely
critical, core functionality for digikam.

I should point out that KDE is currently working on something called
"frameworks".  Basically they are making it so their previously
monolothic packages like kdelibs and kde-runtime are split into a
large number of mostly or completely independent packages.  That means
that applications like digikam will only have to pull in the bits and
pieces it needs, rather than everything.  This is expected to be
finished sometime next year, but it may take longer since it is far
from a trivial task (since there are currently lots of
interdependencies between parts that need to be removed or split out).
 So within the next 2 years or so this should cease being an issue
entirely.

> I hope I don't sound unappreciative to the DK team, nothing is further from
> the truth. But like you, I look at the project with clean, emotionally
> unattached eyes and am compelled to ask, "Why?" And then, "Is to too late or
> too big of a project to divorce DK from KDE?"

Yes, it is far, far too late.  Unless you are willing to deal with
likely a year or two of no new features and massive feature
regressions, and likely several more years of tons of bugs.
Frameworks, which does exactly what you are requesting, will almost
certainly be done before digikam has a chance to re-implement all
those features anyway.

-Todd