Do you really mean this? As far as I've heard,
Apple's official
stance has never been to classify Carbon as a legacy
technology
(though they've certainly taken all the steps). Can we
finally settle
this issue and start calling things as they are?
Of course there is the whole issue of
On Sat, Nov 1, 2008 at 11:35 PM, Rakesh Singhal
[EMAIL PROTECTED] wrote:
Do I need to change the existing code (Windows code) very much. I have not
used Qt before this. Does Qt support the MFC?
If your code is written for MFC, then any code that depends on it will
require
Rakesh Singhal wrote:
I do not know about porting Windows code (MFC based) to Mac OS. The existing
code is written in C++. As suggested that it is possible then how to do it?
Do I need to change the existing code (Windows code) very much. I have not
used Qt before this. Does Qt support the MFC?
Have you seen http://doc.trolltech.com/solutions/qtwinmigrate/index.html ?
If you need a hand then drop me a line, I have been coding with Qt for the
last 6 years, using it on Mac and Windows. I guess starting from scratch is
somewhat of a sledge hammer solution, but if you really want a native
On Nov 1, 2008, at 8:23 AM, Rakesh Singhal wrote:
Thanks Andy. I do not need to port to Qt but it is good to know. I
will have
to write it from scratch using Carbon C++ application template. The
given
link is very useful.
Use Cocoa, not Carbon. Carbon is not (and will not) be supported
On Sat, Nov 1, 2008 at 12:18 PM, Bill Bumgarner [EMAIL PROTECTED] wrote:
Carbon is a legacy technology. Cocoa is the focus of all future
development.
Do you really mean this? As far as I've heard, Apple's official
stance has never been to classify Carbon as a legacy technology
(though they've
On 30.10.2008, at 23:49, Stefan Werner wrote:
You are aware that MFC (1992) is younger than NextStep (1988)? ;-)
Well, not many of the '88 classes are around in today's Cocoa. The
move from NX to NS changed things a lot, so we really don't have much
from '88 left.
And if age is a
On Nov 1, 2008, at 1:33 PM, Kyle Sluder wrote:
Do you really mean this? As far as I've heard, Apple's official
stance has never been to classify Carbon as a legacy technology
(though they've certainly taken all the steps). Can we finally settle
this issue and start calling things as they are?
On 01.11.2008, at 16:23, Rakesh Singhal wrote:
Thanks Andy. I do not need to port to Qt but it is good to know. I
will have
to write it from scratch using Carbon C++ application template. The
given
link is very useful.
Don't use Carbon for GUI work. HIToolbox, the GUI part of Carbon, is
Le 30 oct. 08 à 23:49, Stefan Werner a écrit :
I would also recommend that you start over with the design of your
GUI, for
the sensibilities and design principles of Mac OS X are very
different. This
difference is exacerbated if you consider the age of MFC...
You are aware that MFC
On Oct 31, 2008, at 1:21 AM, Jean-Daniel Dupas wrote:
Le 30 oct. 08 à 23:49, Stefan Werner a écrit :
I would also recommend that you start over with the design of your
GUI, for
the sensibilities and design principles of Mac OS X are very
different. This
difference is exacerbated if you
Hi all
I have to port a project form windows to Mac. The existing code is in
C++ and classes are inherited from MFC library classes. Do I have any
alternative for MFC in MAC OS?
I have gone through some posting on Apple lists and I found that there
are 2 cross-platform tools Power Plant and Code
Do I have any
alternative for MFC in MAC OS?
No.
I have gone through some posting on Apple lists and I found that there
are 2 cross-platform tools Power Plant and Code Warrior.
CodeWarrior was a suite of tools, which was discontinued years ago, and
never supported Intel Macs.
PowerPlant
Check out this article on Apple's web site:
http://developer.apple.com/documentation/Porting/Conceptual/win32porting/win32porting.html
Essentially, CodeWarrior, for Mac development, should not be considered for new
development (I have to use it for a legacy product, and there's lots of
***DO NOT*** expect that it's merely a matter of finding the corresponding
Mac API call for each Windows API call--the differences run deeper than
that. In order to be successful, you ***WILL*** have to learn to be a Mac
developer, period, no shortcuts.
Don't let that scare you. It's easier than
wax sentimental='true'Ah, CodeWarrior. I first cut my coding teeth on
that ol' app. What an experience it was to actually design my own apps.
Those were the days./wax
OK, so I actually used gcc before that, but still
I have to agree with Gary on this one. I have ported over a few
On Oct 30, 2008, at 12:49 PM, Gary L. Wade wrote:
Check out this article on Apple's web site:
http://developer.apple.com/documentation/Porting/Conceptual/win32porting/win32porting.html
Essentially, CodeWarrior, for Mac development, should not be
considered for new development (I have to
Amen.
Codewarrior is dead, long live Xcode. (I still mourn CodeWarrior, but
what's past is past.)
I did some work with MFC a couple of years ago, and thought it was
pretty nice (not elegant, but productive). Now, I am trying to port
my Cocoa app to Windows, and for various reasons
On Oct 30, 2008, at 8:31 AM, Rakesh Singhal wrote:
I have to port a project form windows to Mac. The existing code is in
C++ and classes are inherited from MFC library classes. Do I have any
alternative for MFC in MAC OS?
I have gone through some posting on Apple lists and I found that there
I haven't done any porting between the two platforms, but I have worked with
both for some time.
It's not easy to port such an application and be prepared to rewrite most of
the code (not counting the learning curve). All the GUI stuff, you have to
separate from the model, in order to have a
On 30 okt 2008, at 08.31, Rakesh Singhal wrote:
Hi all
I have to port a project form windows to Mac. The existing code is in
C++ and classes are inherited from MFC library classes. Do I have any
alternative for MFC in MAC OS?
I have gone through some posting on Apple lists and I found that
On Oct 30, 2008, at 3:14 PM, Tommy Nordgren wrote:
I suggest you port your app to use the Qt framework from TrollTech
(http://www.trolltech.com) It is implemented in C++, and the native
layer
on Mac OS X is implemented using Carbon and Cocoa.
You might have to implement some
I would also recommend that you start over with the design of your
GUI, for
the sensibilities and design principles of Mac OS X are very
different. This
difference is exacerbated if you consider the age of MFC...
You are aware that MFC (1992) is younger than NextStep (1988)? ;-)
And if
You are aware that MFC (1992) is younger than NextStep (1988)? ;-)
I was mostly referring to the Mac OS X user interface...,
And if age is a criteria, we should always prefer Carbon over Posix.
True :)
- Nick
email: [EMAIL PROTECTED]
twitter: macsphere
There are many great examples of well-made cross-platform apps out
there.
One of the best examples I've seen, even in terms of code and
organization.. VLC player!
It's open source so you can see how they manage things.
___
Cocoa-dev mailing list
25 matches
Mail list logo