From ahaas at airmail.net Sat Oct 1 02:16:41 2005 From: ahaas at airmail.net (Art Haas) Date: Fri, 30 Sep 2005 19:16:41 -0500 Subject: [PythonCAD] Back online at home again Message-ID: <20051001001641.GB17445@artsapartment.org> Hi. I'm happy to once again have an internet connection at my house, so things regarding PythonCAD should start picking up again in the next week. I'm almost certain to make a release of some sort by the end of October as far too many months have gone by without a proper 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 gossner at arcom.com.au Sun Oct 2 02:53:56 2005 From: gossner at arcom.com.au (Peter Gossner) Date: Sun, 2 Oct 2005 10:23:56 +0930 Subject: [PythonCAD] Back online at home again In-Reply-To: <20051001001641.GB17445@artsapartment.org> References: <20051001001641.GB17445@artsapartment.org> Message-ID: <20051002102356.5c745ba5@node1.kitchen.tux> On Fri, 30 Sep 2005 19:16:41 -0500 Art Haas tapped out: > Hi. > > I'm happy to once again have an internet connection at my house, so > things regarding PythonCAD should start picking up again in the next > week. I'm almost certain to make a release of some sort by the end of > October as far too many months have gone by without a proper 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 > _______________________________________________ > PythonCAD mailing list > PythonCAD at python.org > http://mail.python.org/mailman/listinfo/pythoncad Congratulations Art. Well done. -- Your Fortune Cookie: Q: Why haven't you graduated yet? A: Well, Dad, I could have finished years ago, but I wanted my dissertation to rhyme. Pete < http://www.gnu.org/software/tetum/ > < pete.gossner at gmail.com > From ahaas at airmail.net Mon Oct 3 18:30:16 2005 From: ahaas at airmail.net (Art Haas) Date: Mon, 3 Oct 2005 11:30:16 -0500 Subject: [PythonCAD] Subversion binary upgraded Message-ID: <20051003163016.GE28510@artsapartment.org> Hi. I've updated the Subversion binary on the machine hosting the public repository. There are no new changes in the repository itself. 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 sdb at cloud9.net Thu Oct 13 16:35:31 2005 From: sdb at cloud9.net (Stuart Brorson) Date: Thu, 13 Oct 2005 10:35:31 -0400 (EDT) Subject: [PythonCAD] Greetings and questions about patches! Message-ID: <20051013143531.54ED42AA07@earl-grey.cloud9.net> Hello PythonCADsters -- I downloaded PythonCAD (release 25) a couple of days ago and have been playing with it since then. I have been looking for a good 2D drafting package for a while, and PythonCAD seems to fit the bill! Great work! I have previously checked out QCad, and have rejected it for a couple of reasons. I have also checked out BRL-CAD, but it really isn't suited to producing mechanical drawings. While playing with it I discovered a couple of user interface things I would like to change -- hopefully for the better! I will be happy to produce and submit patches to Art should he be interested. Here is what I propose: * I would like to implement a "keyboard in left hand, mouse in right hand" style of driving PythonCAD. Once you have experienced this style of driving a CAD program you realize that it makes using the program a real breeze. I frequently use (and develop for) gEDA/gschem (the GPL'ed electronic CAD suite), and one thing which gschem does very well is allow for this two-handed style of driving. I believe strongly that PythonCAD will benefit from this addition. Implementing this style of driving means that all menu items need to have keyboard menomics. Note that the GTK project distinguishes between keyboard "accelerators" and keyboard "menomics". Accelerators are the one key shortcuts like c for copy. Menomics are (often) multi key ways to activate menu items, such as dbs for the menu item "Draw -> Basic -> segment". They are the underlined letters you see in the menu items. I have already implemented menomics for about 1/2 of the menu items, and I can be done with this work in a few days. I hope you are interested in this patch! Again, I highly recommend this style of driving a complex program! * I would like to add an "escape key" functionality to each action. Currently, there is no way to leave a particular drawing mode and return to an "idle state". That is, when I am finished drawing a two-point line segment, then PythonCAD goes into a mode where it waits for the first point of my next line segmenet. I would prefer if I could hit and have the program go into an "idle" mode where it wasn't waiting while in a particular tool mode. (That is, the tool.reset() fcn would be called when the user hit .) I believe this is the more intuitive behavior than the present one. I have started looking at the code, and belive I can make this happen (i.e. mod the code and submit patches) in a few days also. Assuming you agree that this would be a useful change! * Finally, I would like to create a new top-level menu item, something like "settings" which would hold actions like "zoom", "preferences" and so on. Right now, "zoom" is buried underneath "modify", which doesn't make sense to me, since I think that modify should only apply to the object being drawn. Before I just change the menus willy-nilly, I will be happy to post a proposed menu configuration in .pdf format. Just let me know if you are open to this! I propose these changes because I believe they will make PythonCAD better. I do want to gauge how open you are to patches, however, before I finish the work. Any comments? Stuart http://www.brorson.com/StuartsPage.html From w.knol at niwa.co.nz Fri Oct 14 03:54:37 2005 From: w.knol at niwa.co.nz (Wilbert Knol) Date: Fri, 14 Oct 2005 14:54:37 +1300 Subject: [PythonCAD] Greetings and questions about patches! In-Reply-To: <20051013143531.54ED42AA07@earl-grey.cloud9.net> References: <20051013143531.54ED42AA07@earl-grey.cloud9.net> Message-ID: <200510141454.37777.w.knol@niwa.co.nz> On Friday 14 October 2005 03:35, Stuart Brorson wrote: > * I would like to implement a "keyboard in left hand, mouse in > right hand" style of driving PythonCAD. Once you have experienced > this style of driving a CAD program you realize that it makes using > the program a real breeze. Great idea. This is one of the features of gschem I really like, and it would be good for PythonCAD. Wilbert. From ahaas at airmail.net Fri Oct 14 15:15:38 2005 From: ahaas at airmail.net (Art Haas) Date: Fri, 14 Oct 2005 08:15:38 -0500 Subject: [PythonCAD] Greetings and questions about patches! In-Reply-To: <20051013143531.54ED42AA07@earl-grey.cloud9.net> References: <20051013143531.54ED42AA07@earl-grey.cloud9.net> Message-ID: <20051014131538.GC7408@artsapartment.org> On Thu, Oct 13, 2005 at 10:35:31AM -0400, Stuart Brorson wrote: > Hello PythonCADsters -- > > I downloaded PythonCAD (release 25) a couple of days ago and have been > playing with it since then. I have been looking for a good 2D > drafting package for a while, and PythonCAD seems to fit the bill! > Great work! I have previously checked out QCad, and have rejected it > for a couple of reasons. I have also checked out BRL-CAD, but it > really isn't suited to producing mechanical drawings. > > While playing with it I discovered a couple of user interface things I > would like to change -- hopefully for the better! I will be happy to > produce and submit patches to Art should he be interested. Here is > what I propose: I'm definitely interested! > * I would like to implement a "keyboard in left hand, mouse in right > hand" style of driving PythonCAD. Once you have experienced this > style of driving a CAD program you realize that it makes using the > program a real breeze. I frequently use (and develop for) > gEDA/gschem (the GPL'ed electronic CAD suite), and one thing which > gschem does very well is allow for this two-handed style of driving. > I believe strongly that PythonCAD will benefit from this addition. > > Implementing this style of driving means that all menu items need > to have keyboard menomics. Note that the GTK project distinguishes > between keyboard "accelerators" and keyboard "menomics". Accelerators > are the one key shortcuts like c for copy. Menomics are (often) > multi key ways to activate menu items, such as dbs for the menu > item "Draw -> Basic -> segment". They are the underlined letters you > see in the menu items. > > I have already implemented menomics for about 1/2 of the menu items, > and I can be done with this work in a few days. I hope you are > interested in this patch! Again, I highly recommend this style of > driving a complex program! Having keyboard shortcuts for accessing things could definitely be handy, especially for people familiar with other CAD packages that offered this sort of use. I suspect that adding the mnemonics is mostly a matter of adding underscore characters to the appropriate argument in the gtk.Action instances, but there could be more to do. > * I would like to add an "escape key" functionality to each action. > Currently, there is no way to leave a particular drawing mode and > return to an "idle state". That is, when I am finished drawing a > two-point line segment, then PythonCAD goes into a mode where it waits > for the first point of my next line segmenet. I would prefer if I > could hit and have the program go into an "idle" mode where > it wasn't waiting while in a particular tool mode. (That is, the > tool.reset() fcn would be called when the user hit .) I > believe this is the more intuitive behavior than the present one. > > I have started looking at the code, and belive I can make this happen > (i.e. mod the code and submit patches) in a few days also. Assuming > you agree that this would be a useful change! Pressing 'Esc' should do what you propose now. It is a bug if doing so does not return PythonCAD to the 'Enter Command' mode. I'll take a peek at this and see if things are or are not working properly. > * Finally, I would like to create a new top-level menu item, > something like "settings" which would hold actions like "zoom", > "preferences" and so on. Right now, "zoom" is buried underneath > "modify", which doesn't make sense to me, since I think that modify > should only apply to the object being drawn. I'd put the 'Zoom' menus under the 'Modify' menu because I was thinking that zoom operations "modify" the view of the drawing. The "preferences" menu is in 'Edit' because that is where many programs keep such a choice, though it could also be in an 'Options' menu a-la Firefox. > I propose these changes because I believe they will make PythonCAD > better. I do want to gauge how open you are to patches, however, > before I finish the work. Any comments? I think your ideas all sound great, and I'm open to nearly anything that makes PythonCAD a better program. 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 sdb at cloud9.net Fri Oct 14 17:36:57 2005 From: sdb at cloud9.net (Stuart Brorson) Date: Fri, 14 Oct 2005 11:36:57 -0400 (EDT) Subject: [PythonCAD] Greetings and questions about patches! In-Reply-To: <20051014131538.GC7408@artsapartment.org> from "Art Haas" at Oct 14, 2005 08:15:38 AM Message-ID: <20051014153657.8245C2AA07@earl-grey.cloud9.net> Hi -- > Having keyboard shortcuts for accessing things could definitely be > handy, especially for people familiar with other CAD packages that > offered this sort of use. I suspect that adding the mnemonics is > mostly a matter of adding underscore characters to the appropriate > argument in the gtk.Action instances, but there could be more to do. This is indeed what I am doing. It's not hard. . . . Expect to see it in a day or so. BTW: What's the best way to submit patches? I'll probably just post a .diff.gz to the list, but is there a better way? BTW: The diff is against release 25. I tried to grab the latest using subversion, but svn wouldn't let me. Do I need an acct, or is there an anonymous login? (I am new to svn, but have used CVS previously.) (I typically use "diff -run" from the base directory. I have put comments and stuff into several source files.) > > * I would like to add an "escape key" functionality to each action. [ . . . . . snip . . . . . ] > > Pressing 'Esc' should do what you propose now. It is a bug if doing so > does not return PythonCAD to the 'Enter Command' mode. I'll take a peek > at this and see if things are or are not working properly. Actually, it didn't work on my machine. However, I got it working. For some reason, this line was commented out in the class definition (__init__) for GTKImage: self.__window.connect("event", window_general_event, self) Therefore, key_press events were getting lost. (The __da window was not receiving them, I don't know why.) Perhaps this was due to some debug activity? Or was this an attempt to squish another bug. > I think your ideas all sound great, and I'm open to nearly anything that > makes PythonCAD a better program. Thanks! Expect to see some patches and other stuff over the next few days! Stuart From ahaas at airmail.net Fri Oct 14 18:28:43 2005 From: ahaas at airmail.net (Art Haas) Date: Fri, 14 Oct 2005 11:28:43 -0500 Subject: [PythonCAD] Greetings and questions about patches! In-Reply-To: <20051014153657.8245C2AA07@earl-grey.cloud9.net> References: <20051014131538.GC7408@artsapartment.org> <20051014153657.8245C2AA07@earl-grey.cloud9.net> Message-ID: <20051014162843.GD7408@artsapartment.org> On Fri, Oct 14, 2005 at 11:36:57AM -0400, Stuart Brorson wrote: > Hi -- > > > Having keyboard shortcuts for accessing things could definitely be > > handy, especially for people familiar with other CAD packages that > > offered this sort of use. I suspect that adding the mnemonics is > > mostly a matter of adding underscore characters to the appropriate > > argument in the gtk.Action instances, but there could be more to do. > > This is indeed what I am doing. It's not hard. . . . Expect to > see it in a day or so. > > BTW: What's the best way to submit patches? I'll probably just post > a .diff.gz to the list, but is there a better way? BTW: The diff is > against release 25. I tried to grab the latest using subversion, but > svn wouldn't let me. Do I need an acct, or is there an anonymous > login? (I am new to svn, but have used CVS previously.) It looks like Apache wasn't running. I've logged in, started Apache, and things should be working again. The instructions for getting the code from the repo are on the following page: http://www.pythoncad.org/download.html Here's the command for getting the current code ... $ svn co http://subversion.pythoncad.org:9000/svn/pythoncad/trunk pythoncad You'll get a 'pythoncad' directory with the code and other stuff. If things don't work please let me know. For making diffs, you use 'svn diff' $ svn diff foo.py Subversion will create a diff of 'foo.py'. If you're happy with the diff, you can save the diff like ... $ svn diff foo.py > foo.diff ... and mail it to me. > (I typically use "diff -run" from the base directory. I have put > comments and stuff into several source files.) > > > * I would like to add an "escape key" functionality to each action. > [ . . . . . snip . . . . . ] > > > > Pressing 'Esc' should do what you propose now. It is a bug if doing so > > does not return PythonCAD to the 'Enter Command' mode. I'll take a peek > > at this and see if things are or are not working properly. > > Actually, it didn't work on my machine. However, I got it working. > For some reason, this line was commented out in the class definition > (__init__) for GTKImage: > > self.__window.connect("event", window_general_event, self) > > Therefore, key_press events were getting lost. (The __da window was > not receiving them, I don't know why.) Perhaps this was due > to some debug activity? Or was this an attempt to squish another bug. Off the top of my head I'm not sure ... :-/ > > I think your ideas all sound great, and I'm open to nearly anything that > > makes PythonCAD a better program. > > Thanks! Expect to see some patches and other stuff over the next few > days! Thanks. 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 john_g at cibolo.com Sat Oct 15 00:13:14 2005 From: john_g at cibolo.com (John Griessen) Date: Fri, 14 Oct 2005 17:13:14 -0500 Subject: [PythonCAD] Greetings and questions about patches! In-Reply-To: <20051014153657.8245C2AA07@earl-grey.cloud9.net> References: <20051014153657.8245C2AA07@earl-grey.cloud9.net> Message-ID: <43502D7A.6080000@cibolo.com> Hey, that's great Stuart, I use gschem and PCB and gattrib. Thanks for helping to make a free open mechanical drafting program that works along the lines circuit designers think... with scriptability and productivity, and a data model that is movable groups instead of a pile of disconnected data straws like QCad creates in a DXF haystack. Awright! John Griessen PS Cadvas is python and has a few decent features. Some of the graphical geometry constructions it does are good to just look at, even if you start coding a completely different way... Stuart Brorson wrote: I suspect that adding the mnemonics is >>mostly a matter of adding underscore characters to the appropriate >>argument in the gtk.Action instances, but there could be more to do. > > > This is indeed what I am doing. It's not hard. . . . Expect to > see it in a day or so. From sdb at cloud9.net Mon Oct 17 17:36:40 2005 From: sdb at cloud9.net (Stuart Brorson) Date: Mon, 17 Oct 2005 11:36:40 -0400 Subject: [PythonCAD] PythonCAD changes and documentation Message-ID: <20051017113640.e8pc5wotcgwg84gc@www.mail.cloud9.net> Hello PythonCADsters -- I spent some spare hours on PythonCAD over the last few days. Here's what I did: * I implemented keyboard mnemonics for all actions. You can now use the "keyboard in left hand, mouse in right hand" method to conveniently drive the program. I will e-mail the patches (a diff file) directly to Art. * I created an OpenOffice doc which lists all available actions along with their accelerators, mnemonics, and text commands. Please find the .sxw original along with a .pdf version attached below. Art -- a kindly suggestion: Please create a "doc" directory beneath the main pythoncad directory and put this doc in there. It will hopefully be useful to other PythonCAD newbies. * I fixed the issue with the key. Now, if you are in the middle or end of some action and hit the key, then the program will return to an idle mode, and await the next command. * I also was puzzled by the program's behavior w.r.t. entering normal keystrokes for entering text commands. Previously, the entered text would sometimes go into the Entry box at the bottom of the window, but sometimes a popup Entry box would appear and accept the text. This behavior seemed to be related to which of the window sub-widgets was last activated. I modified the program so that any normal text keystrokes now go only into the Entry field at the bottom of the window. Hopefully, this is the desired behavior. * To help me understand how the UI worked, I created the beginnings of a quasi-UML diagram showing the components of the GTKImage class. I did the drawing using dia; please find the original attached. If desired, I can create a .png. Art -- another kindly suggestion: Please create a subdirectory "development" beneath the "doc" directory, and place this drawing in there. It will hopefully be useful to other newbie developers. And the more help provided to developers, the more developers will (hopefully) show up. In any event, I will add more stuff to the drawing as I learn more about the program. ============================================================= Now for some questions. * I noticed two classes (in gtkshell.py) which seem to be unused: ImageView and ImageWindow. What are these? Are they vestigal classes which are no longer needed? Or are they an as-yet unimplemented feature? * When I save out a drawing, close and restart PythonCAD and try to read in the drawing, I get this error: Failed loading '/home/sdb/TestOfPythonCAD.xml.gz'! /usr/lib/python2.3/site-packages/_xmlplus/parsers/pyexpat.so: undefined symbol: PyUnicodeUCS4_Decode It looks to me like there is a problem with my XML installation. Has anybody else seen this? * Typing in command strings doesn't seem to work. When I type e.g. copy, I get this: Traceback (most recent call last): File "/usr/local/src/pythoncad/PythonCAD/Interface/Gtk/gtkimage.py", line 255, in entry_event eval(_cmd) # this will go away ... File "", line 0, in ? NameError: name 'gtkmenus' is not defined Is this a known problem? I can work on it if desired, but don't want to interfere if somebody else is taking care of this. ================================================================ Other random notes: * I haven't done any re-orgainzation of the menus yet. I may get to that in a few days. * Selection mechanism: It would be nice if you could just click on an object (rather than doing "edit -> select") to select it. Are there any objections to that behavior? Enjoy! I'll be contributing more stuff as time goes on. Stuart -------------- next part -------------- A non-text attachment was scrubbed... Name: PythonCADClassHierarchy.dia Type: application/x-dia-diagram Size: 4701 bytes Desc: not available Url : http://mail.python.org/pipermail/pythoncad/attachments/20051017/7eaf4a21/PythonCADClassHierarchy-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PythonCADActions.sxw Type: application/vnd.sun.xml.writer Size: 9400 bytes Desc: not available Url : http://mail.python.org/pipermail/pythoncad/attachments/20051017/7eaf4a21/PythonCADActions-0001.sxw -------------- next part -------------- A non-text attachment was scrubbed... Name: PythonCADActions.pdf Type: application/pdf Size: 47649 bytes Desc: not available Url : http://mail.python.org/pipermail/pythoncad/attachments/20051017/7eaf4a21/PythonCADActions-0001.pdf From ahaas at airmail.net Mon Oct 17 20:42:20 2005 From: ahaas at airmail.net (Art Haas) Date: Mon, 17 Oct 2005 13:42:20 -0500 Subject: [PythonCAD] PythonCAD changes and documentation In-Reply-To: <20051017113640.e8pc5wotcgwg84gc@www.mail.cloud9.net> References: <20051017113640.e8pc5wotcgwg84gc@www.mail.cloud9.net> Message-ID: <20051017184220.GF12715@artsapartment.org> On Mon, Oct 17, 2005 at 11:36:40AM -0400, Stuart Brorson wrote: > Hello PythonCADsters -- > > I spent some spare hours on PythonCAD over the last few days. Here's > what I did: > > * I implemented keyboard mnemonics for all actions. You can now use > the "keyboard in left hand, mouse in right hand" method to > conveniently drive the program. I will e-mail the patches (a diff > file) directly to Art. > > * I created an OpenOffice doc which lists all available actions along > with their accelerators, mnemonics, and text commands. Please find > the .sxw original along with a .pdf version attached below. > > Art -- a kindly suggestion: Please create a "doc" directory beneath > the main pythoncad directory and put this doc in there. It will > hopefully be useful to other PythonCAD newbies. I'll add a directory for these files. > * I fixed the issue with the key. Now, if you are in the > middle or end of some action and hit the key, then the > program will return to an idle mode, and await the next command. > > * I also was puzzled by the program's behavior w.r.t. entering normal > keystrokes for entering text commands. Previously, the entered text > would sometimes go into the Entry box at the bottom of the window, but > sometimes a popup Entry box would appear and accept the text. This > behavior seemed to be related to which of the window sub-widgets was > last activated. I modified the program so that any normal text > keystrokes now go only into the Entry field at the bottom of the > window. Hopefully, this is the desired behavior. It isn't, but the behavior you describe about the sometimes unexpected keypress handling is not very nice either. When the Layer display on the left has the focus, arrow keys allow the user to select and change the active layer in the drawing. Pressing a letter key allows for selecting a Layer by name. All this is part of the TreeView widget in GTK. What would be ideal would be some clever means of making it obvious where keypress events are handled. If the focus is in the Layer display, and the user wants to enter some commands, then the user should type in a 'Tab' to move the focus to the DrawingArea or the entry box directly. > * To help me understand how the UI worked, I created the beginnings > of a quasi-UML diagram showing the components of the GTKImage class. > I did the drawing using dia; please find the original attached. If > desired, I can create a .png. One of my long-term goals is to remove the GTKImage class and replace it with an ImageView/ImageWindow. See below for more details ... > Art -- another kindly suggestion: Please create a subdirectory > "development" beneath the "doc" directory, and place this drawing in > there. It will hopefully be useful to other newbie developers. And > the more help provided to developers, the more developers will > (hopefully) show up. In any event, I will add more stuff to the > drawing as I learn more about the program. > > Now for some questions. > > * I noticed two classes (in gtkshell.py) which seem to be unused: > ImageView and ImageWindow. What are these? Are they vestigal > classes which are no longer needed? Or are they an as-yet > unimplemented feature? They are unimplemented as yet. As I wrote above, these classes will hopefully be the replacement for the GTKImage class. The GTKImage class uses the Image class as a base class, and while this is a workable design, I've come to believe it is a poor choice. I really want to try and keep a "wall" between the Interface code and the interface neutral core, and GTKImage class pokes holes in that plan. When I first started PythonCAD there was no messaging mechanism in the code, so subclassing objects was my means of bridging the interface/core gap. > * When I save out a drawing, close and restart PythonCAD and try to > read in the drawing, I get this error: > > Failed loading '/home/sdb/TestOfPythonCAD.xml.gz'! > /usr/lib/python2.3/site-packages/_xmlplus/parsers/pyexpat.so: > undefined symbol: PyUnicodeUCS4_Decode > > It looks to me like there is a problem with my XML installation. Has > anybody else seen this? That looks like a Python installation issue as you appear to be missing some shared library. > * Typing in command strings doesn't seem to work. When I type > e.g. copy, I get this: > > Traceback (most recent call last): > File "/usr/local/src/pythoncad/PythonCAD/Interface/Gtk/gtkimage.py", line 255, > in entry_event > eval(_cmd) # this will go away ... > File "", line 0, in ? > NameError: name 'gtkmenus' is not defined > > Is this a known problem? I can work on it if desired, but don't want > to interfere if somebody else is taking care of this. Bug. I'll look at this. > ================================================================ > > Other random notes: > > * I haven't done any re-orgainzation of the menus yet. I may > get to that in a few days. > > * Selection mechanism: It would be nice if you could just click on > an object (rather than doing "edit -> select") to select it. Are > there any objections to that behavior? Allowing this behavior depends on how it is implemented. Going the 'Edit' -> 'Select' route clearly indicates the the program is now in a selection mode. > Enjoy! I'll be contributing more stuff as time goes on. Thanks. 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 sdb at cloud9.net Mon Oct 17 23:36:12 2005 From: sdb at cloud9.net (Stuart Brorson) Date: Mon, 17 Oct 2005 17:36:12 -0400 (EDT) Subject: [PythonCAD] PythonCAD changes and documentation In-Reply-To: <20051017184220.GF12715@artsapartment.org> from "Art Haas" at Oct 17, 2005 01:42:20 PM Message-ID: <20051017213612.3688B2AA07@earl-grey.cloud9.net> [. . . snip! . . . ] > > Other random notes: > > > > * Selection mechanism: It would be nice if you could just click on > > an object (rather than doing "edit -> select") to select it. Are > > there any objections to that behavior? > > Allowing this behavior depends on how it is implemented. Going the > 'Edit' -> 'Select' route clearly indicates the the program is now in > a selection mode. My suggestion: I am thinking about how to indicate that an object is selected. I propose that any and all selected objects change color to something different, e.g. white. This has at least two good features: 1. You can immediately tell that you have selected the objects you wanted to select. 2. It reminds the user that he is in select mode, and has selected something. This answers your issue above. Then, leaving the ability to select on all the time doesn't present a problem. I also propose that if you hit then all selections are cleared. Comments? Meanwhile, I can look at the code to see how this feature might be implemented. . . . . Stuart From sdb at cloud9.net Wed Oct 19 21:16:01 2005 From: sdb at cloud9.net (Stuart Brorson) Date: Wed, 19 Oct 2005 15:16:01 -0400 Subject: [PythonCAD] Next rev of PythonCAD class diagram, and more questions Message-ID: <20051019151600.k975gdhn7k0o4ks0@www.mail.cloud9.net> Hi -- I have been continuing to study PythonCAD so that I can make more changes/improvements. To this end I have added more stuff to my pseudo-UML class diagram. Please find a .pdf copy of the diagram attached. If anybody wants the original Dia file, let me know and I will post it. Art -- Does the class diagram look correct to you? Now for a couple of questions: * I upgraded my installation of Python to 2.4.2 in order to get rid of an XML problem when reading files. Now, however, I get this error message when trying to read in a PythonCAD file: [sdb at Fermat pythoncad-sdb-20051016]$ gtkpycad.py Test.xml.gz Opening 'Test.xml.gz' SDB debug -- initialized another GTKImage class instance. . . SDB debug -- Created another instance of Entity class! SDB debug -- Created another instance of Entity class! Traceback (most recent call last): File "/usr/local/geda/bin/gtkpycad.py", line 350, in ? main() File "/usr/local/geda/bin/gtkpycad.py", line 307, in main _image = GTKImage() File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkimage.py", line 334, in __init__ super(GTKImage, self).__init__() File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/image.py", line 143, in __init__ add_defaults(self) File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/image.py", line 1948, in add_defaults image.setOption('DIM_STYLE', _ds) File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkimage.py", line 606, in setOption super(GTKImage, self).setOption(key, value) File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/image.py", line 1587, in setOption if value != _gval: _set = True File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/dimension.py", line 2228, in __ne__ return not self == obj File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/dimension.py", line 2201, in __eq__ for _key in Dimstyle.__defaults.keys(): NameError: global name 'Dimstyle' is not defined Any ideas about what's wrong? I will look at this myself later, but perhaps one of the gurus here already knows about this. * Art -- further to the point of highlighting selected objects: What are your thoughts on using signals to tell objects to highlight? I guess that if you could write a couple of sentences giving an example how signaling accomplishes actions in PythonCAD (for example, how signaling works when moving an object) then that would help me understand how this should work. I *did* read the documentation you pointed me to, BTW, but still need a little more insight into how it works in PythonCAD. Thanks! * Finally, any progress on the patches I sent in? I'm just curious, not trying to be pushy! Let me know if I can do anything to help! Stuart -------------- next part -------------- A non-text attachment was scrubbed... Name: PythonCADClassHierarchy.pdf Type: application/pdf Size: 14755 bytes Desc: not available Url : http://mail.python.org/pipermail/pythoncad/attachments/20051019/8bb11160/PythonCADClassHierarchy.pdf From ahaas at airmail.net Wed Oct 19 22:36:18 2005 From: ahaas at airmail.net (Art Haas) Date: Wed, 19 Oct 2005 15:36:18 -0500 Subject: [PythonCAD] Next rev of PythonCAD class diagram, and more questions In-Reply-To: <20051019151600.k975gdhn7k0o4ks0@www.mail.cloud9.net> References: <20051019151600.k975gdhn7k0o4ks0@www.mail.cloud9.net> Message-ID: <20051019203618.GN12715@artsapartment.org> On Wed, Oct 19, 2005 at 03:16:01PM -0400, Stuart Brorson wrote: > Hi -- > > I have been continuing to study PythonCAD so that I can make more > changes/improvements. To this end I have added more stuff to my pseudo-UML > class diagram. Please find a .pdf copy of the diagram attached. If anybody > wants the original Dia file, let me know and I will post it. > > Art -- Does the class diagram look correct to you? I'll have to look at it later as I don't have a '.dia' viewer on my primary machine. I think the other machine around here has something that will display those files. > > Now for a couple of questions: > > * I upgraded my installation of Python to 2.4.2 in order to get rid of > an XML problem when reading files. Now, however, I get this error message > when trying > to read in a PythonCAD file: > > [sdb at Fermat pythoncad-sdb-20051016]$ gtkpycad.py Test.xml.gz > Opening 'Test.xml.gz' > [ ... snip ... ] > File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/dimension.py", line > 2201, in __eq__ > for _key in Dimstyle.__defaults.keys(): > NameError: global name 'Dimstyle' is not defined > > Any ideas about what's wrong? I will look at this myself later, but > perhaps one of the gurus here already knows about this. A typo - 'Dimstyle' should be 'DimStyle'. Oops ... [ ... goes to other window ... ] Fixed and checked in. > * Art -- further to the point of highlighting selected objects: What are > your thoughts on using signals to tell objects to highlight? I guess that > if you could write a couple of sentences giving an example how signaling > accomplishes actions in PythonCAD (for example, how signaling works when > moving an object) then that would help me understand how this should work. > I *did* read the documentation you pointed me to, BTW, but still need a > little more insight into how it works in PythonCAD. Thanks! Let me give you a simpler example for the messaging system than moving, partly because moving is somewhat complex and also I'm looking at that code right now and it will probably be changing. Pretend that you want to change the thickness of a segment in a drawing. You select the segment, go to 'Modify' -> 'Change' -> 'Thickness', enter the new thickness, then click the 'OK' button, and if things go according to plan the selected segment(s) will all have the value you specified in the dialog box for their thickness. The code that sets the thickness on segments is in the 'graphicobject.py' file; look for the setThickness() method. A simplified version is below: def setThickness(self, t): ot = self.__thickness if abs(ot - t) > 1e-10: self.__thickness = t self.sendMessage('thickness_changed', ot) self.modified() The real method has some more error checking and bits around the assignment to the 'self.__thickness' value, , but for example purpose what is above will do. First, a simple test is done to determine if the new thickness 't' is different from the original thickness 'ot'. If so, the new thickness value is assigned, then the sendMessage() call is made. The code for sendMessage() is in the 'message.py' file, btw. The sendMessage() call first argument is a text string which gives the type of message being sent, in this case 'thickness_changed'. The second argument is the previous value of the thickness. After the sendMessage() call completes, the modified() method is invoked, and it sends out a 'modified' message - see the code in 'entity.py'. That is all fine and good, but it does not accomplish anything unless some other entities are listening for either 'thickness_changed' and 'modified' messages. In real drawings, the Segment entity will have an associated SegmentLog entity which keeps track of the changes made on the Segment instance. This SegmentLog entity will listen for 'thickness_changed' messages because SegmentLog is a subclass of the GraphicObjectLog class (see the 'segment.py' file), and look at the 'graphicobject.py' file for the GraphicObjectLog methods. In the GraphicObjectLog::__init__() method, you'll see a couple lines where a connect() method call is used, and in particular the one regarding the thickness value is: obj.connect('thickness_changed', self._thicknessChanged) The file where the connect() code is defined is 'message.py'. Now, whenever the Segment instance invokes the sendMessage() call with a 'thickness_changed', message, the _thicknessChanged() method in the GraphicObjectLog class is executed. All that method does is store off the old thickness value in the list of changes that have been applied to the Segment. The pairing of sendMessage('message') and connect('message') calls is the guts of the messaging system. Using this approach for inter-entity communication has worked out well, as it permits the entities to indicate that they have been changed in some way and that any interested party can use this information as is needed, but the changed entity itself doesn't have to know anything about any entities that are listening in via the connect() calls. > * Finally, any progress on the patches I sent in? I'm just curious, > not trying to be pushy! Let me know if I can do anything to help! The patch was applied, and then I've gone in and made further changes to what you sent. For example, the patch to the 'gtkmenu.py' file adding all the underscores for mnemonics is in essentially unchanged, as was the patch to 'prompt.py'. Your patch for 'gtkimage.py' pointed out a bug fix to connecting to the 'self.__entry' gtk.Entry widget, so thanks for spotting and fixing that. You'd wondered why the connect() call to the window_general_event() function was commented out, and after looking at the code I realized that I was just using it for debug purposes, but your earlier mail where you point out that hitting the 'Esc' key was not doing what you expect made me activate the window_general_event() function and have it handle the 'Esc' key, neatly solving the problem. Also, the '.dia', '.pdf', and '.sxw' files are added into the repo. I've been making lots of changes in the code over the last day or two, and while there are still glitches here and there, brave souls can do an 'svn update' and pull the latest changes. Nearly all the changes I've been making deal with handling the recent Quadtree changes allowing multiple entities to be stored with equivalent values. In particular, this change affected the Quadtree find() method, and that call is used in lots of places in the code. In another day or two I'll be more confident that the code has been adjusted correctly to handle the Quadtree change, but for now those wanting to update their repos can do so but expect a few snags here and there. The 'Dimstyle' fix mentioned above is on the repo, too. 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 Oct 20 20:08:38 2005 From: ahaas at airmail.net (Art Haas) Date: Thu, 20 Oct 2005 13:08:38 -0500 Subject: [PythonCAD] New stuff at repository Message-ID: <20051020180838.GD17002@artsapartment.org> Hi. I'd mentioned in an e-mail yesterday that there was new stuff available on the repo, though in a reply to another message. So, here's a short note letting people using Subversion that there is new stuff available. The majority of the changes deal are due to the Quadtree changes from my pre-Katrina work, though there are other things like bug fixes included. Also included are some patches by Stuart Brorson that will be useful for debugging purposes, but the biggie is his patch adding underscore characters to the menus, so activating the menus can be accomplished with keystrokes in addition to the mouse. This is a nice improvement, so my thanks to him for working on it. My note yesterday also said that things in the repo still had a few glitches, and I think I've stomped them with the work I've done today, though doubtlessly others remain. The big hangup yesterday dealt with moving entities, and I've made changes so that the move operations work again, but as I look at the code I find I'm not liking what I see. Expect some reworked move code to appear in the future. I'm still planning to make a release really soon, probably early next week. It has been far too long since the last one. 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 Oct 21 22:32:08 2005 From: ahaas at airmail.net (Art Haas) Date: Fri, 21 Oct 2005 15:32:08 -0500 Subject: [PythonCAD] [ANNOUNCE] Twenty-sixth release of PythonCAD now available Message-ID: <20051021203208.GE17002@artsapartment.org> I'm pleased to announce the twenty-sixth 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 newer. 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 PythonCAD interfaces will depend on the availability of a Python module for that particular interface and developer interest and action. The twenty-sixth release includes a few interface enhancements. More of the menus can be activated from the keyboard, and stretch/move operations now accept entry box values when performing either task. A significant amount of work has been applied to the internal routines used for storing the entities in a drawing, the result of which required numerous changes throughout the code. The primary change was adjusting the Quadtree search and storage routines to handle the case where multiple instances of equivalent entities are stored. In earlier releases of PythonCAD this scenario would result in strange errors if it were to occur. As is always the case, a large number of smaller bug fixes and code enhancements are also present in this release. A 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! 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 sdb at cloud9.net Sat Oct 22 17:06:10 2005 From: sdb at cloud9.net (Stuart Brorson) Date: Sat, 22 Oct 2005 11:06:10 -0400 (EDT) Subject: [PythonCAD] Patches to highlight selected objects Message-ID: <20051022150610.C1C472AA07@earl-grey.cloud9.net> Hi PythonCADsters -- I have made some mods to PythonCAD in order to implement highlighting after selection. That is, my mods change PythonCAD's behavior so that when you select a graphic object, it turns white. This sees to be the desired behavior for selection. I have submitted the patches to Art in a separate e-mail. The diff is against the the latest svn version (updated yesterday -- Friday, Oct 21st, 2005). Please read about the detailed mods and some other discussion points below. Code modifications made: * Changed image.selectObject and image.deselectObject to change object's color upon selection/deselection. Specifically, upon selection the object turns white. * Connected GTKImage to the "color_changed" signal. When it receives the "color_changed" signal, it invokes self.redraw(). * Added getColor and setColor methods to point class. These methods are just dummy methods. Note: this is a hack. I needed to do this so that I'd get no exception in selectObject/deselectObject when trying to set the color of a point. More discussion below. * Modified gtkimage.reset() so that it would invoke deselect.Object the *second* time the user hits . (The first time you hit reset just clears the tool.) * Changed default color for segments and circles to yellow (it was white). This way, when you select an object, it turns white and you can see that it is selected. Note that this is currently a hack -- I just hardcoded the colors into a __default_color variable in each file. Perhaps there is a global config file where this can go? * Changed the local variable "gtkimage" to "_gtkimage" in gtkmenu.py. I did this while tracking a different bug. I thought that the usage of gtkimage as both a file qualifier ("gtkimage.fooMethod()") and as a local variable ("def fooMethod(self, gtkimage)") was causing a problem. I was wrong, but changing this was so much hassle that I left my change standing. My change doesn't hurt anything. * Added more debug printing calls. This helps me figure out what is going on when PythonCAD is running. Discussion: * My method to set the color upon selection/deselection is a hack. This needs to be fixed. I propose that all graphic objects have an attribute __default_color. This can be set in GraphicObject, and overridden in the individual classes. Then, when you select an object, it can go white ("obj.setColor(0xffffff)"). When you deselect an object, it can revert to its normal default color by ("obj.setColor(obj.__default_color)"). * Sending the signal "color_changed" has the problem that it invokes the graphicObjectLog class to store the last color. When doing a highlight, it makes no sense to store the last color. Therefore, I propose to create a different message "highlighted" which will not cause the graphicObjectLog class to wake up. * One issue with the current architecture is that the point class inherits from Subpart, not from Graphic object. The issue is that the color attribute is set in GraphicObject, so a point doesn't have a color, and doesn't have color methods. I overcame this by implementing dummy color methods in the point class, but this is a hack. Is there a reason that point can't inherit from GraphicObject? And what distinction is made between GraphicObject and Subpart and Entity? * After doing this I noticed that "Edit -> Select" doesn't do anything. That is, when you try to move an object, you do "Modify -> Move -> Horizontal", and you thereafter need to select the objects to move. What is the point behind "Edit -> Select" anyway? Does it do anything? I propose that any "Modify" actions should use the selected parts, instead of requiring the user to re-select the parts to modify. Comments on the above? Stuart From sdb at cloud9.net Mon Oct 24 17:06:37 2005 From: sdb at cloud9.net (Stuart Brorson) Date: Mon, 24 Oct 2005 11:06:37 -0400 Subject: [PythonCAD] More stuff -- including 11x17 titleblock Message-ID: <20051024110637.qicd3iq7sw0844c4@www.mail.cloud9.net> Hi Guys -- I did a little more work on PythonCAD over the weekend. In particular, I did two things: 1. I fixed a bug which was causing a segfault (yes -- Python itself died) when importing an image. I will send a quick patch to Art separately. 2. I created a 1:1 scale titleblock drawing for 11x17 paper in landscape orientation. When I make a drawing I like to have a drawing area around my drawing so that I know how big the drawing will be when printed. The titleblock incorporates a boundary with labeled areas to acheive this goal. It looks like a normal titleblock you would see used on any mechanical drawing. The idea is that a user can first input the titleblock, and then draw the rest of his drawing in the drawing area. Please find the titleblock (in PythonCAD native .xml.gz format) attached below. The titleblock is released under the GNU LPGL licence. Art -- please feel free to put it into the project's released files if you like. One caveat: The titleblock is drawn to 11" x 17" scale. When you first open PythonCAD and draw a line, the line thickness is set to 1.00 in whatever units you use. If you use inches, as I do, then your lines will be giant blobs in this titleblock. Make sure that you set the line thickess to 0.01 (this is what I use) -- or something appropriately thin -- before using this titleblock. Stuart -------------- next part -------------- A non-text attachment was scrubbed... Name: Tabloid_landscape.xml.gz Type: application/gzip Size: 1452 bytes Desc: not available Url : http://mail.python.org/pipermail/pythoncad/attachments/20051024/7d41021d/Tabloid_landscape.xml.bin From ahaas at airmail.net Mon Oct 24 19:32:17 2005 From: ahaas at airmail.net (Art Haas) Date: Mon, 24 Oct 2005 12:32:17 -0500 Subject: [PythonCAD] Patches to highlight selected objects In-Reply-To: <20051022150610.C1C472AA07@earl-grey.cloud9.net> References: <20051022150610.C1C472AA07@earl-grey.cloud9.net> Message-ID: <20051024173217.GH17002@artsapartment.org> On Sat, Oct 22, 2005 at 11:06:10AM -0400, Stuart Brorson wrote: > Hi PythonCADsters -- > > I have made some mods to PythonCAD in order to implement highlighting > after selection. That is, my mods change PythonCAD's behavior so that > when you select a graphic object, it turns white. This sees to be the > desired behavior for selection. I have submitted the patches to Art > in a separate e-mail. The diff is against the the latest svn version > (updated yesterday -- Friday, Oct 21st, 2005). > > Please read about the detailed mods and some other discussion points > below. > > Code modifications made: > [ ... snip ... ] I'll make comments about the changes in another mail. I want to address some of the comments below. > Discussion: > > * My method to set the color upon selection/deselection is a hack. > This needs to be fixed. I propose that all graphic objects have an > attribute __default_color. This can be set in GraphicObject, and > overridden in the individual classes. Then, when you select an > object, it can go white ("obj.setColor(0xffffff)"). When you deselect > an object, it can revert to its normal default color by > ("obj.setColor(obj.__default_color)"). Entities do have a default color already - it is part of their default style. The Style gives them a default color, linetype, and thickness. See the 'graphicobject.py' file for the default. Entities like Segments, Circles, etc. that are subclasses of the GraphicObject class can override the Style values set in GraphicObject.__defstyle by extending the setStyle() method. Look at Segment::setStyle() as an example. If the argument to setStyle() is 'None', the Segment.__defstyle value is used as an argument to GraphicObject::setStyle. Any GraphicObject entity that has had its color changed from that given in its default Style can restore the Style color by calling setColor() without an argument. See the GraphicObject setColor() and getColor() methods for the details as to how things work. > * Sending the signal "color_changed" has the problem that it invokes > the graphicObjectLog class to store the last color. When doing a highlight, > it makes no sense to store the last color. Therefore, I propose to > create a different message "highlighted" which will not cause the > graphicObjectLog class to wake up. > > * One issue with the current architecture is that the point class > inherits from Subpart, not from Graphic object. The issue is that the > color attribute is set in GraphicObject, so a point doesn't have a > color, and doesn't have color methods. I overcame this by > implementing dummy color methods in the point class, but this is a > hack. > > Is there a reason that point can't inherit from GraphicObject? And > what distinction is made between GraphicObject and Subpart and Entity? A GraphicObject is something that has an associated linetype and thickness as well as a color. Point entities don't have any thickness nor would they need a Linetype, so when I set things up I made the Point class be a Subclass of the Subpart class. The idea behind the Subpart class was to provide a class of Entities that are used as components in more complex entities. A Segment, for example, requires two Point entities, so each point is a Subpart of the Segment. When hatching ever arrives in PythonCAD, I'd expect that Segments, Circles, and Arcs will all be Subparts of a Hatch entity. I'd thought at one time about trying to use a parent/child relationship for expressing the connectivity between entities, but it seemed to be more useful to use the parent/child idea as a means of expressing which entities are stored in a Layer, and what Layers are in an Image. This technique allows for a quick means of testing for entities in an Image. > * After doing this I noticed that "Edit -> Select" doesn't do > anything. That is, when you try to move an object, you do "Modify -> > Move -> Horizontal", and you thereafter need to select the objects to > move. What is the point behind "Edit -> Select" anyway? Does it do > anything? It puts the program into entity selection mode. Draw a couple of segments, then do 'Edit'->'Select'. You can then click on each segment or box some/all of them them, then go to 'Modify'->'Change' and you can change the selected entity Style, Linetype, Color, or Thickness. > I propose that any "Modify" actions should use the selected parts, > instead of requiring the user to re-select the parts to modify. The CAD package I used at my old job was structured so that move/stretch type operations were done where the displacement was specfied prior to selecting which entities to apply the operation upon, so that behavior is why things are coded like they are now. It isn't consisent, though, for some operations to be performed by first selecting entities and then choosing some operation, while other tasks require selecting an operation and then choosing entities. 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 w.knol at niwa.co.nz Wed Oct 26 00:22:22 2005 From: w.knol at niwa.co.nz (Wilbert Knol) Date: Wed, 26 Oct 2005 11:22:22 +1300 Subject: [PythonCAD] [ANNOUNCE] Twenty-sixth release of PythonCAD now available In-Reply-To: <20051021203208.GE17002@artsapartment.org> References: <20051021203208.GE17002@artsapartment.org> Message-ID: <200510261122.22439.w.knol@niwa.co.nz> I am assuming I need Subversion to check this out. 'svn', however, is giving me some grief... (turn line wrap off): [wk at wk .subversion]$ svn co http://subversion.pythoncad.org:9000/svn/pythoncad/trunk pythoncad svn: REPORT request failed on '/svn/!svn/vcc/default' svn: REPORT of '/svn/!svn/vcc/default': 400 Bad Request (http://subversion.pythoncad.org:9000) [wk at wk .subversion]$ What am I doing wrong? I am hiding behind a proxy server and have set up svn accordingly. Wilbert. From w.knol at niwa.co.nz Wed Oct 26 02:14:14 2005 From: w.knol at niwa.co.nz (Wilbert Knol) Date: Wed, 26 Oct 2005 13:14:14 +1300 Subject: [PythonCAD] [ANNOUNCE] Twenty-sixth release of PythonCAD now available In-Reply-To: <20051025224951.GA27654@artsapartment.org> References: <20051021203208.GE17002@artsapartment.org> <200510261122.22439.w.knol@niwa.co.nz> <20051025224951.GA27654@artsapartment.org> Message-ID: <200510261314.14535.w.knol@niwa.co.nz> I had checked the Subversion docs and FAQ, but eventually I came across the following info via google: You are most likely behind a proxy at work. The proxy isn't configured to allow REPORT requests, hence the failure. Solutions: - Get the proxy reconfigured to allow REPORT; or - Publish your repository at https://... Sometimes using a different port (other than 80) will do the trick. I am trying to get it sorted with the IT crowd on the campus. Thanks for the hints, Art. Wilbert. (posting to the reflector in case others come across the REPORT error) > On Wed, Oct 26, 2005 at 11:22:22AM +1300, Wilbert Knol wrote: > > I am assuming I need Subversion to check this out. > > > > 'svn', however, is giving me some grief... (turn line wrap off): > > > > [wk at wk .subversion]$ svn co > > http://subversion.pythoncad.org:9000/svn/pythoncad/trunk > > pythoncad svn: REPORT request failed on '/svn/!svn/vcc/default' > > svn: REPORT of '/svn/!svn/vcc/default': 400 Bad Request > > (http://subversion.pythoncad.org:9000) [wk at wk .subversion]$ > > > > What am I doing wrong? I am hiding behind a proxy server and > > have set up svn accordingly. From ahaas at airmail.net Thu Oct 27 20:30:21 2005 From: ahaas at airmail.net (Art Haas) Date: Thu, 27 Oct 2005 13:30:21 -0500 Subject: [PythonCAD] Short hiatus due to moving Message-ID: <20051027183021.GL27654@artsapartment.org> Hi. As the end of October is now upon us, I'm going to have to take another short break on PythonCAD work. I'm moving, and the move begins tomorrow, so I'll likely be hard too reach for the next week or so. I'm not certain how quickly I'll have an internet connection at the new place, nor exactly when the one at where I currently reside will go off, so my response to e-mails may be a bit slow for the next couple of days. With a little luck the majority of the move will be completed this weekend, and the internet connection at the new place up early next week, so hopefully this break will be short. 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