JLuxor example and bugfixes [Was Re: TabPanel Issues]

The attached jluxor.zip is another example this
time using luxor to do RAD GUI prototyping through
a mockup of an existing application interface (the
GUI for FreeCIV, the Open Source version of the
Sid Meier game).

The current mockup represents a few hours of typing
in two core files, Civclient.java and Civclient.xul,
and is not intended to be complete, but rather just
complete enough to show the major elements and how
they can be made to look functional without any
underlying application code development.

The other two diffs represent the collected set of
patches I have made to the beta8 jars to enable all
the GUI elements used. These fixes will also produce
jars that make the previous stopwatch widget function
as expected (e.g. textfield works).

Cheers,
RossW
=====

Gerald Bauer wrote:
> Hi Ross,
[...]
>    Your analysis makes a lot of sense. For now,
> however, I prefer to keep it simple and let you use
> the Swing event model instead of layering another
> event model on top. As in previous mails stated: I
> will improve widget lookup and add dyanmic actions and
> dynamic forms in upcoming Betas.

I don't understand the reference to event model.

In the attached luxor.diff all I needed to do was to
expand luxor's specialized understanding of XulInput
to a base class XulComponent that now includes things
like boxes. AbstractContainer is one of the places
where undue restrictions seem to have been applied
and needed to be rolled back.

XulComponent allows one to retrieve the underlying
luxor.swing glue classes so any methods added there
to improve luxor's understanding of Swing widget
capabilities can be picked up. As I said, I suspect
these classes will turn into interfaces (i.e. luxor's
concept of a generic toolkit) when luxor finally adds
its second toolkit, as opposed to being just Swing
specific wrapper classes as they are now.

Note, I split the non-Text elements off from NInput
as NComponentX. I didn't want to disturb NComponent
by merging the elements of NComponentX back into it,
so there are a lot of rough edges in how XulComponent
papers over the cracks. You might want to take a
closer look here to see what the correct hierarchy
refactoring should be.

In addition to bugfixes to the existing luxor.swing
elements like XTextfield, there is a new method in
XTabBoxPeer. One can easily access this now without
any need to go through any Swing code/hooks.

>   By the way, how's your chrome loader package coming
> along? Are you at all interested in improving your
> first shot?

The updates to the Chrome*Loader classes are in the
attached diff. There were no changes to the original
posting needed that I am aware of. However a luxor
developer should review them carefully and feel free
to fix as needed.

The static default string for the ChromeAnchor and
the static main() code that looked at a series of
System.Properties defaults before falling back to
the hardcoded classpath default is probably user
application specific to a pretty fair degree.

Unless one wants to establish "CHROME", "CHROME_ANCHOR",
"CHROME_JAR" and/or "CHROME_FILE" as luxor defined
System.Properties tags (or some variant naming of them),
this is probably still best left in user code. Copying
the code fragment into the examples would perhaps make
this part of the default template people picked up as
part of their learning curve, i.e. a pseudo convention.

>   Also do you have any interest at all in summing up
> your Luxor bug findings so far? 

All my changes to date are in the attached diffs.

Caveat - consider them prototype hacks. Someone that
understands luxor should probably massage them into
something more consistent with the project architecture,
current practices and evolutionary goals.

>    - Gerald