[Digikam-devel] Talking about the future task (later 0.9.0-final)

[Gilles Caulier-2]

Hi all,

i have started my first investiguations about the 2 next major jobs to do
later 0.9.0 final release :

- Qt4.0/KDE 4.0 port
- CMake port.

The first one is not very complicated. We just need to use the new API. To
have a look into Qt 4.0 and digikam source code, i think it's a long but
trivial task.

The question in suspend is : when we will port digikam to Qt 4.0,
DigikamImagePlugins, kipi-plugins, and libkipi need to be port at the same
time ?

The second task is more complicated, because this require than all extragear
applications migrate at the same time. Right? If yes, a solution is to use a
branch instead trunk. What do you think about ?

Others question is : both jobs must be done at the same time or can be
separate ?

Note : I think that Qt 4.0 port must be done before to add new features in
digiKam (new DB interface for example).

Comments are welcome.

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

[Colin Guthrie-6]

Gilles Caulier wrote:

> Hi all,
>
> i have started my first investiguations about the 2 next major jobs
> to do later 0.9.0 final release :
>
> - Qt4.0/KDE 4.0 port - CMake port.
>
> The first one is not very complicated. We just need to use the new
> API. To have a look into Qt 4.0 and digikam source code, i think it's
> a long but trivial task.
>
> The question in suspend is : when we will port digikam to Qt 4.0,
> DigikamImagePlugins, kipi-plugins, and libkipi need to be port at the
> same time ?

Something which I read on the Amarok Dev list appears relevent here:
http://mail.kde.org/pipermail/amarok/2006-September/001484.html

<quote>
KDE 4

The optimistic estimates seem to agree that KDE 4 will be released in
about 1
year. Even more time will pass until it hits most people's desktops. What
does this mean for us? If we start our KDE 4 port now, then we won't be
able
to release a new version for one year. A long time in Amarok's terms.
Instead
of going KDE 4 right now, we could do a lot of refactoring (port to another
database backend, database scheme reorganization, separating internal data
represenatation from display in order to prepare for MVC, making subsystems
more independent, providing for better scriptability and more powerful
plug-ins...) already in a KDE 3-based version and starting to port when a
better timeline for a KDE 4 release is available.
</quote>


Hope that is some food for thought.

Col.

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

[Gilles Caulier-2]

On Tuesday 03 October 2006 13:50, Colin Guthrie wrote:

> Gilles Caulier wrote:
> > Hi all,
> >
> > i have started my first investiguations about the 2 next major jobs
> > to do later 0.9.0 final release :
> >
> > - Qt4.0/KDE 4.0 port - CMake port.
> >
> > The first one is not very complicated. We just need to use the new
> > API. To have a look into Qt 4.0 and digikam source code, i think it's
> > a long but trivial task.
> >
> > The question in suspend is : when we will port digikam to Qt 4.0,
> > DigikamImagePlugins, kipi-plugins, and libkipi need to be port at the
> > same time ?
>
> Something which I read on the Amarok Dev list appears relevent here:
> http://mail.kde.org/pipermail/amarok/2006-September/001484.html
>
> <quote>
> KDE 4
>
> The optimistic estimates seem to agree that KDE 4 will be released in
> about 1
> year. Even more time will pass until it hits most people's desktops. What
> does this mean for us? If we start our KDE 4 port now, then we won't be
> able
> to release a new version for one year.

No. I won't to start anything now. it just a discution about. in all case, i
will starting this port later than 0.9.0 final release planed to december.


> A long time in Amarok's terms.
> Instead
> of going KDE 4 right now, we could do a lot of refactoring (port to another
> database backend, database scheme reorganization, separating internal data
> represenatation from display in order to prepare for MVC, making subsystems
> more independent, providing for better scriptability and more powerful
> plug-ins...) already in a KDE 3-based version and starting to port when a
> better timeline for a KDE 4 release is available.
> </quote>

digiKam and DigikamImagePlugins use standard Qt class. All are always
available in QT4.0. i think a simple port can be done easily. My vision is to
do a Qt 4.0 port during some weeks, not 1 year (:=)))...

