I forked the repo and fixed applied the fix here:
http://github.com/isaac/phare/commit/b6d78dd4d60b61ea5d7532fc6e43f7e72fdfa894
On Tue, Apr 21, 2009 at 7:25 AM, Matt Aimonetti <mattaimone...@gmail.com>wrote:
> I made some modifications and I probably broke some stuff. Sorry about
> that. Rich and I worked on a new super cool HotCocoa app's structure.
>
> It's not fully done yet but we'll work on it in 2 weeks at RailsConf.
>
> - Matt
>
>
> On Mon, Apr 20, 2009 at 8:39 AM, Emil Tin <e...@koblo.com> wrote:
>
>> cool!
>> i cloned the git repo, but when i do 'macrake' in the dir, it fails.
>>
>> ~/phare$ macrake
>> (in /Users/emiltin/phare)
>>
>> 2009-04-17 09:29:21.313 Phare[12075:613] registering AccountSetupView
>> 2009-04-17 09:29:21.440 Phare[12075:613] registering ProjectSelectionView
>> 2009-04-17 09:29:22.707 Phare[12075:613] registering WebView
>> 2009-04-17 09:29:23.492 Phare[12075:613] Loading Lighthouse Account
>> Settings
>> 2009-04-17 09:29:23.494 Phare[12075:613] available view classes:
>> [{:klass=>"AccountSetupView", :description=>"Lighthouse Account Settings"},
>> {:klass=>"ProjectSelectionView", :description=>"Project Selection"},
>> {:klass=>"WebView", :description=>"Lighthouse Help"}]
>> 2009-04-17 09:29:23.495 Phare[12075:613] looking for Lighthouse Account
>> Settings
>> 2009-04-17 09:29:23.496 Phare[12075:613] HotCocoa couldn't find a view
>> with a description defined as: '<Application: 0x8003c2d20>'
>> 2009-04-17 09:29:23.496 Phare[12075:613] stack trace:
>> ***
>> 2009-04-17 09:29:23.497 Phare[12075:613]
>> /Users/emiltin/phare/Phare.app/Contents/Resources/lib/vendor/mvc.rb:75:in
>> `display'
>> /Users/emiltin/phare/Phare.app/Contents/Resources/lib/application.rb:32:in
>> `block in start'
>> /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/hotcocoa/mappings/application.rb:9:in
>> `call'
>> /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/hotcocoa/mappings/application.rb:9:in
>> `handle_block'
>> /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/hotcocoa/mapper.rb:67:in
>> `block in map_method'
>> /Users/emiltin/phare/Phare.app/Contents/Resources/lib/application.rb:21:in
>> `start'
>> /Users/emiltin/phare/Phare.app/Contents/Resources/lib/vendor/mvc.rb:12:in
>> `initialize'
>> /Users/emiltin/phare/Phare.app/Contents/Resources/lib/application.rb:47:in
>> `new'
>> /Users/emiltin/phare/Phare.app/Contents/Resources/lib/application.rb:47:in
>> `<top (required)>'
>> /Users/emiltin/phare/Phare.app/Contents/Resources/rb_main.rb:2:in `load'
>> /Users/emiltin/phare/Phare.app/Contents/Resources/rb_main.rb:2:in `<main>'
>> 2009-04-17 09:29:23.498 Phare[12075:613]
>> ***
>> /Users/emiltin/phare/Phare.app/Contents/Resources/lib/vendor/mvc.rb:76:in
>> `display': undefined method `new' for nil:NilClass (NoMethodError)
>> from
>> /Users/emiltin/phare/Phare.app/Contents/Resources/lib/application.rb:32:in
>> `block in start'
>> from
>> /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/hotcocoa/mappings/application.rb:9:in
>> `call'
>> from
>> /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/hotcocoa/mappings/application.rb:9:in
>> `handle_block'
>> from
>> /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1/hotcocoa/mapper.rb:67:in
>> `block in map_method'
>> from
>> /Users/emiltin/phare/Phare.app/Contents/Resources/lib/application.rb:21:in
>> `start'
>> from
>> /Users/emiltin/phare/Phare.app/Contents/Resources/lib/vendor/mvc.rb:12:in
>> `initialize'
>> from
>> /Users/emiltin/phare/Phare.app/Contents/Resources/lib/application.rb:47:in
>> `new'
>> from
>> /Users/emiltin/phare/Phare.app/Contents/Resources/lib/application.rb:47:in
>> `<top (required)>'
>> from /Users/emiltin/phare/Phare.app/Contents/Resources/rb_main.rb:2:in
>> `load'
>> from /Users/emiltin/phare/Phare.app/Contents/Resources/rb_main.rb:2:in
>> `<main>'
>>
>>
>>
>>
>>
>> On 17/04/2009, at 02.07, Matt Aimonetti wrote:
>>
>> I recently worked on a proof of concept with HotCocoa. I wanted to see how
>> easy it would be to stay in pure Ruby and still use a MVC type approach.
>> I put together the beginning of a sample app to see how it would work in
>> real life: http://github.com/mattetti/phare/
>>
>> I first wanted to make sure to separate the controller code and the view
>> code. I also wanted to avoid use class variables to deal with my views.
>> There isn't much there but you can see how I organized the various parts
>> of my app:
>>
>>
>> http://github.com/mattetti/phare/tree/2d8d06ceefcfced5040bbe99fdea9b892a0db877/lib
>>
>> lib/controllers
>> lib/views
>> lib/vendor (string.rb extends String, logger.rb will eventually let you
>> log at different debugging levels, mvc.rb takes care of loading the various
>> files)
>>
>> Views just need to respond to render and have a description if you want to
>> use the segmented controller helper.
>>
>> Anyways, as I said there isn't much, it's lacking the entire testing part
>> of the app and the code could definitively be cleaned up/optimized.
>> I just want to know if that's something others are interested in, or if
>> you prefer to
>> 1. come up with your own solution every time
>> 2. don't bother with mvc
>> 3. use xcode/ib
>>
>> - Matt
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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
