| Re: [AD] Using system mouse cursor |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Friday 01 October 2004 23:24, Elias Pschernig wrote:
> Yes - there should never be two mouse pointers at the same time. But
> maybe show_mouse should disable the hardware cursor - it would just
> need to call disable_hardware_cursor at the beginning. And
> show_mouse(NULL) as a way to always remove any mouse cursor, software
> or not, also seems to be a good idea to me.
disable_hardware_cursor() isn't for hiding the hardware cursor - it's for
disallowing it in case you want to use mickeys. Although I suppose that
show_mouse(NULL) could hide the system pointer as well.
Bear in mind the following distinction in the nomenclature:
* Software cursor (the custom cursor drawn by Allegro)
* Hardware cursor (the custom cursor drawn by the OS rather than Allegro)
* System cursor (the system default cursor)
The system cursor is a different entity from the hardware cursor, although
for platforms that have a system cursor it behaves in a similar way in
that Allegro doesn't need to handle drawing it. It can be a software
cursor if the platform doesn't have a native cursor and Allegro's defaults
are used.
Software and hardware cursors have existed in Allegro for a long time
(although the latter were not used). System cursors are new.
Ultimately, the API should hide the differences as much as possible, and
the end user would only see a `custom cursor' or a `system default'
cursor.
What I think is confusing is that the MOUSE_CURSOR_ARROW and such are
really system cursors, which can be turned into custom cursors by
specifying a bitmap for them which is not NULL.
> // default: no mouse at all inside the Allegro window
Yes.
> show_mouse(my_bitmap)
> // now I can be sure the mouse is drawn into that bitmap (from a timer)
Yes - except if a system cursor is currently being drawn. The reason for
this behavior is that the GUI objects check if mouse_screen is set and
call show_mouse() if it is not. For system cursors, mouse_screen is NULL
but a cursor is displayed.
Thinking about this, it would be incorrect with the current code to assume
that mouse_screen being NULL means that there is no pointer. The proper
way to fix this would be to make a function that tells wether a mouse
cursor is being displayed, and if so on which bitmap (it would return
screen for the system cursor). This would break programs depending on the
old behavior though. An API compatible way to deal with this is to set
mouse_screen to screen when a system cursor is in use, but the code in
mouse.c needs to be double checked to make sure this doesn't introduce
errors.
> enable_hardware_cursor()
> // now the hardware cursor is drawn - if possible, else it stays in
my_bitmap
No, Allegro will now try to use a hardware cursor (!=system cursor) if
possible - which it is not if show_mouse() was called with a memory bitmap
as argument.
> show_mouse(NULL)
> // no more mouse is displayed
Custom cursors are hidden, but system cursors are currently unaffected.
> enable_hardware_cursor()
> // the hardware mouse is displayed again
No, Allegro is allowed to use this again.
> show_mouse(my_bitmap)
> // the mouse again is in my_bitmap
Yes.
> disable_hardware_cursor()
> // it is drawn in my_bitmap again
This will not actually affect where the mouse is drawn, only how it is
drawn. Allegro will no longer use a hardware cursor.
> Would all the comments above be true with your patch? I think the
> behavior implied by them makes sense..
It is the current behavior, and true for custom cursors. It is not strictly
true for system cursors.
I think I'm going to postpone the finalization of the system cursors until
after the WIP release - or rather, I don't think it's worth delaying the
WIP for.
Evert