rubycocoa-talk — talking about RubyCocoa

Re: [Rubycocoa-talk] Any indie/commerical app devlopers?

[Jonathan P. <jp...@dc...>]

On 16 Feb 2006, at 0:03, Rod Schmidt wrote:

> Are any of you small developers and using RubyCocoa in commercial  
> apps that you are actually selling?

I'm not yet, I'm afraid. However, as a contributor to the RubyCocoa  
project I'd be interested in hearing how you're using it in your  
application. For example, is the whole app RubyCocoa, or is it mainly  
RubyCocoa with some Objective C bits, or mainly Objective C with some  
RubyCocoa bits. Why did you decide to use RubyCocoa?

Thanks,
Jonathan

[Rubycocoa-talk] Any indie/commerical app devlopers?

[Rod S. <rsc...@xm...>]

Are any of you small developers and using RubyCocoa in commercial  
apps that you are actually selling?

I am and am interested in getting a group together to discuss  
RubyCocoa on the CocoaRadio podcast. If you're interested then drop  
me a line at rsc...@xm...

Rod Schmidt
infiniteNIL Software
www.infinitenil.com

Re: [Rubycocoa-talk] XCode 2.2 and duplicate file names

[Jonathan P. <jp...@dc...>]

On 13 Feb 2006, at 18:58, David Webster wrote:

> I am intending my ruby application to run under different  
> platforms, but to behave natively.  I therefore have created a  
> number of groups under class groups such as GTK2, COCOA, etc.   
> There are some files with the same file name under different group  
> folders, which shouldn't be a problem.  Eg:
>
> /GTK2/AppController.rb
> /COCOA/AppController.rb
>
> The problem is that when XCode builds the .app package, it copies  
> all the ruby files flatly into the Resources folder and does not  
> preserve the folder hierarchy, meaning that some files get  
> overwritten.  Is there a way to make XCode preserve the source  
> folder hierarchy?

A couple of solutions come to mind:

(1) Add the root folders (GTK2 etc) as "Create Folder References"  
rather than "Recursively create groups for any added folders". You'll  
no longer have control over what files show up in the project (just  
everything in the directory will - including .svn directories etc),  
but they will get copied in their entirety and the hierarchy will be  
preserved.

(2) Add the files individually as normal, creating Xcode groups as  
you wish. Go into the project Targets and "New copy files build  
phase". Edit properties for the build phase and choose Destination:  
Resources and Path: "GTK2" etc. You can rename the build phase too.  
Drag the files from the default "Copy Bundle Resources" build phase  
into the new copy files phase. Repeat for other folders.


You could also rename your files so there's no conflict, and pick the  
appropriate classes at run time (e.g., selecting between  
GTKAppController and CocoaAppControler). :)

Hope that helps,
Jonathan

[Rubycocoa-talk] XCode 2.2 and duplicate file names

[David W. <da...@da...>]

I am intending my ruby application to run under different platforms, but 
to behave natively.  I therefore have created a number of groups under 
class groups such as GTK2, COCOA, etc.  There are some files with the 
same file name under different group folders, which shouldn't be a 
problem.  Eg:

/GTK2/AppController.rb
/COCOA/AppController.rb

The problem is that when XCode builds the .app package, it copies all 
the ruby files flatly into the Resources folder and does not preserve 
the folder hierarchy, meaning that some files get overwritten.  Is there 
a way to make XCode preserve the source folder hierarchy?

Thanks,
Dave

Re: [Rubycocoa-talk] Forcing a trip through the event loop?

[Jonathan P. <jp...@dc...>]

On 11 Feb 2006, at 9:20, Jonathan Paisley wrote:

> Passing a plain Ruby doesn't work because it gets a new (and  
> therefore unique) ObjC wrapper object each time it gets passed to  
> Cocoa-land. I'm not 100% sure about this -- will investigate.

The problem described above is an issue. However, even if it were  
modified it doesn't really help[*].

