Re: NSWindow styleMask and full screen

[Gideon King]

It turns out that on 10.6+ at least, just setting the button cell to enabled 
does the trick:

NSButton *button = [window standardWindowButton:NSWindowMiniaturizeButton];
NSButtonCell *buttonCell = [button cell];
[buttonCell setEnabled:YES];

Still, it's definitely an Apple bug, and I'll file a bug report.

Regards

Gideon

On 20/07/2012, at 12:16 PM, Lee Ann Rucker  wrote:

> It's an Apple bug - I meant to file it but apparently didn't; I should do 
> that. It's nothing to do with the styleMask; sometimes the window sets the 
> buttonCell's temporarilyDisabled flag and doesn't restore it.
> 
> From a comment in my code:
> * temporarilyDisabled should only be YES when the menubar is hidden, but 
> sometimes
> * the window code gets confused and doesn't reset it for windows that
> * were changing state at the same time as the menu.
> 
> 


___

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: NSWindow styleMask and full screen

[Lee Ann Rucker]

It's an Apple bug - I meant to file it but apparently didn't; I should do that. 
It's nothing to do with the styleMask; sometimes the window sets the 
buttonCell's temporarilyDisabled flag and doesn't restore it.

From a comment in my code:
* temporarilyDisabled should only be YES when the menubar is hidden, but 
sometimes
* the window code gets confused and doesn't reset it for windows that
* were changing state at the same time as the menu.


- Original Message -
From: "Gideon King" 
To: "Cocoa-Dev List" 
Sent: Thursday, July 19, 2012 6:54:22 PM
Subject: NSWindow styleMask and full screen

I have an application where sometimes I need to go full screen. While in full 
screen mode, I need to change the presentation mode so that sometimes the 
menubar and toolbar are autohiding, and sometimes just not shown. Then when I 
exit full screen, I reset the values to what they were before I started.

This works fine, except that when I return from full screen, the minimize 
button is disabled on the window.

So I thought I would record the styleMask of the window before going full 
screen, and then restore it afterwards.

When I ask for the window's styleMask, I get a value of 4111 which according to 
the documentation would be an impossible value. If I just use that value for 
setStyleMask: later in my program, my minimize button is still disabled.

I'm suspecting that Apple must be using the value for other things too, so I 
thought I would use:

oldStyleMask = [window styleMask];

oldStyleMask = oldStyleMask & 
(NSTitledWindowMask|NSClosableWindowMask|NSMiniaturizableWindowMask|NSResizableWindowMask|NSTexturedBackgroundWindowMask);

… do stuff …

[window setStyleMask:oldStyleMask];

Now when I use the & statement, I get a value of 15, which matches how the 
window looks, but setting the style mask back to that value still doesn't 
enable the minimize button.

I looked around and found a suggestion on stack overflow 
http://stackoverflow.com/questions/7888308/nswindow-loses-miniaturize-button-on-lion,
 but the idea there would only be applicable if I was keeping the same 
application presentation options for the whole time I'm in full screen, which 
is not the case.

I have the same problem on 10.6, and the proposed workaround linked off stack 
overflow doesn't work - presumably because I change the application 
presentation options.

I even thought I would try to be smart and override styleMask with the 
following:

- (NSUInteger)styleMask {
return [super styleMask]|NSMiniaturizableWindowMask;
}

But even that wouldn't enable the miniaturize button!

Does anyone know of a workaround for this?



TIA

Gideon






___

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/lrucker%40vmware.com

This email sent to lruc...@vmware.com

___

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

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

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

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

NSWindow styleMask and full screen

[Gideon King]

I have an application where sometimes I need to go full screen. While in full 
screen mode, I need to change the presentation mode so that sometimes the 
menubar and toolbar are autohiding, and sometimes just not shown. Then when I 
exit full screen, I reset the values to what they were before I started.

This works fine, except that when I return from full screen, the minimize 
button is disabled on the window.

So I thought I would record the styleMask of the window before going full 
screen, and then restore it afterwards.

When I ask for the window's styleMask, I get a value of 4111 which according to 
the documentation would be an impossible value. If I just use that value for 
setStyleMask: later in my program, my minimize button is still disabled.

I'm suspecting that Apple must be using the value for other things too, so I 
thought I would use:

oldStyleMask = [window styleMask];

oldStyleMask = oldStyleMask & 
(NSTitledWindowMask|NSClosableWindowMask|NSMiniaturizableWindowMask|NSResizableWindowMask|NSTexturedBackgroundWindowMask);

… do stuff …

[window setStyleMask:oldStyleMask];

Now when I use the & statement, I get a value of 15, which matches how the 
window looks, but setting the style mask back to that value still doesn't 
enable the minimize button.

I looked around and found a suggestion on stack overflow 
http://stackoverflow.com/questions/7888308/nswindow-loses-miniaturize-button-on-lion,
 but the idea there would only be applicable if I was keeping the same 
application presentation options for the whole time I'm in full screen, which 
is not the case.

I have the same problem on 10.6, and the proposed workaround linked off stack 
overflow doesn't work - presumably because I change the application 
presentation options.

I even thought I would try to be smart and override styleMask with the 
following:

- (NSUInteger)styleMask {
return [super styleMask]|NSMiniaturizableWindowMask;
}

But even that wouldn't enable the miniaturize button!

Does anyone know of a workaround for this?



TIA

Gideon






___

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: Sharing a file between Mac and iOS

[Jerry Krinock]

On 2012 Jul 19, at 11:32, Jens Alfke wrote:

> every time you make a change, the entire file will have to be uploaded [by 
> Dropbox] (and downloaded on the other devices) so this doesn't scale well.

I tested this about a year ago and found otherwise.  Drag a large file into 
your Dropbox.  Say that it takes 5 minutes to transfer to your other device.  
Do the bits/second math with your internet connection speed and verify that the 
transmission time is about as expected.  Now change a few bits in the file.  
Voila!  The other device is updated within seconds.  Dropbox apparently 
transmits only changed blocks.  Very nice.

What's even better, is that I found it also works that way with a Core Data 
sqlite store.  Changing one record in a large store does not transmit the whole 
store.

> it won't resolve conflicts in the file. So if one database row gets changed 
> on one device, and another one on another device, Dropbox is just going to go 
> 'duh' and give you two copies of the file, one with each change. 

That is correct.  Dropbox "syncing" works good for "multi-device" situations, 
not "multi-user".  But that is good enough for most consumer applications.


___

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: Sharing a file between Mac and iOS

[Roland King]

You've found both the methods which apple makes available. If you don't want to 
use iCloud, or can't because it ties you to the MAS, then you're left with 
iTunes file sharing. It's not a lovely solution, it's ok for moving a file 
every once in a while or priming some data one-time, but more than that it 
won't really do. It doesn't help that it's so rarely used (in my experience) 
that many users don't even know it's there .. how often do you click on the App 
tab when your device is connected and you have iTunes up and scroll to the 
bottom of the page to see the 'file sharing' stanza? 

That is however the cheapest solution, where cheapest means you can implement 
it with very little effort indeed and it does work.  


On Jul 19, 2012, at 11:22 PM, Dennis wrote:

> I have written a Mac app (with another, i.e. non-Cocoa, language), and now 
> that I'm developing iOS apps in Xcode, I'd like to create an iOS app that can 
> share its files. The file format is fairly straightforward SQLite, and I've 
> determined that I can work with it just fine with the FMDB classes.
> 
> But I am stumped as to how I might be able to more or less seamlessly handle 
> syncing the file between the Mac and the iOS device. Unfortunately iCloud is 
> not an option for me, and iTunes file sharing seems to be far from seamless. 
> 
> I'm hoping the collective brain trust on this list can point to me some 
> possibilities I have not been exposed to that might serve my needs.


___

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

Trying to track down a core animation issue

[Gideon King]

Hi, I have a problem where it appears that a core animation task is being run 
on something created in a background thread, but the thread is being removed 
before the animation has finished.

I have checked through my code and don't see anything that could be doing this 
explicitly, so am guessing that something is happening implicitly. As 
recommended by the error report, I have turned on the logging, and get the 
following:

CoreAnimation: warning, deleted thread with uncommitted CATransaction; created 
by:
0   QuartzCore  0x7fff8d491b95 
_ZN2CA11Transaction4pushEv + 219
1   QuartzCore  0x7fff8d49176d 
_ZN2CA11Transaction15ensure_implicitEv + 273
2   QuartzCore  0x7fff8d498b6a 
_ZN2CA5Layer12begin_changeEPNS_11TransactionEjRP11objc_object + 44
3   QuartzCore  0x7fff8d498ac8 
_ZN2CA5Layer12set_delegateEP11objc_object + 86
4   AppKit  0x7fff85d2df3a -[NSView 
_finalizeWithReferenceCounting] + 324
5   AppKit  0x7fff85d2ddce -[NSView dealloc] + 
42
6   libobjc.A.dylib 0x7fff8c2792b0 
_ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 464
7   libdispatch.dylib   0x7fff905fa2a8 
_dispatch_worker_thread2 + 410
8   libsystem_c.dylib   0x7fff8c15cceb _pthread_wqthread + 
404
9   libsystem_c.dylib   0x7fff8c1471b1 start_wqthread + 13

So some view somewhere is being deallocated while it still has an animation 
running. But there are many views created for different things in my code, and 
putting a breakpoint on NSView's dealloc would be very time consuming, and 
putting a breakpoint on _ZN2CA11Transaction4pushEv didn't help since it is 
called whenever the window is activated, so I can't get to my application. I 
guess I could log it and continue, but that's not going to give me anything 
where I can identify the view.

I'm looking for suggestions on how to track down which view it is that is 
causing the problem. 

Thanks. (I'm sure I must be missing something blindingly obvious on how to 
track this down, but right now I'm drawing a blank).



Gideon
___

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: GCD question

[Rick C.]

Thanks all for the replies!

rc



On Jul 19, 2012, at 11:41 PM, Fritz Anderson wrote:

> On 19 Jul 2012, at 1:47 AM, Rick C. wrote:
> 
>> If I use this to initiate a background "thread":
>> 
>> 
>> dispatch_async(dispatch_get_global_queue(0, 0), ^{
>> 
>> // do some stuff
>> 
>> [self runMyFunction];
>> 
>> [self runAnotherFunction];
>> 
>> // do some more stuff
>> 
>> });
>> 
>> 
>> My question is with my sample calling runMyFunction or runAnotherFunction 
>> are they blocking? Meaning will they block the background "thread" until 
>> they are complete and then it will continue? Or must I put them into another 
>> kind of block so that they finish FIFO?  Thanks just looking for a 
>> confirmation as I'm moving to GCD from threads...
> 
> Grand Central Dispatch and blocks are orthogonal; GCD uses blocks as its unit 
> of work, but does nothing special to them internally. A block is an anonymous 
> (Objective-) C function. It executes from top to bottom, and if it calls a 
> function/method in the middle, the execution path goes into the function, and 
> when the function returns, execution proceeds in the block from there — just 
> like any other function. For that reason, you don't have to serialize 
> -runMyFunction and -runAnotherFunction; they get run one after the other as 
> in any other code.
> 
>   — F
> 
> -- 
> Fritz Anderson -- Xcode 4 Unleashed: Now in stores! -- 
> 
> 


___

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: Sharing a file between Mac and iOS

[Michael Hall]

On Jul 19, 2012, at 6:40 PM, Mark Munz wrote:

>> iCloud? If these are your own application's files. Might be a possibility. 
>> Haven't tried it.
> 
> According to Apple, apps have to be on the Mac App Store in order to
> use iCloud APIs.
> That makes it an automatic 2nd choice (over something like Dropbox)
> for any dev that isn't going to be MAS-only.

True it does seem tightly coupled with the new application direction.
Thats why Dropbox is on my machine.
I'm a little surprised iCloud doesn't find a little more advocation on this 
list though.



___

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: Changing size of view during NSPrintOperation?

[Graham Cox]

On 20/07/2012, at 12:06 AM, Ben Golding wrote:

> In my app, I have a custom view which I'm printing.  The NSPrintPanel has an 
> accessory panel attached with a couple of options on it that I'm observing 
> using the NSPrintPanelAccessorizing method 
> -keyPathsForValuesAffectingPreview.  That works fine.
> 
> When the user changes some of the settings, the size (ie, frame) of the view 
> changes (columns are added/removed from an NSTableView in my custom view).  
> When that happens, the preview doesn't get updated correctly: it uses the 
> frame of the view as it was when the NSPrintOperation was created.  That 
> means that the preview panel doesn't show the correct image of the page to be 
> rendered.
> 
> Is there a way to notify NSPrintOperation that the frame size has changed on 
> the view to be printed?

Is there not a property that you can touch when you change the columns, and add 
that property to what is returned by -keyPathsForValuesAffectingPreview? The 
property doesn't have to DO anything, it just has to be observed by the 
preview. As far as I can tell it's the only way to notify the print preview of 
changes that I've discovered.

--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: Sharing a file between Mac and iOS

[Mark Munz]

> iCloud? If these are your own application's files. Might be a possibility. 
> Haven't tried it.

According to Apple, apps have to be on the Mac App Store in order to
use iCloud APIs.
That makes it an automatic 2nd choice (over something like Dropbox)
for any dev that isn't going to be MAS-only.


On Thu, Jul 19, 2012 at 3:34 PM, Michael Hall  wrote:
>
> On Jul 19, 2012, at 5:16 PM, Dennis wrote:
>
>> It looks like I need to explore using Dropbox.
>
> iCloud? If these are your own application's files. Might be a possibility. 
> Haven't tried 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:
> https://lists.apple.com/mailman/options/cocoa-dev/unmarked%40gmail.com
>
> This email sent to unmar...@gmail.com



-- 
Mark Munz
unmarked software
http://www.unmarked.com/
___

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

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

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

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

Re: Sharing a file between Mac and iOS

[Kyle Sluder]

On Thu, Jul 19, 2012, at 03:58 PM, Gavin Stokes wrote:
> >
> > But I am stumped as to how I might be able to more or less seamlessly
> > handle syncing the file between the Mac and the iOS device.
> 
> 
> This is perhaps the most glaring and insufferable omission in the SDK.  I
> urge you to file a bug report on this and tell Apple that you want to be
> able to sync data between your iOS app and a companion app on the Mac, *
> without* Internet access or hokey wireless workarounds.
> 
> Developers could do this routinely in the '90s under Palm OS; and yet
> years
> into the iPhone SDK, Apple still hasn't figured it out?  This should have
> been expected and resolved within the first couple of SDK updates, if not
> at launch.  Now I'm sure the myth of free, high-speed, worldwide,
> unlimited, and always-available Internet access will be used as an excuse
> to continue blowing it off.

Really, Palm figured it out? Before I ditched my Centro, HotSync would
constantly replace the existing device database.

--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: Sharing a file between Mac and iOS

[Gavin Stokes]

>
> But I am stumped as to how I might be able to more or less seamlessly
> handle syncing the file between the Mac and the iOS device.


This is perhaps the most glaring and insufferable omission in the SDK.  I
urge you to file a bug report on this and tell Apple that you want to be
able to sync data between your iOS app and a companion app on the Mac, *
without* Internet access or hokey wireless workarounds.

Developers could do this routinely in the '90s under Palm OS; and yet years
into the iPhone SDK, Apple still hasn't figured it out?  This should have
been expected and resolved within the first couple of SDK updates, if not
at launch.  Now I'm sure the myth of free, high-speed, worldwide,
unlimited, and always-available Internet access will be used as an excuse
to continue blowing it off.
___

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: Sharing a file between Mac and iOS

[Michael Hall]

On Jul 19, 2012, at 5:16 PM, Dennis wrote:

> It looks like I need to explore using Dropbox.

iCloud? If these are your own application's files. Might be a possibility. 
Haven't tried 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Sharing a file between Mac and iOS

[Dennis]

On Jul 19, 2012, at 3:12 PM, Jeffrey Oleander wrote:

>> If by 'syncing' you mean 'copying'...
>> If you really mean 'syncing'
> 
> Or do you mean contention management as you'd
> get with a massive data-base running on an NFS
> cluster, so that what is really multiple files
> on separate devices appears to be a monolithic
> data-base that's always "current"?

I mean synching one file such that when a user changes it on one device, it 
gets update on the other device.

It looks like I need to explore using Dropbox.

Thanks to everyone who contributed to this thread.
___

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: Sharing a file between Mac and iOS

[Jeffrey Oleander]

> From: Jens Alfke 
> Subject: Re: Sharing a file between Mac and iOS
> To: "Dennis" 
> Cc: Cocoa-dev@lists.apple.com
> Date: Thursday, 2012 July 19, 13:32 
>> On 2012 Jul 19, at 08:22, Dennis  wrote:
>> But I am stumped as to how I might be able to
>> more or less seamlessly handle syncing the file
>> between the Mac and the iOS device. Unfortunately
>> iCloud is not an option for me, and iTunes file
>> sharing seems to be far from seamless. 
> 
> If by 'syncing' you mean 'copying'...
> If you really mean 'syncing'

Or do you mean contention management as you'd
get with a massive data-base running on an NFS
cluster, so that what is really multiple files
on separate devices appears to be a monolithic
data-base that's always "current"?
___

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: NSAutounbinder not releasing my object in a timely manner

[Ken Thomases]

On Jul 19, 2012, at 6:02 AM, Jonathan Taylor wrote:

> - User requests batch processing of data within a folder tree, which will 
> result in between 0 and many separate movies being generated.
> - Application allocates a "progress" tracker, subclassed from 
> NSWindowController, in control of a window containing a progress indicator 
> and various other feedback elements. 
> - This is supplied to separate traversal/parsing code which identifies source 
> data from which movies should be generated.
> - For each movie to be generated, the progress indicator is retained in 
> association with a GCD block which will be executed to perform the actual 
> work, added to a serial queue
> - Following tree traversal, the application releases its reservation on the 
> progress tracker. If no movies are due to be generated, I had intended this 
> to cause it to be deallocated, at which point I had been closing the window.
> 
> If work was queued, this will in due course be executed. The current work 
> block will take control of updating the progress tracker. When it is finished 
> it will release its reservation of the progress tracker. Again, when all work 
> has been completed I intended the retain count to fall to zero at which point 
> it would be deallocated and closed.

> Now, your statement that "[you shouldn't be] relying on an object being 
> deallocated to change your GUI" seems fair, but how would you tackle my 
> scenario here?

This sounds like a job for a dispatch group.  Schedule all of the blocks using 
one of the dispatch_group_[a]sync() functions.  Set up a block to be performed 
when they are all completed using dispatch_group_notify().

> One possible solution would be to have an intermediary object with no 
> gui/binding/etc of its own, which allocates and owns the progress window and 
> is retained and released by my code as necessary, closing/releasing the 
> window when it is deallocated. In practice, I suspect that would work because 
> that intermediary object "shouldn't" get caught up in any of the deferred 
> autoreleasing that was associated with my original problem.

I would expect it to have exactly the same problem.

> However I am genuinely not sure whether that is just a slightly more indirect 
> way of violating your advice, or whether it is acceptable. I guess I am not 
> sure whether your statement is a generic design principle or a practical rule 
> of thumb for avoiding the sort of issue I encountered.

I would say it's a general principle.  Deallocation is for releasing resources. 
 Don't predicate any behavior of your program which is not related specifically 
to resource management on deallocation.  Ideally, you wouldn't even wait for 
deallocation to release resources.  It's been Apple's advice for a while, for 
example, to explicitly close a file handle when the code which owns the file 
handle knows it's done with it.  Don't just leave it to dealloc.


> In my mind retain/release is a way of tracking the interest that my different 
> work packages have on the progress window.

No, it's a way of tracking ownership of the resource, which is slightly 
different.  Of course an object should keep ownership of the progress window 
for as long as it "has an interest" in it, but that's not what it truly 
represents.  You're currently dealing with the case where the two diverge.

> If you say you don't like my intermediary object approach then my next 
> proposal will be that I implement a "manual" counter of the number of work 
> packages outstanding... which is really just me reimplementing a parallel 
> retain/release mechanism myself. Is *that* more acceptable, or am I again 
> violating the spirit if not the letter of your statement?

I don't consider myself any sort of arbiter of these things, so "acceptable" 
isn't the right word, but I don't have any problem with that.  First, your 
mechanism would presumably not have anything like autorelease.  Second, since 
it's not a mechanism that the rest of Cocoa will participate in, you don't get 
other code implicitly and/or unwittingly changing the behavior of your code.  
Finally, it won't be a mechanism with another, unrelated semantic purpose that 
you'd be overloading.

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: Re: Sharing a file between Mac and iOS

[Marc Respass]

> I have written a Mac app (with another, i.e. non-Cocoa, language), and now 
> that I'm developing iOS apps in Xcode, I'd like to create an iOS app that can 
> share its files. The file format is fairly straightforward SQLite, and I've 
> determined that I can work with it just fine with the FMDB classes.
> 
> But I am stumped as to how I might be able to more or less seamlessly handle 
> syncing the file between the Mac and the iOS device. Unfortunately iCloud is 
> not an option for me, and iTunes file sharing seems to be far from seamless.
> 
> I'm hoping the collective brain trust on this list can point to me some 
> possibilities I have not been exposed to that might serve my needs.

As others have said, Dropbox is a good solution although Dropbox is a file 
synchronization solution, not a data synchronization solution. I have been 
researching this myself. The Dropbox API is pretty easy to use and VoodooPad 5 
uses it to sync Flying Meat: VoodooPad 5.0 Released. If you were to use 
Dropbox, I suggest using the API and integrating support rather than relying on 
Dropbox to correctly sync your data. I have run into many data corruption 
problems doing that.

These all appear to work with CoreData so they might not help
Simperium
nothirst/TICoreDataSync · GitHub
AFNetworking/AFIncrementalStore · GitHub

Good luck
Marc
___

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

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

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

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

Re: NSTokenField: "value" binding hijacks down-arrow key [Punted]

[Jerry Krinock]

On 2012 Jul 18, at 09:12, Jerry Krinock wrote:

> • "value" binding of an NSTokenField bound is bound via an object controller 
> to an array property of a model object.  
> • -tokenField:completionsForSubstring:indexOfToken:indexOfSelectedItem: is 
> implemented to show completions.
> 
> The completions menu shows, but when user hits the down-arrow key, instead of 
> stepping into the completions menu, the token ends editing immediately, 
> setting its value to the first completion in the menu.
> 
> Problem seems to be related to the "value" binding, because without this 
> binding the down-arrow key steps into the completions menu as expected.  
> Works the same with or without the binding options (No Selection, Multiple 
> Values, etc.).  Also works the same with either binding in Interface Builder 
> or in code.

For some reason, if I implement a cheesy "helper" attribute in the window 
controller, and bind the token field's "value" to this, bypassing the object 
controller, the problem is solved.

I tried to reproduce the problem in a small test project, but its completions 
menu always works as expected, with or without the object controller.  The 
explanation may be that, in the real project, the binding is to a special 
"multi-object" object which I have designed to merge attributes for multiple 
selections, via -(set)valueForUndefinedKey:.

But all this trouble is in 10.7, and with 10.8 on the way, the boss says I 
should ship with the cheesy "helper" attribute workaround and move on.  Sorry :)


___

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: NSAutounbinder not releasing my object in a timely manner

[Erik Stainsby]

Jonathan, 
Could you not watch the serial queue you mentioned? When it is empty, release 
the progress window. 

- Erik

Sent from my iPad

On 2012-07-19, at 4:02 AM, Jonathan Taylor  wrote:

> this nasty NSAutounbinder thingy then jumps in and re-retains it in some 
> evil under-the-covers voodoo to do with avoiding retain cycles (as I 
> understand it). Unfortunately the balancing autorelease only occurs 16 
> seconds later when I move the mouse! While not catastrophic this is 
> pretty annoying and looks rather embarrassing.
>>> 
 It's not embarrassing unless your users are running your app in a 
 debugger.  
>>> 
>>> Sorry, you've lost me there. Are you saying this will not occur if I am 
>>> running standalone rather than under XCode? (Unfortunately I don't have the 
>>> code in front of me to try this out). If that is the case then that's good 
>>> - if frustrating - news. Is this a known issue then? I was working on the 
>>> assumption that I was doing something obscurely wrong, or at least 
>>> non-standard somewhere to trigger this from happening.
>>> 
>>> Or are you saying you only see the NSAutounbinder stuff in the debugger? If 
>>> so then - sure, but it's the fact that the progress bar is just sitting 
>>> there until I move the mouse that alarms me.
>> 
>> Are you saying you're relying on an object being deallocated to change your 
>> GUI?  You shouldn't be.  If you want to close or hide a window, send it a 
>> -close or -orderOut: message.  If you want to remove or hide a view, remove 
>> it from the view hierarchy or send it -setHidden:YES.  If its hidden binding 
>> is bound to a model or controller property, set that property (on the main 
>> thread).
> 
> Right, that makes a lot of sense. I can understand the principle of not 
> relying on the dealloc for that sort of thing and on first reading that made 
> complete sense. However, I have now tracked down/remembered the piece of code 
> that was my motivation for taking the approach I did. As always, it turns out 
> the real question is probably not quite the one I originally asked! Can I get 
> your opinion on this workflow? This is how I had previously done things:
> 
> - User requests batch processing of data within a folder tree, which will 
> result in between 0 and many separate movies being generated.
> - Application allocates a "progress" tracker, subclassed from 
> NSWindowController, in control of a window containing a progress indicator 
> and various other feedback elements. 
> - This is supplied to separate traversal/parsing code which identifies source 
> data from which movies should be generated.
> - For each movie to be generated, the progress indicator is retained in 
> association with a GCD block which will be executed to perform the actual 
> work, added to a serial queue
> - Following tree traversal, the application releases its reservation on the 
> progress tracker. If no movies are due to be generated, I had intended this 
> to cause it to be deallocated, at which point I had been closing the window.
> 
> If work was queued, this will in due course be executed. The current work 
> block will take control of updating the progress tracker. When it is finished 
> it will release its reservation of the progress tracker. Again, when all work 
> has been completed I intended the retain count to fall to zero at which point 
> it would be deallocated and closed.
> 
> My intention with all this was to avoid the need for any "information 
> sharing" between bits of code that I felt should be fairly independent. The 
> application-level code that originally allocates the progress tracker doesn't 
> need to care about what any more specific code wants to do with the progress 
> tracker, it just makes it available to anything that wants to retain it for 
> future use, and then relinquishes any further "personal" interest in that 
> object.
> 
> Now, your statement that "[you shouldn't be] relying on an object being 
> deallocated to change your GUI" seems fair, but how would you tackle my 
> scenario here? One possible solution would be to have an intermediary object 
> with no gui/binding/etc of its own, which allocates and owns the progress 
> window and is retained and released by my code as necessary, 
> closing/releasing the window when it is deallocated. In practice, I suspect 
> that would work because that intermediary object "shouldn't" get caught up in 
> any of the deferred autoreleasing that was associated with my original 
> problem. However I am genuinely not sure whether that is just a slightly more 
> indirect way of violating your advice, or whether it is acceptable. I guess I 
> am not sure whether your statement is a generic design principle or a 
> practical rule of thumb for avoiding the sort of issue I encountered.
> 
> In my mind retain/release is a way of tracking the interest that my different 
> work packages have on the progress window. If you say you don't like my 
> in

Re: Sharing a file between Mac and iOS

[Jens Alfke]

On Jul 19, 2012, at 8:22 AM, Dennis  wrote:

> But I am stumped as to how I might be able to more or less seamlessly handle 
> syncing the file between the Mac and the iOS device. Unfortunately iCloud is 
> not an option for me, and iTunes file sharing seems to be far from seamless. 

