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

Ton Roosendaal bf-funboard@blender.org
Fri, 26 Sep 2003 23:14:39 +0200


Hi,

> 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.

An object remains active when *not* selected... that's what you see  
happening.
I'm not happy with the way that visualizes, but you can see it at the  
changed color of the 'centre point'.

'Active' and 'Selected' are important concepts, something we definitely  
can look at improving to communicate. As mentioned in the UI makeover  
doc, the UI doesn't stop with buttons and menus. This is an important  
topic to work at as well. For our planning, I think it's more efficient  
to do most that after 2.30 is out...

One remark from below I think we can include though, and that's make  
sure that our new 'context' sensitive toolbox (pie menu, whatever) will  
clearly comminicate this 'active' status. For example one segment/bar  
with:

- title: Active Object
- items: "Make Parent of selected", "Copy attributes to selected", etc.

When all such tools are grouped together, we communicate the whole  
concept better I think.

-Ton-



>
> ================================
>> 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)
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard@blender.org
> http://www.blender.org/mailman/listinfo/bf-funboard
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org