Hello,
Welcome back to the Thinlet Titan Interview series.
Today let's welcome Dawid Weiss.
Q: Can you tell us a little bit about yourself?
Dawid Weiss: I work at the Laboratory of Intelligent
Decision Support Systems of Poznan University of
Technology, located in beautiful Poznan, Poland. My
primary research interests focus on search engines,
information retrieval and data mining, but since I
hold a masters degree in software engineering I am
also deeply involved in technology and all aspects of
programming technologies (desktop, internet,
middleware).
Q: How did you stumble onto Thinlet? Why do you choose
the Thinlet XML UI toolkit?
Dawid Weiss: Let me briefly introduce the system we
developed -- you will see we had very limited
choice...
MET2 (Medical Emergency Triage), which is developed at
the University of Ottawa by a joint team of Canadian
and Polish researchers, is the second attempt to
create a mobile, lightweight and distributed medical
triaging system for emergency rooms. Based on the
history of previous patients' symptoms, the system
predicts new patient's potential disposition,
hopefully reducing the time (and cost) of that
patient's stay at the hospital. It is, in a way, a
classic decision support system, but very specific
conditions encountered in a hospital make it a really
good (and tough) research subject.
Anyway, the assumption was that the system will be
"ubiquitous" -- a buzz word that translates to the
following requirements:
* the system should be available anywhere at any
moment of time (you must consider wireless networking
in other words)
* the system should run on constrained devices, if
full devices are not available (support for PDAs,
mobile phones, any computing devices)
* network presence is not guaranteed (thin client
is not enough)
* if full functionality of the system is not
possible on a given device due to its constrained
environment, the system should "downgrade" its
functionality to accomodate to it.
We also added another requirement that the system
should adjust the graphical user interface to support
the device in an ergonomic and efficient way.
Thinlet was in fact the only project that we knew of
that matched the above criteria.
MET2 was my first project with Thinlet. However, I
knew before that Andrzej Bialecki used Thinlet for
implementing Luke and knowing Andrzej's vast knowledge
of Java technology I felt confident Thinlet was a good
pick.
Q: What's the hook? Why would anyone use Thinlet over
say plain old Java AWT/Swing coding?
Dawid Weiss: I personally don't think it is a choice
based on preference of the developer. Rather, it
should be a choice driven by what you are trying to
achieve. In our project we could potentially use AWT
(on PocketPCs), but a few spike solutions we had
written clearly showed that AWT development on
PocketPCs will have an unpleasant look and feel and
will require much higher effort than using Thinlet.
Another advantage of using Thinlet was that we have
pretty much the same look and feel on PDA devices and
desktop PCs, regardless of the virtual machine --
operating system combination. This is very important
for non-techie users (such as physicians and nurses).
Q: Can you tell us some challenges you faced building
the medical triaging system using Thinlet?
Dawid Weiss: As usual: bugs and trying to find ways to
get around them. Just to name a few, we discovered a
bug (feature?) in Sun's JDK that demonstrates itself
when you try to invoke setSize() method on a frame
with no listeners on it. The sizing events are simply
not propagated to the frame's children. IBM is also no
exception: for example, their implementation of
InvocationEvent is not a subclass of ActiveEvent (as
it is documented in Sun's API). In other words: many
subtle details that cause your application to behave
differently depending on the VM and AWT
implementation.
Another interesting issue was to create and use a
custom AWT component in Thinlet (see the "clickable"
image component in Figure 2). This turned out to be
quite trivial with Thinlet... after we fixed a bug in
setComponent() method that had a typo in it.
Perhaps the most difficult issue was to design and
implement a library for synchronous (blocking) modal
dialog boxes, similar to JOptionPane known from Swing.
The problem with such blocking dialogs is that if you
invoke them from an AWT thread then your application
will freeze (you must "pump" events yourself then). On
the other hand, if you invoke them from a regular
thread, then you should wait for an event of the
dialog being closed and simply put the calling thread
to sleep. All this, plus apparent architectural
differences between Sun's and IBM's AWT were a hard
problem to beat. We extended Thinlet with a few lines
of code and blocking dialogs work like a charm no
matter what thread you display them from. We hope to
contribute this code back to the project in any
nearest occasion.
Q: Can you tell us more about how you use dynamic UIs
in the medical triaging system?
Dawid Weiss: The project we recently designed and
developed required that the application's GUI should
be created dynamically, depending on the environment
of execution.
We create patient's symptoms user interface in an
ontology defined using Protege ontology tool (see
Figure 1). The ontology allows us to conveniently
specify different layouts of screens (groups of
attributes) and editors (atomic components for
displaying and altering values of a single symptom),
depending on the profile the application runs in. All
GUI profiles are dynamically fetched from a central
ontology server and cached locally to allow running
the application when no network is present. Figure 2
and Figure 3a and Figure 3b present the same "GUI" on
a regular desktop PC and on a PDA -- PocketPC has a
small display, so its "screens" are rendered using
tabs, while regular desktop can show all the screens
at once. Similar "compacting" happens to attribute
editors which are rendered using popup windows on
PocketPC, but are inlined in the GUI on desktops.
It should be stressed that achieving dynamic layout of
the graphical components was a proverbial piece of
cake using Thinlet.
Q: Can you tell us some challenges you faced building
the medical triaging system using Thinlet?
Dawid Weiss: As usual: bugs and trying to find ways to
get around them. Just to name a few, we discovered a
bug (feature?) in Sun's JDK that demonstrates itself
when you try to invoke setSize() method on a frame
with no listeners on it. The sizing events are simply
not propagated to frame's children. IBM is also no
exception: for example, their implementation of
InvocationEvent is not a subclass of ActiveEvent (as
it is documented in SUN's API). In other words: many
subtle details that cause your application to behave
differently depending on the VM and AWT
implementation.
Another interesting issue was to create and use a
custom AWT component in Thinlet (see the "clickable"
image component in Figure 2). This turned out to be
quite trivial with Thinlet... after we fixed a bug in
setComponent() method that had a typo in it.
Perhaps the most difficult issue was to design and
implement a library for synchronous (blocking) modal
dialog boxes, similar to JOptionPane known from Swing.
The problem is with such blocking dialogs is that if
you invoke them from an AWT thread then your
application will freeze (you must "pump" events
yourself then). On the other hand, if you
invoke them from a regular thread, then you should
wait for an event of the dialog being closed and
simply put the calling thread to sleep. All this, plus
apparent architectural differences between SUN'a and
IBM's
AWT were a hard problem to beat. We extended Thinlet
with a few lines of code and blocking dialogs work
like a charm no matter what thread you display them
from. We hope to contribute this code back to the
project
in any nearest occasion.
Q: Can you tell us some challenges you faced using
Thinlet on IBM's J9 runtime?
Dawid Weiss: The virtual machine was not a big problem
-- the AWT was. Some interfaces have slightly
different signatures (nothing you will come across
unless you really try to do something advanced
though). We also
discovered that AWT on PocketPC has a very different
order of events in response to "clicking" using the
stylus. This initially cause Thinlet GUIs to be
completely inactive on PocketPCs. We submitted a patch
back to Thinlet that resolved this issue.
Another thing was the annoying "busy" cursor that was
showing up and remained on screen no matter what. We
investigated this issue for a long time, but with no
success. We know that setCursor() is invoked by
Thinlet with the predefined system's busy cursor, but
it is unclear why the original cursor is not restored.
We quite shamelessly implemented a workaround of
overriding setCursor() in Thinlet code and simply not
propagating the call to the AWT component if PocketPC
is detected. This workaround has no visual
side-effects because cursors are not shown on PocketPC
anyway (apart from the "busy" one), so it worked for
us.
Q: What's your take on adding styling support to
Thinlet? Have you tried out Eugene Klein's Skinlet
addon?
Dawid Weiss: We did not have the need for such
functionality, so it was not considered. I think such
extensions will inevitably make Thinlet's code grow
and this is not a good direction if you want to keep
the project running on constrained devices. If I
really needed fully skinned user interface, I'd rather
write a parser that would translate Thinlet's XML into
Swing components and use JGoodies or some other look
and feel for Swing. I know, blasphemous thoughts these
are, but this is what I think makes more sense than
packing styling support into the Thinlet code.
Q: Do you have a favorite scripting language for the
Java runtime? Do you want to see scripting pushed
more
in Thinlet or do you want to keep the code Java only?
Have you tried out Norbert Barbosa's Scriptable
Thinlet addon?
Dawid Weiss: I have always favored Pat Niemeyer's
BeanShell -- there is my article on JavaWorld that
does some neat tricks with BeanShell and ANT if you
care
to look
(http://www.javaworld.com/javaworld/jw-10-2003/jw-1003-beanshell.html).
As for integrating scripting into the Thinlet core my
opinion is similar to the one I have about styling:
keep the project simple. Scripts are neat but I think
support for them in Thinlet would not bring any
reasonable additional value to the project (apart from
saying: we have scripting support). Scripting
languages recently can produce real Java objects
anyway (Ruby, BeanShell), so if you really want to
keep some code in a script, you still can achieve it
-- load the script, make it a Java object and pass
this object to Thinlet's parse() method as the handler
for method invocations.
Q: What's your take on creating an OO wrapper for
Thinlet?
Dawid Weiss: I have mixed feelings. An OO wrapper is
itself good -- makes understanding the code much
easier. On the other hand, I like the express way of
creating new components by name, or setting their
properties in a similar way. People say they like OO
very much, but they also love those loose-syntax
scripting languages... go figure.
Q: What do you think is still missing badly in
Thinlet?
Dawid Weiss: Some more examples would be nice.
Documentation could also get updated from time to
time. But in general, I'm very happy with the project
even
at the current state.
Q: Do you have any future plans for Thinlet?
Dawid Weiss: Absolutely. I will integrate it into my
lectures about creating user interface and I look
forward to using it in the future.
Thanks Dawid for the interview.
- Gerald
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
xul-announce mailing list
xul-announce@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xul-announce
