From richley at onion-switch.com Tue Jun 12 13:48:50 2007 From: richley at onion-switch.com (Ed Richley) Date: Tue, 12 Jun 2007 07:48:50 -0400 Subject: [PythonCAD] dimensioning Message-ID: <200706121148.l5CBmrS0008452@lodge.onion-switch.com> Hi: Can anyone reproduce this problem, using the latest version?: 1) Be sure that drawing and primary dim units are set to "inches" (edit prefs.py manually) 2) Open a new drawing 3) Draw a 1.000 x 1.000 rectangle 4) Dimension one side (say, with horizontal dimension) 5) See that it shows 0.039 instead of 1.000, as if it thought the drawing units were mm. If dim units are set to "millimeters", then it works correctly (even though I want inches). Also, there seems to be a problem with edit->preferences, for when I try to edit the primary dim units I get the error: Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkmenus.py", line 458, in prefs_cb gtkprefs.prefs_dialog(gtkimage) File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkprefs.py", line 2719, in prefs_dialog preferences.save_user_prefs() File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/preferences.py", line 1660, in save_user_prefs _save_dimstyle_values(_f) File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/preferences.py", line 1471, in _save_dimstyle_values if abs(_val - _ds.getOption('DIM_EXTENSION')) > 1e-10: TypeError: unsupported operand type(s) for -: 'Color' and 'float' It appears that the DIM_EXTENSION attribute if getting the value of the DIM_COLOR. I'm trying to learn Python and fix this (at the same time), but it's hard :-(. Can someone please at least reproduce the problem? Thanks. Ed From ahaas at airmail.net Tue Jun 12 14:30:39 2007 From: ahaas at airmail.net (Art Haas) Date: Tue, 12 Jun 2007 07:30:39 -0500 Subject: [PythonCAD] dimensioning In-Reply-To: <200706121148.l5CBmrS0008452@lodge.onion-switch.com> References: <200706121148.l5CBmrS0008452@lodge.onion-switch.com> Message-ID: <20070612123039.GH7595@artsapartment.org> Hi. I'll see if I can duplicate this, and if so fix it ASAP. 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 12 15:26:39 2007 From: richley at onion-switch.com (Ed Richley) Date: Tue, 12 Jun 2007 09:26:39 -0400 Subject: [PythonCAD] dimensioning Message-ID: <200706121326.l5CDQdrH028558@armstrong.onion-switch.com> Art: It seems that I can't reply to ahaas at airmail.net. In cany case, I've been looking at the code a lot, trying to learn. I do know that when it fails, the "DIM_EXTENSION" has the value of the "DIM_COLOR", as if some index was off by one. But, I really don't understand what's going on in preferences.py. Or, why the prefs.py has what looks like a dictionary (is that correct?) for primary dimension parameters, and then suplements these with variable assignments like: dim_primary_extension = 0.1 at the bottom. Maybe you can explain some of this so I can figure out some of these problems. Thanks for looking into it. Ed From ahaas at airmail.net Tue Jun 12 22:38:12 2007 From: ahaas at airmail.net (Art Haas) Date: Tue, 12 Jun 2007 15:38:12 -0500 Subject: [PythonCAD] dimensioning In-Reply-To: <200706121148.l5CBmrS0008452@lodge.onion-switch.com> References: <200706121148.l5CBmrS0008452@lodge.onion-switch.com> Message-ID: <20070612203812.GL7595@artsapartment.org> On Tue, Jun 12, 2007 at 07:48:50AM -0400, Ed Richley wrote: > > Hi: > > Can anyone reproduce this problem, using the latest version?: > > 1) Be sure that drawing and primary dim units are set to "inches" (edit > prefs.py manually) > 2) Open a new drawing > 3) Draw a 1.000 x 1.000 rectangle > 4) Dimension one side (say, with horizontal dimension) > 5) See that it shows 0.039 instead of 1.000, as if it thought the drawing > units were mm. > > If dim units are set to "millimeters", then it works correctly (even though > I want inches). I've duplicated this. I'm investigating right now. > Also, there seems to be a problem with edit->preferences, for when I try > to edit the primary dim units I get the error: > > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkmenus.py", > line 458, in prefs_cb > gtkprefs.prefs_dialog(gtkimage) > File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkprefs.py", > line 2719, in prefs_dialog > preferences.save_user_prefs() > File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/preferences.py", > line 1660, in save_user_prefs > _save_dimstyle_values(_f) > File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/preferences.py", > line 1471, in _save_dimstyle_values > if abs(_val - _ds.getOption('DIM_EXTENSION')) > 1e-10: > TypeError: unsupported operand type(s) for -: 'Color' and 'float' > > > It appears that the DIM_EXTENSION attribute if getting the value of the > DIM_COLOR. > > I'm trying to learn Python and fix this (at the same time), but it's hard :-(. > Can someone please at least reproduce the problem? I'll take a look at this too, and reply to your other mail 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 Tue Jun 12 23:37:23 2007 From: ahaas at airmail.net (Art Haas) Date: Tue, 12 Jun 2007 16:37:23 -0500 Subject: [PythonCAD] dimensioning In-Reply-To: <20070612123039.GH7595@artsapartment.org> References: <200706121148.l5CBmrS0008452@lodge.onion-switch.com> <20070612123039.GH7595@artsapartment.org> Message-ID: <20070612213723.GN7595@artsapartment.org> On Tue, Jun 12, 2007 at 07:30:39AM -0500, Art Haas wrote: > Hi. > > I'll see if I can duplicate this, and if so fix it ASAP. This was interesting. The core problem was that there are two ways to set the units in a drawing - one with the setUnits() method and the other by setOption('UNITS', xxx). The trouble various places used setOption() to do the dirty work, but it didn't go through. The small patch below fixed things for me. Please apply and let me know that it works for you as well. The next challenge is to figure out the other bug you described. Art Index: PythonCAD/Generic/image.py =================================================================== --- PythonCAD/Generic/image.py (revision 2760) +++ PythonCAD/Generic/image.py (working copy) @@ -721,6 +721,8 @@ self.__units.setUnit(unit) if unit != _ou: self.sendMessage('units_changed', _ou) + self.__options['UNITS'] = unit + self.sendMessage('option_changed', 'UNITS', _ou) self.modified() units = property(getUnits, setUnits, None, @@ -1651,6 +1653,9 @@ key == 'DIM_SECONDARY_FONT_FAMILY'): if value not in self.__fonts: self.__fonts[value] = True + elif key == 'UNITS': + self.setUnits(value) + return # bail out else: pass self.__options[key] = value -- 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 13 00:33:48 2007 From: ahaas at airmail.net (Art Haas) Date: Tue, 12 Jun 2007 17:33:48 -0500 Subject: [PythonCAD] dimensioning In-Reply-To: <200706121148.l5CBmrS0008452@lodge.onion-switch.com> References: <200706121148.l5CBmrS0008452@lodge.onion-switch.com> Message-ID: <20070612223348.GA2779@artsapartment.org> On Tue, Jun 12, 2007 at 07:48:50AM -0400, Ed Richley wrote: > > Also, there seems to be a problem with edit->preferences, for when I try > to edit the primary dim units I get the error: > > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkmenus.py", > line 458, in prefs_cb > gtkprefs.prefs_dialog(gtkimage) > File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkprefs.py", > line 2719, in prefs_dialog > preferences.save_user_prefs() > File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/preferences.py", > line 1660, in save_user_prefs > _save_dimstyle_values(_f) > File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/preferences.py", > line 1471, in _save_dimstyle_values > if abs(_val - _ds.getOption('DIM_EXTENSION')) > 1e-10: > TypeError: unsupported operand type(s) for -: 'Color' and 'float' > > > It appears that the DIM_EXTENSION attribute if getting the value of the > DIM_COLOR. Grrrrrr .... dumb paste-o. Index: PythonCAD/Interface/Gtk/gtkprefs.py =================================================================== --- PythonCAD/Interface/Gtk/gtkprefs.py (revision 2763) +++ PythonCAD/Interface/Gtk/gtkprefs.py (revision 2764) @@ -2205,8 +2205,7 @@ else: raise TypeError, "Unexpected widget for DIM_COLOR: " + `type(_widget)` _r, _g, _b = _get_rgb_values(_color) - _dimcolor = get_color(_r, _g, _b) - globals.prefs['DIM_EXTENSION'] = get_color(_r, _g, _b) + globals.prefs['DIM_COLOR'] = get_color(_r, _g, _b) def _set_background_color(prefstate): _widget = prefstate.getWidget('BACKGROUND_COLOR') -- 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 Wed Jun 13 02:25:37 2007 From: richley at onion-switch.com (Ed Richley) Date: Tue, 12 Jun 2007 20:25:37 -0400 Subject: [PythonCAD] dimensioning In-Reply-To: <20070612223348.GA2779@artsapartment.org> References: <200706121148.l5CBmrS0008452@lodge.onion-switch.com> <20070612223348.GA2779@artsapartment.org> Message-ID: <200706130025.l5D0PfIl012162@lodge.onion-switch.com> > Grrrrrr .... dumb paste-o. > Great. I just did a svn update and it works much better now. Thanks. Oddly, my old drawing must contain something inconsistent with the new code, because it still wants the dimension units to be millimeters. But, a new drawing works fine. Can you explain how all the preferences are stored? My simple mind (ruined by self-taught C-programming) would have a bunch of variables that get set at start-up and when editing, and written when edit->preferences is told "OK". But, here there are a bunch of lists, dictionaries, tuples, etc., and it was really hard for me to follow what was going on. I'm sure there is a good reason, but I'd like to know more so I can help. Thanks. Ed From richley at onion-switch.com Wed Jun 13 13:24:36 2007 From: richley at onion-switch.com (Ed Richley) Date: Wed, 13 Jun 2007 07:24:36 -0400 Subject: [PythonCAD] a few more bugs Message-ID: <200706131124.l5DBOeYC016004@lodge.onion-switch.com> With the latest fixes, things are much better now. However, I do notice the following error: Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/message.py", line 113, in sendMessage _method(self, *args) File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkimage.py", line 1219, in __imageToolChanged _init(self) File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtktext.py", line 217, in text_add_init _text = _tool.getText() File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/tools.py", line 3448, in getText raise ValueError, "No text stored in TextTool." ValueError: No text stored in TextTool. This happens (sometimes) when I place new text, and then modify->change-> textblock->size, selecting the text AFTER the modify. Also, it appears that radial dimensions cause the file to not load at all. I was able to edit them out of an xml page and get the file to load. I can send an example, but you can also do the following: 1) Open a new drawing 2) Draw an arc, at (0,0), with radius = 1.000, start angle = 0, stop angle = 90. 3) Place a radial dimension for this arc in the drawing. 4) Save the drawing. When you open it, you will get: lodge$ Opening 'Test.xml.gz' Failed loading 'Test.xml.gz'! 'circle' and the drawing will not open. Ed From ahaas at airmail.net Wed Jun 13 19:56:45 2007 From: ahaas at airmail.net (Art Haas) Date: Wed, 13 Jun 2007 12:56:45 -0500 Subject: [PythonCAD] dimensioning In-Reply-To: <200706130025.l5D0PfIl012162@lodge.onion-switch.com> References: <200706121148.l5CBmrS0008452@lodge.onion-switch.com> <20070612223348.GA2779@artsapartment.org> <200706130025.l5D0PfIl012162@lodge.onion-switch.com> Message-ID: <20070613175645.GC2779@artsapartment.org> On Tue, Jun 12, 2007 at 08:25:37PM -0400, Ed Richley wrote: > > Grrrrrr .... dumb paste-o. > > Great. I just did a svn update and it works much better now. Thanks. > Oddly, my old drawing must contain something inconsistent with the > new code, because it still wants the dimension units to be millimeters. > But, a new drawing works fine. Weird. > Can you explain how all the preferences are stored? My simple mind (ruined by > self-taught C-programming) would have a bunch of variables that get set at > start-up and when editing, and written when edit->preferences is told "OK". > But, here there are a bunch of lists, dictionaries, tuples, etc., and it was > really hard for me to follow what was going on. I'm sure there is a good > reason, but I'd like to know more so I can help. The 'prefs.py' file is python code (obviously), and the code for loading and saving the values is found in 'PythonCAD/Generic/preferences.py'. The file itself has a couple of comments in it to explain what type of values the next bunch of variables should be, so in my 'prefs.py' file the follow appear: # [ ... snip ... ] # # Boolean variables # autosplit = True highlight_points = True # # Size variables (float values) # chamfer_length = 1.5 fillet_radius = 2.0 leader_arrow_size = 10.0 # [ ... snip ... ] When the defined variable is a dictionary, the variable itself is a style, textstyle, or dimstyle. Each key represents one option with the style. If you've adjusted any of the values in the style to some value other than that defined by the style, the key and value are listed after the dictionary. Again, in my 'prefs.py' file I have the following: # # Standard GraphicObject parameters # line_style = { 'name' : 'Default Style', 'linetype' : ('Solid', None), 'color' : '#ffffff', 'thickness' : 1.0 } line_thickness = 0.10000000000000001 So, the 'line_thickness' in the style is overriden; the value will be 0.1 instead of 1.0. The 'prefs.py' file is parsed using routines found in the the 'imp' module. The initial call to find_module() determines if the file is there or not, and if it is the code is loaded via load_module(). The values of everything in the file can be examined by testing if certain attributes exist within the newly loaded module. Using the bits of my 'prefs.py' file above, the module 'prefs' is tested for attributes 'autosplit', 'highlight_points', 'chamfer_length', 'fillet_radius', 'leader_arrow_size', 'line_style', etc. The complete list of attributes is defined in the '_preflist' variable in 'preferences.py'. If the attribute is found, then the value defined by that attribute gets picked up and placed into the 'global.prefs' dictionary, so in my case global.prefs['AUTOSPLIT'] is True, global.prefs['HIGHLIGHT_POINTS'] is True, etc. When the 'line_style' attribute is found, globals.prefs['LINE_STYLE]' gets set to a Style instance defined by the keys/values in 'line_style'. If any overriden values were seen, as is the case above with 'line_thickness', then the matching key/value pair in globals.prefs gets the override value. In my case, globals.prefs['LINE_THICKNESS'] is set to 0.1, overriding the value defined in the style (1.0). I hope the explanation above sheds some light on the structure of the 'prefs.py' file and how the values get pulled into and used by 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 ahaas at airmail.net Thu Jun 14 23:58:32 2007 From: ahaas at airmail.net (Art Haas) Date: Thu, 14 Jun 2007 16:58:32 -0500 Subject: [PythonCAD] dimensioning In-Reply-To: <20070613175645.GC2779@artsapartment.org> References: <200706121148.l5CBmrS0008452@lodge.onion-switch.com> <20070612223348.GA2779@artsapartment.org> <200706130025.l5D0PfIl012162@lodge.onion-switch.com> <20070613175645.GC2779@artsapartment.org> Message-ID: <20070614215832.GB23004@artsapartment.org> On Wed, Jun 13, 2007 at 12:56:45PM -0500, Art Haas wrote: > > When the 'line_style' attribute is found, globals.prefs['LINE_STYLE]' > gets set to a Style instance defined by the keys/values in 'line_style'. > If any overriden values were seen, as is the case above with > 'line_thickness', then the matching key/value pair in globals.prefs > gets the override value. In my case, globals.prefs['LINE_THICKNESS'] > is set to 0.1, overriding the value defined in the style (1.0). Hi. I was poking around with this code today and fixed what is arguably an oversight on my part. When the globals.prefs['LINE_STYLE'] value is set, the 'LINE_TYPE', 'LINE_THICKNESS', and 'LINE_COLOR' values are not set to whatever values defined by the just-set Style. I've just added the code so those three values get set after LINE_STYLE. Any overriden Style values, such as in my example in the previous mail, will then set the appropriate key/value pair in globals.prefs. When the preferences.py file has 'text_style', the code is supposed to set the globals.prefs['TEXT_STYLE'] key with the suitable Style. The line of code to do this, though, was missing (!), so the TEXT_STYLE was not be set correctly. This problem is now fixed, and when the TEXT_STYLE is set the various TEXT/FONT options get set as well. I've pushed my changes out to the repo, so just do an 'svn update' and you'll get them. Also, some of you may have noticed that the repo now has '.gitignore' files. They have not been added by mistake, as I've imported the PythonCAD Subversion repo into 'git' and am now using it as my development tree. I'm working to set up 'git clone' and 'git pull' access from the PythonCAD site, but it isn't available yet. My work flow now is done in the PythonCAD git repo, and after commiting my changes I extract the change(s) as a patch, apply it to my old Subversion development tree, then commit the patch to the Subversion repo as I've always done. This is a manual process, but as long as the patches are small this works. I wrote earlier that I wanted to switch to a distributed SCM, and the response was that most people were happy with Subversion access and the current setup. I think the approach I've taken in making the switch while still providing Subversion access will work for the foreseeable future. Once I make my 'git' repo accessible then people who want to develop PythonCAD with git will be able to do so while Subversion users will not be abandoned. Ideally there would be a git->svn tool that does the patch application, but I don't know of such a beast. Git does have a 'git svn' command but it is structured so that a Git user can push/pull from an Subversion repo with the idea that the Subversion repo is the "master" repo. I want a simpler "export-only" type transfer from git to svn. When my git repo becomes public I'll send a message to the mailing list giving the location, and those wanting to use git instead of Subversion will be welcome to clone my tree and develop away! 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 miguelverdu at yahoo.es Fri Jun 15 15:20:46 2007 From: miguelverdu at yahoo.es (=?iso-8859-1?q?Miguel=20Verd=FA?=) Date: Fri, 15 Jun 2007 15:20:46 +0200 (CEST) Subject: [PythonCAD] New Interface for PythonCAD Message-ID: <391006.90345.qm@web23307.mail.ird.yahoo.com> Hi, I use Linux from 2003, but I still hava my windows partition because I have to use AutoCad. I think there are a lot CAD projects over the opensource project but anyone it's good enought to leave Autocad, but I would like so much. So, the best thing of opensource it's exactly that, if you don't like a program you can change it. Then I decided contribuite to that. The main problem is that I dont know program, but I think I can help to the comunity making a more useful interface to PythonCAD. I think there are million of people that want to migrate to Linux and they can't do it because there is an alternative good enought. I think the interface must be more similar to Autocad because it is an starndard and there are million of peaplo dont have time to know new interfaces, so... What do you think about create a new interface much more similar to Autocad with glade. I've comented that to the main developer and he told me all you don't use a glade interface because dont want to limit other desktops differents to gnome, but I think we could do it portable anyway like gimp, or others making statics versions (with all libraries requirements). I'm working on it, and I send you the icons I'm working based on Tango icon theme. Please tell me your coments and tips. Greetings and sorry for my bad english. ____________________________________________________________________________________ ?Descubre una nueva forma de obtener respuestas a tus preguntas! Entra en Yahoo! Respuestas. http://es.answers.yahoo.com/info/welcome -------------- next part -------------- A non-text attachment was scrubbed... Name: pythoncad_icons_based_tango_01.jpg Type: image/jpeg Size: 31191 bytes Desc: 930597894-pythoncad_icons_based_tango_01.jpg Url : http://mail.python.org/pipermail/pythoncad/attachments/20070615/a7616e9c/attachment-0001.jpg From richley at onion-switch.com Thu Jun 21 16:19:58 2007 From: richley at onion-switch.com (Ed Richley) Date: Thu, 21 Jun 2007 10:19:58 -0400 Subject: [PythonCAD] dimensioning In-Reply-To: Message from "Art Haas" of "Wed, 13 Jun 2007 12:56:45 CDT." <20070613175645.GC2779@artsapartment.org> Message-ID: <200706211420.l5LEJwgR009098@armstrong.onion-switch.com> > I hope the explanation above sheds some light on the structure of > the 'prefs.py' file and how the values get pulled into and used by > PythonCAD. > > Art > -- Yes, it does. I'll dig into it more when I get a chance. Thanks. Ed From richley at onion-switch.com Fri Jun 22 06:05:11 2007 From: richley at onion-switch.com (Ed Richley) Date: Fri, 22 Jun 2007 00:05:11 -0400 Subject: [PythonCAD] Angular dimensions Message-ID: <200706220405.l5M45F5g001013@lodge.onion-switch.com> In gtkinit.py, lines 1329-1330 should read: _pxmin = _pvx - _pr _pymin = _pvy - _pr For proper angular dimensioning to take place. At least, it works a whole lot better than when it said: _pxmin = _px - _pr _pymin = _py - _pr because _px and _py apparently didn't exist. I must be learning something. I fixed a bug. Ed From richley at onion-switch.com Fri Jun 22 15:20:51 2007 From: richley at onion-switch.com (Ed Richley) Date: Fri, 22 Jun 2007 09:20:51 -0400 Subject: [PythonCAD] Problem with fillets Message-ID: <200706221320.l5MDKpuf020666@armstrong.onion-switch.com> I think I can fix this one, but I wanted to understand something better: When generating Postscript for fillets, I sometimes get an arc that goes the wrong way; instead of smoothly joining the segments, it goes the long way around and forms a large semicircle. In looking at the code, I see that it doesn't pay attention to the order of the angles (start and stop angles). This seems to be OK for imaging on the screen, but Postscript requires an arc to go counterclockwise. I think I can fix this by ensuring that end angle > start angle in the PS arc command, but I wonder if that creates a new problem. Any thoughts? Ed From nelson at crynwr.com Fri Jun 22 15:51:04 2007 From: nelson at crynwr.com (Russ Nelson) Date: Fri, 22 Jun 2007 09:51:04 -0400 Subject: [PythonCAD] Problem with fillets In-Reply-To: <200706221320.l5MDKpuf020666@armstrong.onion-switch.com> References: <200706221320.l5MDKpuf020666@armstrong.onion-switch.com> Message-ID: <18043.54216.946494.89236@desk.crynwr.com> Ed Richley writes: > I think I can fix this by ensuring that end angle > start angle in > the PS arc command, but I wonder if that creates a new problem. No, that should be fine. -- --my blog is at http://blog.russnelson.com | In my head, I'm Crynwr sells support for free software | PGPok | violating your 521 Pleasant Valley Rd. | +1 315-323-1241 | software patent. Potsdam, NY 13676-3213 | Sheepdog | So sue me! From ahaas at airmail.net Fri Jun 22 18:00:06 2007 From: ahaas at airmail.net (Art Haas) Date: Fri, 22 Jun 2007 11:00:06 -0500 Subject: [PythonCAD] Angular dimensions In-Reply-To: <200706220405.l5M45F5g001013@lodge.onion-switch.com> References: <200706220405.l5M45F5g001013@lodge.onion-switch.com> Message-ID: <20070622160006.GG25208@artsapartment.org> On Fri, Jun 22, 2007 at 12:05:11AM -0400, Ed Richley wrote: > > In gtkinit.py, lines 1329-1330 should read: > > _pxmin = _pvx - _pr > _pymin = _pvy - _pr > > For proper angular dimensioning to take place. At least, it works a whole > lot better than when it said: > > _pxmin = _px - _pr > _pymin = _py - _pr > > because _px and _py apparently didn't exist. > > I must be learning something. I fixed a bug. Nice catch. This bit of code uses the older GTK+/GDK routine to draw and the bug wouldn't be seen on newer systems utilizing the Cairo drawing routines. I've applied your patch. 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 richley at onion-switch.com Sat Jun 23 01:23:11 2007 From: richley at onion-switch.com (Ed Richley) Date: Fri, 22 Jun 2007 19:23:11 -0400 Subject: [PythonCAD] Problem with fillets In-Reply-To: <18043.54216.946494.89236@desk.crynwr.com> References: <200706221320.l5MDKpuf020666@armstrong.onion-switch.com> <18043.54216.946494.89236@desk.crynwr.com> Message-ID: <200706222323.l5MNNErp006833@lodge.onion-switch.com> OK, then this seems to work (so far): Change printing.py line 494 to: f.write("%g %g %g %g %g arc\n" % (_xt, _yt, _rt, min(_sa,_ea),max(_sa,_ea))) Ed > Ed Richley writes: > > I think I can fix this by ensuring that end angle > start angle in > > the PS arc command, but I wonder if that creates a new problem. > > No, that should be fine. > > -- From richley at onion-switch.com Sun Jun 24 04:46:39 2007 From: richley at onion-switch.com (Ed Richley) Date: Sat, 23 Jun 2007 22:46:39 -0400 Subject: [PythonCAD] Radial dimensions Message-ID: <200706240246.l5O2khBf014946@lodge.onion-switch.com> I've been having problems with radial dimensions. Basically, they don't work with arcs. Apparently, radial dimensions can be applied to both 'arcs' and 'circles', at least that's what I see in imageio.py. So, here's my (very crude) patch to fix this. I'm sure it can be done much better, but this at least lets the files open. Ed Index: imageio.py =================================================================== --- imageio.py (revision 2769) +++ imageio.py (working copy) @@ -2424,8 +2424,14 @@ _cid = dim['c'] del dim['c'] _lid = id(_cl) - assert _cid in map[_lid]['circle'], "Missing circle key %d" % _cid - _circ = map[_lid]['circle'][_cid] +# assert (_cid in map[_lid]['arc'])|(_cid in map[_lid]['circle']), "Missing circle key %d" % _cid + assert ('arc' in map[_lid])|('circle' in map[_lid]), "Missing circle key %d" % _cid + if 'arc' in map[_lid]: + if _cid in map[_lid]['arc']: + _circ = map[_lid]['arc'][_cid] + elif 'circle' in map[_lid]: + if _cid in map[_lid]['circle']: + _circ = map[_lid]['circle'][_cid] assert 'x' in dim, "Dim missing key 'x': " + `dim` _x = dim['x'] del dim['x'] From richley at onion-switch.com Sun Jun 24 04:53:40 2007 From: richley at onion-switch.com (Ed Richley) Date: Sat, 23 Jun 2007 22:53:40 -0400 Subject: [PythonCAD] Angular dimensions In-Reply-To: <20070622160006.GG25208@artsapartment.org> References: <200706220405.l5M45F5g001013@lodge.onion-switch.com> <20070622160006.GG25208@artsapartment.org> Message-ID: <200706240253.l5O2riNs015003@lodge.onion-switch.com> Actually, what's in the repository won't compile. There was some weird stuff in gtkinit.py at that point. Maybe you can have a look. Ed > Nice catch. This bit of code uses the older GTK+/GDK routine to draw > and the bug wouldn't be seen on newer systems utilizing the Cairo > drawing routines. > > I've applied your patch. Thanks! > > Art Haas From w.knol at niwa.co.nz Sun Jun 24 23:36:09 2007 From: w.knol at niwa.co.nz (Wilbert Knol) Date: Mon, 25 Jun 2007 09:36:09 +1200 Subject: [PythonCAD] ImportError: No module named pygtk Message-ID: <200706250936.11008.w.knol@niwa.co.nz> Revision 2769 produces this error: wk at wk:~/pythoncad$ ./gtkpycad.py Traceback (most recent call last): File "./gtkpycad.py", line 30, in ? import pygtk ImportError: No module named pygtk wk at wk:~/pythoncad$ To me, it looks like a pythoncad-only library module: wk at wk:~/pythoncad$ find ./ -iname pygtk wk at wk:~/pythoncad$ I am lost. Wilbert. From richley at onion-switch.com Mon Jun 25 01:47:00 2007 From: richley at onion-switch.com (Ed Richley) Date: Sun, 24 Jun 2007 19:47:00 -0400 Subject: [PythonCAD] radial dimensions (again) Message-ID: <200706242347.l5ONl3UH031501@lodge.onion-switch.com> Apparently I spoke too soon. This still isn't fixed. Apparently radial dimensions can be applied to both arcs and circles, but don't carry information about which type the apply to. So, with both arcs and circles in a drawing, each can have a member with the same index in the "map" (I think) and it gets all confused. I'm now in over my head and need help. Ed From ahaas at airmail.net Mon Jun 25 04:58:14 2007 From: ahaas at airmail.net (Art Haas) Date: Sun, 24 Jun 2007 21:58:14 -0500 Subject: [PythonCAD] ImportError: No module named pygtk In-Reply-To: <200706250936.11008.w.knol@niwa.co.nz> References: <200706250936.11008.w.knol@niwa.co.nz> Message-ID: <20070625025814.GB6581@artsapartment.org> On Mon, Jun 25, 2007 at 09:36:09AM +1200, Wilbert Knol wrote: > Revision 2769 produces this error: > > wk at wk:~/pythoncad$ ./gtkpycad.py > Traceback (most recent call last): > File "./gtkpycad.py", line 30, in ? > import pygtk > ImportError: No module named pygtk > wk at wk:~/pythoncad$ > > To me, it looks like a pythoncad-only library module: > > wk at wk:~/pythoncad$ find ./ -iname pygtk > wk at wk:~/pythoncad$ > > I am lost. Don't know what's going on here. The 'pygtk' module is the binding to the GTK+ libraries, not a PythonCAD package. Have you done any updates to your system lately? If it is rpm-based, what does $ rpm -qa | grep pygtk produce? If it is '.deb' based, what does $ dpkg -l | grep pygtk yield? 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 w.knol at niwa.co.nz Mon Jun 25 06:11:53 2007 From: w.knol at niwa.co.nz (Wilbert Knol) Date: Mon, 25 Jun 2007 16:11:53 +1200 Subject: [PythonCAD] ImportError: No module named pygtk In-Reply-To: <20070625025814.GB6581@artsapartment.org> References: <200706250936.11008.w.knol@niwa.co.nz> <20070625025814.GB6581@artsapartment.org> Message-ID: <200706251611.54753.w.knol@niwa.co.nz> > Don't know what's going on here. The 'pygtk' module is the binding to > the GTK+ libraries, not a PythonCAD package. Sorry about the confusion. I somehow assumed it was PythonCAD-related! > Have you done any updates > to your system lately? Yes, I upgraded from Debian Sarge to Etch, which seems to have killed my previously installed python-gtk libraries. Anyway, all is well now. I installed python-gtk2, which also pulled in a couple of other dependencies Wilbert. From ahaas at airmail.net Mon Jun 25 15:10:18 2007 From: ahaas at airmail.net (Art Haas) Date: Mon, 25 Jun 2007 08:10:18 -0500 Subject: [PythonCAD] ImportError: No module named pygtk In-Reply-To: <200706251611.54753.w.knol@niwa.co.nz> References: <200706250936.11008.w.knol@niwa.co.nz> <20070625025814.GB6581@artsapartment.org> <200706251611.54753.w.knol@niwa.co.nz> Message-ID: <20070625131018.GC6581@artsapartment.org> On Mon, Jun 25, 2007 at 04:11:53PM +1200, Wilbert Knol wrote: > > > Don't know what's going on here. The 'pygtk' module is the binding to > > the GTK+ libraries, not a PythonCAD package. > > Sorry about the confusion. I somehow assumed it was PythonCAD-related! > > > Have you done any updates > > to your system lately? > > Yes, I upgraded from Debian Sarge to Etch, which seems to have killed my > previously installed python-gtk libraries. > > Anyway, all is well now. I installed python-gtk2, which also pulled in a > couple of other dependencies Glad to hear that all is well again. 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