On Thu, 01 Feb 2001, Tijs van Bakel wrote:
> guint8 for width and height seems a little too restrictive.
> especially as hot_x and hot_y are guint16 :-)
I'll fix this. This has to do with the format of .cur files. Which seem to
be the industry standard for describing cursors. Check this out. There
are plenty of web sites selling or giving away .cur files.
>
> the palette is meant for indexed modes only? (shouldn't there be a
> ggi_palette for this? maintaining malloc()'s for this in different
> libraries seems like asking for bugs.)
No. The palette has nothing to do with modes. Each pixel of
the cursor has an index to the palette for its color.
Again, this has to do with .cur files.
>
> of course i think this would be better handled as a sprite in a
> sprite/blit library; however there's a specific case for hardware
> mouse cursors, so this has to be given some more thought. i will work
> on a sprite library (andreas sent me his libBSE basics, and it looks
> very useful to _me_ (i was writing an extension), although it doesn't
> feature much yet)
Precisely. This is supposed to be an abstraction of the hardware mouse
cursor. Giving access to a hardware cursor when available, and providing
a software cursor when needed. Sprites are similar but not the same. We could
probably learn from eachother because they are similar.
> basically it looks ok to me; i do think however that it'd be better to
> use something like:
> ggiShowCursor(ggi_visual_t visual, ggi_cursor_t cursor);
> (as you suggested)
> how do show and hide work? do they draw at every ggiFlush()?
Well just wanted the user to be able to toggle the current cursor.
Sometimes you want a cursor on, sometimes you don't. Depending on the
target, it may be neccessary to ggiFlush for the change to take place.
>
> --
> Tijs van Bakel, <[EMAIL PROTECTED]>
> the guy who loves design issues but never decides on something :)
--
Lee Brown Jr.
[EMAIL PROTECTED]
