Re: Use kAERestart to Restart Computer

[Nick Zitzmann]

On Jun 19, 2011, at 11:00 PM, Andy Boutte wrote:

> Does any body have some sample code that they can share that will restart the 
> computer?  I have looked at the code on these pages:
> 
> http://applerr.com/forum/mac/3648/programmatically-put-a-mac-into-sleep.htm
> http://developer.apple.com/library/mac/#qa/qa1134/_index.html
> 
> What I cant figure out is what code I should put in my IBAction to make the 
> restart happen.
> 
> -(IBAction) buttonAction: (id) sender {
> 
> }

Something like this has worked for me: (warning, written in Mail, untested but 
should work, use at your own risk)

NSAppleScript *restartAS = [[NSAppleScript alloc] initWithSource:@"tell 
application \"System Events\" to restart"];

[restartAS executeAndReturnError:NULL];
[restartAS release];

Nick Zitzmann




___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

User interface items not get touch events in custom view in iOS app

[talesp]

Hi,

I have a custom view if a few buttons in it. These buttons are added to the 
view programatically in initWithFrame method:

- (id)initWithFrame:(CGRect)frame
{
    self = [super initWithFrame:frame];
    if (self) {
        btnGlass = [UIButton buttonWithType:UIButtonTypeCustom];
        btnGlass.frame = CGRectMake(self.frame.origin.x, self.frame.origin.y, 
30, 30);
        [btnGlass addTarget:self action:@selector(toggleGlass) 
forControlEvents:UIControlEventTouchUpInside];
        [self addSubview:btnGlass];
        
        btnDia = [UIButton buttonWithType:UIButtonTypeCustom];
        btnDia.frame = CGRectMake(self.frame.size.width - 30, 
self.frame.origin.y + 35, 30, 30);;
        [btnDia addTarget:self action:@selector(setDiario) 
forControlEvents:UIControlEventTouchUpInside];
        [self addSubview:btnDia];
        
        btnSemana = [UIButton buttonWithType:UIButtonTypeCustom];
        btnSemana.frame = CGRectMake(self.frame.size.width - 30, 
self.frame.origin.y + 66, 30, 30);;
        [btnSemana addTarget:self action:@selector(setSemanal) 
forControlEvents:UIControlEventTouchUpInside];
        [self addSubview:btnSemana];
...

- (void)toggleGlass {
    NSLog(@"%s", __FUNCTION__);
...
}

- (void)setDiario {
    NSLog(@"%s", __FUNCTION__);
...
}

- (void)setSemanal {
    NSLog(@"%s", __FUNCTION__);
...
}

The view controller has a UIScrollview, and the above custon view is added 
programatically to this scroll view in the loadView method:

- (void)loadView {
    [super loadView];
    nextComponentPosition = self.view.frame.origin;
    [scrollTestComponents setScrollEnabled:YES];
    [scrollTestComponents setCanCancelContentTouches:NO];
    [scrollTestComponents setBackgroundColor:[UIColor blackColor]];
    scrollTestComponents.clipsToBounds = YES;
    scrollTestComponents.autoresizingMask = UIViewAutoresizingFlexibleWidth;
    [self createGraphView];
}

- (void)createGraphView {
    self.graphView = [[ECGraphView alloc] 
initWithFrame:CGRectMake(self.view.frame.origin.x, self.view.frame.origin.y, 
320, 214.7)];
    [graphView setDelegate:self];
    [scrollTestComponents setContentSize:CGSizeMake(320, 214.7)];
    [scrollTestComponents addSubview:self.graphView];
...

In this case, the buttons btnGlass and btnDia work as expected, calling the 
correspondent method, but btnSemana doesn't work. Even when the button types 
are rounded rect, the first two buttons change color as they are touched, but 
btnSemana doesn't behave like this.

Does someone know what I doing wrong?

Thank you.___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How to redraw a view in slow-motion

[Ken Tozier]

Hi Matthias

I got frustrated with my own coding and thought I'd take another crack at your 
animation problem as a diversion...

Here's the result, enjoy

-Ken

#define DRAW_LINES_BLOCK_SIZE   100
#define DRAW_LINES_BLOCK_DELAY  1

- (void) setFrame:(NSRect) inRect
{
// I'm assuming you store you lines in an array
int lineCount   = [lineArray count],
leftovers   = lineCount % DRAW_LINES_BLOCK_SIZE,
blockCount  = lineCount / DRAW_LINES_BLOCK_SIZE + 
((leftovers == 0) ? 0 : 1);
maxBlockIndex   = blockCount - 1,
i;

NSRange subrange= NSMakeRange(0, DRAW_LINES_BLOCK_SIZE);

NSInvocation*invocation;
NSValue *rangeWrapper;

// next variable needs to be defined in the interface
if (invocationStack != nil)
[invocationStack release];

// allocate new invocation stack
invocationStack = [[NSMutableArray alloc] initWithCapacity: 
blockCount];

// populate invocation stack
for (i = 0; i < blockCount; i++)
{
rangeWrapper= [NSValue valueWithRange: subrange];

invocation  = [NSInvocation invocationWithMethodSignature: 
[self methodSignatureForSelector: @selector(drawBlockOfLines:)]];
[invocation setTarget: self];
[invocation setSelector: @selector(drawBlockOfLines:)];
[invocation setArgument: &rangeWrapper atIndex: 3];

[invocationStack addObject: invocation];

subrange.location   += DRAW_LINES_BLOCK_SIZE;

if (i == maxBlockIndex)
subrange.length = leftovers;
}

[super setFrame: inRect];
// may need a [self setNeedsDisplay: YES] here, not sure...
}



// in your drawRect method 
- (void) drawRect:(NSRect) inRect
{
// pop an invocation off the stack and run it
NSInvocation*invocation = [[invocationStack objectAtIndex: 0] 
retain];

[invocationStack removeObjectAtIndex: 0];

[invocation invoke];

[invocation release];

// schedule the next round of drawing
[NSTimer scheduledTimerWithTimeInterval: DRAW_LINES_BLOCK_DELAY target: 
self selector: @selector(drawRect:) userInfo: nil repeats: NO];
}

- (void) drawBlockOfLines:(NSValue *) inRange
{
NSRange range   = [inRange rangeValue];

// do your drawing here
}


On Jun 20, 2011, at 3:49 AM, Matthias Arndt wrote:

> Hi Graham, hi Uli,
> 
> guys, you're gems! Thanks for all the input. Currently it's too early to dive 
> into some high sophisticated optimization, and with Graham's info I'm 
> confident the view's back buffer will work for me.
> 
> Am 20. Jun 2011 um 08:59 schrieb Graham Cox :
> 
>> The view is already doing this for you. Everything drawn in a view actually 
>> ends up in a bitmap - the window's back buffer. If you draw a subrange of 
>> your objects, the ones you've earlier drawn into the back buffer are still 
>> there. The only time you have to start over is when the view resizes, which 
>> is what the 'needsErase' flag is for in my example - the back buffer gets 
>> cleared effectively clearing your "cache". There's no reason to reinvent the 
>> drawing mechanism from scratch, it's just a duplication of effort.
> 
> Hopefully I find some time these days to implement more details of the 
> animation based on NSTimer-triggered redraws: Currently it's only quick & 
> dirty, but seems to do the trick. I'll keep you posted.
> 
> Thanks again, Mattes
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/kentozier%40comcast.net
> 
> This email sent to kentoz...@comcast.net

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

NSSavePanel called from 64-bit NPAPI plugin

[Kevin Peterson]

I'm attempting a "save as" [NSSavePanel savePanel] modal dialog from an 
NPAPI plugin compiled for x86_64 and running under Safari 5.0.5 on OSX 
10.6.7.


Whenever the call to runModal completes Safari ends up in a wedged state 
in which none of menu pull downs are accessible (all greyed out) and the 
only way to exit is to force a quit.  I don't fully understand the 
structure of a modal window but in the wedged state it appears as though 
there's still a modal window open and expecting input even though it's 
not visible.


I've read some comments on this list that suggest that that creating 
windows from the WebkitPluginHost process is discouraged 
(http://lists.apple.com/archives/cocoa-dev/2010/Jun/msg00868.html) but 
does this really apply to the simple Cocoa/modal dialogs like 
NSSavePanel and NSOpenPanel?


Thanks in advance,
Kevin
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Use kAERestart to Restart Computer

[Andy Boutte]

Does any body have some sample code that they can share that will restart the 
computer?  I have looked at the code on these pages:

http://applerr.com/forum/mac/3648/programmatically-put-a-mac-into-sleep.htm
http://developer.apple.com/library/mac/#qa/qa1134/_index.html

What I cant figure out is what code I should put in my IBAction to make the 
restart happen.

-(IBAction) buttonAction: (id) sender {

}

Any help would be greatly appreciated.  


-Andy Boutte

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Disable implicit animations in layer backed NSScrollViews?

[Kyle Sluder]

On Jun 20, 2011, at 9:47 PM, Daniel Waylonis  wrote:

> Hi Kyle,
> 
> Thanks for the suggestion.
> 
> Unfortunately:
> 
> - (void)resizeWithOldSuperviewSize:(NSSize)oldSize {
>   [CATransaction begin];
>   [CATransaction setDisableActions:YES];
>   [super resizeWithOldSuperviewSize:oldSize];
>   [CATransaction commit];
> }
> 
> is still exhibiting the jumpy behavior.

Does it only happen on live resize?

> 
> Perhaps I'm not overriding the right action?  I'm returning "[NSNull null]" 
> for the "onLayout" key in my actionForLayer:forKey: method as well as setting 
> the layer's actions to have [NSNull null] for: position, bounds, frame, 
> hidden, sublayers, onLayout, anchorPoint, onOrderOut, onOrderIn.
> 
> If you happen to have a sample that work for you, I'd really appreciate you 
> sending it my way!

Unfortunately I'm about to board a plane for a week of vacation, so you might 
have better luck bringing this back on list.

I don't have any code handy, but we do have a public beta of OmniPlan 2 that 
has a custom view (not NSTableView) that has had all the kinks worked out of 
it. I might be forgetting another important fix we implemented.

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

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

Re: Progress Indicators Spin vs Bar

[Ken Tozier]

Hi James,

I recently finished a file routing app that does a lot of heavy duty operations 
to files and found that the combination of 
NSInvocationOperations/NSOperationQueue to be really programmer friendly. 

Among the stuff my app does is copy large image files from A to B, creates 
thumbnails and grayscale versions of them and writes the info to a database and 
with NSOperationQueues, there is basically no slowdown at all in the user 
interface. Queues can be stopped at any time so you could give the user that 
option. Here's a stripped down skeleton of how I'm using 
NSOperationQueue/NSInvocationOperation which might get you up and running with 
queues a bit faster. The key is, they are really forgiving and simple to use.

Of particular interest to you might be the delegate idea which allows the file 
processing method to continuously update and send info to another process which 
would help with your progress indicator issue

I just did a test with 1258 full sized images and it routed them, created 
thumbnails, grayscales and extracted a bunch of info in 3 minutes 24 seconds 
with no effect on user responsiveness of the machine or the app.

Enjoy

// In this example, your delegate in the user interface code, might have a 
handler defined like so
- (void) handleImageInfo:(id) inMessage
{
if ([inMessage isKindOfClass: [NSNumber class]])
// do something with the file count
else if ([inMessage isKindOfClass: [NSDictionary class]])
// add data from inMessage to your user interface
}


// Class that monitors and processes files in a drop folder
// For you, it might be a user selected scanning folder
- (id) init
{
self = [super init];
if (self)
{
queue   = [[NSOperationQueue alloc] init];
delegate= nil;
selector= nil;
return self;
}

[self release];
return nil;
}

- (void) setDelegate:(id) inDelegate
selector:(SEL) inSelector
{
delegate= [inDelegate retain];
selector= inSelector;
}


- (void) start
{
[self queueOperation];
}

- (void) stop
{
[queue setSuspended: YES];
}

- (void) queueOperation
{
NSInvocationOperation   *operation;

operation   = [[[NSInvocationOperation alloc] 
initWithTarget: self

selector:@selector(processDropFolder) 
object: nil]
autorelease];

[operation addObserver: self
forKeyPath: @"isFinished"
options: NSKeyValueObservingOptionNew
context: NULL];

[queue addOperation: operation];
}

- (void) processDropFolder
{
NSArray *fileNames  = 
UtilContentsOfDirectoryAtPath(dropFolder);

if ((fileNames != nil) && ([fileNames count] > 0))
{
NSNumber *fileCount = [NSNumber numberWithInt: 
[fileNames count]];

// send file count off to delegate
[delegate performSelector: selector withObject: fileCount];

// we have some photos to process
NSEnumerator*e  = [fileNames objectEnumerator];
NSString*filePath;
NSMutableDictionary *fileInfo;

NSLog(@"Scanning: %@", dropFolder);

while (fileName = [e nextObject])
{
// ignore invisible files
if (![fileName hasPrefix: @"."])
{
filePath= [dropFolder 
stringByAppendingPathComponent: fileName];

// read the exif info, find (or create) a 
thumbnail
// package it up in a nice NSDictionary and 
send it 
// to your delegate
NSDictionary *imgInfo   = 
UtilImageInfo(filePath);

if (imgInfo != nil)
[delegate performSelector: selector 
withObject: imgInfo];
}
}
}
}

- (void)observeValueForKeyPath:(NSString *) inKeyPath 
ofObject:(id) inObject 
change:(NSDictionary *) inChange 
context:(void *) inContext
{
if ([inKeyPath isEqualToString: @"isFinished"])
{
// remove invocation observer
[inObject removeObserver: self forKeyP

Re: Progress Indicators Spin vs Bar

[Conrad Shultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/20/11 8:57 PM, James Merkel wrote:
> Ok, I see GCD == Grand Central Dispatch. Available on Snow Leopard.
> I'm on 10.5.8. I'll probably have to buy a new machine and get back to
> you on this!

Ruh-roh.

If you need to support pre-SL, you can go with NSOperationQueue.  Also
covered in the concurrency programming guide.

It will (probably) require creating a subclass of NSOperation, so more
code, but conceptually similar to GCD (in that both provide facilities
for asynchronous execution).

- -- 
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOABd1aOlrz5+0JdURAqSiAJ9RZeCY+PM7VeKUQc48ET1U7WYcDwCfVf8f
TQXlgk+7keAz45LC/9UPdho=
=WL95
-END PGP SIGNATURE-
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[Conrad Shultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/20/11 8:43 PM, James Merkel wrote:

> First of all (kind of basic) what is GCD ?

Sorry, I shouldn't just throw acronyms around.  GCD stands for "Grand
Central Dispatch" - Apple's newest technology for concurrent
programming.  It has a relatively high-level API that wraps the whole
threading interface so you don't have to think about it.

Details are available at
http://developer.apple.com/library/mac/#documentation/Performance/Reference/GCD_libdispatch_Ref/Reference/reference.html
but you probably want to start with the Concurrency Programming Guide
(http://developer.apple.com/library/mac/#documentation/General/Conceptual/ConcurrencyProgrammingGuide/Introduction/Introduction.html)
for a gentler introduction.

> I have actually implemented this a couple of different ways (not using
> threads).
> At first I just had lazy loading of the TableView. Whenever the
> TableView needed something a file was accessed and a thumbnail
> extracted. Then I changed it to do preprocessing. That is, everything
> was extracted from the files  and then the TableView was allowed to
> load. The first approach uses less memory but is slower in updating the
> TableView (when it is scrolled for example). The second approach uses
> more memory but is faster in updating (provides a better user
> experience). I think trying to do this in a separate thread would be
> much cleaner using the second approach.

That you have already implemented these approaches should simplify the
transition to a multithreaded app.  The code that you have been
extracting during your experimentation should hopefully map pretty well
onto my imaginary -exifData and -thumbnail methods; note that my code
did not make any changes to the mechanics of HOW the thumbnails are
extracted/generated, instead just changing WHEN (and where) the
generation occurs.

You could really use either approach you gave above.  My pseudocode in
the previous message probably is more in line with the second approach,
but you could trivially use the first as well.

In either case, one little trick is that you will want to have a static
placeholder thumbnail at the ready that your table can display until
such time that the threaded code has the actual thumbnail finished.

> I forgot to mention the really slow case: if a thumbnail can't be found
> in the file, then I make a thumbnail from the main image. If this has to
> be done on a lot of files, then things really bog down.

But if the thumbnailing is on a second thread, this won't matter... just
have the threaded code make the thumbnail.  It's like magic, but better. :-)

Give the concurrency programming guide a once-over and post back with
follow-up questions; I think you will find that what you are trying to
do is not as tough as it appears.

- -- 
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOABbEaOlrz5+0JdURAhhWAJ9gakekUwXm8VyEC3zo5yXKeR47yACfVPZR
JF4mJBazIwwz6S3ROgFMopI=
=7QXU
-END PGP SIGNATURE-
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[James Merkel]

On Jun 20, 2011, at 8:43 PM, James Merkel wrote:




On Jun 20, 2011, at 7:23 PM, Conrad Shultz wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/20/11 3:54 PM, James Merkel wrote:

I'm opening all  digital camera files in a folder (JPEG, TIF, etc),
extracting a thumbnail and some Exif data, and putting the data in a
TableView. The time consuming part is finding the thumbnails in  
the files.


OK.

I don't know anything about extracting thumbnails et al., but for the
sake of argument suppose you have a class JMImageProcessor that has
methods like:

- - (id)initWithFileHandle:(NSFileHandle *)fileHandle;
- - (NSDictionary *)exifData;
- - (NSImage *)thumbnail; // Takes a long time to run

So in your main thread you then have a loop over a bunch of
NSFileHandles (of course you might be accessing the files completely
differently; this is just for illustration).  So you might  
currently have:


for (NSFileHandle *fileHandle in files) {
JMImageProcessor *processor = [[JMImageProcessor alloc]
initWithFileHandle:fileHandle];
// Call some code to stash the results, presumably updating the
tableView's data source in the process
[self setExifData:[processor exifData] forFile:fileHandle];
[self setThumbnail:[processor thumbnail] forFile:fileHandle];
[processor release];
// Call some code to redisplay the NSTableView
[self updateTable];
}




You could make such code non-blocking with, for example, GCD:




dispatch_queue_t workerQueue =
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, NULL);

for (NSFileHandle *fileHandle in files) {
dispatch_async(workerQueue,
^{
JMImageProcessor *processor = [[JMImageProcessor alloc]
initWithFileHandle:fileHandle];
[self setExifData:[processor exifData] 
forFile:fileHandle];
[self setThumbnail:[processor thumbnail] 
forFile:fileHandle];
[processor release];
dispatch_async(dispatch_get_main_queue(),
^{
[self updateTable];
// UI updates need to be on the main 
thread, i.e., the GCD main
queue, so we call back asynchronously
}
);
}
);
}

(Note 1: this was all written in a mail client and untested.)

(Note 2: the above assumes that the setExifData/setThumbnail  
methods are

implemented properly, atomically if required.  But if the methods are
backed by, for example, mutable dictionaries, and anything accessing
them handle absent entries reasonably, this should be pretty
straightforward.)

(Note 3: this could all alternatively be done with  
NSOperationQueue, or

even plain old NSThread.  But GCD can probably do it in the smallest
amount of code.)

Good luck!

- --
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOAACvaOlrz5+0JdURAvzkAJ9XaQ4CqRXY4k6fKtRdVkqcYBeBewCeL8fh
jOJSgWEisHfOU6/WflFoukA=
=swOg
-END PGP SIGNATURE-


First of all (kind of basic) what is GCD ?

I have actually implemented this a couple of different ways (not  
using threads).
At first I just had lazy loading of the TableView. Whenever the  
TableView needed something a file was accessed and a thumbnail  
extracted. Then I changed it to do preprocessing. That is,  
everything was extracted from the files  and then the TableView was  
allowed to load. The first approach uses less memory but is slower  
in updating the TableView (when it is scrolled for example). The  
second approach uses more memory but is faster in updating (provides  
a better user experience). I think trying to do this in a separate  
thread would be much cleaner using the second approach.


I forgot to mention the really slow case: if a thumbnail can't be  
found in the file, then I make a thumbnail from the main image. If  
this has to be done on a lot of files, then things really bog down.


Jim Merkel




Ok, I see GCD == Grand Central Dispatch. Available on Snow Leopard.
I'm on 10.5.8. I'll probably have to buy a new machine and get back to  
you on this!


Jim Merkel
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[davelist]

On Jun 20, 2011, at 11:43 PM, James Merkel wrote:

> 
> 
> On Jun 20, 2011, at 7:23 PM, Conrad Shultz wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>> 
>> On 6/20/11 3:54 PM, James Merkel wrote:
>>> I'm opening all  digital camera files in a folder (JPEG, TIF, etc),
>>> extracting a thumbnail and some Exif data, and putting the data in a
>>> TableView. The time consuming part is finding the thumbnails in the files.
>> 
>> OK.
>> 
>> I don't know anything about extracting thumbnails et al., but for the
>> sake of argument suppose you have a class JMImageProcessor that has
>> methods like:
>> 
>> - - (id)initWithFileHandle:(NSFileHandle *)fileHandle;
>> - - (NSDictionary *)exifData;
>> - - (NSImage *)thumbnail; // Takes a long time to run
>> 
>> So in your main thread you then have a loop over a bunch of
>> NSFileHandles (of course you might be accessing the files completely
>> differently; this is just for illustration).  So you might currently have:
>> 
>> for (NSFileHandle *fileHandle in files) {
>>  JMImageProcessor *processor = [[JMImageProcessor alloc]
>> initWithFileHandle:fileHandle];
>>  // Call some code to stash the results, presumably updating the
>> tableView's data source in the process
>>  [self setExifData:[processor exifData] forFile:fileHandle];
>>  [self setThumbnail:[processor thumbnail] forFile:fileHandle];
>>  [processor release];
>>  // Call some code to redisplay the NSTableView
>>  [self updateTable];
>> }
>> 
>> 
>> 
>> 
>> You could make such code non-blocking with, for example, GCD:
>> 
>> 
>> 
>> 
>> dispatch_queue_t workerQueue =
>> dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, NULL);
>> 
>> for (NSFileHandle *fileHandle in files) {
>>  dispatch_async(workerQueue,
>>  ^{
>>  JMImageProcessor *processor = [[JMImageProcessor alloc]
>> initWithFileHandle:fileHandle];
>>  [self setExifData:[processor exifData] 
>> forFile:fileHandle];
>>  [self setThumbnail:[processor thumbnail] 
>> forFile:fileHandle];
>>  [processor release];
>>  dispatch_async(dispatch_get_main_queue(),
>>  ^{
>>  [self updateTable];
>>  // UI updates need to be on the main 
>> thread, i.e., the GCD main
>> queue, so we call back asynchronously
>>  }
>>  );
>>  }
>>  );
>> }
>> 
>> (Note 1: this was all written in a mail client and untested.)
>> 
>> (Note 2: the above assumes that the setExifData/setThumbnail methods are
>> implemented properly, atomically if required.  But if the methods are
>> backed by, for example, mutable dictionaries, and anything accessing
>> them handle absent entries reasonably, this should be pretty
>> straightforward.)
>> 
>> (Note 3: this could all alternatively be done with NSOperationQueue, or
>> even plain old NSThread.  But GCD can probably do it in the smallest
>> amount of code.)
>> 
>> Good luck!
>> 
>> - --
>> Conrad Shultz
>> 
>> Synthetiq Solutions
>> www.synthetiqsolutions.com
> 

> First of all (kind of basic) what is GCD ?
> 
> I have actually implemented this a couple of different ways (not using 
> threads).
> At first I just had lazy loading of the TableView. Whenever the TableView 
> needed something a file was accessed and a thumbnail extracted. Then I 
> changed it to do preprocessing. That is, everything was extracted from the 
> files  and then the TableView was allowed to load. The first approach uses 
> less memory but is slower in updating the TableView (when it is scrolled for 
> example). The second approach uses more memory but is faster in updating 
> (provides a better user experience). I think trying to do this in a separate 
> thread would be much cleaner using the second approach.
> 
> I forgot to mention the really slow case: if a thumbnail can't be found in 
> the file, then I make a thumbnail from the main image. If this has to be done 
> on a lot of files, then things really bog down.
> 
> Jim Merkel


GCD is Grand Central Dispatch - Apple's very nice API for writing multithreaded 
code.

You should read the Concurrency Programming Guide at developer.apple.com



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

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

Re: Progress Indicators Spin vs Bar

[James Merkel]

On Jun 20, 2011, at 7:23 PM, Conrad Shultz wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/20/11 3:54 PM, James Merkel wrote:

I'm opening all  digital camera files in a folder (JPEG, TIF, etc),
extracting a thumbnail and some Exif data, and putting the data in a
TableView. The time consuming part is finding the thumbnails in the  
files.


OK.

I don't know anything about extracting thumbnails et al., but for the
sake of argument suppose you have a class JMImageProcessor that has
methods like:

- - (id)initWithFileHandle:(NSFileHandle *)fileHandle;
- - (NSDictionary *)exifData;
- - (NSImage *)thumbnail; // Takes a long time to run

So in your main thread you then have a loop over a bunch of
NSFileHandles (of course you might be accessing the files completely
differently; this is just for illustration).  So you might currently  
have:


for (NSFileHandle *fileHandle in files) {
JMImageProcessor *processor = [[JMImageProcessor alloc]
initWithFileHandle:fileHandle];
// Call some code to stash the results, presumably updating the
tableView's data source in the process
[self setExifData:[processor exifData] forFile:fileHandle];
[self setThumbnail:[processor thumbnail] forFile:fileHandle];
[processor release];
// Call some code to redisplay the NSTableView
[self updateTable];
}




You could make such code non-blocking with, for example, GCD:




dispatch_queue_t workerQueue =
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, NULL);

for (NSFileHandle *fileHandle in files) {
dispatch_async(workerQueue,
^{
JMImageProcessor *processor = [[JMImageProcessor alloc]
initWithFileHandle:fileHandle];
[self setExifData:[processor exifData] 
forFile:fileHandle];
[self setThumbnail:[processor thumbnail] 
forFile:fileHandle];
[processor release];
dispatch_async(dispatch_get_main_queue(),
^{
[self updateTable];
// UI updates need to be on the main 
thread, i.e., the GCD main
queue, so we call back asynchronously
}
);
}
);
}

(Note 1: this was all written in a mail client and untested.)

(Note 2: the above assumes that the setExifData/setThumbnail methods  
are

implemented properly, atomically if required.  But if the methods are
backed by, for example, mutable dictionaries, and anything accessing
them handle absent entries reasonably, this should be pretty
straightforward.)

(Note 3: this could all alternatively be done with NSOperationQueue,  
or

even plain old NSThread.  But GCD can probably do it in the smallest
amount of code.)

Good luck!

- --
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOAACvaOlrz5+0JdURAvzkAJ9XaQ4CqRXY4k6fKtRdVkqcYBeBewCeL8fh
jOJSgWEisHfOU6/WflFoukA=
=swOg
-END PGP SIGNATURE-


First of all (kind of basic) what is GCD ?

I have actually implemented this a couple of different ways (not using  
threads).
At first I just had lazy loading of the TableView. Whenever the  
TableView needed something a file was accessed and a thumbnail  
extracted. Then I changed it to do preprocessing. That is, everything  
was extracted from the files  and then the TableView was allowed to  
load. The first approach uses less memory but is slower in updating  
the TableView (when it is scrolled for example). The second approach  
uses more memory but is faster in updating (provides a better user  
experience). I think trying to do this in a separate thread would be  
much cleaner using the second approach.


I forgot to mention the really slow case: if a thumbnail can't be  
found in the file, then I make a thumbnail from the main image. If  
this has to be done on a lot of files, then things really bog down.


Jim Merkel


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[Conrad Shultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/20/11 3:54 PM, James Merkel wrote:
> I'm opening all  digital camera files in a folder (JPEG, TIF, etc),
> extracting a thumbnail and some Exif data, and putting the data in a
> TableView. The time consuming part is finding the thumbnails in the files.

OK.

I don't know anything about extracting thumbnails et al., but for the
sake of argument suppose you have a class JMImageProcessor that has
methods like:

- - (id)initWithFileHandle:(NSFileHandle *)fileHandle;
- - (NSDictionary *)exifData;
- - (NSImage *)thumbnail; // Takes a long time to run

So in your main thread you then have a loop over a bunch of
NSFileHandles (of course you might be accessing the files completely
differently; this is just for illustration).  So you might currently have:

for (NSFileHandle *fileHandle in files) {
JMImageProcessor *processor = [[JMImageProcessor alloc]
initWithFileHandle:fileHandle];
// Call some code to stash the results, presumably updating the
tableView's data source in the process
[self setExifData:[processor exifData] forFile:fileHandle];
[self setThumbnail:[processor thumbnail] forFile:fileHandle];
[processor release];
// Call some code to redisplay the NSTableView
[self updateTable];
}




You could make such code non-blocking with, for example, GCD:




dispatch_queue_t workerQueue =
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, NULL);

for (NSFileHandle *fileHandle in files) {
dispatch_async(workerQueue,
^{
JMImageProcessor *processor = [[JMImageProcessor alloc]
initWithFileHandle:fileHandle];
[self setExifData:[processor exifData] 
forFile:fileHandle];
[self setThumbnail:[processor thumbnail] 
forFile:fileHandle];
[processor release];
dispatch_async(dispatch_get_main_queue(),
^{
[self updateTable];
// UI updates need to be on the main 
thread, i.e., the GCD main
queue, so we call back asynchronously
}
);
}
);
}

(Note 1: this was all written in a mail client and untested.)

(Note 2: the above assumes that the setExifData/setThumbnail methods are
implemented properly, atomically if required.  But if the methods are
backed by, for example, mutable dictionaries, and anything accessing
them handle absent entries reasonably, this should be pretty
straightforward.)

(Note 3: this could all alternatively be done with NSOperationQueue, or
even plain old NSThread.  But GCD can probably do it in the smallest
amount of code.)

Good luck!

- -- 
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFOAACvaOlrz5+0JdURAvzkAJ9XaQ4CqRXY4k6fKtRdVkqcYBeBewCeL8fh
jOJSgWEisHfOU6/WflFoukA=
=swOg
-END PGP SIGNATURE-
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Automatically mirroring folders

[Leonardo]

It's simply great! I am going to try it right now.
The point is that I didn't see that option, and I have checked that page
several times. My head is full of variables... I need a break.


Regards
-- Leonardo


> Da: Matt Gough 
> Data: Mon, 20 Jun 2011 08:53:40 +0100
> A: Leonardo 
> Cc: 
> Oggetto: Re: Automatically mirroring folders
> 
> Can you not make use of:
> 
> kFSEventStreamCreateFlagIgnoreSelf
> "Ignore events generated by this client. For example, an application might
> want to watch for changes to a file so that it can reread it, but should not
> needlessly reread it if the change to the file was caused by the application
> itself writing out changes."
> 
> Matt
> 
> On 19 Jun 2011, at 17:48:32, Leonardo wrote:
> 
>> Problem: I have to automatically mirror 2 folders, /A and /B, such a way
>> they contains the same files and folders.
>> 
>> - So I FSEventStreamCreate with kFSEventStreamEventIdSinceNow,
>> kFSEventStreamCreateFlagWatchRoot and a 2 seconds latency time.
>> 
>> - I get a notification: there is a new file to copy from /A to /B. I copy
>> the file, but I quickly get a new notification that there is a new file in
>> B. Well, this notification is useless to me. I copied that file. Therefore I
>> don't need to copy it again.
>> 
>> - So, before I copy the file, I thought, I stop and invalidate the stream,
>> then I copy the file, then I turn the stream on again. But here I get 2
>> problems:
>> 
>> 1) At the end of the copyFile, I turn the stream on again, and the Finder, a
>> couple of seconds later (but it could even be shorter or longer) updates the
>> /B/.DS_Store file so I get a new notification. How to force the Finder to
>> update the .DS_Store file immediately after the copy? Or should I use a
>> longer latency time? How long?
>> 
>> 2) During the period of time the stream is off, if some new files arrive
>> within the folder /A, I lose the notification to copy it.
>> 
>> How to workaround that?
>> 
>> 
>> Regards
>> -- Leonardo
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/devlists.mg%40googlemail.com
>> 
>> This email sent to devlists...@googlemail.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

UIScrolview in only one direction at time

[Tales Pinheiro de Andrade]

Hello,

is it possible to temporally disable the scroll in one direction? For example, 
if the user start scrolling in horizontal, so it's only possible to scroll in 
that direction, until the scroll end. After that, if the user starts scrolling 
in vertical, it's temporally (until the scrolls end) not possible to scroll in 
horizontal.

How can I check this scroll?

Thank you
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Disable implicit animations in layer backed NSScrollViews?

[Kyle Sluder]

On Mon, Jun 20, 2011 at 3:52 PM, Daniel Waylonis  wrote:
> When I resize, the contents "jump" in the table view.  I believe it is 
> because there's an implicit animation to move the bounds and/or position.  Or 
> maybe something in the clip?  I'd also not like it to fade in if I toggle 
> between layer-backed and not.

Make sure that in your implementation of -resizeWithOldSuperviewSize:
that you call super's implementation. This bit us for a long time, but
apparently that's one of the places where the layer glue fixes up the
layer's geometry to match the AppKit geometry. You need to do this
even if you have custom logic in this method that will completely
nullify what super did. You may need to wrap the call to super in a
CATransaction with +setDisableActions:YES.

rdar://problem/8659667

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

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

Re: Progress Indicators Spin vs Bar

[James Merkel]

On Jun 20, 2011, at 3:33 PM, Conrad Shultz wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/20/11 3:17 PM, James Merkel wrote:
I am trying to come up with a way of not using threads (because of  
the
potential problems). All I really want to do is give the user a way  
of

canceling the long process. I was thinking of just sampling a cancel
state variable every time through the loop. Of course that introduces
overhead, and there's the possibility the user cancels on a  
particularly

long duration loop cycle and wouldn't quickly see a response to his
cancel. I would think there is some simpler method than using threads
for handling this fairly common situation of a handling a long  
process.


Please don't do this.

If the main thread is blocked by whatever your process is doing the UI
will not respond.  You won't be able to set a cancel state variable
while the main thread is blocked - it's what handles responding to,
e.g., button clicks!

I'd say that in general your application should be event driven; let  
the
run loop do its thing and handle events as appropriate.  About the  
only

time I can think of to use a state variable as you describe is in, for
example, an NSOperation, to mark it as canceled.  But such an  
operation

would itself be running on a separate thread (most commonly).

While we often make it sound scary, threading needn't be difficult to
implement.  You have GCD, you have NSOperation/NSOperationQueue;  
between
the two you have quite a bit of power with minimal lines of code  
needed.
Depending on what you need to do in your loop, it might be as simple  
as

calling dispatch_async().

Of course, if you need to handle locking, mutual exclusion, thread
coordination, etc., THEN threading can start to get tough, but it
doesn't really sound like this applies to you.

Can you remind me what you are trying to accomplish (broad overview)?

- --
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3/ysUACgkQaOlrz5+0JdU97wCdGwNBFZKMCdTgHediaXlQumgf
3ZUAnjDaoQrFHxAghq48tDOFlm6NdVW4
=5gh7
-END PGP SIGNATURE-


I guess that's right -- I'll never capture the user's cancel.

I'm opening all  digital camera files in a folder (JPEG, TIF, etc),  
extracting a thumbnail and some Exif data, and putting the data in a  
TableView. The time consuming part is finding the thumbnails in the  
files.


Jim Merkel

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Disable implicit animations in layer backed NSScrollViews?

[Daniel Waylonis]

I'm stuck on a weird bug with NSTableViews and CALayers.  I tried to ask up at 
WWDC in one of the labs, but didn't get an answer.

I have a auto-resizing NSTableView subclass in NSScrollView in a layer backed 
view.  I'm using the 10.6 SDK and targeting 10.5 as well.

When I resize, the contents "jump" in the table view.  I believe it is because 
there's an implicit animation to move the bounds and/or position.  Or maybe 
something in the clip?  I'd also not like it to fade in if I toggle between 
layer-backed and not.

I've searched on the mailing lists, StackOverflow, and Google in general for 
this, but I haven't found a solution.

I've tried the following but without any change to the behavior:

1. Custom NSScrollView and NSTableView, each of which implement what I believe 
should disable animations:
- (id)actionForLayer:(CALayer *)layer forKey:(NSString *)key {
return (id)[NSNull null];
}

I also tried returning nil as well.

2. Setting the actions (position, bounds, frame, hidden, onOrderIn) on the 
layers to NSNull.
3. Bracketing live resize methods with a CATransaction to disable animations.  
The results were not pretty.

I have a small sample project available: 

Oddly enough, when the view is small and the scroll bar is present, the 
"jumping" doesn't occur.

Thoughts and suggestions welcomed!

Dan
-
Dan Waylonis | nekotech.com
650.887.3711

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[Conrad Shultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/20/11 3:17 PM, James Merkel wrote:
> I am trying to come up with a way of not using threads (because of the
> potential problems). All I really want to do is give the user a way of
> canceling the long process. I was thinking of just sampling a cancel
> state variable every time through the loop. Of course that introduces
> overhead, and there's the possibility the user cancels on a particularly
> long duration loop cycle and wouldn't quickly see a response to his
> cancel. I would think there is some simpler method than using threads
> for handling this fairly common situation of a handling a long process.

Please don't do this.

If the main thread is blocked by whatever your process is doing the UI
will not respond.  You won't be able to set a cancel state variable
while the main thread is blocked - it's what handles responding to,
e.g., button clicks!

I'd say that in general your application should be event driven; let the
run loop do its thing and handle events as appropriate.  About the only
time I can think of to use a state variable as you describe is in, for
example, an NSOperation, to mark it as canceled.  But such an operation
would itself be running on a separate thread (most commonly).

While we often make it sound scary, threading needn't be difficult to
implement.  You have GCD, you have NSOperation/NSOperationQueue; between
the two you have quite a bit of power with minimal lines of code needed.
 Depending on what you need to do in your loop, it might be as simple as
calling dispatch_async().

Of course, if you need to handle locking, mutual exclusion, thread
coordination, etc., THEN threading can start to get tough, but it
doesn't really sound like this applies to you.

Can you remind me what you are trying to accomplish (broad overview)?

- -- 
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3/ysUACgkQaOlrz5+0JdU97wCdGwNBFZKMCdTgHediaXlQumgf
3ZUAnjDaoQrFHxAghq48tDOFlm6NdVW4
=5gh7
-END PGP SIGNATURE-
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[James Merkel]

On Jun 20, 2011, at 2:05 PM, Greg Parker wrote:


On Jun 20, 2011, at 11:47 AM, James Merkel wrote:
Another question -- when should a progress indicator be put up? The  
length of time in my processing loop can very greatly. I could be  
processing 3 files or 300 files. It seems a waste to flash a  
progress indicator for very short processing cases. On the other  
hand I can't just set a threshold for putting up a progress  
indicator, since the processing period can very from one machine to  
another. Also the processing period varies for different file types  
and even varies on the same machine from run to run.  No obvious  
answers to some of these questions.



One solution is to simply start the operation with no displayed  
progress, then later show the progress if it has not finished in X  
seconds.


(Programmatically: schedule a one-shot NSTimer for X seconds later  
that starts showing progress when it fires. When the operation  
finishes, cancel the timer if it has not fired already. Do this both  
of these on the main thread to avoid thread-safety problems.)


Your app will feel faster if short operations appear to finish  
"instantly" instead of briefly flashing a progress bar. File  
operations in the Finder do something like this.


On the other hand, you should always show progress if the operation  
has no user-visible side effects. Nothing is worse than displaying  
nothing and leaving the user to wonder whether it did anything at  
all. In this case you want the finished progress bar to appear as a  
confirmation to the user for at least some minimum length of time.



True it's extra code to conditionally display an indicator, so I  
may as well always display it.
The bigger problem is putting the long process into another thread.  
Need to delve into that.


Yes, the work thread will be the hard part. Polishing the progress  
UI should be straightforward after that.



--
Greg Parker gpar...@apple.com Runtime Wrangler




I hadn't thought of that -- putting up a progress indicator after a  
short passage of time. Sounds like a better way to go.


I am trying to come up with a way of not using threads (because of the  
potential problems). All I really want to do is give the user a way of  
canceling the long process. I was thinking of just sampling a cancel  
state variable every time through the loop. Of course that introduces  
overhead, and there's the possibility the user cancels on a  
particularly long duration loop cycle and wouldn't quickly see a  
response to his cancel. I would think there is some simpler method  
than using threads for handling this fairly common situation of a  
handling a long process.


Jim Merkel
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How to design a utilities panel as seen in XCode4?

[jonat...@mugginsoft.com]

On 20 Jun 2011, at 21:51, Luc Van Bogaert wrote:

> Hi,
> 
> In the application I'm building, I'm using some kind of "inspector" panel 
> that will display and allow the editing of various attributes of some 
> selected object. We're talking about a significant number of attributes, so I 
> would like to arrange them into logical groups to present them to the user. I 
> could use a tabbed view with a seperate tab for each of the groups, but I 
> also like the way XCode 4 lays out its utilities panel, with various 
> subpanels that can be displayed or hidden using a disclosure triangle. I 
> don't know what kind of objects that could be used to implement such a 
> configuration, nor do I understand how the various subviews should by 
> organized, so that hiding one view moves the  remaining views into place. 
> Could anyone provide or share some tips please?
> 

Github has various frameworks that might be of interest.

https://github.com/ilg/InspectorKit.framework
https://github.com/omnigroup/OmniGroup
https://github.com/sbooth/SFBInspectors

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.com

> Thank you,
> -- 
> Luc Van Bogaert
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/jonathan%40mugginsoft.com
> 
> This email sent to jonat...@mugginsoft.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[Greg Parker]

On Jun 20, 2011, at 11:47 AM, James Merkel wrote:
> Another question -- when should a progress indicator be put up? The length of 
> time in my processing loop can very greatly. I could be processing 3 files or 
> 300 files. It seems a waste to flash a progress indicator for very short 
> processing cases. On the other hand I can't just set a threshold for putting 
> up a progress indicator, since the processing period can very from one 
> machine to another. Also the processing period varies for different file 
> types and even varies on the same machine from run to run.  No obvious 
> answers to some of these questions.


One solution is to simply start the operation with no displayed progress, then 
later show the progress if it has not finished in X seconds. 

(Programmatically: schedule a one-shot NSTimer for X seconds later that starts 
showing progress when it fires. When the operation finishes, cancel the timer 
if it has not fired already. Do this both of these on the main thread to avoid 
thread-safety problems.)

Your app will feel faster if short operations appear to finish "instantly" 
instead of briefly flashing a progress bar. File operations in the Finder do 
something like this.

On the other hand, you should always show progress if the operation has no 
user-visible side effects. Nothing is worse than displaying nothing and leaving 
the user to wonder whether it did anything at all. In this case you want the 
finished progress bar to appear as a confirmation to the user for at least some 
minimum length of time.


> True it's extra code to conditionally display an indicator, so I may as well 
> always display it.
> The bigger problem is putting the long process into another thread. Need to 
> delve into that.

Yes, the work thread will be the hard part. Polishing the progress UI should be 
straightforward after that.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

How to design a utilities panel as seen in XCode4?

[Luc Van Bogaert]

Hi,

In the application I'm building, I'm using some kind of "inspector" panel that 
will display and allow the editing of various attributes of some selected 
object. We're talking about a significant number of attributes, so I would like 
to arrange them into logical groups to present them to the user. I could use a 
tabbed view with a seperate tab for each of the groups, but I also like the way 
XCode 4 lays out its utilities panel, with various subpanels that can be 
displayed or hidden using a disclosure triangle. I don't know what kind of 
objects that could be used to implement such a configuration, nor do I 
understand how the various subviews should by organized, so that hiding one 
view moves the  remaining views into place. Could anyone provide or share some 
tips please?

Thank you,
-- 
Luc Van Bogaert



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[James Merkel]

On Jun 20, 2011, at 12:05 PM, Conrad Shultz wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/20/11 11:47 AM, James Merkel wrote:


On Jun 20, 2011, at 2:01 AM, Mike Abdullah wrote:



On 20 Jun 2011, at 09:31, James Merkel wrote:


Yeah, I just kind of avoided the basic problem.  The app isn't
receiving at least some events -- for example the menus can't be
pulled down. On the other hand,  the spinning beach ball doesn't
appear, and I can drag the progress window around.


Window dragging is handled by the window server so that an
unresponsive app can't affect it.



Upon further investigation I see that the beach ball does finally  
appear.
I guess the question is, what is the definition of unresponsive? An  
app
will always have short unresponsive periods when it is doing  
something.


Disclosure: I haven't really been following this thread (no pun
intended) so I apologize if some of this has been said or is not  
applicable.


"Unresponsive" means the main thread is blocked, i.e. it's not able to
process events (e.g. keystrokes, clicks), update the UI, or even  
respond

to a SIGTERM (hence the "Force Quit" - SIGKILL).

Of course every action on the main thread takes SOME finite amount of
time, but the idea is that a well designed program offloads any tasks
that could potentially take a perceptible amount of time onto a
secondary thread so that the main thread can proceed, the run loop  
turns

over, etc.

There are certain situations where either processing must occur on the
main thread (classes in AppKit or UIKit that are designated
non-thread-safe come to mind) or where a task cannot logically proceed
until a task is completed (for example, if a data model needs to be
loaded in order for the app to be useful).  In such cases, at a  
minimum
you want to have a progress indicator so that user doesn't think the  
app

has crashed.  You should also go to great lengths to try to still
offload such activity so that you can have the main thread handle some
UI to allow the operation to be canceled if it's taking longer than  
the
user wants (think of the "Stop" button omnipresent in every web  
browser).



Another question -- when should a progress indicator be put up? The
length of time in my processing loop can very greatly. I could be
processing 3 files or 300 files. It seems a waste to flash a progress
indicator for very short processing cases. On the other hand I can't
just set a threshold for putting up a progress indicator, since the
processing period can very from one machine to another. Also the
processing period varies for different file types and even varies  
on the

same machine from run to run.  No obvious answers to some of these
questions.


I would say that if a procedure can potentially take a perceptible
amount of time, go ahead and display a progress indicator.  If it's so
quick that the user doesn't even see it, so be it.  Check out how web
browsers do it... even going to http://localhost in Safari or Firefox
shows a progress indicator for a fleeting moment.

I don't really understand what you mean by "a waste."  It would be
_more_ code to conditionally display an indicator, and in the case  
where

you would consider not putting one up it follows that you can't be
taxing the processor too much, so it's not like you're going to be
slowing things down appreciably.

- --
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3/mewACgkQaOlrz5+0JdV9BwCcCv7VwQkBf3/TJO+rMVh/hbW7
IKgAoIiyiflPyQ2DL/GPzgwXP2IK58iA
=Z5g/
-END PGP SIGNATURE-


True it's extra code to conditionally display an indicator, so I may  
as well always display it.
The bigger problem is putting the long process into another thread.  
Need to delve into that.


Thanks,
Jim Merkel


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[Quincey Morris]

On Jun 20, 2011, at 11:47, James Merkel wrote:

> Upon further investigation I see that the beach ball does finally appear.
> I guess the question is, what is the definition of unresponsive? An app will 
> always have short unresponsive periods when it is doing something.

I try to relate it to visual animation. Our brains are happy to treat 24 fps as 
smooth motion. Once the rate falls down below about 20 fps, we see jerky 
motion. If it falls far enough, we stop seeing motion and see a slideshow. 

For UI "motion" (now I'm talking about UI activity, not actual video 
animation), jerky "motion" seems a reasonable compromise between processing 
overhead and responsiveness, so I use something in the range of 1/10th to 
1/15th of a second (i.e. the equivalent of 10-15 fps) as my definition of 
unresponsive, for things like clicking a cancel button.

There's no real science in what I just said.

> Another question -- when should a progress indicator be put up? The length of 
> time in my processing loop can very greatly. I could be processing 3 files or 
> 300 files. It seems a waste to flash a progress indicator for very short 
> processing cases. On the other hand I can't just set a threshold for putting 
> up a progress indicator, since the processing period can very from one 
> machine to another. Also the processing period varies for different file 
> types and even varies on the same machine from run to run.  No obvious 
> answers to some of these questions.

I think the usual value is in the range of 3-5 seconds. What you're trying to 
do is get the progress indicator displayed *before* the user starts thinking 
about whether anything is happening (or, more specifically, starts feeling 
anxious the initiating menu choice or button press maybe got ignored).

OTOH, you're not always in control of the length of time things take. (My 
favorite is doing something that requires loading a nib file, like displaying a 
sheet, where the file access causes an unrelated external disk to spin up, so 
everything freezes for 6 seconds. The app's not at fault for the delay, but it 
takes the blame.) So maybe it's not a waste to always show the indicator.


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[Conrad Shultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/20/11 11:47 AM, James Merkel wrote:
> 
> On Jun 20, 2011, at 2:01 AM, Mike Abdullah wrote:
> 
>>
>> On 20 Jun 2011, at 09:31, James Merkel wrote:
>>
>>> Yeah, I just kind of avoided the basic problem.  The app isn't
>>> receiving at least some events -- for example the menus can't be
>>> pulled down. On the other hand,  the spinning beach ball doesn't
>>> appear, and I can drag the progress window around.
>>
>> Window dragging is handled by the window server so that an
>> unresponsive app can't affect it.
>>
> 
> Upon further investigation I see that the beach ball does finally appear.
> I guess the question is, what is the definition of unresponsive? An app
> will always have short unresponsive periods when it is doing something.

Disclosure: I haven't really been following this thread (no pun
intended) so I apologize if some of this has been said or is not applicable.

"Unresponsive" means the main thread is blocked, i.e. it's not able to
process events (e.g. keystrokes, clicks), update the UI, or even respond
to a SIGTERM (hence the "Force Quit" - SIGKILL).

Of course every action on the main thread takes SOME finite amount of
time, but the idea is that a well designed program offloads any tasks
that could potentially take a perceptible amount of time onto a
secondary thread so that the main thread can proceed, the run loop turns
over, etc.

There are certain situations where either processing must occur on the
main thread (classes in AppKit or UIKit that are designated
non-thread-safe come to mind) or where a task cannot logically proceed
until a task is completed (for example, if a data model needs to be
loaded in order for the app to be useful).  In such cases, at a minimum
you want to have a progress indicator so that user doesn't think the app
has crashed.  You should also go to great lengths to try to still
offload such activity so that you can have the main thread handle some
UI to allow the operation to be canceled if it's taking longer than the
user wants (think of the "Stop" button omnipresent in every web browser).

> Another question -- when should a progress indicator be put up? The
> length of time in my processing loop can very greatly. I could be
> processing 3 files or 300 files. It seems a waste to flash a progress
> indicator for very short processing cases. On the other hand I can't
> just set a threshold for putting up a progress indicator, since the
> processing period can very from one machine to another. Also the
> processing period varies for different file types and even varies on the
> same machine from run to run.  No obvious answers to some of these
> questions.

I would say that if a procedure can potentially take a perceptible
amount of time, go ahead and display a progress indicator.  If it's so
quick that the user doesn't even see it, so be it.  Check out how web
browsers do it... even going to http://localhost in Safari or Firefox
shows a progress indicator for a fleeting moment.

I don't really understand what you mean by "a waste."  It would be
_more_ code to conditionally display an indicator, and in the case where
you would consider not putting one up it follows that you can't be
taxing the processor too much, so it's not like you're going to be
slowing things down appreciably.

- -- 
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.com
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3/mewACgkQaOlrz5+0JdV9BwCcCv7VwQkBf3/TJO+rMVh/hbW7
IKgAoIiyiflPyQ2DL/GPzgwXP2IK58iA
=Z5g/
-END PGP SIGNATURE-
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[James Merkel]

On Jun 20, 2011, at 2:01 AM, Mike Abdullah wrote:



On 20 Jun 2011, at 09:31, James Merkel wrote:

Yeah, I just kind of avoided the basic problem.  The app isn't  
receiving at least some events -- for example the menus can't be  
pulled down. On the other hand,  the spinning beach ball doesn't  
appear, and I can drag the progress window around.


Window dragging is handled by the window server so that an  
unresponsive app can't affect it.




Upon further investigation I see that the beach ball does finally  
appear.
I guess the question is, what is the definition of unresponsive? An  
app will always have short unresponsive periods when it is doing  
something.


Another question -- when should a progress indicator be put up? The  
length of time in my processing loop can very greatly. I could be  
processing 3 files or 300 files. It seems a waste to flash a progress  
indicator for very short processing cases. On the other hand I can't  
just set a threshold for putting up a progress indicator, since the  
processing period can very from one machine to another. Also the  
processing period varies for different file types and even varies on  
the same machine from run to run.  No obvious answers to some of these  
questions.

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[Nathan Sims]

On Jun 20, 2011, at 1:14 AM, Kyle Sluder wrote:

> I look forward to the day when OS X automatically kills beachballing programs 
> after a certain time, a la iOS. Because then maybe iTunes will finally get 
> rewritten.

Ditto for Safari.

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Weird behavior of -URLByAppendingPathComponent:

[Nathan Sims]

FWIW, the standard (can't remember which RFC I saw this in) is for treating a 
double slash // (or any number of slashes) as a single slash / in URLs (after 
the initial http://).


On Jun 19, 2011, at 9:14 PM, Jens Alfke wrote:

> Something seems wrong with -[NSURL URLByAppendingPathComponent:] --
> 
> (gdb) po baseURL
> http://127.0.0.1:5984/
> (gdb) po [baseURL URLByAppendingPathComponent: @"foo"]
> http://127.0.0.1:5984/foo
> (gdb) po [baseURL URLByAppendingPathComponent: @"foo/"]
> http://127.0.0.1:5984/foo//
> 
> Why the doubled slash at the end, in the third result? There should only be 
> one. I’m not sure if doubled slashes are actually illegal in URL paths, but 
> they’re certainly weird, and I’m pretty sure they’d confuse a lot of 
> websites. I’m guessing this is a CF bug.
> 
> [This is on OS X 10.6.7.]
> 
> And yes, I know about +URLWithString:relativeToURL: … but that method doesn’t 
> do the same thing. It only appends the string if the original URL ends with a 
> “/“, otherwise it replaces the last path component. (Which is correct 
> behavior for interpreting relative paths, just not what I want.)
> 
> —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:
> http://lists.apple.com/mailman/options/cocoa-dev/newslists%40autonomy.caltech.edu
> 
> This email sent to newsli...@autonomy.caltech.edu

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: If No Memory Leaks, Is It Good Enough for Memory Management?

[Scott Ellsworth]

On Mon, Jun 20, 2011 at 12:26 AM, Bing Li  wrote:
> Dear all,
>
> I am still a new programmer of Cocoa. In my program, at least right now,
> there are no memory leaks according to Instruments. Is it good enough for
> memory management?

No.  This is not good enough.

If you are doing your memory management at the objc level, you should
read the memory management guide very carefully.  Especially look into
autorelease, as the "memory goes up a bunch, then drops when the next
event loop spins" sounds much like the standard autorelease behavior.

If you are doing it at the C (malloc/free) or CF (some fn call that
says CF...Alloc or CF...Retain and corresponeding CF...Free/Release)
levels, read the APIs that go along with those, and figure out when
your memory is being allocated and when it is being freed or released
back to the system.


>
> What I designed is a TCP server which receives TCP messages. When I tested
> it, 200,000 XML were sent to it with a loop without any delays. Each XML had
> 800 bytes. In this case, no any memory leaks when testing it with
> Instruments. However, according to Activity Monitor, the consumed memory was
> increased from 17.9M to more than 400M. Immediately after the sending, the
> consumed memory started to be lowered until it was stopped to 100M. Was it
> normal? Why wasn't it 17.9M eventually?

Sounds like your program still owns some memory, and is holding on to
too much memory during execution.  Neither ActivityMonitor nor
Instruments is a true memory profiler, but they are good ways to
figure out some areas where you might have a problem.

The true lesson - learn ObjC or C memory management, and do it right
every time, or leak RAM and have angry users.  You are doing the right
thing by asking here for pointers.

Scott

>
> Thanks so much for your help!
>
> Best,
> greatfree
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/scott_ellsworth%40alumni.hmc.edu
>
> This email sent to scott_ellswo...@alumni.hmc.edu
>
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: So... we can't use UIWebView (with a delegate) on a page that's pushed onto a UINavigationController stack?

[David Duncan]

On Jun 20, 2011, at 8:21 AM, Jeff Kelley wrote:

> If you’re creating the web view in -viewDidLoad, you should probably release
> it and nil the pointer to it in -viewDidUnload, not -dealloc.


You need to do both. You aren't guaranteed that your -viewDidUnload method will 
ever be called, so if you don't do it in -dealloc also, you can still have a 
case where you get a delegate callback, but have an incomplete UI (depending on 
what you are doing it may not crash, but you would then not see the results 
either).
--
David Duncan

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: CATransactions having no effect in CALayer draw delegate

[David Duncan]

On Jun 19, 2011, at 2:14 PM, Ken Tozier wrote:

> On Jun 19, 2011, at 3:57 PM, Kyle Sluder wrote:
> 
>> You're setting the contents property of the layer. So returning nil
>> from -actionForKey: should do the trick. I just found this post by
>> Matt Neuburg that might explain why you're having trouble:
>> http://www.cocoabuilder.com/archive/cocoa/293161-calayer-instant-content-update.html
>> 
>> Basically, the sentinel value that tells Core Animation to stop
>> looking for an action to apply to a property change is NOT nil, as
>> implied by the documentation and David Duncan's post. Rather, it is
>> NSNull. "nil" means "I don't have an answer for you; consult someone
>> else," which can be the layer _or_ the default set of implicit
>> actions! Rather, try returning [NSNull null] from your -actionForKey:
>> override.
> 
> I read the link and tried both of the following:
> 
> - (id) actionForKey:(NSString *) inKey
> {
>   if ([inKey isEqualToString: @"contents"])
>   return [NSNull null];
>   
>   return [super actionForKey: inKey];
> }
> 
> Produced the error: 
> -[NSNull runActionForKey:object:arguments:]: unrecognized selector sent to 
> instance 0x7fff701d5fa0

Which value is the sentinel depends on context, hence my recommendation to read 
the documentation. Specifically when using the actions dictionary, style 
dictionary or -actionForLayer:forKey: the sentinel is [NSNull null] and 
nil/non-existant means "keep searching". In other contexts nil means "no 
action".

> Thanks again for the reply it cleared some things up. At this point though, 
> it's probably a good time to put CALayers aside, at least for now. The 
> inability to simply set the shape of the layer and turn off the blasted 
> animations, when needed, is a deal breaker for me. Not sure why Apple made it 
> so squirrely, but really, the entire point of my subclass was to make it 
> possible to do something like  the following.


You probably aren't overriding enough properties default animations. As stated, 
@"contents" is literally only the bitmap backing the layer. It does not affect 
any other animation the layer may perform. From the sounds of it, you also have 
a border and the cornerRadius set to a non-zero value. If you want to disable 
those animations too, you need to disable them for those associated keys too.

Or you can use the CATransaction as you originally tried, but you need to do it 
around the values that you are actually changing. @"contents" is a bit special 
because it is typically set outside of your control, but other properties tend 
no to be.
--
David Duncan

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: So... we can't use UIWebView (with a delegate) on a page that's pushed onto a UINavigationController stack?

[Jeff Kelley]

If you’re creating the web view in -viewDidLoad, you should probably release
it and nil the pointer to it in -viewDidUnload, not -dealloc.

Jeff Kelley


On Sat, Jun 18, 2011 at 12:19 PM, Matt Neuburg  wrote:

> >"Important: Before releasing an instance of UIWebView for which you
> >have set a delegate, you must first set the UIWebView delegate
> >property to nil before disposing of the UIWebView instance. This can
> >be done, for example, in the dealloc method where you dispose of the
> >UIWebView."
> >
> >The delegate for the UIWebView is set up in the XIB file; it's pretty
> >hokey to have to intervene in code to then disassociate the view from
> >its delegate.  Also, there is no "dealloc method where you dispose of
> >the UIWebView", because that's done automatically when the view is
> >popped off the navigation stack.
>
> What I do is start with a UIViewController subclass that creates the
> UIWebView in viewDidLoad and disposes of it in dealloc, setting the delegate
> to nil first, just as suggested in the docs. It's not clear to me why
> creating the UIWebView in the nib would make any difference. m.
>
> --
> matt neuburg, phd = m...@tidbits.com, 
> A fool + a tool + an autorelease pool = cool!
> Programming iOS 4!
>
> http://www.apeth.net/matt/default.html#iosbook___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/slaunchaman%40gmail.com
>
> This email sent to slauncha...@gmail.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Bug in NSBezierPath?

[Graham Cox]

I've found what I think is a bug in NSBezierPath. I'm just wondering if others 
have found this, if there's a workaround, or whether I've just stuffed up 
somewhere.

Given a path formed from two closed subpaths such as:

[first subpath]

MoveTo()
LineTo()
LineTo()
...
LineTo()
ClosePath()

[second subpath]

MoveTo()
LineTo()
...
LineTo()
ClosePath()

If, while forming the path using this series of commands, I change the location 
of the second (or later) subpath's initial MoveTo using setAssociatedPoints, 
the ClosePath for that subpath goes to the previous position of the point, not 
the one I just moved it to. i.e.

[second subpath]

MoveTo() < make a note of this element's index
LineTo()
LineTo()
...
SetAssociatedPoints( using saved index of MoveTo above )
ClosePath() <--- this close path adds a line segment that goes to the wrong 
place, being the previously set value of MoveTo.

This doesn't occur with the first subpath, only the second (or later) subpaths.


I'm supposing that the reason for this is that when you do a MoveTo(), the 
point you pass is internally saved as the point to which a ClosePath() must 
connect, but if setAssociatedPoints is used, and the index is not 0, this 
internal value is not updated as it should be.

The reason I need this to work is because I'm computing a path based on an 
existing path (actually an offset) by iterating over its elements, but the 
exact placement of the initial MoveTo can't be determined until (and unless) a 
ClosePath() is actually encountered, at which point the point of the initial 
MoveTo() needs to be adjusted slightly. If the path isn't closed, this 
adjustment isn't needed. If I leave off the final ClosePath(), the path is 
correct except that there is a small gap left at the very corner where the path 
should be closed when the path is stroked. So I need a ClosePath() to eliminate 
this gap, but the unwanted line segment is even less welcome.

One solution could be to look ahead sufficiently at MoveTo() time to see if the 
path is closed, and if so try to extract all the parameters needed to compute 
the modified moveTo location at that time, but this is really awkward given 
that apart from this problem I can simply process one element at a time in a 
loop with only a single element look-ahead. This requires making a special case 
of the start/end of the path that is anything but straightforward.

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

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

Running at Logout (like Technical Note TN2228, but for logout)

[Markus Hanauska]

I would like to write a little tool that syncs my preference files of various 
apps between different Macs. I have a couple of applications that have plenty 
of complicated settings and I would like to keep these settings always in sync 
between several different Macs. The problem is that I cannot use network 
synchronization, since one of those Macs is not always connected to a network 
and I would like this sync to work even without an active network connection. 
The solution: I will use an USB stick for it. The idea is pretty simple:

Prior to logging in, I plug in the USB stick, then I log into the Mac using my 
user account. The pref files are copied from the USB stick to my home folder 
(~/Library/Preferences). When I log out, the pref files are copied from my home 
folder back to the USB stick. The USB stick thus always contains the latest 
versions of these files. There is no need to merge settings, since I will 
always only be logged in to one of those Macs at all times and the settings of 
this Mac are always the new desired default settings. Ideally the tool will 
also support situations, where the USB stick is currently not plugged in during 
login or logout and prompt me for plugging it in before continuing the 
login/logout process.

There is just one big problem with that idea: The applications that read/write 
those pref files are login items, that means they will start immediately after 
logging in and keep running until I log out again. To make sure the apps start 
with the right prefs, I must replace the prefs prior to starting these apps 
(after login, but prior to login items) and since the sync can take a couple of 
seconds, I'd need a way to temporarily suspend the login until my tool is done. 
The same problem applies to logout: Since pref files are written asynchronously 
and thus the app might modify the pref file again right before quitting, my 
tool has to wait till the app has really quit before syncing the pref files, 
otherwise it may not sync the most up-to-date version. Thus my tool must run 
after all apps were quit, but prior to the real logout and of course it has to 
suspend the logout until it is done with copying files.

My first idea was to write a launchd agent, but I'm afraid such an agent is 
started way too late on login and terminated way too early on logout, so I 
dropped this idea pretty soon. The next idea was to write a launchd daemon that 
runs as root (thus having access to all user home directories), but this 
approach will not work, because in case of a file vault or a remote home, the 
daemon won't have access to the user home when the user is not currently logged 
in. So for the login problem the real solution seems to be an **authorization 
plug-in**. I can place it after the user home has been mounted, so it will have 
access to the user home files, but it can also "delay" the login process for as 
long as necessary (waiting for USB stick to be plugged-in, waiting for sync to 
finish or waiting for user to cancel sync), thus the sync will have finished 
for sure once the login items are being started. From what I've read so far 
regarding these plugins, this approach really seems to be the way to go.

The remaining problem is how to sync back on logout? There seems to be no way 
to write a authorization plug-in that runs on logout. Basically I need code 
that runs after all user processes have been terminated, but before the user 
home is unmounted, and that also can delay the logout process until all 
operations have been finished. Any way to do this?

A rather "crude" approach would be to start a launchd agent right after the 
login has succeeded that has an ExitTimeOut of 0, so launchd will send it a 
SIGTERM on logout, but it will never send it a SIGKILL. The agent could now 
catch the SIGTERM, wait for all other user processes to terminate (except for 
launchd and itself of course) and then start the sync process. The main problem 
with that approach: If my tool has a bug and somehow never terminates (nor 
crashes), the whole logout blocks forever. Also I'm not sure if the agent would 
be allowed to still start other processes (e.g. maybe a helper tool to display 
UI, since I'm not sure if I would like this agent to be Cocoa app) and if the 
agent is not "canceling" the whole logout by waiting too long. Maybe this is 
not a good idea after all, but the only one I could come up with :-(

Apple seems to have a better way to run lougout tasks, e.g. remote home 
synchronization, file vault compaction, etc. 
Any ideas are pretty much welcome. Thanks.

Regards,
Markus___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archiv

Re: [iOS] What's the point of UISegementedControl.tintColor?

[Michael Crawford]

Rick, if that is how you believe it should work, file a bug on it.  Apple might 
agree, once you bring it to their attention.

-Michael

On Jun 15, 2011, at 3:21 PM, Rick Mann wrote:

> 
> On Jun 15, 2011, at 12:19 , Luke Hiesterman wrote:
> 
>> If you set it to a color that isn't black, you will be able to see a 
>> difference. Black behaves this way because selection is shown by making the 
>> button appear depressed, and therefore darker. You can't get darker than 
>> black, thus what you see.
> 
> Ah, that makes sense, even if it's a shortcoming of the control (I would 
> argue dark, or very dark, color should get lighter to show they're 
> depressed). Thanks.
> 
> -- 
> Rick
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/michaelacrawford%40me.com
> 
> This email sent to michaelacrawf...@me.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: finder get info window

[jonat...@mugginsoft.com]

On 20 Jun 2011, at 12:16, Rick C. wrote:

> Sorry I just meant a way to launch that window similar to the way this will 
> reveal an item in Finder:
> 
> [[NSWorkspace sharedWorkspace] selectFile:filePath 
> inFileViewerRootedAtPath:nil];
> 
> If Applescript is the only way then I guess I'll have to give it a try.  
> Thanks to you both!
> 
Insight is easily available. Fire up AppleScript editor hit record then select 
Finder and display get info window:
You should get something like the following:

tell application "Finder"
activate
open information window of document file "cspsol-data-big.txt" of 
folder "Jonathan" of folder "Users" of startup disk
set position of Finder window 1 to {850, 191}
end tell

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.com

> 
> On Jun 20, 2011, at 6:50 PM, Graham Cox wrote:
> 
>> 
>> On 20/06/2011, at 6:48 PM, Rick C. wrote:
>> 
>>> 'm assuming there must be a way to call the standard Finder get info window 
>>> in cocoa
>> 
>> 
>> Seems a strange assumption. How do you "call" a window anyway?
>> 
>> --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:
> http://lists.apple.com/mailman/options/cocoa-dev/jonathan%40mugginsoft.com
> 
> This email sent to jonat...@mugginsoft.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: finder get info window

[Rick C.]

Sorry I just meant a way to launch that window similar to the way this will 
reveal an item in Finder:

[[NSWorkspace sharedWorkspace] selectFile:filePath 
inFileViewerRootedAtPath:nil];

If Applescript is the only way then I guess I'll have to give it a try.  Thanks 
to you both!


On Jun 20, 2011, at 6:50 PM, Graham Cox wrote:

> 
> On 20/06/2011, at 6:48 PM, Rick C. wrote:
> 
>> 'm assuming there must be a way to call the standard Finder get info window 
>> in cocoa
> 
> 
> Seems a strange assumption. How do you "call" a window anyway?
> 
> --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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: finder get info window

[Graham Cox]

On 20/06/2011, at 6:48 PM, Rick C. wrote:

> 'm assuming there must be a way to call the standard Finder get info window 
> in cocoa


Seems a strange assumption. How do you "call" a window anyway?

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

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

Re: finder get info window

[jonat...@mugginsoft.com]

On 20 Jun 2011, at 09:48, Rick C. wrote:

> Hi again,
> 
> I'm assuming there must be a way to call the standard Finder get info window 
> in cocoa but I can't figure it out?  I know this is possible in applescript 
> but hoping I don't have to go there...

I think that you will have to access the info window resource using scripting.
Depending on the complexity of what you require AppleScript might be the 
easiest approach.

If AppleScript is not on the cards try the scripting bridge. This can achieve 
the same result as the AS approach but generates the necessary events from ObjC 
land instead.
You can get the SB definition file for the Finder as follows:

sdef "/System/Library/CoreServices/Finder.app" | sdp -fh -o -


Regards

Jonathan Mitchell

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

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

Re: Progress Indicators Spin vs Bar

[Mike Abdullah]

On 20 Jun 2011, at 09:31, James Merkel wrote:

> Yeah, I just kind of avoided the basic problem.  The app isn't receiving at 
> least some events -- for example the menus can't be pulled down. On the other 
> hand,  the spinning beach ball doesn't appear, and I can drag the progress 
> window around.

Window dragging is handled by the window server so that an unresponsive app 
can't affect it.

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

finder get info window

[Rick C.]

Hi again,

I'm assuming there must be a way to call the standard Finder get info window in 
cocoa but I can't figure it out?  I know this is possible in applescript but 
hoping I don't have to go there...

Thanks!___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Automatically mirroring folders

[Tony Romano]

You coded your application to tell you when the directory has changed and
it's doing exactly that.  I'm not sure what changes you are interested in
knowing or ignoring(I.e. File added, file modified, file deleted).  In all
cases, you will need to track something so you have a reference, get a
notification that something has changed, decide what action you need to
take and then act on it.

Depending on what changes you are interested in, you may only need to
track the last time something changed, when you get a notification,
anything past this time needs an update. Or maybe you need to track all
the files in the directory, get a notification, and decide the difference
and act accordingly.  You can scale up or down as needed.

For example, the project I'm working on, I have a difference engine to
determine files added, deleted, or modified based on a reference I am
looking at in memory.  I am able to surgically modify my internal
structure and UI to match the changes happening on some external storage.
I think if you start playing around with turning notifications on or off,
or ignoring them at certain times, it may lead to errors.  This is just a
hunch on my part and it could totally work just fine.  I'd prefer to
process the notification and decide what to do.  From a performance
perspective, since you are using FSEvents, you have to do a read on the
directory no matter what and that is probably the biggest cost, setting up
a diff engine on a 10, 100, 1000, 1 files is fast.  Also remember that
FSEvent will coalesce multiple event on a directory, so block changes will
come across as one event and the diff engine will find all the changes on
one pass through the engine.

This is one aspect on OS X I find to be weak, notifications on files.
Sure, the are Kqueues, but they have limits.  Not as robust as I've seen
elsewhere.

HTH,
Tony Romano

On 6/20/11 12:53 AM, "Matt Gough"  wrote:


>Can you not make use of:
>
>kFSEventStreamCreateFlagIgnoreSelf
>"Ignore events generated by this client. For example, an application
>might want to watch for changes to a file so that it can reread it, but
>should not needlessly reread it if the change to the file was caused by
>the application itself writing out changes."
>
>Matt
>
>On 19 Jun 2011, at 17:48:32, Leonardo wrote:
>
>> Problem: I have to automatically mirror 2 folders, /A and /B, such a way
>> they contains the same files and folders.
>> 
>> - So I FSEventStreamCreate with kFSEventStreamEventIdSinceNow,
>> kFSEventStreamCreateFlagWatchRoot and a 2 seconds latency time.
>> 
>> - I get a notification: there is a new file to copy from /A to /B. I
>>copy
>> the file, but I quickly get a new notification that there is a new file
>>in
>> B. Well, this notification is useless to me. I copied that file.
>>Therefore I
>> don't need to copy it again.
>> 
>> - So, before I copy the file, I thought, I stop and invalidate the
>>stream,
>> then I copy the file, then I turn the stream on again. But here I get 2
>> problems:
>> 
>> 1) At the end of the copyFile, I turn the stream on again, and the
>>Finder, a
>> couple of seconds later (but it could even be shorter or longer)
>>updates the
>> /B/.DS_Store file so I get a new notification. How to force the Finder
>>to
>> update the .DS_Store file immediately after the copy? Or should I use a
>> longer latency time? How long?
>> 
>> 2) During the period of time the stream is off, if some new files arrive
>> within the folder /A, I lose the notification to copy it.
>> 
>> How to workaround that?
>> 
>> 
>> Regards
>> -- Leonardo
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> 
>>http://lists.apple.com/mailman/options/cocoa-dev/devlists.mg%40googlemail
>>.com
>> 
>> This email sent to devlists...@googlemail.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:
>http://lists.apple.com/mailman/options/cocoa-dev/tonyrom%40hotmail.com
>
>This email sent to tony...@hotmail.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[James Merkel]

It turns out if I use setUsesThreadedAnimation:YES on the progress  
indicator, the bar indicator animates.


The docs say this method sets a hint as to whether the receiver should  
implement animation of the progress indicator in a separate thread.  I  
guess the hint is taken and the animation is performed in a separate  
thread.


Jim Merkel


On Jun 19, 2011, at 1:38 PM, James Merkel wrote:



On Jun 19, 2011, at 1:27 PM, Quincey Morris wrote:


On Jun 19, 2011, at 13:14, James Merkel wrote:


ProgressController * progressController = nil;  
progressController =[[ProgressController alloc] init];
NSLog(@"Progress window: %@\n", [progressController window]);
[progressController startProgressAnimation];
[progressController showWindow:self];

(Long processing)

[progressController close];
[progressController release];

So this works with the spinner but not the bar. Seems strange  
because I thought the two progress indicators would work the same.


They don't. The spinning indicator animates itself, but the bar  
animation depends on run loop iterations to drive the animation. If  
"Long processing" means a loop, you're not going back to the run  
loop. In those circumstances you must arrange for events to be  
processed (run the run loop or dequeue events in a modal event loop).


Note that you probably want to do that anyway, because you probably  
want to have a Cancel button on a long-running operation.




Ok thanks -- I didn't realize there was a difference in the way the  
two progress indicators worked.


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[James Merkel]

Yeah, I just kind of avoided the basic problem.  The app isn't  
receiving at least some events -- for example the menus can't be  
pulled down. On the other hand,  the spinning beach ball doesn't  
appear, and I can drag the progress window around.

I'll have to see if a cancel button will work.

Of course putting the code in another thread would be a big change.

Jim Merkel


On Jun 20, 2011, at 1:14 AM, Kyle Sluder wrote:


On Jun 20, 2011, at 12:36 AM, James Merkel  wrote:

It turns out if I use setUsesThreadedAnimation:YES on the progress  
indicator, the bar indicator animates.


The docs say this method sets a hint as to whether the receiver  
should implement animation of the progress indicator in a separate  
thread.  I guess the hint is taken and the animation is performed  
in a separate thread.


You still haven't addressed the question of whether you're blocking  
the main thread.


According to your pseudocode, you are. This is very bad. The  
spinning beach ball cursor will appear while your app is performing  
its "long processing," and there will be no way for your app to  
receive any events from the user asking it to cancel.


I look forward to the day when OS X automatically kills beachballing  
programs after a certain time, a la iOS. Because then maybe iTunes  
will finally get rewritten.


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

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

Re: If No Memory Leaks, Is It Good Enough for Memory Management?

[Tony Romano]

Well, a loose definition for a leak is memory not being referenced anymore
and not returned to the heap manager.  However, you can still have large
consumptions of memory while being referenced and it's not considered a
leak by the Leaks tool.  BUT, you still have a problem due to your memory
consumption to increase until you run out of virtual space.  You need to
use Allocations and use the heap shot Analysis to determine what actions
in your application are causing the heap to grow and track down where the
memory is not being returned to the heap manager.

I'd do a search in Google for Heapshot analysis.
Tony Romano











On 6/20/11 12:28 AM, "Bing Li"  wrote:

>Dear all,
>
>I am still a new programmer of Cocoa. In my program, at least right now,
>there are no memory leaks according to Instruments. Is it good enough for
>memory management?
>
>What I designed is a TCP server which receives TCP messages. When I tested
>it, 200,000 XML were sent to it with a loop without any delays. Each XML
>had
>800 bytes. In this case, no any memory leaks when testing it with
>Instruments. However, according to Activity Monitor, the consumed memory
>was
>increased from 17.9M to more than 400M. Immediately after the sending, the
>consumed memory started to be lowered until it was stopped to 100M. Was it
>normal? Why wasn't it 17.9M eventually?
>
>Thanks so much for your help!
>
>Best,
>greatfree
>___
>
>Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
>Please do not post admin requests or moderator comments to the list.
>Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
>Help/Unsubscribe/Update your Subscription:
>http://lists.apple.com/mailman/options/cocoa-dev/tonyrom%40hotmail.com
>
>This email sent to tony...@hotmail.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Progress Indicators Spin vs Bar

[Kyle Sluder]

On Jun 20, 2011, at 12:36 AM, James Merkel  wrote:

> It turns out if I use setUsesThreadedAnimation:YES on the progress indicator, 
> the bar indicator animates.
> 
> The docs say this method sets a hint as to whether the receiver should 
> implement animation of the progress indicator in a separate thread.  I guess 
> the hint is taken and the animation is performed in a separate thread.

You still haven't addressed the question of whether you're blocking the main 
thread.

According to your pseudocode, you are. This is very bad. The spinning beach 
ball cursor will appear while your app is performing its "long processing," and 
there will be no way for your app to receive any events from the user asking it 
to cancel.

I look forward to the day when OS X automatically kills beachballing programs 
after a certain time, a la iOS. Because then maybe iTunes will finally get 
rewritten.

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

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

Re: If No Memory Leaks, Is It Good Enough for Memory Management?

[Conrad Shultz]

First, please tell me you have read up on memory management after every person 
on this list told you to do so. And bought a C book.

That said, no, Instruments not showing any leaks is not itself sufficient to 
prove you are managing memory properly.

For one, Instruments will generally only show a leak when an allocated object 
no longer has anything referencing it.  You can easily circumvent this with a 
retain cycle, for example.

Second, I'm not sure what its current level of support for Foundation objects 
(and C in general) is. I vaguely recall having to manually hunt down a missing 
CGGradientRelease() when Leaks proved less than helpful. If this is still an 
issue, it will not help you with your C memory management.

As for your situation, repeat after me: "Activity Monitor is not a profiling 
tool." This should be recited about as often as "I shall not examine 
retainCount for any reason whatsoever."

There are all sorts of things that can go on behind the scenes to cause memory 
usage to grow. For example, some classes may implement a concealed cache that 
will be purged as needed with no intervention needed on your part.

If you want to get a better grasp on what might be happening, use heapshot 
analysis to start. (This is far from the first time I have mentioned this to 
you.) Bill Bumgarner has a nice post on its use 
(http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/).
 There is also coverage in the 2010 WWDC videos.

Given your recent posts, if I had to hazard a guess I would predict that in 
your C code you have a malloc() not paired with a free() or something to that 
effect. 

(Sent from my iPad.)

--
Conrad Shultz

On Jun 20, 2011, at 0:26, Bing Li  wrote:

> Dear all,
> 
> I am still a new programmer of Cocoa. In my program, at least right now,
> there are no memory leaks according to Instruments. Is it good enough for
> memory management?
> 
> What I designed is a TCP server which receives TCP messages. When I tested
> it, 200,000 XML were sent to it with a loop without any delays. Each XML had
> 800 bytes. In this case, no any memory leaks when testing it with
> Instruments. However, according to Activity Monitor, the consumed memory was
> increased from 17.9M to more than 400M. Immediately after the sending, the
> consumed memory started to be lowered until it was stopped to 100M. Was it
> normal? Why wasn't it 17.9M eventually?
> 
> Thanks so much for your help!
> 
> Best,
> greatfree
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Automatically mirroring folders

[Matt Gough]

Can you not make use of:

kFSEventStreamCreateFlagIgnoreSelf
"Ignore events generated by this client. For example, an application might want 
to watch for changes to a file so that it can reread it, but should not 
needlessly reread it if the change to the file was caused by the application 
itself writing out changes."

Matt

On 19 Jun 2011, at 17:48:32, Leonardo wrote:

> Problem: I have to automatically mirror 2 folders, /A and /B, such a way
> they contains the same files and folders.
> 
> - So I FSEventStreamCreate with kFSEventStreamEventIdSinceNow,
> kFSEventStreamCreateFlagWatchRoot and a 2 seconds latency time.
> 
> - I get a notification: there is a new file to copy from /A to /B. I copy
> the file, but I quickly get a new notification that there is a new file in
> B. Well, this notification is useless to me. I copied that file. Therefore I
> don't need to copy it again.
> 
> - So, before I copy the file, I thought, I stop and invalidate the stream,
> then I copy the file, then I turn the stream on again. But here I get 2
> problems:
> 
> 1) At the end of the copyFile, I turn the stream on again, and the Finder, a
> couple of seconds later (but it could even be shorter or longer) updates the
> /B/.DS_Store file so I get a new notification. How to force the Finder to
> update the .DS_Store file immediately after the copy? Or should I use a
> longer latency time? How long?
> 
> 2) During the period of time the stream is off, if some new files arrive
> within the folder /A, I lose the notification to copy it.
> 
> How to workaround that?
> 
> 
> Regards
> -- Leonardo
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/devlists.mg%40googlemail.com
> 
> This email sent to devlists...@googlemail.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How to redraw a view in slow-motion

[Matthias Arndt]

Hi Graham, hi Uli,

guys, you're gems! Thanks for all the input. Currently it's too early to dive 
into some high sophisticated optimization, and with Graham's info I'm confident 
the view's back buffer will work for me.

Am 20. Jun 2011 um 08:59 schrieb Graham Cox :

> The view is already doing this for you. Everything drawn in a view actually 
> ends up in a bitmap - the window's back buffer. If you draw a subrange of 
> your objects, the ones you've earlier drawn into the back buffer are still 
> there. The only time you have to start over is when the view resizes, which 
> is what the 'needsErase' flag is for in my example - the back buffer gets 
> cleared effectively clearing your "cache". There's no reason to reinvent the 
> drawing mechanism from scratch, it's just a duplication of effort.
 
Hopefully I find some time these days to implement more details of the 
animation based on NSTimer-triggered redraws: Currently it's only quick & 
dirty, but seems to do the trick. I'll keep you posted.

Thanks again, Mattes
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSArrayController loses selection upon CoreData refreshObject.

[Quincey Morris]

On Jun 19, 2011, at 23:47, Motti Shneor wrote:

> Background: I use an NSTableView with an NSArrayController to display a list 
> of CoreData entity instances (say instances of  "Note" entity).  I DO NOT 
> configure the array controller for "Entity" mode, because this is a "read 
> only" view. All model changes originate in remote server commands. My client 
> application merely sends requests to the server, and server decides upon 
> model changes.
> 
> NSArrayController is configured for "Class" (NSManagedObject), and its 
> ContentSet is bound to some relation property that leads to all the Notes.

This isn't correct. Entity mode has nothing really to do with whether the model 
is updatable or not, but rather specifies whether the data source has array 
semantics (Class) or set semantics (Entity). In the latter case, it also tells 
the array controller that the data model is a Core Data model.

Now, because NSArrayController is pretty much a black box, it's not at all 
clear whether the kind of mis-configuration you did has any important effect or 
not. Nevertheless, you should fix this. Note that the array controller has a 
separate "editable" checkbox which you should turn off, if you want to make 
sure it doesn't cause any model updates.

> The symptom is:  When user clicks on a table line --- it gets selected. If, 
> however, a server message arrives that causes the client to call 
> 
> [context refreshObject:obj] mergeChanges:YES];
> 
> Selection disappears immediately. I double checked that NONE of the 
> NSManagedObjects  (Note instances) has changed, and no new Note was added, 
> and no Note was removed. The refresh is used to update some Fetched 
> properties (queries).

It's possible that the mergeChanges removes all objects from the relationship 
set, triggering a KVO notification to the array controller which causes it to 
clear the selection (because the set is empty), then adds objects back in. Or, 
it's possible that your array controller mis-configuration has a hand in this.

If you explicitly define a selection indexes property in your data model (which 
means a NSIndexSet* property in a subclass of the appropriate NSManagedObject 
class), you can bind the array controller's selection binding to this 
property***, then save and restore the selection indexes around the 
mergeChanges message. It's not clear from your description whether this *ought* 
to be necessary, but it's something you can try if you can't find a more direct 
solution.



*** What this does, in effect, is to cause the array controller to keep a 
mirror copy of the selection in the data model object. Because it's a binding, 
the selection can be set from either end. Just make sure your property 
implementation is KVO compliant, which is pretty simple in this case.


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

If No Memory Leaks, Is It Good Enough for Memory Management?

[Bing Li]

Dear all,

I am still a new programmer of Cocoa. In my program, at least right now,
there are no memory leaks according to Instruments. Is it good enough for
memory management?

What I designed is a TCP server which receives TCP messages. When I tested
it, 200,000 XML were sent to it with a loop without any delays. Each XML had
800 bytes. In this case, no any memory leaks when testing it with
Instruments. However, according to Activity Monitor, the consumed memory was
increased from 17.9M to more than 400M. Immediately after the sending, the
consumed memory started to be lowered until it was stopped to 100M. Was it
normal? Why wasn't it 17.9M eventually?

Thanks so much for your help!

Best,
greatfree
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

If No Memory Leaks, Is It Good Enough for Memory Management?

[Bing Li]

Dear all,

I am still a new programmer of Cocoa. In my program, at least right now,
there are no memory leaks according to Instruments. Is it good enough for
memory management?

What I designed is a TCP server which receives TCP messages. When I tested
it, 200,000 XML were sent to it with a loop without any delays. Each XML had
800 bytes. In this case, no any memory leaks when testing it with
Instruments. However, according to Activity Monitor, the consumed memory was
increased from 17.9M to more than 400M. Immediately after the sending, the
consumed memory started to be lowered until it was stopped to 100M. Was it
normal? Why wasn't it 17.9M eventually?

Thanks so much for your help!

Best,
greatfree
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How to redraw a view in slow-motion

[Graham Cox]

On 20/06/2011, at 4:47 PM, Matthias Arndt wrote:

> another idea is to cache the last output in a bitmap, redraw it in the next 
> iteration, and update the cache after resizing. But I'll look into this only 
> if a simple redraw won't be sufficient:


The view is already doing this for you. Everything drawn in a view actually 
ends up in a bitmap - the window's back buffer. If you draw a subrange of your 
objects, the ones you've earlier drawn into the back buffer are still there. 
The only time you have to start over is when the view resizes, which is what 
the 'needsErase' flag is for in my example - the back buffer gets cleared 
effectively clearing your "cache". There's no reason to reinvent the drawing 
mechanism from scratch, it's just a duplication of effort.

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

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