nanogui@linuxhacker.org

: > CreateRectRgn
: > GetRgnBox
: > CombinRgn
: > InvalidateRgn
: > GetUpdateRgn
: > ValidateRgn
: > SelectClipRgn
: > EqualRgn
:
: This is stuff that is probably worth having in the core nanogui type code
: to do regions. In fact the server has a chunk of it

Yes.  They all work, except that I don't yet allow window clip regions
to be combined with the user's local clip region...  Not hard, I'll get this
done
this weekend.  I had previosly left all this out, since the full blown, X-like
region code (dynamically allocated) requires more memory than the simple
version that we're currently running, which uses a static array of rectangles,
and only one region is allowed.  (oh well, having full-blown clipping for any
use is probably a very good thing, since then Nano-X or Microwindows can
then be used for any application or widget set, instead of the large X11)


:
: > GlobalAlloc
: > GlobalLock
: > GlobalUnlock
:
: But chunks of this are Win32 memory allocators and have nothing to do with
: a GUI

True.  So either fltk gets changed with an ifdef or I munge these into the
following:
    GlobalAlloc    malloc
    GlobalFree    free
    GlobalLock    nop
    GlockUnlock  nop

the problem is, many win32 programs use GlobalAllocXXX.  Maybe just a define
in fltk sources is the best idea....

Regards,

Greg