[Digikam-devel] Fwd: [Proposed solution] zoom factor error

[Gilles Caulier]

---------- Forwarded message ----------
From: Gilles Caulier <caulier.gilles at gmail.com>
Date: 2008/8/5
Subject: Re: [Proposed solution] zoom factor error
To: Unai Garro <ugarro at gmail.com>


2008/8/5 Unai Garro <ugarro at gmail.com>:
>
>> I'm currently very busy with real life.
>>
>> If you want to contribute properlly, use bugzilla post your patch and
>> let's _constructive_ comments at the right place. if i don't respond
>> to irc you must understand that i can be busy (i have my main car
>> broken) or i work on other important place. No need to perturb me to
>> spam my irc account... Unforget that i work on my free time for open
>> source. It's not a real job. Perhaps are you more friendly with pro
>> software as Bibble pro (like i can read on your irc post !)
>>
>>
>
> Please accept my apology for being rude, but the digikam's source code
> README clearly reads:
>
> "If you want contribute to digiKam developments do email at :
> digikam-devel at kde.org"
>

In fact posting a new file in bugzilla report the file content to
digikam-devel by default. I will change README file to be more clear.

But unforget that the usual way is to use bugzilla to post report +
patch. nothing is lost, instead than a mailing list where messages
will diseapear speedly into a large flux of mails. Also, Mailling list
attachement is limited to 40 Kb. into bugzilla 1Mb...

See bugzilla as a queue of task to do. Imagine that i going to
vacation for a while, your message can be lost definitily. With
Bugzilla, nothing is lost, others developers/users can test your patch
etc...

> And that's what I did. No bugzilla comments. Maybe that needs a change?
>
> I thought my comments were rather friendly:
>   http://mail.kde.org/pipermail/digikam-devel/2008-August/020456.html
> And I submitted the patch to the lists, just like it was suggested:
>   http://mail.kde.org/pipermail/digikam-devel/2008-August/020483.html
>
> I needed a response from you. Other coders refuse to accept any patches
> until you say go. And I cannot code more unless I know you will like the way
> I'm going to do it. I may waste 2 weeks of code just to hear there's
> somebody else doing it in a different way. it happenned to me in digikam in
> the past, remember?

yes, of course (:=)))


>and it's annoying.
>
> The fact that I praise other software doesn't mean I don't praise digikam as
> I have done several times in my blogs, even in my last post around 5 hours
> ago.
>
> http://www.kdedevelopers.org/node/3592
>
> I think having good references in other applications is good. Bibble is a
> good reference for speed and batching, but lightzone is much better
> reference for editor. But both of them suck for sorting photos, while
> digikam is great at it. Each got their strengths. I use what suits me for
> each thing.
>
> Anyway, I want it to beat commercial software. I coded digikam quite a bit
> in the past. You know that: Hot pixels plugin, the 16 bits conversion,
> allowing scrolling of images, autodeletion of images after download and a
> few others.
>
> Please don't take me wrong. I'm trying to use my holidays in the best way
> possible and that's trying to help the project.
> But I don't want to duplicate efforts. If you don't say "go" to something, I
> may be duplicating work you or somebody else are doing. It happenned in the
> past with some patches I had for digikam. And I don't have much time for
> that.

No, there is no duplicates for your zooming patch

>
> I've seen your post on the raw importer for example.  I didn't know it
> existed, and I was trying to do something very similar with batch
> capabilities. Are you interested on that?

Yes, but yet. And it's a huge work to do. In fact i have plan to do
more better : a Batch Queue manager. But this require new data hosted
by Database, and it's can only do into KDE4.

> And in my interests there's also improving raw decoding speed by getting rid
> (if possible) of dcraw executable. Some people have managed already making a
> library out of it. Would you be interested in something like that too?

yes. forget libopenraw which still unsuitable to process demosaicing.
I have planed to patch libkdcraw to use libraw instead dcraw.

libraw implement 90% of dcraw features, excepted all color management
options. But we can use multithreading as well withouit to fork dcraw
in a separate process (which is more long to init). If you is
interrested to patch libkdcraw, let's me hear. Nite that the libkdcraw
to patch is KDE4, not KDE3.

About your patch, it's against KDE3 or KDE4 ? The code sound fine for
me (not yet tested here)

Andi, can you test Unai patch's on your computer and give me your feedback ?

Gilles Caulier

Gilles