After that, there are other complicated details so that _init_foo_class
is used appropriately,
i.e. it must be called at module initialization time in the PIC case
only, with a heap-allocated
structure passed as a parameter. However, this can also be performed
with macros.
I'm preparing a patch to show how this can work on the existing code
base. However this is
going to take a long time, so I would prefer if we could first submit
your changes, then slowly
migrate to this new scheme (we can do this piece by piece, fortunately).
There are also complications due to the fact that modules themselves are
defined through a
constant table (but again, we can work with this with macros), and the
challenge of "derived classes",
but I believe we should be able to support these as well with the
minimal impact on duplication.
Regards
Hi David,
I did some of the initial work and design the PIC version of the FT2
module system (that was a while ago).
I am not sure what the current state of the code is (working on another
project), but IIRC what most of what you describe has already been
implemented. At least if I understood correctly.
To be more specific:
The code to initialize the table of default modules is already defined
automatically in the PIC version (see src/base/ftinit.c). It uses the
macros in ft_module.h.
That user-configurable part of FT2 has not changed. Modules defined in
the h file (using the macros) have their module struct allocation and
init functions called automatically, and are then added to FT2 using
FT_Add_Module(). When FT2 is released, the default modules are also
released via the appropriate call.
As for users that don't want to use the default module list, and want to
use FT_Add_Module themselves:
The idea was that they should call FT_Create_Class_foo_class(), and then
it's the user's responsibility to pass the pointer to FT_Add_Module(),
and at the end to use FT_Destroy_Class_foo_class() to release it.
Again, as I am not sure what the current state is, I can't say much more.
Mickey
_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel