date:20120503

On May 3, 2012, at 8:04 AM, Thomas Davie tom.da...@gmail.com wrote:

 It appears that this text path doesn't deal with font fallbacks correctly; 
 the docs for CTLineDraw though say that it's just an alias for repeatedly 
 calling CGContextShowGlyphs.

That's not precisely what the docs say:

This is a convenience function because the line could be drawn run-by-run by 
getting the glyph runs, getting the glyphs out of them, and calling a function 
such as CGContextShowGlyphsAtPositions.

You might get better results asking on the coretext-dev mailing list.

--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: NSTableView doesn't show data until I click on a header

On May 3, 2012, at 03:52 , Koen van der Drift wrote:

 Thanks! I was indeed using removekeyAtIndexes: , but setKey seems a bit 
 easier to do.

The setter is not quite so easy at it seems. You should declare the property 
with the 'copy' option, so that the parameter is copied by any @synthesized 
setter. If you write your own setter, then you need to make sure you make the 
copy yourself. Otherwise, the caller can (in effect) change your array ivar at 
will (by passing a NSMutableArray object to the setter, and mutating it later).

Also, at the moment you make the copy, there are *three* arrays in existence: 
your current ivar value, the copy (your new ivar value), and the parameter to 
the setter. If the arrays are large or otherwise expensive to create, then the 
copying and memory consumption of the extra copies might be uncomfortably 
unperformant.

In fact, depending on the expected sizes of the arrays involved, the best 
implementation of the setter might actually be one that avoids making the copy:

- (void) setMyArray: (NSArray*) myArray {
[myArrayIvar removeObjectsAtIndexes: … index set of all 
elements …];
[myArrayIvar addObjectsFromArray: myArray];
}

IOW, it would use the wordier code technique that you started out to avoid. :)


___

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 can I prevent UITableViewRowAnimationAutomatic to slide down my UISearchBar?

2012-05-03 Thread Florian Pilz

After an extensive search on Google  StackOverFlow I found the right clue: the 
`UIScrollView`. The actual solution I was looking for and finally implemented 
can be found in an stackoverflow question: 
http://stackoverflow.com/questions/664781/change-default-scrolling-behavior-of-uitableview-section-header

I customized the solution a little bit, to have the following properties:

* row animations may scroll down the table view, unless the header view would 
be shown
* a click on the top (scroll to top) should scroll the table view to the top, 
excluding the header view
* if the header view is partially visible it should slide itself down, so its 
completely visible

Code for this solution:

- (void)scrollViewDidScroll:(UIScrollView *)scrollView
{
CGFloat searchBarHeight = self.searchBar.frame.size.height;
if (scrollView.contentOffset.y = searchBarHeight) {
scrollView.contentInset = UIEdgeInsetsMake(-searchBarHeight, 0, 0, 
0);
} else {
scrollView.contentInset = UIEdgeInsetsZero;
}
}

- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView 
willDecelerate:(BOOL)decelerate
{
if (scrollView.contentOffset.y  self.searchBar.frame.size.height  
scrollView.contentOffset.y  0) {
[scrollView setContentOffset:CGPointZero animated:YES];
}
}

This code is implemented inside a `UITableViewController`, which acts as a 
delegate for the `UITableView`. The `UITableView` on the other side inherits 
from `UIScrollView`, which makes these methods available and performs all the 
magic.

A few sentences to explain `contentOffset` and `contentInset`, which took me a 
while to understand their meaning.

* The offset is a `CGPoint`, which simply tells how far the visible content, 
i.e. the sections  cells of the table view, are scrolled down from the top 
left corner. The header view and footer view are included, therefore an offset 
of (0, 0) says that the table view is scrolled to the top. An offset of (0, 
100) means the table view is scrolled down 100px (the x-value of the point is 
normally not used).
* The inset is a very interesting property, it defines the boundaries of the 
`UIScrollView` as the quadrupel `(top, left, bottom, right)`. Therefore the 
table view will bounce if you cross these boundaries. The default value is (0, 
0, 0, 0), meaning that the table view will bounce, if you scroll above / below 
its first / last cell. Therefore a value of (-44, 0, 0, 0) would lower the 
bounce-boundarie to 44px below the origin of the table view. As my header view 
is 44px high, it will bounce every time you scroll the header view into the 
visible part of the screen. This also prevent row animations from sliding the 
table below an offset of (44, 0) and the slide to top command will slide the 
table view to an offset of (44, 0).



