[Bf-funboard] Re: Reworking of ctrl-t, ctrl-p, ctrl-c, etc....

[Luke Wenke]

Hi ton,
Note that I now agree that Blender's ctrl-t, ctrl-p, etc, system is probably
better, even though I am defending my idea for much of this message. You
don't need to continue to criticize my ctrl-t, etc, idea since I no longer
am supporting it. But the idea about making the current system easier to
work out and use for beginners is one that I'm currently supporting so you
might want to criticize that.
- Luke.
===========================================
================================
> > The problem is ctrl-t, ctrl-p, ctrl-c is that they currently depend on
> > what  thing was selected last (the "active selection") before the hotkey
is
> > pressed. But blender doesn't tell you that.
> The active Object is drawn (in wire) with a different (brighter) color.
> Only right-clicking makes 'active'.
================================
I know that Blender shows the last selected object a brighter colour.
My point is that Blender does say the exact significance of this when you
are using ctrl-T, ctrl-P, etc. You need to find out through trial and error
or through a tutorial. (Hotkey lists usually don't give you enough
information - they'd just say ctrl-P is "make parent" or "parent" - they
don't explain the significance of darker and lighter selections)
Also, in many operations, such as movement (g), rotation (r), etc, the
active selection is completely irrelevant. So if a beginner is used to the
active (lighter) selection seeming to be irrelevant, they may assume it is
irrelevant in other operations too... (ctrl-t, etc)

================================
> Using a border-select for example only selects.
================================
This is partly incorrect. Try it yourself... create some meshes, then use
"a" to select nothing, then use "b" to select some items. The last object
you enclosed with the border will become active.

================================
> I use border-select a lot for selecting groups, then one
> shift+rightclick makes the (future) parent active.
================================
Well my ctrl-p method is ordinarily one click shorter to do, but in that
case it would take the about same number of clicks/keypresses...
1. use b to select a group of items.
2. use shift and double right-click (or single right-click if already
active) on object you want to unselect (which was initially selected)
3. ctrl-p
4. select that unselected item (or esc)
I guess your method is slightly faster, but I didn't even know it existed.
In cases where the parent of the child objects is not close to its children,
or there is only one child, my method is faster
Or what about this: (in my method) if you select a group (using b), then use
ctrl-p, then select an object that happens to be part of the group, it will
automatically make sure the last object isn't parented to itself. So that is
three steps, which is shorter than the current method:
1. use b to select a group of items.
2. use shift and right-click to make the right one active.
3. ctrl-p
4. enter/left-click ok or esc/left-click elsewhere/mouse mouse away

================================
> Also the (buttons)  UI doesn't update with border selecting.
================================
I don't know what you mean by that.

================================
> > Blender doesn't even tell you
> > that at least two objects must be selected...
> That's true... but not a big surprise. :)
================================
But I thought the aim was to make Blender easier to use? Many or most
beginners would think that "copy" involves one selection.

================================
> > (I thought "Copy" just involved one selection, and there would be a
corresponding "Paste"
> > hotkey... but after looking through lots of hotkey lists I eventually
worked out
> > that only the "Copy" hotkey is used somehow...)
> I mailed about copy/past/cut in a mail yesterday. I agree we could
> adopt that for easier learning, but I consider the 'Duplicate' tool in
> Blender more powerful in most situations.
> Blender's current 'copy' tool is completely different from UI standard
> 'copy' BTW... it copies properties only. We also have a related CTRL+L
> tool, to create new links.
================================
I understand that ctrl-C is useful (BTW the way I think it is clearer to
call it "Copy...from..." which emphasises that only an aspect of an object
is being copied, rather than the whole object)
My point in bringing it up was that it is an example where it isn't obvious
(according to its title, etc) that it involves two or more selected objects.
And my idea would fix that.

================================
> This depends at the assumption you can select the Parent in one click.
================================
That's a good objection...

================================
> It also introduces a new temporal mode, waiting for the user to do
> something.
================================
While it is in that mode, there would be a header message telling you that.


================================
> This is how I perceive the current method:
>
> 1) select items that needs to be selected
> 2) select/activate item (sometimes requires retrying when you miss)
> 3) CTRL+Command, ENTER
>
> This is very straightforward. Once you've brought your Objects in a
> certain selection state, you then are free to make-track, parent, copy
> properties, copy links, move to another scene, delete, and so on.
================================
I see that now, but from the tutorials and my own experience I didn't really
pick that up. BTW, my suggestion is to make the active item a more distinct
colour sometimes.... e.g. During the normal confirmation menu (ctrl-T, etc,
then "ok") the active item could become far more distinct that normal,
(maybe red or near-white) since it is the most important thing to check for
during the confirmation... it would normally just be light pink so that it
isn't distracting all the time. Having the active item change colour during
ctrl-T, etc, would make it obvious which item is the active one. (in case
people normally only select two objects at a time and they kind of forget
which shade of pink is the "active" one). (That last point is probably a bit
weak, but I think there are good reasons for making the active item red or
near-white just after you've press ctrl-t/ctrl-p/etc and just before you've
clicked ok)

================================
> I really prefer having selection/activating separated from tools/commands.
> To my surprise such methods are advised by UI theory (Raskin)... but
> apart from that, it's a theorem Blender was built on. The concept of
> 'active' data is widely used everywhere, something we rather should
> communicate in the best possible way, instead of dropping it.
================================
Well my original idea in the Blender.org news thread was to describe it
better.
What about this....?
At the spacebar toolbox menu it probably currently has "Make Track" and
"Make Parent" or "Track To" or "Track" and "Parent".... I don't think
they're clear enough.
e.g.
It could be (assuming the old system of ctrl-t, etc, was used):

Track...
(when you hover the mouse over it... "Track Active Object")
[I don't think "Make Track" and "Track To..." use English in the ordinary
way...]

Parent...
(when you hover the mouse over it... "Active Object Is Parent")

Copy Attribute...
(when hovered over - "Copy.... from Active Object" - and copy menu also
appears)

The same things would come up when you press the hotkeys in order to confirm
the operation... I think the long version should be shown there... (not just
"Parent...") the keywords (like Track, Parent, etc) could be in bold so that
they are easily read amongst the surrounding words (like "Active Object")

================================
> The instruction text you write below - to be printed in headers or so -
> clearly illustrates how bad the 'new' method would be...
 ================================
That is so that the user knows how to use it in case they forget, etc.

 ================================
> Although I like the 'standard' of copy/paste command in many programs,
> it regularly really annoys me to find out it gives more unwanted than
> wanted behaviour. You never really are sure *what* is copied, and never
> know *where* it is pasted, you don't know how long this buffer remains
> active, nor what it does when the context changes (different mode,
> different scene, different editor?).
> Such things then only might work in an acceptable way when you can
> immediately undo the paste...
 ================================
I guess there are too many problems with using ctrl-v, ctrl-c, etc, for
objects in blender, but I think copying/pasting text (including text in all
the text fields) isn't that problematic. (Have you discussed all those text
copy/paste things [and bugs] I brought up in the recent blender.org thread?
If not, I'll make a new message here about it)