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

[John A. De Goes]

How do you define "layout" in a way that has a "direct an enormous  
effect on interaction semantics"???

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 4:31 PM, Conal Elliott wrote:

> Hi John,
>
> I'm not sure how to interpret your remarks about "has no effect" and  
> "is best".  I guess they're subjective opinions, but maybe I'm  
> missing something objective in your intent.  I can see, for  
> instance, at least one way in which layout has a direct and enormous  
> effect on interaction semantics.  And while I can see some benefits  
> in choosing CSS, I also see some significant drawbacks, and I wonder  
> if you've factored these drawbacks into your "is best".
>
>   - Conal
>
> 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/fe713366/attachment.htm