SwiXML robustitude

Hello,

To date our Swing GUI requirements have been modest and have been 
satisfied with in-line code.  Our Swing GUI needs continue to expand 
and can be expected to grow and there's no way I want to support 
massive amounts of GUI glue code.  During my many years of developing 
X/Motif GUIs I heavily utilized Motif's UIL and IMHO the UIL/XUL 
approach to GUI development and maintenance is optimal.

So I'm looking for the Java Swing equiv of Motif's UIL and it looks 
like SwiXML is it.

Before I invest a lot of time discovering more about SwiXML I'd like to 
ask some general questions:

Q1) I don't suppose there's anyone out there that has some Motif UIL 
experience and can offer a comparison of functionality and robustness?

Q2) How well does it scale?  It seems it's modular so I expect it can 
handle a large and complex GUI via decomposition.  But does it have any 
obvious and restrictive limitations on the size and complexity that can 
be described in one XML declaration?

Q3) How mature and stable is it?  Can I expect what's there to work 
today and even more importantly can I expect to be able to carry what I 
implement today forward without significant rework?  How about for Mac 
support specifically?

Q4) Are there any non-obvious issues with incorporation of it into a 
commercial product?

Q5) How well does it support GUI glue functionality?  By glue I mean 
code that is part of the UI but not intrinsic to the toolkit.  A simple 
example would be I need a toggle button that controls the sensitivity 
(i.e. enable/disable) a set of other GUI objects.  Code that implements 
this falls in the crack between my business logic and the toolkit but 
scripting is not necessary to solve the problem.  It can be solved by 
generic GUI support code as long as I can inform that generic code of 
the objects involved via the UIL/XML.  Can object A reference object B 
in the XML?

Thanks very much for your time.

-- ced


-- 
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.