Differences between revisions 5 and 28 (spanning 23 versions)
Revision 5 as of 2008-08-04 18:58:01
Size: 16903
Comment:
Revision 28 as of 2016-05-12 13:59:07
Size: 13388
Editor: inetproxy-p
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Modules =
  
= Packages and Modules Overview =
The wxArt2D code is split in two packages, wxdocview and wxart2d. These packages each containing several modules. The modules are organized as a hierarchy, with higher level modules depending on the lower level ones.
For the whole framework, wxart2d depends on wxdocview, to have applications with multiple drawing, organized as documents, containing those drawings.
It is also possible to build the wxart2d, without using the wxdocview framework. That will gives you mainly a canvas with drawing inside, and tools to work on the drawing.

A module contains mainly files that form together a certain functionality. Modules do depend upon each other, and a certain hierarchy is in them. The hierarchy is not strict, sometimes in modules other modules are used but when wanted they can be switched on or off. Special attention is paid to be able to remove higher order modules, without problem. So the docview module can be used without the canvas module. But also lower order modules like xmlparse are optional for the docview module. Each module compiles and links to a library. Whereas, some of the modules require third party libraries, the basic wxArt2D modules requires only the wxWidgets library.
Line 5: Line 10:
 The wxArt2D code is implemented as a hierarchy of modules with higher level modules
depending on the lower level ones. Each module compiles and links to a library.
Whereas, some of the modules require third party libraries, the basic wxArt2D
modules require only the wxWidgets library.
  
=== DocviewModule ===
= Package wxDocView =
This is the base package. It can be used without the wxart2d package. It consists of three modules.
Line 12: Line 13:
/DocviewModule == Modules ==
At the very bottom, the GeneralModule providing basic functionalities, e.g. smart pointers and properties and event handling. The optional XmlParseModule is needed for XML IO. The DocviewModule defines the document view framework.
Line 14: Line 16:
This is the base module for creating a multi Document and View framework.
It is based on the ideas behind the original wxWidgets Docview classes,
but redesigned to use events as the means of communicating between the document and the view.
This has resulted in a very flexible framework with enhanced ease of use.
The main advantage is in the way views of documents are organized.
The association of views with the application's windows is via the a2dViewConnector class
which results in a view having a single pointer to its parent window. In this way views are made application
independent, and views can be stored in a software library and used
by other applications and/or different flavors of the same application.
For instance an editor view which manipulates an object of a document can
be used in a multi or single window application without modification.
=== General Module ===
The module general is used by all modules. It contains classes etc. that can be used in all other modules. <<Dox(a2dObject)>> and its derived property classes are in this module. Another one is <<Dox(a2dSmrtPtr)>>, which is a smart pointer template class. It works for classes with a Release and Own mechanism, which are all <<Dox(a2dObject)>> derived classes. See GeneralModule for more.
Line 26: Line 19:
Events are used to notify, collect information, or start an action. These events are managed by an event distributer to which it is possible to register a class. In this way independent classes, can be easily hooked into the framework. For example, Views receive update events from associated documents, via the event distributer. A document has no idea how many views of itself there are. A view can even display information from one or more documents. By virtue of the event system the classes in the framework are loosely coupled. Additionally one can use a document class by itself, and without the rest of the framework classes. Furthermore a Document and a View combined with a display window are enough for the implementation of a complete application. The last situation is the simplest use of a a2dCanvas in the wxArt2D library.
  
The Event Distributor when combined with the Command Processor make possible a variety of multiple views from multiple documents. Each View additionally has a plugin capability for adding tools etc. Undo/Redo capability is provided by the Command Processor by virtue of its ability to stack commands. Thus the undoing of modifications to a document are catered for.
  
=== XmlParse Module ===
This module contains the code for the Pullparser, it uses expat for parsing the xml from a file or string. XML Pull parsing is ideal for parsing XML data from a file, especially where the reading of this data is distributed through all classes in other modules, and those classes are deciding what needs to be read from the file. This is different from a parser that reads all XML data at once into a DOM tree. Next to reading XML data, this module also supports classes to easily write XML data to a file, and again in such a manner that the writing of the data is distributed through all classes in other modules. The CVG format uses this module for saving a <<Dox(a2dCanvasDocument)>> to a file and/or load it from a file. <<Dox(a2dIOHandlerXmlSerOut)>> is the class used for that, and it is a general class for serializing class data.
Line 31: Line 22:
The Docview module is at the heart of the wxArt2D libary.It can also be used by
other applications which require an advanced Document View system.
  
=== Docview Module ===
The docview module contains the classes for the docview framework. It makes it easy to implement applications that open several documents, and display the data in the documents in one or more windows using views. The editor module depends on it. See DocviewModule for more.
Line 35: Line 25:
The wxArt2D Docview framework is an improvement over the wxWidgets Docview classes for the following reasons:-
  
   * View connectors make a view independent from a window. The view connector associates a window with a view. This was the biggest stumbling block with the wxWidgets version, and which made it unsuitable for use as a base for wxArt2D, where view and rendering are combined in one class and capable of being plugged into a a2dCanvas. Views or not responsible for windows, and in fact Views can be plugged in an out of its display window.Moreover, it can have a document from which it can display information, however, this is not a must.
   * Combining several views into one frame is easy. A view may or may not have a document attached, so a set of Views can remain attached to a window, and its parent, even if the documents are all closed. On opening a new document all of the existing views can be re-used for displaying a view of the new document. In the wxWidgets version this is close to impossible.
   * documents do not own views, and do not have a list of views, thus making many things much easier. For example, a view can display information from several documents. The Event Distributor is the key to this by accepting events from a Document and dispatching them to Views and other registered classes. Thus it is possible for a view to claim an event and update its view of the associated Document.
   * Almost everything works via events, and in many cases special events are sent to a global event distributor which dispatches the events to those handler classes registered to it. In this way your application is always in complete synchronization, something that is not possible in the wxWidgets version.
   * the concept of a document manager, is replaced by the Command Processor. This class, in addition to doing what the old docmanager did, adds a central Command Processor to the Application. The Command Processor maintains documents and templates, and manages the view for the current document. Command Processing is implemented in such a way as to make macro recording much easier. The Command Processor commands are implemented as ascii strings. Internal there is a variable list, which can be used as part of commands. Commands can set and use variables, either set by the application or by external commands.
   * Important is the way document and their view and windows are closed. A view can be closed for two reasons. One when its frame/window is closed, two when a/its document is closed. So two paths. The second path does come to the view via its document via a viewclose event, and it may/sometimes should also close the windows that contains the view. In a multiframe app this is the case. In a single frame having several views, the windows should stay intact, and maybe even the view, and only the document should be decoupled from its document. In that case the views can be used for a new document later on. In the first path ( closing the frame ), the close event comes form the window, and is sent to the view, and closing the view might lead to also needing to close the document it displays. This is above situation is arranged in the wxArt2D version in an orderly manner, without confusion.
   * There are two templates on to link file extension to document types and an IOhandler class to read such a file into a document. A second template is used to couple document types to view types. This is different form the original docview classes where there was only one template, which coupled file extension plus document type plus viewtype in one. In many cases this does not make sense.
   * Iohandlers are the classes to read files into document, a basic XML pull/push parser iohandler is part of the docview classes. This makes it easy for you to read and write XML based data to and from into an internal document.
  
= Package wxArt2D =
This package requires the package wxdocview. Its many modules can be grouped in

 * Drawer modules
 * Canvas and editor modules
 * IO modules
 * Scripting modules

== Drawer Modules ==
The [[ArtBaseModule|ArtbaseModule]] is the base for drawing context classes, it depends only upon the GeneralModule. The [[ArtBaseModule|ArtbaseModule]] has all definitions for styles like stroke, fill and fonts. AggDrawerModule and GdiPlusDrawerModule use those classes for implementation of extra drawing context classes.

=== ArtBase Module ===
This module contains basic geometric classes, and the abstract a2dDrawer2D class, classes derived from this are drawing context classes. The drawing context is able to draw relative to a matrix that is set to the drawing context first. The drawing contexts classes can be used standalone for wxWidgets, and do not depend on the rest of wxArt2D. That is, it uses the general module, and the xmlparse module is used inside the style classes, but it can be switched off. There is one drawing context in this module which uses wxDc and wxMemoryDc to do normal wxWidgets like drawing. The modules aggdrawer and gdiplusdrawer, use this module to implement a drawing context which can do antialiased drawing.

=== AggDrawer Module ===
Drawing context for a2dCanvasDoucment, based on the !AntiGrain rendering Library, http://www.antigrain.com/. With the current version (which is included with wxArt2D), one can already do anti-aliased rendering and editing.

This module defines drawing context classes for anti aliased double buffer drawing. It only depends on the general and artbase modules. The module is an implementation of the a2dDrawer2D class, and does not depend on the canvas module. So used for drawing only, but in combination with the canvas module, can be used to render <<Dox(a2dCanvas)>> its <<Dox(a2dDrawing)>>.

=== GdiPlusDrawer Module ===
Gdi+ (part of WinXP and newer) is used to do the actual drawing. This module defines drawing context classes for anti aliased double buffer drawing. It only depends on the general and artbase module. The module is an implementation of the wxDrawer2D class, and doesn't depend on the canvas module. So use for drawing, but in combination with the canvas module, can be used to render canvas documents.

== Canvas and Editor Modules ==
The CanvasModule is on top of the GeneralModule and the [[ArtBaseModule|ArtbaseModule]]. The EditorModule is an extension to the document framework designed for containing drawings in documents. The CanExtObjModule is an extension on the CanvasModule, mainly for more advanced graphical objects and IO. The [[CanvasModule |CanvasModule]] also adds editing functionality to canvas drawing. It defines tools to interactively edit canvas objects. The CurveModule defines very advanced canvas objects, to display sets of curves and plots, which can be edited.

The CurveModule is on top of the CanvasModule, and so is CanExtObjModule. Both implement complicated non basic a2dCanvasObjects. It is the best to combine higher order a2dCanvasObjects together with its tools to draw/ manipulate them.
Line 48: Line 54:
/CanvasModule The canvas module builds on top of the general module and th [[ArtBaseModule|ArtbaseModule]], creating a library for 2D drawing applications. A <<Dox(a2dDrawing)>> does contain a hierarchy of drawing objects <<Dox(a2dCanvasObject)>>, which can be displayed on a <<Dox(a2dCanvas)>>. The <<Dox(a2dCanvas)>> uses internally a <<Dox(a2dDrawingPart)>>, which on its turn uses <<Dox(a2dDrawer2D)>> as drawing context to do the actual drawing of the objects in the <<Dox(a2dDrawing)>>.
One can inject a <<Dox(a2dToolController)>> into a <<Dox(a2dDrawingPart)>>, which gives you a large set of interactive drawing tools, to edit the drawing that is displayed on the canvas window. Those tools issue commands to the <<Dox(a2dCanvasCommandProcessor)>>, and that make the editing undo-able.
Line 50: Line 57:
 The module which implements on
top of the docview module all needed to store drawing in a
a2dCanvasDocument and display them with a a2dCanvasView view on a2dCanvas
windows.
See CanvasModule for more.
Line 55: Line 59:
The basic tool and toolcontroller plus a commandprocessor are also here.
  
=== Editor Module ===

/EditorModule

The tools and toolcontroller module. A controller can be plugged into a
a2dCanvasView. A a2dDrawer2D is an abstract drawing context class, each
a2dCanvasView has one, which it uses to draw a a2dCanvasDocument on to the
canvas.

The controller intercepts all events, from the a2dCanvas window,
before they are handled by the a2dCanvasView class. The controller, has a
stack of tools. When a tool is active, it will receive the events, and
based on that, manipulate the contents of the document, which is
displayed on the a2dCanvas.
  

The a2dCanvasView on its turn redirect events to the a2dCanvasObjects which are part of the
a2dCanvasDocument, that is displayed by that a2dCanvasView.
  

The editor module contains a stack oriented controller class, with a large
set of tools used to draw object, and edit those objects. Other tools
are there to copy, drag, delete object. A zoom tool, can be used at all
times to zoom into a drawing, even when one is already busy drawing
etc. with a tool at that moment.
  

All tools are pushed on a stack, and when a tool is popped from the stack, the first tools on the
stack will become active again. This is also the reason that one can push a zoom tool while busy drawing a polygon. This feature makes it easy to do extremely accurate drawing.
  
=== Curve Modules ===

