Re: Cocoa/Windows parallel dvlpmt
Re: Cocoa/Windows parallel dvlpmt
- Subject: Re: Cocoa/Windows parallel dvlpmt
- From: Erez Anzel <email@hidden>
- Date: Sun, 1 Feb 2004 13:22:15 -0500
Thanks, all. All of your comments were informative, and confirm my
supposition that I should write as much core as possible in "pure" C++
(pure enough to function well on any platform), and as thin as possible
a UI layer using native resources and tools such as Cocoa and Xcode.
Most of my engine is in C++ already. I'll leave Linux for a back
burner, without even lighting it (the burner, that is).
Seems like I should use Microsoft's tools for the Windows UI. It would
cost me around US$800 more to get Visual Studio as it would cost me to
get just Visual C++, so I figure on the latter for now; money is real
tight. MFC is bundled at no additional cost, from what I remember. Even
if the UI building tools of Visual BASIC are better than those which
come with Visual C++, I think I'm better off sticking with C++.
Much of the Macintosh UI can be done programmatically in Cocoa, instead
of with Interface Builder. Assuming that the same is true with Windows,
I can picture writing code which would create interface elements (e.g.
dialog boxes) on the fly, depending upon which platform it's being run
on. But I don't think that's the best route to take: neither easier nor
faster nor the best results.
My thanks again to all who responded. Time for me to implement.
Bye...Erez
On 1-Feb-04, at 11:36 AM, Andy Satori wrote:
The key to Cross platform, and retaining a native look and feel is to
make the native UI as thin as possible. This way your platform
independent logic exists entirely in portable libraries, and the UI
can then be assembled quickly and cheaply in the native environment.
In my case, I've actually gone to the point of doing this such that I
can leverage better UI tools on each platform. On OS X, my library is
a framework that exposes C++ classes that are consumed by Objective
C++ UI Controllers. While on Windows, I export the classes as COM
objects, though I may eventually move them to .NET, I'm still not
comfortable with requiring 80 mb of patches and run times to a new
install of XP as a base requirement, and this is what it requires to
run .NET 1.1 apps. The other advantage to this is that I can leverage
the better UI building tools of Visual Basic or Delphi, tools that are
more analogous to Interface Builder than MFC / Visual Studio.
While I haven't deployed anything using this model on Linux, I do have
proof of concept work that implements the same approach using both
Gnome (Bonobo) and KDE. Overall, I'm happier with this approach than
I ever was with my prior cross-platform experiences, using the one
tool to target multiple platforms approach that left me with an app
the ran everywhere and looked native nowhere. And this includes Java
both with AWT and Swing.
Finally, the other thing that is great about this approach is that it
provides a significant speed boost over the alternative solutions.
Please bear in mind that all of this comes from a Windows developer
that is moving away from Windows personally, and now only writes
Windows code for his employer, and is using this very methodology to
be a happy employee. I write my library code in XCode, test the
library on my Mac using a Cocoa UI, and when I'm happy with the
results, I open VPC, and assemble the Windows UI in Delphi or VS.NET.
Andy Satori
Satori & Associates, Inc.
email@hidden
On Feb 1, 2004, at 8:45 AM, Lotsa Cabo wrote:
Phillip,
GREAT mindset! I agree with you 110%.
Too many people these days are stuck in the mud believing that "true"
cross-platform development means writing their app in such a way that
they can simply compile and launch on another platform; for example,
using Java for everything from UI to business to data. And, while
this may theoretically be possible, the end result is usually not
something that feels as if it was made for the target platform.
I'm still in "discovery mode" trying seek out the perfect mix of
technologies for my app so that it can be ported to each platform --
Mac, Linux, and Windows. I've been leaning towards Objective-C, but
was told (on another thread) that it's not very easy to port to
Windows because of licensing. Any information you know of pertaining
to cross-platform ObjC++ stuff would be great.
R/S
Ryan
On Feb 1, 2004, at 8:03 AM, Phillip Mills wrote:
On Saturday, January 31, 2004, at 02:05 PM, Erez Anzel wrote:
I have been happily developing in Cocoa using XCode 1.1. But I have
to port to Windows, very quickly. I want to keep my duplication of
effort to a minimum, so that I can maintain and enhance both
products efficiently.
I've done this kind of thing -- with Linux tossed into the mix as
well -- and it made me a great fan of Objective C++.
My strategy was to use "pure" C++ for everything that was not GUI
and have it compile with as few platform dependencies as possible on
all three targets...lots of STL. I also assumed that the only part
of the GUI that would be portable was the functional design. I
think that by acknowledging that up front, I saved myself a lot of
pain during GUI implementation.
To link the pieces together, my C++ code acted as a library that
could be called by any interface (including a console one that I
wrote for testing). I also defined abstract classes for my C++
library that defined a "virtual" GUI...call-back functions that the
core code needed for display purposes. Those classes then had their
implementations provided by the real, platform-specific
interfaces...either directly on Windows and Linux, or by thin C++
objects within Cocoa/Objective C++ classes.
........................
Phillip Mills
Multi-platform software development
(416) 224-0714
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.