Re: PDFView drawPage called often after selecting text

2013-01-09 Thread Martin Hewitson 

On Jan 9, 2013, at 09:25 AM, Kyle Sluder  wrote:

> On Jan 8, 2013, at 11:43 PM, Martin Hewitson  
> wrote:
> 
>> Some interesting points/problems
>> 
>> - if I use -drawPage: instead, then the focus ring has the wrong size and 
>> overlaps the displayed pages. Don't know why.
>> - doing this in -drawPage: or -drawPagePost: solves the issue I was having
>> - using [self bounds] rather than [[self documentView] bounds] produces no 
>> visible focus ring
> 
> The documentation strongly implies that -drawPage: is called with a graphics 
> context that's been set up for drawing in the page's coordinate space, 
> whereas -drawPagePost: is documented to do its drawing in the PDFView's 
> coordinate space.

Thanks, Kyle. That explains what I see. Somehow I failed to extract those juicy 
facts from the documentation.

Martin

> 
> --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: PDFView drawPage called often after selecting text

2013-01-09 Thread Kyle Sluder 
On Jan 8, 2013, at 11:43 PM, Martin Hewitson  wrote:

> Some interesting points/problems
> 
> - if I use -drawPage: instead, then the focus ring has the wrong size and 
> overlaps the displayed pages. Don't know why.
> - doing this in -drawPage: or -drawPagePost: solves the issue I was having
> - using [self bounds] rather than [[self documentView] bounds] produces no 
> visible focus ring

The documentation strongly implies that -drawPage: is called with a graphics 
context that's been set up for drawing in the page's coordinate space, whereas 
-drawPagePost: is documented to do its drawing in the PDFView's coordinate 
space.

--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: PDFView drawPage called often after selecting text

2013-01-08 Thread Martin Hewitson 
Andy, Kyle,

Thank you both for your assistance on this. I've got something working now 
which doesn't cause the responsiveness issues and even looks visually more 
pleasant. Here's the solution: 

- (void) drawPagePost:(PDFPage *)page {
[super drawPagePost:page];
if ([[self window] firstResponder] == self && [NSApp isActive]) {
[NSGraphicsContext saveGraphicsState];
NSSetFocusRingStyle(NSFocusRingOnly);
NSRect r = [[self documentView] bounds];
[[NSBezierPath bezierPathWithRect:r] fill];
[NSGraphicsContext restoreGraphicsState];
}
}

This puts a nice focus ring tightly around the pdf pages, rather than hugging 
the edges of the PDFView. I find this much nicer and easier to see.

Some interesting points/problems

- if I use -drawPage: instead, then the focus ring has the wrong size and 
overlaps the displayed pages. Don't know why.
- doing this in -drawPage: or -drawPagePost: solves the issue I was having
- using [self bounds] rather than [[self documentView] bounds] produces no 
visible focus ring

Anyway, I'm now happy with the results, though I would like to understand 
better why the other possible 'solutions' don't work.

Best wishes,

Martin

 
On Jan 8, 2013, at 05:22 PM, Kyle Sluder  wrote:

> On Tue, Jan 8, 2013, at 07:58 AM, Andy Lee wrote:
>> You're already calling setKeyboardFocusRingNeedsDisplayInRect: in
>> become/resignFirstResponder, which seems like the right place. But I
>> notice Apple's "Dicey" example project uses NSSetFocusRingStyle
>> differently than you do. It pushes and pops the graphics state -- and
>> thus, I believe, the clipping region -- instead of doing lockFocus on the
>> superview. I bet this is how it avoids the infinite invalidating.
> 
> Well, pushing the graphics state isn't going to reset the clipping rect,
> and -lockFocus pushes a new graphics state on the stack anyway.
> 
>> 
>> I think Kyle is suggesting something like what Apple does (taken from
>> ):
> 
> Yes, this is the approach I am suggesting.
> 
> --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: PDFView drawPage called often after selecting text

2013-01-08 Thread Andy Lee 
On Jan 8, 2013, at 3:59 AM, Martin Hewitson  wrote:
> Maybe not. I just didn't know about this, but I will read up on it. However, 
> as far as my tests show, -drawRect: is never called on PDFView.

This seemed really odd, so I checked and it turns out there is a view hierarchy 
under PDFView. When you drop a PDFView into IB you can see it looks a lot like 
an NSScrollView. I bet it's one of those descendant views that is getting 
setNeedsDisplay: and drawRect: calls, which is why you didn't see them being 
called on your PDFView.

--Andy

___

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: PDFView drawPage called often after selecting text

2013-01-08 Thread Kyle Sluder 
On Tue, Jan 8, 2013, at 07:58 AM, Andy Lee wrote:
> You're already calling setKeyboardFocusRingNeedsDisplayInRect: in
> become/resignFirstResponder, which seems like the right place. But I
> notice Apple's "Dicey" example project uses NSSetFocusRingStyle
> differently than you do. It pushes and pops the graphics state -- and
> thus, I believe, the clipping region -- instead of doing lockFocus on the
> superview. I bet this is how it avoids the infinite invalidating.

Well, pushing the graphics state isn't going to reset the clipping rect,
and -lockFocus pushes a new graphics state on the stack anyway.

> 
> I think Kyle is suggesting something like what Apple does (taken from
> ):

Yes, this is the approach I am suggesting.

--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: PDFView drawPage called often after selecting text

2013-01-08 Thread Andy Lee 
On Jan 7, 2013, at 10:02 PM, Martin Hewitson  wrote:

> Yes, that's right. But doesn't help the problem, unfortunately. The PDFView 
> is not the first responder when I'm typing, so the 'fault' is triggered when 
> the PDFView first becomes first responder then the NSSetFocusRingStyle part 
> of the code is called. The fault then persists.

Ah, I understand better now. I thought the NSSetFocusRingStyle part was getting 
called every time, but it seems it's only called the one time when the PDFView 
gets first responder (when you select something in the PDF). Thereafter, even 
after the PDFView is no longer first responder, you are seeing symptoms 
consistent with an infinite loop of drawing which causes invalidation which 
causes drawing again, etc.

On Jan 8, 2013, at 3:59 AM, Martin Hewitson  wrote:
> 
> On Jan 8, 2013, at 09:21 AM, Kyle Sluder  wrote:
[...]
>> Is there any particular reason you can't use the old 
>> -setKeyboardFocusRingNeedsDisplayInRect: method and draw your focus ring in 
>> your own graphics context in -drawRect:?
> 
> Maybe not. I just didn't know about this, but I will read up on it. However, 
> as far as my tests show, -drawRect: is never called on PDFView.

You're already calling setKeyboardFocusRingNeedsDisplayInRect: in 
become/resignFirstResponder, which seems like the right place. But I notice 
Apple's "Dicey" example project uses NSSetFocusRingStyle differently than you 
do. It pushes and pops the graphics state -- and thus, I believe, the clipping 
region -- instead of doing lockFocus on the superview. I bet this is how it 
avoids the infinite invalidating.

I think Kyle is suggesting something like what Apple does (taken from 
):

[NSGraphicsContext saveGraphicsState];
NSSetFocusRingStyle(NSFocusRingOnly);
path = [NSBezierPath bezierPathWithRoundedRect:NSInsetRect(bounds, 
-focusRectOffset, -focusRectOffset)  cornerRadius:(radius + (focusRectOffset / 
bounds.size.width))];
[path fill];
[NSGraphicsContext restoreGraphicsState];

(I got to the "Dicey" code from the "Related Sample Code" link in the docs for 
NSSetFocusRingStyle.)

--Andy

___

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: PDFView drawPage called often after selecting text

2013-01-08 Thread Martin Hewitson 

On Jan 8, 2013, at 09:21 AM, Kyle Sluder  wrote:

