Gilles Caulier | 1 Mar 10:24 2007
Picon

Prepare the future : merging digiKam and DigikamImagePlugins

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
Digikam-devel@...
https://mail.kde.org/mailman/listinfo/digikam-devel
Fabien | 1 Mar 12:22 2007
Picon

Re: Prepare the future : merging digiKam and DigikamImagePlugins

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
Arnd Baecker | 1 Mar 12:47 2007
Picon

Re: Prepare the future : merging digiKam and DigikamImagePlugins

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
Cesar | 1 Mar 13:07 2007
Picon

[Bug 142363] New: It don't detect my Sony DSC-P9 digital camera.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.kde.org/show_bug.cgi?id=142363         
           Summary: It don't detect my Sony DSC-P9 digital camera.
           Product: digikam
           Version: 0.8.2
          Platform: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: neuron ozu es

Version:           0.8.2 (using KDE 3.5.5 "release 45.2" , openSUSE 10.2)
Compiler:          Target: i586-suse-linux
OS:                Linux (i686) release 2.6.18.2-34-default

My OpenSuse version detect a Sony DSC digital camera, but it is not posible extract images.
Gilles Caulier | 1 Mar 13:31 2007
Picon

Re: libkdcraw

Thanks Boudewijn, i will ping you when libkdcraw will be ready to use with QT4
 
Friendly
 
Gilles

 
2007/3/1, Boudewijn Rempt <boud-4ZnIdb/JcHVAfugRpC6u6w@public.gmane.org>:
On Thursday 01 March 2007, you wrote:
> Hi Boudewijn,
>
> How are you ? Witch great progress in krita since few month.
> Congratulations...

Thanks -- I'm quite well.

> I just ping you about my new shared library named "libkdcraw" witch is a
> C++ wrapper around dcraw decoder. It's used by RAW Converter kipiplugin and
> later digiKam core (with next 0.9.2 release - i have a big patch on my
> computer ready to commit)

I've been following development & I've been testing it recently, because I
just acquired a camera that can do RAW (a cheap but nice fujifilm 6500). I
did intend to start using libkdcraw in Krita 2.0.

> I have worked hard to do this library. You can consider than the code is
> stable. I'm just need to finalize the API doc.

I guess that as soon as it's ported, I'll start using it in Krita :-)


--
Boudewijn Rempt
http://www.valdyas.org/fading/index.cgi


_______________________________________________
Digikam-devel mailing list
Digikam-devel@...
https://mail.kde.org/mailman/listinfo/digikam-devel
Gilles Caulier | 1 Mar 13:52 2007
Picon

Re: Prepare the future : merging digiKam and DigikamImagePlugins

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 <arnd.baecker-S0/GAf8tV78@public.gmane.org>:
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
Digikam-devel-RoXCvvDuEio@public.gmane.org
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
Digikam-devel@...
https://mail.kde.org/mailman/listinfo/digikam-devel
Gilles Caulier | 1 Mar 13:58 2007
Picon

[Bug 142363] It don't detect my Sony DSC-P9 digital camera.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugs.kde.org/show_bug.cgi?id=142363         
caulier.gilles gmail com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |Camera GUI

------- Additional Comments From caulier.gilles gmail com  2007-03-01 13:58 -------
Cesar,

please note than nothing will be fixed in old 0.8.2 release since 0.9.0 is out with a huge list of improvement.

0.9.1 release will be done this week end. I recommend to update digiKam and also libgphoto2 library witch is
used to drive camera.

Gilles Caulier
Gerhard Kulzer | 1 Mar 15:30 2007
Picon

Re: Prepare the future : merging digiKam and DigikamImagePlugins

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
Digikam-devel@...
https://mail.kde.org/mailman/listinfo/digikam-devel
Arnd Baecker | 1 Mar 15:14 2007
Picon

compile from svn problem

Hi,

my usual install from svn
(using the script from http://www.digikam.org/?q=download/svn)
does not work.

The problem seems to be libjasper:

checking for jas_init in -ljasper... no
configure: WARNING: digiKam requires libjasper >= 1.7.0
configure: WARNING: digiKam requires libjasper >= 1.7.0; digiKam will not
be compiled.
configure: creating ./config.status
wrong input (flag != 4) at admin/conf.change.pl line 117, <> line 1261.
config.status: creating digikam/utilities/hotplug/digikam-download.desktop

However, libjasper is installed
digikam/lib $ ls -l | grep jasper
-rw-r--r-- 1 abaecker abaecker 1266404 Mar  1 14:51 libjasper.a
-rwxr-xr-x 1 abaecker abaecker     817 Mar  1 14:51 libjasper.la

and does contain jas_init:

nm libjasper.a | grep jas_init
jas_init.o:
00000010 T jas_init
[ptpcp3] /home/scratch/abaecker/SOFTWARE/digikam/lib $

What puzzles me is:
- all the other stuff (like exiv2) is in the same directory
  and is recognized by configure.
- this did not happen a few days ago
  (hmm, I did a small update on my machine, but this should not
   affect this ...)

How can I debug such configure problem in a systematic way?

Best, Arnd
F.J.Cruz | 1 Mar 16:27 2007
Picon

Re: Prepare the future : merging digiKam and DigikamImagePlugins

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

Gmane