Writing GNU-Step compatible Cocoa

  • What Foundation and AppKit classes can I use for a Cocoa based open
    source project, if
    I want it to easily ported to GnuStep?
    ------
    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
    <tommy.nordgren...>
  • On 9 Dec 2007, at 6:26 AM, Tommy Nordgren wrote:

    > What Foundation and AppKit classes can I use for a Cocoa based open
    > source project, if
    > I want it to easily ported to GnuStep?

    To answer that question would require a list of classes and methods
    (GNUstep classes don't implement all Cocoa methods). Surely the
    GNUstep documents provide this?

    — F
  • Am 09.12.2007 um 15:51  schrieb Fritz Anderson:
    > On 9 Dec 2007, at 6:26 AM, Tommy Nordgren wrote:
    >
    >> What Foundation and AppKit classes can I use for a Cocoa based open
    >> source project, if
    >> I want it to easily ported to GnuStep?
    >
    > To answer that question would require a list of classes and methods
    > (GNUstep classes don't implement all Cocoa methods). Surely the
    > GNUstep documents provide this?

      The GNUstep guys have several mailing lists where you can probably
    find people who have already done programs that run in both GNUstep
    and Cocoa and can answer this question. You can find them here:

    <http://www.gnustep.org/information/gethelp.html>

      In general, you can guess that stuff that already was in OpenStep is
    very likely also available on GNUstep, while newer Cocoa stuff usually
    takes a while until it gets added to GNUstep. Also, most uses of
    GNUstep are obviously on non-Mac platforms, so any Apple-specific
    features generally don't make it into GNUstep, or not that quickly, at
    least, because they don't easily map to other platforms without
    looking out of place.

      This includes sheets, drawers, QuickTime, and of course any lower-
    level technologies that aren't part of Cocoa, like pure C-based
    Quartz, CoreFoundation, Carbon-related calls like file manager etc.

      But in the end, you'll just have to look at GNUstep yourself, I
    guess. Even if a framework is generally implemented and supported, the
    odd call may just not have been implemented. But of course you can
    always implement stuff yourself that's missing.

    Cheers,
    -- M. Uli Kusterer
    "The Witnesses of TeachText are everywhere..."
    http://www.zathras.de
  • On Dec 9, 2007, at 7:26 AM, Tommy Nordgren wrote:

    > What Foundation and AppKit classes can I use for a Cocoa based open
    > source project, if
    > I want it to easily ported to GnuStep?

    The GNUstep documentation for their classes is your best bet.  Barring
    that, the source is available as well, so a quick grep of the
    appropriate header and source files will probably tell you what you
    need to know.  Be on the look out for stubbed, do-nothing methods that
    are often included, usually in AppKit, to ease porting efforts but may
    effect functionality you require (e.g., attributed string tooltips
    that might not actually provide tooltips).  GNUstep also tends to
    progress more incrementally, whereas Cocoa tends to make one big leap
    (10.4 -> 10.5).

    You might want to take a look at my RegexKit project, http://regexkit.sourceforge.net/
      I'm not a GNUstep expert, not even remotely, but I choose to
    include GNUstep as a target as a gesture of goodwill and as a
    debugging aid: being able to compile on platforms other than mac/cocoa
    tends to smoke out portability issues and obscure bugs, making for
    higher quality code.  The same can be said for targeting an
    independent implementation of Foundation.  I also happen to target
    Core Foundation, and I figure if the unit tests can pass when using
    Core Foundation, Cocoa's Foundation, and GNUstep's Foundation on a
    different architecture, OS, and compiler, there's probably less bugs.

    From the RegexKit title, it should be obvious that the framework
    deals with regular expressions.  That said, it should be obvious that
    I only use Foundation, no AppKit (except for some minor things, like
    adding a tooltip to an attributed string 'pretty' error message).
    That said, there's only a few cases off the top of my head where I've
    had to explicitly do Cocoa / GNUstep #ifdef'd code: NSNumberFormatter
    differences (10.4 greatly expanded cocoa's NSNumberFormatter) and an
    observed objc runtime +initilize behavior difference in class
    categories. Those are the big ones that stick out in terms of API
    mismatches, so in other words, I've found the Foundation portion to be
    practically identical for my needs.

    I've managed to hide a lot of other, smaller differences behind pre-
    processor macros.  I #defined my own NSInteger equivalent, RKInteger,
    which just maps to the appropriate native equivalent.  The need to run
    on 10.4 provided the backbone of NSGarbageCollector compatibility: the
    primary class checks to see if the NSGarbageCollector is available and
    if GC is enabled and sets a global variable that isn't exported from
    the framework on the status.  Under GNUstep, NSGarbageCollector is
    never available, so there is a #if conditional that either creates an
    'extern int gc_status' like variable, or '#defines gc_status 0'. This
    causes the conditional statements that need to take different actions
    based on whether or not GC is active to become static, and the
    compiler optimization pass will simply eliminate the alternative that
    will never be executed.  There's also some macros for handling
    retain / release / autorelease and malloc / free (so
    NSAllocateCollectable can be conditionally used, if appropriate),
    along with a conditional memmove (cocoa's GC requires a special GC
    aware memmove be called).  The details of what happen are hidden
    behind a RK_MACRO(), which are used as if you were programming for
    just the retain / release methodology, substantially cleaning up code
    (no big #if blocks littering the source for all the different
    scenarios).

    In short, you might find a few nuggets here and there for dealing with
    Cocoa / GNUstep compatibility, but overall I've found adding, and
    keeping, GNUstep compatibility to be a non-issue.  Come to think of
    it, I've only had two real problems: Writing a GNUstep Makefile, which
    seems to be completely undocumented, and finding a version of OCUnit
    that was old enough to compile on another platform. I had to add some
    macro wrappers because STAssert* and friends are later additions, and
    everything switched to @try / @catch, and I wasn't interested in back
    porting.  Even the objc runtime has been a non-issue for my needs.
  • On Dec 10, 2007 12:11 AM, John Engelhart <john.engelhart...> wrote:
    [...]
    > it, I've only had two real problems: Writing a GNUstep Makefile, which
    > seems to be completely undocumented, and finding a version of OCUnit
    [...]

    One problem with GNUstep is not lack of documentation but the lack of
    consistency with respect to where documentation can be found.

    While there is a reasonably well kept Wiki at http://wiki.gnustep.org/
    occasionally you will have to go out of your way to find documentation
    on specific parts, like writing Makefiles for GNUstep:
    http://www.gnustep.it/nicola/Tutorials/WritingMakefiles/

    --
    Chris
previous month december 2007 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 29 30
31            
Go to today