nanogui: Thread: Re: [linuxce-devel] FLTK Port, list of Win32 functions...

Shane, I really appreciate you getting this list of win32
functions done.  Since Microwindows is basically my project,
I'm definitely commited to getting these functions implemented.
I'm assuming that the many other win32 functions not listed
are already implemented by Microwindows (like CreateWindow,
etc)  It might be nice to have the WHOLE list, since there are
also certain aspects of these functions that aren't fully implemented.

I will get a stubbed out version of Microwindows going that you
can link with, and let you know which functions need a little more help.
My idea is to get this going quickly, so the best approach is probably
to get it linking and running, even though it may limp heavily in certain
areas  (like for instance, even if the region code is not fully there for
clipping, then the drawing might not clip fully correctly, but you can
still draw...)

This is quite cool, since there haven't been enough programmers on
the list capable of actually performing a widget set port, so this
is exactly what Microwindows needs, and I want to take advantage
of it (or you ;-)

Please use Microwindows v0.88pre2, which I just posted to the ftp site
last night, it's the latest tree.  I'll produce some stubbed out routines
immediately
that you can use to link against, so that you can at least get a linked version.
You might also think about putting together some _simple_ fltk demos, used
to test the Microwindows win32 implementation.

There will undoubtably be some #ifdefs to the master fltk code, but we'll try
to keep it to a minimum.  I've got to see the whole list of win32 calls that
fltk
makes in order to get a good feel for how it actually draws (note that none
of the unsupported calls that you list here actually draws anything... so we're
in pretty good shape, it seems)

Regards,

Greg

----- Original Message -----
From: ####@####.####
To: ####@####.#### ####@####.####
Sent: Friday, March 03, 2000 12:15 PM
Subject: [linuxce-devel] FLTK Port, list of Win32 functions...


: NanoGUIer's, and linuxce'ers,
: In order to complete the FLTK port to microwindows we will need the
: folowing Win32 functions implemented in microwindows.  Anyone is free
: to lend a hand in the port.  Greg has already done some work on some
: of these functions (specifically regions), so you should check with
: him before starting work on anything in specific.  I'm finishing up
: some more proprietary aspects of the FLTK win32 operation, but if
: you'd like to help out in implementing one of these functions please
: send me or Greg an email.  If you'd like information on how to build
: fltk with microwindows send me an email, and I'll send you
: instructions and my build files.  (Once we're further along I'll setup
: a website, etc.)
:
: Thanks,
: Shane..
:
: Here is the list:  (Also, for each you need to insert all the
: constants and structures that are needed, there is only about two more
: structures that have to be implemented in microwindows.  If you'd like
: all the function prototypes, send me an email, and I'll forward them
: to you.)
:
: CreateRectRgn
: GetRgnBox
: CombinRgn
: InvalidateRgn
: GetUpdateRgn
: ValidateRgn
: SelectClipRgn
: EqualRgn
: CreateBitMap
: SetAlignText
: SelectPalette
: OpenClipboard
: EmptyClipboard
: GlobalAlloc
: GlobalLock
: GlobalUnlock
: CloseClipboard
: GetClipboardData
: GetKeyState
: GetKeyboardState
: PeekMessage
: SystemParametersInfo
: GetCursorPos
: GetAsyncKeyState
: SetCursor
: UpdateColors
: GetSystemMetrics
: SetWindowPos
: LoadIcon
: LoadCursor
: RegisterClassEx
: IsIconic
: OpenIcon
: BringWindowToTop
:
: This is pretty much all of them.  The other problems are not specific
: to Win32 GUI, but other issues which I'll be taking care of next week.
: If there is any functionality that cannot be replicated I'll be
: implementing work arrounds in the code of fltk.  Once again anyone
: whos been complaining about not having a widget set... this is your
: chance to help it become reality :).  Microsofts Developer site is a
: good resource, as well as the ones that Greg mentioned the otherday,
: wine, twin, and I can't remember the third.  In any event, I'm
: commited to doing this port, so whatever isn't implemented elsewhere
: I'll start taking care of once I've finished the more proprietary
: issues in fltk.
:
: Thanks,
: Shane.
:
: _______________________________________________
: linuxce-devel mailing list
: ####@####.####
: http://mailman.bok.net/mailman/listinfo/linuxce-devel
:

