[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: wxWindows vs. FLTK
- From: "Nick Trout" <ntrout@...>
- Date: Wed, 12 Feb 2003 14:03:28 -0800
> paul_winwood <email@example.com>
> Sent: February 12, 2003 9:57 AM
> To: Multiple recipients of list
> Subject: Re: wxWindows vs. FLTK
> I have read the comments made about bloat when using wxWindows and I
> wanted to put the other side of the story.
> The 2MB Windows wxLua executable contains most the wxWindows UI
> bindings this includes all the 'modern' UI devices such as docking
> windows, toolbars, status bars and a colour syntax highlighting
> editor. This means that in the 2MB executable there is everything
> required not only to run wxLua programs but you can edit and debug
> them as well. The IDE is written in Lua code, compiled with luac and
> then compiled into the executable.
I started writing a Lua Editor/Debugger in wxWindows and I was surprised
how small the exe was when I statically compiled wxWindows (400/500k if
I recall - considering the size of the library anyway). There is a lot
you can remove. I did some homework when I was choosing a GUI for Lua
and the Lua community and these are my notes (granted FLTK now has a Mac
I came down on the size of wxWindows because:
* It has the largest widget set.
* It's the most portable.
* It is very well supported and has a large community (FLTKs look pretty
* wxStyledTextCtrl which is basically Scintilla
(http://www.scintilla.org/SciTEImage.html) wrapped (and quite nicely).
Note, this has a lexer for Lua built in.
* It has SWIG support so in the event that I end up having to bind it,
it could be done using LuaSWIG.
* I didn't like the FLTK GUI editor and there werent any others.
wxWindows has a number of commercial and open solutions.
I agree that it would be better to have more than one solution but I
also think binding and maintaining an evolving GUI library is a lot of
work, so the effort would be best spent on one solution initially. I
Think wxLua/wxWindows is the better solution for the reasons above.
Python had Tcl/Tk bindings from early on and although I don't really
agree that it was the nicest library to use it did unify the community
and some useful tools came out of it (eg. IDLE). I think there is going
to be an awful lot of work creating this library - and a lot maintaining
it. Beware of spreading the effort too thinly over too wide an area.