rubycocoa-talk — talking about RubyCocoa

Re: [Rubycocoa-talk] Objective-C Ubiquity?

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

On 4 Jun 2005, at 23:39, Dave Howell wrote:

>> I usually name my outlets indicating what they're connected to -  
>> for example: "taskTitleField".
>>
>
> An interesting hybrid. I'd been naming them by function, which  
> would be "taskTitle." To name them by recipient would be  
> "NSTextField" or the like. My solution was to just call it "title",  
> which doesn't match "setTaskTitle."

With bindings you often don't need an outlet for the text field at  
all. You just have an NSString in your object bound to the text field  
- Cocoa Bindings takes care of keeping the text field in sync with  
the string.

Furthermore, if you change the value of your string variable through  
a call to (for example) your setTitle, the Key Value Observing system  
notifies the text view and keeps it up to date. This doesn't quite  
happen automatically in RubyCocoa (due to implementation details),  
but can be made to work very naturally with a little extra code,  
which I've posted to the list about before.

>> I'm afraid, however, that it's probably worth working through the  
>> one of the Objective C examples first.
>
> Er, one of which Objective C samples?

An example for Cocoa Bindings (found using Google):

    http://www.cocoadevcentral.com/articles/000080.php

also, from Apple (again via Google):

    http://developer.apple.com/documentation/Cocoa/Conceptual/ 
CurrencyConverterBindings/01introduction/chapter_1_section_1.html

There are lots of ready-to-look-at Objective C examples here:

    http://homepage.mac.com/mmalc/CocoaExamples/controllers.html

[Rubycocoa-talk] Shared Knowledge

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

So where's a good place to put things I've learned that others might 
want to know? I managed to break my window loaders three times while 
trying to get things organized before finally figuring out what was 
going on.

The code for the RubyCocoa sample "RubyRaiseMan" for example, has
	require 'PreferenceController'
in MyDocument.rb. I *thought* when looking at rb_main.rb, that it would 
load ALL *.rb files, but if I also didn't include all my own .rb files 
at the beginning of my main file, classes would go missing, and windows 
would not open.

Lo. Inline code is run at loading, and the loading order is undefined. 
(It looks like it's alphabetical.) I think I can finally predict the 
order of code outside a class, inside a class, inside the "init" 
method, inside the "initialize" method, ditto for all the above in 
files other than the main file, and how to use 
applicationDidFinishLaunching to delay some code further.

Back to work...

Re: [Rubycocoa-talk] Objective-C Ubiquity?

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

> I usually name my outlets indicating what they're connected to - for 
> example: "taskTitleField".

An interesting hybrid. I'd been naming them by function, which would be 
"taskTitle." To name them by recipient would be "NSTextField" or the 
like. My solution was to just call it "title", which doesn't match 
"setTaskTitle."

> I'm afraid, however, that it's probably worth working through the one 
> of the Objective C examples first.

Er, one of which Objective C samples?

[Rubycocoa-talk] tiger and nsobjectcontroller

[Cornelius J. <cj...@vi...>]

hi all

two questions,
all xcode related examples seem to have bugs, or the same bug:
nsview not initialized correctly, did you forget to call super?

i guess this is within the framework, cause the code seems fine on  
first glance.

second question, does RubyCocoa support bindings and core data?
if not, what work remains, and how can i help?
i'm new to ruby, but i've been to objective-c land since nextstep and  
java for 5 years, plus i've been around python on and off for what's  
worth.

regards

cornelius

Cornelius Jaeger,
Member of Visual FOOD GmbH - Software and Multimedia Solutions

http://www.screenfood.ch
http://www.visualfood.ch
Moosstrasse 7
CH-6003 Lucerne
SWITZERLAND

Fon: +41 (0)41 21 0 21 41
Fax: +41 (0)41 21 0 21 43

iChat or AIM ne...@ma...

Re: [Rubycocoa-talk] Objective-C Ubiquity?

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

On 4 Jun 2005, at 20:37, Dave Howell wrote:

> My outlets were named things like "taskDue," "taskTitle," and  
> "taskDescription," and when I added the actions, I named them  
> "setTaskDue," "setTaskTitle," and "setTaskDescription." Xcode or IB  
> or Cocoa or I-don't-know-who's-fault-this-is obviously decided they  
> were related in some way and broke everything for me.

There's a convention that means that rather than directly change the  
instance variable in your class, if there's a method named  
'setSomeName' where 'someName' is the name of the instance variable,  
it'll get used instead.

This is the Key-Value Coding system used in Cocoa Bindings. Read more  
here:

http://developer.apple.com/documentation/Cocoa/Conceptual/ 
CocoaBindings/CocoaBindings.html

Specifically, see the documentation for the setValue:forKey: method:

http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ 
ObjC_classic/Protocols/NSKeyValueCoding.html#//apple_ref/doc/uid/ 
20000471-BABEHECF

> I have gone back and put my outlets back in with names that can't  
> be matched up, and now things work properly. I have no idea where  
> I'd even find this "feature" documented. Sigh. Caveat Programmeri.

I usually name my outlets indicating what they're connected to - for  
example: "taskTitleField".

It's worth taking a look at Cocoa Bindings. They don't solve every  
situation, but for the situations they're designed for they make life  
very easy. A little extra support code is needed in RubyCocoa to make  
them work (see http://rubycocoa.sourceforge.net/w.en/FAQ.html and my  
previous posts to the list on the matter).

I'm afraid, however, that it's probably worth working through the one  
of the Objective C examples first.

[Rubycocoa-talk] Objective-C Ubiquity?

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

Am I the only person on this list who has NOT been programming in 
Objective-C before trying to use RubyCocoa? Certainly every scrap of 
documentation I've found takes for granted I know Obj-C or Java or 
both.

I just spent a few hour running down an exasperatingly weird bug.

I have my happy Interface Builder window and nib file, with all its 
outlets working (finally), and I start adding in actions. When I'm 
done, all my outlets have failed. Nothing I do can get any of my 
outlets to be anything but "NilClass::Nil."

On the other hand, all my actions are going off as soon as the window 
opens, which is tending to overwrite the underlying information with 
blanks before I can fill in the window with the proper values.

OK, fine, I can adapt. I change my actions to check for an 
"initialized" flag, and if it's not initialized, instead of copying the 
text or button or whatever TO the data, they load the interface element 
FROM the data. I still cannot reference interface elements unless 
they're poked by the user, but I guess I'll survive.

I clean up my subclass by removing all those dysfunctional outlets.

All my actions stop firing when the window opens. Initialization is now 
broken.


If you like puzzles. stop here and see if you can figure out what 
"mistake" I made.















My outlets were named things like "taskDue," "taskTitle," and 
"taskDescription," and when I added the actions, I named them 
"setTaskDue," "setTaskTitle," and "setTaskDescription." Xcode or IB or 
Cocoa or I-don't-know-who's-fault-this-is obviously decided they were 
related in some way and broke everything for me.

I have gone back and put my outlets back in with names that can't be 
matched up, and now things work properly. I have no idea where I'd even 
find this "feature" documented. Sigh. Caveat Programmeri.

Re: [Rubycocoa-talk] anyone work with toolbars?

[Mark H. <di...@ma...>]

On Jun 1, 2005, at 9:04 AM, Kevin Bullock wrote:

> There's two problems with your code, both in the  
> toolbar_itemForItemIdentifier_willBeInsertedIntoToolbar method. The  
> first is that when the method is called, itemid is an NSCFString,  
> not a Ruby String, and it doesn't get implicitly converted. Just  
> inserting 'itemid = itemid.to_s' will fix that though. (If you step  
> through that method, you might notice that neither branch of the if  
> is being called, because the comparison fails.)

That was the show stopper... the other problems I managed to figure  
out, but for some reason I couldn't get that one :)

> The other problem is that you're passing a string to  
> NSToolbarItem#setImage, which expects an NSImage. You can fix this  
> easily:
>
>     tbi.setImage "NSApplicationIcon"
>
> becomes:
>
>     tbi.setImage( NSImage.imageNamed( "NSApplicationIcon" ) )
>
> and assuming there's an NSApplicationIcon.{tif,icns,...} in your  
> app bundle, it'll work.

yeah, I noticed that one, and felt kinda dumb :) Setting the image to  
a string? Oh well.

