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

[Gilles Caulier]

2008/8/5 Gilles Caulier <caulier.gilles at gmail.com>:
> ---------- 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.
>

Forget to said than libraw is available at this place:

http://www.libraw.org/

If you patch libkdcraw to support libraw, you must lets dcraw as well
and include libraw as optionnal until we hack it indeep.

Best

Gilles Caulier