First of all, thanks. I had almost judged the cafe to be unable to
discuss any UI issue except rendering backends.
Fraser Wilson
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.