Re: X-platform strategies?
Re: X-platform strategies?
- Subject: Re: X-platform strategies?
- From: Tom Dibble <email@hidden>
- Date: Sat, 14 May 2005 13:49:48 -0700
A few strategies I've used:
1) If the interface logic was minimal, by far the easiest way is to
use a proper MVC paradigm and just change the "V" part for each
platform.
2) If interface elements need to inter-communicate, perhaps a
"messaging" API would be useful (ie, each control gets a constant
identifier and each "action" on there gets another constant).
Doesn't work incredibly well for complex messages being sent, but can
work for simple cases.
3) Somewhat as you suggest below, but a roll-your-own approach:
give each UI element type its own class, exposing the common actions
you need to be able to take on it, and subclass for your particular
platform. Everyone talks to everyone else via the standard parent
class APIs except where absolutely necessary (ie, if the Mac
implementation of a Button needs to do some Mac specific thing to a
Scrollbar, it can assume that the MyScrollbar is an MyOSXScrollbar
instance and dynamic cast down to it ... but if the Windows version
needs to do the same, you've got to duplicate that code).
Since what you need to expose for each element is highly project-
dependent and can introduce compromises elsewhere, I actually prefer
(3) to any of the available cross-platform libraries out there. But,
if you want to minimize work, there are a few to choose from,
including Qt.
---- Tom Dibble
On May 14, 2005, at 12:50 PM, Theodore H. Smith wrote:
Does anyone have an idea of strategies that would be useful when
porting MFC apps to a Cocoa based Mac app?
I'm finding that a lot of the code that I need to port, is doing
stuff to manipulate the controls, which is a lot of MFC code, or
even worse, custom controls based off of MFC.
I find it hard to imagine how to port this in such a way that
maximises code-reuse. I could just re-write almost everything
except for reading and writing of file formats and other
serialisation stuff (Sockets)... but I think that's not a strategy
for the future, because as time goes by, the app will only get more
complex and having more and more forked code will only make things
worse.
Ideally, I'd like to use/write some kind of wrapper that made both
platforms have a consistent programming interface. I'm not sure how
doable that is, and what with all these custom controls defined, it
just makes the idea worse.
Just wondering if anyone had some idea of different strategies.
Right now it's looking like I must fork most of the app code, and
very little will be shared. That just doesn't feel like a good
solution to me.
--
elfdata.com/plugin/ Industrial strength string processing, made easy.
"All things are logical. Putting free-will in the slot for premises in
a logical system, makes all of life both understandable, and free."
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden