Prepare the future : merging digiKam and DigikamImagePlugins

[Gilles Caulier-4]

Hi all,

 

I propose a new reflection subject for the future : merging digiKam and DigikamImagePlugins project

 

This idea have been proprosed by Fabien after 0.9.0 release in a private mail. The reason to have 2 packages is old. In fact, Renchi in the past would to separate the advanced tools of the basic tools for editor. Typicaly, he don't see the reason to include this plugins in digiKam core (the term used is "bloated" if i remember... i hate this term)

 

Personnaly, i'm favorable to move the plugins source code in digiKam without include it to plugin core (remeber than plugin core include basic tool like Red Eyes, BCG, HSL, RGB, etc.). With this solution, users can always disable these advanced plugins in interface, but they will always available without installing a separate package.

 

The advantage of this solution is to have only one pachage to release. less time to do it, more simple, etc.

 

My proposal is to do it when we port the code to QT4.

 

What do you think about ? 

 

Gilles

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

[Fabien-5]

Hi,

Gilles Caulier wrote:

> I propose a new reflection subject for the future : merging digiKam and
> DigikamImagePlugins project
>  
> This idea have been proprosed by Fabien after 0.9.0 release in a private
> mail. The reason to have 2 packages is old. In fact, Renchi in the past
> would to separate the advanced tools of the basic tools for editor.
> Typicaly, he don't see the reason to include this plugins in digiKam
> core (the term used is "bloated" if i remember... i hate this term)
>  
> Personnaly, i'm favorable to move the plugins source code in digiKam
> without include it to plugin core (remeber than plugin core include
> basic tool like Red Eyes, BCG, HSL, RGB, etc.). With this
> solution, users can always disable these advanced plugins in interface,
> but they will always available without installing a separate package.
>  
> The advantage of this solution is to have only one pachage to release.
> less time to do it, more simple, etc.
>  
> My proposal is to do it when we port the code to QT4.
>  
> What do you think about ?

Great, I agree :)

About future plans for digiKam :
How do you see the migration to QT4 ?

I guess that when you will start to port digiKam to QT4, there will be a
  feature freeze for around 1 year, the time to change the source code
and to stabilize the new version, isn't it ?

When do you plan to start the port ?

If I can make a suggestion, I would propose to make (at least :) ) one
more revision that would include this "small" feature :
< http://bugs.kde.org/show_bug.cgi?id=107871#c6>

And I also think the latest revision before the port could be numbered
1.0 because digiKam is mature enough for that...
It definitely deserves it ;-)

PS: sorry for being a bit off-topic.

--
Fabien

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

[Arnd Baecker]

On Thu, 1 Mar 2007, Fabien wrote:

[...]

> I guess that when you will start to port digiKam to QT4, there will be a
>   feature freeze for around 1 year, the time to change the source code
> and to stabilize the new version, isn't it ?

If this would really freeze feature additions for one year,
I would also like to add a few wishes before that ;-)
(OTOH, Gilles is so fast, so maybe the freeze would much shorter ;-0)

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

[Gilles Caulier-4]

About QT4 this is my plan :

 

- This port require also KDE 4 library port. I have seen in lots of developpers blogs than the API is not yet frozen and stabilized. 
- In my computer (Mandriva 2007), i have already QT4 API but not yet KDE4. This one will be certainly available in next Mandriva release planned in few month. I refuse to work on QT4 KDE4 port without a clean API available. The time is precious and i won't lost time to trying to install an unstable package with a risk to break my computer.

- To have take a look into QT4 port, well digiKam will be long (few month) but easy to do because we using standard API witch are always available in QT4. The main change are about multithreading witch is more easy to do with QT4, but i think we can just port the code as well without improve anything. Marcel, i need your viewpoint here...

- Another main problem is to have an area in svn to work on digiKam and others shared lib (libkipi, libexiv2, likdcraw), without to be in conflict with others application available in extragear (kphotoalbum, showimg, etc.) witch will not be ported at now and continue to require QT3/KDE3. I have follow a thread last year about this point in extragear mailing list without to have a clean response. Angelo, if you have some fresh informations about this point, let's me hear... 

- We cannot merge QT3 and QT4 code. This is want mean than all part need to be ported before. All shared lib need to ported in first : libkipi, libkexiv2, and libkdcraw. After the core of digiKAm can be ported to disable all external plugins (kipi-plugins and DigiKamImagePlugins). And t end the port of plugins can be done : DigikamImagePlugins in first (to merge the code in digiKam core), and kipi-plugins in second. This last one is the ost complicated to plan because it's shared with others hosts program and maintaned by a lot of contributors. I think than kipi-plugins will take a while to port.

 

I'm agree with Fabien. A new QT3 release must be done at least : 0.9.2. We will port the core to libkdcraw (a patch is ready on my computer) and we wil fix a lot of bugs from B.K.O. 

 

Gilles 

 

2007/3/1, Arnd Baecker <[hidden email]>:

On Thu, 1 Mar 2007, Fabien wrote:

[...]

> I guess that when you will start to port digiKam to QT4, there will be a
>   feature freeze for around 1 year, the time to change the source code
> and to stabilize the new version, isn't it ?

If this would really freeze feature additions for one year,
I would also like to add a few wishes before that ;-)
(OTOH, Gilles is so fast, so maybe the freeze would much shorter ;-0)

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

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

[Gerhard Kulzer]

Am Thursday 01 March 2007 schrieb Arnd Baecker:

> On Thu, 1 Mar 2007, Fabien wrote:
>
> [...]
>
> > I guess that when you will start to port digiKam to QT4, there will be a
> >   feature freeze for around 1 year, the time to change the source code
> > and to stabilize the new version, isn't it ?
>
> If this would really freeze feature additions for one year,
> I would also like to add a few wishes before that ;-)
> (OTOH, Gilles is so fast, so maybe the freeze would much shorter ;-0)
>

As someone who can (probably) not contribute to this migration I still would

like to inject my opinion. A 1 year feature freeze will put-off everyone,
first you, the developers, and than our users. It's too long a stretch of
time.

We should ask for help (even if we might not get any,
because everyone active is in the same busy boat), and cut it into pieces like
that:
- As Gilles proposed, convert the libraries first
- then the digikam core
- add features when deemed juicy to qt3 at any time, interrupting migration
- migrate the plugins one by one
- migrate kipis, and there export at first (here we have other developers)

I also think that experience and know-how with migration will grow rapidly
everywhere, in particular in amarok which has to deal with threading as much
as we have to. With the result that it will not take 1 year. I definitely
hope so.

Gerhard

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

[F.J.Cruz-2]

El Jueves, 1 de Marzo de 2007, Gerhard Kulzer escribió:

> Am Thursday 01 March 2007 schrieb Arnd Baecker:
> > On Thu, 1 Mar 2007, Fabien wrote:
> >
> > [...]
> >
> > > I guess that when you will start to port digiKam to QT4, there will be
> > > a feature freeze for around 1 year, the time to change the source code
> > > and to stabilize the new version, isn't it ?
> >
> > If this would really freeze feature additions for one year,
> > I would also like to add a few wishes before that ;-)
> > (OTOH, Gilles is so fast, so maybe the freeze would much shorter ;-0)
>
> As someone who can (probably) not contribute to this migration I still
> would like to inject my opinion. A 1 year feature freeze will put-off
> everyone, first you, the developers, and than our users. It's too long a
> stretch of time.
>
> We should ask for help (even if we might not get any,
> because everyone active is in the same busy boat), and cut it into pieces
> like that:
> - As Gilles proposed, convert the libraries first
> - then the digikam core
> - add features when deemed juicy to qt3 at any time, interrupting migration
> - migrate the plugins one by one
> - migrate kipis, and there export at first (here we have other developers)
>
> I also think that experience and know-how with migration will grow rapidly
> everywhere, in particular in amarok which has to deal with threading as
> much as we have to. With the result that it will not take 1 year. I
> definitely hope so.
>
> Gerhard

I agree with Gilles about to merge both digiKam and digikamImagePlugins in one
and only package, there is no reason to have two separate projects now.

About migration to QT4 I think Gerhard makes a good proposition, this could be
a good start point to work on a time line to get it.

What's about some features like non-destructive edition, light table, and
so...?

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

[Marcel Wiesweg]

> Hi all,
>
> I propose a new reflection subject for the future : merging digiKam and
> DigikamImagePlugins project
>
> This idea have been proprosed by Fabien after 0.9.0 release in a private
> mail. The reason to have 2 packages is old. In fact, Renchi in the past
> would to separate the advanced tools of the basic tools for editor.
> Typicaly, he don't see the reason to include this plugins in digiKam core
> (the term used is "bloated" if i remember... i hate this term)
>
> Personnaly, i'm favorable to move the plugins source code in digiKam
> without include it to plugin core (remeber than plugin core include basic
> tool like Red Eyes, BCG, HSL, RGB, etc.). With this solution, users can
> always disable these advanced plugins in interface, but they will always
> available without installing a separate package.
>
> The advantage of this solution is to have only one pachage to release. less
> time to do it, more simple, etc.
>
> My proposal is to do it when we port the code to QT4.
>
> What do you think about ?