Am Donnerstag, 19 April 2012 um 08:11 schrieb Florian Pilz:

 I have figured out how to hide the SearchBar when my view appears, so it will 
 be hidden unless you scrolled it down and only used modal dialogues. However, 
 if I add or delete a row from my table, the search bar slides into the 
 visible part of the view, due to the animation triggered. Is it possible to 
 disallow the animation to scroll the view down if that would cross a certain 
 height? 
 
 -- Florian 

___

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

how to prevent TableView update on key repeat?

Hi All,

I have a master/detail table setup. When I select a row in the master, there 
are one or two detail tables that need to be updated. There are also a bunch of 
conditions that need to be checked to know what you can do to the master and 
the details. I have just finished a lot of optimization but the act of 
selecting a row is still a pretty heavy operation. Although I've managed to go 
from 0.3 seconds to 0.02, I'm still behind the key repeat interval.

I notice that in Mail, if I hold the down arrow and let it repeat, it does 
*not* update the row until I stop. I don't really know how it does that. My 
first thought is that I check for a key repeat event in 
tableViewSelectionDidChange: and skip updating until the user stops. It does 
not appear to be that easy. Maybe I need to subclass the tableview and handle 
the keyDown event? That doesn't seem so easy either since I'm using bindings 
and tableViewSelectionDidChange: is called from NSNotificationCenter via a set 
of private methods on NSTableView (looks like [NSTableView 
_doSelectIndexes:byExtendingSelection:indexType:funnelThroughSingleIndexVersion:]).

Can anyone point me in the right direction on this? How can I prevent 
tableViewSelectionDidChange: from being called when the user is holding the up 
or down arrow and trying to scroll rapidly through the table so I only update 
when they stop?

Thanks a lot
Marc
___

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 prevent TableView update on key repeat?

On May 3, 2012, at 13:46 , Marc Respass wrote:

 Can anyone point me in the right direction on this? How can I prevent 
 tableViewSelectionDidChange: from being called when the user is holding the 
 up or down arrow and trying to scroll rapidly through the table so I only 
 update when they stop?

One approach is to move the heavyweight code out of your selectionDidChange 
method into a separate method, the invoke this new method via 
'performSelector:…afterDelay:0' (or, maybe better still, 'afterDelay:0.1'). In 
order to prevent the performs from stacking up, you would always invoke 
'cancelPreviousPerformRequestsWithTarget:selector:object:' first.

That is, you always write something like this pattern:

[cancelPreviousPerformRequestsWithTarget: self selector: @selector 
(mySelectionDidChange:) object: nil];
[self performSelector: @selector (mySelectionDidChange) withObject: nil 
afterDelay: 0.1];

so you have a queue of 0 or 1 pending selection change actions at any time, and 
the action is done soon if not canceled first.

Other approaches are to use NSOperationQueue to schedule a separate operation, 
or GCD to schedule a separate block, to the same effect. With a bit more 
trouble and attention to thread safety, you could arrange for either of these 
to be done on a background thread, if performance considerations warrant the 
extra effort.


___

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: Xcode warns about missing protocol definition, even though @protocol is used

2012-05-03 Thread Florian Pilz

Hi again. I just stumbled about this problem for another time and rethought 
Ulis explanation. The point of my writing is: Ulis explanation is wrong. The 
program compiles (with a warning) and runs perfectly fine. So basically Xcode 
tells me, that it must know the implementation details, which are not given in 
the header file (but may be added in the implementation file -- therefore a 
warning rather an error). 

