Re: NSDocument and NSViewControllers

[Jerry Krinock]

> On 2015 Dec 04, at 16:32, Rick Mann  wrote:
> 
> I have an NSViewController subclass and SCNView subclass. I can get at the 
> document from the NSViewController subclass via a rather cumbersome "let doc 
> = self.view.window?.windowController?.document as? ModelDocument”

I just happened to have done that yesterday afternoon.  It seemed like the most 
logical approach to me.  “Going to the source”, even via a circuitous key path, 
is usually more robust than adding properties for convenience.

Just make sure you can guarantee that the window and view have been loaded 
previously in your situation, or you’ll get nil.  I’ve also used that as a key 
path in Cocoa Bindings.  In that case, it’s usually OK to return nil initially.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSDocument and NSViewControllers

[Quincey Morris]

On Dec 5, 2015, at 12:20 , Rick Mann  wrote:
> 
> I'll probably make the document a delegate of the view controller so it can 
> be informed of changes to the model.

This may not apply to your app, but what I usually end up doing in an app of 
any complexity is have (essentially) two data models. The “real” one belongs to 
the document. Then there’s a “derived” data model (usually in the window 
controller in the past, but possibly in the new, enhanced view controllers in 
the future) which rearranges the document data model suitably for the 
particular UI that the particular window UI finds convenient.

This is kind of duplicate effort (though not duplicate data, mostly, because 
the “derived” data model really is only a wrapper around the real one), but it 
tends to simplify the UI code a lot. For example, if the real data model is 
flat but the UI displays the data hierarchically, it may be easier to have an 
outline view connected to a hierarchical data structure. Or if data model 
values need to be transformed into displayable strings in customizable ways, it 
can be done in the derived data model.

Or (and this can be a fairly important issue) undo groupings are really 
structured by the UI, even though undo actions are associated with the 
document. It often makes more sense to have the window controller decide how to 
package (and how to name) undoable sequences, rather than leaving it to the 
granularity of document model property updates.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSDocument and NSViewControllers

[Rick Mann]

> On Dec 5, 2015, at 05:24 , Jerry Krinock  wrote:
> 
> 
>> On 2015 Dec 04, at 16:32, Rick Mann  wrote:
>> 
>> I have an NSViewController subclass and SCNView subclass. I can get at the 
>> document from the NSViewController subclass via a rather cumbersome "let doc 
>> = self.view.window?.windowController?.document as? ModelDocument”
> 
> I just happened to have done that yesterday afternoon.  It seemed like the 
> most logical approach to me.  “Going to the source”, even via a circuitous 
> key path, is usually more robust than adding properties for convenience.
> 
> Just make sure you can guarantee that the window and view have been loaded 
> previously in your situation, or you’ll get nil.  I’ve also used that as a 
> key path in Cocoa Bindings.  In that case, it’s usually OK to return nil 
> initially.

Depending on how this shapes up, I think I'm going to try to go the opposite 
route. That is, there will be a top-level view controller subclass that knows 
how to deal with one aspect of the document data. I will try to package up that 
aspect in a model object(s), and hand that to the view controller when its 
window gets created. The ideas is that the NSDocument is a client of the view 
controller, not the other way around. I'll probably make the document a 
delegate of the view controller so it can be informed of changes to the model.

This approach makes it easier to re-use the view controller in another app.

I think.


-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSDocument and NSViewControllers

[Rick Mann]

> On Dec 5, 2015, at 12:40 , Quincey Morris 
>  wrote:
> 
> On Dec 5, 2015, at 12:20 , Rick Mann  wrote:
>> 
>> I'll probably make the document a delegate of the view controller so it can 
>> be informed of changes to the model.
> 
> This may not apply to your app, but what I usually end up doing in an app of 
> any complexity is have (essentially) two data models. The “real” one belongs 
> to the document. Then there’s a “derived” data model (usually in the window 
> controller in the past, but possibly in the new, enhanced view controllers in 
> the future) which rearranges the document data model suitably for the 
> particular UI that the particular window UI finds convenient.
> 
> This is kind of duplicate effort (though not duplicate data, mostly, because 
> the “derived” data model really is only a wrapper around the real one), but 
> it tends to simplify the UI code a lot. For example, if the real data model 
> is flat but the UI displays the data hierarchically, it may be easier to have 
> an outline view connected to a hierarchical data structure. Or if data model 
> values need to be transformed into displayable strings in customizable ways, 
> it can be done in the derived data model.

Not a bad way to look at it. I'll see what makes sense as I go forward. This is 
a utility app for use inside my company, so it's inevitably going to grow 
organically. I can just foresee many of the aspects right now.

> 
> Or (and this can be a fairly important issue) undo groupings are really 
> structured by the UI, even though undo actions are associated with the 
> document. It often makes more sense to have the window controller decide how 
> to package (and how to name) undoable sequences, rather than leaving it to 
> the granularity of document model property updates.

Yeah, I think you're right about this.

-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSDocument and NSViewControllers

[Rick Mann]

I have a very complex "document" that I'm writing an editor for. It's a 
collection files, lending itself to the bundle document style. I use 
NSFileWrappers, and when I open one of these in my app, I get called to read 
the contents. I don't have to read every file all the time, it depends on what 
aspect the user is editing.

One part of the document is a 3D mesh file. I'm using SceneKit to display it, 
and I have an NSViewController subclass and SCNView subclass. I can get at the 
document from the NSViewController subclass via a rather cumbersome "let doc = 
self.view.window?.windowController?.document as? ModelDocument".

But NSViewController has a "representedObject". This suggests something outside 
the VC can inject the model into the VC, improving decoupling between the VC 
and the NSDocument subclass. But I don't see any good way to get at the VC, 
except in makeWindowControllers(). Is that the right place?

Part of the issue is that I may have multiple windows possible for each 
document (like I said, it's quite complex). Certainly multiple views, and I'm 
not a big fan of Xcode-style all-in-one-window UIs. It might work better in 
this particular case, since it's much more rare the user needs multiple aspects 
open simultaneously (like, multiple source files). In any case, a particular 
window may never be opened, so I don't want to make all the window controllers 
at once.

What do most people do in this situation?

TIA,

-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Using NSDocument with NSViewControllers

[Paul Thomas]

Before I set off down the road to frustrating deadendsville, has  
anyone any experience with trying to coerce AppKit's document  
architecture into a single window interface - i.e. using tabviews in  
stead of separate windows?


A sneaky look at a couple of apps shows that people have usually  
resorted to completely custom classes, but I'd like to use NSDocument  
if possible - just with views instead of windows.


Is it possible?

ta,
pt. 
___


Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Using NSDocument with NSViewControllers

[Ross Carter]

On Oct 23, 2008, at 3:07 AM, Paul Thomas wrote:

Before I set off down the road to frustrating deadendsville, has  
anyone any experience with trying to coerce AppKit's document  
architecture into a single window interface - i.e. using tabviews in  
stead of separate windows?


A sneaky look at a couple of apps shows that people have usually  
resorted to completely custom classes, but I'd like to use  
NSDocument if possible - just with views instead of windows.


Is it possible?



I've done it, although my implementation is not yet bug-free. Smarter  
developers might know an easier way, but for me it was a lot of work,  
and I can't say that I saved any effort by working with NSDocument  
instead of a custom class. FWIW, here are some of the methods I had to  
override:


NSWindowController -document, -windowDidLoad, -windowWillClose:, - 
windowDidResignMain:, -windowDidBecomeMain:, -windowDidResize:


NSDocumentController -openDocumentWithContentsOfURL:display:error:, - 
openUntitledDocumentAndDisplay:error:, - 
makeUntitledDocumentOfType:error:, - 
reviewUnsavedDocumentsWithAlertTitle:cancellable:delegate:didReviewAllSelector:contextInfo 
:


NSDocument - 
canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:


The biggest problem was window closing behavior and making sure the  
user gets prompted to save changes for each document in the window.


I didn't use NSViewController.

Ross
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]