Also, NSImage.imageNamed("NSApplicationIcon") doesn't require an  
image with that name in the bundle; it automatically grabs the image  
used for the application's icon in the dock. I was using it because I  
figured it should never fail, and since I was having problems already...

I'm playing with a ruby module right now that helps with various  
setup procedures, including NSToolbar and it's ilk. The verbosity of  
the code needed to create a toolbar item (let alone a toolbar itself)  
is rather staggering, coming from a Ruby standpoint. It makes Ruby  
look like Java :)

thanks,
Mark

> Hope this helps. Let me know if anything is unclear.
>
> Pacem in terris / Mir / Shanti / Salaam / Heiwa
> Kevin R. Bullock
>
>
>> To: rub...@li...
>> From: Mark Hubbart <di...@ma...>
>> Date: Tue, 31 May 2005 07:59:04 -0700
>> Subject: [Rubycocoa-talk] anyone work with toolbars?
>> Reply-To: rub...@li...
>>
>> Hi,
>> The main reasons I want to work with RubyCocoa is the ability to use
>> all the nifty cocoa features like toolbars, drawers, and sheets. I've
>> been fighting to figure out the whole toolbar thing, but I've gotten
>> a bit stuck. I've stuck what I have so far at the end of the message
>> (edited somewhat for brevity).
>>
>> It doesn't work. There is nothing being shown in the toolbar, and it
>> seems that the toolbaritems I'm creating never get added to the
>> toolbar; calling @main_window.toolbar.items returns an empty NSArray.
>>
>> Has anyone worked with toolbars under RubyCocoa, who could offer any
>> advice (or sample code!)? I'm a bit stuck here at the moment, so
>> *any* help would be appreciated.
>>
>> Here's the code. The calls to breakpoint() are from the ruby-
>> breakpoint library, which has helped a lot in figuring out what I  
>> have.
>>
>> -----
>> class AppController < OSX::NSObject
>>    include OSX
>>
>>    ib_outlets :main_window
>>
>>    def awakeFromNib
>>      tb = NSToolbar.alloc.initWithIdentifier "main window toolbar"
>>      tb.setAllowsUserCustomization true
>>      tb.setAutosavesConfiguration true
>>      tb.setDisplayMode NSToolbarDisplayModeIconOnly
>>
>>      tb.setDelegate self
>>      @main_window.setToolbar tb
>>
>>      breakpoint
>>    end
>>
>>    def nullActionOfDoom(*args)
>>      puts "Null action of doom!!!!"
>>      p args
>>    end
>>
>>    # --- delegate for toolbar
>>
>>    def toolbar_itemForItemIdentifier_willBeInsertedIntoToolbar
>> (toolbar, itemid, insert)
>>      if itemid == "install item toolbar item"
>>        tbi = NSToolbarItem.alloc.initWithItemIdentifier itemid
>>        tbi.setLabel "Install"
>>        tbi.setPaletteLabel "Install"
>>        tbi.setToolTip "Install this item"
>>        tbi.setImage "NSApplicationIcon"
>>
>>        tbi.setTarget self
>>        tbi.setAction :nullActionOfDoom # is this how you replace the
>> selector call?
>>
>>      elsif itemid == "remove item toolbar item"
>>        tbi = NSToolbarItem.alloc.initWithItemIdentifier itemid
>>        tbi.setLabel "Remove"
>>        tbi.setPaletteLabel "Remove"
>>        tbi.setToolTip "Remove this item"
>>        tbi.setImage "NSApplicationIcon"
>>
>>        tbi.setTarget self
>>        tbi.setAction :nullActionOfDoom
>>      end
>>      breakpoint
>>      tbi
>>    end
>>
>>    def toolbarAllowedItemIdentifiers(toolbar)
>>      breakpoint
>>      ["install item toolbar item", "remove item toolbar item"]
>>    end
>>
>>    def toolbarDefaultItemIdentifiers(toolbar)
>>      breakpoint
>>      ["install item toolbar item", "remove item toolbar item"]
>>    end
>>
>>    def toolbarDidRemoveItem(notification)        breakpoint end
>>    def toolbarSelectableItemIdentifiers(toolbar) breakpoint end
>>    def toolbarWillAddItem(toolbar)               breakpoint end
>> end
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg- 
> q22005
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>

Re: [Rubycocoa-talk] anyone work with toolbars?

[Kevin B. <krb...@ma...>]

There's two problems with your code, both in the  
toolbar_itemForItemIdentifier_willBeInsertedIntoToolbar method. The  
first is that when the method is called, itemid is an NSCFString, not  
a Ruby String, and it doesn't get implicitly converted. Just  
inserting 'itemid = itemid.to_s' will fix that though. (If you step  
through that method, you might notice that neither branch of the if  
is being called, because the comparison fails.)

The other problem is that you're passing a string to  
NSToolbarItem#setImage, which expects an NSImage. You can fix this  
easily:

     tbi.setImage "NSApplicationIcon"

becomes:

     tbi.setImage( NSImage.imageNamed( "NSApplicationIcon" ) )

and assuming there's an NSApplicationIcon.{tif,icns,...} in your app  
bundle, it'll work.

Hope this helps. Let me know if anything is unclear.

Pacem in terris / Mir / Shanti / Salaam / Heiwa
Kevin R. Bullock

> To: rub...@li...
> From: Mark Hubbart <di...@ma...>
> Date: Tue, 31 May 2005 07:59:04 -0700
> Subject: [Rubycocoa-talk] anyone work with toolbars?
> Reply-To: rub...@li...
>
> Hi,
> The main reasons I want to work with RubyCocoa is the ability to use
> all the nifty cocoa features like toolbars, drawers, and sheets. I've
> been fighting to figure out the whole toolbar thing, but I've gotten
> a bit stuck. I've stuck what I have so far at the end of the message
> (edited somewhat for brevity).
>
> It doesn't work. There is nothing being shown in the toolbar, and it
> seems that the toolbaritems I'm creating never get added to the
> toolbar; calling @main_window.toolbar.items returns an empty NSArray.
>
> Has anyone worked with toolbars under RubyCocoa, who could offer any
> advice (or sample code!)? I'm a bit stuck here at the moment, so
> *any* help would be appreciated.
>
> Here's the code. The calls to breakpoint() are from the ruby-
> breakpoint library, which has helped a lot in figuring out what I  
> have.
>
> -----
> class AppController < OSX::NSObject
>    include OSX
>
>    ib_outlets :main_window
>
>    def awakeFromNib
>      tb = NSToolbar.alloc.initWithIdentifier "main window toolbar"
>      tb.setAllowsUserCustomization true
>      tb.setAutosavesConfiguration true
>      tb.setDisplayMode NSToolbarDisplayModeIconOnly
>
>      tb.setDelegate self
>      @main_window.setToolbar tb
>
>      breakpoint
>    end
>
>    def nullActionOfDoom(*args)
>      puts "Null action of doom!!!!"
>      p args
>    end
>
>    # --- delegate for toolbar
>
>    def toolbar_itemForItemIdentifier_willBeInsertedIntoToolbar
> (toolbar, itemid, insert)
>      if itemid == "install item toolbar item"
>        tbi = NSToolbarItem.alloc.initWithItemIdentifier itemid
>        tbi.setLabel "Install"
>        tbi.setPaletteLabel "Install"
>        tbi.setToolTip "Install this item"
>        tbi.setImage "NSApplicationIcon"
>
>        tbi.setTarget self
>        tbi.setAction :nullActionOfDoom # is this how you replace the
> selector call?
>
>      elsif itemid == "remove item toolbar item"
>        tbi = NSToolbarItem.alloc.initWithItemIdentifier itemid
>        tbi.setLabel "Remove"
>        tbi.setPaletteLabel "Remove"
>        tbi.setToolTip "Remove this item"
>        tbi.setImage "NSApplicationIcon"
>
>        tbi.setTarget self
>        tbi.setAction :nullActionOfDoom
>      end
>      breakpoint
>      tbi
>    end
>
>    def toolbarAllowedItemIdentifiers(toolbar)
>      breakpoint
>      ["install item toolbar item", "remove item toolbar item"]
>    end
>
>    def toolbarDefaultItemIdentifiers(toolbar)
>      breakpoint
>      ["install item toolbar item", "remove item toolbar item"]
>    end
>
>    def toolbarDidRemoveItem(notification)        breakpoint end
>    def toolbarSelectableItemIdentifiers(toolbar) breakpoint end
>    def toolbarWillAddItem(toolbar)               breakpoint end
> end