> On Jan 7, 2013, at 9:16 AM, Martin Hewitson  
> wrote:
> 
>> 
>> On 7, Jan, 2013, at 05:52 PM, Kyle Sluder  wrote:
>> 
>>> On Jan 7, 2013, at 2:48 AM, Martin Hewitson  
>>> wrote:
>>> 
 Actually, at the risk of having a conversation with myself, I've narrowed 
 the issue down to the actions I'm taking within my override of -drawPage:. 
 Essentially what I'm aiming at is having a focus ring on the PDFView. I do 
 this in my PDFView subclass:
 
 - (void)drawPage:(PDFPage *)page {
 [super drawPage:page];
 // focussed?
 if ([[self window] firstResponder] == self && [NSApp isActive]) {
 [[self superview] lockFocus];
 NSRect fr = [self frame];
 NSSetFocusRingStyle(NSFocusRingOnly);
 [[NSBezierPath bezierPathWithRect:fr] fill];
 [[self superview] unlockFocus];
 }
 }
>>> 
>>> This sounds extremely iffy to me. You're dirtying regions of your window 
>>> that overlap other views in the middle of a recursive -drawRect:. I'm 
>>> surprised this doesn't crash or spin infinitely.
>> 
>> This solution was advised on this list (see thread "PDFView focus ring" from 
>> Feb 2012), but it certainly doesn't seem to play nicely with my app. What's 
>> strange is that it doesn't cause problems in a very basic test app
> 
> I'm still not sure this is a good approach to take.
> 
> The drawing machinery is pretty optimized. It's easy to do unsafe things that 
> behave perfectly fine in certain limited circumstances t have deleterious 
> effects in others.
> 
> Locking focus on your superview while you're in the middle of a lockFocus 
> operation strikes me as one of those unsafe things that might usually work 
> until it doesn't.
> 
> Is there any particular reason you can't use the old 
> -setKeyboardFocusRingNeedsDisplayInRect: method and draw your focus ring in 
> your own graphics context in -drawRect:?

Maybe not. I just didn't know about this, but I will read up on it. However, as 
far as my tests show, -drawRect: is never called on PDFView.

Cheers,

Martin

> 
> --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: PDFView drawPage called often after selecting text

2013-01-08 Thread Kyle Sluder 
On Jan 7, 2013, at 9:16 AM, Martin Hewitson  wrote:

> 
> On 7, Jan, 2013, at 05:52 PM, Kyle Sluder  wrote:
> 
>> On Jan 7, 2013, at 2:48 AM, Martin Hewitson  
>> wrote:
>> 
>>> Actually, at the risk of having a conversation with myself, I've narrowed 
>>> the issue down to the actions I'm taking within my override of -drawPage:. 
>>> Essentially what I'm aiming at is having a focus ring on the PDFView. I do 
>>> this in my PDFView subclass:
>>> 
>>> - (void)drawPage:(PDFPage *)page {
>>> [super drawPage:page];
>>> // focussed?
>>> if ([[self window] firstResponder] == self && [NSApp isActive]) {
>>>  [[self superview] lockFocus];
>>>  NSRect fr = [self frame];
>>>  NSSetFocusRingStyle(NSFocusRingOnly);
>>>  [[NSBezierPath bezierPathWithRect:fr] fill];
>>>  [[self superview] unlockFocus];
>>> }
>>> }
>> 
>> This sounds extremely iffy to me. You're dirtying regions of your window 
>> that overlap other views in the middle of a recursive -drawRect:. I'm 
>> surprised this doesn't crash or spin infinitely.
> 
> This solution was advised on this list (see thread "PDFView focus ring" from 
> Feb 2012), but it certainly doesn't seem to play nicely with my app. What's 
> strange is that it doesn't cause problems in a very basic test app

I'm still not sure this is a good approach to take.

The drawing machinery is pretty optimized. It's easy to do unsafe things that 
behave perfectly fine in certain limited circumstances t have deleterious 
effects in others.

Locking focus on your superview while you're in the middle of a lockFocus 
operation strikes me as one of those unsafe things that might usually work 
until it doesn't.

Is there any particular reason you can't use the old 
-setKeyboardFocusRingNeedsDisplayInRect: method and draw your focus ring in 
your own graphics context in -drawRect:?

--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: PDFView drawPage called often after selecting text

2013-01-07 Thread Martin Hewitson 

On Jan 7, 2013, at 09:07 PM, Andy Lee  wrote:

> On Jan 7, 2013, at 2:10 AM, Martin Hewitson  wrote:
>> I've also checked that -setNeedsDisplay: is not being called on the PDFView.
> 
> Could it be that setNeedsDisplay: isn't called but setNeedsDisplayInRect: is?

I checked that as well. It's not being called during these -drawPage: calls.

> 
> On Jan 7, 2013, at 2:48 AM, Martin Hewitson  
> wrote:
>> Actually, at the risk of having a conversation with myself, I've narrowed 
>> the issue down to the actions I'm taking within my override of -drawPage:. 
>> Essentially what I'm aiming at is having a focus ring on the PDFView. I do 
>> this in my PDFView subclass:
>> 
>> - (void)drawPage:(PDFPage *)page {
>> [super drawPage:page];
>> // focussed?
>> if ([[self window] firstResponder] == self && [NSApp isActive]) {
>>  [[self superview] lockFocus];
>>  NSRect fr = [self frame];
>>  NSSetFocusRingStyle(NSFocusRingOnly);
>>  [[NSBezierPath bezierPathWithRect:fr] fill];
>>  [[self superview] unlockFocus];
>> }
>> }
> 
> I'm not hugely familiar with PDFKit, so this may be a naive question, and it 
> definitely delves into wild speculation...
> 
> Why do you override drawPage: rather than drawRect:?

Sorry, missed this question in my last reply. I've tried -drawRect: but that is 
not called on PDFView, as far as I can tell. I tried overridding this in my 
subclass and put in an NSLog there, but it's never called. Hence my use of 
-drawPage:.

Cheers,

Martin



___

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: PDFView drawPage called often after selecting text

2013-01-07 Thread Martin Hewitson 

On Jan 7, 2013, at 09:16 PM, Andy Lee  wrote:

> On Jan 7, 2013, at 12:07 PM, Andy Lee  wrote:
>> It does seem weird that drawPage: is getting called when you aren't even 
>> interacting with the PDFView.
> 
> Come to think of it, this is *really* weird since your drawPage: checks 
> whether the PDFView is first responder -- which it can't be if you're in the 
> middle of typing in the text view. Could it be that something is causing the 
> PDFView to become first responder for an instant?

Seems not. I have an NSLog in the if clause where the NSSetFocusRingStyle is 
called, and this is not called during the 'fault' state.

> I'm extra curious now to know what happens if you put NSLogs in 
> becomeFirstResponder and resignFirstResponder.

See previous reply.

> 
> --Andy (also at risk of having a conversation with myself -- wouldn't be the 
> first time :))
> 


It's sometimes very useful :)

Martin




___

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: PDFView drawPage called often after selecting text

2013-01-07 Thread Martin Hewitson 

On Jan 7, 2013, at 09:07 PM, Andy Lee  wrote:

> On Jan 7, 2013, at 2:10 AM, Martin Hewitson  wrote:
>> I've also checked that -setNeedsDisplay: is not being called on the PDFView.
> 
> Could it be that setNeedsDisplay: isn't called but setNeedsDisplayInRect: is?
> 
> On Jan 7, 2013, at 2:48 AM, Martin Hewitson  
> wrote:
>> Actually, at the risk of having a conversation with myself, I've narrowed 
>> the issue down to the actions I'm taking within my override of -drawPage:. 
>> Essentially what I'm aiming at is having a focus ring on the PDFView. I do 
>> this in my PDFView subclass:
>> 
>> - (void)drawPage:(PDFPage *)page {
>> [super drawPage:page];
>> // focussed?
>> if ([[self window] firstResponder] == self && [NSApp isActive]) {
>>  [[self superview] lockFocus];
>>  NSRect fr = [self frame];
>>  NSSetFocusRingStyle(NSFocusRingOnly);
>>  [[NSBezierPath bezierPathWithRect:fr] fill];
>>  [[self superview] unlockFocus];
>> }
>> }
> 
> I'm not hugely familiar with PDFKit, so this may be a naive question, and it 
> definitely delves into wild speculation...
> 
> Why do you override drawPage: rather than drawRect:? I wonder if drawPage: is 
> being called on multiple instances of PDFPage. Maybe (and here's the wild 
> speculation) something about selecting text in the PDFView causes lots of 
> PDFPage instances to be created, which would explain why you don't see the 
> many calls to drawPage: until then.
> 
> What do you see if you add NSLog(@"%@", page) to your drawPage: method? Is it 
> the same PDFPage every time?

When it goes into overdrive, it's the same page every time.


> 
>> - (BOOL)becomeFirstResponder {
>> [self setKeyboardFocusRingNeedsDisplayInRect:[self bounds]];
>> return [super becomeFirstResponder];
>> }
>> 
>> - (BOOL)resignFirstResponder {
>> [self setKeyboardFocusRingNeedsDisplayInRect:[self bounds]];
>> return [super resignFirstResponder];
>> }
> 
> Not sure if this relates to your problem, but it seems to me you should test 
> the results of super first. For example:
> 
> - (BOOL)becomeFirstResponder {
> BOOL didBecome = [super becomeFirstResponder];
> 
> if (didBecome) {
>  [self setKeyboardFocusRingNeedsDisplayInRect:[self bounds]];
> }
> 
> return didBecome;
> }
> 
> And similarly for resignFirstResponder.

Yes, that's right. But doesn't help the problem, unfortunately. The PDFView is 
not the first responder when I'm typing, so the 'fault' is triggered when the 
PDFView first becomes first responder then the NSSetFocusRingStyle part of the 
code is called. The fault then persists.

> 
> Also, I would be curious how often these get called -- I don't suppose 
> they're getting called with every key you type into the text view? It does 
> seem weird that drawPage: is getting called when you aren't even interacting 
> with the PDFView.

It's called about every 200ms, so I don't think it's for every keystroke, but 
it's hard to tell.


> I don't suppose your text view has a delegate that is doing something that 
> might affect the PDFView?

Not that I can find, but I'll look again. The text view has a delegate and does 
a lot of stuff, but I couldn't find any interaction with the PDFView so far.

Thanks for your thoughts!

Martin

> 
> --Andy
> 







___

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: PDFView drawPage called often after selecting text

2013-01-07 Thread Andy Lee 
On Jan 7, 2013, at 12:07 PM, Andy Lee  wrote:
> It does seem weird that drawPage: is getting called when you aren't even 
> interacting with the PDFView.

Come to think of it, this is *really* weird since your drawPage: checks whether 
the PDFView is first responder -- which it can't be if you're in the middle of 
typing in the text view. Could it be that something is causing the PDFView to 
become first responder for an instant? I'm extra curious now to know what 
happens if you put NSLogs in becomeFirstResponder and resignFirstResponder.

--Andy (also at risk of having a conversation with myself -- wouldn't be the 
first time :))

___

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: PDFView drawPage called often after selecting text

2013-01-07 Thread Andy Lee 
On Jan 7, 2013, at 2:10 AM, Martin Hewitson  wrote:
> I've also checked that -setNeedsDisplay: is not being called on the PDFView.

Could it be that setNeedsDisplay: isn't called but setNeedsDisplayInRect: is?

On Jan 7, 2013, at 2:48 AM, Martin Hewitson  wrote:
> Actually, at the risk of having a conversation with myself, I've narrowed the 
> issue down to the actions I'm taking within my override of -drawPage:. 
> Essentially what I'm aiming at is having a focus ring on the PDFView. I do 
> this in my PDFView subclass:
> 
> - (void)drawPage:(PDFPage *)page {
> [super drawPage:page];
>  // focussed?
>  if ([[self window] firstResponder] == self && [NSApp isActive]) {
>   [[self superview] lockFocus];
>   NSRect fr = [self frame];
>   NSSetFocusRingStyle(NSFocusRingOnly);
>   [[NSBezierPath bezierPathWithRect:fr] fill];
>   [[self superview] unlockFocus];
>  }
> }

