PythonCAD Year Two Report
PythonCAD was first publicly released on December 21, 2002, and after one
year of development a summary of the developments
over that time was written. Now that another year has gone by, it is time
to reflect on the changes made during the second year of PythonCAD development.
As was true in the summary regarding the first year of work, the
ramblings below try to mention the good and bad points encountered
while working on PythonCAD. Overall, the development efforts during the
second year addressed numerous program shortcomings that existed after
the first year of work was completed, and in many ways the program is
becoming more and more capable as a usable drafting package. There is
certainly still much work to do, and with some time and effort the work
over coming year will make PythonCAD even more powerful. So, here is
how I see things on January 14, 2005.
Good Points
The list below contains a few of the high points from working on PythonCAD
during the course of 2004.
-
Numerous shortcomings identified after the first year of development were
addressed. PythonCAD has a robust undo/redo mechanism, the first implementation
of printing was added, the storage of entities within a drawing has been
greatly improved, and many, many design and code deficiencies were addressed.
-
The messaging framework added in the beginning of the year has proved to
be an extremely powerful framework for program development. This approach
has improved the design of the program by defining the mechanism that
entities within a drawing can communicate with each other. The messaging
system will be utilized a great deal more in the user interface code as
improvements to the front-end of the program are made.
-
I am still enthusiastic on working on PythonCAD. I basically said the same
thing last year, and once again I am pleased to say that burnout has not
happened. In some ways the last year of development was easier than the
first, in that there was some code to work with, and that the strengths
and weaknesses of the existing codebase could be examined.
-
PythonCAD is still usable on older machines, and runs on numerous released
versions of Python and PyGTK. Once again I can thank the developer team
of Python, and also the people working
on PyGTK for their work over the last
several years. The hardware requirements of many software packages tends
to increase as newer, better machinery is available, but too often the
latest version of some program becomes more and more
demanding
on
older machines if it even runs acceptability at all, and the Python and
PyGTK teams have done an outstanding job at avoiding this common pitfall
while continually improving their programs.
-
PythonCAD is turning up in more distributions. For a program still in
early development it is nice to see the program being added into various
distributions. I hope this trend continues, as well as making PythonCAD
available in port trees of the various BSD flavors.
-
The introduction of a PyObjC/Cocoa based front end in PythonCAD demonstrated
that the design and layout of the program made it possible for front-ends other
than PyGTK to be developed. As the work on PythonCAD began, the ability
for various front ends to be developed was a goal, and, for a few months
at least, the Cocoa front-end demonstrated that this goal had been met.
Bad Points
Here are a few thoughts on some of the lowlights of last year. They are
not presented in any specific order ...
-
Watching the Cocoa front-end become unusable due to internal changes in
the code. The internal changes were necessary to keep PythonCAD modules
from the standard Python module search paths, but a consequence of the
file moving was the breaking of the Cocoa code. I do not have a machine
running Cocoa so I am unable to maintain the code myself, and the developer
that contributed the code initially now does not have the time to
maintain it. Possibly a PyObjC developer will step up and offer to take
this code and make it work.
-
The lack of hatching in the program is a critical shortcoming that still
makes PythonCAD unsuitable for real drafting work. Last year, the lack of
printing also held PythonCAD back, but that problem has been addressed to
some degree now that the first implementation of printing has been added.
Hatching, however, has not advanced at all over the last year. One of the
goals over the next year is to try and rectify this problem.
-
The lack of a GNOME or KDE front ends for PythonCAD has been a disappointment.
Yes, I said the same thing last year. I still would like to see front-ends
using Python bindings for either environment, with the best result being
developers creating front-ends for both. The addition of the Cocoa front
end exposed some design flaws in the core PythonCAD code, and once seen
these flaws were rectified. Another benefit for creating front-ends for
these desktop environments would be the demonstration of the power of the
Python bindings for these interfaces. Maybe this coming year will be when
PyQT, PyKDE, and/or PyGNOME developers take PythonCAD to their liking and
start working their magic.
-
Numerous interface issues noted in the first year summary still exist.
Nearly all the development efforts over the last year have been dealing
with the back-end code, so the lack of progress on the interface is not
surprising. A goal for the development efforts over the next year is
to improve the interface, both the code to create the interface as well
as the behavior of the interface itself. Hopefully the various redraw
bugs that are still seen will be eradicated, as well as an overall
improvement of the user interface to make using the program more intuitive.
-
Code documentation is at best weak, and at worst non-existent. This needs
to change.
-
The web site is rather
texty
and could use some sprucing up.
While not affecting the code one bit, it would be nice to have a fancier
website. This is as true at the end of 2004 as it was at the end of 2003.
Onward And Upward
So with two years of development completed, where does PythonCAD go from
here? Here are a few goals for the coming year. Some are holdovers from
last year, and some are new
-
Adding hatching support.
-
Code improvements to utilize features found in newer Python and PyGTK
releases, while keeping support for older releases. The base requirements
of PythonCAD are still Python-2.2 and PyGTK-2.0, and the plan is to keep
these minimum versions for the coming year.
-
Interface improvements: Speed up drawing, erase
ghost
lines, utilize
the messaging system for drawing and redrawing operations, etc ...
-
Command line improvements ...
-
Last but not least, the usual assortment of bug fixes and code improvements.
These lists are not necessarily complete, especially what is given for
the goals over the coming year. When the end of 2005 comes, another
summary like this may appear, and it would be nice to say that all the
goals for development over the year have been met. Time will tell if
that is the case.