[MacRuby-devel] 0.3 available for testing

[Ernest N. Prabhakar, Ph.D.]

Hi Laurent,

On Sep 8, 2008, at 4:46 PM, Laurent Sansonetti wrote:
> While shoes could indeed be re-implemented on HotCocoa (or even JRuby
> + your toolkit library of your choice), I wonder if it's really
> meaningful.

 From a *Shoes* perpsective, it might be nice to run Shoes apps on  
HotCocoa.

> This would be a nice project indeed, but at the end, what would be the
> advantage of using Shoes over HotCocoa? Shoes is very minimalist as
> you said, but HotCocoa is already very simple to use (and will be even
> simpler over time).

For HotCocoa, I presume the goal would be to make app construction as  
simple as it is in Shoes, even if the syntax isn't identical.

--enp

>
>
> Laurent
>
> On Sep 8, 2008, at 4:27 PM, Ernest N. Prabhakar, Ph.D. wrote:
>
>> Hi Charles,
>>
>> Have you looked at Shoes lately?
>>
>> http://shoooes.net/tutorial/
>>
>> It is very minimalist, and I think it would be straightforward to  
>> port
>> over to HotCocoa.
>>
>> I second the idea that HotCocoa should use Shoes as a role model,  
>> even
>> if it goes well beyond it.
>>
>> -- Ernie P.
>>
>> On Sep 8, 2008, at 4:08 PM, Charles Oliver Nutter wrote:
>>
>>> Joshua Ballanco wrote:
>>>> Call it the Shoes challenge. I've started looking at doing  
>>>> something
>>>> like this primarily to figure out where HotCocoa needs the most
>>>> work/
>>>> focused attention. Originally I was thinking that Shoes could, some
>>>> day, be a subset of HotCocoa, but I've changed my mind. I think
>>>> HotCocoa should do it's best to encapsulate the full range of  
>>>> what's
>>>> possible with Cocoa, and Shoes should stay a tiny-toolkit that  
>>>> makes
>>>> GUI development easy.
>>>
>>> I've mostly given up on the idea of anyone ever creating a usable  
>>> API
>>> wrapper that works seamlessly across toolkits and platforms without
>>> totally sucking. UI APIs seem to be one of those areas impossible to
>>> wrap in a backend-agnostic API without a hell of a lot of hassle.  
>>> See
>>> SWT, which does a great job, looks mostly consistent, and yet has
>>> constant portability problems and has taken dozens of man-years to
>>> implement. Not worth it IMHO.
>>>
>>> What I would see as a better value is creating API wrappers that are
>>> comprehensive, clean, ruby-like, and trying to cooperate on some
>>> vague
>>> standards how what UI design/development in Ruby is supposed to look
>>> like. Doing all that would mean a few things to me:
>>>
>>> - The APIs individually would be small enough that if someone *did*
>>> want
>>> to maintain multiple backends/platforms it would not be a big deal.
>>> - Each API would be true to its backend, hiding nothing a user would
>>> eventually need access to.
>>> - The general "feel" of these APIs would be consistent across
>>> backends,
>>> even if developed independently, and so the general community
>>> benefits
>>> from a bit more consistency in how these different classes of UI  
>>> APIs
>>> look and behave.
>>>
>>> - Charlie
>>> _______________________________________________
>>> MacRuby-devel mailing list
>>> MacRuby-devel at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>> _______________________________________________
>> MacRuby-devel mailing list
>> MacRuby-devel at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel