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.

--
        Mark



_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Reply via email to