Re: [MacRuby-devel] HotCocoa futures
Hi Rich, Thanks for starting a new thread - I was just getting ready to pollute the future of MacRuby thread with some more HotCocoa talk :) Jordan: "The goal of the project is to simplify the process of creating and configuring Cocoa objects used when building native Mac apps" https://github.com/HotCocoa/hotcocoa/blob/master/README.markdown We should probably do a better job of explaining what this means in more detail - I have opened an issue for this here: https://github.com/HotCocoa/hotcocoa/issues/44 Writing more concise code is great, but I wouldn't say it is my primary motivation, here are some other reasons why I use HotCocoa: * It helps you to write clearer and more idiomatic MacRuby code * Express your UI in code rather than IB * Makes it easier to use Xcode alternatives like TextMate * Helps you to package your code * Provides a basic structure for your project Cheers, Isaac On Sat, Dec 24, 2011 at 9:25 AM, Rich Morin <rdm@cfcl.com> wrote:
At 7:29 PM +0100 12/23/11, Jordan K. Hubbard wrote:
On Dec 23, 2011, at 2:47 AM, isaac kearse wrote:
Are you aware that HotCocoa is being actively developed again?
https://github.com/HotCocoa/hotcocoa/blob/master/History.markdown
That's good to know. It would also be good to know, if and when the subject ever comes up, what its mission statement currently is. Front-end all of AppKit? All of AppKit AND Foundation? Neither of those, but provide convenience functions if and only when a certain conciseness (as expressed in percentage of code saved) is achievable? This is something I have been wondering ever since Rich started the project, since it definitely achieves an admirable degree of brevity over the equivalent ObjC code, but where do you stop? How will we know when HotCocoa is "done"? :-)
I'm not all that worried about whether HotCocoa is ever "done", but I do think there are some interesting questions about how additions should be managed. As Jordan suggests, there could be rules for accepting additions, eg:
... if and only when a certain conciseness (as expressed in percentage of code saved) is achievable ...
Details aside, it can be good to know what kinds of things are likely to be accepted (or rejected) without much discussion. That said, I would like HotCocoa to be a continuing dialogue for ways to make MacRuby code clearer and more idiomatic.
I think that "code forums" such as GitHub are extremely well suited to this sort of dialogue. If I want to try out a new idiom or feature, I can simply fork the project and hack. If my work shows promise, I can push it back to GitHub and make an announcement.
The trickier question is how to get reliable infrastructure out of such a dialogue. The traditional approach involves a cabal of "core committers", but Git and GitHub projects are not required to be organized in this fashion.
In any case, I'm not particularly worried. If we have robust participation in HotCocoa use and development, the details can and will be worked out.
-r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841
Software system design, development, and documentation _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Hi guys, I think Isaac already answered things fairly well, but I still thought I would throw in my two cents. HotCocoa will be done when Cocoa is dead. Even then, I'm sure there will still be things to do. The "goal" of HotCocoa, as I see it, is to make Cocoa apps easier to develop and maintain using MacRuby. The problem here is that that is an extremely broad goal. Everything that Isaac listed is currently aided by HotCocoa by using different components of the project. Some of the components, like the mappings and delegate builder, were designed together and work together nicely; while components like the application builder are completely separate and could become a separate project under the HotCocoa banner in the future. Similarly, the fork of macruby_graphics that exists in the HotCocoa (as `hotcocoa/graphics`) should also become a subproject of HotCocoa in a different repository and released as its own gem. "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. However, HotCocoa can't do everything for everyone with the amount of resources it has now. Personally I will be focusing on updating and strengthening the existing components. I haven't been able to give HotCocoa the love it deserves in the last few months as I was busy with school. That being said, I'm not the only person working on HotCocoa, and the project has been moving ahead thanks to other contributors. I won't be in school for the next few months, so I'll have more time for HotCocoa again. We have plans to improve documentation and promote the project in the next year, and hopefully that will help answer these questions in better detail. HTH, Mark Rada On 2011-12-23, at 4:21 PM, isaac kearse wrote:
Hi Rich,
Thanks for starting a new thread - I was just getting ready to pollute the future of MacRuby thread with some more HotCocoa talk :)
Jordan:
"The goal of the project is to simplify the process of creating and configuring Cocoa objects used when building native Mac apps" https://github.com/HotCocoa/hotcocoa/blob/master/README.markdown
We should probably do a better job of explaining what this means in more detail - I have opened an issue for this here: https://github.com/HotCocoa/hotcocoa/issues/44
Writing more concise code is great, but I wouldn't say it is my primary motivation, here are some other reasons why I use HotCocoa:
* It helps you to write clearer and more idiomatic MacRuby code * Express your UI in code rather than IB * Makes it easier to use Xcode alternatives like TextMate * Helps you to package your code * Provides a basic structure for your project
Cheers, Isaac
On Sat, Dec 24, 2011 at 9:25 AM, Rich Morin <rdm@cfcl.com> wrote:
At 7:29 PM +0100 12/23/11, Jordan K. Hubbard wrote:
On Dec 23, 2011, at 2:47 AM, isaac kearse wrote:
Are you aware that HotCocoa is being actively developed again?
https://github.com/HotCocoa/hotcocoa/blob/master/History.markdown
That's good to know. It would also be good to know, if and when the subject ever comes up, what its mission statement currently is. Front-end all of AppKit? All of AppKit AND Foundation? Neither of those, but provide convenience functions if and only when a certain conciseness (as expressed in percentage of code saved) is achievable? This is something I have been wondering ever since Rich started the project, since it definitely achieves an admirable degree of brevity over the equivalent ObjC code, but where do you stop? How will we know when HotCocoa is "done"? :-)
I'm not all that worried about whether HotCocoa is ever "done", but I do think there are some interesting questions about how additions should be managed. As Jordan suggests, there could be rules for accepting additions, eg:
... if and only when a certain conciseness (as expressed in percentage of code saved) is achievable ...
Details aside, it can be good to know what kinds of things are likely to be accepted (or rejected) without much discussion. That said, I would like HotCocoa to be a continuing dialogue for ways to make MacRuby code clearer and more idiomatic.
I think that "code forums" such as GitHub are extremely well suited to this sort of dialogue. If I want to try out a new idiom or feature, I can simply fork the project and hack. If my work shows promise, I can push it back to GitHub and make an announcement.
The trickier question is how to get reliable infrastructure out of such a dialogue. The traditional approach involves a cabal of "core committers", but Git and GitHub projects are not required to be organized in this fashion.
In any case, I'm not particularly worried. If we have robust participation in HotCocoa use and development, the details can and will be worked out.
-r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841
Software system design, development, and documentation _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
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. - Jordan
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
participants (3)
-
isaac kearse
-
Jordan K. Hubbard
-
Mark Rada