[Bf-taskforce25] search-based workflow

joe joeedh at gmail.com
Sat Mar 14 02:19:20 CET 2009


I think that was ton's point, it adds clicks in those situations where
you want the editor to have focus but it doesn't.  There seem to be
nicer ways to solve this that don't.  Also, only time I can think of
where I'd personally use such a system, is with the text editor.  Most
of the time the mouse cursor has to be in the editor your using.

Joe

On Fri, Mar 13, 2009 at 1:24 PM, vekoon <vekoon at gmail.com> wrote:
> Well how would it add extra clicks? The clicks are necessary only in
> those particular situations where you want an editor to get input
> regardless of the cursor position otherwise it works as regular blender.
> It could "solve" it in the simple way that if you're bothered by the
> lost of focus when you move the mouse and don't want to be annoyed in
> that particular time (for instance you're concentrating in a certain
> editor) you can just lock it for the time you need it and then unlock
> when you're done. I'm not saying is a complete solution, just a possibility.
>
>
> Ton Roosendaal wrote, on 13/03/2009 19.33:
>> Hi Vekoon,
>>
>> We discussed a similar concept during the wintercamp, to enable a
>> single top toolbar/header for all editors. It didn't get much acclaim
>> though. It would add extra clicks to get things work, and especially
>> would violate our attempts to try to make things nonblocking and
>> nonmodal.
>>
>> I also don't see well how it would solve the context issue for
>> inputting searches... there's several ways to solve it relatively nice,
>> as the videos from Aza Raskin show.
>>
>> -Ton-
>>
>> ------------------------------------------------------------------------
>> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
>> Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands
>>
>> On 13 Mar, 2009, at 18:43, vekoon wrote:
>>
>>
>>> What about context lock? I thought about this some time ago. I
>>> concluded
>>> having an explicit context activation (i.e. click-focus) à la for
>>> instance after effects is not super usable as it introduces a kind of
>>> meta-modality, i.e. you have to "switch" to something before you can
>>> actually use it. But in some circumstances it can make sense to have a
>>> "focus" type of thing independent of cursor position (like in this case
>>> for expressions and maybe others).
>>> My idea was to create a "lock context" functionality in which an editor
>>> is locked to capture the focus whatever the position of the mouse is.
>>> It
>>> could be a button on the header or such. It could even be made a
>>> non-exclusive type of thing so that you can lock the context to more
>>> than 1 editor and then which one actually has the focus is decided
>>> basing on cursor position and if cursor is in a non-locked editor you
>>> just pick the first or the larger of the locked ones.
>>> This of course would have some kind of explicit visual feedback, like
>>> the border of the editor being of a different color depending if it's
>>> normal, locked or has focus, like it actually already happens in
>>> blender
>>> but should be more visible by default (like with high contrast colors).
>>>
>>>
>>> Ton Roosendaal wrote, on 13/03/2009 15.21:
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>>> The question again is about context - should it follow the
>>>>> context of where the cursor currently is?
>>>>>
>>>>>
>>>> Blender should allow any hotkey to activate any button in other
>>>> regions, so the search button in top bar gets immediate input even
>>>> when
>>>> you don't move the mouse to it, similarly we can use that for the
>>>> properties of last-used-operators.
>>>>
>>>> -Ton-
>>>>
>>>> ----------------------------------------------------------------------
>>>> --
>>>> Ton Roosendaal  Blender Foundation   ton at blender.org
>>>> www.blender.org
>>>> Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The
>>>> Netherlands
>>>>
>>>> On 13 Mar, 2009, at 13:05, William Reynish wrote:
>>>>
>>>>
>>>>
>>>>> Enso is a nice idea, in that it is completely non-modal, and works in
>>>>> all cases. It could indeed be a nice way to use searching for
>>>>> operators. The question again is about context - should it follow the
>>>>> context of where the cursor currently is? This is what Blender does
>>>>> now - hotkeys only respond to actions within the current editor,
>>>>> which
>>>>> is where the cursor is.
>>>>>
>>>>> The problem with text-based input for Blender is that you might
>>>>> easily
>>>>> lose track of where the cursor is, and the command you are calling
>>>>> might suddenly not work because the cursor is moved into another
>>>>> editor. Same issue exists of macros, as we discussed during Winter
>>>>> Camp.
>>>>>
>>>>> It may not be that big a problem, especially if the searches are
>>>>> clear, and that you can instantly see in which context you are
>>>>> performing the search.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> W
>>>>>
>>>>>
>>>>> On 12 Mar, 2009, at 12:55 PM, Ton Roosendaal wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Was googling around, and found this new startup co-founded by Aza
>>>>>> (son-of) Raskin.
>>>>>> http://humanized.com/enso/
>>>>>>
>>>>>> Entirely search based tools/actions. Even follows our concept "only
>>>>>> use
>>>>>> sticky modes while user actively does something".
>>>>>>
>>>>>> Their search tool works with holding CapsLock, probably they have a
>>>>>> way
>>>>>> to disable it?
>>>>>>
>>>>>> Another great post from Aza, it's very close to our work currently:
>>>>>> http://humanized.com/weblog/2008/07/18/designing-without-modal-
>>>>>> overlays/
>>>>>>
>>>>>> And some of his work on Mozilla:
>>>>>> http://humanized.com/weblog/2008/07/14/ubiquitous-interfaces-
>>>>>> ubiquitous-functionality/
>>>>>>
>>>>>> -Ton-
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> --
>>>>>> --
>>>>>> Ton Roosendaal  Blender Foundation   ton at blender.org
>>>>>> www.blender.org
>>>>>> Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The
>>>>>> Netherlands
>>>>>>
>>>>>> _______________________________________________
>>>>>> Bf-taskforce25 mailing list
>>>>>> Bf-taskforce25 at blender.org
>>>>>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Bf-taskforce25 mailing list
>>>>> Bf-taskforce25 at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Bf-taskforce25 mailing list
>>>> Bf-taskforce25 at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Bf-taskforce25 mailing list
>>> Bf-taskforce25 at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>>
>>>
>>
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>


More information about the Bf-taskforce25 mailing list