Laurent Sansonetti
lsans****@apple*****
Thu Jan 25 21:33:37 JST 2007
Hi Hisa-san,
Your proposal is OK to me (I enjoy the block syntax :)).
Just one though. I think that ib_action should accept 2 different
usages.
First,
ib_action :buttonPressed { |sender| ... }
Second,
ib_action :buttonPressed
# Assuming #buttonPressed is defined elsewhere
My concern is that people already wrote RubyCocoa code (and so, IB
actions as Ruby methods), and would like to port their code without re-
writing the IB actions with the block syntax (so, just adding
ib_action :myMethod after each method).
So, the 2 usages would be possible.
Thoughts?
Laurent
On Jan 25, 2007, at 7:44 AM, Fujimoto Hisa wrote:
> sorry it outside topic for ib_action and the generator.
> addtional thinking about objc_method like that:
>
> class MyController < OSX::NSObject
> ib_outlets :textField
>
> objc_method(:foo_bar_baz, %w(void id id id)) do |foo,bar,baz|
> ...
> end
>
> ib_action :buttonPressed do |sender|
> ...
> end
> end
>
> for this:
>
> module Objcwrapper
> def objc_method(name, form, &blk)
> if block_given?
> define_method(name, blk)
> end
> ... here already implemented ...
> end
> end
>
> these should be optional syntax sugar.
> # i don't want to write much objc_method form ;).
>
> do you think about this?
>
> --
> hisa
>
>
> On 2007/01/25, at 15:28, Fujimoto Hisa wrote:
>
>> Hi Guys!
>>
>> Thanks to Chris, excellent the suggestion also the implementation!
>> it's important already it works or not :)
>>
>> Maybe I can agree your suggestion for generation classes.nib idea.
>> But
>> currently, I care a bit what ib_action seems required for just
>> generating/managing a classes.nib file only. It's not required at
>> runtime in fact. Please give me a bit time to consider about the
>> mean.
>>
>> One of my point is that ib_action can stay or cannot stay as
>> *optional* declaration syntax for future.
>>
>> another my thinking is some diffeent syntax for ib_action. for
>> example...
>>
>> # as primitive syntax
>> def buttonPressed(sender)
>> ...
>> end
>> ib_action :buttonPressed
>>
>> # a sugar
>> ib_action(:buttonPressed) do |sender|
>> ...
>> end
>>
>> just now imagine up as one of possibility syntax.
>> it may be the ruby way ;)
>>
>> module ObjcCWrapper
>> def ib_action(name, &blk)
>> if block_given? then
>> define_method(name,blk)
>> end
>> end
>> end
>>
>>
>> again totally I'm sure ib_action idea is excellent.
>>
>> cheers!
>> --
>> hisa
>>
>> On 2007/01/25, at 8:27, Chris Mcgrath wrote:
>>
>>> (Accidently sent this to the main list first, copying here)
>>>
>>> I got tired of having to create classes in IB to match the ruby
>>> classes I created, and manually add actions/outlets to them so
>>> things
>>> would sink up so I wrote:
>>>
>>> http://pastie.textmate.org/35438
>>>
>>> Run it with -h for the options. It assumes you've only got one class
>>> that calls ib/ns_outlets per file.
>>>
>>> The classes.nib file inside a nib seems to be an old style plist
>>> format, so I've assumed that's what it is. If this turns out not to
>>> be true it could possibly mess up the nib, so make sure you have
>>> your
>>> pristine copy in version control :)
>>>
>>> If I can find a way for it to automatically work out the class names
>>> from the .rb file I will (suggestions welcome)
>>>
>>> Cheers,
>>>
>>> Chris
>>>
>>> _______________________________________________
>>> Rubycocoa-devel mailing list
>>> Rubyc****@lists*****
>>> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel
>>
>
> _______________________________________________
> Rubycocoa-devel mailing list
> Rubyc****@lists*****
> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel