[MacRuby-devel] HotCocoa futures

Mark Rada mrada at marketcircle.com
Mon Dec 26 11:55:38 PST 2011

On 2011-12-24, at 5:00 AM, Jordan K. Hubbard wrote:

> On Dec 24, 2011, at 5:01 AM, Mark Rada wrote:
>> 	"Do we want to front end all the AppKit classes?" No, not unless it can be justified, and I don't think it can. Also, while AppKit may have been the original motivation for mappings, any class in any framework can have a mapping added. Mappings are justified if they make using the class flow more nicely/succinctly with the rest of the code you write, or if it advantageous to get a feature like block based delegation. Even if a mapping would not be useful in general, you can still write it and load mappings yourself.
>> 	"...provide convenience functions if and only when a certain conciseness (as expressed in percentage of code saved) is achievable?" This is similar to what I said above, except it gives a specific heuristic, percentage of code saved, which I think is not quite accurate. It is about making things easier to code/understand/maintain, which isn't always the smallest amount of code. For instance, masking in HotCocoa is just an array of symbols which I think is a bit more verbose looking than a chain of XOR'd constants; though since the symbols don't include the Cocoa prefix (i.e. NSAnnoyingPrefix) it ends up looking shorter than the equivalent Objective-C code.
> That seems like a pretty reasonable mission statement to me - thanks for the thoughtful elaboration.  "Make Cocoa programming Ruby-ish", in a nutshell?
> If that's the case, I think it might be reasonable to suggest that HotCocoa should not be positioned against Interface Builder so much as offered as an alternative for certain types of applications with UI.  Microsoft's XAML, for example, allows for extremely concise interfaces to be constructed (as well as describing some of the more simple runtime behaviors) without necessarily saying that it is a replacement for C#.  To be sure, this (from an online XAML tutorial):
> <StackPanel>
>     <TextBlock Margin="20">Welcome to the World of XAML</TextBlock>
>     <Button Margin="10" HorizontalAlignment="Right">OK</Button>
> </StackPanel>
> Is far more concise than this:
> // Create the StackPanel
> StackPanel stackPanel = new StackPanel();
> this.Content = stackPanel;
> // Create the TextBlock
> TextBlock textBlock = new TextBlock();
> textBlock.Margin = new Thickness(10);
> textBlock.Text = "Welcome to the World of XAML";
> stackPanel.Children.Add(textBlock);
> // Create the Button
> Button button = new Button();
> button.Margin= new Thickness(20);
> button.Content = "OK";
> stackPanel.Children.Add(button);
> But I can also see a number of situations where a serialized object (XIB) file is even more "concise" given that it encapsulates all of the UI in one easy-to-update file, with a nice graphical tool for doing so, in which case it's really the code which interacts with that interface that needs to be "Rubyish" and easy to write.

> In short, I think Interface Builder actually fits within the HotCocoa mission statement for its easy creation and maintenance of interfaces beyond a certain (fairly minimal) amount of complexity.  That leaves the "minimal interfaces" and UI snippets / compound UI elements as one natural fit for HotCocoa, along with other mappings which reduce the complexity of doing audio, video and animation, perhaps?   I'm just thinking out loud here, but I would be curious to know if this is how others see it.

I see what you mean. HotCocoa can be used in conjunction with IB. The application builder supports this, and in the examples directory the "round_transparent_window" example uses a nib. It is possible to mix HotCocoa and nibs; for instance, you could create a button using the HotCocoa constructor and put it in a window created from a nib.

I don't see IB as a competitor, but I do sometimes look at Xcode for ideas how to make HotCocoa better.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macruby-devel/attachments/20111226/ae60d82c/attachment.html>

More information about the MacRuby-devel mailing list