Is there a flag to disable such a warning?

Best wishes
Florian


Am Montag, 16 April 2012 um 23:28 schrieb Uli Kusterer:

 On 16.04.2012, at 23:03, Florian Pilz wrote:
  The import is done in the .m-file of HomeTableViewController. But I just 
  found a fault in my sample code anyways: the .h-file of 
  HomeTableViewController should have an @protocol NewFooController 
  declaration. 
  
  Corrected sample code for HomeTableViewController.h:
  
  #import UIKit/UIKit.h
  @protocol NewFooControllerDelegate;
  // warning points to line below
  @interface HomeTableViewController : UITableViewController 
  NewFooControllerDelegate
  @end
  
 
 
 
 That won't work. When you declare a class as conforming to a protocol, the 
 compiler has to know what methods that protocol contains, so it can make sure 
 to complain if one of the required methods is missing.
 
 @protocol Foo only works if you want to declare a variable of type idFoo 
 (but not actually send messages to it). It simply tells the compiler this 
 protocol exists, but not what methods it actually consists of.
 
 It's the same as with plain C struct Foo; and struct Foo { int x; int y; }; 
 Only the latter can actually be used (because now the compiler knows that 
 there is a struct named 'Foo'), but you can declare pointers to the former, 
 because for a pointer it only has to know the size of an address, not the 
 size of the struct at that address.
 
 Cheers,
 -- Uli Kusterer
 The Witnesses of TeachText are everywhere...
 http://www.masters-of-the-void.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: Xcode warns about missing protocol definition, even though @protocol is used


On May 3, 2012, at 2:54 PM, Florian Pilz wrote:

 Hi again. I just stumbled about this problem for another time and rethought 
 Ulis explanation. The point of my writing is: Ulis explanation is wrong. The 
 program compiles (with a warning) and runs perfectly fine. So basically Xcode 
 tells me, that it must know the implementation details, which are not given 
 in the header file (but may be added in the implementation file -- therefore 
 a warning rather an error).

Please post your code in its entirety.

I just tried this, and it gives me a warning:

// t.m
#import Foundation/Foundation.h

@protocol FooProto;

@interface SomeClass : NSObject FooProto
@end

@implementation SomeClass
@end

int main(int argc, char **argv)
{
[SomeClass new];
return 0;
}

@protocol FooProto
@end
// END t.m

% clang -o t t.m -framework Foundation
t.m:5:34: warning: cannot find protocol definition for 'FooProto'
1 warning generated.

--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: Xcode warns about missing protocol definition, even though @protocol is used

2012-05-03 Thread Marco S Hyman

 I just tried this, and it gives me a warning:

That is what he's complaining about... the warning.

To the OP: there is no way a compiler can tell if a class conforms
to a protocol when the only thing it knows is the name of the
protocol.  Thus the warning.  Maybe it will compile and run...
maybe not.

Marc
___

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: Xcode warns about missing protocol definition, even though @protocol is used


On May 3, 2012, at 3:08 PM, Marco S Hyman wrote:

 I just tried this, and it gives me a warning:
 
 That is what he's complaining about... the warning.

Except he just said he got it to compile without a warning, which means that 
whatever he's got going on is more complicated than the situation as Uli and I 
have understood it.

 
 To the OP: there is no way a compiler can tell if a class conforms
 to a protocol when the only thing it knows is the name of the
 protocol.  Thus the warning.  Maybe it will compile and run...
 maybe not.

Except the compiler produces the warning on the @interface, which provides no 
information about whether the class actually implements the required protocol 
methods. You don't need to redeclare methods from protocols you adopt. The 
logical place to emit this warning is on the @implementation, so the compiler 
can alert you that it can't verify you've _implemented_ all the methods you 
claim to.

But even that's not good enough, because it would make it impossible to 
implement a proxy class that claims to conform to a protocol but actually 
forwards the messages to the object it's proxying via 
-forwardingTargetForSelector:, without getting warnings that the class hasn't 
implemented the protocol methods.

--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: how to prevent TableView update on key repeat?

Thanks Quincey (and Alex),

I ended up finding a solution that almost works perfectly.

- (void)tableViewSelectionDidChange:(NSNotification *)aNotification;
{
NSEvent *event = [NSApp currentEvent];

if(event != nil  [event type] == NSKeyDown  [event isARepeat])
{
return;
}
else
{
// do my thing
}
}

The problem is that it doesn't update the last row since you get there in a 
repeat event. I don't love the do thing with delay, it feels too fragile. I 
need to update every time the selection changes except when repeating. That's 
the only condition. If repeating, wait until stop but, naturally, the table 
view only sends on change.

What I guess I'm looking for is more like the ability to send 
tableViewSelectionDidChange: after keyUp. Since the code above is working so 
well, maybe it's a reasonable idea to subclass NSTableView, note that I'm in a 
key repeat and send the notification in keyUp if wasRepeating is YES. That 
doesn't sound too bad, not too much code, no threading issues.

Marc

El may 3, 2012, a las 5:28 p.m., Quincey Morris escribió:

 On May 3, 2012, at 13:46 , Marc Respass wrote:
 
 Can anyone point me in the right direction on this? How can I prevent 
 tableViewSelectionDidChange: from being called when the user is holding the 
 up or down arrow and trying to scroll rapidly through the table so I only 
 update when they stop?
 
 One approach is to move the heavyweight code out of your selectionDidChange 
 method into a separate method, the invoke this new method via 
 'performSelector:…afterDelay:0' (or, maybe better still, 'afterDelay:0.1'). 
 In order to prevent the performs from stacking up, you would always invoke 
 'cancelPreviousPerformRequestsWithTarget:selector:object:' first.
 
 That is, you always write something like this pattern:
 
   [cancelPreviousPerformRequestsWithTarget: self selector: @selector 
 (mySelectionDidChange:) object: nil];
   [self performSelector: @selector (mySelectionDidChange) withObject: nil 
 afterDelay: 0.1];
 
 so you have a queue of 0 or 1 pending selection change actions at any time, 
 and the action is done soon if not canceled first.
 
 Other approaches are to use NSOperationQueue to schedule a separate 
 operation, or GCD to schedule a separate block, to the same effect. With a 
 bit more trouble and attention to thread safety, you could arrange for either 
 of these to be done on a background thread, if performance considerations 
 warrant the extra effort.
 
 

___

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: Xcode warns about missing protocol definition, even though @protocol is used

On May 3, 2012, at 15:13 , Kyle Sluder wrote:

 Except the compiler produces the warning on the @interface, which provides no 
 information about whether the class actually implements the required protocol 
 methods. You don't need to redeclare methods from protocols you adopt. The 
 logical place to emit this warning is on the @implementation, so the compiler 
 can alert you that it can't verify you've _implemented_ all the methods you 
 claim to.

As an aside, the second kind of information that the compiler needs is the 
inheritance chain for the protocol.

The idea that the actual protocol declaration (as opposed to the forward 
reference) belongs with the implementation ignores the fact that the public 
@interface is all that clients of the class have to go on, and clients of the 
class typically need to know what methods form part of the protocol (and need 
to know the inheritance chain).

If syntax permitted that the class @interface declared conformance only, 
clients would still need to include the actual protocol declaration from 
somewhere.

In the special case of a delegate protocol, most clients of the class won't 
need to know even that the class implements the protocol, but in general the 
class @interface requires a complete protocol declaration for the benefit of 
clients.

Incidentally, I only just discovered that you can declare conformance on a 
class extension:

@interface MyClass () SomeProtocol

while means there is a technique of privatizing the protocol conformance within 
the .m file, when conformance is an implementation detail of the class.


___

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: Xcode warns about missing protocol definition, even though @protocol is used

