Re: [AD] 4.1.17

[Elias Pschernig <allefant@xxxxxxxxxx>]

> 
> Not quite. You can't change the value and pass it back to the caller, but
> you can change the value of the parameter within the function itself.

I see. Still, I don't see the usefulness.

> > I tested it (in linux), and it seems to work. Should update exmouse to
> > demonstrate the different cursors. And, there should be another function
> > set_mouse_cursor(int cursor, BITMAP *bmp) (or different name), similiar
> > to set_mouse_sprite.
> 
> To change the default Allegro cursor? I thought about adding that (in fact,
> I used to have it), but I'm not so sure about it now. You're requesting the
> default system cursor, so IMHO it doesn't make sense for the user to say
> something like `ok, give me the default Windows pointer, but if you can't
> do that, I don't want Allegro's, I want to use my own instead'. You either
> accept the default system pointer or you don't, in which case you'd use the
> default Allegro cursor anyway.

The problem is, I don't want to request a system cursor - just a
different cursor, and I don't care who draws it. Imagine someone
creating a mouse cursor theme, just like a GUI theme. Right now, it
would be like forcing the Allegro GUI to everyone, without the
possibility to use your own.

> That said, I have no real objection to adding it, so I probably will (maybe
> not for this release though).

Yes, this can wait.

> > Or maybe set_mouse_sprite should always modify the
> > current one?
> 
> No, I don't really like that solution. Afterall, we got rid of text_mode
> because we didn't like states ;)

Well, I just feel an API where set_mouse_sprite does nothing even
though a cursor is displayed is confusing. About the state, I guess,
things like mouse/keyboard just need states, in the current design.

> > Could also think about making the global mouse_sprite
> > always point to the current sprite.
> 
> There is none if a system cursor is used. Ok, minor point, it could be NULL
> in that case.

Ah, true. But as I said above, I'd like the different cursors to not
be limited to hardware cursors - and in that case, it could make
sense. Otherwise we could deprecate mouse_sprite in facor of
mouse_cursor[CURSOR_ARROW].

> > Anyway, for 4.1.17, this one is ok to apply. We still have time for
> > 4.2.0 to finalize the cursors API.
> 
> True. I'll fix the mouse driver warnings and apply it.
> 
> After that, the GUI and grabber should be made aware of this change as well
> (GUI is easy: if there is no mouse being displayed, or if a default system
> pointer is in use (as indicated by the new gfx_capabilities flag), then
> it's ok to change the mouse pointer to reflect the current context, such as
> the vertical beam for text fields).

I would say, this should be independent of which cursor type is
displayed. Didn't think too much about this yet though. Will there
also be a way to allow the user to define which cursor to display in
which dialog?