Converting Cocoa XCode app to Multiplatform wxWidgets app Topic is solved

Do you have a typical platform dependent issue you're battling with ? Ask it here. Make sure you mention your platform, compiler, and wxWidgets version.
Post Reply
Chris_DPS
In need of some credit
In need of some credit
Posts: 3
Joined: Wed May 14, 2008 6:43 pm

Converting Cocoa XCode app to Multiplatform wxWidgets app

Post by Chris_DPS »

I'm a newcomer to wxWidgets and have tried some of the sample projects for wxMac.

Our company has an application written in Cocoa/Objective-C using XCode and Interface Builder. How much of an undertaking would it be to convert this XCode application to a wxWidget application that would run on both Mac (10.4 and later) and PC Windows (XP, etc.)? Also, I would greatly appreciate any examples that would lead me in the right direction or that would be a good starting point.

Thanks you,

Chris
mc2r
wxWorld Domination!
wxWorld Domination!
Posts: 1195
Joined: Thu Feb 22, 2007 4:47 pm
Location: Denver, Co
Contact:

Re: Converting Cocoa XCode app to Multiplatform wxWidgets ap

Post by mc2r »

You shouldn't double post, likely an accident, so you might want to delete the other identical post in this thread.
Chris_DPS wrote:How much of an undertaking would it be to convert this XCode application to a wxWidget application that would run on both Mac (10.4 and later) and PC Windows (XP, etc.)?
No on can really answer this for you. How much c++ do you know, how big of an app is it? How well documented is the current code? How well organized? How much platform dependent specific stuff is there? How much of what you are doing is supported by wxWidgets? etc... Every project is unique so there is no way to know what it will take to port your app to wxWidgets.
Chris_DPS wrote:Also, I would greatly appreciate any examples that would lead me in the right direction or that would be a good starting point.
Again, not knowing your project i can't say which direction you need to go in. As to where to start, learn c++ then learn wxWidgets... The samples included with the wxWdigets source is a good place(if you know c++), as well as the tutorials, docs and posts here.

-Max
Ryan Wilcox
I live to help wx-kind
I live to help wx-kind
Posts: 194
Joined: Mon Aug 30, 2004 1:26 pm
Location: PA, USA
Contact:

Post by Ryan Wilcox »

Chris,

So i've done a lot of wxMac programming, and a bit of Cocoa programming, so here's my kind of informed answer.

If I was going to convert a Cocoa app to wxWidgets, I'd start integrating wxBase into the code. NSString to wxString, NSSocket to wxSocket, you know. You'd probably have to write some converter functions, or see if wxCocoa has something clever to overcome this problem. (I suspect it does). In this way you can keep your current UI but make progress in the cross-platform way.

In general, Objective-C++ is the key, and maybe up to and even after you make the jump to cross-platformness. (afterwards, to provide Mac specific functionality). It's definitely the key to this first step, because Cocoa will be handing you NSStrings and stuff but you want to deal with wxStrings.

For this initial step you might actually want to use wxCocoa instead of wxMac. Although I wouldn't recommend it to base an entire application on, but it might be helpful there. UNLESS your team also happens to have a Carbon expert on staff that can help the transition.

From there I would start reworking some windows. Get DialogBlocks, but after IB it'll be a HARD transition. It goes a LOT easier if you think about DB as an outliner that happens to be an interface layout tool (unlike IB which is a drawing tool that happens to be a interface layout tools). (But... autogenerate C++ == not so pretty C++. But there's always XRC)

If you have some custom NSViews you want to take forward, and you don't mind running on 10.5 only, Leopard has a HIView that you can use to draw NSView subclasses in. Although I haven't used it before, it should be trivial to make a custom wxWidgets control that integrates this. I've done a number of HIView subclasses-inside-a-wxWidgets-custom-control and it's not hard (especially using Apple's HIFramework).

Even if you can't use the 10.5 view, HIView drawing code is very similar to NSView (because they're both based on Quartz of course)... except with a C wrapper instead of ObjC wrapper. It's not bad.

Even with all of this, your app *will* (I urge you) have Mac specific features. A better Recent Documents menu (JWWalker has a really nice one that trivially integrates into wx), script-ability (I have some thoughts on that actually, but I haven't had time to experiment), Keychain, etc. Good project organization from the start, and knowing that these things will exist, will help a lot.

On the experimental front, you may be able to load up those nibs somehow and integrate it, to some extent, with wx interface code. It's kind of a sidetrack, and would require and expert in both Cocoa event loops, Carbon event loops, and wx. It can be done: as long as Carbon and Cocoa exist in separate windows in 10.2+, (and I think these rules have changed with 10.5, above and beyond the NSView-in-HIView control i mentioned earlier).

BUT: one of the key advantages to wx, in my eyes, is that it's open source. You may consider grabbing the latest wxWidgets (or wxCocoa) and start hacking on it to make it fit your needs. That's what one of my clients does, and while we try to push patches up when I get free time, sometimes our needs don't meet the approval of the wxGroup in general... so we have our local mods.

Hope this helps. If you have any more questions, feel free to PM me, and I'll see what I can do to help
_Ryan Wilcox
Ryan Wilcox
Wilcox Development Solutions
http://www.wilcoxd.com
Chris_DPS
In need of some credit
In need of some credit
Posts: 3
Joined: Wed May 14, 2008 6:43 pm

Post by Chris_DPS »

Max & Ryan, thanks for your input. I'll start plugging along, trying some of your suggestions.

Sorry about the double post.
Alan-Shouls
Knows some wx things
Knows some wx things
Posts: 33
Joined: Mon Aug 07, 2006 3:26 pm

Post by Alan-Shouls »

Hi Chris,

Something you might like to consider is keeping the UI in cocoa for the OSX build.

I have looked at developing a true mac UI (for shrinkwrapped s/w) in wx and concluded that at the moment it would be almost impossible. Of course this will depend on what sort of user experience you want and who your target market is. If you have a simple UI using "out of the box" cocoa controls - I am sure you can do this, however modern OSX UI is very different - add into the mix that people expect things like animation in their UI experience and it gets hard. Also if your cocoa UI works there any be good reasons to keep it.

Another thing to consider is that the wxCocoa port is a young port it is quite incomplete and I would (personally) not consider building a shipping product against it. It is being developed and this might change. Certianly if your company contacted the developer (David Eliot) he might be happy to come to some arangement for you to get whatever features you need in. wxMac is a complete port - it is mature and actively developed but it is carbon rather than cocoa. This may not be a problem - unless you want to mix with cocoa. My experience of mixing carbon and cocoa at a UI level is that it is rather horrible and never quite works properly.

The developer behind wxMac Stefan Csomore is moving the project to cocoa. A summary of his approach can be found at http://wiki.wxwidgets.org/Development:_wxMac64. Again your company might be interested in reaching an arrangement with Stefan if you need the cocoa part of the UI in wxMac.

Were it me I would keep the UI in cocoa until I was sure I could get the quality I needed. I would use wxMac as it is good enough to build a shipping app against.

My 2€

Best regards

Alan Shouls
Chris_DPS
In need of some credit
In need of some credit
Posts: 3
Joined: Wed May 14, 2008 6:43 pm

Post by Chris_DPS »

Thanks, Alan!

I do appreciate all of the insightful responses I've received!

Chris
Post Reply