From: Tristan Wibberley <twibberley@llamacom.com>
  To  : Marcus Sundberg <mackan@stacken.kth.se>
  Date: Sun, 30 Aug 1998 14:19:11 +0000

Re: New function in libggiMisc RFC.

Marcus Sundberg wrote:
> 
> Tristan Wibberley wrote:
> >
> > Hi all,
> >
> > I think something is needed for greater window system support (in X and
> > eventually berlin).
> >
> > It would be nice to see sets of widgets that use ggi to draw. I propose
> > one new call in ggiMisc and some new struct definitions.
> >
> > The call would do nothing on most targets, but on X you fill in a struct
> > with some data such as title, geometry, borderstyle and pass that to
> > this function which the target implements. GGI should not specify the
> > behaviour but the target should - ie, you need to know what you're
> > doing, but it's not complicated.
> >
> > eg: (pseudocode):
> >
> > #define GGI_WINSTD structsize;
> >
> > typedef void *ggimisc_win_t;
> >
> > typedef struct {
> >         GGI_WINSTD;
> >         title;
> >         resizeable;     /* not by default no way, but allows
> >                            you to resize and check mode on EvExpose */
> >         geometry;
> >         winstyleflags;
> > } ggimisc_xwin;
> >
> > typedef struct {
> >         GGI_WINSTD;
> >         title;
> >         titleface;
> >         blah;
> > } ggimisc_berlin;
> >
> > void setupwin(gg_visual_t vis)
> > {
> >         ggimisc_win_t windata;
> >         ggimisc_xwin xwindata;
> >
> >         /* fill the xwindata struct */
> >         windata = (ggimisc_win_t)(&xwindata);
> >         ggiSetWinData(windata); /* copies the data ready for use if mode not
> >                                    set yet, else uses the data */
> > }
> >
> > We need a way to tell what target ggiOpen(NULL) has chosen, is that
> > possible already. A programmer needs to be able to choose how to fill in
> > the struct for the windowsystem being used.
> >
> > This definately needs a lot of thought, but I think we should implement
> > something like this.
> 
> Yes, I've been thinking of window-titles and such before.
> Putting sucha function in ggimisc is a good idea, but the
> structure passed should _NOT_ be targetdependent. This defeats
> the whole purpose of GGI. Parameters that doesn't make sense to
> the particular target will simply be ignored, and their entries
> will be set to NULL/some other invalid value uppon return.

Agreed.

> So what does this structure need?
> 
> typedef struct {
>         char      *title;
>         char      *iconname;
>         ggi_coord  position;
>         char       resizeable;
>         char       borderless

          void      *targetdata;

> } ggi_wininfo;

We at least need to allow for a target to accept non-standard data (we
don't know what might be provided by other targets such as berlin) -
just let that be not-guaranteed. The first field of the target data
should be guaranteed to be an int containing an identifier to indicate
which target this data is for - so if you provided data expecting X,
berlin knows to ignore it. Perhaps the second field of targetdata should
be guaranteed to point to another targetdata struct or void - Now a
programmer can load data for all the targets he wants to support.

> int ggiSetWinInfo(ggi_visual_t *vis, ggi_wininfo *info);
> int ggiGetWinInfo(ggi_visual_t *vis, ggi_wininfo *info);
> 
> Looks good?

Yes. We should specify that this data will be parsed either immediately
if a visual has had it's mode set (ie is visible), or when the mode
eventually gets set - so you can specify how it should be set up before
you ggiSetMode.



Would it be too much to ask for a function which is passed a visual of
the same size, and specifies that it will crossblit on ggiSetMode, so
you can have it drawn before a big black window appears - this could
otherwise get ugly :( Can/should this be done?

--
Tristan

ps, did this message have twibberley@llamacom.com as the reply-to
instead of ggi-develop@eskimo.com? (I have CC'd this there).