[MacRuby-devel] 0.3 available for testing

[Joshua Ballanco]

On Sep 8, 2008, at 8:01 PM, Ernest N. Prabhakar, Ph.D. wrote:

> 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 is really what I meant. If Shoes is going to exist anyway, an  
implementation on top of HotCocoa would be (clearly) to Shoes'  
benefit. The reverse is also, at least partly, true. Implementing the  
abstractions present in Shoes would require HotCocoa to be fairly  
complete. My thinking was to look at implementing Shoes on top of  
HotCocoa as a good way to figure out what work remains for HotCocoa. I  
don't ever foresee, though, Shoes supplanting or removing the need for  
HotCocoa.

On a related note, I think that concerns like Richard mentioned with  
(ab)use of instance_eval are pertinent. Like Charles was commenting,  
maybe there should be an agreed on convention of what a Ruby GUI  
library should look like?

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

This is actually a point I'm a bit uncertain on. I feel like HotCocoa  
should focus on making app creation through Xcode and IB as simple as  
possible. I'm not so convinced that the focus should be on in-code GUI  
creation. Maybe it's just me, but I feel like the web block/inline  
design paradigm is more suited to in-code GUI creation. I've created  
Java GUIs and attempted GUI creation in Cocoa, but each time I return  
to the GUI builders.

Of course, it occurs to me that I may be missing the point of  
HotCocoa. A question for Richard or Laurent: If I used HotCocoa to  
create a controller class, could I still design my view in IB? (Seems  
like the answer should be yes...)

-Josh

>> 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
>
> _______________________________________________
> MacRuby-devel mailing list
> MacRuby-devel at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel