Lee Brown <[EMAIL PROTECTED]> writes:
> typedef guint ggi_cursor_t;
>
> typedef struct {
> guint16 bpp;
> guint8 width;
> guint8 height;
>
> ggi_color* palette;
>
> void* bits;
>
> guint16 hot_x, hot_y;
> } ggi_cursor;
guint8 for width and height seems a little too restrictive.
especially as hot_x and hot_y are guint16 :-)
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.)
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)
> GList* ggiListCursors(ggi_visual_t vis);
>
> ggi_cursor_t ggiLoadCursor(ggi_visual_t vis, ggi_cursor* cursor);
> int ggiUnloadCursor(ggi_visual_t vis, ggi_cursor_t cursor);
> int ggiSetCursor(ggi_visual_t vis, ggi_cursor_t cursor);
> ggi_cursor_t ggiGetCursor(ggi_visual_t vis);
>
> int ggiShowCursor(ggi_visual_t vis);
> int ggiHideCursor(ggi_visual_t vis);
> int ggiMoveCursor(ggi_visual_t vis, gint x, gint y);
> gboolean ggiIsCursorShown(ggi_visual_t vis);
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)
some thoughts:
the enduser who doesn't want to be concerned with the 'cursor'
argument could use a higher level gui library. i think the audience
for a function like this is in lowlevel gui developers (amongst
others), and i think it's no problem to address the cursor directly.
most statements would be combinations of
"ggiSetCursor();ggiShowCursor();" anyway, as the cursor could change
every frame.
what are your reasons to make this decision? if it's speed, then
neither is better (a dynamic call versus an extra argument); if it's
ease of use, i'd give the "use a higher level library" argument for
cluebies and have the cursor as an extra argument for lowlevel/gui
developers.
i noticed libggi has a few of these Set/Get quirks that look very much
like Borland's BGI interface to me :) i never use them and they seem
very painful for advanced use; they are mostly meant for newbies or
portability freaks who don't want to meddle all too much with system
dependencies.. or at least that's what i think -- please correct me if
i get this wrong :))
how do show and hide work? do they draw at every ggiFlush()?
--
Tijs van Bakel, <[EMAIL PROTECTED]>
the guy who loves design issues but never decides on something :)
