we built what we called a cross-application/cross-platform framework
in C++.

it's hard to succintly describe exactly.  it's not a widget library.
and it's not a kitchen sink like MFC.  nor is it a virtual gui like
Mozilla.

we tried to achieve a proper balance between what needs to be in 
platform-native code and what needs to be in platform-independent 
code -- so that we get a true native application, but one that 
works identically on the various platforms.  so i really don't
think of it as a "toolkit", but rather as a "methodology" for
developing cross-platform applications.  (but i'm probably being
short-sighted or overly anal :-)

[] it provides a structured framework for developing a typical gui,
   document-oriented application; that is, it provides the structure
   for the document/view/controller model in a cross-platform way.

[] it also provides a framework for synthesing portions of the ui
   (such as toolbars and menu) in platform-specific code based upon
   common data tables -- rather than platform-specific resource files.

[] it provides a strategy for dividing ui features into semantic and
   presentation portions.  the semantic portions are shared by all
   and the presentation portions are tight and well-contained in
   platform-specific code.  

the result of this methodology yields a 90% shared- and 10%
platform-specific code breakdown for any one platform; so you get the
second platform for an additional 10%...  

there are some disadvantages to this approach:
[] you still need to do platform-specific code -- but it is isolated.
   but we don't hide the hardware/gui from you in another (often buggy)
   layer of widgets or complexity or limit you in 
   gui-greatest-common-denominator nonsense.
[] you still need a platform gui expert -- but for only 10% of the
   code.
[] the other disadvantage is that you need to clearly think about the
   design -- do that semantic vs presentation division thing -- but
   wait, that is a good thing....

a major advantage here is in QA effort and consistency.  because
platform code is so relatively small and isolated, it can be
easily tested.  the main QA effort can then focus on the meat
of the application -- not the platform-specific eye-candy -- and
can be done on any platform.

<well, enough of my soapboxing>  -- i hope this is helpful.  i know
it's more than what you probably want for your table.  here are some
slides that Paul Rohr used for a Linux World presentation in 2000
that might be helpful: 
http://www.abisource.com/papers/lwce2000ny/sld001.phtml

--Jeff Hostetler <jeff@NerdOne.com>