I agree.
If distros want to provide single packages anyway, we could offer
configure-script options to disable some plugins. (I am not sure what the
right term for CMake is, but there will be no configure script as with
autoconf. CMake build options?)

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

[Gilles Caulier-4]

2007/3/1, F.J.Cruz <[hidden email]>:

El Jueves, 1 de Marzo de 2007, Gerhard Kulzer escribió:

> Am Thursday 01 March 2007 schrieb Arnd Baecker:
> > On Thu, 1 Mar 2007, Fabien wrote:
> >
> > [...]
> >
> > > I guess that when you will start to port digiKam to QT4, there will be
> > > a feature freeze for around 1 year, the time to change the source code
> > > and to stabilize the new version, isn't it ?
> >

 

From my developper viewpoint, this is my time plan to port on QT4 :

 

- shared libs libkexiv2 : 4 hours. very easy...

- shared libs libkdcraw : 1 day maximum, not more.

- shared libs libkipi : 3-4 days.

 

- digiKam core : 2-3 weeks (without testing indeep).

- DigikamImagePlugins : 1-2 weeks (without testing indeep).

 

- kipi-plugins : 4-5 weeks depending of contributors avaibility.

 

Nota : unforget than all Makefile.am/configure.in need to be converted to CMake. This is a tiedous job, especially to test all compilations conditions. The time given before do not includes CMake port

But, like you can see, all features will be frozen a few month, not one year (:=))))

Of course, like i said 'porting to QT4', i would mean porting as well without add new features or improve implementation indeep. I think this is mandatory to be able to compare QT3 and QT4 implementations

 

> > If this would really freeze feature additions for one year,
> > I would also like to add a few wishes before that ;-)
> > (OTOH, Gilles is so fast, so maybe the freeze would much shorter ;-0)
>
> As someone who can (probably) not contribute to this migration I still
> would like to inject my opinion. A 1 year feature freeze will put-off
> everyone, first you, the developers, and than our users. It's too long a
> stretch of time.
>
> We should ask for help (even if we might not get any,
> because everyone active is in the same busy boat), and cut it into pieces
> like that:
> - As Gilles proposed, convert the libraries first
> - then the digikam core
> - add features when deemed juicy to qt3 at any time, interrupting migration
> - migrate the plugins one by one
> - migrate kipis, and there export at first (here we have other developers)
>
> I also think that experience and know-how with migration will grow rapidly
> everywhere, in particular in amarok which has to deal with threading as
> much as we have to. With the result that it will not take 1 year. I
> definitely hope so.
>
> Gerhard

I agree with Gilles about to merge both digiKam and digikamImagePlugins in one
and only package, there is no reason to have two separate projects now.
 

> - Another main problem is to have an area in svn to work on digiKam and
> others shared lib (libkipi, libexiv2, likdcraw), without to be in conflict
> with others application available in extragear (kphotoalbum, showimg, etc.)
> witch will not be ported at now and continue to require QT3/KDE3. I have
> follow a thread last year about this point in extragear mailing list without
> to have a clean response. Angelo, if you have some fresh informations about
> this point, let's me hear...
No new info really, IMO we should start talking about that on kdeimaging
ml soon. As you know in the near future i won't be able to be very present,
so the sooner we talk about that and the sooner we start to migrate...

BTW, are you still on holidays?

Angelo

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

[Marcel Wiesweg]

> About QT4 this is my plan :
>
> - This port require also KDE 4 library port. I have seen in lots of
> developpers blogs than the API is not yet frozen and stabilized.

This is true, it is still changing, but it is much less changing than in
previous months. The core technologies are there. Amarok has started porting.
Most important, high-quality documentation is being written at
techbase.kde.org (subdomain subject to change: developernew.kde.org works as
well ;-) )

> - In my computer (Mandriva 2007), i have already QT4 API but not yet KDE4.
> This one will be certainly available in next Mandriva release planned in
> few month. I refuse to work on QT4 KDE4 port without a clean API available.
> The time is precious and i won't lost time to trying to install an unstable
> package with a risk to break my computer.

I understand your point...but as usual (me being a Gentoo user) I don't have
any objections to install KDE trunk svn parallely on my computer. There is
also documentation:
http://techbase.kde.org/Getting_Started/Build/Unstable_Version

> - To have take a look into QT4 port, well digiKam will be long (few
> month) but easy to do because we using standard API witch are always
> available in QT4. The main change are about multithreading witch is more
> easy to do with QT4, but i think we can just port the code as well without
> improve anything. Marcel, i need your viewpoint here...

Yes multithreading is easier with Qt4, but that's not a problem for porting,
the code still works, it means we can actually remove code (and I will very
happily volunteer to remove all the manual event sending code, QDeepCopies of
QStrings from our multithreaded parts).

Overview documentation
http://techbase.kde.org/Development/Tutorials/KDE4_Porting_Guide

There are scripts to relieve us of the tedious work:
http://doc.trolltech.com/4.2/qt3to4.html
http://websvn.kde.org/trunk/KDE/kdesdk/scripts/qt4/

There are two pages with detailed information about the API changes. These
need to be consulted while porting:
http://doc.trolltech.com/4.0/porting4.html
http://websvn.kde.org/*checkout*/trunk/KDE/kdelibs/KDE4PORTING.html

> - Another main problem is to have an area in svn to work on digiKam and
> others shared lib (libkipi, libexiv2, likdcraw), without to be in conflict
> with others application available in extragear (kphotoalbum, showimg, etc.)
> witch will not be ported at now and continue to require QT3/KDE3. I have
> follow a thread last year about this point in extragear mailing list
> without to have a clean response. Angelo, if you have some fresh
> informations about this point, let's me hear...

Overall KDE policy is clear: trunk is KDE4 because it's the future. Branches
are KDE3. Amarok also has its KDE4 = main development branch as trunk.

> - We cannot merge QT3 and QT4 code. This is want mean than all part need to
> be ported before. All shared lib need to ported in first : libkipi,
> libkexiv2, and libkdcraw. After the core of digiKAm can be ported to
> disable all external plugins (kipi-plugins and DigiKamImagePlugins). And t
> end the port of plugins can be done : DigikamImagePlugins in first (to
> merge the code in digiKam core), and kipi-plugins in second. This last one
> is the ost complicated to plan because it's shared with others hosts
> program and maintaned by a lot of contributors. I think than kipi-plugins
> will take a while to port.
>
> I'm agree with Fabien. A new QT3 release must be done at least : 0.9.2. We
> will port the core to libkdcraw (a patch is ready on my computer) and we
> wil fix a lot of bugs from B.K.O.

This should of course be done before branching to a KDE3-stable and a KDE4
branch. Once the branch is done, we can still do bug fixes but not much more.


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

On Thursday, 1. March 2007, Gilles Caulier wrote:

> About QT4 this is my plan :
>
> - This port require also KDE 4 library port. I have seen in lots of
> developpers blogs than the API is not yet frozen and stabilized.
> - In my computer (Mandriva 2007), i have already QT4 API but not yet KDE4.
> This one will be certainly available in next Mandriva release planned in few
> month. I refuse to work on QT4 KDE4 port without a clean API available. The
> time is precious and i won't lost time to trying to install an unstable
> package with a risk to break my computer.
> - To have take a look into QT4 port, well digiKam will be long (few
> month) but easy to do because we using standard API witch are always
> available in QT4. The main change are about multithreading witch is more
> easy to do with QT4, but i think we can just port the code as well without
> improve anything. Marcel, i need your viewpoint here...
> - Another main problem is to have an area in svn to work on digiKam and
> others shared lib (libkipi, libexiv2, likdcraw), without to be in conflict
> with others application available in extragear (kphotoalbum, showimg, etc.)
> witch will not be ported at now and continue to require QT3/KDE3. I have
> follow a thread last year about this point in extragear mailing list without
> to have a clean response. Angelo, if you have some fresh informations about
> this point, let's me hear...

IMHO, we can use branches/work/<whatever> and to lib*, digikam etc in their.
Maybe call it kipi4.  So everything required/related fits nicely ;)
CMake stuff can always later adapted to whatever schema extragear will chose.

FWIW: I will try to contribute to auto* -> cmake switch.

Achim

