Re: [AD] Mouse cusor documentation

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Sun, 2004-10-03 at 06:57 -0700, Chris wrote:
> 
> > No, we don't. Allegro uses a software cursor automatically if it can't let 
> > the OS draw the cursor. No need to disable the hardware cursor for that.
> 
> I think he means disable temporarilly, until it's shown on the screen again.
> 

I think enable_hardware_cursor should be more than just signalling that
it is ok to use hardware cursor. I'd actually like it to enable the
hardware cursor immediately, like show_mouse(screen) does with the
software cursor. That way, it would be simple to switch between the two:

enable_hardware_cursor();
// Now the hardware cursor is used, if possible

show_mouse(screen);
// Now the software cursor is used again

This won't break the API, and it will work well both when enabling the
HW cursor in an Allegro GUI app (where we already provide a mouse
cursor), and in the new case where you have a double buffered app which
draws a hardware cursor.

In the first case, a single call to enable_hardware_cursor simply makes
the hardware cursor used instead if possible, else it stays like it was
with the software cursor.

In the latter case, you would call enable_hardware_cursor, and depending
on if it suceeded or not, you still have to do a manual draw_sprite or
not (by checking if it succeeded, currently by GFX_HW_CURSOR).

> > I'm not sure... I think this could be considered an API breakage. Anyway, 
> > with the new system and custom cursors, the code needs to be somewhat 
> > rethought anyway.
> 
> True.. and I'm not really against having some API breakage as long as it 
> follows these rules: 1) the break can only happen after the programmer 
> explicitly calls a function that alters behavior (and the called 
> function is documented to change the behavior of the other functions). 
> And 2) the altered behavior is disabled by default.
> 
> Now, since enable_hardware_mouse is a new function, everything's pretty 
> much fair game when it's called.. behavior changes to existing functions 
> included. This includes show_mouse. /However/, the changes should be 
> kept reasonable if not minimal, and I personally don't quite see the 
> reason to change show_mouse. If the OS/hardware can't handle the cursor 
> Allegro tries to set, it falls back to software until the proper 
> conditions are met and it can use the OS/hardware again. This should 
> include not only bitmap size/color restrictions, but also target bitmaps.
> 
> So, IMO when enable_hardware_mouse is called, it should use the 
> hardware/OS only when the target is "screen" (not the physical screen, 
> since page flipping/scrolling can change what's in view and where, but 
> the pointer to the screen bitmap), and the OS/hardware can accept the 
> pointer bitmap.
> 

Well, if enable_hardware_cursor() immediately enables the cursor if
possible, there's no need to use show_mouse(screen). show_mouse(screen)
wouldn't need to change at all. And show_mouse(NULL) would disable any
cursor, software or not. So, no API breakage at all.

-- 
Elias Pschernig





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/