On May 3, 2012, at 3:33 PM, Quincey Morris wrote:

 On May 3, 2012, at 15:13 , Kyle Sluder wrote:
 
 Except the compiler produces the warning on the @interface, which provides 
 no information about whether the class actually implements the required 
 protocol methods. You don't need to redeclare methods from protocols you 
 adopt. The logical place to emit this warning is on the @implementation, so 
 the compiler can alert you that it can't verify you've _implemented_ all the 
 methods you claim to.
 
 As an aside, the second kind of information that the compiler needs is the 
 inheritance chain for the protocol.
 
 The idea that the actual protocol declaration (as opposed to the forward 
 reference) belongs with the implementation ignores the fact that the public 
 @interface is all that clients of the class have to go on, and clients of the 
 class typically need to know what methods form part of the protocol (and need 
 to know the inheritance chain).

This is true; I hadn't thought about that. Especially since current advice is 
to make all your protocols conform to NSObject.

--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: how to prevent TableView update on key repeat?

On May 3, 2012, at 15:27 , Marc Respass wrote:

 I ended up finding a solution that almost works perfectly.
 
 - (void)tableViewSelectionDidChange:(NSNotification *)aNotification;
 {
 NSEvent *event = [NSApp currentEvent];
 
 if(event != nil  [event type] == NSKeyDown  [event isARepeat])
 {
 return;
 }
 else
 {
   // do my thing
 }
 }

Well, apologies in advance for being curmudgeonly, but this is a crummy 
solution.

You don't know, at the time this method is called, what the current event is. 
The table view itself might already have deferred sending the notification 
until some other event occurred (e.g. a NSTimer expiration, or it may even have 
done its own performSelector…afterDelay). That means that pressing a random key 
after an arrow key might suppress the detail update entirely.

On top of that, you're ready to jump in and double your hack by subclassing 
NSTableView to fix the problem the first hack had with keyUp events. Ugh!

The technique I suggested, of performing a selector and canceling unwanted 
performs, isn't fragile. It's a well known (though not immediately obvious) 
pattern that works well in situations like this. I didn't invent it, I just 
learned it from someone else on this list. It also has the distinct advantage 
(in stark contrast to your hack) of being provably correct.



___

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 prevent TableView update on key repeat?


El may 3, 2012, a las 6:47 p.m., Quincey Morris escribió:

 On May 3, 2012, at 15:27 , Marc Respass wrote:
 
 I ended up finding a solution that almost works perfectly.
 
 - (void)tableViewSelectionDidChange:(NSNotification *)aNotification;
 {
 NSEvent *event = [NSApp currentEvent];
 
 if(event != nil  [event type] == NSKeyDown  [event isARepeat])
 {
 return;
 }
 else
 {
  // do my thing
 }
 }
 
 Well, apologies in advance for being curmudgeonly, but this is a crummy 
 solution.

Not at all. That's why I am asking and responded with something I found. I 
apologize if I came across ungrateful. I do appreciate the help.

 You don't know, at the time this method is called, what the current event is. 
 The table view itself might already have deferred sending the notification 
 until some other event occurred (e.g. a NSTimer expiration, or it may even 
 have done its own performSelector…afterDelay). That means that pressing a 
 random key after an arrow key might suppress the detail update entirely.

Good points.

 On top of that, you're ready to jump in and double your hack by subclassing 
 NSTableView to fix the problem the first hack had with keyUp events. Ugh!

OK, not a good idea. Unreadying myself :)

 The technique I suggested, of performing a selector and canceling unwanted 
 performs, isn't fragile. It's a well known (though not immediately obvious) 
 pattern that works well in situations like this. I didn't invent it, I just 
 learned it from someone else on this list. It also has the distinct advantage 
 (in stark contrast to your hack) of being provably correct.

It felt to me that performing a selector after a fixed delay would be fragile. 
I think that I simply didn't understand how running the code via perform 
selector after delay will solve the problem. 

