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. <div>
<div><br></div><div><div>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 :-)</div>
<div><br></div><div><div></div></div></div><div>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... </div>
<div><br></div><div>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 ;-)</div>
<div><br></div><div><div><div><div><div><div class="gmail_quote">2009/2/2 John A. De Goes <span dir="ltr"><<a href="mailto:john@n-brain.net">john@n-brain.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><br></div><div>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.</div><div class="Ih2E3d">
<br><div> <span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">
<span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">
<span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">
<span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">
<div><div>Regards,</div><div><br></div><div>John A. De Goes</div><div>N-BRAIN, Inc.</div><div>The Evolution of Collaboration</div><div><br></div><div><a href="http://www.n-brain.net" target="_blank">http://www.n-brain.net</a> | 877-376-2724 x 101</div>
</div></div></span></div></span></div></span></div></span> </div><br></div><div><div></div><div class="Wj3C7c"><div><div>On Feb 2, 2009, at 2:15 PM, Conal Elliott wrote:</div><br><blockquote type="cite">Could CSS give us semantic clarity? - Conal<br>
<br><div class="gmail_quote">On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes <span dir="ltr"><<a href="mailto:john@n-brain.net" target="_blank">john@n-brain.net</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<br> 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.<br> <br> Regards,<br> <br>
John A. De Goes<br> N-BRAIN, Inc.<br> The Evolution of Collaboration<br> <br> <a href="http://www.n-brain.net" target="_blank">http://www.n-brain.net</a> | 877-376-2724 x 101<div><div></div><div><br> <br> On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote:<br>
<br> </div></div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div><div></div><div> 2009/1/29 Conal Elliott <<a href="mailto:conal@conal.net" target="_blank">conal@conal.net</a>>:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"> Hi Achim,<br> <br> I came to the same conclusion: I want to sweep aside these OO, imperative<br>
toolkits, and replace them with something "genuinely functional", which for<br> me means having a precise & simple compositional (denotational) semantics.<br> Something meaningful, formally tractable, and powefully compositional from<br>
the ground up. As long as we build on complex legacy libraries (Gtk,<br> wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet,<br> drawn into) their ad hoc mental models and system designs.<br>
<br> As Meister Eckhart said, "Only the hand that erases can write the true<br> thing."<br> </blockquote> <br> I think working on a purely functional widget toolkit would actually<br> be a really cool project. Do you have any ideas, though, on what<br>
should be the underlying primitives?<br> <br> The initial gut feeling I have is that one should just ignore any<br> notion of actually displaying widgets & instead focus on a clean<br> algebra of how to 'add' widgets that relates the concepts of<br>
inheritance & relative position. What I mean by inheritance, here, is<br> how to direct a flow of 'events'. I don't necessarily mean events in<br> the Reactive sense, because I think it'd be important to make the<br>
model completely independent of how time & actual UI actions are<br> handled.<br> <br> Any thoughts to throw in, here?<br> <br> Cheers,<br> C<br></div></div><div> _______________________________________________<br> Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></blockquote><div><div></div><div> <br> _______________________________________________<br> Haskell-Cafe mailing list<br> <a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></blockquote></div><br></div></div></div><br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div></div></div></div></div></div>