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
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
