Re: NSDocument-based app limitations?
Re: NSDocument-based app limitations?
- Subject: Re: NSDocument-based app limitations?
- From: Mark Munz <email@hidden>
- Date: Tue, 30 Mar 2004 00:46:38 -0700
On Mar 30, 2004, at 12:09 AM, mmalcolm crawford wrote:
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.
I see not being able to dynamically manipulate the list of filetypes as
a weakness. TextEdit gets around this by doing everything by hand.
Sketch shows how to use a document model, but again it's very simple
(one document type -- no dynamic changes to the type of document).
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?
Well, there's a fundamental difference between plain text files and
Rich Text files. One way to accomplish this is via TextEdit's switch on
the fly design. Another way is to create distinct document types. The
downside of the ladder approach is that it requires the user to decide
up front which type they want and if they want to change after the
initial creation, it's more difficult to switch between the two (UI
experience wise).
Another example that might also require dynamically setting up the
filetypes supported -- plug-in filters that support additional type
conversions as save.
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."
--------
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)?
The above all seemed like very straightforward questions. The original
email (look at the thread) I posted also ask specific questions to try
to solve the same issue. So you jumped into the middle of the
discussion and just assumed that all I did was complain about the
weakness in the architecture.
Yes, I've read the above documentation as well and I know that TextEdit
isn't an NSDocument based application (that was made cleaner in both my
original message & the reply to Scott's). What I am looking for is
information on doing something beyond simple document that all the
books & sample code talk about.
Mark
_______________________________________________
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.