Let me ask if I have figured it out. User presses down, selection did change is 
called, I cancel previous performSelector then perform with delay of 0.1 
seconds. The key repeat is much faster than 0.1 so selection did change is 
called before the selector is called and then it is canceled (the cycle then 
repeats). When the user lifts the key and selection stops, selection did change 
is *not* called, the selector is scheduled to fire, and it does. If I have that 
right, then I simply paste the two lines you provided

[cancelPreviousPerformRequestsWithTarget: self selector: @selector 
(mySelectionDidChange:) object: nil];
[self performSelector: @selector (mySelectionDidChange) withObject: nil 
afterDelay: 0.1];

and I'm done. Do I have that correct? If so, I apologize that I didn't pay 
enough attention to get it the first time.

Thanks a lot
Marc
___

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 prevent TableView update on key repeat?

On May 3, 2012, at 16:07 , Marc Respass wrote:

 Do I have that correct?

Yes, you do. :)

Another way to think about it is this: the cancel suppresses all the selector 
performs except the last one. (There's *always* a last one because the cancel 
is done first.) The last one is the only one you really care about or want.


___

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

[Sandbox]Question on Design Guide

2012-05-03 Thread Yingshen Yu

Hi,

In Apple's App Sandbox Design Guide, Powerbox and File System Access Outside
of Your Container section,
there's a paragraph.

Quote
When a user of your app specifies they want to use file or a folder, Powerbox
adds the associated path to your app’s sandbox. Say, for example, a user
specifies they want to use a file within their ~/Documents folder by dragging
the file to your app’s Dock tile. In response, Powerbox makes the ~/Documents
folder, all its contents, and all its subfolders available to your app.
/Quote

Has anybody found the entire ~/Documents folder available thing working?

I doubt if this is correct. I tested with a slightly different workflow by open
the file from File Open Panel, but it only allows me access the selected file.
Is this behavior only apply for Drag and Drop? or I need some other work to get
this behavior? (I've already enabled the
com.apple.security.files.user-selected.read-write).

