[Bf-funboard] workflow / reworking of ctrl-t, ctrl-p, ctrl-c, etc

Luke Wenke bf-funboard@blender.org
Sat, 27 Sep 2003 22:15:25 +1000


Hi Matt,
> I think some of these discussions may be getting on to the wrong track a
> bit, as some of the suggestions seem a bit un-blenderish to me.
-----------------
I am exploring methods that are easier for beginners to understand while at
the same time are good for power-users. BTW, I've addressed many of the
problems you mention before... so I may sound like I'm repeating myself.

> The Blender workflow seems intuitive and visual, and I fear that choosing
object names
> from lists etc. is quite opposite to that Blender 'feeling'. When I'm
> working I generally don't tend to name my objects (lazy perhaps?), but
work
> in the viewport. I remember something by the way it looks and it's
position,
> not by a name.
-----------------
As I said, when you are hovering your mouse over the names of the items, the
corresponding 3d object would be highlighted (perhaps in all available
views). You can move through the list quickly to see the objects highlight
and show themselves...
Or you can choose the active item like you normally do.

This is how ctrl-T currently works:
1) select some things
2) make sure the right thing is active
3) ctrl-T
4) left-click without moving the mouse (or click elsewhere or esc to cancel)

And you can do exactly the same thing using my method!
Except that instead of the menu saying:
=========
*OK?* (bold)
Make Track
=========

It would now say:
=========
*Track...* (bold)
active-item1
-----------
other-selected-item1
other-selected-item2
=========

And instead of the mouse beginning over the word "Make Track", it will
appear over "active-item1" (or whatever the active item is called).

And you can still cancel in exactly the same way to the old method. (esc or
move or click outside the menu)

-----------------
> Although Luke's method may seem just as fast (same number of mouse
clicks),
> it wouldn't be in practise, as the more inconsistency means that the user
> must spend more time remembering for a split second "oh I have to choose
the
> selection *afterwards* for this command" rather than just doing it
> naturally, the same was as everything else.
-----------------
If implemented, it should be done consistently involving all the relevant
functions of blender.

BTW, I see g/r/s as being quite different - they only involve the selected
items, and if the active item isn't selected (it is possible to select other
things while the active thing is unselected) then the active item is
ignored. On the other hand, ctrl-t, etc, always use the active item, whether
it is selected or not.
The g/r/s functions only involve one group of objects.... ctrl-t, ctrl-p,
etc, use two groups of objects (the active item and the non-active selected
items). Also, there is no pop-up menu to confirm g/r/s like ctrl-t, etc...
so they are quite different in blender.

> Although it's not as consistent as it probably should be, to me, it seems
> that most Blender tools work in a way like:
>
> 1. Select something to operate on
> 2. Invoke command (via hotkey/toolbox/menu/whatever)
> 3. Optionally visualise or predict what will happen either interactively
> (like move/rotate/scale) or non-interactively with a confirmation dialog
> with an opportunity to cancel/undo the command
> 4. Confirm or cancel the command
======================
My idea has those steps, except that the active item can be changed in steps
3 and 4 (by moving the mouse before you click or press enter). And as said
earlier you can still just select the active item in step 1 or cancel the
operation after you've press ctrl-T (using esc, etc).

> I think this sort of workflow is why Blender is quite usable without an
> 'undo' function. Rather than letting the user do things, mess up and undo
> it, Blender often gives a way out before enacting the command in the first
> place. It's like that Raskin UI theory of always giving people an exit or
a
> way to undo - Blender often does it, but more integrated with the workflow
> rather than as a separate command.
-----------------
As said earlier, that is part of my idea.

> To be consistent with this, I like beatabix's suggestion:
> 1. Select the objects as usual, with one active
> 2. Invoke track command (via hotkey/toolbox/menu/whatever)
> 3. Display a confirmation along the lines of "Track selected to <active
> object's name>" and at the same time, draw the helplines (perhaps
partially
> transparent?) from the selected objects to the active object so you can
visu
> alise what will happen when you confirm the command.
> 4. Confirm or cancel the command.
-----------------
My idea is virtually identical to that except step 3 isn't ambiguous. You
aren't actually Tracking the selected items to <active item>.... you are
only tracking the selected non-active items to the active item.

My popup menu would look like this (with the mouse beginning on the the
active object's name):
*Track....* (bold - since it is a key word)
<active item> <-(mouse pointer starts here)
------------
<other selected item 1>
<other selected item 2>
<other selected item 3>

While their mouse is hovering over active item's name, the "helplines" you
describe in (3) could be drawn.

Then you left click on <active item> (it's name in the menu, where the mouse
already is) to confirm. (or press esc - or select something else, while at
the same time the objects change to reflect which one is the new active
object)