From ahaas at airmail.net Wed Feb 1 22:52:02 2006 From: ahaas at airmail.net (Art Haas) Date: Wed, 1 Feb 2006 15:52:02 -0600 Subject: [PythonCAD] More fixes for DimString modification at repo Message-ID: <20060201215202.GG11891@artsapartment.org> Hi. I've sent a couple of fixes for DimString modification to the repo, and it looks like this is the last set of changes to go in before I make the release, most likely tomorrow. People using subversion can get these fixes with an 'svn update'. 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 Feb 2 20:12:40 2006 From: ahaas at airmail.net (Art Haas) Date: Thu, 2 Feb 2006 13:12:40 -0600 Subject: [PythonCAD] [ANNOUNCE] Twenty-eighth release of PythonCAD now available Message-ID: <20060202191240.GK11891@artsapartment.org> Hi. I'm pleased to announce the twenty-eighth 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-eighth release of PythonCAD offers improved abilities to edit entities in a drawing. Previous releases had inconsistent behavior for entity modification as some operations first required selecting then entities to change and then selecting the operation to perform, where other changes were accomplished by first selecting the action and then selecting entities. The latest release allows for entity modifications to be performed in either mode, thus making the code more consistent as well as easier to use. For people familiar with AutoCAD, PythonCAD now has 'NOUN->VERB' and 'VERB->NOUN' entity modification behavior. Numerous internal changes to the code utilizing more current functionality are also included in this release, in particular a rewrite of the entity moving code. Also, the ability to adjust the attributes of the text objects in a Dimension have been improved as well as simplified. And as usual, a wide number of bug fixes and other code enhancements are present in the 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 dgcov at webmail.co.za Sat Feb 4 11:28:41 2006 From: dgcov at webmail.co.za (Dave Coventry) Date: Sat, 04 Feb 2006 12:28:41 +0200 Subject: [PythonCAD] AutoCAD 2004 In-Reply-To: <20060118202720.GC2284@artsapartment.org> References: <20060118202720.GC2284@artsapartment.org> Message-ID: Hi Art, Have you looked at implementing your DWG Reader for AutoCAD 2004? Or is this now off the agenda? Dave Coventry ___________________________________________________________________ For super low premiums, click here http://www.webmail.co.za/dd.pwm http://www.webmail.co.za the South African FREE email service From ahaas at airmail.net Sat Feb 4 15:50:58 2006 From: ahaas at airmail.net (Art Haas) Date: Sat, 4 Feb 2006 08:50:58 -0600 Subject: [PythonCAD] AutoCAD 2004 In-Reply-To: References: <20060118202720.GC2284@artsapartment.org> Message-ID: <20060204145058.GB22821@artsapartment.org> On Sat, Feb 04, 2006 at 12:28:41PM +0200, Dave Coventry wrote: > Hi Art, > > Have you looked at implementing your DWG Reader for AutoCAD > 2004? > > Or is this now off the agenda? > Hi. I am unaware of any publically available documentation for the current(?) DWG file format. The OpenDWG people reverse engineered the R13, R14, and R15 formats, but the R16 format was changed again, and the changes were extensive. I don't know if there is a still newer format that R16, btw. If there is freely available docs for the R16 file format I'd like to get them and I'll work on writing code to read those files. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Mon Feb 6 21:41:19 2006 From: ahaas at airmail.net (Art Haas) Date: Mon, 6 Feb 2006 14:41:19 -0600 Subject: [PythonCAD] Goals for next release Message-ID: <20060206204119.GF28121@artsapartment.org> Hi. I hope that people using the latest release are finding things working well for them. There are still a few missing features in PythonCAD, notably hatching, but overall things are nearing a point where most of the basic everyday feature in a CAD package are present. I wish that we were at this point a year ago, if not sooner, but that was not meant to be. For the next release I want to clean up some older unused code, and I've started doing that by removing the old entity moving routines and various other old routines I find in both the interface and core program components. I'm planning to rework the code that handles transferring entities from one layer to another as, like the entity moving code, the program offers newer routines that can simplify as well as improve this feature. After that I'm not sure what will be next in line. I'd like to try and get back to making at least one release a month, so I'll tentatively plan the next release for early March. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Tue Feb 7 21:03:35 2006 From: ahaas at airmail.net (Art Haas) Date: Tue, 7 Feb 2006 14:03:35 -0600 Subject: [PythonCAD] Question about transferring objects between layers Message-ID: <20060207200335.GK28121@artsapartment.org> Hi. As I wrote in an earlier message, I've started reworking the code that handles transferring objects between layers. While starting to make some of the planned changes, I thought of a scenario that could occur and wonder how other packages that use layers handle it. Suppose we have a segment S and its two endpoints P1 and P2. These three objects are in some layer, and now I decide to transfer either of the points to another layer. As both endpoints of the segment must be in the same layer as the segment itself, what should be the expected way to handle this operation? Should the program allow the point to move, and then by default transfer the segment as well, or should this operation raise an error? If the segment was to be transferred between layers, it will automagically transfer the points if possible (in the initial writing of the new code), so there is an implicit object transferring in some operations already. The current transfer code in 'transfer.py' is based around cloning entities and adding them to the desired layer, and then deleting the original entities. The new approach will try to avoid the cloning operations as much as possible, and instead use the Layer deleteObject() and addObject() methods. So, how do other CAD packages that hold drawing entities in layers behave if the operation to transfer the entity results in the entity having pieces of itself in both layers? I am inclined to code things so that the entity is automagically transferred, but there will certainly be times this behavior will be unexpected. Comments and suggestions welcomed. 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 Tue Feb 7 21:43:25 2006 From: sdb at cloud9.net (Stuart Brorson) Date: Tue, 7 Feb 2006 15:43:25 -0500 (EST) Subject: [PythonCAD] Question about transferring objects between layers In-Reply-To: <20060207200335.GK28121@artsapartment.org> from "Art Haas" at Feb 07, 2006 02:03:35 PM Message-ID: <20060207204325.67F832AA07@earl-grey.cloud9.net> Hi -- > Suppose we have a segment S and its two endpoints P1 and P2. These three > objects are in some layer, and now I decide to transfer either of the > points to another layer. As both endpoints of the segment must be in > the same layer as the segment itself, what should be the expected way to > handle this operation? Should the program allow the point to move, and > then by default transfer the segment as well, or should this operation > raise an error? I guess my question would be: Why would I want to transfer only the points? Is there a use case where only the points need transerring, and not the segment? (I suppose you might want to *copy* some points from one layer to another, but that's a different use than *moving* the points.) > If the segment was to be transferred between layers, it will > automagically transfer the points if possible (in the initial writing > of the new code), so there is an implicit object transferring > in some operations already. Sounds reasonable to me. Caveat: I am not a mechanical CAD guru. Stuart From ahaas at airmail.net Tue Feb 7 22:02:57 2006 From: ahaas at airmail.net (Art Haas) Date: Tue, 7 Feb 2006 15:02:57 -0600 Subject: [PythonCAD] Question about transferring objects between layers In-Reply-To: <20060207204325.67F832AA07@earl-grey.cloud9.net> References: <20060207200335.GK28121@artsapartment.org> <20060207204325.67F832AA07@earl-grey.cloud9.net> Message-ID: <20060207210257.GL28121@artsapartment.org> On Tue, Feb 07, 2006 at 03:43:25PM -0500, Stuart Brorson wrote: > Hi -- > > > Suppose we have a segment S and its two endpoints P1 and P2. These three > > objects are in some layer, and now I decide to transfer either of the > > points to another layer. As both endpoints of the segment must be in > > the same layer as the segment itself, what should be the expected way to > > handle this operation? Should the program allow the point to move, and > > then by default transfer the segment as well, or should this operation > > raise an error? > > I guess my question would be: Why would I want to transfer only the > points? Is there a use case where only the points need transerring, > and not the segment? I was thinking that user might try to perform an entity transfer by selecting points, either interactively or through a script. Normally I would suspect that someone wanting to transfer a segment from layer A to layer B would select the segment to do the operation, but there is nothing in the code now to prohibit trying to do this via point transfer. I'm trying to cover all the bases, and if that approach doesn't work then the next step is to start restricting the way that some task can be accomplished. > (I suppose you might want to *copy* some points from one layer to > another, but that's a different use than *moving* the points.) It is, but what you wrote above made me think that a 'clone-to-layer' operation would be useful. I have to keep that idea around ... > > If the segment was to be transferred between layers, it will > > automagically transfer the points if possible (in the initial writing > > of the new code), so there is an implicit object transferring > > in some operations already. > > Sounds reasonable to me. Thanks for the comments. 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 Tue Feb 7 22:39:48 2006 From: sdb at cloud9.net (Stuart Brorson) Date: Tue, 7 Feb 2006 16:39:48 -0500 (EST) Subject: [PythonCAD] Question about transferring objects between layers In-Reply-To: <20060207210257.GL28121@artsapartment.org> from "Art Haas" at Feb 07, 2006 03:02:57 PM Message-ID: <20060207213948.5A6C52AA07@earl-grey.cloud9.net> > > On Tue, Feb 07, 2006 at 03:43:25PM -0500, Stuart Brorson wrote: > > Hi -- > > > > > Suppose we have a segment S and its two endpoints P1 and P2. These three > > > objects are in some layer, and now I decide to transfer either of the > > > points to another layer. As both endpoints of the segment must be in > > > the same layer as the segment itself, what should be the expected way to > > > handle this operation? Should the program allow the point to move, and > > > then by default transfer the segment as well, or should this operation > > > raise an error? > > > > I guess my question would be: Why would I want to transfer only the > > points? Is there a use case where only the points need transerring, > > and not the segment? > > I was thinking that user might try to perform an entity transfer by > selecting points, either interactively or through a script. Normally I > would suspect that someone wanting to transfer a segment from layer A to > layer B would select the segment to do the operation, but there is > nothing in the code now to prohibit trying to do this via point > transfer. I'm trying to cover all the bases, and if that approach > doesn't work then the next step is to start restricting the way that > some task can be accomplished. Actually, I suppose I would choose the KISS approach: If the user only selects the points to move, and doesn't select the segment too, then let him move only the points. Don't flag an error, and don't try to do anything smart like moving the segment too. It's really up to the user to select all the objects he wants to move. OTOH, if the user selects only the segment, should the points move also? This case is more nuanced. Question: Must a segment have endpoints in PythonCAD? If so, what purpose do they serve? For example, can I click on them and drag them to stretch the segment? If so, they are part of the segment. In that case, the points should get autoselected when the user selects the segment, and they move with the segment. OTOH, If the endpoints don't do anything for the segment, why have them in PythonCAD at all? > > (I suppose you might want to *copy* some points from one layer to > > another, but that's a different use than *moving* the points.) > > It is, but what you wrote above made me think that a 'clone-to-layer' > operation would be useful. I have to keep that idea around ... Yes, I think PythonCAD should have both "move" and "copy" operations which work between layers. Thanks, Stuart From ahaas at airmail.net Tue Feb 7 23:06:44 2006 From: ahaas at airmail.net (Art Haas) Date: Tue, 7 Feb 2006 16:06:44 -0600 Subject: [PythonCAD] [PATCH] Fix for undo/redo operations on DimString entities Message-ID: <20060207220644.GN28121@artsapartment.org> Hi. The small diff below fixes a problem I found when trying to undo a color change on a DimString entity. I'm sending this out to the list if people want to patch their copy of the latest release, and those of you using Subversion can just run 'svn update' to get this change as well. Sorry it didn't make it into the last release. Art Index: PythonCAD/Generic/dimension.py =================================================================== --- PythonCAD/Generic/dimension.py (revision 2157) +++ PythonCAD/Generic/dimension.py (revision 2158) @@ -194,6 +194,18 @@ _data.setValue('print_decimal', self.__print_decimal) return _data + def getParent(self): + """Get the entity containing the DimString. + +getParent() + +This method overrides the Entity::getParent() call. + """ + _parent = None + if self.__dim is not None: + _parent = self.__dim.getParent() + return _parent + def setLocation(self, x, y): """Set the location of the DimString. -- 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 scratchcomputing at gmail.com Tue Feb 7 22:35:36 2006 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Tue, 7 Feb 2006 13:35:36 -0800 Subject: [PythonCAD] Question about transferring objects between layers In-Reply-To: <20060207200335.GK28121@artsapartment.org> References: <20060207200335.GK28121@artsapartment.org> Message-ID: <200602071335.36911.ewilhelm@cpan.org> # from Art Haas # on Tuesday 07 February 2006 12:03 pm: >So, how do other CAD packages that hold drawing entities in layers >behave if the operation to transfer the entity results in the >entity having pieces of itself in both layers? I am inclined to >code things so that the entity is automagically transferred, but there >will certainly be times this behavior will be unexpected. Art, I do not know of any CAD programs where entities can be manipulated in pieces. If the points belong to the entity, you should not be able to change their layer property (they should not have a layer property.) If the points are first-class entities, then it doesn't matter whether they're on a different layer than the segment, etc. If the points are some sort of relational controller (e.g. changing the position of a point modifies one or more entities) then they should either be on a special layer or in some other global context where layers don't apply and there should be a set of tools (or modes for the existing tools) specifically intended to edit them. If this is the case, then the "change layer" action ignores points. I've rambled on this list before about the points being anything other than a child/property of an entity. That's part of the reason why. --Eric -- Like a lot of people, I was mathematically abused as a child. --Paul Graham --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From pachi at mmn-arquitectos.com Wed Feb 8 11:01:37 2006 From: pachi at mmn-arquitectos.com (Rafael Villar Burke) Date: Wed, 08 Feb 2006 11:01:37 +0100 Subject: [PythonCAD] Question about transferring objects between layers In-Reply-To: <20060207200335.GK28121@artsapartment.org> References: <20060207200335.GK28121@artsapartment.org> Message-ID: <43E9C181.1000804@mmn-arquitectos.com> Art Haas escribi?: > Hi. > > As I wrote in an earlier message, I've started reworking the code that > handles transferring objects between layers. While starting to make > some of the planned changes, I thought of a scenario that could occur > and wonder how other packages that use layers handle it. > > Suppose we have a segment S and its two endpoints P1 and P2. These three > objects are in some layer, and now I decide to transfer either of the > points to another layer. As both endpoints of the segment must be in > the same layer as the segment itself, what should be the expected way to > handle this operation? Should the program allow the point to move, and > then by default transfer the segment as well, or should this operation > raise an error? In other CAD packages (my main experience is through using AutoCAD and CAD/FEM analysis tools, some Microstation work and having a look at what Arris and other CAD tools do), those points are internal entities and are usually referred to as "grips". They are just a convenience for the manipulation of those entities, but are a block with the main entity. Only in special cases (such as lines in a polyline, lines of text in a multitext element, or lines and other drawing elements in hatch patterns) those entities can be splitted using a "explode" command. In none of these cases points become new usable entities, they are there just as special points to manipulate entities (you don't draw them, BTW, you end up with them, but just as an implementation detail). > So, how do other CAD packages that hold drawing entities in layers > behave if the operation to transfer the entity results in the > entity having pieces of itself in both layers? I am inclined to > code things so that the entity is automagically transferred, but there > will certainly be times this behavior will be unexpected. > This is the most natural choice, IMHO. Other options are much more prone to weird semantics. > Art > Great work and I hope this helps you, Rafael Villar Burke From w.knol at niwa.co.nz Fri Feb 10 05:05:11 2006 From: w.knol at niwa.co.nz (Wilbert Knol) Date: Fri, 10 Feb 2006 17:05:11 +1300 Subject: [PythonCAD] Moving objects breaks dimensions Message-ID: <200602101705.11429.w.knol@niwa.co.nz> I have just done 'svn update' to revision 2158. Test driving this revision (as well as previous revisions) I find that moving objects that have dimensions attached to them doesn't work properly. The end points of the dimension line get moved, along with the object (a rectangle) but the center of the dim. line along with the value stays behind. I see that this revision (and previous ones) of Pythoncad pumps out copious amounts of 'SDB Debug' lines. If Stuart's patches haven't been incorporated into Pythoncad, then this would indicate that there is some funny business going on with my code. The svn update was successfull as per below: [wk at wk pythoncad]$ svn update U pythoncad.spec U www/download.html U www/index.html U www/checklist.html U setup.py U PythonCAD/Interface/Gtk/gtkmodify.py U PythonCAD/Interface/Gtk/gtkmenus.py U PythonCAD/Generic/tools.py U PythonCAD/Generic/move.py U PythonCAD/Generic/layer.py U PythonCAD/Generic/dimension.py U PythonCAD/Generic/transfer.py U gtkpycad.py U TODO U NEWS Updated to revision 2158. [wk at wk pythoncad]$ -- Wilbert. From ahaas at airmail.net Fri Feb 10 18:48:34 2006 From: ahaas at airmail.net (Art Haas) Date: Fri, 10 Feb 2006 11:48:34 -0600 Subject: [PythonCAD] Moving objects breaks dimensions In-Reply-To: <200602101705.11429.w.knol@niwa.co.nz> References: <200602101705.11429.w.knol@niwa.co.nz> Message-ID: <20060210174834.GK19080@artsapartment.org> On Fri, Feb 10, 2006 at 05:05:11PM +1300, Wilbert Knol wrote: > I have just done 'svn update' to revision 2158. > > Test driving this revision (as well as previous revisions) I find that > moving objects that have dimensions attached to them doesn't work > properly. The end points of the dimension line get moved, along with > the object (a rectangle) but the center of the dim. line along with > the value stays behind. This behavior is by design, but it may not be what is expected. Moving a dimension is really just moving the dimension text DimString entities, so things have been coded so that moving the points in some entity does not automagically move the DimStrings of associated dimensions. It could be time to reassess this decision ... > I see that this revision (and previous ones) of Pythoncad pumps out > copious amounts of 'SDB Debug' lines. If Stuart's patches haven't > been incorporated into Pythoncad, then this would indicate that there > is some funny business going on with my code. > > The svn update was successfull as per below: > > [wk at wk pythoncad]$ svn update > U pythoncad.spec > U www/download.html > U www/index.html > U www/checklist.html > U setup.py > U PythonCAD/Interface/Gtk/gtkmodify.py > U PythonCAD/Interface/Gtk/gtkmenus.py > U PythonCAD/Generic/tools.py > U PythonCAD/Generic/move.py > U PythonCAD/Generic/layer.py > U PythonCAD/Generic/dimension.py > U PythonCAD/Generic/transfer.py > U gtkpycad.py > U TODO > U NEWS > Updated to revision 2158. > [wk at wk pythoncad]$ There are no notices of merge conflicts or other oddities, so it looks like your subversion repo is in good shape. 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 Feb 10 23:29:02 2006 From: ahaas at airmail.net (Art Haas) Date: Fri, 10 Feb 2006 16:29:02 -0600 Subject: [PythonCAD] Dimension changes in the repo Message-ID: <20060210222902.GL19080@artsapartment.org> Hi. I've sent my changes this week to the repo. While working on the entity transfer stuff I started to think about how the code for creating Dimension entities was designed. The arguments needed to create a dimension were points, circles, or arcs plus layer arguments. The code would try to establish that the referenced point, circle, or arc existed in the corresponding layer argument, and things worked well enough. Thinking about this I realized that the layer argument is essentially pointless now that the same info can be retrieved with a getParent() call on the point, circle, or arc, so why require it? The layer is only necessary during file save and reload operations, and a simple test to ensure the getParent() call does not return None provides a good test to ensure the dimension is "sane". I went in and changed the various __init__() methods for the dimension and removed the layer arguments, then adjusted the code to match up the fewer arguments, and while doing this made a couple of other simplifications and cleanups as well. After playing with these changes for a bit, I decided they made sense so I commited them to the repo, and have pushed the changes out for other to examine. Do an 'svn update' and you'll get them, plus a few small bug fixes as well. A few runs of 'pychecker' turned up some embarrasing typos, and going over some of the older code I found a few other goofs 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 scratchcomputing at gmail.com Sat Feb 11 00:58:29 2006 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Fri, 10 Feb 2006 15:58:29 -0800 Subject: [PythonCAD] Moving objects breaks dimensions In-Reply-To: <20060210174834.GK19080@artsapartment.org> References: <200602101705.11429.w.knol@niwa.co.nz> <20060210174834.GK19080@artsapartment.org> Message-ID: <200602101558.29593.ewilhelm@cpan.org> # from Art Haas # on Friday 10 February 2006 09:48 am: >> Test driving this revision (as well as previous revisions) I find >> that moving objects that have dimensions attached to them doesn't >> work properly. The end points of the dimension line get moved, along >> with the object (a rectangle) but the center of the dim. line along >> with the value stays behind. > >This behavior is by design, but it may not be what is expected. Moving > a dimension is really just moving the dimension text DimString > entities, so things have been coded so that moving the points in some > entity does not automagically move the DimStrings of associated > dimensions. It could be time to reassess this decision ... fwiw, autocad doesn't try to make any association between dimensions and entities. If you want to move an entity and related dimensions, you just select them all together. That's not so handy when you're changing the endpoint of an entity, but I haven't noticed this as a major stumbling block. If the design is such that dimensions are going to be relational, it might be worth considering storing the placement as a relative value (possibly even keeping the axial coordinate (e.g. "local x") as a percentage of length on linear dimensions) so that it can better follow along with changes to the entity. --Eric -- Consumers want choice, consumers want openness. --Rob Glaser --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From w.knol at niwa.co.nz Sat Feb 11 02:43:08 2006 From: w.knol at niwa.co.nz (Wilbert Knol) Date: Sat, 11 Feb 2006 14:43:08 +1300 Subject: [PythonCAD] Moving objects breaks dimensions In-Reply-To: <200602101558.29593.ewilhelm@cpan.org> References: <200602101705.11429.w.knol@niwa.co.nz> <20060210174834.GK19080@artsapartment.org> <200602101558.29593.ewilhelm@cpan.org> Message-ID: <200602111443.08179.w.knol@niwa.co.nz> > >> Test driving this revision (as well as previous revisions) I find > >> that moving objects that have dimensions attached to them doesn't > >> work properly. The end points of the dimension line get moved, along > >> with the object (a rectangle) but the center of the dim. line along > >> with the value stays behind. > > > >This behavior is by design, but it may not be what is expected. Moving > > a dimension is really just moving the dimension text DimString > > entities, so things have been coded so that moving the points in some > > entity does not automagically move the DimStrings of associated > > dimensions. It could be time to reassess this decision ... > > fwiw, autocad doesn't try to make any association between dimensions and > entities. If you want to move an entity and related dimensions, you > just select them all together. Agreed, and that's exactly what I did. I drew a box around the lot and tried to shift it. It worked...except for the dimension text, and the centre part of the dimension line, which stayed put along with the dim. text. The arrows rubber-banded with the object to the new location. I must admit I was somewhat taken aback :-) Wilbert. From ahaas at airmail.net Sat Feb 11 16:37:37 2006 From: ahaas at airmail.net (Art Haas) Date: Sat, 11 Feb 2006 09:37:37 -0600 Subject: [PythonCAD] Moving objects breaks dimensions In-Reply-To: <200602111443.08179.w.knol@niwa.co.nz> References: <200602101705.11429.w.knol@niwa.co.nz> <20060210174834.GK19080@artsapartment.org> <200602101558.29593.ewilhelm@cpan.org> <200602111443.08179.w.knol@niwa.co.nz> Message-ID: <20060211153737.GB7091@artsapartment.org> On Sat, Feb 11, 2006 at 02:43:08PM +1300, Wilbert Knol wrote: > > > fwiw, autocad doesn't try to make any association between dimensions and > > entities. If you want to move an entity and related dimensions, you > > just select them all together. > > Agreed, and that's exactly what I did. I drew a box around the lot and tried > to shift it. > > It worked...except for the dimension text, and the centre part of the > dimension line, which stayed put along with the dim. text. The arrows > rubber-banded with the object to the new location. > > I must admit I was somewhat taken aback :-) I see if I can duplicate this today. If you drew a box around the dimension in addition to the entities then the dimension text should have moved. Maybe there is a bug in determining that the dimension was within the boxed region. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Mon Feb 13 16:45:25 2006 From: ahaas at airmail.net (Art Haas) Date: Mon, 13 Feb 2006 09:45:25 -0600 Subject: [PythonCAD] Moving objects breaks dimensions In-Reply-To: <20060211153737.GB7091@artsapartment.org> References: <200602101705.11429.w.knol@niwa.co.nz> <20060210174834.GK19080@artsapartment.org> <200602101558.29593.ewilhelm@cpan.org> <200602111443.08179.w.knol@niwa.co.nz> <20060211153737.GB7091@artsapartment.org> Message-ID: <20060213154525.GB2708@artsapartment.org> On Sat, Feb 11, 2006 at 09:37:37AM -0600, Art Haas wrote: > > I see if I can duplicate this today. If you drew a box around the > dimension in addition to the entities then the dimension text should > have moved. Maybe there is a bug in determining that the dimension > was within the boxed region. Ugh. I found a stupid typo, but this does not completely resolve things. I am embarrassed ... Index: PythonCAD/Generic/move.py =================================================================== --- PythonCAD/Generic/move.py (revision 2166) +++ PythonCAD/Generic/move.py (revision 2167) @@ -599,7 +599,7 @@ elif isinstance(_obj, Polyline): _move_polyline(_obj, _objdict, _dx, _dy) elif isinstance(_obj, (TextBlock, Dimension)): - _obj.move(_nx, _ny) + _obj.move(_dx, _dy) elif isinstance(_obj, (HCLine, VCLine, ACLine)): _move_spcline(_obj, _objdict, _dx, _dy) elif isinstance(_obj, (Chamfer, Fillet)): -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Mon Feb 13 17:14:33 2006 From: ahaas at airmail.net (Art Haas) Date: Mon, 13 Feb 2006 10:14:33 -0600 Subject: [PythonCAD] Moving objects breaks dimensions In-Reply-To: <20060213154525.GB2708@artsapartment.org> References: <200602101705.11429.w.knol@niwa.co.nz> <20060210174834.GK19080@artsapartment.org> <200602101558.29593.ewilhelm@cpan.org> <200602111443.08179.w.knol@niwa.co.nz> <20060211153737.GB7091@artsapartment.org> <20060213154525.GB2708@artsapartment.org> Message-ID: <20060213161433.GC2708@artsapartment.org> On Mon, Feb 13, 2006 at 09:45:25AM -0600, Art Haas wrote: > On Sat, Feb 11, 2006 at 09:37:37AM -0600, Art Haas wrote: > > > > I see if I can duplicate this today. If you drew a box around the > > dimension in addition to the entities then the dimension text should > > have moved. Maybe there is a bug in determining that the dimension > > was within the boxed region. > > Ugh. I found a stupid typo, but this does not completely resolve > things. I am embarrassed ... I've prepared a better patch. In addition to fixing the dumb typo it resolves the problem where the DimString entities do not move. The loop where users of Point entities needed to be touched up so that the flag used to test moving Dimension entities is not set to False. Index: PythonCAD/Generic/move.py =================================================================== --- PythonCAD/Generic/move.py (revision 2166) +++ PythonCAD/Generic/move.py (revision 2168) @@ -34,7 +34,7 @@ from PythonCAD.Generic.leader import Leader from PythonCAD.Generic.polyline import Polyline from PythonCAD.Generic.text import TextBlock -from PythonCAD.Generic.dimension import Dimension +from PythonCAD.Generic.dimension import Dimension, DimString from PythonCAD.Generic.dimension import LinearDimension from PythonCAD.Generic.dimension import AngularDimension from PythonCAD.Generic.layer import Layer @@ -576,9 +576,12 @@ _objdict = {} _fillets = [] for _obj in objs: - _objdict[id(_obj)] = True + if not isinstance(_obj, DimString): + _objdict[id(_obj)] = True for _obj in objs: _oid = id(_obj) + if _oid not in _objdict: + continue if _objdict[_oid]: if isinstance(_obj, Point): _obj.move(_dx, _dy) @@ -586,7 +589,8 @@ _user = _uref() if _user is not None: _uid = id(_user) - if _uid in _objdict: + if (_uid in _objdict and + not isinstance(_user, Dimension)): _objdict[_uid] = False elif isinstance(_obj, (Segment, CLine)): _move_seg_cline(_obj, _objdict, _dx, _dy) @@ -599,7 +603,7 @@ elif isinstance(_obj, Polyline): _move_polyline(_obj, _objdict, _dx, _dy) elif isinstance(_obj, (TextBlock, Dimension)): - _obj.move(_nx, _ny) + _obj.move(_dx, _dy) elif isinstance(_obj, (HCLine, VCLine, ACLine)): _move_spcline(_obj, _objdict, _dx, _dy) elif isinstance(_obj, (Chamfer, Fillet)): -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Mon Feb 13 19:17:01 2006 From: ahaas at airmail.net (Art Haas) Date: Mon, 13 Feb 2006 12:17:01 -0600 Subject: [PythonCAD] Moving objects breaks dimensions In-Reply-To: <200602101705.11429.w.knol@niwa.co.nz> References: <200602101705.11429.w.knol@niwa.co.nz> Message-ID: <20060213181701.GE2708@artsapartment.org> On Fri, Feb 10, 2006 at 05:05:11PM +1300, Wilbert Knol wrote: > I have just done 'svn update' to revision 2158. > > Test driving this revision (as well as previous revisions) I find that > moving objects that have dimensions attached to them doesn't work > properly. The end points of the dimension line get moved, along with > the object (a rectangle) but the center of the dim. line along with > the value stays behind. Fixing this problem (see the patches I posted to an eariler reply) also showed me that moving a dimension was not undoable. This shortcoming has now been fixed, and for those of you using subversion you can get the changes via 'svn update'. Also, deleting a dimension and then undoing this operation would cause an error because I'd missing some places in the 'layer.py' file that create Dimension entities, so the calls had the now superfluous layer arguments. This bug is also fixed. 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 Mon Feb 13 20:58:59 2006 From: w.knol at niwa.co.nz (Wilbert Knol) Date: Tue, 14 Feb 2006 08:58:59 +1300 Subject: [PythonCAD] dimstring patches Message-ID: <200602140858.59965.w.knol@niwa.co.nz> I used 'svn update' and moving entities and their dimensions works perfectly now, Art. Good job! Wilbert. From ahaas at airmail.net Mon Feb 13 22:10:05 2006 From: ahaas at airmail.net (Art Haas) Date: Mon, 13 Feb 2006 15:10:05 -0600 Subject: [PythonCAD] dimstring patches In-Reply-To: <200602140858.59965.w.knol@niwa.co.nz> References: <200602140858.59965.w.knol@niwa.co.nz> Message-ID: <20060213211005.GG2708@artsapartment.org> On Tue, Feb 14, 2006 at 08:58:59AM +1300, Wilbert Knol wrote: > I used 'svn update' and moving entities and their dimensions works > perfectly now, Art. Good job! Thanks for confirming the changes work. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Tue Feb 21 21:46:16 2006 From: ahaas at airmail.net (Art Haas) Date: Tue, 21 Feb 2006 14:46:16 -0600 Subject: [PythonCAD] First take of new entity transfer code now at repo Message-ID: <20060221204616.GG1657@artsapartment.org> Hi. The reworking of the code handling the transfer of entities between layers has been moving along, and I've checked in the code to my repo. While making these changes I found a number of other bugs, glitches, and shortcomings elsewhere in the code, so I've been fixing those problems as well. AngularDimension and RadialDimension entities have been making things interesting, in particular, as those two classes had a latent bug or two lurking that came out in the last couple of days. In addition to the transfer work, the delete_objects() routine in delete.py was rewritten to make it utilize routines like getParent(), and while doing this I made the code a bit more robust as well as flexible. I'll send my transfer code changes to the repo, but if you wish to try out the code by updating your repo with 'svn update' be aware that the code is still somewhat in flux as I'm trying to track down a number of issues that have arisen with undo/redo operations dealing with transferring the entities between layers. I hope things will stablize in a day or two. If you do an 'svn update' please test out the transfer of entities and let me know how things work for you. Thanks. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Thu Feb 23 18:07:47 2006 From: ahaas at airmail.net (Art Haas) Date: Thu, 23 Feb 2006 11:07:47 -0600 Subject: [PythonCAD] First take of new entity transfer code now at repo Message-ID: <20060223170747.GP1657@artsapartment.org> On Tue, Feb 21, 2006 at 02:46:16PM -0600, Art Haas wrote: > > I'll send my transfer code changes to the repo, but if you wish to try > out the code by updating your repo with 'svn update' be aware that the > code is still somewhat in flux as I'm trying to track down a number of > issues that have arisen with undo/redo operations dealing with > transferring the entities between layers. I hope things will stablize in > a day or two. If you do an 'svn update' please test out the transfer > of entities and let me know how things work for you. > I've fixed one problem regarding undo/redo by cleaning up the _delPoint() method in the Layer class, but other issues still remain. The fix has been sent to the repo and is available via 'svn update'. 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 Feb 23 21:19:03 2006 From: ahaas at airmail.net (Art Haas) Date: Thu, 23 Feb 2006 14:19:03 -0600 Subject: [PythonCAD] First take of new entity transfer code now at repo In-Reply-To: <20060223170747.GP1657@artsapartment.org> References: <20060223170747.GP1657@artsapartment.org> Message-ID: <20060223201903.GR1657@artsapartment.org> On Thu, Feb 23, 2006 at 11:07:47AM -0600, Art Haas wrote: > On Tue, Feb 21, 2006 at 02:46:16PM -0600, Art Haas wrote: > > > > I'll send my transfer code changes to the repo, but if you wish to try > > out the code by updating your repo with 'svn update' be aware that the > > code is still somewhat in flux as I'm trying to track down a number of > > issues that have arisen with undo/redo operations dealing with > > transferring the entities between layers. I hope things will stablize in > > a day or two. If you do an 'svn update' please test out the transfer > > of entities and let me know how things work for you. > > > > I've fixed one problem regarding undo/redo by cleaning up the > _delPoint() method in the Layer class, but other issues still remain. > The fix has been sent to the repo and is available via 'svn update'. The second issue I was seeing has now been fixed. It was a problem in the code that removed an entity from the list of children of a given entity. This bug has been lying there since the code was changed to permit equivalent entities to reside in a layer, and I suppose it is just luck that it hasn't appeared sooner. The fix has been sent to the repo and is available for those using subversion by 'svn update'. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Sat Feb 25 20:40:15 2006 From: ahaas at airmail.net (Art Haas) Date: Sat, 25 Feb 2006 13:40:15 -0600 Subject: [PythonCAD] Subversion binary updated Message-ID: <20060225194015.GB1613@artsapartment.org> Hi. Just a heads up to inform everyone that the Subversion binary on the repo machine has been updated to the latest revsion, as has Apache. Please let me know if you have trouble accessing the repo. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Sat Feb 25 22:38:22 2006 From: ahaas at airmail.net (Art Haas) Date: Sat, 25 Feb 2006 15:38:22 -0600 Subject: [PythonCAD] Subversion binary updated In-Reply-To: <20060225194015.GB1613@artsapartment.org> References: <20060225194015.GB1613@artsapartment.org> Message-ID: <20060225213822.GC1613@artsapartment.org> On Sat, Feb 25, 2006 at 01:40:15PM -0600, Art Haas wrote: > > Just a heads up to inform everyone that the Subversion binary on the > repo machine has been updated to the latest revsion, as has Apache. > Please let me know if you have trouble accessing the repo. It appears there's a snag where the repo is unexpectedly requiring authorization. The 'httpd.conf' file looks correct but things aren't working as they had been, so I'm a bit stumped right now. Hold off trying to access the repo for a while as I'm trying to get things working again. Sorry about this. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Sat Feb 25 23:09:47 2006 From: ahaas at airmail.net (Art Haas) Date: Sat, 25 Feb 2006 16:09:47 -0600 Subject: [PythonCAD] Subversion binary updated In-Reply-To: <20060225213822.GC1613@artsapartment.org> References: <20060225194015.GB1613@artsapartment.org> <20060225213822.GC1613@artsapartment.org> Message-ID: <20060225220947.GD1613@artsapartment.org> On Sat, Feb 25, 2006 at 03:38:22PM -0600, Art Haas wrote: > On Sat, Feb 25, 2006 at 01:40:15PM -0600, Art Haas wrote: > > > > Just a heads up to inform everyone that the Subversion binary on the > > repo machine has been updated to the latest revsion, as has Apache. > > Please let me know if you have trouble accessing the repo. > > It appears there's a snag where the repo is unexpectedly requiring > authorization. The 'httpd.conf' file looks correct but things aren't > working as they had been, so I'm a bit stumped right now. Hold off > trying to access the repo for a while as I'm trying to get things > working again. > > Sorry about this. I've removed the binaries I built and installed today and replaced them with the previous working versions. The problem appears to be some recent changes in Apache dealing with authorization, or so I gather from looking at the httpd-dev mailing list. So much for the update, but things work 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 From ahaas at airmail.net Tue Feb 28 21:16:56 2006 From: ahaas at airmail.net (Art Haas) Date: Tue, 28 Feb 2006 14:16:56 -0600 Subject: [PythonCAD] More updates at repo and release probable this week Message-ID: <20060228201656.GG2618@artsapartment.org> Hi. I've sent another batch of changes to the repo. At long last, the ability to toggle the RadialDimension entities to display the value of a diameter instead of a radius is now available, and the ability to invert an AngularDimension is also present as well. There is a redraw glitch with the AngularDimension that I'm going to get fixed, hopefully today or tomorrow. For those using subversion the new code is just an 'svn update' away. I'm probably going to make the next release Thursday or Friday. The new code for transferring entities, plus the changes above, and the various bug fixes over the last month make it seem like a new release is warranted. Plus I'll be getting back to the quicker release plan that I'd mentioned earlier. 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