[Bf-taskforce25] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [17906] branches/blender2.5/blender/source /blender: 2.5

[Ton Roosendaal]

Hi,

Proposal sounds reasonable, however, I wouldn't make the undo-ability a 
guideline, but more the obscurity (or clarity). Locus of attention 
stuff.

Popup menus are very useful for newly added and for obscure (hidden, 
not obvious) options. You don't want to accidentally hit a key and do 
something you don't realize because someone added a hotkey there.

For that reason the 'rip window' doesnt need a menu, it's totally 
obvious, not destructive, and can be undone  by just closing the 
window. But the 'delete markers' deserves a menu, simply because 
timeline is small, and an Xkey will also delete the invisible markers.

There's also myriads of keys you keep forgetting, and the menus then 
show again whether it was "Make Proxy" or "Make Parent without inverse" 
or one of the other plenty "P" tools :). With customizable maps you 
will need this only more.

The menu also shows if there's even something 'in context'. The menu 
"delete objects" doesn't show without selection. We can now even 
register such automatically, and put in an error log or so.

OTH, we can easily make such menus part of the keymap. It can be useful 
for power users to disable most of them.
And once we have a better buttons system, with some kind of 
construction history or a panel "last operators executed", such menus 
will probably be less needed too.

> So in short, this needs to be controlled somehow so that we *don't*
> get these extra confirmations when using menus to launch operators :)

No worries, that's in the spec and reason this whole 2.5 project 
started!

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands

On 18 Dec, 2008, at 1:50, Matt Ebb wrote:

> On Thu, Dec 18, 2008 at 2:38 AM, Ton Roosendaal <ton at blender.org> 
> wrote:
>
>> - Added this confirm call for most of the keys you'd expect it for.
>>  (user settings, delete marker, rip area, split region, etc).
>
> Good to see the functionality back, but I think this is something that
> needs further thought, too.
>
> IMO there's far too many of these popups scattered throughout Blender
> and it can get quite annoying when you're using it a lot, with way too
> much clicking needed. I think much of it is historical, from before
> when Blender didn't have undo, it nagged about everything, since if
> you did make a mistake, you were screwed. Nowadays it's different, and
> we shouldn't have to worry about Blender constantly asking "are you
> sure? are you sure? are you sure?" for *simple procedures*.
>
> I think a good guideline for these confirmations can be to err on the
> side of no popups:
> * For things that are easily reverted (either with undo or by a simple
> click or two) -> no confirmation.
> * For anything that can't be undone (like ripping an area out,
> perhaps) -> confirmation
> * For anything that can involve loss of data (like closing a file
> without saving) -> confirmation
>
> Under this guideline, the ones added in the last commit would be:
> User settings -> confirm (overwriting old data)
> Delete marker -> don't confirm (easy to undo)
> Rip area -> confirm (can't undo)
> Split region -> not sure, will this be undoable?
>
> The other thing to note is that these confirmations should *only* show
> when accessing tools from hotkeys. Not to mention using operators in
> macros, but the current situation now when they show from menus as
> well is very annoying, and unintuitive. While it can help to have some
> confirmations for hotkeys (since hotkeys can be accidentally bumped
> quite easily) it's very different for menus - you've already navigated
> to the right spot and clicked. Having to click again in exactly the
> same spot is very redundant.
>
> But not only this, combined with the way Blender's confirmations
> disappear when the mouse moves away (which is usually really nice),
> having confirmations on menus can cause real problems, when users
> expect that they've chosen the menu option, then move the mouse away,
> but the confirmation was actually cancelled in a split second.
>
> This has actually caused big problems for us at the studio - here's
> the real world example that actually happened, and it's happened for
> two different people, my boss and another experienced animator that we
> brought in here to train with Blender. On separate occasions, they'd
> both experienced loss of work and they couldn't understand why. One of
> them would be working for a period of hours, opening up new files,
> saving all the while through, then at the end of the day, he'd save,
> quit Blender and go home. Then the next day, he went to open up his
> old file, and all the work he'd done was gone (which is very bad, that
> was paid hours on real deadlines!). I searched around on the server,
> and couldn't figure out what was going on.
>
> It was only then when I was watching him save the file, that I noticed
> what was happening. He'd choose File->Save from the menu, and then
> move the mouse pointer away to continue working, not noticing that in
> a split second there was another confirmation popup that flashed away.
> Of course this is expected, in just about every other application
> known to man, it doesn't confirm on a simple Save command, only on a
> Save As, and those confirmations don't disappear when you move the
> mouse a few pixels away. So all the time they thought they were
> saving, nothing was happening at all, then next time they opened a new
> file, the work was gone.
>
> So in short, this needs to be controlled somehow so that we *don't*
> get these extra confirmations when using menus to launch operators :)
>
> cheers
>
> Matt
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>