digiKam inclusion on KDE 4.1 ?

[Gilles Caulier-4]

Hi all,

Today, I have discuted with Stephan Kulow by mail about a possible digiKam inclusion in KDE 4.1, especially in kdegraphics component...

What do you think about ?

Gilles

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

Be part of the kdegraphics is great, but I would prefer to have digikam out of the KDE release cycle; to just stay for in the line that it is, like amarok. The KDE release cycle is perhaps so strict for an application like digikam, where new features are being added in each new release instead of only bug fixes. The digikam development I think is being managed a very good way, making its progress very dynamically. I think that being in the kdegraphics will stop that somehow.  It's just my opinion.

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

On Wednesday, 13. June 2007, Antonio E. wrote:
> Be part of the kdegraphics is great, but I would prefer to have digikam out
> of the KDE release cycle; to just stay for in the line that it is, like
> amarok. The KDE release cycle is perhaps so strict for an application like
> digikam, where new features are being added in each new release instead of
> only bug fixes. The digikam development I think is being managed a very good
> way, making its progress very dynamically. I think that being in the
> kdegraphics will stop that somehow.  It's just my opinion.
>

I agree with Antonio.  I prefer digikam having it's own release cycle.

AFAUI kdelibs kdebase and koffice as well as kdepim,
kdedu and kdegames have teams that work on common frameworks
and work on all apps to use the framework.  So in this case it
makes sense to bundle and release together.

If digikam would strongly depend and share libraries from kdepim
and vice versa (e.g. as kontact plugin. Eh, strange thought)
I would vote for inclusion.  But this is not the case.

What I would really like to see to happen: some developers that like to work gfx
frameworks. Then one could think about bundling some favorite gfx apps
digikam, gwenview, krita, kipi-plugins... extracting the best of them into a
libraries (e.g. raw file handling, meta data, slideshows ...) and making it
available everywhere for KDE apps (like via kparts kfile_plugins qimage kipi-NG ;)
etc etc)...

Just my 2 euro cent
Achim



Achim
--
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- [hidden email]
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Dnia środa 13 czerwiec 2007, Gilles Caulier napisał:
> Hi all,
>
> Today, I have discuted with Stephan Kulow by mail about a possible
> digiKam inclusion in KDE 4.1, especially in kdegraphics component...
>
> What do you think about ?

-1 (and I think this would be bad for both parts)

What are benefits of being part of core KDE?

- better recognition
- better attention from translators
- auto-inclusion in base packages of all distributions

I think in first two points Digikam is doing fairly well (YMMV as main
developer). Third point is worth of investigation.

Fast check:

Mandriva - OK

SUSE - OK but: AFAIR F-Spot is default app for digital photography in
*SUSE, unfortunately it is decision bordering on political grounds, not
merits. Moving to core KDE will change nothing. More helpful here (and
not only here) would be bumping number to 1.0 .

OpenSUSE - OK (see above)

RH - N/A (as primarily server/office distro there is no place for D?)
Fedora - BAD (extras packages but Fedora was always playing ugly with
KDE)

Ubuntu - obvious

Kubuntu - obvious :)

Debian - probably OK but there is no split in main/extras

Being part of KDE brings one big obligation: playing nicely with KDE
deadlines.

Digikam depends on some external projects, sqlite, dcraw, exiv2,
kipi-plugins.

When there is major breakthrough in one of them Digikam can quickly
include changes and has all benefits. When being part of KDE Digikam has
to wait, sometimes for long time, to include major changes, and even
smaller when they bring string modifications/additions.

As KDE user I think also that KDE should get rid of major applications
in main bandwagon. kdebase/kdepim is different story (kdebase is, well
base and kdepim practically is one big program) but general packages
should be rather place for small, entry-level applications[1], not
prosumer beasts. IMO Digikam is on prosumer level as far as digital
photography applications are going.

[1] And keep them on that level. What destroyed JuK in my eyes was
adding features completely unnecessary for simple music player - those
features broke stability and increased complexity of interface.

m.

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