1. Design question for a cross platform GUI (FLTK)
- Posted by Ray Smith <smithr at ix.net.au> Oct 14, 2001
- 563 views
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)
- Posted by Mike Nelson <MichaelANelson at WORLDNET.ATT.NET> Oct 15, 2001
- 554 views
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)
- Posted by David Cuny <dcuny at LANSET.COM> Oct 15, 2001
- 567 views
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