Re: How to properly flip a UIView's coordinate system
On Sep 21, 2013, at 22:38 , Markus Spoettl wrote: > I have a UIView on iOS that shares (a lot of) code with an NSView I have on > OSX. That code relies on a LLO (lower left origin) coordinate system and it's > not an option to change that. What’s the code? Mostly drawing? > So I transform the coordinate system of the view by setting > > [self setTransform:CGAffineTransformMakeScale(1, -1)]; > in the UIView variant's -initializer. That works well, it effects all areas > of view code the right way, including drawing and touch-events. Just what I > want. Or so it seems. Yeah, I have to admit I haven’t been too happy with View coordinate system transformations in general. I just do the transform in the drawing code ( MPWView and MPWDrawingContext handle this automatically). Since event handling code is quite distinct anyhow, I so far haven’t had a burning desire to exploit commonality there, but I’d probably do the transform “by hand” as well (encapsulated so I do it once). Again, since you have different methods to start with, just define your own coordinate system for your own methods and map what the system gives you to that in the system-specific event methods. Marcel ___ 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: How to properly flip a UIView's coordinate system
On 22 Sep 2013, at 16:18, David Rowland wrote: > > On Sep 22, 2013, at 4:20 AM, Dave wrote: > >> >> On 21 Sep 2013, at 21:38, Markus Spoettl wrote: >> >>> Hi, >>> >>> I have a UIView on iOS that shares (a lot of) code with an NSView I have on >>> OSX. That code relies on a LLO (lower left origin) coordinate system and >>> it's not an option to change that. >> >> I'm in a similar position, in fact I have a lot of code that is ULO based >> and a lot of code that is LLO based. If I has only a single wish that would >> enable me to change something about Cocoa it would be that it always ULO or >> as a second wish that iOS used LLO as well. >> >> I'd really like to know why LLO was chosen for the Mac in the first place, >> and, why in iOS they chose to do the opposite? >> >> Anyone understand why/how this happened? > > The earliest interface was the Teletype machine. It used a roll of low-grade > paper and could print 80 characters on one line. Carriage return moved the > print head to the first column, line feed moved the paper up one line. > > The first electronic terminals were often "glass teletypes" with 80 columns > and 24 rows. The cursor could be placed anywhere, and the convention was line > 1 at the top and line 24 at the bottom. I believe that is where the inverted > coordinates began. Bitmapped screens mimicked the TTY. Later creations like > OpenGL respected the older, mathematical model, and we are now caught between. No, I worked on these early teletype emulators, they had 0,0 (e.g. VT100 and friends) as top left on the ones that could address the cursor!. Dave ___ 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: How to properly flip a UIView's coordinate system
On 22 Sep 2013, at 21:36, Kyle Sluder wrote: > On Sep 22, 2013, at 4:20 AM, Dave wrote: >> >> >>> On 21 Sep 2013, at 21:38, Markus Spoettl wrote: >>> >>> Hi, >>> >>> I have a UIView on iOS that shares (a lot of) code with an NSView I have on >>> OSX. That code relies on a LLO (lower left origin) coordinate system and >>> it's not an option to change that. >> >> I'm in a similar position, in fact I have a lot of code that is ULO based >> and a lot of code that is LLO based. If I has only a single wish that would >> enable me to change something about Cocoa it would be that it always ULO or >> as a second wish that iOS used LLO as well. >> >> I'd really like to know why LLO was chosen for the Mac in the first place, >> and, why in iOS they chose to do the opposite? > > Because OS X is derived from NEXTSTEP, which used Display PostScript as its > windowing system. PostScript has a lower-left origin because that's how > Cartesian coordinate systems are often defined, including those used on > plotters. > >> >> Anyone understand why/how this happened? >> >> Also, given that you have code what is written for both systems, how have >> people dealt with this? > > If you're just drawing using Core Graphics, you can flip the CTM and get the > right results. But if you have subviews or sublayers, you're hosed. > > Just so you know, OS X supports both origins. AppKit exposes > -[NSGraphicsContext isFlipped] and -[NSView isFlipped], so coordinate-space > agnostic code does a lot of `y = [self isFlipped] ? CGRectGetMinY(…) : > CGRectGetMaxY(…)`. A, yes that makes sense, thanks a lot. All the Best Dave ___ 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: Strange behaviour of iPhone
On 21 Sep 2013, at 19:25, "Mills, Steve" wrote: >> On Sep 21, 2013, at 13:22, "Dave" wrote: >> >> A similar gotcha is when you declare a local with the same name as an >> instance variable. > > That's why I prefer it when instance vars are named as such. I dislike the > Microsoftish m_var. my old job used iVar, which was a lot easier to type. Yes, me too, I prefix IVar with "m" or more recently "iv". Cheers Dave ___ 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
View hierarchy, documentation, and origin location.
Xcode 4.6.3, OS X Lion 10.7.5, my Document app for OS X
Here are quotes from the View Programming Guide 2013-08-08
"By default, the graphics environment origin (0.0,0.0) is located in the lower
left,…." page 11
"The frame rectangle defines the view's location and size in the superview
using the superview’s coordinate system.
The bounds rectangle defines the interior coordinate system that is used when
drawing the contents of the view, including the origin and scaling." page 12
"The content view acts as the root of the visible view hierarchy in a window."
Page 17
I understand the above.
My code: (N.B. I need to create the Matrix programatically because of the
prototype Cell).
- (void)windowControllerDidLoadNib:(NSWindowController *)aController {
[super windowControllerDidLoadNib:aController];
// Add any code here that needs to be executed once the windowController
has loaded the document's window.
// Get the initial content view size so as to
// (a)compute where to place the matrix and
// (b)what size to make the matrix cells
// Local vars for this method
NSWindow *theWindow = [aController window];
NSView *theContentView = theWindow.contentView;
NSRect theContentFrame = theContentView.frame;
NSRect theMatrixFrame = NSInsetRect(theContentFrame, 40.0, 40.);
Cell *protoCell = Cell new];
// Instance vars
_theMatrix = [[Matrix alloc]initWithFrame:theMatrixFrame
mode:NSListModeMatrix prototype:protoCell
numberOfRows:3 numberOfColumns:3];
[theContentView addSubview:_theMatrix];
}
My questions:
(0) Given the above documentation why is the matrix drawn at top left (indented
of course)?
The default location is stated to be lower left.
(1) Is the contentView's superView the screen?
And thus the contentView uses the screen's origin co-ordinates which are top
left?
TIA
Peter
PS: If my memory is correct, from the beginning of Mac OS up till OS X the
origin was top left.
___
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: View hierarchy, documentation, and origin location.
What I believe you're wanting to know is that cells in a matrix have their row-column coordinates start from the top left, so the cell at (0,0) is in the top left of its enclosure matrix and the cell at row 1 column 0 is below it. -- Gary L. Wade (Sent from my iPhone) http://www.garywade.com/ On Sep 23, 2013, at 9:09 AM, Peter Teeson wrote: > (0) Given the above documentation why is the matrix drawn at top left > (indented of course)? > The default location is stated to be lower left. ___ 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: View hierarchy, documentation, and origin location.
On 23 Sep 2013, at 17:09, Peter Teeson wrote: > > Peter > > PS: If my memory is correct, from the beginning of Mac OS up till OS X the > origin was top left. Yes, Quartz changed it to be bottom left for some crazy reason - maybe just to be different and upset off the Carbon developers of the day! Dave ___ 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: Deficiencies in UIKeyCommand
On Mon, Sep 23, 2013, at 10:40 AM, Gordon Apple wrote: > > I don¹t know whether to file a bug report or an enhancement request for > these. They're pretty much the same thing. Don't let the distinction hold you back from filing anything at all. File early, file often. That's the only way you have any hope of showing Apple what issues affect you. --Kyle Sluder ___ 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: View hierarchy, documentation, and origin location.
On 23 Sep 2013, at 19:50, Gerd Knops wrote: > Probably more to do with the NeXTSTEP/OPENSTEP ancestry. Those used Display > Postscript with the origin being the bottom left. > > Gerd Yes, you're right it was because of PostScript, although you'd chose to an upside down screen coordinate system (as compared to the rest of the world) is beyond me! Surely it would have been better to translate the PostScript coordinate into top left origin? Oh well, such is life….. Still isFlipped thing makes it much easier to handle, I wish I'd know about it before! The problem I had at the time if my memory serves me correctly was that I wanted to render Core Text into UIViews and (again AFAIR), Core Text expects Bottom Left Origin. This was under iOS 4, not sure how it would work under 6+. Question, is it possible to "flip" the CF coordinate system under iOS, so that both (UIView etc. and CF) operate with a Top Left Origin? Cheers Dave ___ 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
iOS 7 Extend Edges View Controller Property
Hi, I'm trying to get an app to look ok under iOS 7, the first problem was that it overrode wantsFullScreenLayout and always returned NO, I removed this and the next problem was that the views were messed up because the Status Bar isn't taken into account. I have 35+ View Controllers and they all have: Extend Edges, Under Top Bars = On, and Under Bottom Bars = On, under Opaque = Off. If I turn Under Top Bars Off, then things begin to look a lot nicer. Question, is it better to go through all 35+ VC's in the Storyboard turning "Under Top Bars" Off, or is it better to do it conditionally in code. All these VCs inherit from a common base VC, so I could just put the code in the Base VC I think, but then I suppose the VC when opened with IB, won't look right? The other problem I have is that the Status Bar disappears when I run the App, a heads up on this one would be appreciated if anyone has encountered this problem and fixed it, otherwise this one is next on my hit list. iOS 7 couldn't have been released at a worse time for this app! They are just about to go live and everything had been signed off and working under iOS 6! Such is life! All the Best Dave ___ 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: View hierarchy, documentation, and origin location.
Probably more to do with the NeXTSTEP/OPENSTEP ancestry. Those used Display Postscript with the origin being the bottom left. Gerd On Sep 23, 2013, at 1:19 PM, Dave wrote: > > On 23 Sep 2013, at 17:09, Peter Teeson wrote: >> >> Peter >> >> PS: If my memory is correct, from the beginning of Mac OS up till OS X the >> origin was top left. > > Yes, Quartz changed it to be bottom left for some crazy reason - maybe just > to be different and upset off the Carbon developers of the day! > > Dave > > > ___ > > 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/gerti-cocoadev%40bitart.com > > This email sent to gerti-cocoa...@bitart.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: View hierarchy, documentation, and origin location.
> On Sep 23, 2013, at 9:09 AM, Peter Teeson wrote: > > My questions: > (0) Given the above documentation why is the matrix drawn at top left > (indented of course)? What’s _theMatrix’s frame? It could either have an origin that puts it at the top, or it could draw its content in its upper-left and have a size that fills the superview, or its superview could return YES from -isFlipped. > The default location is stated to be lower left. See -[NSView isFlipped]. > > (1) Is the contentView's superView the screen? No, it’s the window’s private NSThemeFrame, or nil if the window is borderless. Windows and screens are not views. > And thus the contentView uses the screen's origin co-ordinates which are top > left? Flippedness does not cascade; every NSView’s bounds coordinate system is independent. If a view returns NO from -isFlipped, then drawing at (0,0) in that view’s bounds will always draw at the lower left of that view, regardless of whether any ancestors return YES from -isFlipped. --Kyle Sluder ___ 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
Deficiencies in UIKeyCommand
UIKeyCommand is a welcomed addition to iOS when using an external keyboard. However, there seems to be a few deficiencies in its functionality: 1. F-keys. Is there any way to snag an F-key command with UIKeyCommand? You have to specify a string. Is there a way to do this? 2. Repeat keys. Some work, some don¹t. UITextView will respond to character key repeats, and to left/right arrows to move the insert along a line. But is doesn¹t support up/down arrow keys. (Pages does this just fine.) So we subclassed UITextView and added key commands and our own code to allow the insert to move up/down from the current line, keeping as close to the original insert horizontal offset as possible. However, it¹s a one-shot operation, no key repeats. Is there any way to fix this? I don¹t know whether to file a bug report or an enhancement request for these. ___ 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: Correct usage of NSTextView and NSFindBar
On Sep 20, 2013, at 10:15 PM, Martin Hewitson
wrote:
> Actually, I got this wrong. I swap out the textstorage in the textview by
> calling setTextView on the textContainer which I get from the textStorage
> that belongs to the file instance being edited. This is probably why I'm
> bypassing the 'notification' chain. Perhaps I'm going about this 'one editor
> for many files' problem the wrong way because looking back at (very) old code
> I get the textContainer by doing
>
> - (NSTextContainer*)textContainer
> {
> // An ugly quick hack to return the 'main' text container for this
> document
> return [[self.textStorage layoutManagers][0] textContainers][0];
> }
>
> Is there a better way to do all this?
That seems a little backwards to me.
NSLayoutManager is really the center of the Cocoa text architecture. It manages
the list of NSTextViews, the list of NSTextContainers (those two objects are
associated 1-to-1), and the NSTextStorage that will be rendered and laid out
between all of the NSTextViews. It sounds like you're assuming there's a 1-to-1
association between NSTextStorage and NSTextContainer objects, which I don't
think is true. The NSTextContainer's job is to define the region in which the
text should be rendered—it doesn't really have anything to do with the string
itself. Thus, instead of doing this to swap out your NSTextStorage:
[textView setTextContainer: ];
… it would make more sense to me to do:
[textView.layoutManager replaceTextStorage: newTextStorage];
Take a look at
https://developer.apple.com/library/mac/documentation/TextFonts/Conceptual/CocoaTextArchitecture/TextSystemArchitecture/ArchitectureOverview.html#//apple_ref/doc/uid/TP40009459-CH7-SW1
for more in-depth information.
-KP
> Many thanks,
>
> Martin
>
>
> On Sep 21, 2013, at 06:52 AM, Martin Hewitson
> wrote:
>
>> Ah, that's very useful information. I actually maintain multiple
>> NSTextStorage instances, one for each file that's being managed, and swap
>> those in and out by doing setTextView on the storage instance. So is this
>> somehow bypassing the chain of notifications that tells NSTextFinder that
>> the string changed? Any way around that?
>>
>> Many thanks,
>>
>> Martin
>>
>>
>>
>>
>> On Sep 20, 2013, at 07:37 PM, Kevin Perry wrote:
>>
>>>
>>> On Sep 20, 2013, at 10:00 AM, Martin Hewitson
>>> wrote:
>>>
Dear list,
I have an editor app which presents a list of files that can be edited.
Selecting a file displays the text contents in an NSTextView subclass. On
10.7 and later the app supports using the FindBar. Searching the currently
displayed text works fine the first time the find bar is used. But if
another file is selected (so that the text in the textview changes) then
the find bar shows nonsensical results, as if subsequent uses are still
looking at the contents of the file that where displayed when the find bar
was first invoked.
Is there something I can/should do to 'reset' the find bar when the file
being edited changes? I couldn't find anything in the documentation, and I
couldn't figure out how to get the NSTextFinder instance that the textview
is using, and even if I could, I don't see anything in the documentation
to 'reset' its state, or set the string it should search.
>>>
>>> How are you replacing the NSTextView contents when switching files? The
>>> 'reset' call for NSTextFinder when the client's content changes is
>>> -noteClientStringWillChange. NSTextView is supposed to invoke this during
>>> -shouldChangeTextInRanges:replacementStrings:. It's also invoked during
>>> -[NSLayoutManager setTextStorage:], so when you switch your NSTextView
>>> contents, you could load the new file's contents into a new NSTextStorage
>>> instance, then invoke [[textStorage layoutManager]
>>> replaceTextStorage:newTextStorage].
>>>
>>> -KP
>>>
Am I going about this all the wrong way? I thought this is one of those
'it just works' cases
Many thanks,
Martin
>>
>>
>>
>
>
> Martin Hewitson
> Albert-Einstein-Institut
> Max-Planck-Institut fuer
>Gravitationsphysik und Universitaet Hannover
> Callinstr. 38, 30167 Hannover, Germany
> Tel: +49-511-762-17121, Fax: +49-511-762-5861
> E-Mail: martin.hewit...@aei.mpg.de
> WWW: http://www.aei.mpg.de/~hewitson
>
>
>
>
>
>
___
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
Alternate to scrollPoint?
We have a situation where we want to call scrollPoint on our view that's in a scroll view. It appears that scrollPoint does not immediately cause the scroll to happen. Right after we call scrollPoint, we need to ask the view for its new scroll location to see if it actually changed. At this point, it has not scrolled yet, so it breaks this code that used to work in Carbon. It appears that scrollPoint is causing an animation to be queued, even though we tried to disable it like so: [CATransaction begin]; [CATransaction setValue:(id)kCFBooleanTrue forKey:kCATransactionDisableActions]; [CATransaction setAnimationDuration:0]; [view scrollPoint:pos]; [CATransaction commit]; The animation is in our way. I found a workaround that seems to work, which is to simply call this instead of all that: [[[view enclosingScrollView] contentView] setBoundsOrigin:pos]; Is this a viable workaround? Can anyone foresee any problems with it? Is there a better way to make scrollPoint work *right now*? -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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
outlets in objects loaded from nibs
Hello all, I am wondering if foregoing the standard way of loading nibs is the answer to problem I have. I need to create two different versions of my app's main window based on what OS version the app is running on. So far the app contains one single main nib file that gets loaded when the app launches and that nib has all the objects that are needed. The main window gets loaded from here, as well as a bunch of controller objects that elements in the main window are connected to. The question that I have is: how could I break this whole thing up into several nib files? Ideally I'd have one main nib that contains the controllers etc, and then two more nibs, each containing the main window in a version specific to an OS version. But how would I manage the bindings between elements in the window and the controllers? What's the best way to deal with this? Thanks! Rainer ___ 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: outlets in objects loaded from nibs
On 2013 Sep 23, at 15:26, Rainer Standke wrote: > Ideally I'd have one main nib that contains the controllers etc, and then two > more nibs, each containing the main window in a version specific to an OS > version. Looks like a good plan. > But how would I manage the bindings between elements in the window and the > controllers? They should be the same as they are now. > What's the best way to deal with this? I would suggest to duplicate your existing nib and *remove* items from each. This will probably be less re-wiring than re-creating one or both from scratch. Both nibs will probably keep all the controllers they have now, unless some controllers end up with no connections. I recently endured the pain of splitting a nib which had grown too large into four smaller nibs. It was tedious to get everything reconnected, although more so in my case since I was also splitting three view controllers off from the original, huge window controller. ___ 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: View hierarchy, documentation, and origin location.
On 2013-09-23, at 1:08 PM, Gary L. Wade wrote: > What I believe you're wanting to know is that cells in a matrix > have their row-column coordinates start from the top left, > so the cell at (0,0) is in the top left of its enclosure matrix and the cell > at row 1 column 0 is below it. Thanks but not really - that is what's happening but not my question. The docs say "By default, the graphics environment origin (0.0,0.0) is located in the lower left,…." page 11 "The window instance maintains a reference to a single top-level view instance, call the content view. "The content view acts as the root of the visible view hierarchy in a window." Page 17 If you look at the code I posted along with my comments you will see that I get the windows content view frame, inset it and use that as the matrix frame. (The matrix is also a View per NSMatrix docn) It's values happen to be 0, 0, 500, 500 and, based on the documentation I quoted, I anticipated that it would draw from the lower left of the content view. It doesn't! It draws from the top left of the content view (which is a View per NSWindow docn) Why is that? What am I not understanding? Why does the docn say one thing but the Cocoa code, (i.e. not my code) do something different? ___ 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: View hierarchy, documentation, and origin location.
On 2013-09-23, at 1:36 PM, Kyle Sluder wrote: > What’s _theMatrix’s frame? Here once again is the code I posted NSWindow *theWindow = [aController window]; NSView *theContentView = theWindow.contentView; NSRect theContentFrame = theContentView.frame; NSRect theMatrixFrame = NSInsetRect(theContentFrame, 40.0, 40.); It's values happen to be 40.0 40.0 500.0 500.0 > It could either have an origin that puts it at the top, or it could draw > its content in its upper-left and have a size that fills the superview, or > its superview could return YES from -isFlipped. There is no superview of a window's content view - it is the root of the view hierarchy. >> The default location is stated to be lower left. > See -[NSView isFlipped]. Of course I read the docn and know about this. isFlipped returns NO both before and after getting the content view frame. > Flippedness does not cascade; every NSView’s bounds coordinate system is > independent. I know that. > If a view returns NO from -isFlipped, then drawing at (0,0) in that view’s > bounds > will always draw at the lower left of that view, regardless of whether any > ancestors return YES from -isFlipped. No it doesn't! The code I posted draws from the top left. ___ 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: View hierarchy, documentation, and origin location.
On Sep 23, 2013, at 8:07 PM, Peter Teeson wrote: > On 2013-09-23, at 1:08 PM, Gary L. Wade wrote: >> What I believe you're wanting to know is that cells in a matrix >> have their row-column coordinates start from the top left, >> so the cell at (0,0) is in the top left of its enclosure matrix and the cell >> at row 1 column 0 is below it. > > Thanks but not really - that is what's happening but not my question. I suspect that Gary is on point and you're not following his point. > The docs say > "By default, the graphics environment origin (0.0,0.0) is located in the > lower left,…." page 11 > "The window instance maintains a reference to a single top-level view > instance, call the content view. > "The content view acts as the root of the visible view hierarchy in a > window." Page 17 > > If you look at the code I posted along with my comments you will see that > I get the windows content view frame, inset it and use that as the matrix > frame. > (The matrix is also a View per NSMatrix docn) > > It's values happen to be 0, 0, 500, 500 and, based on the documentation I > quoted, > I anticipated that it would draw from the lower left of the content view. > It doesn't! It draws from the top left of the content view (which is a View > per NSWindow docn) The docs you've cited don't say anything about where a view will "draw". It describes its coordinate system. The matrix is free to draw the (row == 0, col == 0) cell at view coordinates (x == 5, y == 480) in order to get it to appear at the top left, if that's what it wants to do. > Why is that? What am I not understanding? > Why does the docn say one thing but the Cocoa code, (i.e. not my code) do > something different? If the above still doesn't explain what you're seeing, then you're going to have to provide a picture of what's happening vs. what you expect to happen. Regards, Ken ___ 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: View hierarchy, documentation, and origin location.
On Mon, Sep 23, 2013, at 06:20 PM, Peter Teeson wrote: > > On 2013-09-23, at 1:36 PM, Kyle Sluder wrote: > > What’s _theMatrix’s frame? > Here once again is the code I posted That's not what I asked. I asked for the frame. > It's values happen to be 40.0 40.0 500.0 500.0 Thank you for answering my question. > > > It could either have an origin that puts it at the top, or it could draw > > its content in its upper-left and have a size that fills the superview, or > > its superview could return YES from -isFlipped. > There is no superview of a window's content view - it is the root of the > view hierarchy. > > >> The default location is stated to be lower left. > > See -[NSView isFlipped]. > Of course I read the docn and know about this. And I know that the default location is the lower left. But it seemed worth mentioning what affected "the default." > > > Flippedness does not cascade; every NSView’s bounds coordinate system is > > independent. > I know that. > > If a view returns NO from -isFlipped, then drawing at (0,0) in that view’s > > bounds > > will always draw at the lower left of that view, regardless of whether any > > ancestors return YES from -isFlipped. > No it doesn't! The code I posted draws from the top left. Did you write NSMatrix? Then how do you know it's doing its own drawing at (0,0)? --Kyle Sluder ___ 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
