[PythonCAD] other notes about development

[Stuart Brorson]

> > I must somehow agree here.  I remember looking at the code more
> > closely a while ago.  Initially I applauded the separation.  But then
> > I discovered that the core/engine/whatever was too much linked with
> > the GUI.  Specifically I remember the menu layout being specified in
> > the GUI-independent part, this did really put me off.  I was hoping to
> > find a much more generic core/engine where one can then build several
> > UI's on.  For example, why should it not be possible to build two GTK
> > GUI's that look different?
>  
> The initial menu code was in the 'Generic' code, but that is no longer
> true. When I first started working on PythonCAD I thought that was the
> way things should be done, so the interface would use the 'menus.py'
> file and build a menu/toolbar/something from that file. That approach
> has since been abandoned, and all the menu code is now done in the
> 'gtkmenus.py' file. The 'menus.py' file is still around but is not used.
> I need to 'svn delete' it ...

Hi Art and company,

This has been an interesting thread.  I also am kind of confused about
how the GUI part of the code relates to the GUI-independent back end.
Art has graceously and helpfully tried to explain it in e-mails, and
that has been useful.  However, I wonder if it would help prospective
developers to have some kind of UML drawing showing how the GUI stuff
is supposed to relate -- and communicate -- with the non-GUI stuff. 

Some time ago I made a quick class drawing of PythonCAD in pseudo-UML
& contributed it to the project.  It is kind of limited, but I found
the exercise useful.  However, that is only a small step.  Since then
I have thought that another diagram showing how a representative
drawing is made up would be a good thing.  The drawing would show how
the different graphic objects were related to or point to each other.
That is, take a drawing of a segment, a circle, and perhaps a
dimension, and show how each object is instantiated, in which object
list it lives, etc.

Another useful UML-type drawing would be a protocol/communication
drawing showing how the GUI stuff is supposed to communicate to the
non-GUI stuff in response to various user commands (e.g. place a
segment, move a segment, erase a segment, undo/redo an operation,
etc.).   

Just some thoughts.  I may look at making one or more of these
drawings at some point, but my day job & other activities prohibit me
from getting too involved right now.  :-(

Stuart