[Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense

[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.

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).

For example, you need a changed flag in the state of the text editor.  This
is updated by a signal from the text widget, and read by the main window
(because it affects the title bar text), the File/New and File/Open menu
items (need to put up a "Save Changes?" message box) and the main window
destroy handler (same thing, but it also needs some way of cancelling the
action).  Unfortunately, the main window is at one end of the event chain,
while the menu is all the way over on the other side.  This leads to tricky
composition, and widgets which pass the entire state to each other because
there's one little bit of information they might need.

A related issue is that the application is like a river, in which events
flow from one end to the other.  Send events back the other way is ugly.
Some sort of blackboard design might work better.

This conversation made me start thinking about replacing Glade with a
Haskell layout language, but I still don't know how to solve the above
problems.  I should read the FRP papers again.

cheers,
Fraser.

[1] http://thewhitelion.org/darcs/barrie

On Mon, Feb 2, 2009 at 8:58 PM, John A. De Goes <john at n-brain.net> wrote:

>
> The actual presentation and layout of widgets would be better handled by a
> DSL such as CSS (which is, in fact, declarative in nature), while event
> logic would be best handled purely in Haskell.
>
> Regards,
>
> John A. De Goes
> N-BRAIN, Inc.
> The Evolution of Collaboration
>
> http://www.n-brain.net    |    877-376-2724 x 101
>
>
> On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote:
>
>  2009/1/29 Conal Elliott <conal at conal.net>:
>>
>>> Hi Achim,
>>>
>>> I came to the same conclusion: I want to sweep aside these OO, imperative
>>> toolkits, and replace them with something "genuinely functional", which
>>> for
>>> me means having a precise & simple compositional (denotational)
>>> semantics.
>>> Something meaningful, formally tractable, and powefully compositional
>>> from
>>> the ground up.  As long as we build on complex legacy libraries (Gtk,
>>> wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse
>>> yet,
>>> drawn into) their ad hoc mental models and system designs.
>>>
>>> As Meister Eckhart said, "Only the hand that erases can write the true
>>> thing."
>>>
>>
>> I think working on a purely functional widget toolkit would actually
>> be a really cool project.  Do you have any ideas, though, on what
>> should be the underlying primitives?
>>
>> The initial gut feeling I have is that one should just ignore any
>> notion of actually displaying widgets & instead focus on a clean
>> algebra of how to 'add'  widgets that relates the concepts of
>> inheritance & relative position.  What I mean by inheritance, here, is
>> how to direct a flow of 'events'.  I don't necessarily mean events in
>> the Reactive sense, because I think it'd be important to make the
>> model completely independent of how time & actual UI actions are
>> handled.
>>
>> Any thoughts to throw in, here?
>>
>> Cheers,
>> C
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
http://thewhitelion.org/mysister
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/86abaf14/attachment-0001.htm