If by 'syncing' you mean 'copying', there's always the document access UI in 
iTunes for copying files in and out of your iOS app's Documents directory, 
although it's kind of awkward to use.

If you really mean 'syncing', then Dropbox is probably your best bet. Just be 
aware that its notion of syncing is pretty coarse-grained — it's going to 
update the entire file at once, and it won't resolve conflicts in the file. So 
if one database row gets changed on one device, and another one on another 
device, Dropbox is just going to go 'duh' and give you two copies of the file, 
one with each change. Also, of course, every time you make a change, the entire 
file will have to be uploaded (and downloaded on the other devices) so this 
doesn't scale well.

—Jens
___

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

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

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

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

Re: KVC generic enough?

[Jens Alfke]

On Jul 19, 2012, at 6:13 AM, William Squires  wrote:

>  I'm wondering if there's some way to use introspection to figure out the 
> (primitive) type of a property, such as 'int', 'float', 'char', or 'BOOL' 

Sure — call the Obj-C runtime function property_getAttributes(). You'll first 
want to call class_getProperty() to get the objc_property_t pointer 
representing the property. If the property was declared in a superclass, you'll 
need to manually walk up the class hierarchy until you find the base class that 
has it.

For an example of how to use this, you can take a look at
https://github.com/snej/MYUtilities/blob/master/MYDynamicObject.m
especially the functions getPropertyInfo() and getPropertyType().

—Jens

smime.p7s
Description: S/MIME cryptographic 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Sharing a file between Mac and iOS

[Dennis]

On Jul 19, 2012, at 9:52 AM, Jerry Krinock wrote:

> Dropbox :))
> 
> Seriously, Dropbox won't give you any crap.  Read this, though, and then 
> research further to learn if the App Store rejection issue has been resolved…
> 
> http://www.macrumors.com/2012/05/02/ios-apps-with-dropbox-integration-running-afoul-of-apples-app-store-rules/

Thanks. I hadn't thought of that.

Since the Mac app isn't in the Mac store, that wouldn't be a problem, but I'd 
probably run into the same restriction trying to get the iOS app into the App 
Store. So I'd probably still need an alternative...
___

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: Sharing a file between Mac and iOS

[davelist]

On Jul 19, 2012, at 12:52 PM, Jerry Krinock wrote:

> 
> On 2012 Jul 19, at 08:22, Dennis wrote:
> 
>> Unfortunately iCloud is not an option for me
> 
> Dropbox :))
> 
> Seriously, Dropbox won't give you any crap.  Read this, though, and then 
> research further to learn if the App Store rejection issue has been resolved…
> 
> http://www.macrumors.com/2012/05/02/ios-apps-with-dropbox-integration-running-afoul-of-apples-app-store-rules/
> 

Dropbox released a new SDK that solved the App Store rejection so that is no 
longer an issue.

Dave


___

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

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

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

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

Re: Sharing a file between Mac and iOS

[Jerry Krinock]

On 2012 Jul 19, at 08:22, Dennis wrote:

> Unfortunately iCloud is not an option for me

Dropbox :))

Seriously, Dropbox won't give you any crap.  Read this, though, and then 
research further to learn if the App Store rejection issue has been resolved…

http://www.macrumors.com/2012/05/02/ios-apps-with-dropbox-integration-running-afoul-of-apples-app-store-rules/



___

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: Sharing a file between Mac and iOS

[Glenn L. Austin]

On Jul 19, 2012, at 8:22 AM, Dennis wrote:

> I have written a Mac app (with another, i.e. non-Cocoa, language), and now 
> that I'm developing iOS apps in Xcode, I'd like to create an iOS app that can 
> share its files. The file format is fairly straightforward SQLite, and I've 
> determined that I can work with it just fine with the FMDB classes.
> 
> But I am stumped as to how I might be able to more or less seamlessly handle 
> syncing the file between the Mac and the iOS device. Unfortunately iCloud is 
> not an option for me, and iTunes file sharing seems to be far from seamless. 
> 
> I'm hoping the collective brain trust on this list can point to me some 
> possibilities I have not been exposed to that might serve my needs.


Networking and Bonjour?

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver <><
"Where there's breath, there's hope!"



___

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: NSSplitView question - how to implement my own "adjustViews" style method

[Gary L. Wade]

I don't know for sure, but you might be able to get around the 3rd party 
plug-in issue by using runtime attributes instead.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.com/


___

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

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

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

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

Re: GCD question

[Fritz Anderson]

On 19 Jul 2012, at 1:47 AM, Rick C. wrote:

> If I use this to initiate a background "thread":
> 
> 
> dispatch_async(dispatch_get_global_queue(0, 0), ^{
> 
> // do some stuff
> 
> [self runMyFunction];
> 
> [self runAnotherFunction];
> 
> // do some more stuff
> 
> });
> 
> 
> My question is with my sample calling runMyFunction or runAnotherFunction are 
> they blocking? Meaning will they block the background "thread" until they are 
> complete and then it will continue? Or must I put them into another kind of 
> block so that they finish FIFO?  Thanks just looking for a confirmation as 
> I'm moving to GCD from threads...

Grand Central Dispatch and blocks are orthogonal; GCD uses blocks as its unit 
of work, but does nothing special to them internally. A block is an anonymous 
(Objective-) C function. It executes from top to bottom, and if it calls a 
function/method in the middle, the execution path goes into the function, and 
when the function returns, execution proceeds in the block from there — just 
like any other function. For that reason, you don't have to serialize 
-runMyFunction and -runAnotherFunction; they get run one after the other as in 
any other code.

— F

-- 
Fritz Anderson -- Xcode 4 Unleashed: Now in stores! -- 



___

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

Sharing a file between Mac and iOS

[Dennis]

I have written a Mac app (with another, i.e. non-Cocoa, language), and now that 
I'm developing iOS apps in Xcode, I'd like to create an iOS app that can share 
its files. The file format is fairly straightforward SQLite, and I've 
determined that I can work with it just fine with the FMDB classes.

But I am stumped as to how I might be able to more or less seamlessly handle 
syncing the file between the Mac and the iOS device. Unfortunately iCloud is 
not an option for me, and iTunes file sharing seems to be far from seamless. 

I'm hoping the collective brain trust on this list can point to me some 
possibilities I have not been exposed to that might serve my needs.
___

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: 10.7 Full-Screen transition animation corrupts my UI - how to avoid?

[Kyle Sluder]

On Jul 19, 2012, at 5:17 AM, Motti Shneor  wrote:

> Hi Steve
> 
> How can a view disregard resizing request? It is simply resized

Try -[ windowWillResize:toSize:].

--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: NSSplitView question - how to implement my own "adjustViews" style method

[Rainer Brockerhoff]

On Jul 19, 2012, at 11:06 , cocoa-dev-requ...@lists.apple.com wrote:


> Date: Thu, 19 Jul 2012 11:42:07 +0300
> From: Motti Shneor 
> Message-ID: 
> 
> Thanks for the note. Indeed, RBSplitView is a complete, functional  and 
> feature-loaded class, but it is also lagging behind current Cocoa 
> developments, and does not integrate well XCode 4.x and with SDK 10.7 or and 
> SDK 10.8. Testing with it I saw problems in:
> 1. Look and feel (not coherent with recent standard NSSplitView variants).
> 2. Integration with dev. environment (Apple broke the plugin architecture of  
> Interface-Builder in XCode 4). Everything must be done programmatically.
> 3. Does not mix well with auto-layout views. We don't yet use auto-layout (or 
> we wouldn't have so much trouble with the split-view - it does very well with 
> auto-layout policies.)


Thanks. I was waiting for a solution to #2 (but it seems none will be 
forthcoming) and #3 caught me by surprise - I'd hoped autolayout would help me 
in making a lighter-weight solution for Xcode4 and/or 10.7. So far that doesn't 
seem workable either.

Can you elaborate on #1, by private email? Offhand I don't see any look&feel 
differences.

Thanks,
--
Rainer Brockerhoff  
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
Weblog: http://www.brockerhoff.net/blog


___

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: Icon Overlay on Mac OSX

[David Catmull]

Uli Kusterer  wrote:
> In the old days, one could use Icon Services calls to change the icon used 
> for a particular file type, that might even save you the renaming, but Icon 
> Services is probably considered "old" API these days, and I'm not sure if 
> changes to icons in your app using Icon Services will still affect Finder. 
> Anyway, it's worth a try.

That worked back in Mac OS 9, but as of Mac OS X, changing icons like that 
doesn't affect other applications.
___

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

Changing size of view during NSPrintOperation?

[Ben Golding]

In my app, I have a custom view which I'm printing.  The NSPrintPanel has an 
accessory panel attached with a couple of options on it that I'm observing 
using the NSPrintPanelAccessorizing method -keyPathsForValuesAffectingPreview.  
That works fine.

When the user changes some of the settings, the size (ie, frame) of the view 
changes (columns are added/removed from an NSTableView in my custom view).  
When that happens, the preview doesn't get updated correctly: it uses the frame 
of the view as it was when the NSPrintOperation was created.  That means that 
the preview panel doesn't show the correct image of the page to be rendered.

Is there a way to notify NSPrintOperation that the frame size has changed on 
the view to be printed?

I've tried all sorts of fiddling with the frame and bounds of the view to try 
to get it to display to no avail.

I'm really stuck so any help would be appreciated, as by my customer who is 
very frustrated at how long this detail has taken resolve.

Thanks,

Ben.

smime.p7s
Description: S/MIME cryptographic 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: KVC generic enough?

[Graham Cox]

On 19/07/2012, at 11:13 PM, William Squires wrote:

> Okay, I think there's a misunderstanding here.


Sure.


> In this case - as the writer of the game engine - I don't know (nor should I 
> care) what the interface to the model objects is - as long as the developer 
> of said model objects codes the keys into my game engine, it should be able 
> to manipulate the model object(s) according to the 'effects' the coder feeds 
> into the game engine - KVC should do the rest. The parser in the game engine 
> though, should check (somehow) to see if the value assigned in the 'effect' 
> can be put into the property specified in the 'key' so that I can issue a 
> scripting error (or raise an NSException) if they types are incompatible (in 
> my case, I want the parser to be even more strict than C itself and warn if 
> they assign an integer to a float, or vice versa.
>  I'm wondering if there's some way to use introspection to figure out the 
> (primitive) type of a property, such as 'int', 'float', 'char', or 'BOOL' 
> without having to load the model classes with unnecessary complexity (i.e. 
> keep the complexity in one place - the game engine.)


I think part of the problem here is that you have a reasonable understanding of 
your problem space, and are using terminology that makes sense to you but 
no-one else. From this and your previous description of what you're trying to 
do, to be honest I'm none the wiser. Perhaps a concrete example would help, 
because when you talk about 'effect' I think you mean something specific your 
game engine implements that is not the general meaning of 'effect'.

I've been trying to ignore that and give you advice based on concepts in the 
abstract.

One of these is the general rule that in object-oriented programming, taking 
different code-paths based on the type of an object is avoided, and instead 
some common method is called on the object and that takes the necessary code 
path. You seem determined to break this rule, which I suggest is a bad idea.

If your game engine needs to violate basic concepts like this to do its thing, 
it's probably not a very good design. KVC exists so that any object can be 
treated (in terms of its properties) in much the same way as a dictionary, and 
that's about it. If that's not enough, it's probably not the right technology 
to be basing this on.

You mention that assigning an int to a float should throw an exception. Basing 
it on KVC and NSNumber that's not possible. You can't know from the internal 
type of an NSNumber what value it was created with, for example, if I assign 
the float value 1.0 to an NSNumber it is perfectly within its rights to store 
it as an integer, because that's the maximum precision it requires to represent 
that particular float. If you attempt to examine the obj-c type of the 
NSNumber, you might see integer, not float, even though the original property 
that was boxed into this value was a float! Asking for its -floatValue however, 
you get 1.0, so there's no problem with this until you expect it to to track 
types end-to-end for you.

All I can suggest is that you don't use the automatic boxing/unboxing of scalar 
properties and instead force clients of your engine to return properties in 
some form you can always deal with, such as an object you define that embodies 
the data value and type information. e.g. declare a class 
'WSGameEngineProperty' that can hold numbers, strings or any other value you 
want to work with and ask your clients to send and receive these. (Make it easy 
on them by defining a nice set of convenience class methods for making these 
using any scalar or string type). You can still use KVC to set and retrieve 
these, because they are object types and won't be subject to automatic boxing. 
In effect what you're doing is giving up on automatically detecting the data 
type (because you can't for numbers, and shouldn't in general) and putting that 
responsibility onto the programmer who is the client of your engine, who is a 
lot more intelligent and can always do the right thing!

If that's too big a pill to swallow, another alternative could be to replace 
KVC with something similar of your own which converts to and from your private 
property type automatically (you can use @encode to detect the original type of 
a scalar property). That way your implementation can track the type. The only 
restriction would be that your clients would have to implement their objects 
with methods that you require, such as setGameProperty:forKey:, and 
-gamePropertyForKey: in place of the KVC equivalents.

I still fail to see how your game engine would even be able to ask for a 
property without knowing what it is going to be dealing with, or is it just up 
to the client to push values into your engine? If the latter, the client could 
tell you the type through the API you define, no?


--Graham


___

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

Re: NSArrayController not rearranging correctly

[Markus Spoettl]

On 7/19/12 8:40 AM, Quincey Morris wrote:

2. Use a brute force flag when setting the predicate, something like this:

dontStartExpensiveUpdate = YES;
[_arrayController setPredicate: …];
[_arrayController rearrangeObjects];
// at this point, the KVO notification has been sent up to twice, but ignored
each time
dontStartExpensiveUpdate = NO;
… do the expensive update now …


I ended up doing something similar: I subclassed NSArrayController and added a 
flag there. The heavy lifting custom views, which are bound to arrangedObjects, 
now check if the object they are bound to is my NSArrayController subclass when 
a KVO notification is delivered. If so and the flag is set, they ignore the 
observation notification. My NSArrayController subclass implements 
-rearrangeObjects which clears the flag first, then calls super.


Of course I sacrifice a little of my perfect view class encapsulation, but it's 
justifiable because it makes solving the issue so simple. If only that 
NSArrayController bug didn't exist…


Thanks Quincey for the elaborate responses and for confirming the bug.

Regards
Markus--
__
Markus Spoettl
___

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: KVC generic enough?

[William Squires]

  Okay, I think there's a misunderstanding here. In this case - as the writer 
of the game engine - I don't know (nor should I care) what the interface to the 
model objects is - as long as the developer of said model objects codes the 
keys into my game engine, it should be able to manipulate the model object(s) 
according to the 'effects' the coder feeds into the game engine - KVC should do 
the rest. The parser in the game engine though, should check (somehow) to see 
if the value assigned in the 'effect' can be put into the property specified in 
the 'key' so that I can issue a scripting error (or raise an NSException) if 
they types are incompatible (in my case, I want the parser to be even more 
strict than C itself and warn if they assign an integer to a float, or vice 
versa.
  I'm wondering if there's some way to use introspection to figure out the 
(primitive) type of a property, such as 'int', 'float', 'char', or 'BOOL' 
without having to load the model classes with unnecessary complexity (i.e. keep 
the complexity in one place - the game engine.)

On Jul 18, 2012, at 10:09 PM, Graham Cox wrote:

> 
> On 19/07/2012, at 1:33 AM, Alex Zavatone wrote:
> 
>> Ah, yes, when coding, of course.  For some reason, I was expecting that 
>> during runtime/debugging, if you know the name of an object or you are 
>> accessing a object your coworker wrote there was some concept that instantly 
>> told you its class and makeup. 
> 
> 
> Well, there is - you can use the runtime functions to delve into the class 
> hierarchy of an object.
> 
> But that's not how you write code.
> 
> If you are using code a co-worker wrote then you use the documentation that 
> the co-worker provided to make use of it. And by documentation I mean the 
> headers - they are the "contract" which his code promises to abide by. If a 
> property is declared to return a string and it doesn't, that's a bug, pure 
> and simple. The same headers told you the names of the properties - how else 
> would you know them? Property declarations link a name to a type. If every 
> property were typed 'id' however and you were expected to examine the type at 
> runtime, then your co-worker should probably be pensioned off rather quickly. 
> Where a type is returned as 'id', it means that any object can be returned, 
> and that's a hint that your code should not need to care what it is, and so, 
> if you find yourself needing to know, that could be a code smell that 
> something's amiss in your approach.
> 
> Note that -isKindOfClass only tells you whether an object is a given class or 
> a subclass of it, it returns a BOOL. So it's only there to confirm what you 
> already expect, or to reject silly mistakes, like passing in the wrong kind 
> of object to something that must have another kind.
> 
> If you do something like this:
> 
> NSString* theType = NSStringFromClass([someObject class]);
> 
> if([theType isEqualToString:@"classTypeA"])
> {
>   [self doStuffForClassAType:someObject];
> }
> else if( [theType isEqualToString:@"classTypeB"])
> {
>   [self doStuffForClassBType:someObject];
> 
> }
> else if .
> 
> 
> then that's really violating the spirit and intention of object-oriented 
> programming.
> 
> 
> --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: GCD question

[Jonathan Taylor]

> If I use this to initiate a background "thread":
> 
> 
> dispatch_async(dispatch_get_global_queue(0, 0), ^{
> 
> // do some stuff
> 
> [self runMyFunction];
> 
> [self runAnotherFunction];
> 
> // do some more stuff
> 
> });
> 
> 
> My question is with my sample calling runMyFunction or runAnotherFunction are 
> they blocking?  Meaning will they block the background "thread" until they 
> are complete and then it will continue?  Or must I put them into another kind 
> of block so that they finish FIFO?  Thanks just looking for a confirmation as 
> I'm moving to GCD from threads...

You are correct in that they are "blocking" if I understand you correctly. 
There is nothing magic about the concept of GCD blocks, they are really just 
anonymous functions with a slightly unusual scope. You would be equally welcome 
to use the alternative dispatch_async_f API, which would have exactly the same 
outcome (code written in Mail; not complied!):

void MyDispatchFunc(void *)
{
// do some stuff
[self runMyFunction];
[self runAnotherFunction];
// do some more stuff   
}

void foo(void)
{
dispatch_async_f(dispatch_get_global_queue(0, 0), MyDispatchFunc);
}


I hope it is obvious from this alternative formulation that there is nothing 
"magic" going on: the API call is just scheduling a call to MyDispatchFunc at 
the time GCD deems appropriate. Exactly the same is true of the example you 
gave, it is just that you are passing a block around instead of a function 
pointer.

Hope that helps
Jonny
___

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

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

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

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

Re: 10.7 Full-Screen transition animation corrupts my UI - how to avoid?

[Motti Shneor]

Hi Steve

How can a view disregard resizing request? It is simply resized

The window cannot reject its resizing. Or actually, it DOES reject, by stating 
its min-size to cocoa. The window IS RESIZED.

The content view of a window has no way to prevent its resizing. It is by 
definition covering its windows content area. As far as I know, there is no 
(BOOL)shouldResize: method I can override for an NSView or a NSWindow, in which 
It can refuse a new size. 

A possible solution would be to have sub-view not-resize as their super-view, 
and be cut when the superview goes below their minimum. 
That implies pretty much coding to let subviews do resize with superview when 
possible and don't do it otherwise. Also, revealing sub-view contents that has 
been cut calls for more re-drawing and synchronization mechanism.

On 19 ביול 2012, at 13:56, Steve Bird wrote:

> 
> On Jul 10, 2012, at 10:39 AM, Motti Shneor wrote:
>> If the window started in its minimal size, this animation will SHRINK IT 
>> BELOW THE MINIMAL size and will corrupt my UI beyond repair. My views are 
>> receiving setFrameSize: with unsupported size.
> 
> Not sure about prevention, but can't you put a check here?
> If (sizeRequested < minSize)
>   sizeRequested = minSize
> 
> Just disregard the invalid requests?
> 
> Steve Bird
> Culverson Software - Elegant software that is a pleasure to use.
> www.Culverson.com (toll free) 1-877-676-8175
> 
> 

Motti Shneor


___

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: NSAutounbinder not releasing my object in a timely manner

[Jonathan Taylor]

 this nasty NSAutounbinder thingy then jumps in and re-retains it in some 
 evil under-the-covers voodoo to do with avoiding retain cycles (as I 
 understand it). Unfortunately the balancing autorelease only occurs 16 
 seconds later when I move the mouse! While not catastrophic this is pretty 
 annoying and looks rather embarrassing.
>> 
>>> It's not embarrassing unless your users are running your app in a debugger. 
>>>  
>> 
>> Sorry, you've lost me there. Are you saying this will not occur if I am 
>> running standalone rather than under XCode? (Unfortunately I don't have the 
>> code in front of me to try this out). If that is the case then that's good - 
>> if frustrating - news. Is this a known issue then? I was working on the 
>> assumption that I was doing something obscurely wrong, or at least 
>> non-standard somewhere to trigger this from happening.
>> 
>> Or are you saying you only see the NSAutounbinder stuff in the debugger? If 
>> so then - sure, but it's the fact that the progress bar is just sitting 
>> there until I move the mouse that alarms me.
> 
> Are you saying you're relying on an object being deallocated to change your 
> GUI?  You shouldn't be.  If you want to close or hide a window, send it a 
> -close or -orderOut: message.  If you want to remove or hide a view, remove 
> it from the view hierarchy or send it -setHidden:YES.  If its hidden binding 
> is bound to a model or controller property, set that property (on the main 
> thread).

Right, that makes a lot of sense. I can understand the principle of not relying 
on the dealloc for that sort of thing and on first reading that made complete 
sense. However, I have now tracked down/remembered the piece of code that was 
my motivation for taking the approach I did. As always, it turns out the real 
question is probably not quite the one I originally asked! Can I get your 
opinion on this workflow? This is how I had previously done things:

- User requests batch processing of data within a folder tree, which will 
result in between 0 and many separate movies being generated.
- Application allocates a "progress" tracker, subclassed from 
NSWindowController, in control of a window containing a progress indicator and 
various other feedback elements. 
- This is supplied to separate traversal/parsing code which identifies source 
data from which movies should be generated.
- For each movie to be generated, the progress indicator is retained in 
association with a GCD block which will be executed to perform the actual work, 
added to a serial queue
- Following tree traversal, the application releases its reservation on the 
progress tracker. If no movies are due to be generated, I had intended this to 
cause it to be deallocated, at which point I had been closing the window.

If work was queued, this will in due course be executed. The current work block 
will take control of updating the progress tracker. When it is finished it will 
release its reservation of the progress tracker. Again, when all work has been 
completed I intended the retain count to fall to zero at which point it would 
be deallocated and closed.

My intention with all this was to avoid the need for any "information sharing" 
between bits of code that I felt should be fairly independent. The 
application-level code that originally allocates the progress tracker doesn't 
need to care about what any more specific code wants to do with the progress 
tracker, it just makes it available to anything that wants to retain it for 
future use, and then relinquishes any further "personal" interest in that 
object.

Now, your statement that "[you shouldn't be] relying on an object being 
deallocated to change your GUI" seems fair, but how would you tackle my 
scenario here? One possible solution would be to have an intermediary object 
with no gui/binding/etc of its own, which allocates and owns the progress 
window and is retained and released by my code as necessary, closing/releasing 
the window when it is deallocated. In practice, I suspect that would work 
because that intermediary object "shouldn't" get caught up in any of the 
deferred autoreleasing that was associated with my original problem. However I 
am genuinely not sure whether that is just a slightly more indirect way of 
violating your advice, or whether it is acceptable. I guess I am not sure 
whether your statement is a generic design principle or a practical rule of 
thumb for avoiding the sort of issue I encountered.

In my mind retain/release is a way of tracking the interest that my different 
work packages have on the progress window. If you say you don't like my 
intermediary object approach then my next proposal will be that I implement a 
"manual" counter of the number of work packages outstanding... which is really 
just me reimplementing a parallel retain/release mechanism myself. Is *that* 
more acceptable, or am I again violating the spirit if not the letter of your 
statemen

Re: 10.7 Full-Screen transition animation corrupts my UI - how to avoid?

[Steve Bird]

On Jul 10, 2012, at 10:39 AM, Motti Shneor wrote:
> If the window started in its minimal size, this animation will SHRINK IT 
> BELOW THE MINIMAL size and will corrupt my UI beyond repair. My views are 
> receiving setFrameSize: with unsupported size.

Not sure about prevention, but can't you put a check here?
If (sizeRequested < minSize)
   sizeRequested = minSize

Just disregard the invalid requests?




Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
www.Culverson.com (toll free) 1-877-676-8175



___

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: NSSplitView question - how to implement my own "adjustViews" style method

[Motti Shneor]

Hello Gideon.

Thanks for the note. Indeed, RBSplitView is a complete, functional  and 
feature-loaded class, but it is also lagging behind current Cocoa developments, 
and does not integrate well XCode 4.x and with SDK 10.7 or and SDK 10.8. 
Testing with it I saw problems in:
1. Look and feel (not coherent with recent standard NSSplitView variants).
2. Integration with dev. environment (Apple broke the plugin architecture of  
Interface-Builder in XCode 4). Everything must be done programmatically.
3. Does not mix well with auto-layout views. We don't yet use auto-layout (or 
we wouldn't have so much trouble with the split-view - it does very well with 
auto-layout policies.)

On 18 ביול 2012, at 09:05, Gideon King wrote:

> I always use RBSplitView - has all that stuff built in and more…
> 
> http://brockerhoff.net/blog/tag/rbsplitview/
> 
> Seems to work fine for my needs.
> Regards
> Gideon
> 

Motti Shneor
___

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: NSArrayController not rearranging correctly

[Quincey Morris]

On Jul 18, 2012, at 23:22 , Markus Spoettl wrote:

> The array controller is used by views directly, they bind to arrangedObjects 
> (like in the example). Since when is it recommended to insert an intermediate 
> object between table view and NSArrayController?

Ugh, I didn't pay enough attention to what you actually said. Yes, you can't 
just prevent the KVO notifications getting through when you're using bindings.

So let me rephrase and see if I can say something sensible…

To use bindings at all, you're basically buying into the idea that your bound 
view can reasonably respond to each KVO notification individually (from the 
data model, via the binding). You have no real control over the timing and 
granularity** and [non]redundancy of the KVO notifications. If the response is 
very expensive, bindings are not a reasonable solution.

If the response to the notifications is simply to redraw, and redrawing is 
expensive, one way out is to move the expensive calculation into a background 
thread, leaving the redrawing itself to be quite cheap. This is the sort of 
"concurrent user interface" approach that's more usual in iOS apps, with the 
effect that content "pops" into view asynchronously. (There's a session on this 
in the 2012 WWDC videos.)

Another way out is to bind the view to an intermediate object, such as a window 
controller, which is more careful about when it triggers the KVO notifications 
that affect the view.

A third way is to use a data source/control action approach, instead of using 
bindings. This is a perfectly fine alternative, and is *better* than bindings 
when you need a more controlled form of communication between the source and 
the view.

In the latter two approaches, you might end up asking yourself if using array 
controllers at all makes sense. It's easy to end up writing more code working 
around array controller assumptions than just writing glue code that really 
works. The main benefits of array controllers are (a) sorting; (b) filtering; 
and (c) oversight of the NSEditor/NSEditorRegistration protocols. Chances are 
you can do those things yourself without much trouble.

FWIW


** For example, it would be perfectly legal, when you change the array 
controller's filter predicate, for there to be pairs of KVO notifications, one 
specifying just object deletions and one specifying just object insertions. If 
you've been getting a single generic "property changed" notification, that's 
almost more by luck than by design.


___

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