Cross-platform?

  • Curious about how people are dealing with cross-platform issues.
    Cocoa on Mac to ? on Windows, ? on Linux.

    If it was a carbon app all/most code would be in C or C++ and UI could be
    dealt with in at least somewhat similar fashion between platforms.  Seems to
    be one of the potential trade-offs of Cocoa vs Carbon that Apple doesn't
    address much.

    I know I can code in C or C++ within Cocoa as well but how are most real
    Cocoa developers dealing with this and the UI porting issues?  Or are most
    Cocoa developed apps staying Mac only?

    Is the potential faster/easier coding in Cocoa(is it?) offset by added time
    and work to port to other platforms?

    Thanks.
  • On 16/feb/06, at 01:04, Scott Squires wrote:

    > Curious about how people are dealing with cross-platform issues.
    > Cocoa on Mac to ? on Windows, ? on Linux.
    >
    > If it was a carbon app all/most code would be in C or C++ and UI
    > could be
    > dealt with in at least somewhat similar fashion between platforms.
    > Seems to
    > be one of the potential trade-offs of Cocoa vs Carbon that Apple
    > doesn't
    > address much.
    >
    > I know I can code in C or C++ within Cocoa as well but how are most
    > real
    > Cocoa developers dealing with this and the UI porting issues?  Or
    > are most
    > Cocoa developed apps staying Mac only?
    >
    > Is the potential faster/easier coding in Cocoa(is it?) offset by
    > added time
    > and work to port to other platforms?

    A common practice is to write the Mac front-end in Cocoa and the
    cross-platform back-end in whatever. This is no different from
    writing the front-end in Carbon: in both cases, it's not portable and
    you need to write a different front-end for other platforms.

    Another strategy is to use a cross-platform toolkit for the GUI, but
    this usually results in a sub-optimal user experience on the Mac. A
    recent example of this approach is Google Earth.

    Camillo
  • On Feb 15, 2006, at 4:30 PM, Camillo Lugaresi wrote:

    > On 16/feb/06, at 01:04, Scott Squires wrote:
    >
    >> Curious about how people are dealing with cross-platform issues.
    >> Cocoa on Mac to ? on Windows, ? on Linux.
    >>
    >> If it was a carbon app all/most code would be in C or C++ and UI
    >> could be
    >> dealt with in at least somewhat similar fashion between
    >> platforms.  Seems to
    >> be one of the potential trade-offs of Cocoa vs Carbon that Apple
    >> doesn't
    >> address much.
    >>
    >> I know I can code in C or C++ within Cocoa as well but how are
    >> most real
    >> Cocoa developers dealing with this and the UI porting issues?  Or
    >> are most
    >> Cocoa developed apps staying Mac only?
    >>
    >> Is the potential faster/easier coding in Cocoa(is it?) offset by
    >> added time
    >> and work to port to other platforms?
    >
    > A common practice is to write the Mac front-end in Cocoa and the
    > cross-platform back-end in whatever. This is no different from
    > writing the front-end in Carbon: in both cases, it's not portable
    > and you need to write a different front-end for other platforms.
    >
    > Another strategy is to use a cross-platform toolkit for the GUI,
    > but this usually results in a sub-optimal user experience on the
    > Mac. A recent example of this approach is Google Earth.

    From personal experience, I can say that C++ back-end plus Cocoa/
    Objective-C front-end is a great way to develop an app. A little bit
    of forethought is needed to keep the front-end and back-end truly
    separate, but that's true whether you use Cocoa, Carbon, or a
    separate approach. There are adaptors to let STL containers work as
    NS containers as well; I haven't tried these personally, though.
  • I don't like using things like Qt on the Mac as I like Objective-C so
    much. If I need to be cross-platform I write most of the back-end in
    'C' then do a very thin GUI layer in Cocoa, then I give it to the
    Windows guys to do the Windows front-end in whatever they use and
    keep the back-end portable.

    I'd love to be able to write once on a Mac and to be able to produce
    a Windows, LINUX and UNIX app from that...

    Regards, Rob.

    On 16 Feb 2006, at 00:04, Scott Squires wrote:

    > Curious about how people are dealing with cross-platform issues.
    > Cocoa on Mac to ? on Windows, ? on Linux.
    >
    > If it was a carbon app all/most code would be in C or C++ and UI
    > could be
    > dealt with in at least somewhat similar fashion between platforms.
    > Seems to
    > be one of the potential trade-offs of Cocoa vs Carbon that Apple
    > doesn't
    > address much.
    >
    > I know I can code in C or C++ within Cocoa as well but how are most
    > real
    > Cocoa developers dealing with this and the UI porting issues?  Or
    > are most
    > Cocoa developed apps staying Mac only?
    >
    > Is the potential faster/easier coding in Cocoa(is it?) offset by
    > added time
    > and work to port to other platforms?
    >
    > Thanks.
  • The obvious solution would be to use GNUStep on the other platforms.
    The GNUStep Foundation and AppKit frameworks are coded to the
    OpenStep interface defined by NeXT and Sun way back when. Take a peek
    at www.gnustep.org . You'll find that the class libraries conform
    closely to those in Cocoa.

    This is absolutely the best approach for Linux. For Windows it would
    require that the GNU Cygwin libraries are loaded  first.

    John Sarkela
    [|] Knight of the Square Brackets

    > Message: 9
    > Date: Wed, 15 Feb 2006 16:04:12 -0800
    > From: Scott Squires <scottsquires...>
    > Subject: Cross-platform?
    > To: <cocoa-dev...>
    > Message-ID: <C019017C.622B%<scottsquires...>
    > Content-Type: text/plain;    charset="US-ASCII"
    >
    > Curious about how people are dealing with cross-platform issues.
    > Cocoa on Mac to ? on Windows, ? on Linux.
    >
    > If it was a carbon app all/most code would be in C or C++ and UI
    > could be
    > dealt with in at least somewhat similar fashion between platforms.
    > Seems to
    > be one of the potential trade-offs of Cocoa vs Carbon that Apple
    > doesn't
    > address much.
    >
    > I know I can code in C or C++ within Cocoa as well but how are most
    > real
    > Cocoa developers dealing with this and the UI porting issues?  Or
    > are most
    > Cocoa developed apps staying Mac only?
    >
    > Is the potential faster/easier coding in Cocoa(is it?) offset by
    > added time
    > and work to port to other platforms?
    >
    > Thanks.
    >
    >
    >
  • > I'd love to be able to write once on a Mac and to be able to
    > produce a Windows, LINUX and UNIX app from that...

    You can do that with RealBasic.  Despite the stigma associated with
    it, it's a very good development environment.

    Personally, I've found that even with trivial CLI programs,
    supporting the major three OS' is not at all trivial.  Linux & MacOS
    X differ substantially in how they do certain basic things, and
    Cygwin doesn't even pretend to be compatible with anything.  In fact,
    I ended up getting one large POSIX app to work under true Windows
    (using a trivial compatibility layer) before I could get it to even
    compile with Cygwin.

    Trying to use a generic UI toolkit is almost always asking for
    trouble - all they do is guarantee your interface looks and works
    consistently bad across all platforms.  As people have said, a native
    front-end is a must for any serious app.  And when I say frontend,
    I'm including things like file I/O and basic OS services.  Anything
    that involves a system call.  There are some cross-platform libraries
    which abstract all these fundamental things, which can be quite handy
    to use.  I'm not particularly familiar with any of them, but a quick
    Google will deliver a plethora of choices.

    Wade
  • I guess it depends on your target.
    If you are targeting end users on Windows and OS X, GNUStep is pretty
    inappropriate.
    If you're targeting developers or techie types who don't mind
    installing a grip of extra tools and libraries, then GNUStep may be
    appropriate. I haven't used it. My impression is that it's missing a
    fair amount of functionality that Cocoa has, but that's all hearsay.

    On Feb 15, 2006, at 5:17 PM, John Sarkela wrote:

    > The obvious solution would be to use GNUStep on the other
    > platforms. The GNUStep Foundation and AppKit frameworks are coded
    > to the OpenStep interface defined by NeXT and Sun way back when.
    > Take a peek at www.gnustep.org . You'll find that the class
    > libraries conform closely to those in Cocoa.
    >
    > This is absolutely the best approach for Linux. For Windows it
    > would require that the GNU Cygwin libraries are loaded  first.
    >
    > John Sarkela
    > [|] Knight of the Square Brackets
    >
    >> Message: 9
    >> Date: Wed, 15 Feb 2006 16:04:12 -0800
    >> From: Scott Squires <scottsquires...>
    >> Subject: Cross-platform?
    >> To: <cocoa-dev...>
    >> Message-ID: <C019017C.622B%<scottsquires...>
    >> Content-Type: text/plain;    charset="US-ASCII"
    >>
    >> Curious about how people are dealing with cross-platform issues.
    >> Cocoa on Mac to ? on Windows, ? on Linux.
    >>
    >> If it was a carbon app all/most code would be in C or C++ and UI
    >> could be
    >> dealt with in at least somewhat similar fashion between
    >> platforms.  Seems to
    >> be one of the potential trade-offs of Cocoa vs Carbon that Apple
    >> doesn't
    >> address much.
    >>
    >> I know I can code in C or C++ within Cocoa as well but how are
    >> most real
    >> Cocoa developers dealing with this and the UI porting issues?  Or
    >> are most
    >> Cocoa developed apps staying Mac only?
    >>
    >> Is the potential faster/easier coding in Cocoa(is it?) offset by
    >> added time
    >> and work to port to other platforms?
    >>
    >> Thanks.
    >>
    >>
    >>
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/jstiles%
    > 40blizzard.com
    >
    > This email sent to <jstiles...>
  • If you concern about the fact that your GUI should look as close as
    possible to "native" GUI look, then GNUStep is not the best
    solution.  Just take a look at this screenshot (http://
    www.gnustep.org/images/full-screenshot1.png). It does not look
    anything like Mac OS X.

    If you are familiar with Java, you might want take a look into SWT
    (http://www.eclipse.org/swt/) from Eclipse folks (http://
    www.eclipse.org/).  Latest version (3.2) of SWT does look remarkable
    like "Native" application on all 3 platforms ( Mac OS X, Windows,
    Linux ).  You will miss some Apple specific GUI elements, but
    "standard" widgets do look pretty good. Another piece of good news,
    it looks like Eclipse finally got enough people working on Mac OX
    port, so latest builds of Eclipse finally usable on Mac OS (even
    Visual Editor!!!).

    On Feb 15, 2006, at 8:17 PM, John Sarkela wrote:

    > The obvious solution would be to use GNUStep on the other
    > platforms. The GNUStep Foundation and AppKit frameworks are coded
    > to the OpenStep interface defined by NeXT and Sun way back when.
    > Take a peek at www.gnustep.org . You'll find that the class
    > libraries conform closely to those in Cocoa.
    >
    > This is absolutely the best approach for Linux. For Windows it
    > would require that the GNU Cygwin libraries are loaded  first.
    >
    > John Sarkela
    > [|] Knight of the Square Brackets
    >
    >> Message: 9
    >> Date: Wed, 15 Feb 2006 16:04:12 -0800
    >> From: Scott Squires <scottsquires...>
    >> Subject: Cross-platform?
    >> To: <cocoa-dev...>
    >> Message-ID: <C019017C.622B%<scottsquires...>
    >> Content-Type: text/plain;    charset="US-ASCII"
    >>
    >> Curious about how people are dealing with cross-platform issues.
    >> Cocoa on Mac to ? on Windows, ? on Linux.
    >>
    >> If it was a carbon app all/most code would be in C or C++ and UI
    >> could be
    >> dealt with in at least somewhat similar fashion between
    >> platforms.  Seems to
    >> be one of the potential trade-offs of Cocoa vs Carbon that Apple
    >> doesn't
    >> address much.
    >>
    >> I know I can code in C or C++ within Cocoa as well but how are
    >> most real
    >> Cocoa developers dealing with this and the UI porting issues?  Or
    >> are most
    >> Cocoa developed apps staying Mac only?
    >>
    >> Is the potential faster/easier coding in Cocoa(is it?) offset by
    >> added time
    >> and work to port to other platforms?
    >>
    >> Thanks.
    >>
    >>
    >>
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/<andrei...>
    >
    > This email sent to <andrei...>
  • There are three "first class" development environments that Apple supports
    on Mac OS X: Cocoa, Carbon and Java. The latter is the one with the best
    cross platform story. And contrary to popular belief, a Java application can
    certainly look and feel like any Carbon or Cocoa application on the Mac.
    Unfortunately, not all software applications written in Java make the modest
    adjustments that are usually needed to provide a "Mac like" experience when
    running on a Mac; and that fact has lead some to the wrong conclusion that
    apps written in Java cannot behave like ordinary Macintosh applications.

    Greg

    On 2/15/06 4:04 PM, "Scott Squires" <scottsquires...> wrote:

    > Curious about how people are dealing with cross-platform issues.
    > Cocoa on Mac to ? on Windows, ? on Linux.
    >
    > If it was a carbon app all/most code would be in C or C++ and UI could be
    > dealt with in at least somewhat similar fashion between platforms.  Seems to
    > be one of the potential trade-offs of Cocoa vs Carbon that Apple doesn't
    > address much.
    >
    > I know I can code in C or C++ within Cocoa as well but how are most real
    > Cocoa developers dealing with this and the UI porting issues?  Or are most
    > Cocoa developed apps staying Mac only?
    >
    > Is the potential faster/easier coding in Cocoa(is it?) offset by added time
    > and work to port to other platforms?
    >
    > Thanks.
    >
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/<greghe...>
    >
    > This email sent to <greghe...>
  • On 16 Feb 2006, at 06:49, Greg Herlihy wrote:

    > And contrary to popular belief, a Java application can
    > certainly look and feel like any Carbon or Cocoa application on the
    > Mac.
    > Unfortunately, not all software applications written in Java make
    > the modest
    > adjustments that are usually needed to provide a "Mac like"
    > experience when
    > running on a Mac; and that fact has lead some to the wrong
    > conclusion that
    > apps written in Java cannot behave like ordinary Macintosh
    > applications.
    >
    Can you point us to some example apps which do look like ordinary Mac
    apps. All of the ones I have seen look a bit wierd compared to
    'normal' apps.

    Thanks

    Matt Gough

    Softchaos Limited
  • On 16.02.2006, at 11:58, Matt Gough wrote:

    >
    > On 16 Feb 2006, at 06:49, Greg Herlihy wrote:
    >
    >> And contrary to popular belief, a Java application can
    >> certainly look and feel like any Carbon or Cocoa application on
    >> the Mac.
    >> Unfortunately, not all software applications written in Java make
    >> the modest
    >> adjustments that are usually needed to provide a "Mac like"
    >> experience when
    >> running on a Mac; and that fact has lead some to the wrong
    >> conclusion that
    >> apps written in Java cannot behave like ordinary Macintosh
    >> applications.
    >>
    > Can you point us to some example apps which do look like ordinary
    > Mac apps. All of the ones I have seen look a bit wierd compared to
    > 'normal' apps.

    CyberDuck for example.

    Daniel.
  • On 16 Feb 2006, at 11:03, Daniel Vollmer wrote:

    >> Can you point us to some example apps which do look like ordinary
    >> Mac apps. All of the ones I have seen look a bit wierd compared to
    >> 'normal' apps.
    >
    > CyberDuck for example.

    Sorry, I guess I should have been a bit clearer:

    Can you point us to some example apps which do look like ordinary Mac
    apps and that DONT use a cocoa/carbon front end for the GUI stuff.

    Matt
  • Am 16.02.2006 um 03:05 schrieb Andrei Tchijov:

    > If you concern about the fact that your GUI should look as close as
    > possible to "native" GUI look, then GNUStep is not the best
    > solution.  Just take a look at this screenshot (http://
    > www.gnustep.org/images/full-screenshot1.png). It does not look
    > anything like Mac OS X.

    This is a screenshot from a Linux or *BSD machine. On Mac OS X,
    GNUstep (with the apple-apple-apple libcombo) uses the native
    Foundation/AppKit and gives you a fully native user experience
    accordingly. In fact, GNUstep on Mac OS X is very thin, mostly
    consisting of a make based build system and a bunch of additions to
    Foundation/AppKit to improve compatibility.

    For an example, you might wan to check out GNUMail.app: <http://
    www.collaboration-world.com/gnumail/>

    That said, GNUstep is used and maintained mostly by professional
    developers, so it lacks a three-clicks-to-get-a-working-app experience.

    Markus

    - - - - - - - - - - - - - - - - - - -
    Dipl. Ing. Markus Hitter
    http://www.jump-ing.de/
  • We used GNUStep/ObjC for the back end, a thin layer of C++ glue code
    and C#/.net front end for the Windows version of NovaMind www.nova-
    mind.com. The same ObjC back end is used for the Mac version. Result:
    very high level of code reuse and complete native experience on both
    platforms.

    The only real issues we had apart from the usual familiarization/
    general design issues were to do with handling NSImages going back
    and forth and being usable in Windows. Oh yes, and we are using
    native text layout (actually we wrote our own for windows because the
    normal windows font handling is appalling!), so the string layout
    metrics were different. Apart from that, it has been a pretty smooth
    ride. During the course of the project which started about 9 months
    ago and is just now starting the roll out phases, GNUStep for Windows
    has matured quite a bit, and it is now much easier to build and work
    with than when we started. We have somewhere around 150,000 lines of
    code in the cross-platform portion of the application, and it just
    works.

    When I started preparing for the port, I wanted to just use
    Foundation and stay completely away from AppKit because I had heard
    that it was unstable under GnuStep, but I quickly found that it was
    pretty much impossible to do the things that I wanted to do, like
    complete handling of NSAttributedStrings (which have things like
    NSFonts, NSColors etc from AppKit in them), so had to add AppKit to
    the mix, but it didn't cause any issues for the things we have done
    with it.

    So we have an example of a real world application that was
    successfully ported, keeping the lovely Objective-C code for all the
    internals and just putting a thin native layer on it to give the best
    experience on both platforms.

    The windows version of the application is just a newborn babe (first
    release yesterday) and still needs performance tuning, but the issues
    that we have looked at regarding performance were bottlenecks
    elsewhere in our code - we haven't seen anything of serious concern
    speed wise for our application on windows/GNUStep (yet). We don't
    have anything that we are doing that is ultra-specially speed
    critical, so YMMV.

    Just thought this would be a good data point...

    Gideon King
    <novasoft...>

    On 16/02/2006, at 9:31 PM, Markus Hitter wrote:

    >
    > Am 16.02.2006 um 03:05 schrieb Andrei Tchijov:
    >
    >> If you concern about the fact that your GUI should look as close
    >> as possible to "native" GUI look, then GNUStep is not the best
    >> solution.  Just take a look at this screenshot (http://
    >> www.gnustep.org/images/full-screenshot1.png). It does not look
    >> anything like Mac OS X.
    >
    > This is a screenshot from a Linux or *BSD machine. On Mac OS X,
    > GNUstep (with the apple-apple-apple libcombo) uses the native
    > Foundation/AppKit and gives you a fully native user experience
    > accordingly. In fact, GNUstep on Mac OS X is very thin, mostly
    > consisting of a make based build system and a bunch of additions to
    > Foundation/AppKit to improve compatibility.
    >
    > For an example, you might wan to check out GNUMail.app: <http://
    > www.collaboration-world.com/gnumail/>
    >
    >
    > That said, GNUstep is used and maintained mostly by professional
    > developers, so it lacks a three-clicks-to-get-a-working-app
    > experience.
    >
    >
    > Markus
    >
    > - - - - - - - - - - - - - - - - - - -
    > Dipl. Ing. Markus Hitter
    > http://www.jump-ing.de/
    >
    >
    >
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/<novasoft...>
    >
    > This email sent to <novasoft...>
  • No one has mentioned it, but another possible option is  C#/Mono back-
    end, CocoaSharp (C# bindings to Cocoa) on the front-end for Mac --
    Systems.Forms (native Win toolkit) for Windows -- Gtk for Linux.
    With some of the more recent versions of Mono, you could use
    System.Forms (or GTK) on all three systems, but lose the native look
    & feel obviously.

    Imeem is using this approach.

    Rich

    On Feb 16, 2006, at 6:55 AM, Gideon King wrote:

    > We used GNUStep/ObjC for the back end, a thin layer of C++ glue
    > code and C#/.net front end for the Windows version of NovaMind
    > www.nova-mind.com. The same ObjC back end is used for the Mac
    > version. Result: very high level of code reuse and complete native
    > experience on both platforms.
    >
    > The only real issues we had apart from the usual familiarization/
    > general design issues were to do with handling NSImages going back
    > and forth and being usable in Windows. Oh yes, and we are using
    > native text layout (actually we wrote our own for windows because
    > the normal windows font handling is appalling!), so the string
    > layout metrics were different. Apart from that, it has been a
    > pretty smooth ride. During the course of the project which started
    > about 9 months ago and is just now starting the roll out phases,
    > GNUStep for Windows has matured quite a bit, and it is now much
    > easier to build and work with than when we started. We have
    > somewhere around 150,000 lines of code in the cross-platform
    > portion of the application, and it just works.
    >
    > When I started preparing for the port, I wanted to just use
    > Foundation and stay completely away from AppKit because I had heard
    > that it was unstable under GnuStep, but I quickly found that it was
    > pretty much impossible to do the things that I wanted to do, like
    > complete handling of NSAttributedStrings (which have things like
    > NSFonts, NSColors etc from AppKit in them), so had to add AppKit to
    > the mix, but it didn't cause any issues for the things we have done
    > with it.
    >
    > So we have an example of a real world application that was
    > successfully ported, keeping the lovely Objective-C code for all
    > the internals and just putting a thin native layer on it to give
    > the best experience on both platforms.
    >
    > The windows version of the application is just a newborn babe
    > (first release yesterday) and still needs performance tuning, but
    > the issues that we have looked at regarding performance were
    > bottlenecks elsewhere in our code - we haven't seen anything of
    > serious concern speed wise for our application on windows/GNUStep
    > (yet). We don't have anything that we are doing that is ultra-
    > specially speed critical, so YMMV.
    >
    > Just thought this would be a good data point...
    >
    > Gideon King
    > <novasoft...>
    >
    > On 16/02/2006, at 9:31 PM, Markus Hitter wrote:
    >
    >>
    >> Am 16.02.2006 um 03:05 schrieb Andrei Tchijov:
    >>
    >>> If you concern about the fact that your GUI should look as close
    >>> as possible to "native" GUI look, then GNUStep is not the best
    >>> solution.  Just take a look at this screenshot (http://
    >>> www.gnustep.org/images/full-screenshot1.png). It does not look
    >>> anything like Mac OS X.
    >>
    >> This is a screenshot from a Linux or *BSD machine. On Mac OS X,
    >> GNUstep (with the apple-apple-apple libcombo) uses the native
    >> Foundation/AppKit and gives you a fully native user experience
    >> accordingly. In fact, GNUstep on Mac OS X is very thin, mostly
    >> consisting of a make based build system and a bunch of additions
    >> to Foundation/AppKit to improve compatibility.
    >>
    >> For an example, you might wan to check out GNUMail.app: <http://
    >> www.collaboration-world.com/gnumail/>
    >>
    >>
    >> That said, GNUstep is used and maintained mostly by professional
    >> developers, so it lacks a three-clicks-to-get-a-working-app
    >> experience.
    >>
    >>
    >> Markus
    >>
    >> - - - - - - - - - - - - - - - - - - -
    >> Dipl. Ing. Markus Hitter
    >> http://www.jump-ing.de/
    >>
    >>
    >>
    >>
    >> _______________________________________________
    >> Do not post admin requests to the list. They will be ignored.
    >> Cocoa-dev mailing list      (<Cocoa-dev...>)
    >> Help/Unsubscribe/Update your Subscription:
    >> http://lists.apple.com/mailman/options/cocoa-dev/<novasoft...>
    >>
    >> This email sent to <novasoft...>
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/<rcw3...>
    >
    > This email sent to <rcw3...>
  • On 16/feb/06, at 07:49, Greg Herlihy wrote:

    > There are three "first class" development environments that Apple
    > supports
    > on Mac OS X: Cocoa, Carbon and Java. The latter is the one with the
    > best
    > cross platform story. And contrary to popular belief, a Java
    > application can
    > certainly look and feel like any Carbon or Cocoa application on the
    > Mac.

    Unfortunately, Java GUIs (both Swing and SWT) still feel really
    slooooow on Mac OS X. Applications such as Poseidon or Eclipse always
    seem to run orders of magnitudes worse on OS X than they do on
    Windows. I can't say for sure that it is impossible to make a complex
    Java GUI "snappy" on OS X, but it certainly cannot be easy, since so
    many people seem to be unable accomplish it.

    Camillo
  • On Feb 16, 2006, at 1:51 PM, Camillo Lugaresi wrote:

    > On 16/feb/06, at 07:49, Greg Herlihy wrote:
    >
    >> There are three "first class" development environments that Apple
    >> supports
    >> on Mac OS X: Cocoa, Carbon and Java. The latter is the one with
    >> the best
    >> cross platform story. And contrary to popular belief, a Java
    >> application can
    >> certainly look and feel like any Carbon or Cocoa application on
    >> the Mac.
    >
    > Unfortunately, Java GUIs (both Swing and SWT) still feel really
    > slooooow on Mac OS X. Applications such as Poseidon or Eclipse
    > always seem to run orders of magnitudes worse on OS X than they do
    > on Windows. I can't say for sure that it is impossible to make a
    > complex Java GUI "snappy" on OS X, but it certainly cannot be easy,
    > since so many people seem to be unable accomplish it.

    For some reason, they also seem to flicker/blink a lot more than real
    OS X apps. It's as if they aren't taking full advantage of the back-
    buffer.
    (Could it be that they are flushing after every draw? That would
    explain a lot.)
  • Yes, this would also work well if you started with a project that
    used C# or you had strong C# experience to start with.

    In my case, NovaMind had been out on MacOS X for 2.5 years and was
    firmly an ObjC application at the time we started the Windows port,
    so the best solution for our situation was to leverage the ObjC code
    and experience we had, and hire a C# programmer to do the Windows
    side of things.

    Gideon King
    <novasoft...>

    On 17/02/2006, at 1:30 AM, Rich Wardwell wrote:

    > No one has mentioned it, but another possible option is  C#/Mono
    > back-end, CocoaSharp (C# bindings to Cocoa) on the front-end for
    > Mac -- Systems.Forms (native Win toolkit) for Windows -- Gtk for
    > Linux.  With some of the more recent versions of Mono, you could
    > use System.Forms (or GTK) on all three systems, but lose the native
    > look & feel obviously.
    >
    > Imeem is using this approach.
    >
    > Rich
    >
    > On Feb 16, 2006, at 6:55 AM, Gideon King wrote:
    >
    >> We used GNUStep/ObjC for the back end, a thin layer of C++ glue
    >> code and C#/.net front end for the Windows version of NovaMind
    >> www.nova-mind.com. The same ObjC back end is used for the Mac
    >> version. Result: very high level of code reuse and complete native
    >> experience on both platforms.
    >>
    >> The only real issues we had apart from the usual familiarization/
    >> general design issues were to do with handling NSImages going back
    >> and forth and being usable in Windows. Oh yes, and we are using
    >> native text layout (actually we wrote our own for windows because
    >> the normal windows font handling is appalling!), so the string
    >> layout metrics were different. Apart from that, it has been a
    >> pretty smooth ride. During the course of the project which started
    >> about 9 months ago and is just now starting the roll out phases,
    >> GNUStep for Windows has matured quite a bit, and it is now much
    >> easier to build and work with than when we started. We have
    >> somewhere around 150,000 lines of code in the cross-platform
    >> portion of the application, and it just works.
    >>
    >> When I started preparing for the port, I wanted to just use
    >> Foundation and stay completely away from AppKit because I had
    >> heard that it was unstable under GnuStep, but I quickly found that
    >> it was pretty much impossible to do the things that I wanted to
    >> do, like complete handling of NSAttributedStrings (which have
    >> things like NSFonts, NSColors etc from AppKit in them), so had to
    >> add AppKit to the mix, but it didn't cause any issues for the
    >> things we have done with it.
    >>
    >> So we have an example of a real world application that was
    >> successfully ported, keeping the lovely Objective-C code for all
    >> the internals and just putting a thin native layer on it to give
    >> the best experience on both platforms.
    >>
    >> The windows version of the application is just a newborn babe
    >> (first release yesterday) and still needs performance tuning, but
    >> the issues that we have looked at regarding performance were
    >> bottlenecks elsewhere in our code - we haven't seen anything of
    >> serious concern speed wise for our application on windows/GNUStep
    >> (yet). We don't have anything that we are doing that is ultra-
    >> specially speed critical, so YMMV.
    >>
    >> Just thought this would be a good data point...
    >>
    >> Gideon King
    >> <novasoft...>
    >>
    >> On 16/02/2006, at 9:31 PM, Markus Hitter wrote:
    >>
    >>>
    >>> Am 16.02.2006 um 03:05 schrieb Andrei Tchijov:
    >>>
    >>>> If you concern about the fact that your GUI should look as close
    >>>> as possible to "native" GUI look, then GNUStep is not the best
    >>>> solution.  Just take a look at this screenshot (http://
    >>>> www.gnustep.org/images/full-screenshot1.png). It does not look
    >>>> anything like Mac OS X.
    >>>
    >>> This is a screenshot from a Linux or *BSD machine. On Mac OS X,
    >>> GNUstep (with the apple-apple-apple libcombo) uses the native
    >>> Foundation/AppKit and gives you a fully native user experience
    >>> accordingly. In fact, GNUstep on Mac OS X is very thin, mostly
    >>> consisting of a make based build system and a bunch of additions
    >>> to Foundation/AppKit to improve compatibility.
    >>>
    >>> For an example, you might wan to check out GNUMail.app: <http://
    >>> www.collaboration-world.com/gnumail/>
    >>>
    >>>
    >>> That said, GNUstep is used and maintained mostly by professional
    >>> developers, so it lacks a three-clicks-to-get-a-working-app
    >>> experience.
    >>>
    >>>
    >>> Markus
    >>>
    >>> - - - - - - - - - - - - - - - - - - -
    >>> Dipl. Ing. Markus Hitter
    >>> http://www.jump-ing.de/
    >>>
    >>>
    >>>
    >>>
    >>> _______________________________________________
    >>> Do not post admin requests to the list. They will be ignored.
    >>> Cocoa-dev mailing list      (<Cocoa-dev...>)
    >>> Help/Unsubscribe/Update your Subscription:
    >>> http://lists.apple.com/mailman/options/cocoa-dev/<novasoft...>
    >>>
    >>> This email sent to <novasoft...>
    >>
    >> _______________________________________________
    >> Do not post admin requests to the list. They will be ignored.
    >> Cocoa-dev mailing list      (<Cocoa-dev...>)
    >> Help/Unsubscribe/Update your Subscription:
    >> http://lists.apple.com/mailman/options/cocoa-dev/<rcw3...>
    >>
    >> This email sent to <rcw3...>
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/<novasoft...>
    >
    > This email sent to <novasoft...>
  • Lately, I've been looking into XUL and XULRunner, which is how
    Mozilla applications like Firefox and Thunderbird were written. From
    what I've figured out so far, XUL looks very similar to the way you
    might write a web application  in HTML and Javascript. However, I
    think XUL has something called XPCOM that allows you to create
    objects that are available through Javascript, so you can also write
    objects in Java or C++ or something if you don't want to write a
    whole application in Javascript.

    However XUL does have some of the non native UI issues you mentioned
    for Java (i.e. the tabs are still real tabs, as in OS 10.1), but I
    don't think its as bad. Open Firefox for an example of a XUL app.

    On Feb 15, 2006, at 4:04 PM, Scott Squires wrote:

    > Curious about how people are dealing with cross-platform issues.
    > Cocoa on Mac to ? on Windows, ? on Linux.
    >
    > If it was a carbon app all/most code would be in C or C++ and UI
    > could be
    > dealt with in at least somewhat similar fashion between platforms.
    > Seems to
    > be one of the potential trade-offs of Cocoa vs Carbon that Apple
    > doesn't
    > address much.
    >
    > I know I can code in C or C++ within Cocoa as well but how are most
    > real
    > Cocoa developers dealing with this and the UI porting issues?  Or
    > are most
    > Cocoa developed apps staying Mac only?
    >
    > Is the potential faster/easier coding in Cocoa(is it?) offset by
    > added time
    > and work to port to other platforms?
    >
    > Thanks.
    >
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/omar%
    > 40roflsoftware.com
    >
    > This email sent to <omar...>
  • I realise that this thread may be of interest to some, but the focus
    of this list is Cocoa.  Please try to keep messages relevant to the
    list.  In particular, discussion of the relative merits of various
    cross-platform technologies, Java user experience etc. are not really
    appropriate; discussion of integration of a C++ back end with a Cocoa
    GUI layer is on topic.

    mmalc
previous month february 2006 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28          
Go to today