This paper focuses on the techniques involved in building an interactive application using a plastic user interface. These techniques take advantage of the QTk toolkit, a toolkit that features unusual but interesting concepts with respect to more classical object-oriented toolkits. These features are possible thanks to the underlying programming language used, Oz. In particular, it can support all facilities provided by symbolic records like XML structures and more than that. It also exhibits the capacity to wrap any languages entities into higher order data structures. This paper shows by a case study how the combination of QTk and Oz helps developers write plastic user interface very easily.

1. Université catholique de Louvain (UCL)
Louvain Interaction Laboratory (LiLab)
Place des Doyens, 1
B-1348 Louvain-la-Neuve (Belgium)
FlexClock, a Plastic Clock Written
in Oz with the QTk toolkit
by
Donatien Grolaux, Peter Van Roy, &
Jean Vanderdonckt
Department of Computing Science and Engineering

2. What interface builders can do
 Difference between « what application
needs » and « what interface builder
offer »

3. Code generators
 From declarative specifications
– « What » instead of « how to ».
– Limited to UI known before the execution of
the application.
– Artificial gate between declaration part and
imperative part

4. QTk approach
 Mixing declarative and imperative approaches
inside the same programming language :
– User can choose between « what » and « how to » :
– Where QTk offers a declarative support, e.g. at GUI
construction.
– As they see best fit their purpose.
 Programming language requirement :
– Inline declarations of arbitrary parameters ⇒
symbolic data structure with a dictionary structure
(key → value)

5. Mozart
 Oz records :
label(feature1:value1 … featureX:valueX)
 Full language support :
– Label extraction/replacement
– Add/remove/replace one/many feature(s)
– Iteration on features
– Transformation into/from list
– …
 Good candidates for declarative specifications
of GUIs

6. QTk example (1)
td(lr(label(text:"Enter your name") entry(handle:E))
button(text:"Ok" action:Ok))
...
{E set(text:"Type here")}
...
Result={E get(text:$)}

7. QTk example (2)
placeholder(handle:P)
…
{P set(label(text:"Hello"))}
…
{P set(label(text:“World"))}

8. FlexClock
 What’s FlexClock?
 Information needed to define a view :
– UI construction declaration
– Update procedure
– Size information
 17 views = 60 declarative lines + 40 imperative lines
 View specification code sample :
r(desc: label(handle:H1 glue:nswe bg:white)
refresh: proc{$ T} {H1 set(text:{FmtTime T})} end
area: 40#10)

9. FlexClock: different views

10. FlexClock: calendar widget
 UI declared using Oz's natural data structures : records and lists ⇒
complete language support for creation/manipulation at runtime.
lr(label(text:"Mo") label(text:"Tu") ... label(text:"Su")
newline
lrline(glue:we) lrline(glue:we) ... lrline(glue:we)
newline
empty label(text: "1") ... label(text: "6")
newline
label(bg:black fg:white text:"7") ... label(text:"13")
newline
label(text:"14") label(text:"15") ... label(text:"20")
newline
label(text:"21") label(text:"22") ... label(text:"27")
newline
label(text:"28") label(text:"29") label(text:"30"))

11. Definition of view

12. Software Probe for Plasticity (G. Calvary)

13. Probe
 Initial purpose:
software
mechanism that is
responsible to
detect any change
of the context of
use
 FlexClock:
– No probe into the
functional core
– Event generated
proc{Place}
when size changes
WW={QTk.wInfo width(P)}
WH={QTk.wInfo height(P)}
_#Handle={List.foldRInd Views
fun{$ I W#H#Handle Max#CH}
This=(W-WW)*(W-WW)+(H-WH)*(H-WH)
in
if W<WW andthen H<WH andthen
(Max==inf orelse This<Max)
then
This#Handle
else
Max#CH
end
end
inf#local (_#_#H)|_=Views in H end}
in
{P set(Handle)}
end
{P bind(event:'<Configure>'
action:Place)}

14. Plasticity domain
 Initial definition
 FlexClock

15. Current and Next Contexts
 Initial definition: they respectively
capture the current context of use and
the one that will be produced after some
detection of a change
 FlexClock:
– No current context
– Next context: is directly computed, but not
stored

16. Selection rules
 Initial definition: reaction to a change of
context, selecting the most appropriate
– Prologue
– Reaction
– Epilogue
 FlexClock:
– No prologue
– Computation of a new layout resulting from the
change of window size
– No epilogue

17. Calculation of the reaction

18. Calculation of the reaction
proc{Place}
WW={QTk.wInfo width(P)}
WH={QTk.wInfo height(P)}
_#Handle={List.foldRInd Views
fun{$ I W#H#Handle Max#CH}
This=(W-WW)*(W-WW)+(H-WH)*(H-WH)
in
if W<WW andthen H<WH andthen
(Max==inf orelse This<Max)
then
This#Handle
else
Max#CH
end
end
inf#local (_#_#H)|_=Views in H end}
in
{P set(Handle)}
end
{P bind(event:'<Configure>'
action:Place)}
Returns the handle of the
New layout
Selection rule
Code which changes
The new layout

19. History mechanism
 Initial definition: it records context
transitions along with their migration
costs as the user runs the system
 FlexClock: none

20. Conclusion
 FlexClock is
– Plastic
– Multi-platform
– Generated at run-time
– Uses the software probe