Digikam and the KDE

[davidvj]

CONTENTS DELETED

The author has deleted this message.

[Andreas K. Huettel]

On Freitag 07 Oktober 2011 19:32:39 David Vincent-Jones wrote:
> Of course this is plain heresy but .... looking at digikam installation
> problems I have had and that others share on the forum, many of the
> difficulties appear to be rooted in the tight integration of the program
> along with the requirements of its desktop environment.

Actually most of *these* problems occur because people try to run digikam with
libraries that do not ship with the installed Linux distribution, or try to
combine different sets of incompatible libraries. Seriously, if you want to be
bleeding edge, either compile yourself (not too complicated), or use a
bleeding edge distribution. :)

> Are there graphic, or other, functions that can only be done under this
> environment? I hardly think so. Is my desktop improved by the use of
> this emulator? If so I do not see it.    ....... Are there any thoughts,
> or moves towards, extracting Digikam into a more neutral environment?

Probably impossible. The integration is pretty deep, and digikam uses a lot of
KDE features. Then, of course, just because you're too lazy :o) to install
kdelibs, that's not really a reason for the rest of us to lose the tight
integration into our favourite desktop environment...

Cheers,
Andreas

--

Andreas K. Huettel
Gentoo Linux developer
[hidden email]
http://www.akhuettel.de/


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Paul Verizzo]

David Vincent-Jones wrote:

Message: 4
Date: Fri, 07 Oct 2011 10:32:39 -0700
From: David Vincent-Jones <[hidden email]>
To: digiKam <[hidden email]>
Subject: [Digikam-users] Digikam and the KDE
Message-ID: <1318008759.1767.131.camel@david-desktop>
Content-Type: text/plain; charset="UTF-8"

Of course this is plain heresy but .... looking at digikam installation
problems I have had and that others share on the forum, many of the
difficulties appear to be rooted in the tight integration of the program
along with the requirements of its desktop environment.

As far as I can tell this is the only program running on my system that
requires a very large desktop emulator, and of a specific release build,
to operate correctly. To me, this is more than highly reminiscent of the
Microsoft bloatware from which I fled some years ago.

Are there graphic, or other, functions that can only be done under this
environment? I hardly think so. Is my desktop improved by the use of
this emulator? If so I do not see it.    ....... Are there any thoughts,
or moves towards, extracting Digikam into a more neutral environment?

David

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.  

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." 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 latter is a nice graphics program, although not near the pro level of DK.  

A few weeks ago I pointed out here that DK consumes huge amounts of RAM, even just sitting without anything open.  It was several times that of my Adobe Elements 8, and I think of Adobe as being the true bloatware company, moreso than Microsoft. The culprit in Windows is repeated sessions of "kioslave.exe" running, which - I think - come and go with photos or processes.  

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.  

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?"

Thanks for listening, Giles and Friends!

Paul Verizzo





_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Rinus]

kde is not my favorite desktop environment. I prefer gnome. but that´s only a matter of taste.
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 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.

Regards,
Rinus

Op 07-10-11 19:48, Andreas K. Huettel schreef:

On Freitag 07 Oktober 2011 19:32:39 David Vincent-Jones wrote:

Of course this is plain heresy but .... looking at digikam installation
problems I have had and that others share on the forum, many of the
difficulties appear to be rooted in the tight integration of the program
along with the requirements of its desktop environment.

Actually most of *these* problems occur because people try to run digikam with 
libraries that do not ship with the installed Linux distribution, or try to 
combine different sets of incompatible libraries. Seriously, if you want to be 
bleeding edge, either compile yourself (not too complicated), or use a 
bleeding edge distribution. :)

Are there graphic, or other, functions that can only be done under this
environment? I hardly think so. Is my desktop improved by the use of
this emulator? If so I do not see it.    ....... Are there any thoughts,
or moves towards, extracting Digikam into a more neutral environment?

Probably impossible. The integration is pretty deep, and digikam uses a lot of 
KDE features. Then, of course, just because you're too lazy :o) to install 
kdelibs, that's not really a reason for the rest of us to lose the tight 
integration into our favourite desktop environment...

Cheers, 
Andreas

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Subash]

On Fri, 07 Oct 2011 10:32:39 -0700
David Vincent-Jones <[hidden email]> wrote:

> Of course this is plain heresy but .... looking at digikam
> installation problems I have had and that others share on the forum,
> many of the difficulties appear to be rooted in the tight integration
> of the program along with the requirements of its desktop environment.

