From CSomerlot at Brwncald.com Tue Feb 3 11:23:41 2004 From: CSomerlot at Brwncald.com (Somerlot, Chris) Date: Tue Feb 3 11:24:17 2004 Subject: [PythonCAD] GTK installation path Message-ID: I'm having trouble getting pythonCAD to start in Windows because it can't find a GTK library (new installation). pyGTK is in the python directory (/lib/site-packages), and the installation of GTK put it somewhere in the Program Files directory. Has anyone had this problem? I think I need to either install GTK in a different directory or put in a PATH variable? Chris From CSomerlot at Brwncald.com Wed Feb 4 16:36:33 2004 From: CSomerlot at Brwncald.com (Somerlot, Chris) Date: Wed Feb 4 16:43:30 2004 Subject: FW: [PythonCAD] GTK installation path Message-ID: I figured it out, I just had to edit gtkpycad.py as such: import getopt import sys if sys.platform == 'win32': gtkdir = 'C:/Program Files/Common Files/GTK/2.0' import os os.environ['PATH'] += ";%s/lib;%s/bin" % (gtkdir, gtkdir) else: import os import gtk ... > -----Original Message----- > From: Somerlot, Chris > Sent: Tuesday, February 03, 2004 11:24 AM > To: Pythoncad > Subject: [PythonCAD] GTK installation path > > > I'm having trouble getting pythonCAD to start in Windows > because it can't find a GTK library (new installation). pyGTK > is in the python directory (/lib/site-packages), and the > installation of GTK put it somewhere in the Program Files > directory. Has anyone had this problem? I think I need to > either install GTK in a different directory or put in a PATH variable? > > Chris > > _______________________________________________ > PythonCAD mailing list > PythonCAD@python.org http://mail.python.org/mailman/listinfo/pythoncad > From gossner at arcom.com.au Wed Feb 4 22:34:34 2004 From: gossner at arcom.com.au (Peter Gossner) Date: Wed Feb 4 22:30:14 2004 Subject: [PythonCAD] GTK installation path In-Reply-To: References: Message-ID: <20040205140434.1f56155c.gossner@arcom.com.au> Hey congrats, Not having Windows I could not check. Would the same path apply across the various flavours of 'doze. (i.e 98 - XP ) ? --Pete On Wed, 4 Feb 2004 13:36:33 -0800 "Somerlot, Chris" wrote: >I figured it out, I just had to edit gtkpycad.py as such: > >import getopt >import sys >if sys.platform == 'win32': > gtkdir = 'C:/Program Files/Common Files/GTK/2.0' > import os > os.environ['PATH'] += ";%s/lib;%s/bin" % (gtkdir, gtkdir) >else: > import os >import gtk >... > >> -----Original Message----- >> From: Somerlot, Chris >> Sent: Tuesday, February 03, 2004 11:24 AM >> To: Pythoncad >> Subject: [PythonCAD] GTK installation path >> >> >> I'm having trouble getting pythonCAD to start in Windows >> because it can't find a GTK library (new installation). pyGTK >> is in the python directory (/lib/site-packages), and the >> installation of GTK put it somewhere in the Program Files >> directory. Has anyone had this problem? I think I need to >> either install GTK in a different directory or put in a PATH >variable?> >> Chris >> >> _______________________________________________ >> PythonCAD mailing list >> PythonCAD@python.org >http://mail.python.org/mailman/listinfo/pythoncad> > >_______________________________________________ >PythonCAD mailing list >PythonCAD@python.org >http://mail.python.org/mailman/listinfo/pythoncad From CSomerlot at Brwncald.com Thu Feb 5 08:07:30 2004 From: CSomerlot at Brwncald.com (Somerlot, Chris) Date: Thu Feb 5 08:08:07 2004 Subject: FW: [PythonCAD] GTK installation path Message-ID: It should, and that's the beauty of setting up the PATH variable in the code, I will double check on the other versions to make sure. > -----Original Message----- > From: Peter Gossner [mailto:gossner@arcom.com.au] > Sent: Wednesday, February 04, 2004 10:35 PM > To: pythoncad@python.org > Subject: Re: [PythonCAD] GTK installation path > > > Hey congrats, > Not having Windows I could not check. > Would the same path apply across the various flavours of > 'doze. (i.e 98 - XP ) ? > > --Pete > > > On Wed, 4 Feb 2004 13:36:33 -0800 "Somerlot, Chris" > wrote: > >I figured it out, I just had to edit gtkpycad.py as such: > > > >import getopt > >import sys > >if sys.platform == 'win32': > > gtkdir = 'C:/Program Files/Common Files/GTK/2.0' > > import os > > os.environ['PATH'] += ";%s/lib;%s/bin" % (gtkdir, gtkdir) > >else: > > import os > >import gtk > >... > > > >> -----Original Message----- > >> From: Somerlot, Chris > >> Sent: Tuesday, February 03, 2004 11:24 AM > >> To: Pythoncad > >> Subject: [PythonCAD] GTK installation path > >> > >> > >> I'm having trouble getting pythonCAD to start in Windows > >> because it can't find a GTK library (new installation). pyGTK > >> is in the python directory (/lib/site-packages), and the > >> installation of GTK put it somewhere in the Program Files > >> directory. Has anyone had this problem? I think I need to > >> either install GTK in a different directory or put in a PATH > >variable?> > >> Chris > >> > From gossner at arcom.com.au Thu Feb 5 11:04:03 2004 From: gossner at arcom.com.au (Peter Gossner) Date: Thu Feb 5 10:59:45 2004 Subject: [PythonCAD] GTK installation path In-Reply-To: References: Message-ID: <20040206023403.60089adb.gossner@arcom.com.au> On Thu, 5 Feb 2004 05:07:30 -0800 "Somerlot, Chris" wrote: >It should, and that's the beauty of setting up the PATH variable in the >code, I will double check on the other versions to make sure. > Cool. Thanks for that. Pete -- Mesage Composed: Thu Feb 5 16:03:45 UTC 2004 Calendar events: Feb 06 Waitangi Day (NZ) Feb 07 Beatles land at JFK airport to begin first U.S. tour, 1964 Feb 07 Steven Stills makes the first digitally recorded rock album, 1979 Feb 08 Black Thursday, The CDA is signed into law, 1996 Feb 08 1963 Revolution Anniversary in Iraq Feb 09 Carole King (Carole Klein) is born in Brooklyn, 1941 Feb 09 -51 degrees F, Vanderbilt MI, 1934 < http://www.gnu.org/software/tetum/ > < http://bigbutton.com.au/~gossner > < gossner@arcom.com.au > From ahaas at airmail.net Thu Feb 5 13:42:18 2004 From: ahaas at airmail.net (Art Haas) Date: Thu Feb 5 13:42:29 2004 Subject: [PythonCAD] Update on undo/redo work and other goings on Message-ID: <20040205184218.GA1013@artsapartment.org> Hi. So if you're getting the code with Subversion and update your repo, you'll find that a huge number of changes have just appeared affecting the entities like points, segments, circles, etc. These changes are part of my means of adding undo/redo abilities to PythonCAD, and they also reflect a large design change to the core of the program itself. Here's the problem the old design faced when doing undo/redo stuff - there was no good means of know just when an entity changed without trying to keep track of this information at every place that made a change. This shortcoming could have been dealt with in the code now by doing something like the following info = get_entity_to_be_changed_info() save_this_info_somewhere(info) change_the_entity(val1, val2, ...) This approach just wouldn't work, and it would make scripting in PythonCAD unbearable. A better approach is needed, and I think what I've added is a good start. Anyone doing programming with QT deals with the Signals and Slots approach Trolltech built that toolkit around. An object can send a message (signal) to another object by invoking a method (slot) in that object once the two have been connected with a connect() call. GTK has a similar approach, but I think the QT example is better as it maps more easily onto Python's object oriented features. A new base class called Messenger was added to the PythonCAD code, and this class provides connect() and sendMessage() method that do the same thing as the QT signals/slots code. One object can send a message to some other object if the two have been connected. Let me illustrate how I've changed things with a bit of code. Here's the old code for setting the 'x' value of a Point. In class '_Point' there is this ... def setx(self, val): _v = val if not isinstance(_v, float): _v = float(val) self.__x = _v ... and in the class 'Point' - a subclass of '_Point' - there is the following ... def setx(self, x): _Point.setx(self, x) self.modified() So, the best we could get from the old class is testing if the instance was modified, but there is no way to know just what the old value was before it was changed without getting that value before the change was made. Here's the code from the new 'Point' class. First, there is no longer a '_Point' parent class, as I've tried to simplify the class hierarchy and not have classes with multiple base classes. def setx(self, val): if self.isLocked(): raise RuntimeError, "Coordinate change not allowed - object locked." _v = val if not isinstance(_v, float): _v = float(val) _x = self.__x if abs(_x - _v) > 1e-10: self.__x = _v self.sendMessage('moved', _x, self.__y) self.modified() First, notice that there is a new self.isLocked() call. When simpilfying the base classes of the drawing entities, I created a new class called Entity that will allow you to set an entity as being locked - no changing it until you unlock it - or hidden. I've had people suggest to me that both features would be good to have, and now they are in there. So, back in the code, we check that the new value is a float value, then we compare it to the existing value. If the two values differ, then the point gets the new value assigned to it's 'x' value, and the point sends out a message called 'moved' and passes the old 'x' value and the current 'y' value as arguments. Now, lets suppose that there is some other object out there that is interested in keeping an eye on what a Point instance is doing. By using a connect() call, this object would then be notified by the point that it has been moved and here are the old coordinates of the point. So, we've now got some means of finding out when an entity changes and what value(s) it posssed before the change was made. It just so happens that there _is_ an entity now in PythonCAD that does track when a point moves. One of the goals I had for this year was to improve the entity storage data structures used in the program. The old approach was based on a sorted list, and needed entities that would be stored in these lists to implement a __cmp__ method so the list could be kept sorted. The code now uses quadtrees for storing most of the entities in a drawing, and this approach should make for faster searches of entities. The quadtree that stores Points is a PointQuadtree, and when a Point instance is added into a PointQuadtree instance, the Point instance makes this call: obj.connect('moved', self, PointQuadtree.movePoint) The Point instance is the variable 'obj', and the PointQuadtree is 'self', So, when the Point sends out a 'moved' message, the PointQuadtree receives it and invokes the movePoint() method. def movePoint(self, obj, *args): ... nifty code here ... When an object creates a connection with connect(), the first argument to connect is a string giving the message, the second argument is the object that will receive the message, and the third argument is a method that the receiving object can call. In this case, the PointQuadtree instance will call its 'movePoint' method. The method itself will recieve as its first argument the object making the call, in our case the point that moved, then there are a variable number of arguments. Again, in our 'moved' message case, there will be two arguments. See the code in 'Generic/point.py' for the details about the nifty code. The code changes in the last couple of weeks are really major, and I am sure that there glitches in what I've commited, so if you are accessing the Subversion repo things will be a little unstable for a while. The changes themself are working fairly well here, and I really like the way this messaging stuff is working, as adding undo/redo stuff can now be done by creating objects that utilize this message passing to save and store info about an object. In the case of a Point, an object would need to connect to the 'moved' message, and then it could store the old position of the point, and as the point itself is an argument, it can retrieve the points current position and store that as well. I'll be working on robustifying the new code over the next few weeks, as well as adding some to the message handling code. I think the ability to ignore a message may be useful. Also I'll start cooking up some classes that keep track of entity history for the undo/redo stuff. If you pull the code from Subversion, please test it and let me know of any problems you encounter. Having more eyes go over the code would certainly be good. I'll be adding some stuff to the website regarding the messaging approach the code is now using over the next few weeks. 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 From pachiburke at terra.es Thu Feb 5 05:55:15 2004 From: pachiburke at terra.es (Rafael Villar Burke) Date: Mon Feb 9 09:10:55 2004 Subject: [PythonCAD] GTK installation path In-Reply-To: <20040205140434.1f56155c.gossner@arcom.com.au> Message-ID: > -----Mensaje original----- > De: pythoncad-bounces@python.org [mailto:pythoncad-bounces@python.org]En > nombre de Peter Gossner > Enviado el: jueves, 05 de febrero de 2004 4:35 > Para: pythoncad@python.org > Asunto: Re: [PythonCAD] GTK installation path > > > Hey congrats, > Not having Windows I could not check. > Would the same path apply across the various flavours of 'doze. > (i.e 98 - XP ) ? The path to the GTK libraries should be set as a variable in the system path and it depends on the exact directory where each one decides to install GTK. This is explained in the GTK installation docs. This patch hardcodes the default path, but some people (like me) don't always use default paths. Perhaps that code snippet could go into a README.win32 -- Pachi From gossner at arcom.com.au Mon Feb 9 09:25:52 2004 From: gossner at arcom.com.au (Peter Gossner) Date: Mon Feb 9 09:21:55 2004 Subject: [PythonCAD] GTK installation path In-Reply-To: References: <20040205140434.1f56155c.gossner@arcom.com.au> Message-ID: <20040210005552.4184dadf.gossner@arcom.com.au> On Thu, 5 Feb 2004 11:55:15 +0100 from a terminal far far away "Rafael" wrote: > > >> -----Mensaje original----- >> De: pythoncad-bounces@python.org >[mailto:pythoncad-bounces@python.org]En> nombre de Peter Gossner >> Enviado el: jueves, 05 de febrero de 2004 4:35 >> Para: pythoncad@python.org >> Asunto: Re: [PythonCAD] GTK installation path >> >> >> Hey congrats, >> Not having Windows I could not check. >> Would the same path apply across the various flavours of 'doze. >> (i.e 98 - XP ) ? >The path to the GTK libraries should be set as a variable in the system >path and it depends on the exact directory where each one decides to >install GTK. This is explained in the GTK installation docs. >This patch hardcodes the default path, but some people (like me) don't >always use default paths. >Perhaps that code snippet could go into a README.win32 > yes It probably is a good idea :) Sorry I can not validate this .. no 'doze box here (at the moment). (gave away my crossover cable :( >-- >Pachi > > >_______________________________________________ >PythonCAD mailing list >PythonCAD@python.org >http://mail.python.org/mailman/listinfo/pythoncad From vic at wittmanhydro.com Tue Feb 10 12:01:27 2004 From: vic at wittmanhydro.com (Vic Kelson) Date: Tue Feb 10 14:08:22 2004 Subject: [PythonCAD] Looking for DXF help Message-ID: <40290E67.8020107@wittmanhydro.com> Hi All, I am in need of code for writing DXF or DWG files from Python. My application is pretty simple, only 2-D, but I need to write in world-coordinates. The application is drawing geological cross-sections from spatial data and lithological data. I have done this in 1998 using VB (ugh!), but my new data management framework is all Python (yeah!). I can of course write DXF files "by hand", but I'd really rather use a library if one exists. Incidentally, is the OpenDWG library python-able? SWIG-able? Not quite "open", but it's pretty good... Does PythonCAD plot to scale? Does it have hatching/fill patterns? Would it be a capable cross-section drawing tool (in Win32 or Linux)? THANKS, Vic Kelson From ahaas at airmail.net Tue Feb 10 14:13:59 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Feb 10 14:14:14 2004 Subject: [PythonCAD] Looking for DXF help In-Reply-To: <40290E67.8020107@wittmanhydro.com> References: <40290E67.8020107@wittmanhydro.com> Message-ID: <20040210191359.GC4928@artsapartment.org> On Tue, Feb 10, 2004 at 12:01:27PM -0500, Vic Kelson wrote: > Hi All, > > I am in need of code for writing DXF or DWG files from Python. My > application is pretty simple, only 2-D, but I need to write in > world-coordinates. The application is drawing geological cross-sections > from spatial data and lithological data. I have done this in 1998 using > VB (ugh!), but my new data management framework is all Python (yeah!). I > can of course write DXF files "by hand", but I'd really rather use a > library if one exists. > > Incidentally, is the OpenDWG library python-able? SWIG-able? Not quite > "open", but it's pretty good... > > Does PythonCAD plot to scale? Does it have hatching/fill patterns? Would > it be a capable cross-section drawing tool (in Win32 or Linux)? > Hi. Unfortunately PythonCAD won't do what you need. The two features you're looking for - plotting and hatching - are the two big missing parts of the program as it currently stands. Sorry. As for handling DWG and DXF files, there is code in PythonCAD for reading these formats, but no code for writing them. Coding up a DXF writer will probably be much easier than a DWG writer due to the nature of the DWG file format - binary, lots of checksums, bitstreams for storing the data, and other unpleasantness to deal with. I don't believe the OpenDWG library is has a Python interface or SWIG interface at the moment, but the best source of info is the OpenDWG site. Sorry to inform you that PythonCAD can't help you right now. Art Haas -- 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 From ewilhelm at sbcglobal.net Tue Feb 10 14:31:51 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Feb 10 14:29:17 2004 Subject: [PythonCAD] Looking for DXF help In-Reply-To: <20040210191359.GC4928@artsapartment.org> References: <40290E67.8020107@wittmanhydro.com> <20040210191359.GC4928@artsapartment.org> Message-ID: <200402101331.51367.ewilhelm@sbcglobal.net> > The following was supposedly scribed by > Art Haas > on Tuesday 10 February 2004 01:13 pm: >I don't believe the OpenDWG library is has a Python interface or SWIG >interface at the moment, but the best source of info is the OpenDWG >site. It does have a Perl binding CAD::Drawing::IO::DWGI, if nothing else, this might give you some insight into how to do a python binding. If you only need dxf, you might try binding the Dime library into Python. --Eric From digitect at mindspring.com Tue Feb 10 18:44:19 2004 From: digitect at mindspring.com (Steve Hall) Date: Tue Feb 10 18:44:23 2004 Subject: [PythonCAD] Looking for DXF help Message-ID: <32105631.1076456659463.JavaMail.root@wamui01.slb.atl.earthlink.net> From: Art Haas, Feb 10, 2004 2:13 PM > On Tue, Feb 10, 2004 at 12:01:27PM -0500, Vic Kelson wrote: > > > > I am in need of code for writing DXF or DWG files from Python... I > > can of course write DXF files "by hand", but I'd really rather use > > a library if one exists. > > As for handling DWG and DXF files, there is code in PythonCAD for > reading these formats, but no code for writing them. Vic, if you do any research on this could you please post your findings back here? I have a GPL [expensive, proprietary]CAD script project that is getting ready to release, and it will maintain links to the tons of helpful GPL projects I continue to find. (Like PythonCAD.) The OpenDWG project is as closed source as it can be, and I don't know if I've ever found a single clearinghouse for reverse engineering the .DWG or .DXF doc formats. If Free CAD software is ever going to make a dent in the market, we need to organize a bit better, and collect information a bit more centrally. Thanks. -- Steve Hall [ digitect@mindspring.com ] From ewilhelm at sbcglobal.net Tue Feb 10 22:04:48 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Tue Feb 10 22:02:15 2004 Subject: [PythonCAD] Looking for DXF help In-Reply-To: <32105631.1076456659463.JavaMail.root@wamui01.slb.atl.earthlink.net> References: <32105631.1076456659463.JavaMail.root@wamui01.slb.atl.earthlink.net> Message-ID: <200402102104.48604.ewilhelm@sbcglobal.net> > The following was supposedly scribed by > Steve Hall > on Tuesday 10 February 2004 05:44 pm: > I have a GPL [expensive, proprietary]CAD script >project that is getting ready to release, and it will maintain links >to the tons of helpful GPL projects I continue to find. (Like >PythonCAD.) > >The OpenDWG project is as closed source as it can be, and I don't know >if I've ever found a single clearinghouse for reverse engineering the >.DWG or .DXF doc formats. If Free CAD software is ever going to make a >dent in the market, we need to organize a bit better, and collect >information a bit more centrally. I'd love to see this central information collection. If you aren't on the cad-linux mailing list, you might want to go through the archives, and phrostie's page http://www.freelists.org/webpage/cad-linux http://www.freelists.org/webpage/cad-linux-dev http://pfrostie.freeservers.com/cad-tastrafy/ --Eric -- The opinions expressed in this e-mail were randomly generated by the computer and do not necessarily reflect the views of its owner. --Management From digitect at mindspring.com Tue Feb 10 23:40:05 2004 From: digitect at mindspring.com (Steve Hall) Date: Tue Feb 10 23:41:09 2004 Subject: [PythonCAD] Looking for DXF help In-Reply-To: <200402102104.48604.ewilhelm@sbcglobal.net> References: <32105631.1076456659463.JavaMail.root@wamui01.slb.atl.earthlink.net> <200402102104.48604.ewilhelm@sbcglobal.net> Message-ID: <1076474404.4661.2.camel@localhost.localdomain> From: Eric Wilhelm, Tue Feb 10 21:04:48 2004 > by Steve Hall, Tuesday 10 February 2004 05:44 pm: > > > > I have a GPL [expensive, proprietary]CAD script project that is > > getting ready to release, and it will maintain links to the tons of > > helpful GPL projects I continue to find. (Like PythonCAD.) > > > > The OpenDWG project is as closed source as it can be, and I don't > > know if I've ever found a single clearinghouse for reverse > > engineering the .DWG or .DXF doc formats. If Free CAD software is > > ever going to make a dent in the market, we need to organize a bit > > better, and collect information a bit more centrally. > > I'd love to see this central information collection. > > If you aren't on the cad-linux mailing list, you might want to go > through the archives, and phrostie's page > http://www.freelists.org/webpage/cad-linux > http://www.freelists.org/webpage/cad-linux-dev > http://pfrostie.freeservers.com/cad-tastrafy/ Yup, seen those. Unfortunately, some of us are going to be stuck on proprietary systems for a while longer, which is where our project will come in, sort of a way to introduce Open Source to the masses. Which leads me to something a bit more on topic for this list... Has anyone here ever written extensions for A___CAD using Python? I've heard some stand-alone/static binaries could be compiled for Win32 from Python, but is this crazy talk? Of course, ALisp can run and return from binaries, but is this reasonable? I'm itching to get into Python, and writing tools which could be reused across CAD packages (like the thread-starting DXF inquiry) would make a *huge* amount of sense if it helps us all migrate some day. -- Steve Hall [ digitect@mindspring.com ] From pfrostie at yahoo.com Wed Feb 11 06:56:30 2004 From: pfrostie at yahoo.com (phrostie) Date: Wed Feb 11 06:56:34 2004 Subject: [PythonCAD] Looking for DXF help In-Reply-To: <1076474404.4661.2.camel@localhost.localdomain> Message-ID: <20040211115630.44226.qmail@web60810.mail.yahoo.com> > > Has anyone here ever written extensions for A___CAD using Python? I've > heard some stand-alone/static binaries could be compiled for Win32 > from Python, but is this crazy talk? Of course, ALisp can run and > return from binaries, but is this reasonable? > > I'm itching to get into Python, and writing tools which could be > reused across CAD packages (like the thread-starting DXF inquiry) > would make a *huge* amount of sense if it helps us all migrate some > day. > > like: http://sourceforge.net/projects/pyacad/ ===== phrostie Oh I have slipped the surly bonds of DOS and danced the skies on Linux silvered wings. http://pfrostie.freeservers.com/cad-tastrafy/ http://www.freelists.org/webpage/cad-linux __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html From pachiburke at terra.es Wed Feb 11 05:59:54 2004 From: pachiburke at terra.es (Rafael Villar Burke) Date: Wed Feb 11 08:56:45 2004 Subject: RV: [PythonCAD] Looking for DXF help Message-ID: Steve Hall wrote: >Has anyone here ever written extensions for A___CAD using Python? I've >heard some stand-alone/static binaries could be compiled for Win32 >from Python, but is this crazy talk? Of course, ALisp can run and >return from binaries, but is this reasonable? > >I'm itching to get into Python, and writing tools which could be >reused across CAD packages (like the thread-starting DXF inquiry) >would make a *huge* amount of sense if it helps us all migrate some >day. > > I suppose you already know pyacad. It's a python wrapper to the A***CAD/IntelliCAD API. Its home page is located at http://pyacad.sourceforge.net/ Yet, I don't know any project based on this wrapper. Cheers, (also from the freearchitecture mailing list ;) Rafael Villar Burke From digitect at mindspring.com Wed Feb 11 23:26:29 2004 From: digitect at mindspring.com (Steve Hall) Date: Wed Feb 11 23:27:34 2004 Subject: [PythonCAD] Looking for DXF help In-Reply-To: <20040211115630.44226.qmail@web60810.mail.yahoo.com> References: <20040211115630.44226.qmail@web60810.mail.yahoo.com> Message-ID: <1076559988.2393.1.camel@localhost.localdomain> [Cross-posting to freearchitecture, since this is nearly OT here.] From: phrostie, Wed Feb 11 06:56:30 2004 > > > Has anyone here ever written extensions for A___CAD using Python? > > I've heard some stand-alone/static binaries could be compiled for > > Win32 from Python, but is this crazy talk? Of course, ALisp can run > > and return from binaries, but is this reasonable? > > like: > http://sourceforge.net/projects/pyacad/ This appears to require the Python environment. Not knowing Python (yet), I'm looking for a simple binary distributable that I can run from AutoCAD. It won't work if I have to convince my company to install Python on 800 machines. ;) I guess I was looking for stand alone executables, something that might be created with: http://starship.python.net/crew/theller/py2exe/ Throw in the ability to write GUI dialogs for AutoCAD *with Python* and I begin to see a way to write tools (like our thread-starting .DXF) that can be Free for the imprisoned yet still useful to a Free project like PythonCAD. -- Steve Hall [ digitect@mindspring.com ] From ewilhelm at sbcglobal.net Thu Feb 12 11:20:22 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Thu Feb 12 11:17:46 2004 Subject: [PythonCAD] I/O filters via text streams Message-ID: <200402121020.22780.ewilhelm@sbcglobal.net> Art, I mentioned this a bit a while back. Did you ever come-up with an implementation for dwg/dxf import and export to/from pythoncad? I'm in discussions with the author of perlcad about collaboration between perlcad and CAD::Drawing. It's looking like one thing which might come out of this is a set of streaming objects which allow one I/O backend to be connected directly to another. It occurred to me that this might be a good way to consolidate import/export methods between multiple projects. For example, iirc, you are using an XML format for pythoncad. If a backend for CAD::Drawing could be written to handle this format, a small perl program could be opened in a pipeline to load/save to/from this format or any other supported format. It would also make a great command-line converter as well as giving any program automatic import/export abilities to any other program which had a working backend to CAD::Drawing. Any thoughts? --Eric From ahaas at airmail.net Thu Feb 12 13:20:22 2004 From: ahaas at airmail.net (Art Haas) Date: Thu Feb 12 13:20:39 2004 Subject: [PythonCAD] I/O filters via text streams In-Reply-To: <200402121020.22780.ewilhelm@sbcglobal.net> References: <200402121020.22780.ewilhelm@sbcglobal.net> Message-ID: <20040212182022.GB28426@artsapartment.org> On Thu, Feb 12, 2004 at 10:20:22AM -0600, Eric Wilhelm wrote: > Art, > > I mentioned this a bit a while back. Did you ever come-up with an > implementation for dwg/dxf import and export to/from pythoncad? Yes and no. The DWG stuff is at the point where there is a means of creating a DWG class, having it read the DWG file and store all that rich, creamy DWG goodness in itself, and then retreive the information from the class and use it as one sees fit. DXF stuff is still little more than just printing out the contents of the file. Aside from the lack of writing either a DWG or DXF file, a problem with the current DWG reader is that it won't work if the DWG info is coming in through a pipe, as the reader does all sorts of seek()ing through the file when reading the objects found in the object map. One can read a DWG file from in a serial manner, but that isn't how the code does it at present. > I'm in discussions with the author of perlcad about collaboration between > perlcad and CAD::Drawing. It's looking like one thing which might come out > of this is a set of streaming objects which allow one I/O backend to be > connected directly to another. > > It occurred to me that this might be a good way to consolidate import/export > methods between multiple projects. > > For example, iirc, you are using an XML format for pythoncad. If a backend > for CAD::Drawing could be written to handle this format, a small perl program > could be opened in a pipeline to load/save to/from this format or any other > supported format. > > It would also make a great command-line converter as well as giving any > program automatic import/export abilities to any other program which had a > working backend to CAD::Drawing. > > Any thoughts? PythonCAD does use XML for storing files, and I'm interested in anything that can make the format exportable to other programs. -- 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 From ewilhelm at sbcglobal.net Thu Feb 12 13:53:28 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Thu Feb 12 13:50:50 2004 Subject: [PythonCAD] I/O filters via text streams In-Reply-To: <20040212182022.GB28426@artsapartment.org> References: <200402121020.22780.ewilhelm@sbcglobal.net> <20040212182022.GB28426@artsapartment.org> Message-ID: <200402121253.28166.ewilhelm@sbcglobal.net> > The following was supposedly scribed by > Art Haas > on Thursday 12 February 2004 12:20 pm: >Aside from the lack of writing either a DWG or DXF file, a problem with >the current DWG reader is that it won't work if the DWG info is coming >in through a pipe, as the reader does all sorts of seek()ing through the >file when reading the objects found in the object map. One can read a DWG >file from in a serial manner, but that isn't how the code does it at > present. I don't think that is really a problem. Some formats are more suited to being parsed into a library as a whole (would that be the wholistic method?) Where pipes come in is the ability to connect libraries from dissimilar languages. I think it's fine if one end of the pipe has to read everything before it can start emitting to the other end (and also fine if the far end has to receive everything before saving / dumping.) The central part of the idea that I have is that CAD::Drawing would have a stream implementation available for its objects so that a middle-ground in-memory data-structure is not necessary. The worst case would be two wholistic formats connected together, but its much better to store the data in two places rather than three. The best case would be two streamable formats connected together, where each time an entity is read from the input stream, it is immediately added to the output stream. CAD::Drawing currently implements multiple format support by having each backend use a load and save function. The load function calls add methods and the save function calls get methods. Currently, these methods build into an in-memory data structure, so to go from dwg to dxf, you load the whole dwg via the library (in C structs, etc), go through it adding each entity to a format-agnostic data structure, and then go through that data structure, adding each entity to a dxf object before saving the file. The thought is to have the add methods be connectable directly to the output format. So, rather than having 4000 entities in the middle-ground memory between formats, you would have 1 entity in memory at a time which gets passed directly to the save function. --Eric -- A counterintuitive sansevieria trifasciata was once literalized guiltily. --Product of Artificial Intelligence From ahaas at airmail.net Fri Feb 13 12:11:20 2004 From: ahaas at airmail.net (Art Haas) Date: Fri Feb 13 12:12:16 2004 Subject: [PythonCAD] Recent changes update Message-ID: <20040213171120.GA31899@artsapartment.org> Hi. Just a quick note to say that practically all of the quadtree stuff is now in the code. The chamfers and fillets are the two entities that have yet to be converted, but all the other drawing entities are done. The dimension entities have been converted to the messaging system, and lots of changes to do this conversion have been applied. The conversion fixed a couple of dumb bugs - typos, returning the wrong value, etc. - and improved a number of the methods that dimension objects contain. I'll definitely be making a release this month, probably near or at the end of the month. Even though the undo/redo stuff isn't implemented, all the changes in the code to implement that missing functionality seem to be working well, and the usage of quadtrees to store, and more importantly find stored entities, add up to a set of improvements that make a release worthwhile. Undo/redo stuff should start appearing soon. 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 From digitect at mindspring.com Sat Feb 14 12:23:11 2004 From: digitect at mindspring.com (Steve Hall) Date: Sat Feb 14 12:24:14 2004 Subject: [PythonCAD] HTML bug on status.html Message-ID: <1076779390.4441.7.camel@localhost.localdomain> FYI, there's a missing close quote on the python.org link in the Good Points third paragraph which obscures most of the following paragraph. -- Steve Hall [ digitect@mindspring.com ] From ahaas at airmail.net Sun Feb 15 11:33:08 2004 From: ahaas at airmail.net (Art Haas) Date: Sun Feb 15 11:34:59 2004 Subject: [PythonCAD] HTML bug on status.html In-Reply-To: <1076779390.4441.7.camel@localhost.localdomain> References: <1076779390.4441.7.camel@localhost.localdomain> Message-ID: <20040215163308.GA7661@artsapartment.org> On Sat, Feb 14, 2004 at 12:23:11PM -0500, Steve Hall wrote: > > FYI, there's a missing close quote on the python.org link in the Good > Points third paragraph which obscures most of the following paragraph. > Thanks for spotting this. It should be fixed, as was a missing quote in the opendwg.org link. 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 From ewilhelm at sbcglobal.net Mon Feb 23 07:50:07 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Mon Feb 23 07:48:13 2004 Subject: [PythonCAD] dwgbase.py wins Message-ID: <200402230650.07675.ewilhelm@sbcglobal.net> I've been messing with the idea of a perl binding to the dime dxf library for a few days now. I've been looking for a way to get a GPL'd dwg/dxf backend into CAD::Drawing (currently using the *penDWG library.) So, after this brief tour of C++ and an even briefer tour of python, it looks like I'll be better off to work on the fine python library that Art has so kindly cooked-up for us. As strike one, there is the fact that the Dime library does not support any sort of text objects. Strike two is that C++ is boringly stiff. So, since we aren't playing baseball, I've decided to focus on learning python and finding my way around the dwg library. Art, Is there any formal documentation for the dwg*.py modules besides that which is inline in the source? Would you like some more? Is there any sort of test suite set-up? Should I write one? How about sample usage scripts? Also, can you summarize the current status of its capabilities? (e.g. read/write dxf/dwg) --Eric -- "It is a mistake to allow any mechanical object to realize that you are in a hurry." --Ralph's Observation From ahaas at airmail.net Mon Feb 23 10:53:59 2004 From: ahaas at airmail.net (Art Haas) Date: Mon Feb 23 10:54:10 2004 Subject: [PythonCAD] dwgbase.py wins In-Reply-To: <200402230650.07675.ewilhelm@sbcglobal.net> References: <200402230650.07675.ewilhelm@sbcglobal.net> Message-ID: <20040223155359.GA17633@artsapartment.org> On Mon, Feb 23, 2004 at 06:50:07AM -0600, Eric Wilhelm wrote: > > Is there any formal documentation for the dwg*.py modules besides that which > is inline in the source? Would you like some more? > Not really. I'd like to have much more documentation available, particularly on the web pages, but haven't made the effort to due this. I'd like to avoid duplicating work, so an ideal solution would be something that takes the doc-string from the code and extracts them into nice web pages. A program to do this may already exist, but I don't know for sure. > Is there any sort of test suite set-up? Should I write one? There isn't any sort of test suite, and writing one would be good. One thing I found when reading a DWG file is that things either work or the fail spectacularly, as errors in decoding the bit-streams in the DWG format will quickly cause the reading code to do the wrong thing. > > How about sample usage scripts? > Those would be great. Once a few of these are written by people other than myself I am certain that some missing functionality will be revealed, or a better way of presenting the DWG data can be developed. > Also, can you summarize the current status of its capabilities? (e.g. > read/write dxf/dwg) There is no writing capability yet for either DWG/DXF formats. The reading of DWG formats is currently R12, R13, R14, and R15. Based on the sample files I have the readers pick up nearly all the entities in the drawings successfully, but there are one or two entity types that aren't read in because the OpenDWG docs don't describe them. DXF file handling is still little more than printing the entities out, but dealing with DXF files is much simpler than DWG files, so adding code for improving the handling of these files should be straightforward. 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 From CSomerlot at Brwncald.com Mon Feb 23 11:05:26 2004 From: CSomerlot at Brwncald.com (Somerlot, Chris) Date: Mon Feb 23 11:06:17 2004 Subject: FW: [PythonCAD] dwgbase.py wins Message-ID: > On Mon, Feb 23, 2004 at 06:50:07AM -0600, Eric Wilhelm wrote: > > > > Is there any formal documentation for the dwg*.py modules > besides that > > which > > is inline in the source? Would you like some more? > > > > Not really. I'd like to have much more documentation > available, particularly on the web pages, but haven't made > the effort to due this. I'd like to avoid duplicating work, > so an ideal solution would be something that takes the > doc-string from the code and extracts them into nice web > pages. A program to do this may already exist, but I don't > know for sure. > How about Epydoc? http://epydoc.sourceforge.net/ I also like PyXR http://www.cathoderaymission.net/~logistix/python/pyxr.html, I found both of these handy on other projects. Chris From ahaas at airmail.net Mon Feb 23 11:11:42 2004 From: ahaas at airmail.net (Art Haas) Date: Mon Feb 23 11:11:49 2004 Subject: FW: [PythonCAD] dwgbase.py wins In-Reply-To: References: Message-ID: <20040223161142.GB17633@artsapartment.org> On Mon, Feb 23, 2004 at 08:05:26AM -0800, Somerlot, Chris wrote: > > > On Mon, Feb 23, 2004 at 06:50:07AM -0600, Eric Wilhelm wrote: > > > > > > Is there any formal documentation for the dwg*.py modules > > besides that > > > which > > > is inline in the source? Would you like some more? > > > > > > > Not really. I'd like to have much more documentation > > available, particularly on the web pages, but haven't made > > the effort to due this. I'd like to avoid duplicating work, > > so an ideal solution would be something that takes the > > doc-string from the code and extracts them into nice web > > pages. A program to do this may already exist, but I don't > > know for sure. > > > How about Epydoc? http://epydoc.sourceforge.net/ > > I also like PyXR > http://www.cathoderaymission.net/~logistix/python/pyxr.html, I found both of > these handy on other projects. > I'll take a look at both of these. Thanks for the links. 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 From ahaas at airmail.net Tue Feb 24 11:15:58 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Feb 24 11:16:59 2004 Subject: [PythonCAD] ANNOUNCE: Twelfth release of PythonCAD now available Message-ID: <20040224161558.GA8066@artsapartment.org> Hi. I'd like to announce the twelfth development release of PythonCAD, a CAD package for open-source software users. As the name implies, PythonCAD is written entirely in Python. The goal of this project is to create a fully scriptable drafting program that will match and eventually exceed features found in commercial CAD software. PythonCAD is released under the GNU Public License (GPL). PythonCAD requires Python 2.2 or Python 2.3. The interface is GTK 2.0 based, and uses the PyGTK module for interfacing to GTK. The design of PythonCAD is built around the idea of separating the interface from the back end as much as possible. By doing this, it is hoped that both GNOME and KDE interfaces can be added to PythonCAD through usage of the appropriate Python module. Addition of other interfaces will depend on the availability of a Python module for that particular interface and developer interest and action. The twelfth release of PythonCAD contains a large number of internal changes to the program. The class hierarchy for the various entities has been simplified, and the ability to hide or lock entities on an individual basis has been added. The largest change to the code is the incorporation of a messaging system between the entities similar to that in Trolltech's QT framework. Another significant change in this release is the introduction of quadtrees for storing the various entities in a drawing, which should provide faster searching for the location of the entities. A number of code cleanups have also been applied to this release. Numerous deprecated methods have been removed, and several Python function calls that are deprecated or appear to be heading that way have been removed. The code cleanup also exposed various bugs which are now resolved. Changes due to the incorporation of the new messaging system have made a number of entity methods deprecated, so warnings messages will appear if they are called. These newly deprecated methods will be removed in an upcoming release. The mailing list for the development and use of PythonCAD is available. Visit the following page for information about subscribing and viewing the mailing list archive: http://mail.python.org/mailman/listinfo/pythoncad Visit the PythonCAD web site for more information about what PythonCAD does and aims to be: http://www.pythoncad.org/ Come and join me in developing PythonCAD into a world class drafting program, and Happy New Year to everyone! Art Haas -- 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 From budr at netride.net Tue Feb 24 18:17:53 2004 From: budr at netride.net (Bud Rogers) Date: Tue Feb 24 18:18:00 2004 Subject: [PythonCAD] newbie install can't find Generic.globals Message-ID: <200402241717.53381.budr@netride.net> Greetings, Just saw the release announcement on c.l.p, thought I would have a look at pythoncad. I followed the installation instructions on the web page. If I run gtkpycad.py from the source directory, it seems to work OK. If I run it from its installed location in /usr/local/bin, I get this error: budr@twocups:~$ which gtkpycad.py /usr/local/bin/gtkpycad.py budr@twocups:~$ gtkpycad.py Traceback (most recent call last): File "/usr/local/bin/gtkpycad.py", line 31, in ? import Generic.globals ImportError: No module named Generic.globals I know just enough about python to whet my appetite. What have I overlooked? -- Bud Rogers KD5SZ From ahaas at airmail.net Tue Feb 24 19:08:59 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Feb 24 19:09:12 2004 Subject: [PythonCAD] newbie install can't find Generic.globals In-Reply-To: <200402241717.53381.budr@netride.net> References: <200402241717.53381.budr@netride.net> Message-ID: <20040225000859.GA1312@artsapartment.org> On Tue, Feb 24, 2004 at 05:17:53PM -0600, Bud Rogers wrote: > Greetings, > > Just saw the release announcement on c.l.p, thought I would have a look > at pythoncad. I followed the installation instructions on the web > page. If I run gtkpycad.py from the source directory, it seems to work > OK. If I run it from its installed location in /usr/local/bin, I get > this error: > > budr@twocups:~$ which gtkpycad.py > /usr/local/bin/gtkpycad.py > budr@twocups:~$ gtkpycad.py > Traceback (most recent call last): > File "/usr/local/bin/gtkpycad.py", line 31, in ? > import Generic.globals > ImportError: No module named Generic.globals > > I know just enough about python to whet my appetite. What have I > overlooked? > It sounds like Python can't find the code in it's built-in search path. What do you see when you do the following ... $ python >>> import sys >>> sys.path You should see a list of directories. These are the directories that Python will search when a bit of code uses an 'import' statement. On my machine I get the following ... >>> import sys >>> sys.path ['', '/usr/lib/python23.zip', '/usr/lib/python2.3', '/usr/lib/python2.3/plat-linux2', '/usr/lib/python2.3/lib-tk', '/usr/lib/python2.3/lib-dynload', '/usr/lib/python2.3/site-packages', '/usr/lib/python2.3/site-packages/PythonCAD', '/usr/lib/python2.3/site-packages/gtk-2.0'] Notice that '/usr/lib/python2.3/site-packages/PythonCAD' is in the list. That directory is where the 'install.py' script put the files when I run the install command 'python setup.py install'. 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 From budr at netride.net Tue Feb 24 19:28:03 2004 From: budr at netride.net (Bud Rogers) Date: Tue Feb 24 19:28:10 2004 Subject: [PythonCAD] newbie install can't find Generic.globals In-Reply-To: <20040225000859.GA1312@artsapartment.org> References: <200402241717.53381.budr@netride.net> <20040225000859.GA1312@artsapartment.org> Message-ID: <200402241828.03259.budr@netride.net> On Tuesday 24 February 2004 18:08, Art Haas wrote: > It sounds like Python can't find the code in it's built-in search > path. What do you see when you do the following ... > Notice that '/usr/lib/python2.3/site-packages/PythonCAD' is in the > list. That directory is where the 'install.py' script put the files > when I run the install command 'python setup.py install'. That was it. sys.path listed /usr/lib/python2.3/site-packages, among others, but the PythonCad directory wasn't there. I ran the install script as a normal user the first time. I wondered that it went pretty fast and didn't seem to do much. I re-ran the script as sudo, and it spent a couple minutes byte compiling things into site-packages. Now gtkpycad.py runs OK from its installed location. One of the joys of being a newbie -- everything's an adventure. Thanks for the prompt response. -- Bud Rogers KD5SZ From ahaas at airmail.net Tue Feb 24 19:32:55 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Feb 24 19:33:46 2004 Subject: [PythonCAD] newbie install can't find Generic.globals In-Reply-To: <200402241828.03259.budr@netride.net> References: <200402241717.53381.budr@netride.net> <20040225000859.GA1312@artsapartment.org> <200402241828.03259.budr@netride.net> Message-ID: <20040225003255.GB1312@artsapartment.org> On Tue, Feb 24, 2004 at 06:28:03PM -0600, Bud Rogers wrote: > On Tuesday 24 February 2004 18:08, Art Haas wrote: > > That was it. sys.path listed /usr/lib/python2.3/site-packages, among > others, but the PythonCad directory wasn't there. I ran the install > script as a normal user the first time. I wondered that it went pretty > fast and didn't seem to do much. I re-ran the script as sudo, and it > spent a couple minutes byte compiling things into site-packages. Now > gtkpycad.py runs OK from its installed location. > > One of the joys of being a newbie -- everything's an adventure. Thanks > for the prompt response. > Glad to hear it installed correctly and works. Hope you like the program. Comments, suggestions, and patches welcomed. Art Haas -- 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