Shane,
    I've pulled down the source to fltk v1.0.7, and checked
it out.  I've responded to your list of functions with the following
actions that I'm going to try to take to get you up and running
fast.  Also, there are still other files that you haven't included in the
make that will be required, like fl_draw_image_win32.cxx.  This
includes the SetDiBitsToDevice function, which I will implement.

After looking at all of it, it shouldn't be too hard getting fltk running
under Microwindows...

Anyway, here's the list:
: 
: CreateRectRgn yes
: GetRgnBox yes
: CombinRgn yes

: InvalidateRgn comment out
: GetUpdateRgn comment out
: ValidateRgn comment out

the above routines are used in a strange way to play with window's
paint algorithm.  At this point, you'll just want to call BeginPaint/Endpaint
around the WM_PAINT msg.  (for more info, see microwin/src/demos/mwin/
demos)


: SelectClipRgn not yet
: EqualRgn yes

Although I plan to support regions, these probably aren't necessary,
as most are used for the painting trickery, which isn't needed...


: CreateBitMap - replace with CreateCompatibleBitmap
: SetAlignText - yes
: SelectPalette comment out
: OpenClipboard no
: EmptyClipboard no
: GlobalAlloc replace with malloc
: GlobalLock replace with nop
: GlobalUnlock replace with nop
: CloseClipboard no
: GetClipboardData no
(clipboard will likely never be supported)

: GetKeyState comment out
: GetKeyboardState comment out
For now, comment out all kbd stuff, including messages, except
WM_CHAR

: PeekMessage yes
(note: fltk uses a strange mechanism where win32 select() AND
PeekMessage() are called to handle sockets and messages...  This
will need rewriting to just GetMessage or PeekMessage in the
beginning, unless the fltk program uses sockets)



: SystemParametersInfo replace with GetWindowRect(GetDesktopWindow(),...)
    to get the screen x, y, w. h. size

: GetCursorPos yes
: GetAsyncKeyState comment out
: SetCursor yes
: UpdateColors no
: GetSystemMetrics possibly, depends on the value
: SetWindowPos yes
: LoadIcon yes
: LoadCursor yes
: RegisterClassEx yes
: IsIconic yes
: OpenIcon no
: BringWindowToTop yes
: 
Regards

Greg

Shane,
    I am slightly revising my ideas on how to port fltk, after
spending most all day looking into it.

I think at this point, that it would be best to try to get
fltk linked, even if it barely runs...  So, I suggest that
you comment out many, many calls with //FIXME
or something like that, and then work on getting
the window creation, main loop and basic
painting going...  pick the simplest fltk demo
you can find and get that running.

following are my revised ideas on which functions I 
can implement easily....

I have all the region calls, in, but they don't all work the way
we may need yet.  I will post a 0.88pre3 soon that has them.  In the
mean time, we'll want a single BeginPaint/Endpaint combo for ALL
painting

: : SetAlignText - NO

: : PeekMessage NO
: (note: fltk uses a strange mechanism where win32 select() AND
: PeekMessage() are called to handle sockets and messages...  This
: will need rewriting to just GetMessage or PeekMessage in the
: beginning, unless the fltk program uses sockets)

Just rewrite and use a single GetMessage call in fltk's main loop.


: : GetCursorPos done
: : SetCursor NO
: : SetWindowPos complicated - use MoveWindow instead
: : LoadIcon NO
: : LoadCursor NO
: : RegisterClassEx no - use RegisterClass instead
: : IsIconic NO
: : OpenIcon no
: : BringWindowToTop use ShowWindow instead for the time being.

I know what we can get fltk running with Microwindows quickly.  But
the key is keeping the number of calls into Microwindows DOWN, rather
than UP.  Then we can add functionality after you/we get a simple demo
running.  So, as I said, I think just getting the window creation, basic
display and painting, and message loop going are the best bet...

