[Bf-funboard] Cursor Set Proposal - Revision 2

[Ton Roosendaal]

Hi Douglas,

Let's finalize this proposal with a stamp "Approved". :)
I have two additions though, which can be inserted:

1- Soon we also might need a sort-of "cutting cursor". People are =20
implementing knife tools, and subdivide-drawing tools (draw over face =20=

and it subdivides). This is something we could design a generic cursor =20=

for as well.

2- We should add some general guidelines for when we'll accept more =20
cursors, or in which cases a cursor switch can be accepted; to ensure =20=

some consistancy for future development. I think we all agree on the =20
following:

-> a cursor change always indicates that mouse clicking or keyboard =20
input behaviour changed from default into an exceptional case. Like;
    - no input possible (system is busy)
    - to indicate 'modes', such as edit-mode, vertex-paint, text-input, =20=

etc
    - or indicate temporal editing loops, such as 'border select', 'drag =
=20
edge', or 'transform'

Looking at the list below, only the Hand Cursor is not covered in this =20=

rule. Middle-mouse in Blender is by default view transform. However, =20
for systems with 2-button mouses, this will help understanding its =20
behaviour.

For the design: apart from the normal mousepointer, I would like to see =20=

a fixed set of cursors being designed and used for all platforms. I =20
don't mind when we follow conventions from the X11 set, but we can make =20=

better looking ones than that! :)

Who volunteers? (I've cc-ed this to Ingo, he already said he was =20
interested).

I will store this info in a "UI design guidelines" section or so. I =20
hope to be able to collect all of it soon.

-Ton-


On Thursday, Sep 4, 2003, at 20:12 Europe/Amsterdam, Douglas Bischoff =20=

wrote:

> Hello, all:
>
> Blender does not currently have a comprehensive set of cursors to =20
> provide feedback to the user about the state of the program and what =20=

> it is ready to do or capable of doing at any given moment with the =20
> mouse. In order to fix this, the first thing needed is a proposal on =20=

> the Blender Cursor Set.
>
> This document will start the ball rolling in 3 areas: Needed Cursors, =20=

> Design Limitations, and Design. Naturally, the artistic among us want =20=

> to jump straight to Design, but without the first two items a lot of =20=

> time can be wasted. Note that I've started this off with the =20
> understanding that the UI will not change as a result of this project, =
=20
> just the visual feedback that the mouse pointer can provide the user =20=

> based on various states.
>
> This is the second revision, incorporating the input I've gotten so =20=

> far. Thanks, and please continue the dialog!
>
> Blender Cursor Set
> --------------------------
> Needed Cursors:
> These are the cursors which are needed and a brief description of the =20=

> visual cue they are intended to provide to the user.
>
> GLOBALS:
> * "Normal" Pointer - (use the default OS cursor here)
> * WaitCursor - the program is running and the user should stand by.
> * FrameCounter - display the current frame number while in playback or =
=20
> render mode
> * Horizontal Window edge dragger - horizontal window boundary changes
> * Vertical Window edge dragger - vertical window boundary changes
>
> WINDOW/EDITOR RELATED:
>
> * Normal pointer by default, unless one of the below cases apply (in =20=

> this order):
> * Paintbrush - for vertexpaint / texturepaint / weightpaint modes
> * Texture-Face selector - for FaceSelect mode
> * Armature Selector - for Pose mode
> * TextCursor - for texteditor
> * Vertex Selector - default editmode cursor
> 	* Edge Selector - if editmode defaults to edge selection
> 	* Face Selector - if editmode defaults to face selection
> * Boundary Selector - Appears when the program is in "boundary select" =
=20
> mode
> * Transform cursor - for all sublooping transform calls (grab/size =
etc)
> * HandCursor - for all (middlemouse) view manipulations
>
> TO BE PHASED OUT:
> * Viewport Selector - This is needed for such functions as "Spin," but =
=20
> will be obsoleted when contextual menus are implemented.
>
> Design Limitations:
> In order to operate in all supported operating systems, the cursor =20
> definitions must adhere to the following criteria:
> * 16 pixels high
> * 16 pixels wide
> * 2 colors
>
> Designs:
> Once the Design Limitations are agreed upon by all platform managers =20=

> and coders, and the Needed Cursors have been decided upon, proposals =20=

> for what the cursors should actually look like will be accepted. Some =20=

> guiding ideas that have been proposed:
> * Matt Ebb proposes that cursors that operate on what may be very =20
> precise locations (vertex selector especially) have a space at their =20=

> "hotspot" that allows the user to see exactly what will be affected =20=

> underneath the cursor.
>
> ** ALTERNATIVES **
> Gregor M=FCckl suggests loading the default cursor from the UI as a =20=

> starting point, then appending the feedback info for each specific =20
> cursor to that cursor instead of creating a whole library of new =20
> cursors.
> * Advantage is that it preserves some UI familiarity: the default =20
> cursor is well-known to the user.
> * Disadvantage is that a limited amount of modification can be done, =20=

> limiting what can be communicated by the cursor.
> * Disadvantage in that Blender would have to be aware of the handling =20=

> of cursors on a per-system basis?
>
> -Bish
>
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard@blender.org
> http://www.blender.org/mailman/listinfo/bf-funboard
>
>
------------------------------------------------------------------------=20=

--
Ton Roosendaal  Blender Foundation ton@blender.org =20
http://www.blender.org