[Bf-funboard] Experimental keymap introduction video

Paweł Łyczkowski pawellyczkowski at gmail.com
Sun Oct 27 21:35:07 CET 2013


> I don't think this is necessary.  IMO this stems from a broken
> interaction model in the knife cut operator, which I've fixed in the
> keymap.  RMB should only cancel the current incomplete cut, not all
> cuts that have been made

Ah, that is even better, nice!
> Nathan Vegdahl <mailto:cessen at cessen.com>
> 27 października 2013 20:06
> Hi Pawel,
> Thanks for the link!  I'll look at it more in-depth when I get a
> chance.  But just a quick response to the main body of your reply:
>
>> You can see there that I propose to set up mode switching as follows:
>> "Tab to switch between Object mode and Edit mode when tapped, gives a
>> pie menu with all modes when held."
>
> This is a cool idea, but my concern is that we still end up using a
> toggle mentality in a scenario where there are more than two modes.
> For example, what happens if I'm in sculpt mode and press tab?  Does
> it switch to edit mode, or does it switch to object mode?  Let's say
> it switches to edit mode.  Now that I've switched to edit mode from
> sculpt mode, what happens if I hit tab again?  Does it switch back to
> sculpt mode, or does it switch to object mode?
>
> Obviously, we can design it so that the answers to those questions are
> fully consistent.  But it presents a more complex mental model that
> the user has to keep in their heads when doing tasks that involve more
> than just object and edit mode.  And I think it is best to avoid that
> if possible.  IMO we should drop the toggle mentality all together.
> It just isn't applicable anymore.
>
>> What you have already is ok, except for deselecting - it would be better
>> if click on empty space would also deselected all, not only click drag.
>> Double click behaves weird, it not only selects loops but sometimes
>> faces - https://db.tt/QAFkjjCl
>
> These are both excellent points, and I consider both to be bugs, not
> part of the intended interaction model.  I agree that click-select in
> a blank area should deselect all.  And obviously double-click for loop
> select should only select loops.
>
>> Make sure spacebar can confirm an operation, like confirm Knife cuts.
>
> I don't think this is necessary.  IMO this stems from a broken
> interaction model in the knife cut operator, which I've fixed in the
> keymap.  RMB should only cancel the current incomplete cut, not all
> cuts that have been made.  This is consistent with the loop-cut
> operator, where RMB only cancels the steps that haven't been completed
> yet.  The user should never have to use the keyboard to confirm an
> operation, unless perhaps that operation is keyboard-centric to begin
> with (like typing in a text string).
>
> --Nathan
>
>
> On Sun, Oct 27, 2013 at 10:25 AM, Paweł Łyczkowski
> <pawellyczkowski at gmail.com>  wrote:
>> Hey Nathan, great work on the keymap/interaction.
>>
>> You can find the ideal interaction for selecting and basic operations be
>> me and Jonathan Williamson in this doc -
>> https://docs.google.com/document/d/1ScPMbHv8WRCU2znB7IU2l-W9hH-NLs5weQKLkjqmgpA/edit#
>> in the part called "Selection Methods". You might also find "RMB Menu",
>> "Multiselect" and "Quick Switch" sections interesting.
>>
>> Some of it overlaps with how you set it already.
>>
>> You can see there that I propose to set up mode switching as follows:
>> "Tab to switch between Object mode and Edit mode when tapped, gives a
>> pie menu with all modes when held." I don't know if registering that a
>> button is held down is possible to register in Blender. If it is, it
>> could be used in more places. For instance the spacebar mode switcher
>> that you propose could take advantage of it - hold spacebar, move mouse
>> over specific mode, release spacebar.
>>
>> What you have already is ok, except for deselecting - it would be better
>> if click on empty space would also deselected all, not only click drag.
>> Make sure spacebar can confirm an operation, like confirm Knife cuts.
>> Double click behaves weird, it not only selects loops but sometimes
>> faces - https://db.tt/QAFkjjCl
>>
>> Cheers
>> Paweł Łyczkowski
>>
>> Nathan Vegdahl wrote:
>>> I'm starting to put together some videos to teach the new
>>> input-map/key-map I've been been developing. This is the first video:
>>> http://www.youtube.com/watch?v=PaB7r_Q47qk
>>>
>>> This video is just a short intro to communicate some broad concepts
>>> and some of the thought process behind developing the keymap, and
>>> hopefully to get people interested in trying it out.
>>>
>>> The intent of these videos in general is to give people a chance to
>>> start trying the keymap out, and to communicate some of the keymap's
>>> primary ideas, especially for the new UI process that Brecht and Ton
>>> are getting started.
>>>
>>> I'll post more videos to this thread as I complete them.
>>>
>>> --Nathan
>>> _______________________________________________
>>> Bf-funboard mailing list
>>> Bf-funboard at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-funboard
>> _______________________________________________
>> Bf-funboard mailing list
>> Bf-funboard at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-funboard
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard
> Paweł Łyczkowski <mailto:pawellyczkowski at gmail.com>
> 27 października 2013 18:25
> Hey Nathan, great work on the keymap/interaction.
>
> You can find the ideal interaction for selecting and basic operations 
> be me and Jonathan Williamson in this doc - 
> https://docs.google.com/document/d/1ScPMbHv8WRCU2znB7IU2l-W9hH-NLs5weQKLkjqmgpA/edit# 
> in the part called "Selection Methods". You might also find "RMB 
> Menu", "Multiselect" and "Quick Switch" sections interesting.
>
> Some of it overlaps with how you set it already.
>
> You can see there that I propose to set up mode switching as follows: 
> "Tab to switch between Object mode and Edit mode when tapped, gives a 
> pie menu with all modes when held." I don't know if registering that a 
> button is held down is possible to register in Blender. If it is, it 
> could be used in more places. For instance the spacebar mode switcher 
> that you propose could take advantage of it - hold spacebar, move 
> mouse over specific mode, re lease spacebar.
>
> What you have already is ok, except for deselecting - it would be 
> better if click on empty space would also deselected all, not only 
> click drag. Make sure spacebar can confirm an operation, like confirm 
> Knife cuts. Double click behaves weird, it not only selects loops but 
> sometimes faces - https://db.tt/QAFkjjCl
>
> Cheers
> Paweł Łyczkowski
>
> Nathan Vegdahl wrote:
> Nathan Vegdahl <mailto:cessen at cessen.com>
> 27 października 2013 17:31
> I'm starting to put together some videos to teach the new
> input-map/key-map I've been been developing. This is the first video:
> http://www.youtube.com/watch?v=PaB7r_Q47qk
>
> This video is just a short intro to communicate some broad concepts
> and some of the thought process behind developing the keymap, and
> hopefully to get people interested in trying it out.
>
> The intent of these videos in general is to give people a chance to
> start trying the keymap out, and to communicate some of the keymap's
> primary ideas, especially for the new UI process that Brecht and Ton
> are getting started.
>
> I'll post more videos to this thread as I complete them.
>
> --Nathan
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org
> http://lists.blender.org/mailman/listinfo/bf-funboard


More information about the Bf-funboard mailing list