[Bf-funboard] Questions re: mouse cursor in modal functions

[Jude Jackson]

Ah, thanks for the reply! That makes sense; I was thinking of this purely
as a UI consistency issue, but it didn't occur to me that it would also add
undue complexity to the code. It's a minor enough issue, I was mostly just
curious if it had even been thought about. For the longest time, Blender
had suffered from a silly preoccupation with the evils of modal interface,
so I wasn't sure if the peculiarities of the mouse-based interface were a
hangover. Sounds like: probably not!

On Monday, August 25, 2014, Campbell Barton <ideasman42 at gmail.com> wrote:

> Sorry for blank mail, (gmail UI refreshed the send button under mouse!
> tsk! - Blender isn't only app with UI issues :D )
>
>
> Hiding cursor while orbiting the view could be OK, but also a bit
> confusing when you exit your mouse will popup somewhere you might not
> expect.
>
> Making scale work differently is quite a big change, and you're not
> suggesting an alternative - so not sure how to respond.
> While it can be confusing at first - you get used to it and can take
> advantage of it too.
>
> It could work to compensate the difference from the center of the
> selection to the mouse when scaling so as to give a constant
> scale-delta based on mouse movement, would need to test it, it could
> be a preference though all these interaction preferences make the code
> difficult to maintain, so personally I'm not really interested to add
> this just now.
>
>
>
> On Sun, Aug 17, 2014 at 4:48 PM, Jude Jackson <syzygy6 at gmail.com
> <javascript:;>> wrote:
> > Hey folks, this is just a question, maybe it will open things up for
> > discussion or at least solidify the concept, but I've thought it was odd
> > that in certain mouse-movement-based modal function, the cursor remains
> on
> > screen and moves during the function, even if the cursor itself is not
> > really relevant and could just disappear.
> >
> > For example: in rotating the 3D view, the operation does not account for
> > the location of the 3D cursor, just its motion (I'm not at my computer to
> > confirm right now (or for a couple more weeks), but I think you can even
> > continue to rotate the 3D view by dragging the mouse further than the
> edge
> > of the screen).
> >
> > Another example: scaling/rotating an object in 3D view actually *does*
> use
> > the mouse cursor (the function has something to do with the distance of
> the
> > cursor from the origin of the object I think), but it results in an
> awkward
> > scenario where the scale of the operation is set by the distance of the
> > cursor from the origin of the object (I assume it sets that scale to 1).
> > This system isn't wrong per se, but it is strange for various reasons.
> >
> > One recent example: Pie menus are basically a gestural input at their
> best,
> > which I great. I understand that, as-implemented, it makes sense to use
> the
> > cursor for selecting options if you don't know the appropriate gesture.
> But
> > when it is working as a gestural input, it seem strange that it would use
> > the global mouse cursor, because the user isn't trying to point at
> > something.
> >
> >
> > Now, I want to clarify that I don't think that the current paradigm is
> > wrong. It's consistent, in fact, which is a strong foundation for UX
> > design. But, I think it's worth examining the possibility of visualizing
> > non-pointer-based mouse inputs without the cursor, and figuring out
> whether
> > it's worth doing and how it would be done if it is.
> >
> > Cheers
> > _______________________________________________
> > Bf-funboard mailing list
> > Bf-funboard at blender.org <javascript:;>
> > http://lists.blender.org/mailman/listinfo/bf-funboard
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org <javascript:;>
> http://lists.blender.org/mailman/listinfo/bf-funboard
>