Re: Rotate a standard Cocoa control?

2015-05-08 Thread Steve Mills

> On May 9, 2015, at 00:22:12, Jerry Krinock  wrote:
> 
> Graham, from one who has been using your code since MacZoop, I say thank you 
> AGAIN :)
> 
> After using Apple’s NSSlider in circular style, I discovered other issues in 
> addition to the two mentioned in my original post…
> 
> - NSSlider has only one size.
> 
> - NSSlider requires the eyesight and dexterity of a 14-year-old to use it.
> 
> -- In order to turn NSSlider “up” or “down”, the user must make a circular 
> motion on the mouse or trackpad.  Yours works correctly: Drag up or down in a 
> straight line.  This is the way the circular controls in GarageBand work.
> 
> Go Graham!

Ditto, especially to the part about the correct way to mouse a knob. Trying to 
run a mouse around a knob in a circular motion might be intuitive, but it’s one 
of the worst motions you could do with a mouse. You’d be better off training an 
actual mouse to push your mouse in a circular motion. Up and down is far more 
natural and easier to control, but I also think side to side is also intuitive 
and natural as well. I’d offer both if I ever need to do this, just *never* 
circular.

--
Steve Mills
Drummer, Mac geek


___

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

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

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

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

Re: Rotate a standard Cocoa control?

2015-05-08 Thread Jerry Krinock
Graham, from one who has been using your code since MacZoop, I say thank you 
AGAIN :)

After using Apple’s NSSlider in circular style, I discovered other issues in 
addition to the two mentioned in my original post…

- NSSlider has only one size.

- NSSlider requires the eyesight and dexterity of a 14-year-old to use it.

-- In order to turn NSSlider “up” or “down”, the user must make a circular 
motion on the mouse or trackpad.  Yours works correctly: Drag up or down in a 
straight line.  This is the way the circular controls in GarageBand work.

Go Graham!


___

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

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

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

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

Re: Where and how do I know a save completed successfully?

2015-05-08 Thread Quincey Morris
On May 8, 2015, at 17:50 , Charles Jenkins  wrote:
> 
> I tell the text view its delegate is my Document instance as soon as possible 
> in windowControllerDidLoadNib: 

I don’t know the timing offhand, but it’s possible that the text view looks for 
its undo manager earlier. I’d suggest you hook up its delegate outlet in IB, 
which means you’ll need to make the window controller its delegate, not the 
document (unless, that is, you’re using the document subclass as File’s Owner 
for the document window NIB). The window controller should already have its 
“document” property set, but you should verify this and if necessary get hold 
of the document some other way.

The details would be different if you’re using a storyboard, but the window 
controller is still there to be connected as delegate.

If this continues to be problematic, you might want to examine the source code 
for TextEdit, which presumably addresses the undo controller issue in much the 
same way that you want.



___

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

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

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

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

Re: Where and how do I know a save completed successfully?

2015-05-08 Thread Charles Jenkins
On May 8, 2015 at 1:09:01 PM, Quincey Morris 
(quinceymor...@rivergatesoftware.com) wrote:
In this case, the text view should probably use the document undo manager, 
though you may have to do extra work to coordinate its use with your document’s 
needs. To configure it, you should tell the text view what its undo manager is, 
via its ‘undoManagerForTextView:’ delegate method.


My NSTextViewDelegate section begins like this:

extension Document : NSTextViewDelegate {  /// Plug document undo manager into 
the text v

  func undoManagerForTextView( view:NSTextView )
    -> NSUndoManager?
  {
    var um = self.undoManager
    describeUndoManager( um, 
source:"NSTextViewDelegate.undoManagerForTextView:" )
    return self.undoManager
  }

I think the delegate is good, because its other methods get called. But this 
one doesn’t. I tell the text view its delegate is my Document instance as soon 
as possible in windowControllerDidLoadNib: — right after I test and find that 
my Document’s undoManager is NOT nil. So the situation remains that the 
Document has an undoManager, but the text view’s undoManager variable remains 
nil throughout execution. Is there still a step I’m missing?
___

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

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

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

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

Re: Rotate a standard Cocoa control?

2015-05-08 Thread Graham Cox

> On 9 May 2015, at 6:08 am, Robert Martin  wrote:
> 
> Graham,
> 
> Thanks so much for posting this. I’ve always wondered how to go about doing 
> this kind of thing, but never had the actual need in a project to prod me to 
> figure it out. Your app and code are terrific at making things clear.


You’re welcome. There’s a few things I need to tweak to make it into production 
quality code, such as conformance to NSCoding - I’ll post an update later if I 
get the chance.

—Graham



___

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

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

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

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

Re: Limiting GCD concurrent queues

2015-05-08 Thread Graham Cox

> On 9 May 2015, at 6:19 am, Ken Thomases  wrote:
> 
> You should use an NSOperationQueue.  You can set its 
> maxConcurrentOperationCount.  You can add blocks to it using 
> -addOperationWithBlock: or by instantiating NSBlockOperation objects and 
> adding those with -addOperation:.


Though watch out for the new “quality of service” API - the documentation is 
incorrect and the default value for this can cause problems for your main 
thread. Easy workaround - just set the QoS setting deliberately to the 
“background” setting, don’t leave it at the default value. (bug reported).

—Graham



___

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

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

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

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

Re: Limiting GCD concurrent queues

2015-05-08 Thread Carl Hoefs

> On May 8, 2015, at 1:19 PM, Ken Thomases  wrote:
> 
> You should use an NSOperationQueue.  You can set its 
> maxConcurrentOperationCount.  You can add blocks to it using 
> -addOperationWithBlock: or by instantiating NSBlockOperation objects and 
> adding those with -addOperation:.

Awesome, thanks for the pointer to NSOperationQueue. Sounds just like what I 
was searching for. 

-Carl


___

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

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

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

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

Re: Limiting GCD concurrent queues

2015-05-08 Thread Ken Thomases
On May 8, 2015, at 1:51 PM, Carl Hoefs  wrote:

> I need to limit a GCD concurrent queue to a specific number of concurrently 
> executing tasks (less than the number of cores available).

> I was hoping an API like the following might be lurking around somewhere:
> 
>gcdConcQueue = dispatch_queue_create("GCDConcQueue", 
> DISPATCH_QUEUE_CONCURRENT, 16);
> 
> in which the queue manages itself behind the scenes.

> Would this make sense as an API enhancement?

Anything you think would be useful makes sense for an enhancement request.  
Whether Apple finds it worth doing is a different question.

> Am I overlooking something obvious?

You should use an NSOperationQueue.  You can set its 
maxConcurrentOperationCount.  You can add blocks to it using 
-addOperationWithBlock: or by instantiating NSBlockOperation objects and adding 
those with -addOperation:.

Regards,
Ken


___

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

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

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

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

Re: Rotate a standard Cocoa control?

2015-05-08 Thread Robert Martin
Graham,

Thanks so much for posting this. I’ve always wondered how to go about doing 
this kind of thing, but never had the actual need in a project to prod me to 
figure it out. Your app and code are terrific at making things clear.

Thanks,

Rob


> On May 7, 2015, at 11:54 PM, Graham Cox  wrote:
> 
> 
>> On 8 May 2015, at 6:11 am, Jerry Krinock  wrote:
>> 
>> I would like to subclass NSSlider to make it work like the "volume control" 
>> on a mid 19th-century radio receiver. That is, I want the minimum value to 
>> be at 7 o'clock, and the maximum value to be at 5 o'clock. 
> 
> 
> Jerry,
> 
> Since I found the problem interesting and also potentially useful for 
> something of my own down the track, I thought I’d have a quick go at making a 
> control like this.
> 
> It’s here: http://apptree.net/code/GCVolumeControl.zip
> 
> 
> It’s fairly basic, though it does what you want with the positioning and 
> stopping on tick marks, etc. I subclassed NSControl rather than NSSlider but 
> I kept some of the same method names so it’s easy to swap in. The knob itself 
> is just a PDF resource which I created using my own Artboard app (graphic and 
> original file included). Obviously you can change this to anything you like - 
> my quick and dirty image is likely a bit short of your needs.
> 
> Hopefully you find it useful, and at least having the source you can 
> customise it easily compared to standard classes. No licensing issues from me 
> either.
> 
> —Graham
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/robmartin%40frontiernet.net
> 
> This email sent to robmar...@frontiernet.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Limiting GCD concurrent queues

2015-05-08 Thread Carl Hoefs
OS X 10.10.3  Xcode 6.3.1

I need to limit a GCD concurrent queue to a specific number of concurrently 
executing tasks (less than the number of cores available). The only way I can 
get this to work is by adding "external plumbing" in the form of semaphores to 
the dispatch invocation:

  dispatch_queue_t gcdConcQueue = dispatch_queue_create("GCDProcQueue", 
DISPATCH_QUEUE_CONCURRENT);
  dispatch_semaphore_t concLimitSem = dispatch_semaphore_create(16);
. . .
  dispatch_async(gcdConcQueue, ^{
dispatch_semaphore_wait(concLimitSem, DISPATCH_TIME_FOREVER);
// Concurrent DB access, etc . . .
dispatch_semaphore_signal(concLimitSem);
});

I was hoping an API like the following might be lurking around somewhere:

gcdConcQueue = dispatch_queue_create("GCDConcQueue", 
DISPATCH_QUEUE_CONCURRENT, 16);

in which the queue manages itself behind the scenes. Is the semaphore approach 
currently the (only) way to do this? Would this make sense as an API 
enhancement? Am I overlooking something obvious?

-Carl


___

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

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

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

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

Re: Subclassing NSPopUpButton

2015-05-08 Thread Kyle Sluder
On Fri, May 8, 2015, at 12:41 PM, Raglan T. Tiger wrote:
> > On May 8, 2015, at 10:55 AM, Kyle Sluder  wrote:
> > 
> >  In that case, the menu is running the runloop in event-tracking mode and 
> > pulling events for its own purpose.
> 
> 
> I create an NSMenu and populate it with NSMenuItem s and then set this
> menu to the NSPopUpButton.
> 
> Would it make sense to use a subclass of NSMenu for this menu ... i.e.
> would I get keyDown events in this subclass?

No, because NSMenu doesn't work like a normal window/view.

I'd suggest looking around for that Xcode-alike implementation I
mentioned. Maybe someone else on the list recalls what I'm talking
about. It might involve overriding -sendEvent: in an NSApplication
subclass.

--Kyle Sluder
___

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

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

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

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

Re: Subclassing NSPopUpButton

2015-05-08 Thread Raglan T. Tiger
> On May 8, 2015, at 10:55 AM, Kyle Sluder  wrote:
> 
>  In that case, the menu is running the runloop in event-tracking mode and 
> pulling events for its own purpose.


I create an NSMenu and populate it with NSMenuItem s and then set this menu to 
the NSPopUpButton.

Would it make sense to use a subclass of NSMenu for this menu ... i.e. would I 
get keyDown events in this subclass?


-rags
___

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

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

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

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

Re: Where and how do I know a save completed successfully?

2015-05-08 Thread Quincey Morris
On May 8, 2015, at 02:46 , Charles Jenkins  wrote:
> 
> I may have a fundamental misunderstanding of how a document class, a text 
> view, and an undo manager work together.

It depends a bit on what kind of editing your document can have done to it.

> I already tried plugging the document’s undoManager into the text view after 
> the NIB loads, but the text view’s undoManager property isn’t directly 
> settable.

If you wanted a text view to use the document’s undo manager, you *could* 
implement the ‘windowWillReturnUndoManager:’ NSWindowDelegate method to return 
it. That is, you would do this in your window controller, or in your NSDocument 
subclass if you aren’t using a window controller, whichever is hooked up as the 
window delegate.

I’m not sure, though, that this is what’s generally wanted. If you do so, then 
the keystroke undo for every text view and text field will live in your 
document’s undo chain, and that almost certainly isn’t what you want.

Undo for text fields (and text views when the content isn’t directly your 
document content) is usually handled by the window-provided freestanding undo 
manager. In document-based apps, changes to the model are generally handled by 
end-editing notifications, delegate methods or bindings, and uncommitted text 
changes are dealt with via the “informal” NSEditor and NSEditorRegistration 
protocols. (Note that NSViewController and NSDocument implement support for 
these, but NSWindowController doesn’t, which is a big PITA.) In these 
scenarios, a separate window-specific undo manager is all you need.

> As a text editor, shouldn’t my app have just one undo manager for each 
> Document, one that works for the document window and the text view contained 
> within it? If so, how do I configure that?

In this case, the text view should probably use the document undo manager, 
though you may have to do extra work to coordinate its use with your document’s 
needs. To configure it, you should tell the text view what its undo manager is, 
via its ‘undoManagerForTextView:’ delegate method.

I think that if you supply an undo manager this way, the text view won’t ask 
the window for its undo manager, so you avoid the 
‘windowWillReturnUndoManager:’ process and the danger of getting tangled up 
with undo actions for other editing controls in the same window.



___

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

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

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

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

Re: Subclassing NSPopUpButton

2015-05-08 Thread Kyle Sluder
On Fri, May 8, 2015, at 11:42 AM, Raglan T. Tiger wrote:
> I have subclassed NSPopUpButton.  In the subclass  drawRect:dirtyRect is
> called ... I did this just to check that the subclass is properly
> implemented.
> 
> In the subclass keyDown:theEvent is not being called.  How does one
> override this method for an NSPopUPButton subclass?
> 
> The purpose for overriding keyDown:theEvent is to create my own search
> string to find items in the menu.

This sounds like a feature that exists in Xcode, which implies you're
trying to do this while the menu is visible. In that case, the menu is
running the runloop in event-tracking mode and pulling events for its
own purpose. The window containing the popup button is (conceptually, if
not in actuality) no longer key.

I believe someone has implemented a workalike to the Xcode
functionality.

--Kyle Sluder
___

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

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

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

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

Re: orderFront: 10.10 vs 10.9

2015-05-08 Thread Kyle Sluder
On Fri, May 8, 2015, at 09:40 AM, sqwarqDev wrote:
> Can't help with the "why", but try putting
> 
> [button lockFocus];
> 
> in that method. Even when there isn't an explicit unlockFocus call, I've
> had this error message a couple of times and adding an explicit lockFocus
> cured it.


Please don't blindly lock and unlock focus on views. You will have much
better results if you actually sit down and figure out where 
the bug is in your code.

--Kyle Sluder
___

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

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

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

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

Subclassing NSPopUpButton

2015-05-08 Thread Raglan T. Tiger
I have subclassed NSPopUpButton.  In the subclass  drawRect:dirtyRect is called 
... I did this just to check that the subclass is properly implemented.

In the subclass keyDown:theEvent is not being called.  How does one override 
this method for an NSPopUPButton subclass?

The purpose for overriding keyDown:theEvent is to create my own search string 
to find items in the menu.



-rags




___

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

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

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

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

Re: orderFront: 10.10 vs 10.9

2015-05-08 Thread Torsten Curdt
Seems like I found the culprit.

The drawing code was throwing an exception for a font that couldn't be
found.

cheers,
Torsten

On Fri, May 8, 2015 at 4:40 PM, sqwarqDev  wrote:

> >
> > On 10.9 I am seeing
> >
> >  "unlockFocus called too many times.
>
>
>
> Can't help with the "why", but try putting
>
> [button lockFocus];
>
> in that method. Even when there isn't an explicit unlockFocus call, I've
> had this error message a couple of times and adding an explicit lockFocus
> cured it.
>
>
>
>
> Best
>
> Phil
>
> DisplayDroid beta (a lightweight script editor and automation tool) is now
> available for free download. More info on sqwarq.com/displaydroid
> OSXClock - big, beautiful alarm clock and timer for your mac. More info on
> sqwarq.com/osxclock
>
> http://applehelpwriter.com
> http://sqwarq.com - apps for OS X & iOS
>
>
>
>
>
>
>
>
>
>
___

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

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

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

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

Re: orderFront: 10.10 vs 10.9

2015-05-08 Thread sqwarqDev
> 
> On 10.9 I am seeing
> 
>  "unlockFocus called too many times. 



Can't help with the "why", but try putting

[button lockFocus];

in that method. Even when there isn't an explicit unlockFocus call, I've had 
this error message a couple of times and adding an explicit lockFocus cured it.




Best

Phil

DisplayDroid beta (a lightweight script editor and automation tool) is now 
available for free download. More info on sqwarq.com/displaydroid
OSXClock - big, beautiful alarm clock and timer for your mac. More info on 
sqwarq.com/osxclock

http://applehelpwriter.com
http://sqwarq.com - apps for OS X & iOS










___

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

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

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

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

orderFront: 10.10 vs 10.9

2015-05-08 Thread Torsten Curdt
I am staring at this code and don't get why it works fine under 10.10 while
under 10.9 it does not.

NSScreen *screen = self.window.screen;
NSWindow *overlay = [[NSWindow alloc]
initWithContentRect:screen.frame

styleMask:NSBorderlessWindowMask

backing:NSBackingStoreBuffered
defer:NO];
self.instructionsWindow = overlay; // strong reference
overlay.opaque = NO;
overlay.ignoresMouseEvents = NO;
overlay.level = NSFloatingWindowLevel - 1;
overlay.backgroundColor = [NSColor colorWithCalibratedWhite:0.0
alpha:0.6];

InstructionsView *view = [[InstructionsView alloc]
initWithFrame:overlay.frame];

view.autoresizingMask = NSViewWidthSizable | NSViewHeightSizable;
view.wantsLayer = YES;

overlay.contentView = view;
// [overlay.contentView addSubview:view];

InstructionsButton *button = [[InstructionsButton alloc]
initWithFrame:NSMakeRect(120, 45, 172, 44)];
[button setTitle:@"Done"];
[button setTarget:self];
[button setAction:@selector(actionInstructions:)];
[view addSubview:button];

NSLog(@"to front");
[overlay orderFront:nil];
// [overlay makeKeyAndOrderFront:nil];
NSLog(@"in front");

On 10.9 I am seeing

  "unlockFocus called too many times. Called on 
  Unlocking Focus on wrong view

I am getting no window and not even "in front" in the console.

The focus thing is strange, too. The code is actually generated by
PaintCode (for 10.9+) and there are no problem on 10.10.

Any pointers? I am running out of ideas.

cheers,
Torsten
___

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

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

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

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

Re: Where and how do I know a save completed successfully?

2015-05-08 Thread Charles Jenkins
I may have a fundamental misunderstanding of how a document class, a text view, 
and an undo manager work together.

I made these override functions in my Document class:

  override func updateChangeCount( change:NSDocumentChangeType ) {
    println( "updateChangeCount:" )
    super.updateChangeCount( change )
    if change == .ChangeCleared {
      println( "Change count cleared. Now clearing modification flags" )
      project.resetModificationFlags()
    }
  }

  override func updateChangeCountWithToken(
    changeCountToken:AnyObject,
    forSaveOperation saveOperation:NSSaveOperationType
  ) {
    println( "updateChangeCountWithToken:forSaveOperation:" )
    let before = documentEdited
    super.updateChangeCountWithToken( changeCountToken, 
forSaveOperation:saveOperation )
    let after = documentEdited
    println( "Before=\(before); after=\(after)" )
    project.resetModificationFlags()
  }

I start my app and type some junk in the main window’s text view, where Undo 
works, then save.

updateChangeCount: is never called, ever. I expected it to be called upon 
changing text in the text view and again upon saving.

updateChangeCountWithToken:forSaveOperation: is called after saving, but the 
“before" and “after" flags are both FALSE, meaning that my typing in the text 
view didn’t cause the document to be marked as edited. 

Here’s the way I thought things worked: the first time you type into a text 
view, it needs to get an undo manager in order to put the change on its undo 
stack. Unless you do something special, it will get the window’s undo manager, 
which will also (for a document window) be the document’s undo manager. So I 
thought I’d be dealing with exactly one undo manager. When the undo stack 
contains operations, the change count is non-zero, and the document knows it 
has been edited.

Somehow, that’s not all true for me. At the time 
updateChangeCount:forSaveToken: is called, the document’s undoManager property 
returns a value: an undoManager with zero levelsOfUndo, which may mean it’s 
going unused. The text view’s undoManager property returns nil.

I already tried plugging the document’s undoManager into the text view after 
the NIB loads, but the text view’s undoManager property isn’t directly settable.

As a text editor, shouldn’t my app have just one undo manager for each 
Document, one that works for the document window and the text view contained 
within it? If so, how do I configure that?

— 

Charles

On April 29, 2015 at 10:19:22 AM, Uli Kusterer (witness.of.teacht...@gmx.net) 
wrote:

On ٢٩‏/٠٤‏/٢٠١٥, at ١١:٠٨, Charles Jenkins  wrote:
I think it most likely I’m doing this in the wrong place. But what’s the right 
place? Overriding NSDocument’s setFileModificationDate() would seem like the 
best way, but the NSDocument Programming guide says messages are sent to 
setFileURL:, setFileType: and setFileModificationDate: “if appropriate,” so I’m 
not sure I can count on getting that message.

 I don't think that's a good spot, as it isn't explicitly connected to file 
saving. I'd try updateChangeCount: instead, and check for NSChangeCleared.

 Also, keep in mind that "Save to..." and the likes also may get used on your 
document, saving to a different file but (IIRC) leaving the original document 
dirty. Maybe I'm misremembering what they do, but all those definitely need 
testing.

-- Uli
http://stacksmith.org
___

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

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

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

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

Re: NSNotification coalescing - which one gets through?

2015-05-08 Thread Jonathan Taylor
Thanks for your replies Seth:

>> I am trying to work out whether there are any rules that define which of 
>> multiple NSNotifications combined using coalescing actually get through to 
>> the receivers, and preferably a way of controlling that behaviour. This 
>> becomes relevant if for example there is different UserInfo associated with 
>> each object. I can’t find any specific statement about what the behaviour is 
>> under these circumstances.
> 
> My interpretation of the API is that user info should either be consistent or 
> not used in coalescing scenarios, though the documentation never discusses 
> this.

Hmm, that's a good point.

>> Actually I think I may have answered my own question: calling 
>> dequeueNotificationsMatching immediately before posting a new notification 
>> seems to do the trick. This seems like a reasonable and logical way of 
>> achieving what I want. Can anyone see any problem with doing that?
> 
> Nope. Seems fine to me.

On further consideration I do wonder, in a case where some notifications were 
treated in this way and other different notifications weren't, whether the ones 
I did treat this way would end up effectively being treated as *even* lower 
priority than the ones that weren't (by constantly being relegated to the back 
of the event queue). Shouldn't be a problem in my case though, as I am going to 
treat all coalesced+postWhenIdle events the same way.

> The other way to accomplish is this is to have the data stored outside of the 
> notification and accessible to the receivers, and just let the notifications 
> coalesce as normal. Instead of looking in userInfo, the receivers would go 
> pull the data from the other source. But whether that's a better fit is 
> questionable based on circumstances.

Yes, in fact that's basically the setup I had previously, and wanted to move 
away from. Rightly or wrongly, I decided I would prefer to avoid having a whole 
load of state and properties whose sole purpose (as it turned out) was to be 
queried in response to notifications. That also felt like a slightly awkward 
compromise between a tightly coupled scenario using KVO and a weakly coupled 
scenario using notifications to classes that don't need to know anything about 
the originating class - I liked the idea of things being as decoupled as 
possible.
___

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

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

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

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

Re: static analyzers says I'm leaking, I _think_ I'm not

2015-05-08 Thread Charles Srstka
> On May 8, 2015, at 2:43 AM, Daniel Höpfl  wrote:
> 
> a)
> @property (assign, nonatomic, readonly) GridCycler *cycler;
> 
> init:
> _cycler = [[GridCycler alloc] initWithGrid: self];
> 
> dealloc:
> [_cycler release];

Why are we presenting an assign property as the first (and presumably, default) 
choice? This is incorrect, in my view, even if it technically works; the 
property is owned by the LifeGrid object, and its declaration should reflect 
that. Plus, if you remove the “readonly” from the declaration (as in the 
original example), and a caller changes the property, it will not only leak 
memory but then crash.

Charles

___

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

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

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

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

Re: static analyzers says I'm leaking, I _think_ I'm not

2015-05-08 Thread Daniel Höpfl
On 07.05.2015 20:16, Charles Srstka wrote:
> On May 7, 2015, at 6:44 AM, Daniel Höpfl  > wrote:
>>
>> I'd change the code as follows:
>>
>> // init
>> self.cycler = [[[GridCycler alloc] initWithGrid: self] autorelease];
>>
>> // alternative init, if you want to bypass the autorelease pool:
>>
>> GridCycler *cycler = [[GridCycler alloc] initWithGrid: self];
>> self.cycler = cycler;
>> [cycler release];
>> // Don't use [self.cycler release], one day you might change the
>> property to copy.
>>
>>
>> // dealloc:
>> // nothing.
> 
> The dealloc is wrong here; that still has to release the property,
> either by setting it to nil or by releasing the ivar (not through a
> property access). With MRC, properties aren’t automatically released on
> dealloc.
> 
> So, in dealloc, either:
> 
> [_cycler release];
> 
> or:
> 
> self.cycler = nil;

You are right: I was wrong.

cycler has to be released in dealloc, but using the setter (self.cycler)
does not help here: The property is marked as "assign".

So, to fix the code:

a)
@property (assign, nonatomic, readonly) GridCycler *cycler;

init:
_cycler = [[GridCycler alloc] initWithGrid: self];

dealloc:
[_cycler release];

b)
@property (strong, nonatomic) GridCycler *cycler;

init:
_cycler = [[GridCycler alloc] initWithGrid: self];

dealloc:
[_cycler release];

or c)
@property (strong, nonatomic) GridCycler *cycler;

init:
GridCycler *cycler = [[GridCycler alloc] initWithGrid: self];
self.cycler = cycler;
[cycler release];

dealloc:
[_cycler release];

(or d: Like a) but use a ivar.)

ARC has its pitfalls but simple things are simpler than in MRC ...

Bye,
   Daniel
___

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

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

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

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