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

[Peter Verswyvelen]

Well, that is also the idea behind Microsoft's WPF/XAML: they provide a
declarative approach to describe the widget tree (specifying what it is, not
what is does), and a GUI toolkit (Expression Blend) for artists and
designers so they can use a high level tool to build the GUI. You can even
define limited behavior and animation in a declarative way.
However, I believe those "designer friendly" tools are not designed by
designers but by programmers who claim to think what designers want. I work
everyday with artists and designers, and these people are frustrated by the
limitations and erratic behavior (read "side effects") of most "designer
friendly" tools... Furthermore making even a simple GUI requires a lot of
collaboration between the developer and the designer, and this screams for a
language that both can understand and reason about :-)

Also, this approach is nice for "simple" or (should I say mostly form-based
GUIs), but as soon as you get into something more complicated, this design
won't help you. For example, try to make a mathematical editor like that...
or a diagram editor...

IMO any GUI framework should work for complicated GUIs as well as easy form
based one. I feel the model -> presentation -> view -> reactivity -> model'
cycle is still the best approach today for building complex GUIs. Never
start with widgets, these are just a possible representation of a model.
Although this paradigm comes from Smalltalk, MVC is really functional in my
opinion.. If you make that approach compositional *and* fast, you have a
winner.  Something like FRUIT on steroids (Grapefruit? ;-) but then of
course you are stuck with the arrows syntax which feels like drawing
graphical circuits with a text editor ;-)

2009/2/2 John A. De Goes <john at n-brain.net>

>
> The size, color, and layout of widgets has no effect on interaction
> semantics and is best pushed elsewhere, into a designer-friendly realm such
> as CSS.
>
> 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 2:15 PM, Conal Elliott wrote:
>
> Could CSS give us semantic clarity?  - Conal
>
> On Mon, Feb 2, 2009 at 11:58 AM, 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
>>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/6efecb5d/attachment.htm