[feature request] open url in browser
Here is what I had to do after Laurent showed me how to open an URL in the browser: NSWorkspace.sharedWorkspace.openURL(NSURL.URLWithString("http://google.com") I wish this would be wrapped in a simpler way. open_url_in_browser("http://google.com") open_file_in_browser("./resources/schedule.html") (I guess there is way to open a pdf without having to use the browser) -Matt
Hi, I like the idea of HotCocoa, but it should not go too far, and this is maybe taking it one step too far imo. The problem is that at some point you _will_ have to use real Cocoa, because HotCocoa can't wrap everything. If you are frightened by the verbosity of this line of code, well than working with edge cases in Cocoa will give you nightmares. Maybe this is actually not an edge case, because a lot of people might use this method. But my point is that MacRuby & HotCocoa should not teach the users how to _not_ use Cocoa, but simply provide shortcuts for the majority of simpler cases. Eloy On 9 nov 2008, at 10:41, Matt Aimonetti wrote:
Here is what I had to do after Laurent showed me how to open an URL in the browser:
NSWorkspace.sharedWorkspace.openURL(NSURL.URLWithString("http://google.com ")
I wish this would be wrapped in a simpler way.
open_url_in_browser("http://google.com") open_file_in_browser("./resources/schedule.html") (I guess there is way to open a pdf without having to use the browser)
-Matt
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
hmm I guess I disagree but since I just got started with MacRuby and don't know Cocoa I might be totally wrong. My hope is to have all the common cocoa methods available in Ruby so I can quickly create simple apps without always having to dig into the cocoa documentation and create this kind of super long/not so obvious method calls. -Matt On Sun, Nov 9, 2008 at 10:13 AM, Eloy Duran <eloy.de.enige@gmail.com> wrote:
Hi, I like the idea of HotCocoa, but it should not go too far, and this is maybe taking it one step too far imo. The problem is that at some point you _will_ have to use real Cocoa, because HotCocoa can't wrap everything. If you are frightened by the verbosity of this line of code, well than working with edge cases in Cocoa will give you nightmares. Maybe this is actually not an edge case, because a lot of people might use this method. But my point is that MacRuby & HotCocoa should not teach the users how to _not_ use Cocoa, but simply provide shortcuts for the majority of simpler cases.
Eloy
On 9 nov 2008, at 10:41, Matt Aimonetti wrote:
Here is what I had to do after Laurent showed me how to open an URL in the browser:
NSWorkspace.sharedWorkspace.openURL(NSURL.URLWithString("http://google.com ")
I wish this would be wrapped in a simpler way.
open_url_in_browser("http://google.com") open_file_in_browser("./resources/schedule.html") (I guess there is way to open a pdf without having to use the browser)
-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
On 9 nov 2008, at 16:19, Matt Aimonetti wrote:
hmm I guess I disagree but since I just got started with MacRuby and don't know Cocoa I might be totally wrong.
Yes, this is what I thought too when first starting with Cocoa in RubyCocoa, but I was very wrong. Most helpful docs/references are either from Apple or by googling for other source etc which are all in Objective-C. Now imagine everything would be wrapped and abstracted away from MacRuby users, then all these resources out on the web are useless… For instance, the RubyCocoa syntax, is imo very easy to read compared to what the Apple references mention, however even this was too hard to understand for a lot of starting users.
My hope is to have all the common cocoa methods available in Ruby so I can quickly create simple apps without always having to dig into the cocoa documentation and create this kind of super long/not so obvious method calls.
I would really hope HotCocoa will not aspire to wrap everything, except for where it _really_ makes sense. And my advice to you would be to re-evaluate this after you have had the chance to really do something with Cocoa. Cheers, Eloy
While I agree that HotCocoa should not aspire to wrap all APIs, I think that providing a mapping file for NSWorkspace is nevertheless a good idea. #workspace could return the shared workspace by default (I'm not even sure if you can get a different workspace instance) then we could create a custom #open method. workspace.open('http://google.com') Thoughts? Laurent On Nov 9, 2008, at 10:30 AM, Eloy Duran wrote:
On 9 nov 2008, at 16:19, Matt Aimonetti wrote:
hmm I guess I disagree but since I just got started with MacRuby and don't know Cocoa I might be totally wrong.
Yes, this is what I thought too when first starting with Cocoa in RubyCocoa, but I was very wrong. Most helpful docs/references are either from Apple or by googling for other source etc which are all in Objective-C.
Now imagine everything would be wrapped and abstracted away from MacRuby users, then all these resources out on the web are useless…
For instance, the RubyCocoa syntax, is imo very easy to read compared to what the Apple references mention, however even this was too hard to understand for a lot of starting users.
My hope is to have all the common cocoa methods available in Ruby so I can quickly create simple apps without always having to dig into the cocoa documentation and create this kind of super long/not so obvious method calls.
I would really hope HotCocoa will not aspire to wrap everything, except for where it _really_ makes sense. And my advice to you would be to re-evaluate this after you have had the chance to really do something with Cocoa.
Cheers, Eloy
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
How would that work to open a local file? -Matt Sent from my iPhone On Nov 9, 2008, at 14:53, Laurent Sansonetti <lsansonetti@apple.com> wrote:
While I agree that HotCocoa should not aspire to wrap all APIs, I think that providing a mapping file for NSWorkspace is nevertheless a good idea.
#workspace could return the shared workspace by default (I'm not even sure if you can get a different workspace instance) then we could create a custom #open method.
workspace.open('http://google.com')
Thoughts?
Laurent
On Nov 9, 2008, at 10:30 AM, Eloy Duran wrote:
On 9 nov 2008, at 16:19, Matt Aimonetti wrote:
hmm I guess I disagree but since I just got started with MacRuby and don't know Cocoa I might be totally wrong.
Yes, this is what I thought too when first starting with Cocoa in RubyCocoa, but I was very wrong. Most helpful docs/references are either from Apple or by googling for other source etc which are all in Objective-C.
Now imagine everything would be wrapped and abstracted away from MacRuby users, then all these resources out on the web are useless…
For instance, the RubyCocoa syntax, is imo very easy to read compared to what the Apple references mention, however even this was too hard to understand for a lot of starting users.
My hope is to have all the common cocoa methods available in Ruby so I can quickly create simple apps without always having to dig into the cocoa documentation and create this kind of super long/ not so obvious method calls.
I would really hope HotCocoa will not aspire to wrap everything, except for where it _really_ makes sense. And my advice to you would be to re-evaluate this after you have had the chance to really do something with Cocoa.
Cheers, Eloy
_______________________________________________ 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 Nov 9, 2008, at 7:13 AM, Eloy Duran wrote:
I like the idea of HotCocoa, but it should not go too far, and this is maybe taking it one step too far imo. The problem is that at some point you _will_ have to use real Cocoa, because HotCocoa can't wrap everything. If you are frightened by the verbosity of this line of code, well than working with edge cases in Cocoa will give you nightmares. Maybe this is actually not an edge case, because a lot of people might use this method. But my point is that MacRuby & HotCocoa should not teach the users how to _not_ use Cocoa, but simply provide shortcuts for the majority of simpler cases.
I'm glad you opened this discussion since I think HotCocoa is likely to undergo something of a prolonged identity crisis unless we decide fairly early on just what it's trying to achieve. To my way of thinking, if all HotCocoa does is provide "shortcuts" like Eloy is suggesting then we probably shouldn't even bother going further in the direction we're going since it's basically just a glorified macro pre-processor and we should be trying to define just how the "macros" (or "mappings") work, documenting the process of creating them, and providing just a few examples in order to illustrate how they can be used. It would also be a reasonable assumption that these mappings should be tied to the application itself, not stored in some central location (as they are currently), since applications would be creating them on an individual basis in order to shortcut their own frequently used Cocoa idioms. Sure, we might have some collection of reasonable "system mappings", but just as you wouldn't provide /bin/cpp with hundreds of canned macros for general purpose use, we would not take HotCocoa in any particularly complicated directions, it would really be about creating and supporting the notion of mappings. That's assuming that all the value of HotCocoa is in the mapping creation and management process, of course. Speaking just for myself, I don't see enough real value in going much further with HotCocoa if that's the objective. The real value, as I see it, is in creating useful abstractions "above" Cocoa for simplifying complex or difficult- to-learn operations, like basic UI or higher-level graphics / animation primitives (think "Logo" if you need a point of comparison). If that is our objective then we should make that clear, also deciding whether or not it's worth adding mappings for things like NSUrl and NSWorkspace if those classes are already fairly easy to use (and I don't know if they really are, I'm just continuing to use them as examples) since Eloy is right in saying that there' no point in "wrapping everything" - we have to focus on the high value/high reward targets if it's true convenience and rapid development we're aiming at. So, which is it, guys? A glorified macro pre-processor with enough canned macros to illustrate how to use the same approach in your own applications, or an attempt to simplify Cocoa programming where it genuinely cries out for simplification, hopefully also in cases which are commonly used enough to generate real bang-for-buck? - Jordan
So, which is it, guys? A glorified macro pre-processor with enough canned macros to illustrate how to use the same approach in your own applications, or an attempt to simplify Cocoa programming where it genuinely cries out for simplification, hopefully also in cases which are commonly used enough to generate real bang-for-buck?
Rich, Laurent and I talked about this at length this weekend, and I think we can safely say that we’d to improve upon Cocoa and Mac OS X development in Ruby. One example we cooked up was this: play_sound do |t| sin(440.0 * t * 2.0 * Math::PI) end Setting up a simple CoreAudio configuration is a pain; you need to dive into the component manager, and wire together a bunch of callbacks and audio units, and…ugh. In HotCocoa we have a chance to make audio generation into a nice simple operation. We had plenty more ideas; I’m sure they’ll be shared in this forum when we all get caught up on the rest of our lives. -Ben
On Nov 9, 2008, at 8:57 PM, Benjamin Stiglitz wrote:
Rich, Laurent and I talked about this at length this weekend, and I think we can safely say that we’d to improve upon Cocoa and Mac OS X development in Ruby.
One example we cooked up was this:
play_sound do |t| sin(440.0 * t * 2.0 * Math::PI) end
Yeah, that's exactly the sort of thing I'd hoped HotCocoa would be able to provide: Something so easy that an entirely new segment of programmers (or "artist cum programmers") will find their creativity more easy to express (and that's kind of what "it's all about" in many aspects of what we offer, I daresay). - Jordan
By the way, I did a quick demo of HotCocoa for Matz and he was pretty impressed. He even said: "I will have to play with that when I will buy a Mac ;)" First I was totally shocked(in a good way) to hear that Matz is considering buying a Mac and then I was like.... wow, if Matz sees something in HotCocoa, it's that there is really something there. I think what Matz liked from my quick demo was the fact Rich and Laurent kept the Ruby spirit. In other words: "use Ruby and have fun playing with your code". -Matt On Mon, Nov 10, 2008 at 2:00 AM, Jordan K. Hubbard <jkh@apple.com> wrote:
On Nov 9, 2008, at 8:57 PM, Benjamin Stiglitz wrote:
Rich, Laurent and I talked about this at length this weekend, and I think
we can safely say that we'd to improve upon Cocoa and Mac OS X development in Ruby.
One example we cooked up was this:
play_sound do |t| sin(440.0 * t * 2.0 * Math::PI) end
Yeah, that's exactly the sort of thing I'd hoped HotCocoa would be able to provide: Something so easy that an entirely new segment of programmers (or "artist cum programmers") will find their creativity more easy to express (and that's kind of what "it's all about" in many aspects of what we offer, I daresay).
- Jordan
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
The result we're looking for (IMHO) is a way to write Cocoa apps that "look right" to Ruby programmers. The number of Objective-C programmers who don't work on OSX apps is vanishingly small. By opening up OSX programming to MacBook-carrying Rubyists, Apple can grow its developer base in relatively short order. Jordan's "artist cum programmer" folks may follow along, but the Rubyists (and some book authors) will have to pave the way. More than one step will be needed to bridge the gap between ObjC- based OSX programming and the Ruby crew. First, we need a Ruby implementation with direct, efficient access to OSX functionality. For example, it should be straightforward to read about the ObjC API and then code up the appropriate MacRuby call(s). MacRuby is expected to provide this implementation. However, this means that MacRuby code is going to look a lot like transliterated ObjC. Java and Objective-C programmers are inured to their languages' verbosity (and downright inconvenience), so they may not understand how WRONG this code looks to a Rubyist: "Programming in TSO is like kicking a dead whale down the beach" -- Ken Thompson The first step in making MacRuby look reasonable to a Rubyist is to reduce the verbosity of method names and arguments, fill in common defaults, etc. I see no problem with letting HotCocoa do this, if it does so in a well-documented and -engineered fashion. I would also be delighted to have HotCocoa provide high-level abstractions for Cocoa (etc) functionality, cute ways to lay out windows programmatically, etc. My only real concern is that it may become unwieldy, because it is trying to do too much. So, I might suggest a bit more modularity, along the lines of Merb... -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 Technical editing and writing, programming, and web development
The result we're looking for (IMHO) is a way to write Cocoa apps that "look right" to Ruby programmers. The number of Objective-C programmers who don't work on OSX apps is vanishingly small.
By opening up OSX programming to MacBook-carrying Rubyists, Apple can grow its developer base in relatively short order. Jordan's "artist cum programmer" folks may follow along, but the Rubyists (and some book authors) will have to pave the way.
More than one step will be needed to bridge the gap between ObjC- based OSX programming and the Ruby crew. First, we need a Ruby implementation with direct, efficient access to OSX functionality. For example, it should be straightforward to read about the ObjC API and then code up the appropriate MacRuby call(s). MacRuby is expected to provide this implementation.
However, this means that MacRuby code is going to look a lot like transliterated ObjC. Java and Objective-C programmers are inured to their languages' verbosity (and downright inconvenience), so they may not understand how WRONG this code looks to a Rubyist:
That's simply because at that time they don't know any better. But real rubyists will educate themselves is my experience.
"Programming in TSO is like kicking a dead whale down the beach"
-- Ken Thompson
The first step in making MacRuby look reasonable to a Rubyist is to reduce the verbosity of method names and arguments, fill in common defaults, etc. I see no problem with letting HotCocoa do this, if it does so in a well-documented and -engineered fashion.
Well actually there are a few problems with this: - First of all, it would mean hundreds of man hours to create basically just shortcuts, and then also need to be maintained. - Then there's the documentation part, you say “if it does so in a well-documented and -engineered fashion”. Which means: Someone will have to write documentation for the shortcuts _again_ because the docs already exist in Apple's Cocoa reference docs. Honestly, nobody would want to do that. Apple has a much better track record for keeping their docs up to date. - Then there's the point I tried to make earlier, but apparently failed at: Say, hypothetically, that all of Cocoa would be wrapped in shortcuts and even docs would exist. Then at some point I would like to start using other OSS Objective- C code, should I ask the maintainers to write shortcuts for that as well? Or should I simply take the effort to learn the syntax used by idiomatic Objective-C? Which really only takes 1 afternoon. Just to restate the last point: Smart rubyists _will_ be able to figure out how to use Objective-C classes in 1 afternoon, I have seen it happen many many times over the past years that I have been active in the RubyCocoa area. (Lazy people don't. But my guess is this applies in all areas.) After using it for a while, they _will_ figure out that it was best option to learn some Objective-C and cherish the big API and it's documentation provided by Apple. And let's not forget the wealth of info available through Google, all in Objective-C and it's verbose syntax.
I would also be delighted to have HotCocoa provide high-level abstractions for Cocoa (etc) functionality, cute ways to lay out windows programmatically, etc. My only real concern is that it may become unwieldy, because it is trying to do too much. So, I might suggest a bit more modularity, along the lines of Merb...
Like stated before, I hope HotCocoa will _only_ provide high level abstractions and maybe some shortcuts. Not the other way around. To put this all in perspective: - I am a rubyist pur sang, not a Java/Objective-C programmer, and never used Cocoa before RubyCocoa. - I too thought it would be a good idea to create ruby like syntax abstractions around all of Cocoa, but have realized after actually doing stuff that that would have been a cumbersome task. And more importantly, it would not have taught me to educate myself where needed. - Eloy
participants (6)
-
Benjamin Stiglitz
-
Eloy Duran
-
Jordan K. Hubbard
-
Laurent Sansonetti
-
Matt Aimonetti
-
Rich Morin