Hallöchen!

Sebastian Kraft writes:

> I just had a look at the lfModifier Class. One solution would be to
> create a new lfModifier::Create() with a different parameter set in
> parallel and mark the old one as deprecated. However, putting all
> necessary parameters in one function would probably be too
> confusing.

Yes, I see this problem, too.

> Do you have an idea how we can split this in a meaningful way?

I thought about the following solution yesterday:

We may introduce a new struct lfImage.  It is contains no methods,
but lfLens and lfCamera object, width, height (in px), the pixel
format, focal length, aperture, and distance.  The constructor of
lfModifier gets this signature:

    lfModifier(lfImage, reverse)

Then, lfModifier gets the methods:

    lfModifier::PrepareDistortionCorrection()
    lfModifier::PrepareTCACorrection()
    lfModifier::PrepareVignettingCorrection()
    lfModifier::PrepareProjectionTransform(target_projection)
    lfModifier::PrepareScaling(scale)

> [...]
>
>> 3. Prepend the following to lensfun.h.in:
>>
>>     #ifndef __G_TYPES_H__
>>     typedef char gchar;
>>     typedef int gint;
>> [...]
>>     #endif
>>
>> [...]
>>
>> (3) is the ugly part of course.
>
> And that is what should be avoided by this strange arrangement in
> lensfun. The glib types should not appear in the header because we
> do not want them to be imported into every calling application.

Actually, lensfunprv.h can stay.  I was wrong in trying to merge it
with lensfun.h.in completely.  As a very first step, @Sebastian:
Please review my branch lensfunprv-refactoring and merge it if it's
okay.

In order to have real constructors, we need to merge the two
lfExt... classes with their parents.  The two GLib types here are
GPtrArray and gchar.

What do you think of this idea: Rename gchar -> char and GPtrArray
-> void in the declarations moved to lensfun.h.in and some other
places, and static-typecast them back to the GLib types when we call
GLib functions?

Tschö,
Torsten.

-- 
Torsten Bronger    Jabber ID: torsten.bron...@jabber.rwth-aachen.de
                                  or http://bronger-jmp.appspot.com


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Lensfun-users mailing list
Lensfun-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lensfun-users

Reply via email to