Re: gEDA-user: Transformations during copying or moving operations

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Sat, 2007-06-30 at 20:02 +0100, Peter TB Brett wrote:
> Hi folks,
> 
> There are a number of bugs evident in copying and moving operations.
> 
> Firstly, it is useful to be able to rotate symbols while a move or copy is in 
> progress.  However, at the moment it is not possible to do so, as far as I 
> can tell; the "er" command cancels the current operation and carries out a 
> rotation on the original selection, while middle-clicking appears to be a 
> no-op[1].  Even when middle-clicking was not a no-op, it was heavily bugged 
> during copy in that the original selection would be rotated as well as the 
> copied version.
> 
> Secondly, it is counter-intuitive for "er" not to be the command to use for 
> rotation during move/copy.  In addition, we should try and support mirror 
> during move/copy as well (a would-be-nice change).
> 
> Finally, the way that rotations and translations are stored is currently kind 
> of messy.  Patrick Bernaud had a really good idea which he submitted a 
> sort-of-broken patch to implement: use an 2x2 matrix to represent the current 
> transformation applied to the original selection, and then "commit" the 
> transformation once the move/copy is complete (I think I remember this 
> correctly: Peter C?).

That sound correct. I'd not say the patch was sort-of-broken either, but
it was a bit of a monolith - and certainly wouldn't apply cleanly now.
It was before "noscreen". We can lean from its implementation though.

> So I'd really like some input from both users and developers on how it should 
> behave and how that behaviour should be implemented.

I think I'd like to see it implemented as part of the MMVC type
arrangement we discussed briefly.

For the benefit of others who won't get my made up acronym, MVC is
"Model View Controller" abstraction used to separate data view and
display. MMVC was supposed to contain an extra model.

Libgeda should have the data model, gschem (or a gui lib) should have
the view. The controller is kind-of the step which says "user clicked
here", and translates that to a meaningful action on the data-model.
(This might not be a good description, the controller part is the one
I'm least familiar with).

For gschem's rendering, I think we want two "models", one being
libgeda's data-structures, and a second which contains things relevant
to drawing operations (but not libgeda, or the underlying CAD
"database"). For example, a rotation or drag might need to keep state -
which would be in this second model. We can then allow multiple views
which share this info without polluting libgeda with the details of the
operation.

E.g. The controller will issue a method call such as
"geda_object_translate( object, x, y )" in response to the finished
operation.

Does a copy operation need a separate entity in the libgeda model until
it is placed? Perhaps not (I don't think it does now), but I expect it
ought to have some identity / state associated in the second, "canvas"
model if you will.

I'm keen to discuss more details with people (and help with
implementation) when I'm back from surveying in Scotland, as I have
always been keen to clean up this API where possible.

> Thanks everyone!
> 
> Peter
> 
> [1] This is recent regression which I have yet to track down.

Isn't middle clicking for a rotate that won't succeed a deliberate
no-op?


> 
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user