• 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: NSDocument-based app limitations?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSDocument-based app limitations?


  • Subject: Re: NSDocument-based app limitations?
  • From: mmalcolm crawford <email@hidden>
  • Date: Mon, 29 Mar 2004 23:09:07 -0800

On Mar 29, 2004, at 10:35 PM, Mark Munz wrote:

On Mar 29, 2004, at 10:24 PM, Scott Anguish wrote:

On Mar 29, 2004, at 10:44 PM, Mark Munz wrote:
I sure wish TextEdit would have been written as an NSDocument-based application, or maybe it can't be?
TextEdit predates NSDocument by a good bit, which is why it isn't written with it.
For me, seeing a good example (like TextEdit) that uses NSDocument would I think
1. Show how to do some very common tasks in a document-based program
2. Show some of the weaknesses in the current NSDocument model so they could be improved

It's not clear why you think there are weaknesses in the current model, and what you think they are?

Sketch does use the document model, and provides a reasonable example.


So I'll rephrase my main question. Can I dynamically change the filetypes that show up in the save dialog? Do I hack in and muck with the UI elements (doesn't seem the "right way" -- but maybe that's the way everyone does it)? Or do I have to by-pass the whole NSDocument code completely and do it myself (like TextEdit does)?

Why do you need to dynamically change the filetypes?

I keep thinking that I must be missing something obvious for this type of behavior.
Or is it better to create another subclass for my RTF-type document --making it harder to switch between plain and RTF text, but perhaps solving the save as filetype problem with showing all types. That creates new UI issues -- like requiring two "new document" menu items since they would be very different documents now.
Or should I just abandon the whole NSDocument model and do what TextEdit does?

It might be better to ask straightforward questions rather than posit weaknesses in the architecture.

<http://developer.apple.com/documentation/Cocoa/Conceptual/Documents/ Concepts/DocTypePList.html> and other accompanying documentation describes the use of document types information -- it also notes:

"The TextEdit application is unusual in that its a document-based application that doesnt subclass NSDocument, so the dictionaries in Listing 1 dont specify a document class name. However, document-based Cocoa applications typically do subclass NSDocument and should specify the document class name to handle each specific document type the application can view or edit."

mmalc
_______________________________________________
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.


  • Follow-Ups:
    • Re: NSDocument-based app limitations?
      • From: Mark Munz <email@hidden>
    • Re: NSDocument-based app limitations?
      • From: Chris Ridd <email@hidden>
References: 
 >NSDocument-based app limitations? (From: Mark Munz <email@hidden>)
 >Re: NSDocument-based app limitations? (From: Scott Anguish <email@hidden>)
 >Re: NSDocument-based app limitations? (From: Mark Munz <email@hidden>)

  • Prev by Date: RE: Using IP or hostname for NSConnections rootProxyForConnectionWithRegisteredName:host:
  • Next by Date: Re: NSURL and lingering FTP processes
  • Previous by thread: Re: NSDocument-based app limitations?
  • Next by thread: Re: NSDocument-based app limitations?
  • Index(es):
    • Date
    • Thread