Re: [Rubycocoa-talk] [ANN] RubyCocoa 0.4.1 for Tiger (10.4)

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

On 1 Jun 2005, at 15:54, FUJIMOTO Hisa wrote:
>
> It's difficult to decide which (and how) libruby is linked for *binary
> package* when different requirement exists. It may be better that you
> build rubycocoa by yourself tuned for your purpose.
>

Thanks for the info.

Thinking about it further, I realise my question was more like this:

I know that during the build process the installed AppKit header  
files are parsed to generate wrappers. Will the built RubyCocoa be  
susceptible to (Cocoa, not Ruby) link failures on 10.3 if compiled on  
Tiger? If so, is there a way to persuade it to build against the  
10.3.9 SDK?

Thanks.
Jonathan

Re: [Rubycocoa-talk] anyone work with toolbars?

[Mark H. <di...@ma...>]

On Jun 1, 2005, at 4:26 AM, Jonathan Paisley wrote:

>
> On 31 May 2005, at 15:59, Mark Hubbart wrote:
>
>
>>   def toolbar_itemForItemIdentifier_willBeInsertedIntoToolbar 
>> (toolbar, itemid, insert)
>>     if itemid == "install item toolbar item"
>>
>>
>
> Does this code work? The condition above is likely to always be  
> false, since itemid is an NSString, not a ruby string:
>
> irb> "Foo" == "Foo"
> => true
> irb> OSX::NSString.stringWithString("Foo") == "Foo"
> => false
> irb> OSX::NSString.stringWithString("Foo").to_s == "Foo"
> => true

Ahhh! Thank you so much! I added those five characters to my code and  
it works. Now I can stop pulling my hair out :)

There were a few other bugs that I solved by looking at the japanese  
example code on the website, but the String != NSString eluded me.  
I'm not sure why I didn't think of that, I probably should have  
realized I would be getting an NSString argument, not a Ruby String...

thanks,
Mark

Re: [Rubycocoa-talk] [ANN] RubyCocoa 0.4.1 for Tiger (10.4)

[FUJIMOTO H. <hi...@fo...>]

At Wed, 1 Jun 2005 13:51:18 +0100,
Jonathan Paisley wrote:
> On 1 Jun 2005, at 13:33, FUJIMOTO Hisa wrote:
> 
> > RubyCocoa 0.4.1 binary package (dmg) for Tiger (Mac OS X 10.4) is  
> > here:
> >
> >   http://prdownloads.sourceforge.net/rubycocoa/RubyCocoa-0.4.1- 
> > tiger.dmg
> >
> 
> What will happen if this framework is used on Panther?

Rubycocoa of the current Tiger binary package is (dynamic) linked to
/usr/lib/libruby.dylib. So it may be depend on /usr/lib/libruby.dylib
on target environment:

  $ cd /tmp && mkdir foo && cd foo
  $ gzcat /Volumes/RubyCocoa-0.4.1-tiger/RubyCocoa-0.4.1.pkg/Contents/Archive.pax.gz | \
      pax -r ./Library/Frameworks/RubyCocoa.framework/Versions/A/RubyCocoa
  $ otool -L ./Library/Frameworks/RubyCocoa.framework/Versions/A/RubyCocoa
  ./Library/Frameworks/RubyCocoa.framework/Versions/A/RubyCocoa:
	@executable_path/../Frameworks/RubyCocoa.framework/Versions/A/RubyCocoa \
           (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa \
           (compatibility version 1.0.0, current version 11.0.0)
	/usr/lib/libruby.1.dylib (compatibility version 1.8.0, current version 1.8.2)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.0)

It's difficult to decide which (and how) libruby is linked for *binary
package* when different requirement exists. It may be better that you
build rubycocoa by yourself tuned for your purpose.

thanks,
-- 
FUJIMOTO Hisa

Re: [Rubycocoa-talk] [ANN] RubyCocoa 0.4.1 for Tiger (10.4)

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

On 1 Jun 2005, at 13:33, FUJIMOTO Hisa wrote:

> RubyCocoa 0.4.1 binary package (dmg) for Tiger (Mac OS X 10.4) is  
> here:
>
>   http://prdownloads.sourceforge.net/rubycocoa/RubyCocoa-0.4.1- 
> tiger.dmg
>

What will happen if this framework is used on Panther?

My script that bundles up RubyCocoa inside an application copies the  
installed RubyCocoa framework for distribution. Will it mean the  
application won't work on Panther?

Thanks
Jonathan

[Rubycocoa-talk] [ANN] RubyCocoa 0.4.1 for Tiger (10.4)

[FUJIMOTO H. <hi...@fo...>]

Hi all,

RubyCocoa 0.4.1 binary package (dmg) for Tiger (Mac OS X 10.4) is here:

  http://prdownloads.sourceforge.net/rubycocoa/RubyCocoa-0.4.1-tiger.dmg

thanks,
-- 
FUJIMOTO Hisa

Re: [Rubycocoa-talk] anyone work with toolbars?

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

On 31 May 2005, at 15:59, Mark Hubbart wrote:

>   def toolbar_itemForItemIdentifier_willBeInsertedIntoToolbar 
> (toolbar, itemid, insert)
>     if itemid == "install item toolbar item"
>

Does this code work? The condition above is likely to always be  
false, since itemid is an NSString, not a ruby string:

irb> "Foo" == "Foo"
=> true
irb> OSX::NSString.stringWithString("Foo") == "Foo"
=> false
irb> OSX::NSString.stringWithString("Foo").to_s == "Foo"
=> true

Re: [Rubycocoa-talk] anyone work with toolbars?

[Mark H. <di...@ma...>]

On May 31, 2005, at 7:59 AM, Mark Hubbart wrote:

> Hi,
> The main reasons I want to work with RubyCocoa is the ability to  
> use all the nifty cocoa features like toolbars, drawers, and  
> sheets. I've been fighting to figure out the whole toolbar thing,  
> but I've gotten a bit stuck.

I think I may have found something. I didn't find it before, because  
it was embedded in a japanese page, but the code seems very clear:
http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=view;name=RubyCocoa% 
A4%C7Cocoa%CB%DC

cheers,
Mark

[Rubycocoa-talk] anyone work with toolbars?

[Mark H. <di...@ma...>]

Hi,
The main reasons I want to work with RubyCocoa is the ability to use  
all the nifty cocoa features like toolbars, drawers, and sheets. I've  
been fighting to figure out the whole toolbar thing, but I've gotten  
a bit stuck. I've stuck what I have so far at the end of the message  
(edited somewhat for brevity).

It doesn't work. There is nothing being shown in the toolbar, and it  
seems that the toolbaritems I'm creating never get added to the  
toolbar; calling @main_window.toolbar.items returns an empty NSArray.

Has anyone worked with toolbars under RubyCocoa, who could offer any  
advice (or sample code!)? I'm a bit stuck here at the moment, so  
*any* help would be appreciated.

Here's the code. The calls to breakpoint() are from the ruby- 
breakpoint library, which has helped a lot in figuring out what I have.

-----
class AppController < OSX::NSObject
   include OSX

   ib_outlets :main_window

   def awakeFromNib
     tb = NSToolbar.alloc.initWithIdentifier "main window toolbar"
     tb.setAllowsUserCustomization true
     tb.setAutosavesConfiguration true
     tb.setDisplayMode NSToolbarDisplayModeIconOnly

     tb.setDelegate self
     @main_window.setToolbar tb

     breakpoint
   end

   def nullActionOfDoom(*args)
     puts "Null action of doom!!!!"
     p args
   end

   # --- delegate for toolbar

   def toolbar_itemForItemIdentifier_willBeInsertedIntoToolbar 
(toolbar, itemid, insert)
     if itemid == "install item toolbar item"
       tbi = NSToolbarItem.alloc.initWithItemIdentifier itemid
       tbi.setLabel "Install"
       tbi.setPaletteLabel "Install"
       tbi.setToolTip "Install this item"
       tbi.setImage "NSApplicationIcon"

       tbi.setTarget self
       tbi.setAction :nullActionOfDoom # is this how you replace the  
selector call?

     elsif itemid == "remove item toolbar item"
       tbi = NSToolbarItem.alloc.initWithItemIdentifier itemid
       tbi.setLabel "Remove"
       tbi.setPaletteLabel "Remove"
       tbi.setToolTip "Remove this item"
       tbi.setImage "NSApplicationIcon"

       tbi.setTarget self
       tbi.setAction :nullActionOfDoom
     end
     breakpoint
     tbi
   end

   def toolbarAllowedItemIdentifiers(toolbar)
     breakpoint
     ["install item toolbar item", "remove item toolbar item"]
   end

   def toolbarDefaultItemIdentifiers(toolbar)
     breakpoint
     ["install item toolbar item", "remove item toolbar item"]
   end

   def toolbarDidRemoveItem(notification)        breakpoint end
   def toolbarSelectableItemIdentifiers(toolbar) breakpoint end
   def toolbarWillAddItem(toolbar)               breakpoint end
end

Re: [OT] Re: [Rubycocoa-talk] Install failing, at wit's end

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

On 25 May 2005, at 23:14, Dave Howell wrote:


> Oo! Once you're framework is done, then I can compile a Ruby  
> application and it will actually be a Ruby application, and not 1/3  
> of a program that breaks on anybody's system that doesn't have  
> necessary (but invisible!!) Ruby files?
>

I posted a script to this list about a month ago called  
'standaloneify.rb'. I'm reposting it again now.

It takes a RubyCocoa application you've built with Xcode and removes  
any external dependencies. I didn't hear back from anyone about it,  
so as far as I know it just "works for me".

Excerpt from the header:

# standaloneify.rb
# Takes a built RubyCocoa app bundle (as produced by the
# Xcode/ProjectBuilder template) and copies it into a new
# app bundle that has all dependencies resolved.
#
# usage:
#   ruby standaloneify.rb -d mystandaloneprog.app mybuiltprog.app
#
# This creates a new application that should have dependencies resolved.
#
# The script attempts to identify dependencies by running the program
# without OSX.NSApplicationMain, then grabbing the list of loaded
# ruby scripts and extensions. This means that only the libraries that
# you 'require' are bundled.
#
# NOTES:
#
#  Your ruby installation MUST NOT be the standard Panther install -
#  the script depends on ruby libraries being in non-standard paths to
#  work.
#
#  I've only tested it with a DarwinPorts install of ruby 1.8.2.
#
#  Extension modules should be copied over correctly.
#
#  Ruby gems that are used are copied over in their entirety (thanks  
to some
#  ideas borrowed from rubyscript2exe)
#
#  install_name_tool is used to rewrite dyld load paths - this may  
not work
#  depending on how your libraries have been compiled. I've not had any
#  issues with it yet though.

Re: [OT] Re: [Rubycocoa-talk] Install failing, at wit's end

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

On May 25, 2005, at 1:21 PM, Mark Hubbart wrote:

> The "lurking in a framework" is the part I was getting at.

That's what I figured.

> :) I guess it's fun to make things work properly, though fun isn't the 
> reason for this. Frameworks support being embedded in applications.  
> If you try to distribute an application that you create that was made 
> with your non-apple ruby installation, it will likely not run until 
> the users upgrade their ruby to be the same as yours. Which sucks. 
> With a framework, there are fewer worries.

Oo! Once you're framework is done, then I can compile a Ruby 
application and it will actually be a Ruby application, and not 1/3 of 
a program that breaks on anybody's system that doesn't have necessary 
(but invisible!!) Ruby files?

I wholeheartedly support efforts to enable XCode to make programs that 
actually work right. :)

[OT] Re: [Rubycocoa-talk] Install failing, at wit's end

[Mark H. <di...@ma...>]

On May 25, 2005, at 12:33 PM, Dave Howell wrote:

>
> On May 25, 2005, at 8:48 AM, Mark Hubbart wrote:
>
>
>> mark@eMac% l /Library/Frameworks
>> ...
>> drwxr-xr-x    6 mark  admin   204 May 25 00:25 Ruby.framework
>> mark@eMac% ruby -v -e'puts RUBY_FRAMEWORK_VERSION'
>> ruby 1.8.2 (2004-12-25) [powerpc-darwin8.0.0]
>> 0.5
>> mark@eMac% ls -la `where ruby`
>> lrwxr-xr-x   1 root  wheel  65 May 25 00:42 /usr/bin/ruby -> / 
>> Library/Frameworks/Ruby.framework/Versions/Current/Commands/ruby
>>
>
> [squinting] I think this is telling me that Mark's 'ruby' command  
> lurks in a framework. And that he's running Tiger. K00l.

The "lurking in a framework" is the part I was getting at. After your  
rant about (among other things) self-containedness and drag and drop  
installation, I thought you might find it interesting, since it  
solves those problems in the apple-preferred way.

>>  It's at a point now where I'm eating my own dog food, and it's  
>> almost tasty. :)
>>
>
> [shakes head] I am SO glad there are people out there who think  
> that sort of thing is fun. :)

:) I guess it's fun to make things work properly, though fun isn't  
the reason for this. Frameworks support being embedded in  
applications.  If you try to distribute an application that you  
create that was made with your non-apple ruby installation, it will  
likely not run until the users upgrade their ruby to be the same as  
yours. Which sucks. With a framework, there are fewer worries.

>> Still, Dave, it would be a good idea to get used to the command- 
>> line voodoo.
>>
>
> Aww, c'mon. I've replaced my /usr/bin/ruby with a link to 1.8.2.  
> I've installed TeX, and installed fonts into it (shudder). I've  
> redefined "ls -la" as "dir". I know where my mach kernel is,  my  
> PATH, and my .login file. I'm *used* to command-line voodoo. I just  
> don't *like* it. :) I spend way too much time trying to guess how  
> to make the 'man' command cough up useful answers. [I'd love to  
> spend a little time in a small room with a baseball bat and the guy  
> who thought that making case significant was a good idea.]
>
> There's a Terminal window open most of the time. But the less I  
> have to use it, the happier I am, as a general rule. TextWrangler  
> good, pico bad (do NOT get me started on Emacs or vi. I have not  
> the words for my loathing). Webmin good, apachectl/postfix/rndc  
> bad. (I didn't even know there WAS an rndc until I did 'man named'  
> for this message. Are-en-dee-cee, for pete's sake???) DiskUtility  
> fabulous, diskutil/pdisk/fdisk/bless/whatever frightening.
>
> I hug my perky working (I hope!) RubyCocoa, so that now my Ruby  
> programs can also eschew the command line. smilesmilesmilesmilesmile.
>
> I am often mistaken for a programmer. I'm actually a hard-core  
> applications person. I make my programs work really hard. (I've  
> applescripted Freehand to load PostScript files that I'm writing to  
> the drive as text. Macromedia tech support didn't even know that  
> FreeHand could *be* applescripted. No, not with the UI tools,  
> either.) I program only to make the applications that I need that  
> don't yet exist. (cf. http://grandfenwick.net/dave/applescripts  
> especially Sort&File, iTunes Voice Control, and Chatelaine. Font  
> Undulator isn't listed there, but it's a drag & drop window that  
> takes just about any random font file (Suitcase,  
> LWFN, .pfb, .ttf, .bin) and hammers it into a .dfont or .otf.)
>
> I need to speed up my Mail archiving application, and make a game  
> show display board and a to-do list manager (and I've looked at  
> every existing one I could find, and only TinderBox came close to  
> doing what I needed. But it's not a to do list manager, it's a  
> programming environment. So I'm using Ruby instead).

If you're programming in AppleScript and Ruby, IMHO, you're a  
programmer :) Maybe not by trade, but by habit -- like a lot of  
programmers, myself included.