Make your model objects - Project in your example - subclasses of  
NSObject and pass them directly as items to NSOutlineView. If you  
don't like having to do the 'alloc.init' dance, you can make a wrapper:

class Project < OSX::NSObject
   def self.new(*args)
     self.alloc.init(*args)
   end

   ...
end


[*] NSOutlineView doesn't retain items, so the persistent objc  
wrapper for the ruby object gets released but is still referenced by  
NSOutlineView - boom

Re: [Rubycocoa-talk] Forcing a trip through the event loop?

[Jonathan P. <jp...@dc...>]

On 10 Feb 2006, at 22:48, Dave Howell wrote:

> 		currentItem = @outlineView.itemAtRow(@outlineView.selectedRow)
> 		currentProject = Project.index(currentItem.to_i)
> 		newProject = currentProject.newProject('Unnamed')
>
> [I'm not passing Ruby objects to the outlineView, just ID numbers.)  
> If I now ask
>
> 		@outlineView.isExpandable(currentItem)
>
> it's "false," no surprise there. Specifically, it's "0". If I try  
> to update the view, things actually get worse....
>
> 		@outlineView.reloadItem(currentItem)
> 		@outlineView.isExpandable(currentItem)

I think the problem is due to the way items are handled across the  
ruby-cocoa bridge.

Cocoa identifies outline view items by ObjC object identity. Although  
you are passing ID numbers, they get converted to instances of  
NSDecimalNumber. For example, each time ID number '10' is passed,  
it'll get a different NSDecimalNumber instance. Therefore, Cocoa will  
never think you're referring to the same item.

Try making your items a Ruby subclass of NSObject and passing them  
directly, if that's possible. That will ensure the same ObjC instance  
is used for each item.

Passing a plain Ruby doesn't work because it gets a new (and  
therefore unique) ObjC wrapper object each time it gets passed to  
Cocoa-land. I'm not 100% sure about this -- will investigate.

Jonathan

[Rubycocoa-talk] Forcing a trip through the event loop?

[Dave H. <gr...@gr...>]

I have an outline display, with a convenient "+" button nearby. When I 
click the +, I want a new item to appear "underneath" my currently 
selected row, the current row to expand to expose the new item, and to 
select the new item.

I create the new item just fine, but I can't select the new thing 
because I can't expand the old thing. I can't expand the old thing 
because Cocoa doesn't know that it's expandable yet.

*IF* it already had an item underneath it, collapsed or not, then 
everything works find. It's only when it isn't an expandable item when 
I start that I get stuck.


		currentItem = @outlineView.itemAtRow(@outlineView.selectedRow)
		currentProject = Project.index(currentItem.to_i)
		newProject = currentProject.newProject('Unnamed')

