[PythonCAD] other notes about development

[Art Haas]

On Fri, Jun 17, 2005 at 05:06:28PM -0700, Eric Wilhelm wrote:
> # The following was supposedly scribed by
> # Art Haas
> # on Friday 17 June 2005 01:40 pm:
> 
> >However, I
> >think the development model that I'd set up for PythonCAD needs
> >reassessment. When I started PythonCAD three years ago I'd hoped that,
> >by this time, there would be an active community of developers
> >contributing to the project. That has not been the case. Part of the
> >problem I believe is that the master repository was not publicly
> >accessible, like it is for GNOME, KDE, Apache, BSD, etc., and that
> >people wanting to contribute would have to send the patches to me.
> 
> IMO, this is not that much of a barrier.  Any project needs some sort of 
> gatekeeping and I think that svn makes generating patches easy enough.

I set things up initially as they were because I wanted to shepherd the
beginning of the project in the direction I believed it should go. If
I'd set up a repo at SourceForge and said "Hack away and commit what you
want" then who knows what may have appeared in the repo, if anything
at all. The lack of direct access to the repository may be an impediment
to some potential developers.

> >Also, a CAD package is a specialized software program that many
> >developers would not use in their daily lives, so drawing these people
> >in to work on a program that they would rarely use requires a bit of
> >luck in finding the people willing to do this.
> 
> My bet is that this is reason #1 for the lack of products and 
> development in open-source CAD in general.  After all, I'm only a 
> software developer because I was too disgusted with the existing tools 
> to tolerate a career of using them as an engineer.

I've hoped that people sharing your view above - the existing tools are
not adequate or nonexistant - would find PythonCAD and want to
contribute. I know that there is a demand for CAD software on Linux and
the BSD varieties, and that a good CAD package would fill a missing niche 
in the current software offerings. Making the CAD package open-source
means it could run on platforms that commericial packages would not
consider. Closed-source CAD would probably not run on older releases of
Fedora/RedHat, Suse, Mandrake/Mandrive, etc, or on PPC/Alpha/Sparc
chips, and probably not on older BSD releases either.

> >There are certainly 
> > other reasons that can explain why a regular development team has not
> > appeared, and I want that to change.
> 
> Better to pursue these than fix a not-really-broken version-control 
> system.  I'd let git simmer for a while if what you're really trying to 
> do is get more developers involved.  The effort would be better 
> invested in things like:
> 
> partitioning the problem
>   (too many cooks don't fit in one bowl of soup)
>   This is big architectural step-back and chin-scratch type of stuff.

The lack of cooks is something I want to change. :-)

> write a HACKING howto
>   I've had a lot of things that I would like to fix in KDE, but would 
> need to spend the better part of a few days figuring out how to 
> checkout and setup a development copy of it without screwing up my 
> production environment (might even take that long _with_ a HACKING 
> howto!)

This could certainly be done.
 
> smile floormats
>   I've said it before.  Maybe we're close enough to loading dxf's at 
> this point anyway that you could just go for it?  The big deal with 
> dxf->rhizopod for the uber-converter is that dxf/dwg is stupid (when 
> you get to digging around in the object model) and rhizopod (if I can 
> at all help it) won't be.
> 
> geometric functions
>   Offset?
> Interface work
>   Yeah :-(  It's the last thing to go on, but it's the first thing we 
> look at.  That goes a long way toward deciding whether you want to get 
> involved in the project.
> 
> Just in case:  don't get offended.  (I seem to be having some troubles 
> with that today.)  Let's all rant about pythoncad a little and then see 
> what we learn from that.
> 
> I for one don't use pythoncad on a regular basis.  Maybe a lack of 
> patience with Python, maybe it's the lack of wheel-mouse/mb-pan.  If 
> you'll promise not to cry (like I said, I've had troubles with that 
> today :-), I'll take a hard look at it and write you a laundry-list of 
> complaints.

The program still lacks numerous features that make using it on a daily
basis not feasible. Hatching, for one, is essential in any cad package,
and PythonCAD doesn't offer this necessary feature. The lack of a
spline-type entity is also a shortcoming, and I am certain that other
people have various entities they use in CAD software that PythonCAD
currently lacks.

I'm all for hearing some rants about PythonCAD and its shortcomings. My
skin is pretty thick, and I have no doubt that the program is lacking in
numerous areas. To get things started, here are a few problems that
irritate me ...

1) No hatching, ellipse, spline/nurbs entities. The lack of these
entities make drawing curved objects really difficult.
2) No import/export abilities. DWG/DXF in particular.
3) No ability to easily create, save, and load user-defined linetypes
and styles. These things could be done by hacking on the code, but that
is not realistic for most uses.
4) Drawing behavior - by this I mean the GTK calls to draw in the
DrawingArea. All entities are redrawn far too often, drawing dimensions
leaves ghosted or hidden lines, zooming only done with menu choices,
no keyboard abilities to pan left, right, up, down.
5) Limited documentation for the various entities and no tutorial for
users wanting to try the program for the first time.

I've been working on problem #4 above. My approach to solving many of
these problems is to utilize the 'ImageView' class in 'gtkshell.py'.
The goal would be to replace the DrawingArea instance in 'gtkimage.py'
with an ImageView instance. The ImageView would utilize the messaging
abilities of the various entities and erase and redraw the entities
as needed. Adding a new entity to a drawing would no longer redraw
everything, and removing an entity would be done by redrawing it
but in the background color, again a single draw operation. The
ImageView would also respond to arrow key press events, and with
a little more cleverness, mouse wheel events. Unfortunately things have
been moving very slowly lately, so the current code still uses the
existing routines.

Rant away ...

Art
-- 
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822