Ok, I get it. You apparently missed the main point of having a Cocoa
framework. You said: "RB could be using a mostly Cocoa framework now
-- how would we know? What RB uses under the hood is an internal
implementation detail." But this is just wrong.
What are all of the .Handle properties on controls, windows, and
graphics contexts? Are those "internal implementation details"? No.
They're exposed for a reason: Declares. The main point of having a
Cocoa framework is that you can use declares to customize your app
for Mac-only features.
- If REALbasic is using native Cocoa views (NSTextView, NSTableView/
NSOutlineView, NSButton...) then you can easily customize those views
with declares.
- If REALbasic doesn't have an implementation for a certain view, you
can just drop it in straight from Cocoa using a declare. "You need a
PDF view in REALbasic? Oh no problem. Just add the Cocoa view to your
window. Thanks Cocoa." Couldn't do that with the existing Carbon
framework (not in 10.4 anyway). "Need you text view to handle images?
No problem. NSTextView does it. Just use some relatively simple
declares to handle that and use REALbasic for everything else." You
can't do that with the existing Carbon framework.
Additionally, if there's standard behavior some of these views
exhibit that REALbasic does not (and sometimes cannot), with a Cocoa
framework you'd get those behaviors. For example Option-[Forward]
Delete to delete a word in a text view is a standard OS feature.....
That REALbasic does not have. You'd get that for free.
Plus, there are some controls which aren't even implemented by
Carbon. ComboBox, BevelButton... I know there are more hiding out
there. How long did it take to get a semblance of a real control out
of ComboBox? Sure we have it now, but what about future controls?
Will we have to wait another year just for RS to get be able to
mostly mimic it?
Come on..... surely you can see the benefits of this.
Not to mention, if custom REALbasic objects were internally
subclasses of NSObject and they exposed the ability to implement Obj-
C methods, then we could have REALbasic objects acting as delegates
to _any_ Cocoa object, or even be a subclass of one. I could set up a
connection to over Cocoa's distributed object architecture and talk
to iChat all in RB code using some declares.
And if you want to get in to future technology, how on earth is RS
going to support Core Animation? It's Cocoa only. They'd be _forced_
to use Cocoa. We can't even use NSViewAnimation as it is now. There
are new controls in every OS release that are all being added to
Cocoa. There's a new one in 10.5 I really want to use, but with
REALbasic it's impossible. But I could do it with a simple declare.
This is all stuff that cannot be done right now without waiting for
RS, reinventing the wheel, or (for the few things that are possible)
going through a boatload of work.
Those of us who are loudly demanding a Cocoa framework are *well
aware* that we don't magically get new classes and objects for free.
Don't think we're so foolish. We know what it means and we're excited
by the possibilities.
--
Seth Willits
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
