[PythonCAD] New patches to PythonCAD . . . .

[Stuart Brorson]

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.

> > 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. . . .

> 
> 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.

Stuart