Re: TrollTech releases QT for Mac under GPL
Re: TrollTech releases QT for Mac under GPL
- Subject: Re: TrollTech releases QT for Mac under GPL
- From: Don Yacktman <email@hidden>
- Date: Sat, 21 Jun 2003 19:02:24 -0600
On Saturday, June 21, 2003, at 06:11 PM, Greg Weston wrote:
On Saturday, June 21, 2003, at 05:25 PM, Jeff Harrell wrote:
Not going to happen. When Apple made the promise of YB/Win, I never
could figure out what the business case for that, apart from a sudden
urge to satisfy suicidal tendencies.
Uh. The business case is to allow Apple and Apple developers to write
applications that can be deployed on Windows, and to give Windows
developers an API through which they can write applications that can
be
deployed on the Mac.
The first one is key for things like iTunes, and the second one is
good
for everybody. Windows programmers get a better toolkit, and Mac users
get the benefit of more applications.
The business case seems clear. What am I missing?
The problem is the danger of it undercutting Mac sales, and Apple isn't
willing to take that risk -- and I can't blame them for that. It's an
awfully big risk to take. (Of course I wish that weren't the case. I
still find it quite irritating that Apple reneged on that promise.)
An explanation of exactly how it's in Apple's best interests to give
Windows developers a better toolkit when there's absolutely no promise
that Mac builds would arise. And you can't say "but why wouldn't they
because the Mac builds would be 'free'" because:
a) We've all seen people turn down good ideas for bad reasons.
Yeah, they'd pretty much have to set up a runtime licensing policy that
requires that a Mac version be produced. Like "if you use Cocoa on
Windows, part of the cost of doing so is that you are required to
produce a Macintosh build as well." Or even making it so that the
toolset just always creates a Mac version of the app when you click
build, not even offering the way of building for Windows only.
In fact, if they wanted YB to be a profit center (which is probably the
only way you could convince them to do it at all) then I could see a
stipulation like this: you have to release a Mac product first, and
have it be exclusive to the Mac for x number of months and/or you have
to pay a per copy runtime fee as a royalty on every copy of your app,
but of course, no royalty fee for copies of the Mac version so that the
Mac version is cheaper (or else offers a better profit margin).
That would unfortunately probably be more than enough to discourage use
of Cocoa by typical Windows developers, or in other words, everyone but
the Mac diehards that are already using it. (Of course, the diehards
wouldn't mind, because just being able to use Cocoa at all to build
apps that can be sold in the Windows market would make a lot of us very
happy.) But only having Mac people use it, instead of a broader
developer base, is a shame, because if you could create a situation
where the latest software technology always came out first on a Mac and
always costs less on the Mac, that would be a nice way to shift public
perception of the value of using the platform... (right now that's
still somewhat true, even if people tend to ignore it, but if it were
indisputably true for a lot more stuff, wouldn't that be nice!)
Well, it's a fun thought exercise, but I seriously doubt it's ever
going to happen.
b) It's not free. TCP-enablement is almost de rigeur for any app that
might possibly have something to gain from it. Now say the phrase
"endian issues."
With Cocoa, it really is "for free". If you're using Cocoa right,
endian issues shouldn't be cropping up. The old NeXT environment
really did work as a one-click cross platform system. You could build
for 68k, HPPA, Sparc, and x86 just by selecting the checkboxes for the
architectures you wanted. That simple. I only had an m68k machine for
a while, but my beta testers _never_ found a cross platform problem
with anything I built on that machine. I just handed them the built
app and it just worked. It was amazing, and it was a while before I
trusted it because it was so amazing. But it got to the point where I
would have been surprised if something hadn't worked!
So waving cross platform issues as a reason YellowBox couldn't work
isn't a good reason in my book. The same team pulled it off once
before, I see no reason that they couldn't do so again if they felt it
was in their best interests to do so.
It should be noted, btw, that before the NeXT merger Apple already had
a surprisingly good cross-platform toolkit: QuickTime. Not _as_good_
as YB would have been, not least because it wasn't supported as a
general-use API but it did work.
And before the merger, NeXT had an even better, more complete, cross
platform toolkit. So obviously both companies had the expertise, so
the combined forces of both teams should be able to work miracles, I'd
think. From a technical standpoint, it can be done. It's all a matter
of whether or not it's worth the trouble...ie, all the non-technical
factors, and those are the part that is overwhelming.
--
Later,
Don Yacktman
email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.