[PythonCAD] New patches to PythonCAD . . . .

[Art Haas]

On Fri, Dec 09, 2005 at 02:09:01PM -0500, Stuart Brorson wrote:
> 
> I've been silent for a while!  Thanks for the most recent release of
> PythonCAD!

Glad you like it!

> I have recently had a little time to do some hacking on PythonCAD.  In
> particular, I have implemented the following two changes:
> 
> 1.  I have long wanted to move objects on the following way:
> 
>    1.  Select all objects to be moved.  They highlight upon
>        selection.
>    2.  Do "modify -> move -> move horizontal"
>    3a. 1  The user types in the distance to move.
>           The numerical distance appears in
>           the text Entry widget at the bottom of the screen.
>    3a. 2  Hit <return>.  The selected objects move, and are
>           automatically deselected after the move.
>    -----------  <or>  ------------
>    3b. 1. The user presses the first left mouse button to define a
>           move distance.
>    3b. 2. The user presses the second left mouse button to define
>           the move distance.  The selected objects move, and
>           are automatically deselected after the move.
> 
> 
> As you know, the way it works now is:  1.  Do "modify -> move -> move
> horizontal".  2.  Define move distance.  3.  Select items to move.
> 
> Personally, I think it makes more sense to first select the items you
> want to act upon, and then do the action.  Right now PythonCAD is
> mixed: some actions are done by selecting first, then acting, and
> others are done by choosing the action and then selecting the
> objects.  As a user, I favor a consistant interface, and one where you
> select first and then act is the most common, most logical,
> and most up-to-date.
> 
> I have modified only the "modify -> move -> move horizontal" action to
> work in my preferred way.  I wanted to see how open you were to this
> kind of change.  If you do like the change, then I can modify all the
> other actions to behave this way also.  If you don't like it, that's
> too bad for me, but at least I didn't make zillions of changes.  In
> any event,  but I really think that "select first, then act" is the
> best way to drive PythonCAD, and I would appreciate it if you gave
> this method some thought.
 
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.

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

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.

> Please find my patches attached here.  Please let me know how
> interested you are in these changes, and depending upon your interest
> I can continue working on cleaning them up, or I can drop them.  BTW:
> the patches are done against revision 2077, which is the last time I
> was able to do an "svn update".  If this presents a problem, please let
> me know.

You should be able to do an 'svn update' today. If not let me know and
I'll see if I can figure out what is wrong.

> Finally, Art, you have mentioned several times doing away with GTKImage and
> replacing it with ImageView and ImageWindow.  I may have asked this 
> previously,
> but could you please give a quick top-level overview of what 
> functionality these
> two classes are supposed to implement.  I more or less understand 
> GTKImage (it's
> the top-level class for the entire user interface), but I'm less certain 
> what
> ImageView and ImageWindow are all about.

In brief, the ImageView is meant to display a drawing area with some
portion of the Image displayed within. An ImageWindow is meant to be the
graphical container for the Image itself. I'd like to code things so
that a user can display numerous ImageViews of some Image at any given
time, and each ImageView will properly update itself when the data in
the underlying Image changes. There will only be one ImageWindow
associated with the Image, however.

I'll need to go into more detail on my ideas for these classes again.

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