Re: Windows and views and controls, oh my!
Re: Windows and views and controls, oh my!
- Subject: Re: Windows and views and controls, oh my!
- From: N!K <email@hidden>
- Date: Wed, 07 Sep 2011 11:19:50 -0700
Thank you. This helps me with higher level issues
On Sep 5, 2011, at 9:42 PM, Quincey Morris wrote:
> On Sep 5, 2011, at 20:43 , N!K wrote:
>
>> The examples I've seen all show a window with a view in it and how to draw in that view. But I want to put up a window with a couple of views in it and draw in them individually, sometimes clearing and redrawing, sometimes adding more drawing.
>
> You're misusing the term "view" and I have to conclude that you've mis-absorbed what a view is.
>
> A view is not so much a construct for breaking apart the visual *appearance* of a window as a construct for organizing the *process* of drawing window contents. That is, views are mostly about apportioning responsibility, and not so much about providing a canvas (although, in the end, they are that too).
>
> In Cocoa, you really don't "draw in" views. Rather, views draw themselves. That's the first conceptual hurdle you need to overcome.
Please pardon my loose terminology. By "draw in," I meant "draw within." I meant using NSBezierpath to create lines which will appear within a view whenever it gets displayed. I didn't mean causing a view to appear. I understand that the system takes care of displaying the views.
>
> The second hurdle is that in Cocoa the view appearance is conceptually redrawn from scratch as necessary. That is, having drawn something, a view doesn't just assume its previous appearance is persistent and can be erased. Instead, the window appearance is achieved by layering the drawing done by each view in a controlled manner, and this happens every time the window contents needs to be drawn or redrawn.
>
> Now, a view certainly *can* cache its own previous visual state (as a bitmap, or via some other intermediate representation), but that sort of thing is generally done only if necessary for performance reasons, because it's a lot more coding work.
>
> Thus, if you have a custom view that draws one or more graphs superimposed, where there is a user option to control which graphs are shown, you don't add a second graph simply by drawing it on top of something that already exists from a previous drawing pass. Instead, you "add" it by redrawing the entire view, but with 2 graphs instead of 1 (except, of course, in the exceptional case already mentioned case of manually caching previous drawing).
This explains the changing process very well.
>
> You say you want to put up a window "with a couple of views in it", but we have no idea what this means. You want to draw a couple of graphs, or something like that? Well, then, your task is about implementing a custom view that draws itself with some kind of custom appearance.
Exactly. making a second view work is where I'm stumbling.
What I'm trying to do is really very simple. I want a pushbutton to seek data input for the model (easily done). Then I want a pushbutton to display two different views of the data.
> That has, typically, very little to do with the mechanics of the window as a whole.
>
>> (Controller code that takes input from pushbuttons and data entry are not a problem.)
>
> FWIW, keep in mind that buttons and text fields are views, too.
Yes.
>
>> Do I need an NSWindow Controller at all?
>
> Nothing in your considerations of views has anything do with the question of whether there's a window controller or not.
>
The reason I ask if a window controller is necessary is that I do not plan to manipulate the window at all. Once it's open, I will leave it alone while "drawing within" the views until quitting. Also, I will not be manipulating the views as a whole. Many examples, notably in Hillegas' books, successfully display views with content in them without using window and view controllers.
> Others may disagree, but I believe that there's basically no reason ever *not* to use a window controller. Its prime function is to load and manage the nib resource file of its associated window, so using a window controller relieves you of the responsibility of writing that management code yourself. Window controllers are also useful as controller objects in the MVC sense (that is, as places to put certain business logic that links the window contents to the data model) and as window delegates (that is, as places to put certain code that customizes some of the window behavior).
I think I haven't encountered a need for the use a window controller. The system loads the nib and window automatically, and I don't know what the business logic might be.
>
>> Ditto NSViewController?
>
> No, view controllers are, paradigmatically, analogous to window controllers except that they manage loadable view resource files rather than window resource files. Unless you are swapping various different views in and out of a window a different times, you most likely will put your view resources in the window nib file, which means they get loaded with the window, and don't need to be separately managed.
>
> It is certainly possible to use view controllers in more subtle ways (such as dividing controller responsibility when there is a lot of controller code). However, for fundamental purposes, you should simply consider that every window nib file should be paired with its own window controller (set as the nib's File's Owner object), and every view nib file should be paired with its own view controller (set ditto).
Does this mean that the window and view controllers are somehow necessary links even though I will not be use them to do anything else? I really don't want to make a big issue of this. If it's avoidable, I'm simply reluctant to add more code that I can screw up. On the other hand, if there's something to be gained (that I'm currently unaware of) for my case I'll go for it. When I look at the docs, I see what the controllers can do but I don't recognize anything I want to do. Then I wonder what I'm missing.
>
>> I tried separate drawRect's in controllers but couldn't make them work.
>
> The 'drawRect:' method belongs in a (custom) view, not in window or view controllers.
Thank you. I didn't express well that when I failed in the views, I even tried in the controllers.
> It is the mechanism via which the view is told to draw itself -- it's something you implement but don't call yourself.
Yes.
>
> At this point you should probably stop trying to understand the Cocoa drawing architecture by examining sample code, and read some essential Apple documents. Start with the NSView Class Reference document, and read everything listed there as a "companion guide". Same thing starting from the NSWindow Class Reference.
Indeed, that was my starting point. I read most of those (and others) and understood how to manipulate windows and views as wholes. If only I wanted to do some of that manipulation! My needs are much simpler. I can easily do one view, but I'm stuck while trying to add the second view and draw within it. The two views (and later, more views) are necessary to organize different looks at the data.
I may have gone too far in trying to use what I learned in the references. For example, I got hung up on changing focus, where to place setNeedsDisplay, and numerous other details. Understanding the items is not difficult, but what to do with them is. Where applicable, examples are extremely helpful in understanding what ought to be done (not just copying), hopefully extendable to cases beyond the examples. I'm sure that they will all turn out to be simple when I get through them, but right now there are so many of them. I share the lament: "Oh my!"
Nick
_______________________________________________
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