App Sandbox Design Guide:
(http://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW17)

Thanks!
-Jonny

___

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: No validation with a bound NSTableView and custom NSFormatter

2012-05-03 Thread Ben Kennedy

On 01 May 2012, at 9:09 pm, Quincey Morris wrote:

 When you bind one or more table columns to an array controller, the table 
 view automatically binds its own content binding to the array controller 
 (presumably with some heuristic for choosing one out of several, if you 
 happened to bind different columns different ways). It doesn't seem 
 impossible that the table view honors cell formatter errors only when its 
 content binding isn't used (i.e. pure data source for all columns). 

That seems like a reasonable explanation (although I see no inherent reason why 
it must be the case, nor have I found it documented, alas.)

I have re-worked things to take full advantage of bindings now, so as to get 
the more desirable automated validation handling.  However, I've now come up 
against another challenge.

As I may have alluded in an earlier posting, I need to be able to perform a 
cascading update on the data set in response to a particular row being edited.  
Previously, this was trivial to do with a for loop in the delegate's 
-[tableView:setObjectValue:forTableColumn:row:], but now requires some trickery.

I've found myself overriding -[editColumn:row:withEvent:select:] and 
-[textShouldEndEditing:] in a NSTableView subclass in order to have a hook into 
performing an operation post-edit in relation to the modified row.  This feels 
filthy, but I yet haven't seen how better to do it.

I considered that I could register as a KVO observer for each of my data 
objects (and then use [arrayController.arrangedObjects indexOfObject:object] as 
the basis for my cascading update), but that requires adding extra 
-[addObserver:...] code accompanying everywhere I have an [arrayController 
addObject:], which seems prone to oversight.  Is there a better way?

Separate from the above, I also have a new performance problem.  The loop in 
which I do my cascading updates executes inordinately slowly; simply assigning 
new values for two properties takes about 0.45 seconds when iterating a data 
set of a mere 135 objects.  It used to be instantaneous before bindings came 
into the picture.  I suspect that all of the KVO overhead is to blame (a quick 
peek in Instruments supports this).  Is there something fundamental I'm missing 
to avoid this bottleneck?

thanks,

b

--
Ben Kennedy, chief magician
Zygoat Creative Technical Services
http://www.zygoat.ca


___

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

Core Data: Setting attribute of deleted object causes it to remain in store

2012-05-03 Thread Jerry Krinock

I use Core Data to model an ordered tree of objects. Delete Rule from parent
to children is Cascade. Because this is pre-Lion, ordering is done by my own
'index' attribute. Store type is In Memory.

Deleting children with many siblings was expensive because, as each child was
deleted, business logic would require all of its siblings to be re-indexed to
fill the gap, maybe triggering KVO in user interface, etc., etc.

To improve performance, I implemented a bulk deleteObjects: method, which
does this…

• Loop 1. For each deletedObject,
Add parent to set of affectedParents
If deletedObject is itself in affectedParents, remove it
Remove from parent with this:
NSMutableSet* oldSiblings = [oldParent
mutableSetValueForKey:@children] ;
[oldSiblings removeObject:deletedObject] ;
Inadvertently (needed in other cases) set an attribute in deletedObject,
[deletedObject setIndex:[NSNumber numberWithInteger:0] ;
Delete from managed object context with this:
[managedObjectContext deleteObject:object] ;
[managedObjectContext processPendingChanges] ;
• Loop 2. For each affectedParent,
Re-index its children to remove gaps

This improved the performance nicely, but led to the unexpected result that any
objects which happened to have been deleted (in Loop 1) after their parent had
been deleted remain in the store, with all attributes nil. In other words, a
bunch of nil objects.

Branching around the inadvertent setIndex: fixed the problem.

I've seen the nilling of attributes happen before, upon re-inserting a deleted
object [1]. This behavior is obviously related, but different. If anyone can
think of a good reason for this behavior, it would be interesting to read.

Jerry Krinock

1.
http://www.cocoabuilder.com/archive/cocoa/236009-nsmanagedobjectcontext-insertobject-cancels-prior-deletion.html?q=cancels+prior+deletion#236009

___

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: Xcode warns about missing protocol definition, even though @protocol is used

2012-05-03 Thread Jens Alfke


On May 3, 2012, at 2:54 PM, Florian Pilz wrote:

 Hi again. I just stumbled about this problem for another time and rethought 
 Ulis explanation. The point of my writing is: Ulis explanation is wrong. The 
 program compiles (with a warning) and runs perfectly fine.

Well, Uli was wrong in implying that the compiler *has* to know the definition 
of the protocol. It can generate code without it. But he’s correct that the 
compiler wants to know the definition so it can do proper consistency checking.

 So basically Xcode tells me, that it must know the implementation details, 
 which are not given in the header file (but may be added in the 
 implementation file -- therefore a warning rather an error). 
 Is there a flag to disable such a warning?

Probably, but that’s the wrong approach. Warnings are there for a reason. If 
you disable the warning, then if you add a new method to the protocol later but 
don’t update a class that implements the protocol, you may not find out until 
your program throws an exception at runtime.

You should instead add an #import to your header so that the actual protocol 
definition gets parsed before the class that implements it.

(Also, this thread belongs on xcode-users or objc-language, not cocoa-dev.)

—Jens
___

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 prevent TableView update on key repeat?

El may 3, 2012, a las 7:27 p.m., Quincey Morris escribió:

 On May 3, 2012, at 16:07 , Marc Respass wrote:
 
 Do I have that correct?
 
 Yes, you do. :)
 
 Another way to think about it is this: the cancel suppresses all the selector 
 performs except the last one. (There's *always* a last one because the cancel 
 is done first.) The last one is the only one you really care about or want.

Excellent. Thank you again. [NSEvent keyRepeatInterval] returned 0.83 so I 
set the delay to 0.9 and it works perfectly. What was a slow process is now as 
smooth as can be. It even works correctly if I hold the up/down arrow until I 
get to the end. The delay to display once I stop the repeat is not noticeable. 
I just moved my selection code to a method and replaced it with this

[NSObject cancelPreviousPerformRequestsWithTarget:self 
selector:@selector(selectionDidChange) object:nil];
[self performSelector:@selector(selectionDidChange) withObject:nil 
afterDelay:0.09];

I've been working for days profiling this app to increase the responsiveness of 
this app and I've made a lot of progress (table view selection change used to 
take 0.3 seconds, now 0.014) but this is the final straw that will really make 
a difference.

