[PythonCAD] New patches to PythonCAD . . . .

[Art Haas]

On Mon, Dec 12, 2005 at 05:19:20PM -0500, Stuart Brorson wrote:
> Art --
> 
> > The current move behavior, that is the distance specification prior to
> > the entity specification, was how I remember doing move operations
> > in ME-10. As you point out, this approach is inconsistent with other
> > PythonCAD operations, and in many cases the reverse procedure in how
> > other programs expect the user to modify the entities built and
> > controlled in that program. The internal PythonCAD inconsistency has
> > become more bothersome to me, and a note to fix things was added into
> > the TODO file included in the latest release. So, I definitely want to
> > make some changes so that PythonCAD is consistent and performing one
> > type of operation should at least give you a reasonable guess on the
> > steps needed to perform some other change.
> 
> As I said in a different e-mail, I prefer the "first select, then act"
> behavior for driving a program.  I realize that lots of programs don't
> behave this way.  I think, however, that "select action, then select
> objects" is the older, obsolete behavior.  
> 
> The gold standard drawing program IMO is Visio.  I find it simply
> great, despite being an MS product.  (Of course, it's not an
> internally developed program, but rather something they bought.)
> Visio uses a strict "select then act" paradigm.
> 
> YMMV, of course.

I've never used Visio, so I'm not familiar with how it works. As for CAD
software, I haven't used AutoCAD in years, and my ME-10 work stopped
around 1998, so I don't know what the current program does, or for that
matter if it is still around.
 
> > > Note that I had to make one architectural change to make "select
> > > first, then act" work for text objects:  I had to make TextBlock a
> > > subclass of GraphicObject (it was subclassed to Entity).  Without this
> > > change, text wouldn't move using
> > > PythonCAD.Generic.move.move_objects().  Now moving text works, but I
> > > get lots warning spew when the program is run and addStyle is called.
> > > The program seems to work anyway.  The warning spew occurs because
> > > _layerAddedChild tries to setStyle or getStyle on the
> > > text.  Maybe I need to add a Style parameter to TextBlock?  Or make
> > > the conditional (isinstance(_obj,  GraphicObject)) return true for
> > > text by defining a different type of class which can be moved?  In any
> > > event, if you don't like my changes, I didn't want to get too far
> > > ahead in cleaning up this issue.
> > 
> > I don't like the change to the TextBlock class, because making that
> > class be a subclass of GraphicObject implies that at TextBlock needs
> > the style, linetype, and thickness attributes that a GraphicObject
> > instance utilizes. A peek at move_objects() suggests that there
> > should not be any changes needed to handle moving TextBlocks, so I'm not
> > sure why the change was necessary. After I dig into things a little
> > deeper maybe I'll achieve enlightenment.
> 
> That's fine.  I found that without this change, the bits of text
> annotation I had placed in my drawings weren't moving.   Maybe there's
> a better way. . . .
 
In the patch I posted I didn't make any changes to the TextBlock code
and I was able to move TextBlock instances without error.

> > I'm going to make the change to the horizontal moving to behave as your
> > patch would have it, and I'll use some of your changes as a starting
> > point. I suspect that I'll tweak some of your changes a bit, so what
> > I'll do is send out some diffs when things look like I think they
> > should, then we can see how things looks.
> > 
> > > 2.  Next change:  Added stuff to Entry, TreeView, and
> > > window_general_event to try to make entry box behave as I want, but
> > > also pass arrow keys to the TreeView, which is what you want.  That
> > > is, I want to type numbers into the Entry widget at the bottom of the
> > > window when asked for numerical input (e.g. when making a move).  My
> > > changes seem to work, but you must sometimes
> > > first select the LayerDisplay area with the mouse.  That is, when the
> > > Entry box has the focus, it doesn't let any arrow keys past it to get
> > > to the TreeView. I can look at that more, but first wanted to gague
> > > your interest in this change.
> > 
> > I'll look at this stuff after playing with the move changes. Again, I
> > definitely want making numerical input from the keyboard work when the
> > focus is in the layer display, as the unexpected appearance of the entry
> > box is, well, unexpected.
> 
> I'll wait for a day or two and then do an "svn update".  After that I
> can implement the "select first then act" behavior everywhere -- with
> your blessing, of course.

Let me know what you think of the patch I posted for implementing
selection first moving. A coding plus of using this approach is the need
for a motion-notify handler after the first button press is removed
because there is no need to try and draw a box for selecting 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