Hi, Hal.
While mixing toolkits would indeed be a godsend, that sort of thing is still
kind of in the realm of fantasy, as each toolkit usually has its own
message/event loop... usually done in a pretty incompatible way.
I would suggest you either embed a browser into your application and/or
write a simple html renderer, if that''s enough for your needs. If you
are
on windows, embedding something like explorer is relatively easy (you really
just need the HDC handle), but your application will be limited in terms of
OS support, as doing the same on unix systems is not as simple (or, at
least, I don''t know how). I can probably dig some C++ embedding
example if
you want.
Writing an html renderer for simple stuff is also relatively simple, but
supporting all that your users'' expect from web browsers these days
(css,
tabs, marking menus, etc.) is the work of a lifetime.
For a pretty good and simple html browser, it is hard to beat FLTK''s
Fl_Help_View. It supports all html2 tags, including graphics. You can
probably use it as template to write a Fox widget if you want to go that
way.
If you have not settled on a GUI toolkit yet for your application, using
FLTK instead of Fox is also something you should consider. Stay as far away
from Tk as you can, as it is a slow and ugly looking toolkit.
FLTK''s ruby bindings are also pretty mature (at least for fltk1) and
FLTK
itself is also a very good toolkit, with an identical LPGL as Fox (you can
use it for commercial stuff -- as a matter of fact, Digital Domain''s
Nuke
compositing package, arguably the best compositing software on the vfx
industry, is fully written with it and propels the development of Fltk
itself).
Compared to Fox, FLTK''s benefits are:
- A tad richer widget set for common stuff.
- Lighter and a tad faster than Fox overall.
- Simpler and a tad better documented api.
- GUI builder (for C at least, albeit I also once wrote a custom version
that spit ruby code instead)
- Excellent demo examples of pretty much every single aspect of the toolkit
(makes it much easier to learn than Fox).
- Much simpler and better support for GL and double buffered windows
(Fox''s
need to use off-line images and blit them is a pain in the neck).
- Ruby''s FLTK binding does not use SWIG, but a macro system. This
makes it
much easier to add new classes than having to learn how swig works and also
faster as the (minor) SWIG overhead is not there.
- FLTK''s table support (particularly thru the FLVW add-on) is better
than
what Fox offers.
Disadvantages:
- Ruby''s FLTK binding does not come in precompiled binaries or as a
gem.
- Ruby''s FLTK binding does not use SWIG. Albeit simpler, this will
probably
present a problem with future Fltk versions such as the upcoming FLTK2 as
making it work with Ruby will probably need to be a big rewrite. Note that
python''s Fltk bindings are done with SWIG. Still, very, very hard to
beat
Lyle on the amazing work he has done with fxruby and the like.
- Ruby''s FLTK documentation is pretty much non-existant, but I found it
pretty self explanatory, particularly as there''s a 1:1 relationship
with the
C++ api.
- Ruby''s FLTK project is not done by the mantainers of the toolkit,
unlike
Fox. This means that your ruby bindings are probably behind the C++ api
(not much of an issue as most C++ development now is on v2 of fltk, not v1).
The ruby fltk project had been dropped but now there''s someone taking
charge
of it again.
- Default widgets are a tad uglier looking than Fox, albeit YMMV.
- There isn''t any real MDI controlling system in FLTK as in
Fox''s really
good MDIChild/Client. You can still popup windows within windows with no
problem, but you have to take care of doing the listing and user management
of them in menus yourself.
- API is OO, but their callback mechanism is not. Callbacks need to use
static functions. If you are going to be dealing with it from Ruby, this is
not an issue, thou. Also, the GUI builder in fltk hides this unpleasantry
from you.
- FLTK does not use any ID messaging system like Fox. I''m still trying
to
decide whether that is a plus or a minus.
Same-oh-same-oh (if you need these today, you probably want something
commercial like Qt):
- No Unicode/UTF-8 support.
- No themes.
- No unified printing.