[Haskell-cafe] GUI semantics [was: Achim ranting]

[Achim Schneider]

First of all, thanks. I had almost judged the cafe to be unable to
discuss any UI issue except rendering backends.

Fraser Wilson <blancolioni at gmail.com> wrote:

> You know, I read the Fudgets thesis, and threw together an experiment
> which used Glade for layout and Haskell for semantics [1].  As
> somebody else noted, this isn't really a clean division, because of
> things like editable flags in the layout.  The darcs repository has a
> couple of demo applications, there's also a Bridge game that doesn't
> quite work (not included), and I understand that Arrows would solve
> all my problems, but I still don't grok them, alas.
> 
It depends on what you may flag as editable. I just re-watched Conal's
techtalk about TV's, which short-circuited a few neurons that were held
apart by things like Functors and the ilk: Flagging an input as
editable or not is OK, flagging an output is not (duh). 

In retrospect, TV's appear to me as being too denotationalistic[1]: From
what I can tell, the way a String is displayed is _solely_ controlled
by the run* functions. In a line-oriented text environment there's only
one way, so it doesn't matter, but in a GUI, you might want to display
it either as a label, or as an input-disabled textbox (so the user can
copy the string). It might also be the text of a button, or the label
of a node edge in a graph editor. Reactive gives us a way to describe
the String (and other things) as a function of time, now we need to
figure out how to describe the rest of its properties: A thing is not
only defined by its inherent properties, but also by its interaction
with the rest of the world. A hungry cat next to a mouse behaves
different from a hungry cat next to a stone; how can we make a String
aware of being the input of a label vs. being the input of a textbox,
without shoving all knowledge of interaction into the world itself? Can
we avoid specifying "into textbox" or "into label" (or "in 14.5pt
slanted Helvetica") if we don't care or the rendering backend just
doesn't support it? Can we specify a new renderer that knows about a
new attribute, and enrich our model with that attribute without
changing the whole core?

> What I found was that wiring the events through the application in a
> nice, functional way was quite tricky, but it was unclear whether
> this was just an API problem, or something more fundamental.  The
> entire state seems to turn up in every connection between widgets
> (which really suggests that it's imperative with a veneer of
> declarative style, which of course it is).
> 
I've also noticed this. Right now, my code would thread one event
stream through everything, splitting and rejoining as necessary, but
always uni-directional and staying one stream[2]. If I wanted feedback
(I do, but haven't actually implemented it), I'd send an event down the
stream, collect it at the end, and sink it back into the beginning
(via IO, that is, threads and mvars). I bet there's a way to define
fixpoints on event streams so that feedback does not have to take a full
round-trip, and, most importantly, can flow on more paths than one, and
I'm absolutely positive that it would break my current model (which,
most likely, would be a good thing to do).

I'm also not using Behaviours at all, which annoys me: I'd say
"textbox, change the string of that label if you're changed", not
"label, you form a Widget behaviour influenced by the string output
of that Widget over there (which happens to be a textbox)". 

I guess that once I understand what fixpoints mean in this context,
stuff will clear up a lot.

 
[1] TM.
[2] It is modelled as a tuple of two streams of different type, one
    getting drained by handling functions, the other filled.

-- 
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance and/or quoting of this signature prohibited.