[MacRuby-devel] 0.3 available for testing

[Richard Kilmer]

On Sep 8, 2008, at 8:26 PM, Joshua Ballanco wrote:

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

I don't think we will come with with a single 'convention' for GUIs  
across
different runtimes.  That is not my goal with HotCocoa.  My goal is to
make building Ruby OS X applications a simple as possible (like Ernest
had indicated).  Just as an example, Cocoa lacks layout management
instead it relies on springs/struts.  Swing has many different layout
managers.  We had to provide a layout management class in HotCocoa
and that is based on GTK's model of layout.  Different that Swing.  The
convention for wrapping them is going to be different.  Layout  
management
is a critical thing when you are producing UIs in code.  Anyway,  
that's just
one thing.

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

And I don't like GUI builders :-)  But that's OK!  You can use HotCocoa
with an application using IB (instantiating NSImage objects, etc) but  
the
controllers, etc will be created in Ruby just like now, you will not  
rely on
HotCocoa for that.

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