Hi,
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. Do
you have an idea how we can split this in a meaningful way? Maybe:
// Create a modifier object
lfModifier::Create(
const lfLens *lens,
lfLensType targeom,
float scale,
int flags,
bool reverse);
// initialize with image parameters
lfModifier::Initialize(
lfPixelFormat format,
int width,
int height,
float crop,
float focal,
float aperture,
float distance,
)
>
> 3. Prepend the following to lensfun.h.in:
>
> #ifndef __G_TYPES_H__
> typedef char gchar;
> typedef int gint;
> [...]
> #endif
>
> 4. Move lensfunprv.h into lensfun.h.in.
>
> (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.
Sebastian
------------------------------------------------------------------------------
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
