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

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

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 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 :

...

...

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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe