Hi everyone!
Good news! 3D box coding finally has had a new visible effect: Boxes are now resizable 'in perspective'. The current version by default provides three handles for each box, two on the front face (which we consider lying in XY plane) and one on the rear face (for the Z direcion). (As a sidenote, observe that the labelling of the Y and Z axis has been changed compared to the last version.)
The first two handles can be used to arbitrarily resize the box inside the XY-plane, the third one obviously resizes it in the direction of the Z axis. When Shift is being pressed, the movement temporarily becomes constrained to a single axis for the first two handles and switches to occuring inside the XY plane for the third handle. (Try it, this is more intuitive than it sounds.)
However, this is only one of many possible scenarios. As an alternative, I have implemented a second variant where the box has four handles and all but the circle-shaped one (which acts as a kind of 'master handle') use constrained dragging by default.
It is possible to switch between these two variants using the corresponding toggle buttons in the 3D box toolbar showing three/four knots, respectively. These buttons are for convenience only and will disappear once the definitive behaviour is settled.
I would very much appreciate your feedback what kind of behaviour you consider most intuitive. This could certainly also be a mixture of the two, or there could be a different number of handles, or they could be at different corners, or ... Tell me what you think is most natural. (It probably depends on the perspective, too; try toggling the states of the vanishing points from infinite to finite using the corresponding buttons and see whether this makes a difference). BTW, the 3D box tool now has the shortcuts Shift-F4 and X so that it's not necessary to manually change line #143 in widgets/toolbox.cpp to unhide the toolbox icon.
In case you are wondering why this new feature has taken so long since my last email: I have constantly been refactoring the code under the hood because it was extremely cumbersome at that time, making expansion and implementation of new features rather difficult. But I believe that the current internal representation is sufficiently elegant and generic so that further development should be much quicker (and with a lot more visible effects anyway).
Next I am going to attack the style issues Bulia mentioned in one of his last emails (sorry that this has lied idle in the meantime). Alternatively, I could implement draggable vanishing points first. Bulia, what do you think is more important?
Thanks for all your feedback and best regards, Max
====
P.S.: While I am at it I'd also like to pose a few questions regarding small bugs that can possibly spare me a good deal of scouring the code. Maybe someone has a quick hint where to look.
1) After resizing the box, undo (Ctrl-Z) correctly undoes the change of size but the corresponding handle remains at the altered position. How can I make the handle undo-aware, too?
2) Toggling the state of a vanishing point is not undo-able either. How can I change that? Do I need to register the corresponding action somewhere?
3) With the 3D box tool active, clicking on an already created but currently unselected box only selects a single face instead of the whole box. I suspect this is related to the fact that the box is implemented as a group of paths (which represent the separate faces). How can I pass the click on to the parent box? Can this be done by tagging the paths as objects of sodipodi:type="inkscape:3dboxface" (which I would have to do for the style stuff anyway) and catching the select action?
Thanks!