[[http://wxart2d.sourceforge.net/modules/curve/curvy.html|Curve Modules]]

Special objects for drawing multiple curves or bars etc. on a plot
object. It can have makers attached to curves, and show-maker objects to
display and edit the position of the markers on the curve.

This module gets the maximum from the wxArt2D library. It uses
dependencies between curve objects and its marker object, in order to
keep them in sync while editing the curve or marker. It also uses
sub-editing, therefore in a plot of curves, one can edit each curve and
the markers on the curve. First one starts editing the plot itself, but
the plot object pushes other tools when clicking on the objects
contained within the plot. Events in a2dCanvasObjects are organized
such, that events travel through a hierarchy of nested a2dCanvasObjects.
This makes the sub-editing of object possible.
  
=== SvgIO ===

Basic Scalable Vector Graphics In and Output. Its understands all basic
primitives in SVG and hierarchy, but the fancy stuff like animation
etc. not. When reading SVG, it is translated/mapped into
a2dCanvasDocument.

When writing as SVG, all object stored into the
a2dCanvasDocument are mapped to most advanced SVG drawing possible. A
a2dCanvasDocument is meant for many drawing application, and not just
for viewing SVG. The idea is that a2dCanvasObject derived complex
objects can also be saved and loaded. But in case of saving as SVG,
this will result in a simple drawing, and the original object can never
be reconstructed. For that we have the CVG format.
  
=== GDSIO ===

GdsII format In and Output. This is a Computer Aided Design format for
the chip industry. It is layers based, and contains hierarchy in so
called structures. Structures are like sub-drawings, which can be
referenced at any position on a higher level. This a key feature in
wxArt2D, it knows how to deal with multiple references to one drawing.
Automatic updating, and bounding box calculation is all based on this
principle. Many canvas classes, can not do this.

=== CVG In Out ===

This is not a real module, but an option,
it allows you to save a a2dCanvasDocument into a file and read it back.
The format is XML based, and save a hierarchical a2dCanvasDocument into
a file. This format uses the wxWidgets dynamic class information, to
store a class and its lower level children to a file, and later read
them back. Based on the class name which is stored into the CVG format,
the class can be reconstructed. The nice thing is that you can easily
save your own canvas objects into the CVG format also. Two member
functions to read and write the CVG format for a derived canvas object ,
is all that is needed. When another wxArt2D based program does not know
the object you have written, it will skip it when reading it.
  
=== AggDrawer ===
  
Drawing context for a2dCanvasDoucment, based on the [[http://www.antigrain.com/][AntiGrain rendering Library]].
This library is still in development. But with the current version (which is included with wxArt2D ), one can already do anti-aliased rendering and editing.
   
= Module Hierarchy =

wxArt2D is set up in modules.A modules contains mainly files that form together a certain
functionality. Modules do depend upon each other, and a certain hierarchy
is in them. The hierarchy is not strict, sometimes in modules other
modules are used but when wanted they can be switched on or off. Special attention is payed to be able to remove higher order modules, without problem, So the docview module can be used without the canvas
module. But also lower order modules like xmlparse are optional for the docview module.
  
=== General Module ===

/GeneralModule

  The module general is used by all modules. It contains classes etc. that can be used in all other modules.<br />
a2dRefObject and its derived property classes are in this module.
Another one is a2dSmrtPtr, which is a smart pointer template class. It
works for classes with a Release and Own mechanism, which are all
a2dRefObject derived classes.<br />
  
=== xmlparse Module ===

  This module contains the code for the Pull-parser, it uses expat for parsing the xml fro a file or string.<br />
XML Pull parsing is ideal for parsing XML data from a file, but where
the reading of this data is distributed through all classes in other
modules, and those classes are deciding what needs to be read from the
file. This is different from a parser that reads all XML data at once
into a DOM tree. Next to reading XML data, this module also support you
to easily write XML data from a file, and again in such a manner that
the writing of the data is distributed through all classes in other
modules.<br />
The CVG format uses this module for saving a a2dCanvasDocument to a file
and/or load it from a file. a2dDocviewIOHandlerXmlSer is the class used
for that, and it is a general class for serialising class data.<br />
  
=== artbase Module ===

This module contains basic geometric classes, and the abstract
wxDrawer2D clas, classes derived from this are drawing context classes.<br />
  The drawing context is able to draw relative to a matrix that is set to the drawing context first.<br />
  The drawing contexts classes can be used standalone for wxWidgets, and that do not depend on the rest of wxArt2D.<br />
  That is, it uses the general module, and the xmlparse module is used inside the style classes, but it can be switched off.<br />
  There is one drawing context in this module which uses wxDc and wxMemoryDc to do normal drawing.<br />
  The module aggdrawer and libartdrawer, use this module to implement a drawing context which can do antialiased drawing.<br />
  
=== gdsiplusdrawer Module ===

This module defines a drawing context classes for anti aliased double
buffer drawing. Based on GDI+. They only depend on the general and artbase module. The
two modules are implementations of the a2dDrawer2D class, and don't
depend on the canvas module.

=== aggdrawer Module ===

This module defines a drawing context classes for anti aliased double
buffer drawing. Based on AntiGrain. They only depend on the general and artbase module. The
two modules are implementations of the a2dDrawer2D class, and don't
depend on the canvas module.
  
  
=== Docview Module ===

/DocviewModule

The docview module contains the classes for the docview framework. It
makes it easy to implement applications that open several documents,
and display its data one or more windows using views. The canvas module
and editor module depend on it. A base wrapping class for wrapping
commands/functions to external scripting languages is also in here.<br />
  
=== Canvas Module ===

/CanvasModule
 
The canvas module builds on top of the docview module a library for 2D
drawing applications. A a2dCanvasDocument does contain a hierarchy of
drawing objects (a2dCanvasOject), and the document can be displayed on
windows, using specialized view called a2dCanvasView. a2dCanvasView uses
internal the a2dDrawer2D derived classes to really draw the objects in
the a2dCanvasDocument. Each view can display a different part and level
of the hierarchy in the a2dCanvasDocument. The module depends on the
following modules: general, xmlparse (optional), artbase, docview.

=== io Modules ===
 The modules svgio and gdsio are using the
canvas module. But the canvas module can do without them, so this is
the way to add extra IO formats. The classes parse a file and
translates the contents to a a2dCanvasDocument containing the drawing in
the form of a2dCanvasOjects. They can also write the a2dCanvasDocument
back to a file, by traversing the document from the outside, and
translating the contents of the document back to a the file format. The
idea is to add more formats without extending the canvas module.
=== CanExtObj Module ===
This module defines canvas objects which are more advanced, and not used for any application. The idea is not to make the canvas module to big, and instead add extra fancy <<Dox(a2dCanvasObject)>> derived objects here. Currently there are several object to make references on a canvas towards other canvas documents <<Dox(a2dCanvasDocumentReference)>>. Like an overview of document which are open. Also those can be used to make documents which contain libraries of complex objects, <<Dox(a2dLibraryReference)>> Also interesting is <<Dox(a2dCanvasDocumentIOHandlerImageIn)>>, which allows you to save what is in a document to image files. You can define the size of the image, and automatically the document will be rendered into the image and saved into the format you choose.
Line 242: Line 64:
/EditorModule The editor module extends the basic DocviewModule, to contain a2dCanvasDocuments. And since a <<Dox(a2dCanvasDocument)>> can contain several <<Dox(a2dDrawing)>>'s, the CanvasModule is used to edit those drawing again.
A specialized editor frame and a command processor do extend the canvas command processor for working with multiple documents. <<Dox(a2dEditorFrame)>> is the spill, together with a lot of dialog classes which are called from it, but not directly. Instead all is going via the <<Dox(a2dCentralEditorCommandProcessor)>>. That way wxArt2D can record actions to a script. Most dialogs are more are less standalone, and work on the context and contents of the current active view. See EditorModule for more.
Line 244: Line 67:
 The editor module is for editing 2d
graphical data. Here are the tools, editor frame and the command
wrapper a2dCanvasDocviewCsPlWrapper. The last is more or less the
interface to the docview and canvas module. The module STSL does
interface through its wrapper in a similar manner.
=== Curve Module ===
Special objects for drawing multiple curves or bars etc. on a plot object. It can have markers attached to curves, and show-marker objects to display and edit the position of the markers on the curve.
Line 250: Line 70:
=== curve Module === This module gets the maximum from the wxArt2D library. It uses dependencies between curve objects and its marker object, in order to keep them in sync while editing the curve or marker. It also uses sub-editing, therefore in a plot of curves, one can edit each curve and the markers on the curve. First one starts editing the plot itself, but the plot object pushes other tools when clicking on the objects contained within the plot. Events in a2dCanvasObjects are organized such, that events travel through a hierarchy of nested a2dCanvasObjects. This makes the sub-editing of objects possible.
Line 252: Line 72:
 The curve module is on top of the canvas
module, and so is canextobj. Both implement complicated non basic
a2dCanvasObjects. Since the curve module has a tool inside, it also
depend on the editor module. Very likely it is the best to combine
higher order a2dCanvasObjects together with its tools to draw/manipulate
them. So therefore they will depend on the editor module in general.
== IO Modules ==
CVGIO, SVGIOModule, GDSIOModule and KeyIOModule are all implementing a specific way to save and load documents as defined in the EditorModule. The modules svgio and gdsio are using the editor module. But the editor module can do without them, so this is the way to add extra IO formats. The classes parse a file and translate the contents to a a2dCanvasDocument containing the drawing in the form of a2dCanvasOjects. They can also write the a2dCanvasDocument back to a file, by traversing the document from the outside, and translating the contents of the document back to a the file format. The idea is to add more formats without extending the canvas module.
Line 259: Line 75:
   === CVG IO ===
This is not a real module, but a built in option. It allows you to save a a2dCanvasDocument and/or a2dDrawing into a file and read it back. The format is XML based, and saves a hierarchical a2dCanvasDocument into a file. This format uses the wxWidgets dynamic class information, to store a class and its lower level children to a file, and later read them back. Based on the class name which is stored into the CVG format, the class can be reconstructed. The nice thing is that you can easily save your own canvas objects into the CVG format also. Two member functions to read and write the CVG format for a derived canvas object, is all that is needed. When another wxArt2D based program does not know the object you have written, it will skip it when reading it.

=== SVG IO Module ===
Basic Scalable Vector Graphics In and Output. Its understands all basic primitives in SVG and hierarchy, but the fancy stuff like animation etc. not. When reading SVG, it is translated/ mapped into a2dCanvasDocument.

When writing as SVG, all objects stored into the a2dCanvasDocument are mapped to most advanced SVG drawing possible. A a2dCanvasDocument is meant for many drawing application, and not just for viewing SVG. The idea is that a2dCanvasObject derived complex objects can also be saved and loaded. But in case of saving as SVG, this will result in a simple drawing, and the original object can never be reconstructed. For that we have the CVG format.

=== GDSIO Module ===
GdsII format In and Output. This is a Computer Aided Design format for the chip industry. It is layers based, and contains hierarchy in so called structures. Structures are like sub-drawings, which can be referenced at any position on a higher level. This a key feature in wxArt2D, it knows how to deal with multiple references to one drawing. Automatic updating, and bounding box calculation is all based on this principle. Not many canvas libraries can do this.

=== KeyIO Module ===
KeyIO format In and Output. Which is an ascii readable representation of GDSII, plus extra objects like circles. Also the object can have properties added to them. See also GDSIO Module.

== Scripting ==
On top of all this is the LuaWrapsModule, which implements scripting based on wxLua using wxArt2D's functionality.

=== LuaWraps Module ===
This module uses all other modules and wraps its functionality into wxLua bindings. That way you can write programs in wxLua that are using wxArt2D. But more often you will like to use the scripting to automate things in your own C++ application. This all becomes easy with this module, you can also easily extend the bindings with your own application functionality. A typical use is to startup your application by reading a configuration file written in lua. This gives the user of your application an enormous amount of flexibility. WxArt2D does even have objects which can be placed in a canvas document, but which are drawn/created using a lua script. For more see LuaWraps.

----
 . CategoryModules

Packages and Modules Overview

The wxArt2D code is split in two packages, wxdocview and wxart2d. These packages each containing several modules. The modules are organized as a hierarchy, with higher level modules depending on the lower level ones. For the whole framework, wxart2d depends on wxdocview, to have applications with multiple drawing, organized as documents, containing those drawings. It is also possible to build the wxart2d, without using the wxdocview framework. That will gives you mainly a canvas with drawing inside, and tools to work on the drawing.

A module contains mainly files that form together a certain functionality. Modules do depend upon each other, and a certain hierarchy is in them. The hierarchy is not strict, sometimes in modules other modules are used but when wanted they can be switched on or off. Special attention is paid to be able to remove higher order modules, without problem. So the docview module can be used without the canvas module. But also lower order modules like xmlparse are optional for the docview module. Each module compiles and links to a library. Whereas, some of the modules require third party libraries, the basic wxArt2D modules requires only the wxWidgets library.

Package wxDocView

This is the base package. It can be used without the wxart2d package. It consists of three modules.

Modules

At the very bottom, the GeneralModule providing basic functionalities, e.g. smart pointers and properties and event handling. The optional XmlParseModule is needed for XML IO. The DocviewModule defines the document view framework.

General Module

The module general is used by all modules. It contains classes etc. that can be used in all other modules. a2dObject and its derived property classes are in this module. Another one is a2dSmrtPtr, which is a smart pointer template class. It works for classes with a Release and Own mechanism, which are all a2dObject derived classes. See GeneralModule for more.

XmlParse Module

This module contains the code for the Pullparser, it uses expat for parsing the xml from a file or string. XML Pull parsing is ideal for parsing XML data from a file, especially where the reading of this data is distributed through all classes in other modules, and those classes are deciding what needs to be read from the file. This is different from a parser that reads all XML data at once into a DOM tree. Next to reading XML data, this module also supports classes to easily write XML data to a file, and again in such a manner that the writing of the data is distributed through all classes in other modules. The CVG format uses this module for saving a a2dCanvasDocument to a file and/or load it from a file. a2dIOHandlerXmlSerOut is the class used for that, and it is a general class for serializing class data.

Docview Module

The docview module contains the classes for the docview framework. It makes it easy to implement applications that open several documents, and display the data in the documents in one or more windows using views. The editor module depends on it. See DocviewModule for more.

Package wxArt2D

This package requires the package wxdocview. Its many modules can be grouped in

  • Drawer modules
  • Canvas and editor modules
  • IO modules
  • Scripting modules

Drawer Modules

The ArtbaseModule is the base for drawing context classes, it depends only upon the GeneralModule. The ArtbaseModule has all definitions for styles like stroke, fill and fonts. AggDrawerModule and GdiPlusDrawerModule use those classes for implementation of extra drawing context classes.

ArtBase Module

This module contains basic geometric classes, and the abstract a2dDrawer2D class, classes derived from this are drawing context classes. The drawing context is able to draw relative to a matrix that is set to the drawing context first. The drawing contexts classes can be used standalone for wxWidgets, and do not depend on the rest of wxArt2D. That is, it uses the general module, and the xmlparse module is used inside the style classes, but it can be switched off. There is one drawing context in this module which uses wxDc and wxMemoryDc to do normal wxWidgets like drawing. The modules aggdrawer and gdiplusdrawer, use this module to implement a drawing context which can do antialiased drawing.

AggDrawer Module

Drawing context for a2dCanvasDoucment, based on the AntiGrain rendering Library, http://www.antigrain.com/. With the current version (which is included with wxArt2D), one can already do anti-aliased rendering and editing.

This module defines drawing context classes for anti aliased double buffer drawing. It only depends on the general and artbase modules. The module is an implementation of the a2dDrawer2D class, and does not depend on the canvas module. So used for drawing only, but in combination with the canvas module, can be used to render a2dCanvas its a2dDrawing.

GdiPlusDrawer Module

Gdi+ (part of WinXP and newer) is used to do the actual drawing. This module defines drawing context classes for anti aliased double buffer drawing. It only depends on the general and artbase module. The module is an implementation of the wxDrawer2D class, and doesn't depend on the canvas module. So use for drawing, but in combination with the canvas module, can be used to render canvas documents.

Canvas and Editor Modules

The CanvasModule is on top of the GeneralModule and the ArtbaseModule. The EditorModule is an extension to the document framework designed for containing drawings in documents. The CanExtObjModule is an extension on the CanvasModule, mainly for more advanced graphical objects and IO. The CanvasModule also adds editing functionality to canvas drawing. It defines tools to interactively edit canvas objects. The CurveModule defines very advanced canvas objects, to display sets of curves and plots, which can be edited.

The CurveModule is on top of the CanvasModule, and so is CanExtObjModule. Both implement complicated non basic a2dCanvasObjects. It is the best to combine higher order a2dCanvasObjects together with its tools to draw/ manipulate them.

Canvas Module

The canvas module builds on top of the general module and th ArtbaseModule, creating a library for 2D drawing applications. A a2dDrawing does contain a hierarchy of drawing objects a2dCanvasObject, which can be displayed on a a2dCanvas. The a2dCanvas uses internally a a2dDrawingPart, which on its turn uses a2dDrawer2D as drawing context to do the actual drawing of the objects in the a2dDrawing. One can inject a a2dToolController into a a2dDrawingPart, which gives you a large set of interactive drawing tools, to edit the drawing that is displayed on the canvas window. Those tools issue commands to the a2dCanvasCommandProcessor, and that make the editing undo-able.

See CanvasModule for more.

CanExtObj Module

This module defines canvas objects which are more advanced, and not used for any application. The idea is not to make the canvas module to big, and instead add extra fancy a2dCanvasObject derived objects here. Currently there are several object to make references on a canvas towards other canvas documents a2dCanvasDocumentReference. Like an overview of document which are open. Also those can be used to make documents which contain libraries of complex objects, a2dLibraryReference Also interesting is a2dCanvasDocumentIOHandlerImageIn, which allows you to save what is in a document to image files. You can define the size of the image, and automatically the document will be rendered into the image and saved into the format you choose.

Editor Module

The editor module extends the basic DocviewModule, to contain a2dCanvasDocuments. And since a a2dCanvasDocument can contain several a2dDrawing's, the CanvasModule is used to edit those drawing again. A specialized editor frame and a command processor do extend the canvas command processor for working with multiple documents. a2dEditorFrame is the spill, together with a lot of dialog classes which are called from it, but not directly. Instead all is going via the a2dCentralEditorCommandProcessor. That way wxArt2D can record actions to a script. Most dialogs are more are less standalone, and work on the context and contents of the current active view. See EditorModule for more.

Curve Module

Special objects for drawing multiple curves or bars etc. on a plot object. It can have markers attached to curves, and show-marker objects to display and edit the position of the markers on the curve.

This module gets the maximum from the wxArt2D library. It uses dependencies between curve objects and its marker object, in order to keep them in sync while editing the curve or marker. It also uses sub-editing, therefore in a plot of curves, one can edit each curve and the markers on the curve. First one starts editing the plot itself, but the plot object pushes other tools when clicking on the objects contained within the plot. Events in a2dCanvasObjects are organized such, that events travel through a hierarchy of nested a2dCanvasObjects. This makes the sub-editing of objects possible.

IO Modules

CVGIO, SVGIOModule, GDSIOModule and KeyIOModule are all implementing a specific way to save and load documents as defined in the EditorModule. The modules svgio and gdsio are using the editor module. But the editor module can do without them, so this is the way to add extra IO formats. The classes parse a file and translate the contents to a a2dCanvasDocument containing the drawing in the form of a2dCanvasOjects. They can also write the a2dCanvasDocument back to a file, by traversing the document from the outside, and translating the contents of the document back to a the file format. The idea is to add more formats without extending the canvas module.

CVG IO

This is not a real module, but a built in option. It allows you to save a a2dCanvasDocument and/or a2dDrawing into a file and read it back. The format is XML based, and saves a hierarchical a2dCanvasDocument into a file. This format uses the wxWidgets dynamic class information, to store a class and its lower level children to a file, and later read them back. Based on the class name which is stored into the CVG format, the class can be reconstructed. The nice thing is that you can easily save your own canvas objects into the CVG format also. Two member functions to read and write the CVG format for a derived canvas object, is all that is needed. When another wxArt2D based program does not know the object you have written, it will skip it when reading it.

SVG IO Module

Basic Scalable Vector Graphics In and Output. Its understands all basic primitives in SVG and hierarchy, but the fancy stuff like animation etc. not. When reading SVG, it is translated/ mapped into a2dCanvasDocument.

When writing as SVG, all objects stored into the a2dCanvasDocument are mapped to most advanced SVG drawing possible. A a2dCanvasDocument is meant for many drawing application, and not just for viewing SVG. The idea is that a2dCanvasObject derived complex objects can also be saved and loaded. But in case of saving as SVG, this will result in a simple drawing, and the original object can never be reconstructed. For that we have the CVG format.

GDSIO Module

GdsII format In and Output. This is a Computer Aided Design format for the chip industry. It is layers based, and contains hierarchy in so called structures. Structures are like sub-drawings, which can be referenced at any position on a higher level. This a key feature in wxArt2D, it knows how to deal with multiple references to one drawing. Automatic updating, and bounding box calculation is all based on this principle. Not many canvas libraries can do this.

KeyIO Module

KeyIO format In and Output. Which is an ascii readable representation of GDSII, plus extra objects like circles. Also the object can have properties added to them. See also GDSIO Module.

Scripting

On top of all this is the LuaWrapsModule, which implements scripting based on wxLua using wxArt2D's functionality.

LuaWraps Module

This module uses all other modules and wraps its functionality into wxLua bindings. That way you can write programs in wxLua that are using wxArt2D. But more often you will like to use the scripting to automate things in your own C++ application. This all becomes easy with this module, you can also easily extend the bindings with your own application functionality. A typical use is to startup your application by reading a configuration file written in lua. This gives the user of your application an enormous amount of flexibility. WxArt2D does even have objects which can be placed in a canvas document, but which are drawn/created using a lua script. For more see LuaWraps.


wxArt2D: WxArt2dModules (last edited 2016-05-12 13:59:07 by inetproxy-p)