Re: NSDocument and a 'persistent profiles palette'
Re: NSDocument and a 'persistent profiles palette'
- Subject: Re: NSDocument and a 'persistent profiles palette'
- From: Fritz Anderson <email@hidden>
- Date: Thu, 7 Jun 2007 13:11:52 -0500
I offer ideas, not solutions...
You're setting yourself up to fight NSDocument. You'd have to
subclass and override so much to suppress features that it's easier
to have your own file structure, and build a custom class up from there.
What you're really intending is a reinvention of iTunes. iTunes
ordinarily keeps all of the albums (student profiles) in subfolders
of a library folder, and songs (recordings) within the album
(student) folders, with a file at the root of the library to identify
and organize the songs.
You may (depending how your application performs) have two layers of
organization, one for per-student lists, and another above it for per-
teacher lists. All the library files have an obvious way to rebuild
themselves (by traversing their subdirectories) if they get out of
sync with the contents.
iTunes doesn't really have a document interface for individual songs.
It will play an MP3, but in doing so it adds a file reference to the
library file. NSDocument wouldn't come into play with iTunes anyway,
as it is a Carbon application.
In iTunes, there's only one library per user. If you need more than
one library for a user, you'll have to offer an interface to choose
among them. NSOpenPanel may be awkward for this unless you package
the library folders (and sacrifice the ability to open student/
performance files from the Finder*); another option would be to keep
a list of libraries in ~/Library/Application\ Support, and offer a
choice from that list.
* You could have libraries keep aliases (Google BDAlias) to student
or performance files the user stores randomly, but that makes it
harder to keep library listings in sync with additions and deletions
of files. What you _can't_ let happen upon import is two files, one
pre-import, and a copy in your library hierarchy. Your user _will_
edit the pre-import copy and not understand why the changes don't
appear in the library.
I'm not sure what you mean by "palette-style window." Do you mean a
floating window with a tiny title bar? Palettes make sense as shared
inspectors/adjective editors for whatever might be the current
selection in the current document window. The library-management
window you envision doesn't inspect or edit the contents of other
windows at all. It should have a document-style window; conceptually
it edits a (possibly singleton) library, the contents of which it
displays.
I'm not saying the library window has to edit or play individual
performances; you can make a selection there and [double-click | File-
>Open Selection | Open button] to open a window for the selection.
Have your student object be an NSResponder, and make it first
responder, with an "import:" method, when a student is selected; or
if there is no selected student, have the library window's delegate
(the Library object) implement "import:". Have File->Import... send
import:, and the right thing will happen.
For ideas on how to manage hierarchical packages, browse NSFileWrapper.
— F
On 5 Jun 2007, at 4:56 PM, Hans Kuder wrote:
[Managing atomic recordings within a student wrapper within a teacher
wrapper...]
As sort of an auxiliary function, though, the app needs to allow a
voice
teacher to be able to manage a list of his or her students'
"profiles" - to
be able to save new recordings under a student's profile, to add new
profiles for new students, to load recordings from a profile into the
analysis/synthesis engine, and so on. I'd like for this
functionality to be
contained in a single palette-style window, with a list of the
teacher's
students on the left and all of the selected student's past
recordings,
information, etc. on the right. All of this information should be
persistent
across multiple sessions of the app, so I need a way to save both
individual
profiles and the entire list of the teacher's students' profiles.
I've got a pretty robust class that encapsulates a single student's
profile,
and I've got the palette interface all set up and ready to bind,
but I'm
having trouble trying to figure out how to go about managing the
loading/unloading of a set of profiles. I'm hoping to make each
profile a
subclass of NSDocument, but my understanding is that each
NSDocument has its
own window, which I don't want. Is there a way to override this and
have
each document "register" with the NSArrayController I'm using to
manage the
palette? Is it possible to store all of the active profiles/
documents in the
user's preferences and have them loaded at launch time?
I also thought about making the entire set of profiles one NSDocument
subclass, but I'm not sure if that would give me enough fine-
grained control
over adding/importing recordings to an individual profile. Also, I
don't
really think NSDocument fits at this level, since it doesn't make
sense to
have multiple palettes open. Would anybody recommend this approach
over the
former?
Any other ideas? This is the first project of this scale where I've
needed
this sort of document-based functionality, and I could use all the
help I
can get.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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