[Bf-funboard] Cursor Set Proposal - Revision 2
Ton Roosendaal
bf-funboard@blender.org
Wed, 10 Sep 2003 23:16:30 +0200
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