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 _______________________________________________ PythonCAD mailing list [email protected] http://mail.python.org/mailman/listinfo/pythoncad