Anyway, I was just offering another perspective. I learned to like  
the command line, though I started out hating to use it. Once I got  
familiar with man and apropos, learned the terminology, and got  
practice, I realized that it's easier to use it than the gui in many  
cases. However, YMMV, so use what works best for you.

cheers,
Mark

Re: [Rubycocoa-talk] Install failing, at wit's end

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

On May 25, 2005, at 8:48 AM, Mark Hubbart wrote:

> mark@eMac% l /Library/Frameworks
> ...
> drwxr-xr-x    6 mark  admin   204 May 25 00:25 Ruby.framework
> mark@eMac% ruby -v -e'puts RUBY_FRAMEWORK_VERSION'
> ruby 1.8.2 (2004-12-25) [powerpc-darwin8.0.0]
> 0.5
> mark@eMac% ls -la `where ruby`
> lrwxr-xr-x   1 root  wheel  65 May 25 00:42 /usr/bin/ruby -> 
> /Library/Frameworks/Ruby.framework/Versions/Current/Commands/ruby

[squinting] I think this is telling me that Mark's 'ruby' command lurks 
in a framework. And that he's running Tiger. K00l.

>  It's at a point now where I'm eating my own dog food, and it's almost 
> tasty. :)

[shakes head] I am SO glad there are people out there who think that 
sort of thing is fun. :)

> Still, Dave, it would be a good idea to get used to the command-line 
> voodoo.

Aww, c'mon. I've replaced my /usr/bin/ruby with a link to 1.8.2. I've 
installed TeX, and installed fonts into it (shudder). I've redefined 
"ls -la" as "dir". I know where my mach kernel is,  my PATH, and my 
.login file. I'm *used* to command-line voodoo. I just don't *like* it. 
:) I spend way too much time trying to guess how to make the 'man' 
command cough up useful answers. [I'd love to spend a little time in a 
small room with a baseball bat and the guy who thought that making case 
significant was a good idea.]

There's a Terminal window open most of the time. But the less I have to 
use it, the happier I am, as a general rule. TextWrangler good, pico 
bad (do NOT get me started on Emacs or vi. I have not the words for my 
loathing). Webmin good, apachectl/postfix/rndc bad. (I didn't even know 
there WAS an rndc until I did 'man named' for this message. 
Are-en-dee-cee, for pete's sake???) DiskUtility fabulous, 
diskutil/pdisk/fdisk/bless/whatever frightening.

I hug my perky working (I hope!) RubyCocoa, so that now my Ruby 
programs can also eschew the command line. smilesmilesmilesmilesmile.

I am often mistaken for a programmer. I'm actually a hard-core 
applications person. I make my programs work really hard. (I've 
applescripted Freehand to load PostScript files that I'm writing to the 
drive as text. Macromedia tech support didn't even know that FreeHand 
could *be* applescripted. No, not with the UI tools, either.) I program 
only to make the applications that I need that don't yet exist. (cf. 
http://grandfenwick.net/dave/applescripts especially Sort&File, iTunes 
Voice Control, and Chatelaine. Font Undulator isn't listed there, but 
it's a drag & drop window that takes just about any random font file 
(Suitcase, LWFN, .pfb, .ttf, .bin) and hammers it into a .dfont or 
.otf.)

I need to speed up my Mail archiving application, and make a game show 
display board and a to-do list manager (and I've looked at every 
existing one I could find, and only TinderBox came close to doing what 
I needed. But it's not a to do list manager, it's a programming 
environment. So I'm using Ruby instead).

Re: [Rubycocoa-talk] Install failing, at wit's end

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

On May 25, 2005, at 11:22 AM, Dave Howell wrote:

>
> On May 25, 2005, at 3:37 AM, Jonathan Paisley wrote:
>
>>
>> Although that VERSION says 0.4.1, it isn't the 0.4.1 release.
>
> [bangs head against wall]
>
> Oh. My goodness.
>
> All right, let's start by installing a different 0.4.1........

Imagine!

It works.

Hallelujah, the program actually opened a window without error. I'm 
staring at a window.

[I do a little jig of joy.]

The insurmountable obstacle preventing me from completing my headlong 
flight from AppleScript has fallen. On Dasher, on Dancer, on prntcer, 
on Bixen! On cron-et, on Queue-pid, on python-cer, on bzip-sen!

Re: [Rubycocoa-talk] Install failing, at wit's end

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

On May 25, 2005, at 3:37 AM, Jonathan Paisley wrote:

>
> Although that VERSION says 0.4.1, it isn't the 0.4.1 release.

[bangs head against wall]

Oh. My goodness.

All right, let's start by installing a different 0.4.1........

Re: [Rubycocoa-talk] Install failing, at wit's end

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

On May 25, 2005, at 3:29 AM, Jonathan Paisley wrote:

> You say 'some of the files required to boot the system' - these aren't 
> just files required to boot the system: the system *depends* on lots 
> of BSD stuff in the standard unix directories, both when booting and 
> during normal use.

I know. How painfully I know. Sigh.

> I realise you may not care, but... the reason the AppleScript doesn't 
> work but using osascript does is due to the way the PATH environment 
> variable works. The PATH is inherited from the process that starts a 
> given program. So, in the AppleScript example, the PATH comes via 
> Script Editor (for example), which is eventually rooted in the 
> LoginWindow process. Compare this with running from a terminal, where 
> the PATH has been updated by whatever commands you needed to add to 
> make this happen. The 'osascript' command sees this updated PATH, and 
> therefore knows where to find the appropriate ruby.

I know why it does that. The nastiness is that it makes debugging 
vastly worse, when what happens on "my" command line is often but not 
always the same as what happens at AppleScript's command line. Oh, 
well. (And finding the 'whereis' command frequently refusing to answer 
the question doesn't help. Grr.)

> I'm sorry to say that this boils down again to the difference between 
> the Mac and Unix ways of doing things. Ruby is not yet ready for the 
> Mac way.

Note that I agreed with this! I am, however, quite comforted that you 
seem to agree, generally, with the observation that it isn't the Mac 
way, even if it is a bit soon to expect it to be so. :)

Re: [Rubycocoa-talk] Install failing, at wit's end

[Mark H. <di...@ma...>]

On May 25, 2005, at 3:29 AM, Jonathan Paisley wrote:

>
> On 25 May 2005, at 10:40, Dave Howell wrote:
>
>
>>> You say that it's stupid to put things in an invisible folder on  
>>> a mac. I'd argue that this is only the case if the items in  
>>> question are intended to be used from the GUI. ruby is not. The  
>>> RubyCocoa applications you may create should be GUI-accessible,  
>>> but this doesn't mean that ruby itself should be.
>>>
>>
>> [Danger. Rant approaching...]
>>
>
> :)
>
>
>> I must respectfully disagree. The pinnacle of good design, as  
>> Apple's guidelines support and I wholeheartedly endorse, is seen,  
>> in part, when "installation" of an application involves dragging  
>> it onto my hard drive, and de-installing involves dropping a  
>> folder in the trash. Ruby's log file belongs in Ruby's folder (or  
>> arguably in [~|]/Library/Logs/). Ruby's documentation definitely  
>> belongs in Ruby's folder. I found a RubyCocoa.framework in / 
>> Library/Frameworks, exactly where I'd expect to find such a thing,  
>> and where a Splat-F Find will turn it up.  If something isn't  
>> working right, I should be able to hunt down folders and files  
>> with my mouse, not by having to open a terminal and start digging  
>> around in a foreign environment with unknown command line voodoo.  
>> (Or by starting the process via Shift-Command-G and typing the  
>> initial path.)
>>
>
> I very much agree with the principle of drag installation and  
> deinstallation. However, converting a well-established unix tool  
> (ruby) to work like this is non-trivial. Since it hasn't been done  
> yet, we have to work with the existing system.