Regards,

Greg

Greg,
Yes, there are quite a few things that will need to be changed
arround.  Most of the fl*_win32.cxx files will have to be redone as
fl*_microwindows.cxx and much of it will have to be written in NanoX
speak.  Following a tip from Greg I noticed that some stuff was
getting left out in my build of fltk, so here are the functions that
should be added to the list I posted:
Arc
Pie
MessageBeep
CreatePalette //fixmeable... (very minimal impact)
RealizePalette  //fixmeable... (very minimal impact)
SetDIBitsToDevice //this will have to be done in NanoX speak prob.
CreateFont
GetCharWidth
GetTextMetrics
Polygon
RectInRegion
Polyline
PolyPolygon

I'm just trying to put together a full list of things that will be
needed for a "full port"..., however fltk will work well without all
of this functionality.  I belive at this point we have a full listing.
(Pretty sure actually, just made my first libftk.a designed for
microwindows :>... minus five .cxx files, these are the ones I'm in
the midst of re-writing.  Probably a week of concentrated work
away from getting a linking program that will execute and give
anything of use..., but oh well.)

On Sat, Mar 04, 2000 at 09:46:53PM -0700, Greg Haerr wrote:
> Shane,
>     I am slightly revising my ideas on how to port fltk, after
> spending most all day looking into it.
> 
> I think at this point, that it would be best to try to get
> fltk linked, even if it barely runs...  So, I suggest that
> you comment out many, many calls with //FIXME
> or something like that, and then work on getting
> the window creation, main loop and basic
> painting going...  pick the simplest fltk demo
> you can find and get that running.

I'm working on that right now...,  I'm just going to create my own
demo sets more than likely and tread lightly arround things that are
"known trouble makers".  A lot of the fl*win32.cxx stuff is what I
would consider "fluff" at this point.  (MessageBeep... come on :>)

> following are my revised ideas on which functions I 
> can implement easily....
> 
> I have all the region calls, in, but they don't all work the way
> we may need yet.  I will post a 0.88pre3 soon that has them.  In the
> mean time, we'll want a single BeginPaint/Endpaint combo for ALL
> painting
> 
> : : SetAlignText - NO
> 
> : : PeekMessage NO
> : (note: fltk uses a strange mechanism where win32 select() AND
> : PeekMessage() are called to handle sockets and messages...  This
> : will need rewriting to just GetMessage or PeekMessage in the
> : beginning, unless the fltk program uses sockets)
> 
> Just rewrite and use a single GetMessage call in fltk's main loop.
> 
> 
> : : GetCursorPos done
> : : SetCursor NO
> : : SetWindowPos complicated - use MoveWindow instead
> : : LoadIcon NO
> : : LoadCursor NO
> : : RegisterClassEx no - use RegisterClass instead
> : : IsIconic NO
> : : OpenIcon no
> : : BringWindowToTop use ShowWindow instead for the time being.
> 
> I know what we can get fltk running with Microwindows quickly.  But
> the key is keeping the number of calls into Microwindows DOWN, rather
> than UP.  Then we can add functionality after you/we get a simple demo
> running.  So, as I said, I think just getting the window creation, basic
> display and painting, and message loop going are the best bet...

Agreed.  I'm a bit concerned about how fltk handles events..., its
very odd.  Thats what I'm working on first as it's giving me lots of
headaches at the moment :).  I'm going to clean out my header files to
stock when you put up the version of which you were speaking, and then
just start commenting like a mad man.  I'm sure that we can wiggle our
way around a lot of fltk calls into microwindows.  Once we have a
linking version of fltk, we'll work on the displaying part, then
finilize the events, and then start working arround those microwindows
calls.  Either implementing them in microwindows where absolutely
necessary, or working arround them.  (There are a lot of unnecessary
calls at this point that we can definetly avoid... or re-write them
into NanoX speak.)

Thanks microwindows master Greg,
Shane.

I have browsed the library for while. It looks very good.

It'll be an excellent toolkit for MicroWindows.

Keep up with the good work guys !!!.

Rosimildo.

 


______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com