[Bf-committers] Cursor proposal and OSX Cursor size

Ton Roosendaal bf-committers@blender.org
Wed, 3 Dec 2003 12:07:42 +0100


Hi,

> That may not be true (Depends what you mean by easy).  From the docs  
> you
> showed me, it depends on what the default state of
> IOFB_ARBITRARY_SIZE_CURSOR is.  It may be set by default (but sounds  
> like it
> isn't).
>
> If it isn't,  it looks like we can override this by setting the above  
> define
> and calling IOFBCreateSharedCursor() with 32x32 during init.  The  
> predefined
> structs are undef'd (they are now the wrong size) and we then create  
> our own
> structs at the specified height/width (Which we have to do anyway to  
> map the
> data in the Blender Cursor struct to an Apple Cursor struct).  Again,  
> I'd
> probably make them all 32x32 and make a small cursor only fill 1  
> corner.

 From I've seen it's possible at Kernel level... something I rather not  
touch at all! Googling around about it reveils that the 'acceptable'  
solution is to create a 'window' and move that around at cursor  
location. Apparantly more OSX coders have been fighting with issue...  
and since we don't have (a lot) of OSX competence on board I really  
prefer to drop that requirement for OSX.

I think a limit of 16x16 is very acceptable for Blender now... but  
you're of course free to build code based at 32x32, and only use 1  
corner for now. In the future we might be able to solve this problem  
then.
Also note that on OSX you can have many more colors for pointers,  
something we won't support either.


> 	1) All cursors will become custom cursors so they match across  
> platforms.

With as exception the default pointer, I hope?
Or maybe not... if this can prevent the X11 cursor hack some people use  
to draw soft shadows; this seems to be done with OpenGL and screws up  
the Blender window.

> 	2) Cursors will have a large and small version selectable by a  
> userpref.
> 		This userpref will be disabled on platforms that cannot support  
> large 	
> 		cursors.  The data will consist of a bitmap and transparency mask,  
> as it 	
> 		does now. (My MakeCursor.py is available to paint Cursors. Can this  
> be
> 		put on Blender.org?).

I propose to postpone design efforts and choices for larger cursors  
until we can solve this for all platforms.

> 	3) Cursors will have definable fg and bg colors.
> 	4) Cursors will have definable hot-spots.
> 	5) Each cursor will be a member in a global array of structs defined  
> in
> 		cursors.c
> 	6) Each cursor will have a define in cursor.h that is its index  
> number in 		
> 		the array.
> 	7) Cursor setting API code will go in cursor.c  And will be  
> implimented with
> 		the existing GHOST custom cursor calls (modified to handle the size
> 		change). 	
> 	8)  API will be:
> 			GetBlenderCursor() - returns defined number of current cursor.
> 			SetBlenderCursor(int i) - sets cursor to the ith cursor.
> 			Defines will be set so all cursors can be refered to by name.
> 	9) Current cursor API will be phased out, but will remain active  
> during
> 		changeover so things don't get broken.

Further it looks fine!
Are you going to use the design proposal as done before, which was  
copied to the UI doc at  
http://www.blender.org/docs/UI/ui_redesign2.html ?

Thanks,

-Ton-

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