nanogui: nanogui widget set
Subject:
RE: nanogui widget set
From:
Greg Haerr ####@####.####
Date:
11 Jun 1999 20:22:24 -0000
Message-Id: <01BEB414.400A3930.greg@censoft.com>
On Friday, June 11, 1999 1:31 PM, Lajber Zoltan ####@####.#### wrote:
: Greg,
:
: Is it hard to port an already working widget set?
: I looked on fltk, it's not big, has a very good gui designer and I just
: liked it for X.
:
I think the only way to go is to look at porting existing widget/custom control
sets. The key is to start with a widget set that is fairly simple, and
doesn't use alot of the more sophisticated low-level draw/clip functions.
I'm not familiar with fltk, but I would suggest starting with it's button widget,
and looking at exactly which Xlib-like calls it makes. If you want, I'll help with
this if you send me the button source.
Another major consideration is which api the widget is running on top of. For instance,
the nano-X (mini-X) engine implements a very basic (but suitable) set window-creation
and graphics draw primitives that are almost identical to their Xlib counterparts, but
with the names changed. Perhaps nano-X should change the names to be 100% compatible.
That's the approach I've taken with Micro-Windows, but with the win32 api. In any case,
a quick recompile of your fltk button widget, with all the X database stuff removed,
and all the X header files changed to a single "nano-X.h", would be the first step.
In regards to the gui designer, what is the output of this program? Does it write
a resource file or output C code? If its a resource file, its still too soon to use that
since none of that is implemented. With Micro-Windows, I plan on implementing
resource-based dialog templates after I have the base set of controls running.
The other problem is that we could probably get a small implementation of button,
radio, checkbox and static controls, but when you add edit, listbox, and pop-down
listbox, the memory requirements get significantly larger.
Greg
