1. Design question for a cross platform GUI (FLTK)
Hi,
I have been playing around with a cross platform GUI called
Fast Light Tool Kit ("FLTK") at http://www.fltk.org/.
I have a few simple things working (in Windows) and it looks
great! It is not as extensive as Win32Lib but is much smaller
(and so far simpler). One drawback is that it uses it's own widget
set (like gtk). It also doesn't have the rich set of widgets
available like wxWindows. I guess this is the trade off for being
small and simple!
I have to make a decision as to how I will expose the classes
and methods of FLTK. It has a rather different design than that
of Windows (i.e. Win32Lib) and I have the option of trying to
manipulate my FLTK wrapper to look a bit like Windows (ie
Win32Lib) or do a straight wrapper to FLTK as FLTK works.
For example ... Radio buttons. In FLTK a radio button is just a
"Round" command button with the RADIO attribute set.
I could force my wrapper for the "Round" command button to set the
RADIO attribute to make it look like windows ... or I could leave
it as FLTK does and let the programmer decide how they want to use it.
At this stage I'm leaning towards the "leave it as FLTK" does it method
as it is the most flexible and powerful. The down side is that this
method is also the most "foreign" to current Windows and Win32Lib
programmers.
Just as a side note I have wrapped an "ASK" dialog box class that asks
a yes/no question with some text ... I have this bug where "YES" is the
only button that is displayed ... and it sort of reminded me of one of
the questions in the Euphoria survey!!!! (Which I will have to tabulate
one day!)
I feel pretty bad about not completing that (IF anyone wants a really
boring
job I'm willing to send them all the results to be tabulated!!! Any
takers???
anyway ... back to my question ... does anyone have any comments either
way on
the "best" way to wrap FLTK?
Anyone have any other questions about FLTK?
Ray Smith
http;//www.geocities.com/ray_223
2. Re: Design question for a cross platform GUI (FLTK)
Ray Smith wrote:
<snip>
> I have to make a decision as to how I will expose the classes
> and methods of FLTK. It has a rather different design than that
> of Windows (i.e. Win32Lib) and I have the option of trying to
> manipulate my FLTK wrapper to look a bit like Windows (ie
> Win32Lib) or do a straight wrapper to FLTK as FLTK works.
>
> For example ... Radio buttons. In FLTK a radio button is just a
> "Round" command button with the RADIO attribute set.
> I could force my wrapper for the "Round" command button to set the
> RADIO attribute to make it look like windows ... or I could leave
> it as FLTK does and let the programmer decide how they want to use it.
>
> At this stage I'm leaning towards the "leave it as FLTK" does it method
> as it is the most flexible and powerful. The down side is that this
> method is also the most "foreign" to current Windows and Win32Lib
> programmers.
</snip>
I think that leaving it a s FLTK does it is the better approach for a
general library. It would be considerably easier to extend the basic library
to make it more windows-like when that was desired than to have to
"unextend" a windows-like library when FLTK behavior was desired.
If fact, if you're feeling ambitious, why not try both: Code your library
using the leave it as FLTK approach, and as a separate include file, code
wrapper functions for the basic library for more windows-like behavior.
-- Mike Nelson
3. Re: Design question for a cross platform GUI (FLTK)
Ray Smith wrote:
> I have to make a decision as to how I will
> expose the classes and methods of FLTK.
I chose to make Win32Lib look a lot like Visual Basic because I think it VB
does a good job of hiding complexity from the end user. Other than having to
know about how to repaint a window, you don't need a lot of information
about the underlying toolkit.
The problem with this approach is that the wrappers are a bit more complex.
You end up having to do a bit of work behind the scenes to get things to
work, and this gets in the way of the 'power user'. A good example of this
is the font system - it's convenient for the end user, but not especially
efficient. If you're trying to emulate a rich text display that needs to
display a lot of fonts in a lot of styles, it's much more efficient to write
your own wrappers.
Other factors include the size of the toolkit, and how often it changes. If
you are autogenerating your wrappers with something like SWIG, it's much
simpler if you use the 'native' approach. You just create a wrapper
generator that, given a file of C++ function prototypes, spits out C
wrappers. Much less "hands on', an you can concentrate on other things. If
the toolkit is large, or has a nice API, this is the way to go.
-- David Cuny
