Re: Porting from Windows to Mac
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 What is Carbon?. Perhaps you are restricting your classification to things like HIToolbox? If you can't compile it for 64 bit architecture, then its legacy. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 re-writing---regardless of the approach you choose. Qt is one of many UI frameworks that allow cross-platform development (personally, I prefer GTK+). However, if your code is already written against the MFC framework, then you will need to re-write your UI code. Coding against a framework like Qt makes maintence of the code easier, but doesn't help you much if you already have a large existing codebase written for another framework. Phil ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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? To answer your last question, No. Qt is a widget toolkit that serves the same purpose of MFC, but does so in a very different way, and unlike MFC is inherently cross-platform. You will basically need to rewrite the program from scratch. There is no tool that will automagically turn the MFC code in the application into something that will work on Mac OS X or anything other than Windows. Even a few seconds using Google would have answered your questions. Jason Regards On Fri, Oct 31, 2008 at 4:01 AM, Bill Bumgarner [EMAIL PROTECTED] wrote: 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 modules in your app differently depending on target OS, particularly to get native look and feel. The most important thing with using Qt, is that you will be able to port your app to any unix dialect that uses X windows, as well. Qt is good stuff, but be very careful going down this path. While Qt applications are very portable, the Macintosh Qt apps tend to stick out like sore thumbs. Google Earth, likely one of the most popular Qt applications around, is certainly an awesomely powerful application. But the UI stinks. It looks bad, it doesn't behave like standard Mac OS X applications, and it is generally clunky. b.bum ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/jason%40sigio.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 Mac OS X app then I would use Cocoa anytime, it all depends on the size and complexity of the project. Andy On Sat, Nov 1, 2008 at 1:47 PM, Jason Stephenson [EMAIL PROTECTED] wrote: 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? To answer your last question, No. Qt is a widget toolkit that serves the same purpose of MFC, but does so in a very different way, and unlike MFC is inherently cross-platform. You will basically need to rewrite the program from scratch. There is no tool that will automagically turn the MFC code in the application into something that will work on Mac OS X or anything other than Windows. Even a few seconds using Google would have answered your questions. Jason Regards On Fri, Oct 31, 2008 at 4:01 AM, Bill Bumgarner [EMAIL PROTECTED] wrote: 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 modules in your app differently depending on target OS, particularly to get native look and feel. The most important thing with using Qt, is that you will be able to port your app to any unix dialect that uses X windows, as well. Qt is good stuff, but be very careful going down this path. While Qt applications are very portable, the Macintosh Qt apps tend to stick out like sore thumbs. Google Earth, likely one of the most popular Qt applications around, is certainly an awesomely powerful application. But the UI stinks. It looks bad, it doesn't behave like standard Mac OS X applications, and it is generally clunky. b.bum ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/jason%40sigio.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/andy.bell%40allbabel.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 64 bit. Carbon is a legacy technology. Cocoa is the focus of all future development. b.bum smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 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 What is Carbon?. Perhaps you are restricting your classification to things like HIToolbox? --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 criteria, we should always prefer Carbon over Posix. Well, when it comes to file manipulation and dates, I can only strongly encourage exactly that! :-p Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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? I'm calling it legacy because of the definition of legacy and not because of any official policy on anyone's part. Definition of legacy: denoting software or hardware that has been superseded but is difficult to replace because of its wide use. All of the currently shipping Macs are 64 bit, 64 bit shows up as a focus for Snow Leopard here (http://www.apple.com/macosx/ snowleopard/), and Carbon is not supporting 64 bit. And, if you look at the history of Mac OS X Leopard and Tiger, Carbon has been maintained, but not advanced. New technologies are generally presented as Objective-C or CoreFoundation based APIs. To me, that seems kinda legacy like. Of course, I also call the 32 bit Mac OS X Objective-C ABI legacy. And the 64 bit and OS X Touch Objective-C 2.0 ABI modern. The point of all of this is that, if you are developing a new Mac OS X application today, including porting an application from some other platform to Mac OS X, starting by creating a New Cocoa Application, New Cocoa Document Based Application or one of the Core Data new applications is more appropriate than any of the Carbon projects. b.bum smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 being discontinued. It will stay available, but it won't be updated for 64-bit. Don't be scared of Cocoa and Objective C. There is Objective C++, which lets you mix C++ and Objective C on the expression level. Look into that. Don't think Carbon is the better choice just because it's a straight C API and comes with a tiny C++ wrapper 'framework' in its template. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 (1992) is younger than NextStep (1988)? ;-) And if age is a criteria, we should always prefer Carbon over Posix. Yes, but is older than the OpenStep specification (1993) that is the true ancestor of Cocoa. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 consider the age of MFC... You are aware that MFC (1992) is younger than NextStep (1988)? ;-) And if age is a criteria, we should always prefer Carbon over Posix. Yes, but is older than the OpenStep specification (1993) that is the true ancestor of Cocoa. NeXTSTEP is the true ancestor of Cocoa. The NeXTSTEP APIs were quite similar to OpenStep (of which, of course, Cocoa evolved out of). There is relevance to Cocoa-dev here, assuming that an understanding of history helps you. The shift from NeXTSTEP to OpenStep was really focused on a several of areas of change. - The memory management model moved from a classic straight alloc / free model -- literally, objects implemented -free and you called that directly to tear down and deallocate the object -- to a reference counted model using -retain/-release/-autorelease. - Much of what had been straight C APIs were replaced with classes and methods on said classes. User Defaults functions moved to NSUserDefaults, for example. File management, archiving, and a number of other fundamental subsystems were moved to Objective-C. - NSString was added, along with NSDate and NSNumber, and the NEXTSTEP collection classes (List and HashTable) were retired in favor of NSDictionary, NSArray, and NSSet. List and HashTable supported non- ObjC types, but this greatly limited their capabilities. The new collection classes -- what you have today -- were pure object contains and, thus, operations like archiving, KVC, etc... were enabled. - In general, much of what had been code that every developer seemingly needed to write over and over were captured as general purpose, reusable, APIs. When OpenStep was released, it contained a porting toolkit that would run through an application's source and convert it to use the new APIs. Trivia: Andrew Stone's Create -- www.stone.com -- is the only Cocoa application (that I'm aware of) that has run on every single release of Mac OS X, OpenStep, NeXTSTEP, or derivatives (including Sun's NEO) as well as on every processor for which support shipped -- m68k, i386/ mach, i386/windows, SPARC/mach, SPARC/solaris, PA-RISC, PPC, and maybe some I'm forgetting. (Before joining Apple, one of my last contracts involved porting a 750,000 line Objective-C++ application from NS 3.3 to Mac OS X 10.2 [Jaguar]. It was actually quite a bit of fun and required effectively porting to OpenStep 4.2, then Rhapsody DR1, then Mac OS X Beta, then -- finally -- Mac OS X 10.2. By doing this, I was able to port the rather complex NIBs, including custom palette support, from NS 3.3 to MOSX 10.2, taking advantage of the compatibility archive support in AppKit/IB at each stop to preserve the NIBs. Thank goodness for Virtual PC!) b.bum smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Porting from Windows to Mac
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 Warrior. Which one is better and If I want to use any of them then do I need to install them on Mac system and will I need to modify the code very much? Which type of application do I need to choose for porting in Mac cocoa or carbon or something? Thanks in advance. Regards rksinghal ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 was their framework, which was originally Mac-specific, later ported to Windows, discontinued by them but still supported by some long-time users, not of much use in porting MFC to Mac. In fact, there's not really anything of much use in porting MFC to Mac. In order to be cross-platform, and app needs to be designed with that goal in mind. If this app was not so designed, then you may be the one who gets to refactor it. Whether you use something like wxWindows or QT, or separate UI from the application functionality and reimplement the UI in Cocoa or Carbon, depends on the details of the app. ***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. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
RE: Porting from Windows to Mac
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 features it lacks, and debugging is painful under 10.4 and later, especially for Intel-based Macs). Use Xcode instead; it's free and already available to you on your system disks. PowerPlant, for the most part, was very useful before CarbonEvents and Cocoa came to be part of the Mac operating system, but since these facilities and many more became available, you'll be better off rewriting your code into platform-specific and platform-neutral logic, and then move your MFC-based code into the platform-specific section, which is where your Mac/Cocoa code will go, and any logic that doesn't really care about a particular platform should go into the platform-neutral area. 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 Warrior. Which one is better and If I want to use any of them then do I need to install them on Mac system and will I need to modify the code very much? Which type of application do I need to choose for porting in Mac cocoa or carbon or something? Thanks in advance. Regards rksinghal ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
***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 you think. And in the end, you'll go back to Win32 grumbling about how much extra work you have to do there. ;) Topher ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 dead-on-the-vine Win32 apps into a modern Cocoa based version. I have found that once you rectify the MVC designs strategies on each side, the development in XCode goes rather easy. On every project, the process of getting the business logic from the old app cast into the better design has consistently been a challenge. I wish Rakesh good will in this most noble of ventures and offer my help in decrypting the MFC. 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 use it for a legacy product, and there's lots of features it lacks, and debugging is painful under 10.4 and later, especially for Intel-based Macs). Use Xcode instead; it's free and already available to you on your system disks. PowerPlant, for the most part, was very useful before CarbonEvents and Cocoa came to be part of the Mac operating system, but since these facilities and many more became available, you'll be better off rewriting your code into platform-specific and platform-neutral logic, and then move your MFC-based code into the platform-specific section, which is where your Mac/Cocoa code will go, and any logic that doesn't really care about a particular platform should go into the platform-neutral area. 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 Warrior. Which one is better and If I want to use any of them then do I need to install them on Mac system and will I need to modify the code very much? Which type of application do I need to choose for porting in Mac cocoa or carbon or something? Thanks in advance. Regards rksinghal ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/mcstoufer%40lbl.gov This email sent to [EMAIL PROTECTED] -- * Martin C. Stoufer * * ISS/IT * * Lawrence Berkeley National Lab * * 510-486-5306 * * MS 937-700 * smime.p7s Description: S/MIME Cryptographic Signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 use it for a legacy product, and there's lots of features it lacks, and debugging is painful under 10.4 and later, especially for Intel-based Macs). Use Xcode instead; it's free and already available to you on your system disks. PowerPlant, for the most part, was very useful before CarbonEvents and Cocoa came to be part of the Mac operating system, but since these facilities and many more became available, you'll be better off rewriting your code into platform-specific and platform-neutral logic, and then move your MFC-based code into the platform-specific section, which is where your Mac/Cocoa code will go, and any logic that doesn't really care about a particular platform should go into the platform-neutral area. I have to strongly second this approach. Of the 15 frameworks I've authored and/or used over the years, the most successful apps written always contained platform-specific UI. If you attempt to go cross-platform for everything, the app typically suffers (since you're now dealing with a least-common-denominator UI and many religious wars such a button placements). Also have found that the amount of workarounds and/or bugs in such frameworks are often quite high. So the benefits of the so-called write-once are typically lost. ___ Ricky A. Sharp mailto:[EMAIL PROTECTED] Instant Interactive(tm) http://www.instantinteractive.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 decided to go with MFC again. I cannot believe how much of a pain it is. I just learned some Cocoa/ObjC for my last project, and it was easier to learn Cocoa/ ObjC than to get this thing going in MFC/C++. Get the Objective-C 2.0 Programming Language pdf from Apple, and have it printed out at Kinkos, and BUY A COPY OF Cocoa Programming for Mac OS X, Third Edition by Aaron Hillegass. While there is a learning curve for Cocoa/ObjC, once you get going you will look back at MFC with disdain. Refactor the MFC project FIRST. Seperate the UI from the logic as much as possible. It should help you understand the MFC code better, and you might even be able to stick some of it in a dynamic library for reuse. On Oct 30, 2008, at 11:21 AM, [EMAIL PROTECTED] wrote: ***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 you think. And in the end, you'll go back to Win32 grumbling about how much extra work you have to do there. ;) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 are 2 cross-platform tools Power Plant and Code Warrior. None of the two. What you want is Xcode (the standard IDE for Mac OS X) and, may I humbly suggest, wxWidgets. wxWidgets is a cross-platform toolkit that is not the same as MFC but probably one of the easiest to port to from MFC: http://wiki.wxwidgets.org/WxWidgets_For_MFC_Programmers In fact, it appears that there's even a sed script to convert MFC code to wx code (can't vouch for it, I never tried it: http://wiki.wxwidgets.org/Helpers_For_Automated_Rescue_From_MFC) . wxWidgets uses native controls on both OS X and Windows. Should you decide to use a Mac OS native API instead of a cross- platform toolkit, use Cocoa. -Stefan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 decent starting point and make your life easier. Hence, a lot of refactoring beforehand (and some decent unit testing). You have to take into account that Mac development is centered on the MVC pattern and the tools are built for that purpose. You will find that the GUI designer (Interface Builder) is separate from the code editor (Xcode) and you don't have the same mixed up model that e.g. Visual Studio and Delphi promote. 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... - Nick email: [EMAIL PROTECTED] twitter: macsphere ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 there are 2 cross-platform tools Power Plant and Code Warrior. Which one is better and If I want to use any of them then do I need to install them on Mac system and will I need to modify the code very much? Which type of application do I need to choose for porting in Mac cocoa or carbon or something? Thanks in advance. Regards rksinghal ___ 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 modules in your app differently depending on target OS, particularly to get native look and feel. The most important thing with using Qt, is that you will be able to port your app to any unix dialect that uses X windows, as well. -- What is a woman that you forsake her, and the hearth fire and the home acre, to go with the old grey Widow Maker. --Kipling, harp song of the Dane women Tommy Nordgren [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 modules in your app differently depending on target OS, particularly to get native look and feel. The most important thing with using Qt, is that you will be able to port your app to any unix dialect that uses X windows, as well. Qt is good stuff, but be very careful going down this path. While Qt applications are very portable, the Macintosh Qt apps tend to stick out like sore thumbs. Google Earth, likely one of the most popular Qt applications around, is certainly an awesomely powerful application. But the UI stinks. It looks bad, it doesn't behave like standard Mac OS X applications, and it is generally clunky. b.bum smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 age is a criteria, we should always prefer Carbon over Posix. -Stefan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Porting from Windows to Mac
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 (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