generally agree with your opinions there. digikam is so tightly
integrated with the kde desktop environment that it becomes very
difficult to upgrade the application without upgrading KDE too. a huge
ask. i don't really know what the gains of such tight integration are
but i do know you are losing a lot of potential users. there'd be a lot
more users if digikam were a little more independent of KDE and hence a
little more easy to compile and run.

i am on the latest stable release of slackware yet can't compile DK
2.1.x or 2.2.0 because i need to upgrade KDE from 4.5.5. i think i'll
stick to DK 2.0 thanks...

regards, subash
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[todd rme]

On Fri, Oct 7, 2011 at 8:05 PM, Paul Verizzo <[hidden email]> 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
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[todd rme]

On Fri, Oct 7, 2011 at 8:09 PM, sleepless <[hidden email]> 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.

> 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?

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.

-Todd
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Le 09/10/2011 09:42, todd rme a écrit :

> And how many years are you willing to wait for that?

and there is an easy solution: compile digiKam for any kde version and
make it available for your prefered distribution.

The way was show here several times. I think digiKam is much easier to
compile today than it was some years ago (the fact that I could do is
a proof :-))

jdd

--
http://www.dodin.net
http://www.youtube.com/user/jdddodinorg
http://jdd.blip.tv/
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Rinus]

Op 09-10-11 09:42, todd rme schreef:
> On Fri, Oct 7, 2011 at 8:09 PM, sleepless<[hidden email]>  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?
>
>> 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.
>
> 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! 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.
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.

Just thoughts, I admit to be ignorent!
Rinus
>
> -Todd
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Rinus]

Op 09-10-11 10:00, jdd schreef:

> Le 09/10/2011 09:42, todd rme a écrit :
>
>> And how many years are you willing to wait for that?
>
> and there is an easy solution: compile digiKam for any kde version and
> make it available for your prefered distribution.
>
> The way was show here several times. I think digiKam is much easier to
> compile today than it was some years ago (the fact that I could do is
> a proof :-))

That might be true, but I think we should not pretent that it is easy
for common users, it is hard. So we should say: It is not easy but if
you want you may ask for help and we will do the best we can.
Rinus
>
> jdd
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Martin (KDE)]

Am Freitag, 7. Oktober 2011 schrieb sleepless:

> kde is not my favorite desktop environment. I prefer gnome. but
> that´s only a matter of taste.
> 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 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.

I think you miss the point. If you want to run a Java program you
first have to install all required Java tools and libs. If you want to
run a .Net program you have to do the same for .Net. The same is true
for digikam.

If you want to run a Java 6 program with a Java 5 Environment it may
work but most likely will not. You have to install Java 6 first. Same
is true for Digikam. Version 2.2 may require some libs from KDE 4.6 so
you can no longer simply compile it for KDE 4.5. You have to install
KDE 4.6 first (or any other KDE version required with DK - numbers are
just examples).

The difference is that Java release new versions every four (or even
more) years and KDE every half a year. But this is simple open source
strategy. If you need a longer period you can not run recent software.
It is as simple as that.

And regarding needles complexity: I use DK because of the complexity
and the integration into KDE. Some of the functionality I use
regularly some other every now and then. So most of them are not
needless.

Fedora for example ships DK version 1.9. If I want to use 2.x I have
to use kde-testing packages (which are testing and possibly not that
stable). But DK 1.9 does all I need, so why should I update? I will
update with the new fedora 16 in two or three month.

Regards
Martin

>
> Regards,
> Rinus
>
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[todd rme]

On Sun, Oct 9, 2011 at 11:10 AM, sleepless <[hidden email]> wrote:

> Op 09-10-11 09:42, todd rme schreef:
>>
>> On Fri, Oct 7, 2011 at 8:09 PM, sleepless<[hidden email]>
>>  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
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Martin (KDE)]

Am Sonntag, 9. Oktober 2011 schrieb sleepless:
> Op 09-10-11 09:42, todd rme schreef:
> > On Fri, Oct 7, 2011 at 8:09 PM,
sleepless<[hidden email]>  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 is the name of the toolkit. Same as GTK is the name of the toolkit
gnome is based on.

>
> >> 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.

In theory yes, in praxis no. Why should 20 enthusiasts take two years
of their time to port a running and working program to a different
toolkit? Wouldn't it be better to take the same time to improve the
already available program (and the underlying tools)?