> - We cannot merge QT3 and QT4 code. This is want mean than all part need to
> be ported before. All shared lib need to ported in first : libkipi,
> libkexiv2, and libkdcraw. After the core of digiKAm can be ported to disable
> all external plugins (kipi-plugins and DigiKamImagePlugins). And t end the
> port of plugins can be done : DigikamImagePlugins in first (to merge the
> code in digiKam core), and kipi-plugins in second. This last one is the ost
> complicated to plan because it's shared with others hosts program and
> maintaned by a lot of contributors. I think than kipi-plugins will take a
> while to port.
>
> I'm agree with Fabien. A new QT3 release must be done at least : 0.9.2. We
> will port the core to libkdcraw (a patch is ready on my computer) and we wil
> fix a lot of bugs from B.K.O.
>
> Gilles
>
>
> 2007/3/1, Arnd Baecker <[hidden email]>:
> >
> > On Thu, 1 Mar 2007, Fabien wrote:
> >
> > [...]
> >
> > > I guess that when you will start to port digiKam to QT4, there will be a
> > >   feature freeze for around 1 year, the time to change the source code
> > > and to stabilize the new version, isn't it ?
> >
> > If this would really freeze feature additions for one year,
> > I would also like to add a few wishes before that ;-)
> > (OTOH, Gilles is so fast, so maybe the freeze would much shorter ;-0)
> >
> > Arnd
> > _______________________________________________
> > Digikam-devel mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-devel
> >
>

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

[Gilles Caulier-4]

2007/3/1, Angelo Naselli <[hidden email]>:

> - Another main problem is to have an area in svn to work on digiKam and
> others shared lib (libkipi, libexiv2, likdcraw), without to be in conflict
> with others application available in extragear (kphotoalbum, showimg, etc.)
> witch will not be ported at now and continue to require QT3/KDE3. I have
> follow a thread last year about this point in extragear mailing list without
> to have a clean response. Angelo, if you have some fresh informations about
> this point, let's me hear...
No new info really, IMO we should start talking about that on kdeimaging
ml soon. As you know in the near future i won't be able to be very present,
so the sooner we talk about that and the sooner we start to migrate...

 

Angelo, no need to post a message in kde-imaging. The extragears repositories coordinator is in extragear ML. We must contact him to be sure how and where we will work on svn to port source code to QT4.

 

Also, look into the message from Marcel... 

 

BTW, are you still on holidays?

 

yes. I'm back at home next monday. I will have acess to my DSL line at home. I will be better to work under linux (actually i'm using Vista and ie to read my mail via gmail web interface...

 

Nota : i have performed some investiguation under Vista about the new small tool "Windows Image Gallery" program from M$. A very simple photo management program (it handle only JPEG files) where i have found some good ideas. I will post a new message in this room later about it (especially how M$ handle JPEG metadata) 

 

Gilles

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

[Gilles Caulier-4]

2007/3/1, Marcel Wiesweg <[hidden email]>:

> About QT4 this is my plan :
>
> - This port require also KDE 4 library port. I have seen in lots of
> developpers blogs than the API is not yet frozen and stabilized.

This is true, it is still changing, but it is much less changing than in
previous months. The core technologies are there. Amarok has started porting.
Most important, high-quality documentation is being written at
techbase.kde.org (subdomain subject to change: developernew.kde.org works as
well ;-) )

> - In my computer (Mandriva 2007), i have already QT4 API but not yet KDE4.
> This one will be certainly available in next Mandriva release planned in
> few month. I refuse to work on QT4 KDE4 port without a clean API available.
> The time is precious and i won't lost time to trying to install an unstable
> package with a risk to break my computer.

I understand your point...but as usual (me being a Gentoo user) I don't have
any objections to install KDE trunk svn parallely on my computer. There is
also documentation:
http://techbase.kde.org/Getting_Started/Build/Unstable_Version

 

yes, but i won't to fight with an hard installation of KDE 4 on my computer. If Mandriva provide standard packages, it will be more easy to do... 

 

> - To have take a look into QT4 port, well digiKam will be long (few
> month) but easy to do because we using standard API witch are always
> available in QT4. The main change are about multithreading witch is more
> easy to do with QT4, but i think we can just port the code as well without
> improve anything. Marcel, i need your viewpoint here...

Yes multithreading is easier with Qt4, but that's not a problem for porting,
the code still works, it means we can actually remove code (and I will very
happily volunteer to remove all the manual event sending code, QDeepCopies of
QStrings from our multithreaded parts).

 

 

Fine for me if you can do it (:=)))

 

Overview documentation
http://techbase.kde.org/Development/Tutorials/KDE4_Porting_Guide

There are scripts to relieve us of the tedious work:
http://doc.trolltech.com/4.2/qt3to4.html
http://websvn.kde.org/trunk/KDE/kdesdk/scripts/qt4/

There are two pages with detailed information about the API changes. These
need to be consulted while porting:
http://doc.trolltech.com/4.0/porting4.html
http://websvn.kde.org/*checkout*/trunk/KDE/kdelibs/KDE4PORTING.html

 