[I'm not passing Ruby objects to the outlineView, just ID numbers.) If 
I now ask

		@outlineView.isExpandable(currentItem)

it's "false," no surprise there. Specifically, it's "0". If I try to 
update the view, things actually get worse....

		@outlineView.reloadItem(currentItem)
		@outlineView.isExpandable(currentItem)

Now the answer's "-1". "reloadItem" sets "needsDisplay" on the view, 
and it appears that "-1" is code for "this view's current status is not 
known."

OK, fine.

		self.window.display

Nope, doesn't help. Nothing happens until my entire little method has 
completed. The reload and display doesn't actually happen until Cocoa 
walks back through the input event loop, which it doesn't do until my 
code is done executing. :/ How can I get my code to *wait* until the 
reload/refresh/update/display has actually occurred? Or put another 
way, how can I get Cocoa to NOT wait to update the display? I don't 
know where to look for that sort of thing.

Re: [Rubycocoa-talk] programatically adding checkboxes to a prefs sheet

[Jonathan P. <jp...@dc...>]

On 9 Feb 2006, at 8:59, Yvon Thoraval wrote:

> having, by default three checkboxes (NSButton) a separator two  
> Cancel and Save buttons at the bottom.
>
> i'd like to programatically insert new checkboxes between the last  
> default one and the separator.

I don't know the answer to this one. However, since it's not specific  
to Ruby, you can probably get assistance from a much wider audience  
at one of the Cocoa-specific mailing lists or web sites. For example:

    http://lists.apple.com/mailman/listinfo/cocoa-dev

Cheers,
Jonathan

[Rubycocoa-talk] programatically adding checkboxes to a prefs sheet

[Yvon T. <tho...@fr...>]

Hey all,

i've a prefs sheet

having, by default three checkboxes (NSButton) a separator two Cancel  
and Save buttons at the bottom.

i'd like to programatically insert new checkboxes between the last  
default one and the separator.

i'd like having some advices on how to do that.

should i first group the default check boxes , could this facilitate  
inserting others ?

when i insert new NSButtons, is the sheet height following or does i  
have to do something to resize it ?

any help will be apreciated.

Yvno

Re: [Rubycocoa-talk] closing a sheet and getting back to the mainWindow

[Yvon T. <tho...@fr...>]

Le 8 f=E9vr. 06 =E0 11:01, Jonathan Paisley a =E9crit :

>
> I'm confused - isn't it just about the same? You're calling through =20=

> to the same Cocoa methods underneath. Could you give an example of =20
> the differences in complexity?
>


ruby-side open a sheet :


	def prefsSheetOpen(sender)
         OSX::NSApp=20
().beginSheet_modalForWindow_modalDelegate_didEndSelector_contextInfo=20
(@prefsSheet, @mainWindow, self, nil, nil)
	end


java-side open a sheet :


     public void bottleSheetViewOpen() {
		=
NSApplication.sharedApplication().beginSheet(bottleSheetView, =20
mainWindow,null,null,null);
     }

i don't understand clearly why this part =20
"_modalForWindow_modalDelegate_didEndSelector_contextInfo" is needed =20
for ruby...

oups i see in java you might have more than one method named =20
"beginSheet" depending on args number and types, afaik, in ruby it =20
isn't possible, the reason for...

somehow rubyCocoa syntax is closer to ObjC ones than Java...
best,

Yvon=

Re: [Rubycocoa-talk] closing a sheet and getting back to the mainWindow

[Jonathan P. <jp...@dc...>]

On 7 Feb 2006, at 22:30, Yvon Thoraval wrote:

> Le 7 f=E9vr. 06 =E0 23:24, Jonathan Paisley a =E9crit :
>
>> Don't call 'runModalForWindow' and it should work.
>
> yes ok this works, thanks !
>
> i'm surprised that the way to use cocoa thru ruby is more =20
> complicated than thru java...

I'm confused - isn't it just about the same? You're calling through =20
to the same Cocoa methods underneath. Could you give an example of =20
the differences in complexity?

Cheers,
Jonathan

Re: [Rubycocoa-talk] closing a sheet and getting back to the mainWindow

[Yvon T. <tho...@fr...>]

Le 7 f=E9vr. 06 =E0 23:24, Jonathan Paisley a =E9crit :

> Don't call 'runModalForWindow' and it should work.
>

yes ok this works, thanks !

i'm surprised that the way to use cocoa thru ruby is more complicated =20=

than thru java...

best

Yvon=

FOUND Re: [Rubycocoa-talk] closing a sheet and getting back to the mainWindow

[Yvon T. <tho...@fr...>]

Le 7 f=E9vr. 06 =E0 20:49, Yvon Thoraval a =E9crit :

> i suppose i need to add something to get access back to the =20
> mainWindow ?
>

yes just add :

OSX::NSApp().stopModal()

in order to counter-balanced the runModalForWindow

(Luc Heinrich)

best

Yvon=

Re: [Rubycocoa-talk] closing a sheet and getting back to the mainWindow

[Jonathan P. <jp...@dc...>]

On 7 Feb 2006, at 19:49, Yvon Thoraval wrote:

> something strange : i'm able to open and close a sheet but after  
> having closed it i've no more acces to the mainWindow buttons even  
> the main menu quit...
>
> here is the way i open it :
>
> 	def prefsSheetOpen(sender)
>         OSX::NSApp 
> ().beginSheet_modalForWindow_modalDelegate_didEndSelector_contextInfo( 
> @prefsSheet, @mainWindow, self, nil, nil)
>         OSX::NSApp().runModalForWindow(@prefsSheet)
> 	end

Don't call 'runModalForWindow' and it should work.

A sheet implicitly grabs focus from the window it is a sheet for.  
Other windows in the application continue to respond.

'runModalForWindow' grabs focus from all windows in the application  
to the chosen one (and is rarely needed), and can only be stopped  
using stopModal and friends (see the documentation).

Hope that helps,
Jonathan

[Rubycocoa-talk] closing a sheet and getting back to the mainWindow

[Yvon T. <tho...@fr...>]

Hey all,

something strange : i'm able to open and close a sheet but after  
having closed it i've no more acces to the mainWindow buttons even  
the main menu quit...

here is the way i open it :

	def prefsSheetOpen(sender)
         OSX::NSApp 
().beginSheet_modalForWindow_modalDelegate_didEndSelector_contextInfo 
(@prefsSheet, @mainWindow, self, nil, nil)
         OSX::NSApp().runModalForWindow(@prefsSheet)
	end


and the way to close it :

	def prefsSheetSave(sender)
		p "prefsSheetSave"
		OSX::NSApp().endSheet(@prefsSheet)
		p "prefsSheetSave"
		@prefsSheet.close()
		p "prefsSheetSave finished"
	end


i suppose i need to add something to get access back to the mainWindow ?

Yvon

Re: [Rubycocoa-talk] how to quit an application properly ?

[Yvon T. <tho...@fr...>]

Le 7 f=E9vr. 06 =E0 11:34, Jonathan Paisley a =E9crit :

> Having said that, you can wire the button up directly in Interface =20
> Builder without having to add any extra code :) -- try this:
>
>   control-drag from the qutton to "File's Owner"
>   double click 'terminate:' in the Target/Action list that appears


thanks a lot, i didn't know that feature...

Yvon=

Re: [Rubycocoa-talk] how to quit an application properly ?

[kimura wataru<ki...@us...>]

Hi,

NSApplication#terminate() quits your application.

  def quitter(sender)
    app = OSX::NSApplication.sharedApplication
    app.ternimate(sender)
  end

Tue, Feb 7, 2006 11:16:20 AM, Yvon Thoraval wrote:
>Hey all,
>
>i've written a first app using RubyCocoa, in this app i've a button  
>"Quit" whose action is "quitter" the method "quitter" within  
>Controller.rb, is "simply" :
>
>	def quitter(sender)
>		exit 0
>	end
>


-- 
kimura wataru

Re: [Rubycocoa-talk] how to quit an application properly ?

[Jonathan P. <jp...@dc...>]

On 7 Feb 2006, at 10:16, Yvon Thoraval wrote:

> Hey all,
>
> i've written a first app using RubyCocoa, in this app i've a button  
> "Quit" whose action is "quitter" the method "quitter" within  
> Controller.rb, is "simply" :
>
> 	def quitter(sender)
> 		exit 0
> 	end

Try:

   OSX::NSApplication.sharedApplication.terminate(nil)

You can see the documentation for this method in Xcode's  
Documentation window by searching for 'terminate:'.

Having said that, you can wire the button up directly in Interface  
Builder without having to add any extra code :) -- try this:

   control-drag from the qutton to "File's Owner"
   double click 'terminate:' in the Target/Action list that appears

That's it!

[Rubycocoa-talk] how to quit an application properly ?

[Yvon T. <tho...@fr...>]

Hey all,

i've written a first app using RubyCocoa, in this app i've a button  
"Quit" whose action is "quitter" the method "quitter" within  
Controller.rb, is "simply" :

	def quitter(sender)
		exit 0
	end

i think this is, by far, not properly done, because, when i use this  
button i get :
/Users/yvon/work/RubyCocoa/AB2Web/build/Development/AB2Web.app/ 
Contents/Resources/Controller.rb:171:in `NSApplicationMain':  
NSApplicationMain - RBException_SystemExit - exit (OSX::OCException)
	from /Users/yvon/work/RubyCocoa/AB2Web/build/Development/AB2Web.app/ 
Contents/Resources/rb_main.rb:49

AB2Web has exited with status 1.

line 171 of Controller.rb being "exit 0"

and rb_main.rb : 49 being :

if $0 == __FILE__ then
   rb_main_init
   OSX.NSApplicationMain(0, nil) ### line 49
end


then what's the correct way to quit (no files to save) ?

surprisingly, i've noticed that in "" their is no application avec a  
button for quitting why ?

best,

Yvon

[Rubycocoa-talk] Ruby Cocoa Programmers for Hire?

[Tom M. <tmo...@in...>]

I have a commercial development project that I think would
be perfect for Ruby Cocoa.

Are there any accomplished programmers for hire that are
looking for contract work?

-- 
-- Tom Mornini

Re: [Rubycocoa-talk] [NSPopUpButton] adding items

[Yvon T. <tho...@fr...>]

Le 4 f=E9vr. 06 =E0 19:10, Jonathan Paisley a =E9crit :

>
> XCode documentation tells me there's no method called 'addItem' on =20
> NSPopUpButton. There is 'addItemWithTitle' though. Can you try it?
>
>


yes, fine thanks, it works ;-)

the reason for addItem it's becaus it does exist on the Cocoa-Java =20
side ))

i've made use of AppKiDo.app in order to browse classes/methods...=

Re: [Rubycocoa-talk] [NSPopUpButton] adding items

[Jonathan P. <jp...@dc...>]

On 4 Feb 2006, at 9:14, Yvon Thoraval wrote:

> i'm starting within RubyCocoa, although i've been using Cocoa-Java,  
> i want to setup the items of an NSPopUpButton programmatically.
>
> if i list all the associated methods by :
>
> 		ctm...@ch...
> 		ctmethods.each { |m| p "choixTheme #{m}"}
>
> i never get even the "titleOfSelectedItem" nor "indexOfSelectedItem"
> why ?

The 'methods' method lists plain Ruby methods. The Objective C  
methods are implemented via the method_missing hook, and therefore  
don't show up like that.

There is an 'objc_methods' method provided by RubyCocoa, but it had a  
bug which was fixed in CVS a couple of days ago. Your version may not  
have this fix yet.


> @choixTheme.addItem("Unbelievable")
> i get an error :
> /Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/ 
> osx/objc/oc_wrapper.rb:17:in `NSApplicationMain': NSApplicationMain  
> - RBException_OSX::OCMessageSendException - NSPopUpButton#addItem:  
> - methodSignature is nil. (OSX::OCException)
>
> then, what's the correct way to setup all the items of a  
> NSPopUpButton programmatically ?

XCode documentation tells me there's no method called 'addItem' on  
NSPopUpButton. There is 'addItemWithTitle' though. Can you try it?

[Rubycocoa-talk] [NSPopUpButton] adding items

[Yvon T. <tho...@fr...>]

Hey all,

i'm starting within RubyCocoa, although i've been using Cocoa-Java, i  
want to setup the items of an NSPopUpButton programmatically.

the related named ib_outlets is called ":choixTheme"

if i list all the associated methods by :

		ctm...@ch...
		ctmethods.each { |m| p "choixTheme #{m}"}

i never get even the "titleOfSelectedItem" nor "indexOfSelectedItem"

why ?

if i try :

@choixTheme.addItem("Unbelievable")
i get an error :
/Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/osx/ 
objc/oc_wrapper.rb:17:in `NSApplicationMain': NSApplicationMain -  
RBException_OSX::OCMessageSendException - NSPopUpButton#addItem: -  
methodSignature is nil. (OSX::OCException)

then, what's the correct way to setup all the items of a  
NSPopUpButton programmatically ?

best,

Yvon

Re: [Rubycocoa-talk] writing ruby extensions with rubycocoa

[Jonathan P. <jp...@dc...>]

On 2 Feb 2006, at 23:53, Tim Burks wrote:

> To illustrate it, I've written a small article that shows how to wrap
> Dave Thomas' jukebox example with rubycocoa.  It is online here:
>
> http://www.rubycocoa.com/ruby-extensions-with-rubycocoa
>
> Please take a look sometime and send me any thoughts or suggestions.

This looks cool.

> Memory deallocation is handled the Cocoa way rather than the Ruby =20
> way. So even though we=92ve gotten rid of all references to our =20
> jukebox object, it=92s not deleted until the Objective-C runtime =20
> cleans up. In our example, that happens when we exit irb.
Isn't it just that ruby's garbage collector hasn't run yet, and so =20
the Ruby reference to the ObjC object is still around? Try putting =20
GC.start before exiting and see if that forces the deallocation.


I've just been playing with RubyInline for simple C interfacing. I =20
wanted to register a global hotkey, which requires accessing Carbon =20
event APIs. Here's a nippet of the code:

class Controller < NSObject
   def self.shared_instance
     @instance ||=3D Controller.alloc.init
   end

   inline do |builder|
     builder.src_ext =3D "m"
     builder.prefix %q{
     #undef T_DATA
     } # required because Ruby and Quicktime both define T_DATA
     builder.include "<Carbon/Carbon.h>"
     builder.prefix %q{
         EventHotKeyRef gMyHotKeyRef;
         EventHotKeyID gMyHotKeyID;
         static OSStatus MyHotKeyHandler(EventHandlerCallRef =20
nextHandler,EventRef theEvent,void *userData)
         {
           rb_eval_string("Controller.shared_instance.hotkey_pressed");
           return noErr;
         }
     }
     builder.c_singleton %q{
       void register_key(int keycode) {
         EventTypeSpec eventType;
         eventType.eventClass=3DkEventClassKeyboard;
         eventType.eventKind=3DkEventHotKeyPressed;
         InstallApplicationEventHandler(&MyHotKeyHandler,=20
1,&eventType,NULL,NULL);
         gMyHotKeyID.signature=3D'WBCM'; // choose something here
         gMyHotKeyID.id=3D1;
         RegisterEventHotKey(keycode, cmdKey, gMyHotKeyID, =20
GetApplicationEventTarget(), 0, &gMyHotKeyRef);

       }
     }
   end

   def hotkey_pressed
     ...
   end
end

# During initialisation...
Controller.register_key

--- inline.rb	1970-01-01 01:00:00.000000000 +0100
+++ ../inline.rb	2006-02-03 09:14:59.000000000 +0000
@@ -260,6 +260,7 @@
      public
+    attr_accessor :src_ext
      def initialize(mod)
        raise ArgumentError, "Class/Module arg is required" unless =20
Module =3D=3D=3D mod
        # new (but not on some 1.8s) -> inline -> real_caller|eval
@@ -276,6 +277,7 @@
        @sig =3D {}
        @flags =3D []
        @libs =3D []
+      @src_ext =3D "c"
      end
      ##
@@ -310,7 +312,7 @@
        unless so_exists and File.mtime(rb_file) < File.mtime(so_name)
=09
-	src_name =3D "#{Inline.directory}/#{module_name}.c"
+	src_name =3D "#{Inline.directory}/#{module_name}.#{src_ext}"
	old_src_name =3D "#{src_name}.old"
	should_compare =3D File.write_with_backup(src_name) do |io|
	  io.puts

[Rubycocoa-talk] writing ruby extensions with rubycocoa

[Tim B. <tim...@gm...>]

One of my favorite things about rubycocoa is how easily I can use it
to call C code from Ruby.  It's perhaps an obvious advantage, but an
underappreciated one as well.

To illustrate it, I've written a small article that shows how to wrap
Dave Thomas' jukebox example with rubycocoa.  It is online here:

http://www.rubycocoa.com/ruby-extensions-with-rubycocoa

Please take a look sometime and send me any thoughts or suggestions.

thanks!

Tim