[PythonCAD] other notes about development

Rafael Villar Burke pachi at mmn-arquitectos.com
Mon Jun 20 13:03:32 CEST 2005


Art Haas wrote:

>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 also don't think having commit access to a repository is so important. 
Subversion is quite easy to use and install in a lot of platforms, and 
while a distributed model would make much easier having local branches 
to hack on, there isn't still (IMHO) a good enough replacement to be 
used in PythonCAD. Furthermore, using git comes with the drawback of not 
being able to contribute if you work on win32, and, I'd dare to say that 
most people working on professional CAD are tied to the win32 platform 
(exceptions are numerically irrelevant, AFAICT). This will be a big 
point for the adoption of PythonCAD and make the switch, and loosing so 
many potential contributors now would be a big error, IMHO.

If it is of any help, I've been tracking the development some SCM 
systems, and I look with great curiosity and hope the ongoing work on 
Mercurial (http://www.selenic.com/mercurial/) and Bazaar-NG 
(http://bazaar-ng.org/). Both are written in python, are easy to use, 
don't have complicated dependencies (bazaar-ng only requires python) and 
are being heavily developed. The sad part is that, despite they are 
self-hosting and usable, they are still not mature to be used in 
production work AFAICT...

>>>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.
>  
>
A lot of people would like to make the switch to a free and powerful CAD 
tool, but take into consideration that besides changing aplications, in 
most cases it's also a change in platform. Most people to whom I have 
shown PythonCAD really appreciate being able to test it on Windows, even 
when installing pythoncad, through gtk+, pygtk and python is not as easy 
as any other windows app. Besides the installation burden, I think 
having a closs platform app is a killer feature for PythonCAD, as well 
as being written in python (easy to hack, no compiles...).

>>>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. :-)
>  
>
I believe that having some more short term goals and concentrate on 
users, not only on developers could be beneficial to have some more 
exposure an attract new developers too. QCad did concentrate on being 
usable to make furniture drawings, or basic geometrical shapes, etc and 
that's why I think there are some free electronic cad programs around 
with relative success. Users would bring some more feedback and more 
rewarding short term goals (I admire you for being able and have the 
will to keep it going, really!).

Another point I humbly think makes difficult to grow a community of 
developers is that some architectural decisions such as the generic UI 
layer, which were made to have some more flexibility in the future, make 
current development too complex and burdensome. The current situation 
makes difficult to take advantage of the underlaying toolkit 
capabilities and to attract developers that are proficient in a specific 
toolkit.

 I'd rather go for a gtk+ interface and avoid having to learn another 
GUI model and its API, as I hope the ongoing Cairo integration can get 
us the benefit of easy printing, an usable canvas, so much needed for 
graphical apps such as PyhtonCAD.

>  
>
>>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.
>  
>
Apart from this good idea, I'd add having a visible TODO list. A list of 
tasks of varying difficulty, size, and nature (documentation, webdesign, 
coding, advocacy...). A list of tasks makes easy to contribute, as you 
don't need to know what's going on to be able to help, and you can see 
if there are some tasks that suit your time and knowledge. I've had the 
experience of seeing how little but interesting tasks were being made by 
casual developers that spent a couple of hours hacking on a project 
(gazpacho) because it was easy to do it thanks to an appealing TODO list.

> 
>  
>
>>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.
>  
>
I don't think these are _really_ so important. PythonCAD is not suited 
now (and won't be in a while) to do high precision jobs... and any of 
these can be done using arcs and lines with reasonable good results. 
Well, maybe I'm too biased towards construction, architecture and 
engineering drawing...

>2) No import/export abilities. DWG/DXF in particular.
>  
>
This is really important... if you have a good exporter you can overcome 
the app's shortcomings using other apps to do the work.

>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.
>  
>
A dashed line, a dash-dot line for axes, and a continuous line should be 
enough for basic usage.

>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.
>  
>
More GUI and usability work would be great... making some things but 
doing them really well is the basis for further steps, IMHO. Maybe we 
are stuck now waiting for easier solutions to come with cairo 
integration into gtk+ (I can't see the time where gtk+ gets a first 
class retained mode drawing widget!), so perhaps this work will be 
easier later on...

>5) Limited documentation for the various entities and no tutorial for
>users wanting to try the program for the first time.
>  
>
This has the benefit of realizing what parts are missing, as you have to 
take the position of a user who wants to achieve concrete tasks.

>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.
>  
>
A great thing of your release planning is always going forward and 
concentrate on specific tasks, instead of continuously aiming at 
perfection and running in circles... :)

>Rant away ...
>  
>
After all... you're doing an incredibly good job, and I can't express 
how bad I feel not being able to be more helpful. I've even tried to get 
some institution and some people to work on PythonCAD development, but 
I've seen that there's a vicious circle here... if it's not usable no 
one uses it, so no feedback, and no external development happens...

>Art
>  
>
Thanks for your work and your perseverance.

--
Rafael Villar Burke


More information about the PythonCAD mailing list