I think that nothing must be done about to improve digiKam/DigikamImagePlugins
for this port. The digiKam Qt4.x must running like digiKam Qt 3.x.

But is libkipi/kipi-plugins must be ported to Qt 4.0 before digiKam ?

Normally yes. and a libkipi Qt 4.0 port can take a while because what about
others kipi-host Qt  4.0 port ?

In all cases the first task to do with digiKam/DigikamImagePlugins is a CMake
port. Right ?

Gilles

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

[Marcel Wiesweg]

> Hi all,
>
> i have started my first investiguations about the 2 next major jobs to do
> later 0.9.0 final release :
>
> - Qt4.0/KDE 4.0 port
> - CMake port.

I think the CMake port will be done at the same time as the KDE4 port, because
KDE4 uses CMake and for KDE3 CMake is not well supported.
I would see the three, Qt4, KDE4, CMake, as parts of one task.

>
> The first one is not very complicated. We just need to use the new API. To
> have a look into Qt 4.0 and digikam source code, i think it's a long but
> trivial task.

I have been playing with Qt4 a bit and I like the new API and I am happily
looking forward to throw away some code in digikam ;-) (flicker
optimizations, inter-thread communication with custom events, QDeepCopies of
QStrings)

Of course I have no experience how much the automated tools will help.

>
> The question in suspend is : when we will port digikam to Qt 4.0,
> DigikamImagePlugins, kipi-plugins, and libkipi need to be port at the same
> time ?
>
> The second task is more complicated, because this require than all
> extragear applications migrate at the same time. Right? If yes, a solution
> is to use a branch instead trunk. What do you think about ?

Main KDE uses a branch for KDE3 and trunk for KDE4.
What needs to be changed is the "How to compile from svn" for all kipi-based
apps, and packagers need to pack from the right place, and developers need to
switch their svn copy if they continue to use KDE3.


>
> Others question is : both jobs must be done at the same time or can be
> separate ?
>
> Note : I think that Qt 4.0 port must be done before to add new features in
> digiKam (new DB interface for example).

Agreed.
Though I am already imagining how to make use of new Qt features ;-)

>
> Comments are welcome.

Time frame needs to be considered.
We plan 0.9 as "Edition Noel" on December 24 ;-)

Colin quoted Martin Aumueller. According to Linux.com, Aaron Seigo:
"The goal right now, says Seigo, is to have KDE 4 done "in the first half
of '07." Some distributions, like Kubuntu and openSUSE, will put out KDE 4
packages right away when KDE 4 is released. ... However, Seigo says
that "mainline" distros will probably be slower to incorporate the new
release and their users won't start seeing KDE 4 until the second half of
2007."

I would assume we need a KDE4 digikam in a year, a beta in 10 months.

We can start thinking now, and coding after 0.9 release.

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

[Gilles Caulier-2]

On Tuesday 03 October 2006 15:18, Marcel Wiesweg wrote:
> Main KDE uses a branch for KDE3 and trunk for KDE4.
> What needs to be changed is the "How to compile from svn" for all
> kipi-based apps, and packagers need to pack from the right place, and
> developers need to switch their svn copy if they continue to use KDE3.

Yes Marcel, but my question is different :

If libkipi and kipi-plugins aren't yet ported to Qt/KDE 4, and if digikam is
ported to Qt/KDE 4, it will work ? (:=)))

Gilles

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

[Marcel Wiesweg]

Am Dienstag 03 Oktober 2006 15:24 schrieb Gilles Caulier:

> On Tuesday 03 October 2006 15:18, Marcel Wiesweg wrote:
> > Main KDE uses a branch for KDE3 and trunk for KDE4.
> > What needs to be changed is the "How to compile from svn" for all
> > kipi-based apps, and packagers need to pack from the right place, and
> > developers need to switch their svn copy if they continue to use KDE3.
>
> Yes Marcel, but my question is different :
>
> If libkipi and kipi-plugins aren't yet ported to Qt/KDE 4, and if digikam
> is ported to Qt/KDE 4, it will work ? (:=)))

No, I don't think so.
libkipi needs to be ported for digikam to compile.
Not ported Kipi-plugins will simply not be available.

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