Public C++ API: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
Line 5: | Line 5: | ||
For all these reasons, we would benefit signifiantly from providing a new public C++ API to Scribus's functionality. This would be a collection of wrappers around the core code that: | For all these reasons, we would benefit signifiantly from providing a new public C++ API to Scribus's functionality. This would be a collection of wrappers around the core code that: | ||
* Hide internal-only structure and complexity | |||
* Abstracted some functionality into simpler, but perhaps slower, interfaces | |||
* Handle ownership issues related to exposing the API to refcounting or GC'd languages with: | |||
** Handles or proxy objects for important internal objects | |||
** Factory functions rather than direct ctor use | |||
* Hides direct use of pointers to structures behind indexes into structures, names, proxy objects, or other abstractions. | |||
* Logically groups functionality, often consolidating a number of objects into one | |||
** Needs interfaces to: | |||
*** Text system | |||
*** Pages | |||
*** PageItems | |||
*** Document manipulation (sizes, export, page management) | |||
*** Application-wide functions (open doc etc) | |||
*** GUI (menus, toolbars, etc) | |||
* Provides important hooks for extending the GUI (exposes menu manager, key toolbars, action manager, etc) | |||
* Exposes signals that can be connected to when a script/plugin wants to be informed of important events |
Revision as of 17:35, 7 April 2007
Public C++ API
Scribus's internal interfaces are in constant flux as code is improved and refactored. They're also sometimes complex, hard to use, and often underdocumented. Often performance takes priority over easy understanding for the new user, and some have a considerable amount of historical cruft.
For all these reasons, we would benefit signifiantly from providing a new public C++ API to Scribus's functionality. This would be a collection of wrappers around the core code that:
- Hide internal-only structure and complexity
- Abstracted some functionality into simpler, but perhaps slower, interfaces
- Handle ownership issues related to exposing the API to refcounting or GC'd languages with:
- Handles or proxy objects for important internal objects
- Factory functions rather than direct ctor use
- Hides direct use of pointers to structures behind indexes into structures, names, proxy objects, or other abstractions.
- Logically groups functionality, often consolidating a number of objects into one
- Needs interfaces to:
- Text system
- Pages
- PageItems
- Document manipulation (sizes, export, page management)
- Application-wide functions (open doc etc)
- GUI (menus, toolbars, etc)
- Needs interfaces to:
- Provides important hooks for extending the GUI (exposes menu manager, key toolbars, action manager, etc)
- Exposes signals that can be connected to when a script/plugin wants to be informed of important events