From ahaas at airmail.net Thu Jun 2 15:30:15 2005 From: ahaas at airmail.net (Art Haas) Date: Thu, 2 Jun 2005 08:30:15 -0500 Subject: [PythonCAD] R25 bug In-Reply-To: <42975FF8.40108@unipex.it> References: <42975FF8.40108@unipex.it> Message-ID: <20050602133015.GB23906@artsapartment.org> On Fri, May 27, 2005 at 07:59:20PM +0200, Michele Petrazzo wrote: > I have just download the release 25, and I found these three bugs: > > - when I print: > File > "/home/michele/PythonCAD-DS1-R25/PythonCAD/Interface/Gtk/gtkmenus.py", > line 320, in file_print_screen_cb > gtkprinting.print_dialog(gtkimage, _plot) > File > "/home/michele/PythonCAD-DS1-R25/PythonCAD/Interface/Gtk/gtkprinting.py", > line 152, in print_dialog > if isinstance(_size_widget, gtk.ComboBox): > AttributeError: 'module' object has no attribute 'ComboBox' The fix is to change this line to look like ... if hasattr(gtk, 'ComboBox') and isinstance(_size_widget, gtk.ComboBox): > > - into PythonCAD/Interface/Gtk/gtkmodify.py at line 393 there is a > Truee, not True Arrgghh!!! Obviously remove the extra 'e' ... > - I draw an object (line, circle, etc..), I select move (one of the > three), I select the first point to move, the second and after I select > no objects then the program ask me for select an object (I click two > times into the canvas). After I re-click for the distance (first and > second point), but now I click over the object, and I receive this error: > [ ... snip ... ] I'll try and track this down today. After making the release last week I went out of town and was away from my computer. 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 Thu Jun 2 21:37:02 2005 From: ahaas at airmail.net (Art Haas) Date: Thu, 2 Jun 2005 14:37:02 -0500 Subject: [PythonCAD] R25 bug In-Reply-To: <20050602133015.GB23906@artsapartment.org> References: <42975FF8.40108@unipex.it> <20050602133015.GB23906@artsapartment.org> Message-ID: <20050602193702.GB14121@artsapartment.org> On Thu, Jun 02, 2005 at 08:30:15AM -0500, Art Haas wrote: > > - I draw an object (line, circle, etc..), I select move (one of the > > three), I select the first point to move, the second and after I select > > no objects then the program ask me for select an object (I click two > > times into the canvas). After I re-click for the distance (first and > > second point), but now I click over the object, and I receive this error: > > [ ... snip ... ] > > I'll try and track this down today. > > After making the release last week I went out of town and was away from > my computer. I just looked at this and things work here. I drew a segment, then went to 'Modify' -> 'Move' -> 'Horizontal' (my arbitrary choice), clicked in the drawing area once to define the start point for defining the distance, then clicked again to define the second point and thus the distance, and then clicked on the segment and it moved correctly. I guess I'm not duplicating the steps exactly. On another note, I've fixed the embarrasing 'Truee' typo and added the additional hasattr() test regarding the ComboBox, and my changes have been sent to the repo. I also bumped the version info in the '.spec' file, the 'setup.py' file, and the 'gtkpycad.py' file. I may make a release tomorrow with these bug fixes but I have not decided just yet. I may also make a small patch and post it to the mailing list and the download page as well. 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 Thu Jun 2 23:09:24 2005 From: ahaas at airmail.net (Art Haas) Date: Thu, 2 Jun 2005 16:09:24 -0500 Subject: [PythonCAD] Patch for DS1-R25 bugs Message-ID: <20050602210924.GC14121@artsapartment.org> Hi. I'm going to post this patch to the website as well as the mailing list. The patch contains two trivial fixes for the twenty-fifth releases. Index: PythonCAD/Interface/Gtk/gtkmodify.py =================================================================== --- PythonCAD/Interface/Gtk/gtkmodify.py (.../tags/DS1-R25) (revision 1865) +++ PythonCAD/Interface/Gtk/gtkmodify.py (.../trunk) (revision 1865) @@ -390,7 +390,7 @@ gtkimage.setPrompt("Select the points to move.") # tool.delHandler("entry_event") tool.setHandler("button_press", stretch_elem_button_press_cb) - return Truee + return True def stretch_horizontal_init(tool): tool.initialize() Index: PythonCAD/Interface/Gtk/gtkprinting.py =================================================================== --- PythonCAD/Interface/Gtk/gtkprinting.py (.../tags/DS1-R25) (revision 1865) +++ PythonCAD/Interface/Gtk/gtkprinting.py (.../trunk) (revision 1865) @@ -149,7 +149,7 @@ plot.invertWhite(_icb.get_active()) plot.setLandscapeMode(_lcb.get_active()) plot.getPlotData() - if isinstance(_size_widget, gtk.ComboBox): + if hasattr(gtk, 'ComboBox') and isinstance(_size_widget, gtk.ComboBox): _idx = _size_widget.get_active() elif isinstance(_size_widget, gtk.OptionMenu): _idx = _sizewidget.get_history() -- 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 Thu Jun 2 23:20:17 2005 From: ahaas at airmail.net (Art Haas) Date: Thu, 2 Jun 2005 16:20:17 -0500 Subject: [PythonCAD] Patch for DS1-R25 bugs In-Reply-To: <20050602210924.GC14121@artsapartment.org> References: <20050602210924.GC14121@artsapartment.org> Message-ID: <20050602212017.GD14121@artsapartment.org> On Thu, Jun 02, 2005 at 04:09:24PM -0500, Art Haas wrote: > Hi. > > I'm going to post this patch to the website as well as the mailing list. > The patch contains two trivial fixes for the twenty-fifth releases. > [ ... snip ... ] The patch is now also available on the download web page below the links for the twenty-fifth release. 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 michele.petrazzo at unipex.it Fri Jun 3 10:09:13 2005 From: michele.petrazzo at unipex.it (Michele Petrazzo) Date: Fri, 03 Jun 2005 10:09:13 +0200 Subject: [PythonCAD] R25 bug In-Reply-To: <20050602193702.GB14121@artsapartment.org> References: <42975FF8.40108@unipex.it> <20050602133015.GB23906@artsapartment.org> <20050602193702.GB14121@artsapartment.org> Message-ID: <42A01029.7040101@unipex.it> Art Haas wrote: > On Thu, Jun 02, 2005 at 08:30:15AM -0500, Art Haas wrote: > >>> - I draw an object (line, circle, etc..), I select move (one of >>> the three), I select the first point to move, the second and >>> after I select no objects then the program ask me for select an >>> object (I click two times into the canvas). After I re-click for >>> the distance (first and second point), but now I click over the >>> object, and I receive this error: [ ... snip ... ] >> >> I'll try and track this down today. >> >> After making the release last week I went out of town and was away >> from my computer. > > > I just looked at this and things work here. I drew a segment, then > went to 'Modify' -> 'Move' -> 'Horizontal' (my arbitrary choice), > clicked in the drawing area once to define the start point for > defining the distance, then clicked again to define the second point > and thus the distance, and then clicked on the segment and it moved > correctly. I guess I'm not duplicating the steps exactly. For reproduce the error, you don't have to select the object then you want to move the object. Try to think that a user, for an error, don't select an object (so it select no objects) when he want to move an object. You have to do the move operation two times, so: select move, select the first point to move, the second point (for distance), select the start point for the rectangle (into a point where are no objects), select the second point of the rect (where are no objects), so you have create a rectangle where no objects are present (so don't select any object!), after try to move the same object, but now when the program ask you to select an object, you have to select the object, but the program don't move it, and an error appear. I hope you understand my explain. :) Michele From w.knol at niwa.co.nz Fri Jun 3 14:01:40 2005 From: w.knol at niwa.co.nz (Wilbert Knol) Date: Sat, 4 Jun 2005 00:01:40 +1200 Subject: [PythonCAD] R25 bug In-Reply-To: <42975FF8.40108@unipex.it> References: <42975FF8.40108@unipex.it> Message-ID: <200506040001.40962.w.knol@niwa.co.nz> On Sat, 28 May 2005 05:59, Michele Petrazzo wrote: > - I draw an object (line, circle, etc..), I select move (one of the > three), I select the first point to move, the second and after I select > no objects then the program ask me for select an object (I click two > times into the canvas). After I re-click for the distance (first and > second point), but now I click over the object, and I receive this error: Well spotted. I see the same thing here. First time I move an empty selection. All is well. Nothing gets moved (as expected). Now, when I try to move an object, I get the 'list index out of range' error: Traceback (most recent call last): File "/home/wk/src/PythonCAD-DS1-R25/PythonCAD/Interface/Gtk/gtkimage.py", line 127, in da_general_event event, _tool) File "/home/wk/src/PythonCAD-DS1-R25/PythonCAD/Interface/Gtk/gtkmodify.py", line 109, in move_end_button_press_cb move_objects(gtkimage, _objlist, tool) File "/home/wk/src/PythonCAD-DS1-R25/PythonCAD/Interface/Gtk/gtkmodify.py", line 83, in move_objects PythonCAD.Generic.move.move_objects(_active_layer, objlist, _dx, _dy) File "/home/wk/src/PythonCAD-DS1-R25/PythonCAD/Generic/move.py", line 339, in move_objects _move_point(layer, _obj, _dx, _dy) File "/home/wk/src/PythonCAD-DS1-R25/PythonCAD/Generic/move.py", line 74, in _move_point layer.addObject(_np) File "/home/wk/src/PythonCAD-DS1-R25/PythonCAD/Generic/layer.py", line 427, in addObject obj.setParent(self) File "/home/wk/src/PythonCAD-DS1-R25/PythonCAD/Generic/entity.py", line 305, in setParent Entity.addChild(parent, self) File "/home/wk/src/PythonCAD-DS1-R25/PythonCAD/Generic/entity.py", line 345, in addChild self.modified() File "/home/wk/src/PythonCAD-DS1-R25/PythonCAD/Generic/entity.py", line 212, in modified self.sendMessage('modified') File "/home/wk/src/PythonCAD-DS1-R25/PythonCAD/Generic/message.py", line 114, in sendMessage _method(self, *args) File "/home/wk/src/PythonCAD-DS1-R25/PythonCAD/Generic/image.py", line 1019, in _objectModified _undo[_i].append((_pid, _oid)) IndexError: list index out of range I am using DS1-R25 with Art's latest patch. Wilbert Knol. From ahaas at airmail.net Fri Jun 3 16:58:34 2005 From: ahaas at airmail.net (Art Haas) Date: Fri, 3 Jun 2005 09:58:34 -0500 Subject: [PythonCAD] R25 bug In-Reply-To: <200506040001.40962.w.knol@niwa.co.nz> References: <42975FF8.40108@unipex.it> <200506040001.40962.w.knol@niwa.co.nz> Message-ID: <20050603145834.GH14121@artsapartment.org> On Sat, Jun 04, 2005 at 12:01:40AM +1200, Wilbert Knol wrote: > On Sat, 28 May 2005 05:59, Michele Petrazzo wrote: > > > - I draw an object (line, circle, etc..), I select move (one of the > > three), I select the first point to move, the second and after I select > > no objects then the program ask me for select an object (I click two > > times into the canvas). After I re-click for the distance (first and > > second point), but now I click over the object, and I receive this error: > > Well spotted. I see the same thing here. First time I move an empty selection. > All is well. Nothing gets moved (as expected). Now, when I try to move an > object, I get the 'list index out of range' error: > [ ... snip backtrace ... ] I've duplicated this now. I believe the root of this problem is that the first selection doesn't return any entities. Today's challenge for me is to fix this. 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 Sat Jun 4 15:10:10 2005 From: ahaas at airmail.net (Art Haas) Date: Sat, 4 Jun 2005 08:10:10 -0500 Subject: [PythonCAD] RPM packages for twenty-fifth release available Message-ID: <20050604131010.GB32229@artsapartment.org> Hi. D. Scott Barninger has provided RPMs for the latest release. These packages have the patch fixing the 'Truee' typo and the ComboBox issue has been applied to these packages. 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 Mon Jun 6 20:30:27 2005 From: ahaas at airmail.net (Art Haas) Date: Mon, 6 Jun 2005 13:30:27 -0500 Subject: [PythonCAD] R25 bug In-Reply-To: <20050603145834.GH14121@artsapartment.org> References: <42975FF8.40108@unipex.it> <200506040001.40962.w.knol@niwa.co.nz> <20050603145834.GH14121@artsapartment.org> Message-ID: <20050606183027.GE32229@artsapartment.org> On Fri, Jun 03, 2005 at 09:58:34AM -0500, Art Haas wrote: > On Sat, Jun 04, 2005 at 12:01:40AM +1200, Wilbert Knol wrote: > > On Sat, 28 May 2005 05:59, Michele Petrazzo wrote: > > > > > - I draw an object (line, circle, etc..), I select move (one of the > > > three), I select the first point to move, the second and after I select > > > no objects then the program ask me for select an object (I click two > > > times into the canvas). After I re-click for the distance (first and > > > second point), but now I click over the object, and I receive this error: > > > > Well spotted. I see the same thing here. First time I move an empty selection. > > All is well. Nothing gets moved (as expected). Now, when I try to move an > > object, I get the 'list index out of range' error: > > [ ... snip backtrace ... ] > > I've duplicated this now. I believe the root of this problem is that the first > selection doesn't return any entities. Today's challenge for me is to > fix this. It turned out to be _today's_ challenge instead of Friday as other things needed doing over the weekend. Here's a patch to try. The problem was in the Image class and the counter used to track what actions get placed in the undo stack. In the case above no objects were selected, so nothing moved, but the count was incremented anyway, leading to an IndexError exception. By setting the count variable to the length of the undo array this problem is resolved. I suspect this bug could have been tripped in numerous other routines, so the fix below, if it is indeed all that is needed, is a nice improvement. Try it out and let me know if it works for you. It worked for me, so it must be right, right? :-) Art Index: PythonCAD/Generic/image.py =================================================================== --- PythonCAD/Generic/image.py (revision 1865) +++ PythonCAD/Generic/image.py (revision 1868) @@ -1354,7 +1354,7 @@ if not self.__busy: raise ValueError, "Image not in busy state" self.__busy = False - self.__action = self.__action + 1 + self.__action = len(self.__undo) def inAction(self): """Test if the Image is with a startAction()/endAction() operation. -- 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 w.knol at niwa.co.nz Tue Jun 7 00:51:37 2005 From: w.knol at niwa.co.nz (Wilbert Knol) Date: Tue, 7 Jun 2005 10:51:37 +1200 Subject: [PythonCAD] R25 bug In-Reply-To: <20050606183027.GE32229@artsapartment.org> References: <42975FF8.40108@unipex.it> <20050603145834.GH14121@artsapartment.org> <20050606183027.GE32229@artsapartment.org> Message-ID: <200506071051.38371.w.knol@niwa.co.nz> Sure enough, the latest patch (below), as applied against DS1-R25, fixes the 'list index out of range' bug. Well done. Wilbert. -- > Here's a patch to try. The problem was in the Image class and the > counter used to track what actions get placed in the undo stack. In > the case above no objects were selected, so nothing moved, but the > count was incremented anyway, leading to an IndexError exception. > By setting the count variable to the length of the undo array this > problem is resolved. > > I suspect this bug could have been tripped in numerous other > routines, so the fix below, if it is indeed all that is needed, is > a nice improvement. Try it out and let me know if it works for you. > It worked for me, so it must be right, right? :-) > > Art > > Index: PythonCAD/Generic/image.py > =================================================================== > --- PythonCAD/Generic/image.py (revision 1865) > +++ PythonCAD/Generic/image.py (revision 1868) > @@ -1354,7 +1354,7 @@ > if not self.__busy: > raise ValueError, "Image not in busy state" > self.__busy = False > - self.__action = self.__action + 1 > + self.__action = len(self.__undo) > > def inAction(self): > """Test if the Image is with a startAction()/endAction() > operation. From ahaas at airmail.net Tue Jun 7 02:17:50 2005 From: ahaas at airmail.net (Art Haas) Date: Mon, 6 Jun 2005 19:17:50 -0500 Subject: [PythonCAD] R25 bug In-Reply-To: <200506071051.38371.w.knol@niwa.co.nz> References: <42975FF8.40108@unipex.it> <20050603145834.GH14121@artsapartment.org> <20050606183027.GE32229@artsapartment.org> <200506071051.38371.w.knol@niwa.co.nz> Message-ID: <20050607001750.GA4410@artsapartment.org> On Tue, Jun 07, 2005 at 10:51:37AM +1200, Wilbert Knol wrote: > Sure enough, the latest patch (below), as applied against DS1-R25, > fixes the 'list index out of range' bug. Well done. > [ ... snip ... ] Good to know the patch worked for you. Thanks. 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 Wed Jun 15 18:29:09 2005 From: ahaas at airmail.net (Art Haas) Date: Wed, 15 Jun 2005 11:29:09 -0500 Subject: [PythonCAD] Handling exceptions in sendMessage() calls Message-ID: <20050615162909.GA31997@artsapartment.org> Hi. Last month I send an e-mail to the list about the problem of dealing with exceptions during sendMessage() calls. After trying various ideas and seeing flaws in them, and thinking more about the problem, my latest conclusion is that the exceptions raised during sendMessage() calls cannot be handled given the current design of the messaging system. What I'm looking at doing is utilizing the traceback module to print out the stack trace but not raise the exception after that so things continue going along. In the 'message.py' file I've added a try/except clause looking something like this: try: method(self, *args) except: traceback.print_exc() The lack of a 'raise' statement in the except block means the exception is "handled" there, although in reality all that is done is print out where things went boom. I'm now trying to decide what can or should be done to indicate that the drawing is in an inconsistent state. Depending on where the exception happened, the drawing itself is fine, as would be the case if a draw() operation failed. On the other hand, things could be really screwed up. I'm not sure what to do just yet. Suggestions? 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 Fri Jun 17 02:28:40 2005 From: ahaas at airmail.net (Art Haas) Date: Thu, 16 Jun 2005 19:28:40 -0500 Subject: [PythonCAD] SVN repo temporarily down Message-ID: <20050617002840.GM31997@artsapartment.org> Hi. I'm trying to update the Apache and Subversion binaries but have hit a snag. The repo may be offline for a day or two. Sorry about this ... 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 Fri Jun 17 22:40:23 2005 From: ahaas at airmail.net (Art Haas) Date: Fri, 17 Jun 2005 15:40:23 -0500 Subject: [PythonCAD] SVN repo back online and other notes about development Message-ID: <20050617204023.GS31997@artsapartment.org> Hi. It's back. During the downtime I converted my repository from Berkeley DB format to the newer 'fsfs' format, something I've wanted to do for quite some time as dealing with the Berkeley DB libraries has produced occasional hiccups. Those problems should now be gone, and as I've heard nothing but good reports of 'fsfs' based Subversion repositories I'm hopeful that things are smooth sailing from here through the foreseeable future. While on the subject of the public repository, I'm becoming interested in replacing Subversion with 'git', the new source code tracker developed by Linus to replace BitKeeper. I liked BitKeeper, and the decentralized development model is also a model that appeals more and more to me. BitKeeper, however, was proprietary and my fear was that the company would be bought and then BK would no longer be available, trapping projects in the BK format. When the BK/Linux divorce happened I was surprised about why it happened, but I believed that the kernel data stored in BK would be extracted because some people or company would put up the money to buy the needed BK license. Aside from the proprietary nature of BK, the program was taxing to run on older machines, especially as the ChangeSet file grew larger. Now that BK is only available with a license I would not consider it at all. Git, on the other hand, is free, runs fantastically well on older hardware, and as it is being used to maintain the kernel source code I know that git itself will have some of the sharpest developers around keeping it running in top fashion. Git code will almost certainly run on any Linux variant, as well as the different BSD flavors, and probably OS X, so I don't suspect any developer on these platforms would have a problem getting, building, and installing the various 'git' programs. So, why replace Subversion with a brand new source code management system? Subversion has worked fine for PythonCAD, and there is no reason to believe that it would not work for future development. 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. 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. There are certainly other reasons that can explain why a regular development team has not appeared, and I want that to change. A distributed development system like that BK, and now git, made possible offers a possible route to making more people interested in contributing to PythonCAD. Subversion itself does not support this type of development model, but the 'svk' package extends Subversion in this direction. I've never used 'svk', so I cannot comment on its strengths and weaknesses. I've not made up my mind yet when, or if, the switch to 'git' will happen. I'd want to convert the repository to 'git', but at present there is not a svn2git converter. I am very serious about trying to draw more developers in to work on PythonCAD, and want to make some changes to see that happen. Maybe moving the master repository on the the publicly accessible machine and offering write-privledges could be a better short-term or long-term plan. Still, a single master repository has the drawbacks that if that machine is offline it hinders people from committing changes, where the 'git' based model you have the repository on your machine, commit locally, and then send your changes out to others. Comments welcomed with regards to switching to git and for drawing more developers into PythonCAD. 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 Sat Jun 18 02:06:28 2005 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Fri, 17 Jun 2005 17:06:28 -0700 Subject: [PythonCAD] other notes about development In-Reply-To: <20050617204023.GS31997@artsapartment.org> References: <20050617204023.GS31997@artsapartment.org> Message-ID: <200506171706.29021.ewilhelm@sbcglobal.net> # 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. >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. >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. 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!) 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. --Eric -- "If you only know how to use a hammer, every problem begins to look like a nail." --Richard B. Johnson --------------------------------------------- http://scratchcomputing.com --------------------------------------------- From ahaas at airmail.net Sat Jun 18 15:38:56 2005 From: ahaas at airmail.net (Art Haas) Date: Sat, 18 Jun 2005 08:38:56 -0500 Subject: [PythonCAD] other notes about development In-Reply-To: <200506171706.29021.ewilhelm@sbcglobal.net> References: <20050617204023.GS31997@artsapartment.org> <200506171706.29021.ewilhelm@sbcglobal.net> Message-ID: <20050618133856.GB25478@artsapartment.org> 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 From pachi at mmn-arquitectos.com Mon Jun 20 13:03:32 2005 From: pachi at mmn-arquitectos.com (Rafael Villar Burke) Date: Mon, 20 Jun 2005 13:03:32 +0200 Subject: [PythonCAD] other notes about development In-Reply-To: <20050618133856.GB25478@artsapartment.org> References: <20050617204023.GS31997@artsapartment.org> <200506171706.29021.ewilhelm@sbcglobal.net> <20050618133856.GB25478@artsapartment.org> Message-ID: <42B6A284.9070107@mmn-arquitectos.com> 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 From ahaas at airmail.net Mon Jun 20 17:55:19 2005 From: ahaas at airmail.net (Art Haas) Date: Mon, 20 Jun 2005 10:55:19 -0500 Subject: [PythonCAD] other notes about development In-Reply-To: <42B6A284.9070107@mmn-arquitectos.com> References: <20050617204023.GS31997@artsapartment.org> <200506171706.29021.ewilhelm@sbcglobal.net> <20050618133856.GB25478@artsapartment.org> <42B6A284.9070107@mmn-arquitectos.com> Message-ID: <20050620155519.GH25478@artsapartment.org> On Mon, Jun 20, 2005 at 01:03:32PM +0200, Rafael Villar Burke wrote: > Art Haas wrote: > > > [ ... snip ... ] > > 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. I've not commited myself to switching to 'git' yet, and any change that would it harder for people to someone to contribute to PythonCAD I want to avoid. Making the master code repository public could entice more people to help out, but there is no guarantee that will happen. > 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... I've seen a bit about Mercurial when I read the 'git' development list, but not much about Bazaar-NG. > > [ ... snip ... ] > > > >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...). I realize that many potential PythonCAD users are currently not using Linux/BSD, so having them switch from their current CAD package will not be easy. The fact that PythonCAD is somewhat cross-platform is certainly a plus, and the points you make about Python itself are definitely true. > > >>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!). I'd love to get more feedback from users, especially on the mailing list. Comments posted to the list can produce replies from many people, as well act as an encouragement to try new approaches in resolving the questions/problems in the original message. > 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. As the GTK+ interface is currently the only active interface being developed, somewhat to my disappointment, there can be a case made that the design of the program discourages developers. If PythonCAD was to solely be a PyGTK/GTK+ program then the generic messaging system could be replaced with Glib's gobject signal approach. I still believe that in the long run seperating the program into an interface-neutral core and interface-specific UI is the best approach for development. Some of the missing features in the standard PyGTK/GTK+ are made visible - printing for example - where in other environments like PyQT/PyKDE there is built in functionality for printing. If a single person or group decided to contribute a PyQT/PyKDE front end I would do everything I could to make things easy for him/her/them to contribute and maintain that code, plus I am certain the new code would expose weakness in the core code that, once made visible, could be rectified. The end result is a better program all around, regardless of the interface. > > > >>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. I'll add a 'TODO' file in the next release. > > [ ... snip ... ] > > > >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... My background is mechanical engineering, so I may share some of those biases. The first company I worked for after leaving college made oil field equipment, and there were a few times that ellipse and spline entities were in the drawings. Hatching, though, was essential. For people doing architectural drawings I'd imaging hatching and splines would be common. > >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. The ability to import an existing drawing into PythonCAD is essential, and ideally this should be transparent to the user. Exporting can be done by saving the file in the normal XML format and then a stand-alone converting utility be invoked, but it would be really nice to save directly into the desired format. > >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. These linetypes are in the program now, but I want to make it easy for people to define their own linetypes and styles if they wish. This feature though is a lower priority than others listed here. > >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... Over the last couple of days I've been adding code to the core files which will help with drawing. A short discussion at the end of message will follow. > >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. Anyone care to start a PythonCAD documentation project? :-) > >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. The changes in the last few days utilize two new messages 'change_pending' and 'change_complete'. The 'change_pending' message is sent in the startChange() method, and 'change_complete' in, oddly enough, endChange(). Here's an example of how they are used. The simplified setThickness() routine again is useful, and here is how it had been written: setThickness(self, t): _ot = self.__thickness if abs(_ot - t) > 1e-10: self.__thickness = t self.sendMessage('thickness_changed', _ot) self.modified() # sends 'modified' message So, when some entity has the thickness adjusted, the 'thickness_changed' message goes out, then 'modified' is sent. Notice all these messages happen after the actual value is changed. So, if my plans are to erase the entity and redraw it with the new thickness, I'd have to listen for 'thickness_changed' messages, and when receiving that message use the old value to perform the erase operation, then perform the draw with the newly adjusted thickness. This is simple enough, but consider that there are many entity types, and complex entities like dimensions send out many different messages regarding changed values. It would become a maintenence nightmare trying to listen for all the different 'changed' type messages. Here is how things now look with the startChange() and endChange() calls: setThickness(self, t): _ot = self.__thickness if abs(_ot - t) > 1e-10: self.startChange('thickness_changed') self.__thickness = t self.endChange('thickness_changed') self.sendMessage('thickness_changed', _ot) self.modified() # sends 'modified' message The startChange() call sends the 'change_pending' message, as well as the message the object will send once the change is complete. What the program will listen for initially is just the 'change_pending' message. So, when receiving this message, the entity is still in its unchanged state, so the erase() operation can be performed while the entity values match what the last draw() operation saw, so erasing the object from the image should not leave any ghost pixels. The big win, however, is that the program only needs to listen for 'change_pending' messages from any entity instead of the many various 'changed' type messages. This enormous simplification greatly eases the burden of handing erase and draw operations. The endChange() call currently is a complement to startChange(), but I don't see it being used at first. It does offer a bit of info to any object listening for 'change_complete' in that the entity sending the message has finished adjusting whatever values were to be changed. > 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... :) A 'perfect' program would never get publically released, or privately finished. > >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... The old chicken-and-egg problem in action ... > Thanks for your work and your perseverance. Thanks. 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 Fri Jun 24 18:23:15 2005 From: ahaas at airmail.net (Art Haas) Date: Fri, 24 Jun 2005 11:23:15 -0500 Subject: [PythonCAD] Apache and Subversion updated Message-ID: <20050624162315.GG25478@artsapartment.org> Hi. The programs were updated this morning, and things look like they are working correctly. Also the transition from the Berkeley DB storage to the 'fsfs' storage has been seemingly transparent and working without any problems. Sorry to say there have been no new additions to the repo as I've been unproductive above and beyond the call of duty this week. Bleah ... 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 richley at onion-switch.com Tue Jun 28 14:02:36 2005 From: richley at onion-switch.com (Ed Richley) Date: Tue, 28 Jun 2005 08:02:36 -0400 Subject: [PythonCAD] R26 and stretching Message-ID: <200506281202.j5SC2b6G015674@localhost.localdomain> Hi: I just got R26 up and running. I was drawing some parts, and noticed something odd. Bearing in mind that I usually use PythonCAD with numeric input (I don't use the mouse to enter coordinates; I usually specify them accurately with numeric entry), I can't stretch things. I tried Horizontal and Vertical and they both don't work. Stretching with mouse coordinates works fine, but not with numeric input. Also, "Move" works fine with both. Anybody else notice this? Otherwise, things seem great. Much improved from a few months ago. Ed From ahaas at airmail.net Tue Jun 28 20:46:33 2005 From: ahaas at airmail.net (Art Haas) Date: Tue, 28 Jun 2005 13:46:33 -0500 Subject: [PythonCAD] R26 and stretching In-Reply-To: <200506281202.j5SC2b6G015674@localhost.localdomain> References: <200506281202.j5SC2b6G015674@localhost.localdomain> Message-ID: <20050628184633.GH2264@artsapartment.org> On Tue, Jun 28, 2005 at 08:02:36AM -0400, Ed Richley wrote: > > Hi: > > I just got R26 up and running. > > I was drawing some parts, and noticed something odd. > > Bearing in mind that I usually use PythonCAD with numeric input > (I don't use the mouse to enter coordinates; I usually specify > them accurately with numeric entry), I can't stretch things. > I tried Horizontal and Vertical and they both don't work. > > Stretching with mouse coordinates works fine, but not with > numeric input. Also, "Move" works fine with both. > > Anybody else notice this? The stretch operations have been the routines for handling entry-box data input. I guess that I started adding them, got sidetracked in some manner, and never finished the process. I'll take a shot at finishing things up. For reference, look at the 'gtkmodify.py' file and look for the code handling stretch operations. The bits of code for handling the 'entry_event' are commented out. > Otherwise, things seem great. Much improved from a few months > ago. That's very good news to hear. 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 Jun 28 21:01:18 2005 From: ahaas at airmail.net (Art Haas) Date: Tue, 28 Jun 2005 14:01:18 -0500 Subject: [PythonCAD] R26 and stretching In-Reply-To: <20050628184633.GH2264@artsapartment.org> References: <200506281202.j5SC2b6G015674@localhost.localdomain> <20050628184633.GH2264@artsapartment.org> Message-ID: <20050628190118.GI2264@artsapartment.org> On Tue, Jun 28, 2005 at 01:46:33PM -0500, Art Haas wrote: > On Tue, Jun 28, 2005 at 08:02:36AM -0400, Ed Richley wrote: > > > > Hi: > > > > I just got R26 up and running. > > > > I was drawing some parts, and noticed something odd. > > > > Bearing in mind that I usually use PythonCAD with numeric input > > (I don't use the mouse to enter coordinates; I usually specify > > them accurately with numeric entry), I can't stretch things. > > I tried Horizontal and Vertical and they both don't work. > > > > Stretching with mouse coordinates works fine, but not with > > numeric input. Also, "Move" works fine with both. > > > > Anybody else notice this? > > The stretch operations have been the routines for handling entry-box ^ missing > data input. I guess that I started adding them, got sidetracked in some > manner, and never finished the process. I'll take a shot at finishing > things up. For reference, look at the 'gtkmodify.py' file and look for > the code handling stretch operations. The bits of code for handling > the 'entry_event' are commented out. Now the paragraph makes a little more sense ... 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 Jun 28 21:29:38 2005 From: ahaas at airmail.net (Art Haas) Date: Tue, 28 Jun 2005 14:29:38 -0500 Subject: [PythonCAD] R26 and stretching In-Reply-To: <200506281202.j5SC2b6G015674@localhost.localdomain> References: <200506281202.j5SC2b6G015674@localhost.localdomain> Message-ID: <20050628192938.GJ2264@artsapartment.org> On Tue, Jun 28, 2005 at 08:02:36AM -0400, Ed Richley wrote: > > (I don't use the mouse to enter coordinates; I usually specify > them accurately with numeric entry), I can't stretch things. > I tried Horizontal and Vertical and they both don't work. > > Stretching with mouse coordinates works fine, but not with > numeric input. Also, "Move" works fine with both. > I've added the missing 'entry_event' handling code now. People getting the PythonCAD code from SVN can just do an 'svn update' to get the code, or you can apply this patch: Index: PythonCAD/Interface/Gtk/gtkmodify.py =================================================================== --- PythonCAD/Interface/Gtk/gtkmodify.py (revision 1863) +++ PythonCAD/Interface/Gtk/gtkmodify.py (revision 1916) @@ -388,14 +388,25 @@ _x1 = tool.popObject() tool.setDistance((_x - _x1), 0.0) gtkimage.setPrompt("Select the points to move.") - # tool.delHandler("entry_event") + tool.delHandler("entry_event") tool.setHandler("button_press", stretch_elem_button_press_cb) return True +def stretch_horiz_entry_event(gtkimage, widget, tool): + _entry = gtkimage.getEntry() + _text = _entry.get_text() + _entry.delete_text(0,-1) + if len(_text): + _dist = util.get_float(eval(_text, gtkimage.getImageVariables())) + tool.setDistance(_dist, 0.0) + gtkimage.setPrompt("Select the points to move.") + tool.setHandler("button_press", stretch_elem_button_press_cb) + tool.delHandler("entry_event") + def stretch_horizontal_init(tool): tool.initialize() tool.setHandler("button_press", stretch_horiz_button_press_cb) - # tool.setHandler("entry_event", stretch_horiz_entry_event) + tool.setHandler("entry_event", stretch_horiz_entry_event) # # stretch vertical @@ -414,14 +425,25 @@ _x1 = tool.popObject() tool.setDistance(0.0, (_y - _y1)) gtkimage.setPrompt("Select the points to move.") - # tool.delHandler("entry_event") + tool.delHandler("entry_event") tool.setHandler("button_press", stretch_elem_button_press_cb) return True +def stretch_vert_entry_event(gtkimage, widget, tool): + _entry = gtkimage.getEntry() + _text = _entry.get_text() + _entry.delete_text(0,-1) + if len(_text): + _dist = util.get_float(eval(_text, gtkimage.getImageVariables())) + tool.setDistance(0.0, _dist) + gtkimage.setPrompt("Select the points to move.") + tool.setHandler("button_press", stretch_elem_button_press_cb) + tool.delHandler("entry_event") + def stretch_vertical_init(tool): tool.initialize() tool.setHandler("button_press", stretch_vert_button_press_cb) - # tool.setHandler("entry_event", stretch_horiz_entry_event) + tool.setHandler("entry_event", stretch_vert_entry_event) # # split objects into two pieces or at intersection points -- 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 Thu Jun 30 21:14:28 2005 From: ahaas at airmail.net (Art Haas) Date: Thu, 30 Jun 2005 14:14:28 -0500 Subject: [PythonCAD] Stretch/Move operations and keyboard input Message-ID: <20050630191428.GJ2253@artsapartment.org> Hi. I've added some entry-event handling code that allows you to define the distance in an two-point move operation from the entry box at the bottom of the screen. After selecting the 'Two-point Move' menu the prompt reads 'Click in the drawing area or enter the x and y distances'. You must specify both the x and y values at the same time, and you do this either as two values separated by a comma like '20.5, 40.5', or you can enter the values in tuple form like (20.5, 40.5). Don't put the tuple in quotes, however. Also, the ability to do an x/y stretch operation has been missing, but no longer. The 'Two-point Stretch' menu now works, and like the similar two-point move you can specify the stretch distance either with two mouse clicks or via the entry box. If you're getting the code via Subversion just do 'svn update' and you'll get these changes. 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