• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Use of AppKit in command-line app on headless node
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use of AppKit in command-line app on headless node


  • Subject: Re: Use of AppKit in command-line app on headless node
  • From: Rick Hoge <email@hidden>
  • Date: Tue, 12 Aug 2008 13:28:30 -0400



Thanks again for that very detailed post - I know it sounds like I'm being lazy, but there are other parts of the app that would have to be redesigned to allow the possibility for code use under headless conditions and it's really important to me to know why this is necessary. What you said goes a long way toward clarifying the underlying issues. Obviously I'm not going to risk it now.

...


One obvious alternative is to create a 'Data Object' class that has no
AppKit dependencies and stash it as an instance variable in a 'thin'
NSDocument subclass that just supports tasks relating to a real
document-based app in a window server environment. To make my app work, I
need two layers of subclass for my documents (a general NSDocument subclass
and several subclasses of this for specific data types) so it's a bit more
tricky. I'd need to have a data object class hierarchy and a parallel
document hierarchy.

If all of the smarts are in your own custom classes, why do you need a hierarchy of NSDocument subclasses? Have a single NSDocument subclass that passes all of the important methods on to your custom classes, and your job should be done.

The way the app was originally designed, the top level NSDocument subclass implements custom functionalities used by all document types. There are a few different types of document/data that are related, but different enough that it has worked well to use separate subclasses to implement them. For example different nib files are loaded depending on the document type (something that would go in the NSDocument subclass), and the data model is different (something which would go in the data object class).


Rick



Mike
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

(43092.6825)

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Use of AppKit in command-line app on headless node
      • From: "Michael Ash" <email@hidden>
References: 
 >Use of AppKit in command-line app on headless node (From: Rick Hoge <email@hidden>)
 >Re: Use of AppKit in command-line app on headless node (From: Rick Hoge <email@hidden>)
 >Re: Use of AppKit in command-line app on headless node (From: "Michael Ash" <email@hidden>)
 >Re: Use of AppKit in command-line app on headless node (From: Rick Hoge <email@hidden>)
 >Re: Use of AppKit in command-line app on headless node (From: "Michael Ash" <email@hidden>)

  • Prev by Date: Re: Accessing memory of another application?
  • Next by Date: Re: Accessing memory of another application?
  • Previous by thread: Re: Use of AppKit in command-line app on headless node
  • Next by thread: Re: Use of AppKit in command-line app on headless node
  • Index(es):
    • Date
    • Thread