mark@eMac% l /Library/Frameworks
total 16
drwxrwxr-x    6 root  admin   204 May 25 00:23 .
drwxrwxr-t   47 root  admin  1598 May 25 00:23 ..
-rw-rw-r--    1 mark  admin  6148 May 24 23:47 .DS_Store
drwxr-xr-x    7 mark  admin   238 May 25 00:08 Readline.framework
drwxr-xr-x    6 mark  admin   204 May 25 00:25 Ruby.framework
drwxrwxr-x    6 root  admin   204 May 12 21:33 StuffIt.framework
mark@eMac% ruby -v -e'puts RUBY_FRAMEWORK_VERSION'
ruby 1.8.2 (2004-12-25) [powerpc-darwin8.0.0]
0.5
mark@eMac% ls -la `where ruby`
lrwxr-xr-x   1 root  wheel  65 May 25 00:42 /usr/bin/ruby -> /Library/ 
Frameworks/Ruby.framework/Versions/Current/Commands/ruby

> Apple have done their own work on making Python more mac-friendly.  
> The whole of Python lives in a framework, and symlinks from /usr/ 
> bin into the framework allow command-line tools to find it easily.  
> This could be done with Ruby, but as far as I'm aware, it hasn't  
> been tackled yet.

It's a little slow going, but it's being tackled. It's at a point now  
where I'm eating my own dog food, and it's almost tasty. :) The focus  
is on maximum containment, with no files being external to the  
framework and support dirs (/Library/Frameworks/Ruby.framework and / 
Library/Ruby). Eventually, Drag and drop installation will be  
possible, and there will be a gui app included to do any configuration.

Still, Dave, it would be a good idea to get used to the command-line  
voodoo. All it takes is practice, and you will gain a much wider  
understanding of how things work under the hood of OSX. I agree that  
we need to move towards self-contained drag-and-drop installable  
frameworks and applications, but I don't see Apple getting to that  
point any time soon. They make small advances with each OS release,  
but I shudder to think of the development costs that would be  
required to get it all done at once (and for only minimal return on  
investment). At the moment, though, almost all the core OS  
functionality is based around /bin /var /etc and /dev.

Anyway, I couldn't resist plugging the framework into this thread. :)  
It's almost ready for a preview release, contact me off-list if you  
want to test-drive it when it's ready.

cheers,
Mark

Re: [Rubycocoa-talk] Install failing, at wit's end

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

On 25 May 2005, at 10:45, Dave Howell wrote:

> But it is RubyCocoa 0.4.1 that I installed. . . .
>
> From file VERSION
>
> VERSION = "0.4.1"
> STAGE = "devel-panther"
> RELEASE_DATE = "2003-12-04"
>
> I have no idea what "branch-devel-panther was merged to trunk" means.
>

Although that VERSION says 0.4.1, it isn't the 0.4.1 release. You've  
checked out an old version of the code that was used for working on  
initial Panther support.

The VERSION file for 0.4.1 release looks like this:

VERSION = "0.4.1"
STAGE = ""
RELEASE_DATE = "2005-03-25"

Probably easiest to go with the 0.4.1 source tar:

http://prdownloads.sourceforge.net/rubycocoa/rubycocoa-0.4.1.tgz? 
download