deskew plugin
Schleimer, Ben
bensch128 at yahoo.com
Mon Mar 19 17:00:29 CET 2007
--- Cyrille Berger <cberger at cberger.net> wrote:
> > We're aiming for 1) -- but we didn't want to install everything by default
> > because that means that the krita/image and krita/ui libraries have export
> > all their symbols, which is a Bad Thing, apparently.
> It's a bad things because every symbol you export every header you install can
> be use ! Which means that if you change either the API (not nice) or the ABI
> (even more not nice) you break the plugin. The real option is to consider the
> list of what is usefull to plugins and what API/ABI we _won't_ change.
I suppose that copying+pasting plugins from krita/plugins to krita-plugins isn't really the best
route but it's sure easier to get started on a new plugin that way then to have to start a new one
from scratch. For example, I'm doing the gradient clone tool so I've simply copied the duplicate
tool plugin and will just modify the copy function but leave the rest alone. Its easier not to
play games with which headers to remove because they're not part of the "external plugin API" and
add a includedir path to them. This of course is the problematic part.
>
> Krita will have show maturity when (and only when) we will see external
> plugins project.
IMHO Krita will be mature when it's ABI doesn't have to change for external developers to
implement reasonable outside plugins. (Reasonable is course subjective :) I suppose krita will be
very mature when it can copy TT and really truely not change ABI between major revisions and API
between minor revisions.
More information about the kimageshop
mailing list