Thanks very much!
Marc
___

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 prevent TableView update on key repeat?

2012-05-03 Thread Graham Cox


On 04/05/2012, at 11:25 AM, Marc Respass wrote:

 Excellent. Thank you again. [NSEvent keyRepeatInterval] returned 0.83 so 
 I set the delay to 0.9 and it works perfectly. What was a slow process is now 
 as smooth as can be. It even works correctly if I hold the up/down arrow 
 until I get to the end. The delay to display once I stop the repeat is not 
 noticeable. I just moved my selection code to a method and replaced it with 
 this
 
[NSObject cancelPreviousPerformRequestsWithTarget:self 
 selector:@selector(selectionDidChange) object:nil];
[self performSelector:@selector(selectionDidChange) withObject:nil 
 afterDelay:0.09];


You probably should do this as your last line:

[self performSelector:blah withObject:nil afterDelay:[NSEvent 
keyRepeatInterval] + 0.1];

because the key repeat rate is set by the user in the Keyboard system 
preferences and can change.


--Graham


___

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: No validation with a bound NSTableView and custom NSFormatter

2012-05-03 Thread Keary Suska

On May 3, 2012, at 6:11 PM, Ben Kennedy wrote:

 I have re-worked things to take full advantage of bindings now, so as to get 
 the more desirable automated validation handling.  However, I've now come up 
 against another challenge.
 
 As I may have alluded in an earlier posting, I need to be able to perform a 
 cascading update on the data set in response to a particular row being 
 edited.  Previously, this was trivial to do with a for loop in the delegate's 
 -[tableView:setObjectValue:forTableColumn:row:], but now requires some 
 trickery.
 
 I've found myself overriding -[editColumn:row:withEvent:select:] and 
 -[textShouldEndEditing:] in a NSTableView subclass in order to have a hook 
 into performing an operation post-edit in relation to the modified row.  This 
 feels filthy, but I yet haven't seen how better to do it.
 
 I considered that I could register as a KVO observer for each of my data 
 objects (and then use [arrayController.arrangedObjects indexOfObject:object] 
 as the basis for my cascading update), but that requires adding extra 
 -[addObserver:...] code accompanying everywhere I have an [arrayController 
 addObject:], which seems prone to oversight.  Is there a better way?
 
 Separate from the above, I also have a new performance problem.  The loop in 
 which I do my cascading updates executes inordinately slowly; simply 
 assigning new values for two properties takes about 0.45 seconds when 
 iterating a data set of a mere 135 objects.  It used to be instantaneous 
 before bindings came into the picture.  I suspect that all of the KVO 
 overhead is to blame (a quick peek in Instruments supports this).  Is there 
 something fundamental I'm missing to avoid this bottleneck?

I would say that to have this kind of performance issue generally means that 
bindings is not being worked with properly, and I would add that doing so is 
frequently an exceedingly frustrating thing. Following this thread it sounds to 
me that you would be served best by dumping bindings altogether and using the 
delegate model. It will give you far more control, will be more obvious and 
easier to debug, and will be more performant into tens to hundreds of thousands 
of rows. I know, because I have been in  a similar place, although I was 
experiencing slowdowns when getting into thousands of objects, rather than just 
135. 

Don't get me wrong, I think bindings are great, and I use them extensively in 
almost everything I do. But it seems to me they are really built for 
straightforward usage and if you need to stretch them they tend to break. Not 
to mention that they are completely opaque and are a bear to debug.

HTH,

Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business


___

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 prevent TableView update on key repeat?