PythonCAD One Year Report
PythonCAD was first publicly released on December 21, 2002, and after one
year of development it is worthwhile to reflect on the status of the
development efforts of the past year. The capabilities of the program have
grown by leaps and bounds when comparing the eleventh release to the initial
one. There are still some obvious shortcomings in the program, too. The
saying Rome was not built in a day
certainly applies here.
The comments below are a small collection of my thoughts after working
on the program this year, and what I want to accomplish as development
continues onward. Summarizing the highlights of the year in both good
points and bad points seems a reasonable way to present my thoughts, so
without further ado, here is how things looked as of December 30, 2004.
Good Points
Here is a summary of the things that I believe have gone well over the
first year of PythonCAD development:
-
The program has been well received, and I have received encouragement from
people all over the world. My thanks to everyone.
-
In addition to encouragement, a number of people have contributed patches
and improvements to the code. In fact, a small development group seems
to be building around PythonCAD. The fact that someone is willing to pitch
in and help with the program is a great development, and to have several
people doing this is even better. Again, my thanks to everyone who has
contributed!
-
The fact that the development of PythonCAD is continuing is something
I am pleased with. Any software project, and open-source projects in
particular, run the risk of development becoming stalled. When I started
working on this program, I knew that there would be times during the
development when things will not work right, and frustration caused
by these delays will mount. Also, the fear of becoming burned out had
crossed my mind. Fortunately, when work in one area of the code bogged
down (i.e. hatching), there are other areas code where development efforts
were resumed. As for becoming burned out, I am happy to say that has not
happened, and does not look like it will appear any time soon.
-
The drawing abilities of PythonCAD after one year of development is something
I am very pleased with. The improvements in dimensioning, the addition
of various drawing entities like leader lines, and the overall stability
and capabilities of the program are definitely good accomplishments over
this year. The choice of using Python as the development language has
made reaching this point much simpler and easier than would have been
possible if the program had been written in C or C++. It is so nice to
just write the code and run it without the intermediate steps of compiling
and linking. Also, not having to step through core dumps with a debugger is
another development chore I am happy to avoid. Once again I compliment
the Python developers for their efforts.
-
Although not yet entirely functional, the ability of PythonCAD to handle
DXF and DWG files is an example of some well spent development time and
effort. These two formats are so common that the ability to import files
in either format is essential in getting people to try to use PythonCAD
at some point. In particular the ability to read DWG files directly without
relying on external libraries is something I am very pleased with as importing
this format is something I did not think would be possible without massive
efforts figuring out the layout of these binary files. My thanks to the
OpenDWG people for doing just
this and publishing their work.
-
The use of Subversion for storing
the code has been an overall plus. There have been a few snags along the way,
especially when the site moved from one machine to another, but the use of
subversion itself has been basically trouble free. The repository access at
the website seems to work (mostly) without problems.
Bad Points
One cannot have good points without a few bad ones as well. Here are a few
things that I think did not go so well this year. The bugs or design defects
in the code will hopefully be removed shortly.
-
The lack of hatching and printing in the program are two critical shortcomings
that still make PythonCAD unsuitable for real drafting work. I knew that
hatching would be a challenge to implement, and it has show itself to be
a much more complex problem than I had imagined. Printing support will also
be difficult, but I am still hopeful that adding this missing feature will
be easier than hatching has proven to be.
-
The lack of a GNOME or KDE front ends for PythonCAD has been a disappointment.
Creating non-GTK front ends for PythonCAD will expose design shortcomings
in the core code, as well as provide PythonCAD to new users in their
preferred UI, be it GNOME, KDE, or some other choice. The development
of a GNOME front end may be starting now, but I have not seen nor heard of
a KDE front end, nor one in any other style like wxPython. Hopefully this
situation will improve as development continues.
-
There are numerous shortcomings in the interface of the program as of the
eleventh release. Some of these problems are just bugs in the code or
problems due to incorrectly handling GTK requirements. An example of this
is seen when creating a linear, horizontal, or vertical dimension. When
clicking on the first point, a line is drawn from that point to the current
location of the mouse until the second point is selected. When the second
point is selected by a mouse click, the line is still displayed, which
is at the very least confusing, and it can overlap the entity being
dimensioned, which is more annoying. Another interface problem is found
in the preference dialog box improperly redrawing itself. Bugs like
these two will be eliminated eventually, but their prescence in the
program for several releases is frustrating.
-
There are various speed issues in the program I would like to have had
resolved. The speed of calculating entity intersections is too slow.
Possibly the root of this problem is due to using a language like Python
instead of compiled code like C, but I am certain that there are many
places in the code where a better algorithm can be implemented, or better
Python code can be written which will speed things up. Another slow code
example is in drawing circular objects. Again, this may be a Python
issue, but then I would expect similar behavior when drawing other
entities like lines.
-
The lack of undo/redo support in the program is another shortcoming
that is irksome. While not as much of a drawback as lack of printing,
not being able to painlessly revert an unwanted change is something the
program should do.
-
The web site is rather
texty
and could use some sprucing up.
While not affecting the code one iota, it would be nice to have a fancier
website.
Onward And Upward
So with one year of development completed, where does PythonCAD go from
here? Here are a few goals for the coming year:
-
Add in printing and hatching.
-
Add in undo/redo.
-
Interface improvements: Speed up drawing, erase
ghost
lines;
refine the preferences dialog; improve layout of drawing window.
-
Add in code to modify existing attributes, especially dimensions. In many
cases the low-level code is present, but there is no interface code written
to do the changes. Using dimensions as an example, the code to do things like
add or hide a second dimension, increase or decrease the dimension precision,
and change the dimension markers all exist, but there is no way to do these
things through the current menu choices.
-
Improve the command line functionality within PythonCAD. The current
implementation is primitive but functional. A better implementation will
be one that provides a complete Python environment accessible from the
entry box as if python was invoked from a command line.
-
Improve the storage and access methods of the entities in a drawing. The
current implementation stores many of the entities in lists, and while this
approach has worked to some extent, its shortcomings are more evident as
the number of entities in a drawing increases. A better approach will be
to use data structure designed to store geometric entities. The new
storage should also provide faster access to the entities, as well as be
flexible enough when adding new entities to PythonCAD.
-
Python code improvements in both code cleanliness and Python idioms. The
Python language itself has been slowly changing, with improvements to
the core Python syntax and libraries making their appearance with each
new release. There have also be various deprecations in Python, such as
the use of the apply() function. The xrange() function in Python seems
to be heading out, so the removal of this function will begin shortly.
Also, there are various places in the code where the code is written
in idioms that can be better expressed, so cleaning up these warts is
an ongoing process.
-
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. It would be great to have all of these
goals met by December, 2004, as well as some of the other design ideas
given elsewhere on
the website. Hopefully the 2004 year in review page will list these
goals as being met, and the new challenges that arise this coming year
will be the starting points for development over the following year.