[Bf-taskforce25] New tools mockups

[Ton Roosendaal]

Hi all,

To put some relativeness to the discussion here:

The underlying design specs of how tools work (like extrude) have been 
carefully made generic, so a decision how to use it (sticky, modal, or 
like 2.4x, whatever) is separated from its functioning in many ways. 
It's even well possible that the keymap editor in Blender will allow 
you to define it with great freedom too.

That's the reason why we *can* even have this discussion, new ways are 
possible, very interesting to explore it. That's all. Give it a bit of 
benefit of doubt to let us show results of the experiments. :)

I'm also still trying to grasp the entire scope and range of this 2.5 
project, it's becoming fuzzy a bit. We don't have to change the 
workflow in every part of blender for the first 2.5 installment, this 
ui & workflow work will go on indefinitely anyway. :)

-Ton-

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

On 25 Apr, 2009, at 11:14, William Reynish wrote:

> Ah, what a discussion! 
>
> This really goes to show that this is a hot topic, and that it's an 
> important hurdle to overcome. 
>
> There are, it seems, some misunderstandings that I'll need to clear 
> up. Perhaps some IRC discussion might be good too, which is more 
> direct, and is less likely to provoke confusion and misunderstanding.
>
>
> On 24 Apr, 2009, at 7:29 PM, Martin Poirier wrote:
>
>> That would be shit when using the API (either internally or from 
>> Python). You'd have to set the toolsettings, call the operator, then 
>> restore to what it previously was (unless you want to piss off 
>> users).
> Well, I'm talking about the user interface level here, not Python 
> scripting. In 2.4x, PET is not a property (as far as the user is 
> concerned) of any tool, but rather a global setting that changes the 
> behaviour of most tools. In 2.4x, you can't even enable or disable PET 
> during a transform.
>
> In the tools UI, there's no need to present this twice, both in the 3d 
> View header and in the tool settings themselves, so that's why I 
> consider it redundant.
>
> On 24 Apr, 2009, at 7:34 PM, Jason van Gumster wrote:
>
>> I'm not completely opposed to the concept of Select->Act->Tweak, but 
>> it
>> does add an additional step to the flow because you have to confirm
>> after tweaking.
> No, you don't! If anything, the Select->Act->Tweak workflow 
> needs fewer clicks because if the user is content with the default 
> tool settings, he/she does not even need to interact with it.
>
>
> On 24 Apr, 2009, at 7:34 PM, Jason van Gumster wrote:
>
>> And I certainly don't want to rely on holding down a
>> key and applying on key-up... especially if that's the more common
>> use-case. In the case of extrusion, the current moving mouse method is
>> faster (and more likely to be used) than the tap method you propose...
>> but the tap method has the quicker access.
> Sticky keys are one solution. But if anything, it does 
> require less user input. Consider the current workflow for extruding 
> in 2.4x:
>
> 1: Tap e
> 2: Chose extrusion type
> 3: Move mouse
> 4: Click to confirm
>
> With sticky keys:
>
> 1: Hold e
> 2: Drag mouse
>
> If the user desires a different extrusion type, that can be tweaked 
> later, but most of the time, it's just a simple swift stroke of 
> holding e and moving the mouse. 
>
>
> On 24 Apr, 2009, at 7:19 PM, Martin Poirier wrote:
>
>>
>> As much as the press and hold sounds good in theory, having to hold 
>> an additional key on top of Ctrl (and perhaps Shift) when doing 
>> precise movements just seems foolish. What if you want to extrude 
>> along an axis? Press X (or Y or Z) while holding down E?
>>
>> No way.
>> ...All in theory, but trying holding down G (or S, or E, or ...) and 
>> then press Shift-O to switch between PET falloff modes, all the while 
>> keeping one hand on the mouse (or tablet).
>>
>> Also, while it throws transform numerical input out the windows (try 
>> typing values while holding down another key), you can now type in 
>> the operator param buttons instead, if you don't mind doing something 
>> that worked very fast before in twice the time (if not more).
>>
>> Martin
>
> Well, this confuses me. I thought one of the points of 2.5 was exactly 
> to get rid of the very modal workflow that most tools in 2.4x employ. 
> You are absolutely right in your skepticism, were the tools going to 
> otherwise continue to work like they used to.
>
> Your main issue is with these modal operations, such as pressing all 
> kinds of keys that apply only when you are inside a tool mode. Most of 
> these things, like snapping, PET etc. are really more global settings 
> that can affect any tool, and shouldn't have to be applied while a 
> tool is in use. I'd advocate getting rid of these modal settings that 
> only apply when you are in a tool mode, but that's not the same as we 
> shouldn't have these settings, or quick ways to access them. The 
> difference is simply that they become global properties instead of 
> local to that tool, and workflow speed won't suffer. Consider this 
> proposal:
>
> *    Blender 2.5 will have a global constraining system where things 
> can be constrained to axes, normal direction, surface etc etc.
> *     These settings have shortcuts for fast interaction (could be the 
> x, y and z keys for constraining to these axes)
> *     This means that the constraint axes can be set both before, 
> during or after a tool is in use.
>
> The result is that you can keep using tools as before, where you tap a 
> key, set a constraint axis and confirm, but this is no longer the only 
> possible workflow. You can also set the constraint axis first, and 
> then start using a tool.
>
> Besides, the whole point of sticky keys is that they are sticky! This 
> means you can still just tap a key, like before, and then start using 
> that tool.
>
> One of the big issues has to do with enabling tools from menus and 
> tool lists. Many tools are very dependent on mouse starting position, 
> and therefore aren't 100% compatible with choosing a tool from a menu. 
> One solution is to have tools be 'active', rather than totally 
> blocking, meaning that the user can use any part of the app while 
> using a tool, and can start the actual transformation from any part of 
> the screen, even if a tool has been enabled on, say, the left side.
>
> I consider the tools design to be the biggest design challenge left of 
> 2.5, and one that hasn't been explored fully yet. Hope to continue a 
> healthy discussion here and on IRC.
>
> Cheers,
>
> -William
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25