These links are very important. Please put these urls in TODO file to remember... 

 

> - Another main problem is to have an area in svn to work on digiKam and
> others shared lib (libkipi, libexiv2, likdcraw), without to be in conflict
> with others application available in extragear (kphotoalbum, showimg, etc.)
> witch will not be ported at now and continue to require QT3/KDE3. I have
> follow a thread last year about this point in extragear mailing list
> without to have a clean response. Angelo, if you have some fresh
> informations about this point, let's me hear...

Overall KDE policy is clear: trunk is KDE4 because it's the future. Branches
are KDE3. Amarok also has its KDE4 = main development branch as trunk.

 

This is true about KDE core, but extragear is different and do not follow KDE release plan...

 

The problem is than extragear host multiple project witch will use QT3 for a long time.

 

Question : where Amarok team have placed the QT4 port source code ? It's Amarok is moved to KDE core (like Gwenview) ?

 

> - We cannot merge QT3 and QT4 code. This is want mean than all part need to

> be ported before. All shared lib need to ported in first : libkipi,
> libkexiv2, and libkdcraw. After the core of digiKAm can be ported to
> disable all external plugins (kipi-plugins and DigiKamImagePlugins). And t
> end the port of plugins can be done : DigikamImagePlugins in first (to
> merge the code in digiKam core), and kipi-plugins in second. This last one
> is the ost complicated to plan because it's shared with others hosts
> program and maintaned by a lot of contributors. I think than kipi-plugins
> will take a while to port.
>
> I'm agree with Fabien. A new QT3 release must be done at least : 0.9.2. We
> will port the core to libkdcraw (a patch is ready on my computer) and we
> wil fix a lot of bugs from B.K.O.

This should of course be done before branching to a KDE3-stable and a KDE4
branch. Once the branch is done, we can still do bug fixes but not much more.

 

If i'm following you, after to release digiKam 0.9.1-final, we copy the code from trunk to stable, and we continue the QT3 digiKam serie in stable, and in trunk, we start the QT4 port. In this case, we will have a conflict with others extragear applications witch continue to use QT3. In fact, the problem is about the common autotools rules (.configure and makefile.am) witch are obsolete with CMake. Can we have both at the same time and at the same place ? 

 

Gilles

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

[Gilles Caulier-4]

2007/3/1, Achim Bohnet <[hidden email]>:

On Thursday, 1. March 2007, Gilles Caulier wrote:
> About QT4 this is my plan :
>
> - This port require also KDE 4 library port. I have seen in lots of
> developpers blogs than the API is not yet frozen and stabilized.
> - In my computer (Mandriva 2007), i have already QT4 API but not yet KDE4.
> This one will be certainly available in next Mandriva release planned in few
> month. I refuse to work on QT4 KDE4 port without a clean API available. The
> time is precious and i won't lost time to trying to install an unstable
> package with a risk to break my computer.
> - To have take a look into QT4 port, well digiKam will be long (few

> month) but easy to do because we using standard API witch are always
> available in QT4. The main change are about multithreading witch is more
> easy to do with QT4, but i think we can just port the code as well without
> improve anything. Marcel, i need your viewpoint here...
> - Another main problem is to have an area in svn to work on digiKam and
> others shared lib (libkipi, libexiv2, likdcraw), without to be in conflict
> with others application available in extragear (kphotoalbum, showimg, etc.)
> witch will not be ported at now and continue to require QT3/KDE3. I have
> follow a thread last year about this point in extragear mailing list without
> to have a clean response. Angelo, if you have some fresh informations about
> this point, let's me hear...

IMHO, we can use branches/work/<whatever> and to lib*, digikam etc in their.
Maybe call it kipi4.  So everything required/related fits nicely ;)
CMake stuff can always later adapted to whatever schema extragear will chose.

FWIW: I will try to contribute to auto* -> cmake switch.

 

Fine for me about CMake port. But look my response about Marcel thread, especially to use autottools and CMake at the same time in trunk/extragear...

 

In all case, to start porting, we will do libexiv2 (for ex.). It's smal and easy to do. We will learn the port job without risk (:=))) 

 

Gilles

 

Achim

> - We cannot merge QT3 and QT4 code. This is want mean than all part need to
> be ported before. All shared lib need to ported in first : libkipi,
> libkexiv2, and libkdcraw. After the core of digiKAm can be ported to disable
> all external plugins (kipi-plugins and DigiKamImagePlugins). And t end the
> port of plugins can be done : DigikamImagePlugins in first (to merge the
> code in digiKam core), and kipi-plugins in second. This last one is the ost
> complicated to plan because it's shared with others hosts program and
> maintaned by a lot of contributors. I think than kipi-plugins will take a
> while to port.
>
> I'm agree with Fabien. A new QT3 release must be done at least : 0.9.2. We
> will port the core to libkdcraw (a patch is ready on my computer) and we wil
> fix a lot of bugs from B.K.O.
>
> Gilles
>
>
> 2007/3/1, Arnd Baecker <[hidden email]>:
> >
> > On Thu, 1 Mar 2007, Fabien wrote:
> >

> > [...]

> >
> > > I guess that when you will start to port digiKam to QT4, there will be a
> > >   feature freeze for around 1 year, the time to change the source code
> > > and to stabilize the new version, isn't it ?
> >
> > If this would really freeze feature additions for one year,
> > I would also like to add a few wishes before that ;-)
> > (OTOH, Gilles is so fast, so maybe the freeze would much shorter ;-0)
> >
> > Arnd
> > _______________________________________________
> > Digikam-devel mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-devel
> >
>

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

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

[F.J.Cruz-2]

El Jueves, 1 de Marzo de 2007, Gilles Caulier escribió:
> see my response before. This can be implemented just later QT4 port.
>
> Gilles

Right for me.

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

[Marcel Wiesweg]

> yes, but i won't to fight with an hard installation of KDE 4 on my
> computer. If Mandriva provide standard packages, it will be more easy to
> do...

Yes if Mandriva provides developer packages in time? There is no official
release of KDE4 yet, only snapshots. And you need Qt4.3 - not yet released,
so you need qt-copy.
There is also mentioned the possibility to do a non-root installation of KDE4.
Perhaps in the next or the following week I will try to install a fresh KDE4
and then I will tell you about my experience ;-)

> > > improve anything. Marcel, i need your viewpoint here...
> >
> > Yes multithreading is easier with Qt4, but that's not a problem for
> > porting,
> > the code still works, it means we can actually remove code (and I will
> > very
> > happily volunteer to remove all the manual event sending code,
> > QDeepCopies of
> > QStrings from our multithreaded parts).
>
> Fine for me if you can do it (:=)))

Oh yes. I am really looking forward to delete some parts of the code and
replace it with queued signals ;-) That's fun ;-))

> > Overall KDE policy is clear: trunk is KDE4 because it's the future.
> > Branches
> > are KDE3. Amarok also has its KDE4 = main development branch as trunk.
>
> This is true about KDE core, but extragear is different and do not follow
> KDE release plan...
>
> The problem is than extragear host multiple project witch will use QT3 for
> a long time.
>
> Question : where Amarok team have placed the QT4 port source code ? It's
> Amarok is moved to KDE core (like Gwenview) ?

http://websvn.kde.org/trunk/extragear/multimedia/amarok/ :
There is a CMakeLists.txt, and the code is Qt4. All Makefile.* are removed.
In the parent directory http://websvn.kde.org/trunk/extragear/multimedia/ 
there is also a CMakeLists.txt, and still a Makefile.cvs.

> If i'm following you, after to release digiKam 0.9.1-final, we copy the
> code
>
> >from trunk to stable, and we continue the QT3 digiKam serie in stable, and
>
> in trunk, we start the QT4 port. In this case, we will have a conflict with
> others extragear applications witch continue to use QT3. In fact, the
> problem is about the common autotools rules (.configure and makefile.am)
> witch are obsolete with CMake. Can we have both at the same time and at the
> same place ?

We have to talk to the other extragear applications about the location of the
libraries that we share.
Again taking extragear/multimedia as an example, amarok/ is Qt4, while
kmplayer/ is apparently not yet ported. So it seems to work. (I still have to
read the documentation on CMake)

Marcel

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

Dnia czwartek 01 marzec 2007, Gilles Caulier napisał:
> About QT4 this is my plan :

About Qt4: what about MS-Windows port?

m.

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

[Gerhard Kulzer]

> > http://techbase.kde.org/Development/Tutorials/KDE4_Porting_Guide
> >
> > There are scripts to relieve us of the tedious work:
> > http://doc.trolltech.com/4.2/qt3to4.html
> > http://websvn.kde.org/trunk/KDE/kdesdk/scripts/qt4/
> >
> > There are two pages with detailed information about the API changes.
> > These need to be consulted while porting:
> > http://doc.trolltech.com/4.0/porting4.html
> > http://websvn.kde.org/*checkout*/trunk/KDE/kdelibs/KDE4PORTING.html
>
> These links are very important. Please put these urls in TODO file to
> remember...
>

