Hello, On Mon, 26 Jun 2006, Igor Russkih wrote:
> For me this patch looks fine, its good idea for MC to detect colorer's > library presence in runtime. > > However the implementation is not rather straightforward because of > that separate glue library. Yes, it adds another level, but at the moment it is the only working solution. By using this library we avoid linking to libcolorer at build time. > If such a dynamic loading is best case for MC, maybe it is worth > implementing it in more 'valid' way? I mean I can develop a set of > 'neutral' C API, which will be included directly into libcolorer The dynamic loading is desired since it drops the dependency on libcolorer. For the package maintainer this means that she/he can build MC with colorer support but the package will not pull libcolorer unless specifically requested to do so (by the user). This is very important IMHO. > Then MC can dynamically load libcolorer and import all the required > API functionality as it imports 'colorer_get_interface' via gmodule in > Pavel's version. Yes. > Surely it will require additional efforts as on my side, as on MC > side, but with this we'll get better colorer's integration with MC. > Moreover colorer will get a general C-based API, which it doesn't have > now. > > Pavel, whats your opinion on this? If you are willing to change colorer so that it will become C-friendly you are more than welcome. Providing a generic interface seems a better solution than writing a new plugin for every editor in the wild. Of course custom plugins could be tuned better to fit the specific requirements of XYZ editor. I think it is up to you after all - either way I'll try to help getting colorer support into MC. _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel