Re: [AD] Using system mouse cursor |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> Looks mostly okay. Though here are a few issues:
>
> > + AL_METHOD(int, select_os_cursor, (AL_CONST int cursor));
> > } MOUSE_DRIVER;
>
> Granted this is in the driver struct, and not API exposed, but do you
> plan on changing os to hardware here?
No, although I may change it to system or native.
The reason is that this selects the OS native cursor. This is different
from the hardware cursor, which can also be an Allegro defined one.
> > +static int use_os_cursor = FALSE; /* Use native cursor? */
>
> Again, it is internal, but I think we should maintain proper naming
> convention. IMO, this should be hardware, not os.
Basically the same as above. I do think I prefere use_system_cursor or
use_native_cursor here too.
> > +static BITMAP *create_mouse_pointer(char data[][DEFAULT_SPRITE_W])
>
> It might be safer to pass (char *data, int w), so you're not restricting
> the data to be a specific width.
That may be a good idea, although I don't think we want to keep track of
which predefined cursor has which width. Perhaps we should add an internal
mouse_sprite struct that stores the current data alongside a width/height
count?
> You might want to change this to:
> ASSERT((cursor < NUM_CURSORS) && (cursor >= 0))
> for added safety.
Makes sense. I also considered making it unsigned, but I'm undecided if I
want to leave MOUSE_CURSOR_NONE at 0 or make that -1. In either case,
chacking for cursor >= MOUSE_CURSOR_NONE would make sense.
> This also seems to indicate that you can't use custom hardware cursors.
Yes you can. Well, if you mean hardware cursors in style of the current
Allegro nomenclature.
> I'd like to be able to set MOUSE_CURSOR_ARROW/BUSY/etc to custom
> pointers so I can just select and use them as if they were the defaults
> (like for the GUI, and so I don't need to keep calling set_mouse_cursor
> to change it).
Effectively, that means to disable the OS cursor? I can see where that
might be convenient.
What I'd propose though is to add a function (ugh, another one!) that
disables the OS cursor, so that Allegro's defaults (or the user specified
defaults) are always used. Another idea which may make sense is to make
the first parameter a bit field, so that you can pass a flag to override
(or request) the use of the OS cursor. Of course, that leaves open the
question of how to interpret MOUSE_CURSOR_ARROW|MOUSE_CURSOR_BUSY|
MOUSE_CURSOR_EDIT.
> This means show_mouse won't have an effect if the hardware cursor is
> being used, right?
Yes, because you don't want Allegro to draw a mouse pointer if the OS
already does this as well, however...
> IMO, showing the mouse on a memory bitmap should
> behave as if there is no hardware mouse (disable the hardware mouse, use
> software drawing on the specified bitmap), and show_mouse(NULL) should
> remove the mouse pointer from being displayed.
... you are correct that this shouldn't really apply to memory bitmaps
(although I think the user who draws a mouse sprite on his memory bitmap
while also displaying an OS cursor on the screen should rethink his
design).
On the other hand - Allegro's current API also allows for only one mouse
cursor to be displayed at the same time. In that light, I think it
actually makes sense to retain the above behavior.
Evert