>
> > 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! 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.

These are different beasts. Take the NASA as an example. They use more
than 20 years old software and hardware to send rockets into the
orbit. They use different programming systems and because of the risk
different methods. And in the end the machines are way more expensive
than a simple computer including the programs. And believe it or not,
there are bugs in the airplane software which causes many dead
peoples.

> 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.

To my point it is the other way around. I have more flexibility to do
what I want and have to do instead of working around the limitations
of the programming language.

> I think
> kde is in this respect the top level programming language.

May be or not. It is easy said, not that easy proven and if so hard to
change.

Martin

>
> Just thoughts, I admit to be ignorent!
> Rinus
>
> > -Todd
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Mark Fraser]

On Sunday 09 Oct 2011 10:40:25 todd rme wrote:

> On Sun, Oct 9, 2011 at 11:10 AM, sleepless <[hidden email]> wrote:

> > Op 09-10-11 09:42, todd rme schreef:

> >> On Fri, Oct 7, 2011 at 8:09 PM, sleepless<[hidden email]>

> >>

> >>  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.

 

According to http://en.wikipedia.org/wiki/Qt_%28framework%29 "The toolkit was called Qt because the letter Q looked appealing in Haavard's Emacs font, and "t" was inspired by Xt, the X toolkit."

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Remco Viëtor]

>
> Fedora for example ships DK version 1.9. If I want to use 2.x I have
> to use kde-testing packages (which are testing and possibly not that
> stable). But DK 1.9 does all I need, so why should I update? I will
> update with the new fedora 16 in two or three month.

And that's another point...
For how many other programs do you want the latest version RIGHT NOW?
Digikam 2.2.0 got announced last tuesday (so 5 days ago)... For OpenSuse 11.4,
there was a package available for a standard install _2_days_ after the
announcement (that package had problems with a KDE 4.7.1 system, where the
11.4 standard version is KDE 4.6). That is very fast in my book.

For Ubuntu, Philip Johnsson provides packages within a few days, for specific
Ubuntu versions. Again, very fast work.

If you insist about using the latest version, at least make sure you know what
you are doing... If you start combining different repositories, NO ONE will
guarantee that everything works, and you are on your own.

So I agree with Martin here, I guess...

Either have a bit of patience and give packagers time to create the packages
for your version of whatever distro you use, or compile Dk yourself (and of
course make sure everyting is backed up correctly etc. before upgrading).

Remco

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Benjamin Girault]

2011/10/9 sleepless <[hidden email]>:
> Bugs should not be there! 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.

Think about what the software of an airplane is doing. Each of its
tasks alone is fairly simple (read a sensor, display its value or act
according to its value), and the difficulty does not come from that,
but from the scheduling of those tasks such that each is performed
within the required time. Thus their requirements are completely
different: no bugs. However, this is achieved at the cost of
efficiency: the cpus are often waiting for tasks to do, and the
hardware is kept to a minimum (there are in CPUs made for desktop PCs
a lot of non determinism, both hardware and software, that prevent one
from proving anything software related, thing for example of when a
thread is taking over within a single core CPU, or when an interrupt
can happen...) to have a good model of the hardware (which is required
to prove softwares).

The main tasks of programmers is then to do an efficient and correct
scheduling, and prove it (which involves not only engineers but also
researchers). People in the critical embedded programming have
dedicated tools (such as Scade) to do this. Proving Qt, KDE or Digikam
is something noone want, or even is able, to do, and using tools like
Scade does not make any sense. Thus, bugs are expected.

My guess is that if someone claims to write programs without bugs, it
can mean 2 things, either that this person is lying or is burying is
head in the sand, or that he never wrote a program of more than a
hundred lines.

Also, do not mix up programming language and library. The kde
libraries, and QT, are written in C++, which is a low level
programming language, are high level libraries. Programming languages
of higher level are Python, Java, OCaml, Haskell, Prolog, etc... What
you could think as limitations for those are rather possibilities. For
example, with functional programming languages (like OCaml and
Haskell) it is much easier to prove programs. For high level
libraries, it allows the programmer to both code faster, and not to
have to reinvent the wheel.

--
Benjamin.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Rinus]

The main point of my thoughts is the gut feeling that we are going down,
because of the greatness and complexity of kde and digikam.
Bugfixing and fixing the bugs in the fixes is a downward spiral, at some
point you need to rethink, redraw and rebuild.
Rinus
Op 07-10-11 19:32, David Vincent-Jones schreef:

> Of course this is plain heresy but .... looking at digikam installation
> problems I have had and that others share on the forum, many of the
> difficulties appear to be rooted in the tight integration of the program
> along with the requirements of its desktop environment.
>
> As far as I can tell this is the only program running on my system that
> requires a very large desktop emulator, and of a specific release build,
> to operate correctly. To me, this is more than highly reminiscent of the
> Microsoft bloatware from which I fled some years ago.
>
> Are there graphic, or other, functions that can only be done under this
> environment? I hardly think so. Is my desktop improved by the use of
> this emulator? If so I do not see it.    ....... Are there any thoughts,
> or moves towards, extracting Digikam into a more neutral environment?
>
> David
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[todd rme]

On Sun, Oct 9, 2011 at 12:45 PM, sleepless <[hidden email]> wrote:

> Op 07-10-11 19:32, David Vincent-Jones schreef:
>> Of course this is plain heresy but .... looking at digikam installation
>> problems I have had and that others share on the forum, many of the
>> difficulties appear to be rooted in the tight integration of the program
>> along with the requirements of its desktop environment.
>>
>> As far as I can tell this is the only program running on my system that
>> requires a very large desktop emulator, and of a specific release build,
>> to operate correctly. To me, this is more than highly reminiscent of the
>> Microsoft bloatware from which I fled some years ago.
>>
>> Are there graphic, or other, functions that can only be done under this
>> environment? I hardly think so. Is my desktop improved by the use of
>> this emulator? If so I do not see it.    ....... Are there any thoughts,
>> or moves towards, extracting Digikam into a more neutral environment?
>>
>> David
>
> The main point of my thoughts is the gut feeling that we are going down,
> because of the greatness and complexity of kde and digikam.
> Bugfixing and fixing the bugs in the fixes is a downward spiral, at some
> point you need to rethink, redraw and rebuild.
> Rinus

What makes you think the rebuilt version would be any better?  Unless
you have some specific, practical suggestions for how the underlying
systems could be improved upon, it is just wishful thinking.

Actually, that was exactly what happened for the KDE 3 -> KDE 4
transition (at least partially, a lot of stuff was kept).  Do you
remember how much fun that was?  It took over 3 years from the release
of KDE 4 to the time digikam was fully ported to it (with digikam
2.0).  That is just making digikam work with the new system, it does
not include all the work done by other developers to make the
underlying system work, which was going on for several years at least
before the release of KDE 4.  You are saying Digikam developers should
have to do that all over again, AND re-implement all the stuff that
the KDE developers had already done, which means it would take even
longer.

-Todd
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Karl Günter Wünsch]

On Sunday 09 October 2011, todd rme wrote:
> You are saying Digikam developers should
> have to do that all over again, AND re-implement all the stuff that
> the KDE developers had already done, which means it would take even
> longer.
In some areas this indeed would have been preferrable. I am migrating away
from using KDE as my main desktop because of the errant ways it took - the
whole Nepomuk and Akonadi mess is - well a mess. There is little redeeming
features that they bring for all the bloat and the requirements to become a
database specialist (of differing databases as they are switched too often).
KMail 2 is still unusable for daily use - so I am migrating from KMail to
Thunderbird. Digikam will be another casualty of the switch as Akonadi and
Nepomuk integration scatters information all over the place (or is lost on a
regular basis when one of their databases acts up which they often do) - so
having a more stable, dedicated basis for storage (which isn't messed up by
the rest of the desktop environment on a regular basis) would be highly
desireable, as it currently stands I'll just switch for my organizing needs to
another program...
regards
Karl Günter
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Anders Lund]

On Søndag den 9. oktober 2011, Karl Günter Wünsch wrote:
> I am migrating away
> from using KDE as my main desktop because of the errant ways it took - the
> whole Nepomuk and Akonadi mess is - well a mess.

Difficult/new things are hard to achieve. Not being able to use that lattest
kdepim myself, I look forward to doing that, as much as I enjoy the evolving
benefits of nepomuk. I agree that there is still work to be done before it
works, but the promises makes it worth while :)

That said, KDE is in a process of modularizing itself, making the porential
dependencies lighter and easier to maintain. Already you do not need very much
in order to build kde applications, and digikam does not require anything but
what it uses.

If you do not want to go through the trouble of building the software on your
own but still want to stay up to date, use a system/distro that does ;)
--
Anders
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users