Re: [MiNT] [Mint-cvs] [FreeMiNT CVS] lib/gemlib

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Wed, 2005-07-13 at 23:12 +0000, Odd Skancke wrote:
>  Agreed on wind_calc() should return error. I dont agree wind_set

Why have it return an error?

> (WF_CURRXYWH) should return error. Its in the name CURR as in current.
> Do not confuse CURRENT with FULL. Its just that normally the AES was
> FULL-area oriented while in WCOWORK mode, the AES is WORK-area oriented.
> WF_CURRXWYH changes behaviour thereafter. If anyhting WF_WORKXWWH should
> return error, as this mode looses its meaning.

I don't think the names of the flags are important.  One returns the
working area.  One returns the full area.  Both might be useful to
someone.  Why change things and remove one?

>  Besides, under MiNT there is the /pipe/alert to wich application can
> write important notes, and the system decides how to show it. Ofcourse
> this is not supported under MagiC or SingleTOS, so it is not used.

Hmm .. I suddenly imagine a GEM application that could watch the alert
pipe and display critical errors, or be configured as to what and how to
display them.  Maybe even do some weird stringserver integration.

As for reporting debugging errors ... put TOSWIN in the desktop.

>  I would think such a lib would return the size of its output for the
> user. Then the user would use, for example, windom to create the window,
> and use its features to install a function for WM_REDRAWs that calls the
> the draw function of the form library to draw the form inside the
> window. Having two libs using the AES in this scenario is just plain bad
> design. Doesnt matter if the libs output is a form or a text or image or
> mplayer. Neither should NEVER go to the GUI by themselves.

I think its OK that libs make AES calls.  That isn't the problem.  They
both shouldn't be processing events!   The details that the library
would get, as your example points out, would be things like a redraw
callback.  The coordinate system wouldn't change and these libraries
wouldn't care which coordinate system the window was in - especially if
you kept the WF_WORKXYWH and WF_CURRXYWH calls the way they work now,
without ever changing their behavior as I mentioned above.  

> > >> Another example (that already exist) : WoutLib. This is a "windowed
> > >> Output" library. For example, in your code you put "wout_printf("blabla
> > >> %d", var);" and woutlib will open a window (if not already opened),
> > >> display there the string, manage the window when opened (slider,  
> > >> scrolling
> > >> when new text is displayed, etc...).
> 
>  Then this is a badly designed lib.

A library that manages its own events sounds weird to me.  Who does the
evnt_multi()?   Smells like a hack.

>  The implementation is is not a hack, but you are right it is far from
> complete. I was hoping for constructive critisism instead of being told
> it is useless because the way you design your library. While your idea

I've been trying!!  See my last very long post for an alternative that
may satify all these arguments