Chronicle of the Xul Revolution
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:
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?
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
InvocationEvent is not a subclass of
(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
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
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
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.
Thanks Dawid Weiss. Check back next week for the second part of the Thinlet XUL Titan interview with Dawid discussing Thinlet running on IBM's J9, scripting choices for Thinlet, styling using Skinlet and much much more.
|Please send comments on our web pages to our public xul-talk mailinglist or to a member of our web team.||Copyright © 2003, 2004, 2005 Open XUL Alliance|