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