Way to handle this is the use of proxy objects, or handles, in cases where a 1:1 Interfaces to languages that handle memory differently (using a gc, refcounting, etc). Lifetimes or performing manual memory management - especially for It should be able to do this without explicitly managing object Loaded, or wish to create objects that will exist after it is unloaded. One thing I am pretty clear on is how to handle object lifetime issues.Ī script or plug-in may wish to use objects that existed before it was That gives the beginnings of the structure we'd need the API to have as far as users of it are concerned.ĭetails Object Lifetimes & Memory Management
Once we know what we want to initially expose, we collect functionality into logical groups or entities based on what it applies to or acts on (works on the entire app vs works on the document vs works on a text pageitem, etc). The existing scripter will serve as the beginnings of a guide to what's needed. We need to start, I think, by (a) looking at how others have done it (especially KDE apps supporting Kross, see here the Kross Tutorials), and (b) writing down everything we want the plug-in API to enable people to do.
Exposes signals that can be connected to when a script/plugin wants to be informed of important events. Provides important hooks for extending the GUI (exposes menu manager, key toolbars, action manager, etc). See current scripter for an outline of some of the needed functionality. 
Application-wide functions (open doc etc). Document manipulation (sizes, export, page management). Logically groups functionality, often consolidating a number of objects into one. Hides direct use of pointers to structures behind indexes into structures, names, proxy objects, or other abstractions. Factory functions rather than direct ctor use. Handles or proxy objects for important internal objects. Handle ownership issues related to exposing the API to refcounting or GC'd languages with:. Abstracted some functionality into simpler, but perhaps slower, interfaces. Hide internal-only structure and complexity. This would be a collection of wrappers around the core code that: Often performance takes priority over easy understanding for the new user, and some have a considerable amount of historical cruft.įor all these reasons, we would benefit signifiantly from providing a new public C++ API to Scribus's functionality. They're also sometimes complex, hard to use, and often underdocumented. Scribus's internal interfaces are in constant flux as code is improved and refactored. 1.2.1 Object Lifetimes & Memory Management.
0 kommentar(er)