I'm not hugely familiar with PDFKit, so this may be a naive question, and it 
definitely delves into wild speculation...

Why do you override drawPage: rather than drawRect:? I wonder if drawPage: is 
being called on multiple instances of PDFPage. Maybe (and here's the wild 
speculation) something about selecting text in the PDFView causes lots of 
PDFPage instances to be created, which would explain why you don't see the many 
calls to drawPage: until then.

What do you see if you add NSLog(@"%@", page) to your drawPage: method? Is it 
the same PDFPage every time?

> - (BOOL)becomeFirstResponder {
>  [self setKeyboardFocusRingNeedsDisplayInRect:[self bounds]];
>  return [super becomeFirstResponder];
> }
> 
> - (BOOL)resignFirstResponder {
>  [self setKeyboardFocusRingNeedsDisplayInRect:[self bounds]];
>  return [super resignFirstResponder];
> }

Not sure if this relates to your problem, but it seems to me you should test 
the results of super first. For example:

- (BOOL)becomeFirstResponder {
 BOOL didBecome = [super becomeFirstResponder];

 if (didBecome) {
  [self setKeyboardFocusRingNeedsDisplayInRect:[self bounds]];
 }

 return didBecome;
}

And similarly for resignFirstResponder.

Also, I would be curious how often these get called -- I don't suppose they're 
getting called with every key you type into the text view? It does seem weird 
that drawPage: is getting called when you aren't even interacting with the 
PDFView. I don't suppose your text view has a delegate that is doing something 
that might affect the PDFView?

--Andy

___

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: PDFView drawPage called often after selecting text

2013-01-07 Thread Martin Hewitson 

On 7, Jan, 2013, at 05:52 PM, Kyle Sluder  wrote:

> On Jan 7, 2013, at 2:48 AM, Martin Hewitson  
> wrote:
> 
>> Actually, at the risk of having a conversation with myself, I've narrowed 
>> the issue down to the actions I'm taking within my override of -drawPage:. 
>> Essentially what I'm aiming at is having a focus ring on the PDFView. I do 
>> this in my PDFView subclass:
>> 
>> - (void)drawPage:(PDFPage *)page {
>> [super drawPage:page];
>> // focussed?
>> if ([[self window] firstResponder] == self && [NSApp isActive]) {
>>   [[self superview] lockFocus];
>>   NSRect fr = [self frame];
>>   NSSetFocusRingStyle(NSFocusRingOnly);
>>   [[NSBezierPath bezierPathWithRect:fr] fill];
>>   [[self superview] unlockFocus];
>> }
>> }
> 
> This sounds extremely iffy to me. You're dirtying regions of your window that 
> overlap other views in the middle of a recursive -drawRect:. I'm surprised 
> this doesn't crash or spin infinitely.

This solution was advised on this list (see thread "PDFView focus ring" from 
Feb 2012), but it certainly doesn't seem to play nicely with my app. What's 
strange is that it doesn't cause problems in a very basic test app

> 
>> 
>> Is there perhaps a better way I can achieve this focus ring without 
>> triggering this (recursive?) -drawPage: behaviour?
> 
> Why not use the modern API, -noteFocusRingMaskChanged and -drawFocusRingMask?

Unfortunately I want to maintain support for 10.6.8 and these only appear in 
10.7, as far as I can tell.

Cheers,

Martin

> 
> --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: PDFView drawPage called often after selecting text

2013-01-07 Thread Kyle Sluder 
On Jan 7, 2013, at 2:48 AM, Martin Hewitson  wrote:

> Actually, at the risk of having a conversation with myself, I've narrowed the 
> issue down to the actions I'm taking within my override of -drawPage:. 
> Essentially what I'm aiming at is having a focus ring on the PDFView. I do 
> this in my PDFView subclass:
> 
> - (void)drawPage:(PDFPage *)page {
>  [super drawPage:page];
>  // focussed?
>  if ([[self window] firstResponder] == self && [NSApp isActive]) {
>[[self superview] lockFocus];
>NSRect fr = [self frame];
>NSSetFocusRingStyle(NSFocusRingOnly);
>[[NSBezierPath bezierPathWithRect:fr] fill];
>[[self superview] unlockFocus];
>  }
> }

This sounds extremely iffy to me. You're dirtying regions of your window that 
overlap other views in the middle of a recursive -drawRect:. I'm surprised this 
doesn't crash or spin infinitely.

> 
> Is there perhaps a better way I can achieve this focus ring without 
> triggering this (recursive?) -drawPage: behaviour?

Why not use the modern API, -noteFocusRingMaskChanged and -drawFocusRingMask?

--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: PDFView drawPage called often after selecting text

2013-01-07 Thread Martin Hewitson 
Actually, at the risk of having a conversation with myself, I've narrowed the 
issue down to the actions I'm taking within my override of -drawPage:. 
Essentially what I'm aiming at is having a focus ring on the PDFView. I do this 
in my PDFView subclass:

- (void)drawPage:(PDFPage *)page {
  [super drawPage:page];
  // focussed?
  if ([[self window] firstResponder] == self && [NSApp isActive]) {
[[self superview] lockFocus];
NSRect fr = [self frame];
NSSetFocusRingStyle(NSFocusRingOnly);
[[NSBezierPath bezierPathWithRect:fr] fill];
[[self superview] unlockFocus];
  }
}

- (BOOL)becomeFirstResponder {
  [self setKeyboardFocusRingNeedsDisplayInRect:[self bounds]];
  return [super becomeFirstResponder];
}

- (BOOL)resignFirstResponder {
  [self setKeyboardFocusRingNeedsDisplayInRect:[self bounds]];
  return [super resignFirstResponder];
}

If I remove the call to NSSetFocusRingStyle and [NSBezierPath fill] then the 
problem goes away. Hmmm.

To make the matter more mysterious, I created a test app which loads the same 
PDF I'm testing the main app with, and has a text view in a split pane with a 
PDFView in the other split pane. I use the same PDFView subclass, and the 
problem isn't present. So clearly there's some strange interaction with the 
setting of this focus ring and some other element of my app. Am I somehow 
screwing up the drawing stuff with the locking and unlocking focus? A bit out 
of my depth here.

Is there perhaps a better way I can achieve this focus ring without triggering 
this (recursive?) -drawPage: behaviour?

All ideas welcome,

Martin 


On Jan 7, 2013, at 11:10 AM, Martin Hewitson  wrote:

> Dear list,
> 
> I have an app which has a main split view. In the left panel there is a text 
> editor (NSTextView), in the right panel there is a PDFView. I find that when 
> typing in the text view, the -drawPage: method of the PDFView is called about 
> once every 200ms but only if the PDFView is displaying a (large) graphic. I 
> have this method overridden because I do some additional drawing. The problem 
> is that if the drawing of the PDF page is heavy (due to the complex graphic), 
> then the responsiveness of the text view becomes noticeably poorer. In fact 
> the responsiveness of the whole app is affected.
> 
> The strange thing is, that this behaviour is only triggered if I have 
> selected text in the PDF at least once since loading the PDF document. If 
> text has never been selected, then the -drawPage: is called only a couple of 
> times at the beginning or when scrolling (as expected), but not when typing 
> in the text view or doing other non-pdf related actions. Clearing the 
> selected text (by just clicking somewhere on the PDFView) doesn't rectify the 
> problem - it persists until the app is restarted.
> 
> Can anyone explain to me why the -drawPage: method of PDFView is being called 
> when I'm typing in the text view? I'm pretty sure I'm not calling it anywhere 
> in my app.  I've also checked that -setNeedsDisplay: is not being called on 
> the PDFView.
> 
> Could this be a PDFKit bug?
> 
> Best wishes,
> 
> Martin
> 



___

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