Done (rev 638468) in svn



--
Hakuna matata
http://www.gerhard.fr

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

[Gilles Caulier-4]

Well, look in multimedia, both autotools and cmake config files are present. It work.

 

Gilles

 

2007/3/1, Marcel Wiesweg <[hidden email]>:

> yes, but i won't to fight with an hard installation of KDE 4 on my
> computer. If Mandriva provide standard packages, it will be more easy to
> do...

Yes if Mandriva provides developer packages in time? There is no official
release of KDE4 yet, only snapshots. And you need Qt4.3 - not yet released,
so you need qt-copy.
There is also mentioned the possibility to do a non-root installation of KDE4.
Perhaps in the next or the following week I will try to install a fresh KDE4
and then I will tell you about my experience ;-)

> > > improve anything. Marcel, i need your viewpoint here...
> >
> > Yes multithreading is easier with Qt4, but that's not a problem for
> > porting,
> > the code still works, it means we can actually remove code (and I will
> > very
> > happily volunteer to remove all the manual event sending code,
> > QDeepCopies of
> > QStrings from our multithreaded parts).
>
> Fine for me if you can do it (:=)))

Oh yes. I am really looking forward to delete some parts of the code and
replace it with queued signals ;-) That's fun ;-))

> > Overall KDE policy is clear: trunk is KDE4 because it's the future.
> > Branches
> > are KDE3. Amarok also has its KDE4 = main development branch as trunk.
>
> This is true about KDE core, but extragear is different and do not follow
> KDE release plan...
>
> The problem is than extragear host multiple project witch will use QT3 for
> a long time.
>
> Question : where Amarok team have placed the QT4 port source code ? It's
> Amarok is moved to KDE core (like Gwenview) ?

http://websvn.kde.org/trunk/extragear/multimedia/amarok/ :
There is a CMakeLists.txt, and the code is Qt4. All Makefile.* are removed.
In the parent directory http://websvn.kde.org/trunk/extragear/multimedia/
there is also a CMakeLists.txt, and still a Makefile.cvs.

> If i'm following you, after to release digiKam 0.9.1-final, we copy the
> code
>
> >from trunk to stable, and we continue the QT3 digiKam serie in stable, and
>
> in trunk, we start the QT4 port. In this case, we will have a conflict with
> others extragear applications witch continue to use QT3. In fact, the
> problem is about the common autotools rules (.configure and makefile.am)
> witch are obsolete with CMake. Can we have both at the same time and at the
> same place ?

We have to talk to the other extragear applications about the location of the
libraries that we share.
Again taking extragear/multimedia as an example, amarok/ is Qt4, while
kmplayer/ is apparently not yet ported. So it seems to work. (I still have to
read the documentation on CMake)

Marcel

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

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

[Gilles Caulier-4]

Ah, i'm waiting a question about a native Win32 port. well, i can said than this is possibe to do since QT4 and KDE4 are ported to win32 (:=)))

 

Of course, we need to compile digiKam and co under win32 and see if all is ok... I'm very curious to see digiKam running out of Linux, and not only under Win32, but also MacOS X, an OS used by pro-photograph...

 

Marcel, since a long time, i'm checking all the code to see where we have pure linux depencies

 

- In digiKam, we have some X11 API call to checked if CTRL or SHIFT keys are pressed during D&D. I don't know why this way have been used by Renchi instead to use QT API. This point must be fixed for 0.9.2

 

- In digiKam, we need to check how the color Theme core is implemented to be sure if it's portable.

 

- i'm not sure if LCMS library canbe compiled under Win32. Paco, can you confirm it ? 
 

There is no problem to port DigikamImagePlugins, libkipi, libkexiv2, and libkdcraw.

 

In Kipi-plugins, imlib2 library use a pure X11 depency to run. This one is always used in SlideShow plugin. There is no advantage to continue to use it, to only cache pictures loading in memory (imlib2 is not used in this plugin to render image on screen if i remember). The solution is simple : remove imlib2 depency and use the same QT cache mechanism like it's used in the recent OPENGL viewer plugin. Angelo, Valerio, perhaps a common of QT cache mechanism in kipi-plugins/common place will be fine.

 

Gilles

 

 

 

2007/3/1, Mikolaj Machowski <[hidden email]>:

Dnia czwartek 01 marzec 2007, Gilles Caulier napisał:
> About QT4 this is my plan :

About Qt4: what about MS-Windows port?

m.

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

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