date:20090222

On Sun, Feb 22, 2009 at 10:49 PM, Ben Lachman  wrote:
> The original question stands, does anyone have code that would be helpful in
> implementing such a feature?

To be fair, the original question was indeed answered by Nick Zitzmann
at the very outset: you can't move a running application, because it
confuses the framework.

--Kyle Sluder
___

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

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

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

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

Re: Moving oneself to /Applications (or ~/Applications)

2009-02-22 Thread Ben Lachman

Perhaps the issue is that you are assuming an offer to do something is  
subtle way of telling you where to put your stuff.  In reality it  
isn't.  It's purely offering a short cut/automation if you'd like it.   
Say no, and it would never ask you again.  But anyway, this is getting  
quite off topic, and I'd prefer to stay on topic.


The original question stands, does anyone have code that would be  
helpful in implementing such a feature?


If you'd like to continue discussing the validity of such a feature  
you are more than welcome to contact me off list.


Thanks,
->Ben
--
Ben Lachman
Acacia Tree Software

http://acaciatreesoftware.com

email: blach...@mac.com
twitter: @benlachman
mobile: 740.590.0009



On Feb 21, 2009, at 12:26 PM, Andreas Mayer wrote:



Am 21.02.2009 um 17:33 Uhr schrieb Alex Kac:

If an app offered to help - just once - I don't see that as an  
intrusion, but a more Mac-like feature. Its not intrusive.


I disagree. It's not an applications job to tell me where to put it.

If, for some reason, it *must* be put in /Applications, use an  
installer package.



Andreas
___

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

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

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

This email sent to blach...@mac.com


___

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

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

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

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

test please ignore

2009-02-22 Thread Matt Anderson

Sorry if this actually gets through -- I don't think it will.  Please ignore.

I sent my first message to cocoa-dev 2 weeks ago, and it was never (to
my knowledge) posted.  Contacting the admins has garnered no response
thusfar.

Just testing again.
___

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

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

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

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

Re: Name to PSN

2009-02-22 Thread Jerry Krinock



On 2009 Feb 22, at 15:36, Michael Ash wrote:


An agent is (I think!) a daemon that gets linked to a user's login
session and is automatically started and stopped by launchd.



Until a few weeks ago, I thought that I was stupid for not being able  
to state in my own words the "differences" "between" an application,  
background application, daemon, LSUI-whatever; after having read  
several articles on them.  Then I found this "definition" in the  
ProcessSerialNumber documentation:


"applications (defined as things which can appear in the Dock that are  
not documents and are launched by the Finder or Dock)".


Since I read that, I don't think I'm stupid any more.  At best, this  
space is multi-dimensional and depends on the context.  For  
practitioners, I'd say: "As long as you can make it work, you can call  
it whatever you want to."


___

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

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

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

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

Re: immutable collection given to mutating function error

2009-02-22 Thread Charles Srstka


Replace this line:

On Feb 22, 2009, at 11:17 AM, Michael Domino wrote:

prefMinorSectionCFMutableDictionaryRef =  
static_cast(const_cast(pVoid));


with this:

prefMinorSectionCFMutableDictionaryRef =  
CFDictionaryCreateMutableCopy(NULL, 0,  
static_cast(const_cast(pVoid)));


This way, you'll be sure to always get a mutable dictionary,  
regardless of whether the original was mutable or not.


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

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

Re: Name to PSN

On Sun, Feb 22, 2009 at 5:00 PM, Pierce Freeman
 wrote:
> Very true, very true.  Is the dock considered an agent (or daemon) anyway?
> It is on the screen, but I don't think I'd classify it as an application.
> It's kind of confusing. @_@

No, the Dock is an LSUIElement application. The LSUIElement means that
it has no menu bar, and does not appear in the Dock.

A daemon is a long-lived BSD-level background process which does not
make a connection to the window server.

An agent is (I think!) a daemon that gets linked to a user's login
session and is automatically started and stopped by launchd.

Mike
___

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

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

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

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

Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock).

On Sun, Feb 22, 2009 at 3:46 PM, Luke Evans  wrote:
> My discovery (and life is full of them, so nothing particularly unusual
> here) is that the practicality of doing the locking appears to 'tip over' if
> you have binding to your Core Data.  I have my main thread, and one
> background thread trawling for files - both scrupulously locked on the MOC
> around _any_ access, i.e. even reading a property.

No you don't. You're locking around any *explicit* access to a
property. Meanwhile your implicit accesses due to bindings are going
unlocked, and your code fails, hard.

It's a basic tenet of multithreading. If you're taking an unsafe
datastructure, and making it safe by synchronizing all accesses with
locks, you *cannot* give *any* references to that data structure to
outside code.

Bindings will not follow your locking protocol, so you can't let them
touch your context with this approach.

Mike
___

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

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

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

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

Re: How to get the "white shadow" effect when drawing NSStrings?

2009-02-22 Thread Steve Christensen

It seems like the best solution would be to handle both the Leopard+  
and pre-Leopard cases at runtime so any changes to HID over time are  
non-issues since you've limited the custom code to the pre-Leopard  
case. You might be able to get away with as little as adding a  
category to NSCell (typed in Mail so this hasn't been tested):


@implementation NSCell (MyRaisedBackgroundStyle)
- (void)useRaisedBackgroundStyle
{
#if MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_5
if (floor(NSAppKitVersionNumber) <= NSAppKitVersionNumber10_4)
{
NSMutableAttributedString* text =  
[[[NSMutableAttributedString alloc] initWithAttributedString:

[self attributedStringValue]] autorelease];
NSShadow* shadow = [[[NSShadow alloc] init] autorelease];

[shadow setShadowColor:[NSColor colorWithCalibratedWhite:1.0  
alpha:0.5]];

[shadow setShadowOffset:NSMakeSize(0.0, -1.5)];
[shadow setShadowBlurRadius:0.0];

[text addAttribute:NSShadowAttributeName value:shadow  
range:NSMakeRange(0, [text length])];

[self setAttributedStringValue:text];
}
else
#endif

{
[self setBackgroundStyle:NSBackgroundStyleRaised];
}
}
@end

You'd need to call this method after the cell's text has been  
initialized/modified, which could just be done in -awakeFromNib for  
static text. If you wanted to get fancy, you could write a custom  
cell class that does all of the above whenever any of the text  
attributes are changed.


steve


On Feb 22, 2009, at 2:38 PM, Ken Ferry wrote:


Yes, I'm sure. :-) You won't get the subpixel font smoothing right, if
nothing else.
Also, the other method tracks whatever the current human interface  
design is

for text on a raised surface.

-Ken

On Sun, Feb 22, 2009 at 2:16 PM, Graham Cox  
 wrote:




On 23/02/2009, at 4:43 AM, Ken Ferry wrote:


 This effect cannot be implemented with text attributes.



Are you sure? This gets awfully close, unless I'm missing the  
point here

(the font to use your choice):

+ (NSDictionary*)   defaultTitleAttributes
{
   // return the dictionary used to specify the attributes for  
drawing

the title string in the palette windows. Override to
   // customize the title string

   static NSDictionary*sTitleAttrs = nil;

   if ( sTitleAttrs == nil )
   {
   NSFont* font = [NSFont boldSystemFontOfSize:11.0];
   NSMutableParagraphStyle* style = [[NSParagraphStyle
defaultParagraphStyle] mutableCopy];

   [style setAlignment:NSCenterTextAlignment];

   NSShadow* shadw = [[NSShadow alloc] init];

   [shadw setShadowColor:[NSColor whiteColor]];
   [shadw setShadowOffset:NSMakeSize( 0, -1.5 )];
   [shadw setShadowBlurRadius:1.0];

   sTitleAttrs = [NSDictionary
dictionaryWithObjectsAndKeys:font,NSFontAttributeName,

 style,NSParagraphStyleAttributeName,

 shadw, NSShadowAttributeName,

 nil];
   [sTitleAttrs retain];
   [style release];
   [shadw release];
   }

   return sTitleAttrs;
}

___

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

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

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

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

Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock).

2009-02-22 Thread Luke Evans


Thanks Ken.

Yes, I'm intending to experiment with the multiple-context approach  
now.  I had a few questions about this (posted earlier in the thread),  
but they're only really soliciting for thoughts on best practice using  
that technique - and nothing I wouldn't discover through  
experimentation.


I had thought the locking would be relatively contention free, seeing  
as almost all the interaction with the MOC was happening on the main  
thread anyway, and I just had a background thread for a single  
function, that would only find relevant files once in a blue moon - at  
which point all that locking everywhere would allow a simple update to  
the MOC from that thread.  I was completely ignorant of the effect of  
the binding to UI controls though, which I believe was the Achilles'  
heal - in this specific case.


Agreed on shared memory point in general, but of course there is  
almost always a need to exchange data (which very frequently comes to  
you as some memory reference, and whose contents you are supposed to  
obtain via methods).  I'm still learning what things can be safely  
exchanged, even when supposedly 'reading'.  For instance I just  
discovered that extracting an NSImage's representation from background  
threads to use in a CIImage can be deadly (apparently using it causes - 
[NSBitmapImageRep getBitmapDataPlanes:] to _loadData which I assume  
isn't thread-safe - though I need to properly figure this one out).   
Naturally, it's unrealistic to expect documentation of all the  
behaviours that objects have vis-a-vis threading (though Apple have  
guidelines), but whenever you create some kind of concurrency you have  
to think about what objects/states will specify its operation and  
whether these will be safe to pass themselves.  Anyway, I digress.   
It's patently clear in the case of MOCs that locking is only viable in  
some benevolent conditions, which are not those I thought I had :-)


-- lwe


On 22-Feb-09, at 1:51 PM, Ken Ferry wrote:


Memory accessed by multiple threads is the enemy of multithreaded  
performance and correctness.  The multiple-contexts approach  
isolates the sharing to a well controlled layer in the store.



___

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

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

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

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

Re: How to get the "white shadow" effect when drawing NSStrings?

2009-02-22 Thread Graham Cox



On 23/02/2009, at 9:38 AM, Ken Ferry wrote:

Yes, I'm sure. :-) You won't get the subpixel font smoothing right,  
if nothing else.



Are you saying that using a shadow attribute turns off or interferes  
with subpixel font smoothing? That seems a bit strange.


--Graham


___

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

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

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

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

Re: How to get the "white shadow" effect when drawing NSStrings?

2009-02-22 Thread Ken Ferry

Yes, I'm sure. :-) You won't get the subpixel font smoothing right, if
nothing else.
Also, the other method tracks whatever the current human interface design is
for text on a raised surface.

-Ken

On Sun, Feb 22, 2009 at 2:16 PM, Graham Cox  wrote:

>
> On 23/02/2009, at 4:43 AM, Ken Ferry wrote:
>
>  This effect cannot be implemented with text attributes.
>>
>
>
> Are you sure? This gets awfully close, unless I'm missing the point here
> (the font to use your choice):
>
> + (NSDictionary*)   defaultTitleAttributes
> {
>// return the dictionary used to specify the attributes for drawing
> the title string in the palette windows. Override to
>// customize the title string
>
>static NSDictionary*sTitleAttrs = nil;
>
>if ( sTitleAttrs == nil )
>{
>NSFont* font = [NSFont boldSystemFontOfSize:11.0];
>NSMutableParagraphStyle* style = [[NSParagraphStyle
> defaultParagraphStyle] mutableCopy];
>
>[style setAlignment:NSCenterTextAlignment];
>
>NSShadow* shadw = [[NSShadow alloc] init];
>
>[shadw setShadowColor:[NSColor whiteColor]];
>[shadw setShadowOffset:NSMakeSize( 0, -1.5 )];
>[shadw setShadowBlurRadius:1.0];
>
>sTitleAttrs = [NSDictionary
> dictionaryWithObjectsAndKeys:font,NSFontAttributeName,
>
>  style,NSParagraphStyleAttributeName,
>
>  shadw, NSShadowAttributeName,
>
>  nil];
>[sTitleAttrs retain];
>[style release];
>[shadw release];
>}
>
>return sTitleAttrs;
> }
>
>
>
> --Graham
>
>
>
___

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

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

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

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

Re: How to get the "white shadow" effect when drawing NSStrings?

2009-02-22 Thread Graham Cox



On 23/02/2009, at 4:43 AM, Ken Ferry wrote:


This effect cannot be implemented with text attributes.



Are you sure? This gets awfully close, unless I'm missing the point  
here (the font to use your choice):


+ (NSDictionary*)   defaultTitleAttributes
{
	// return the dictionary used to specify the attributes for drawing  
the title string in the palette windows. Override to

// customize the title string

static NSDictionary*sTitleAttrs = nil;

if ( sTitleAttrs == nil )
{
NSFont* font = [NSFont boldSystemFontOfSize:11.0];
		NSMutableParagraphStyle* style = [[NSParagraphStyle  
defaultParagraphStyle] mutableCopy];


[style setAlignment:NSCenterTextAlignment];

NSShadow* shadw = [[NSShadow alloc] init];

[shadw setShadowColor:[NSColor whiteColor]];
[shadw setShadowOffset:NSMakeSize( 0, -1.5 )];
[shadw setShadowBlurRadius:1.0];

		sTitleAttrs = [NSDictionary  
dictionaryWithObjectsAndKeys:font,NSFontAttributeName,


style,NSParagraphStyleAttributeName,
shadw, 
NSShadowAttributeName,
nil];
[sTitleAttrs retain];
[style release];
[shadw release];
}

return sTitleAttrs;
}



--Graham


___

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

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

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

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

Re: Name to PSN

2009-02-22 Thread Pierce Freeman

Very true, very true.  Is the dock considered an agent (or daemon) anyway?
It is on the screen, but I don't think I'd classify it as an application.
It's kind of confusing. @_@

Pierce

On 2/22/09 1:46 PM, "Kyle Sluder"  wrote:

> On Sun, Feb 22, 2009 at 3:37 PM, Pierce Freeman
>  wrote:
>> As I said above, I'm just not sure.  If it's an application an Apple Event
>> probably will work, but if it's a daemon (as you pointed out) it probably
>> won't.
> 
> Don't forget that there are also "agents".  See
> http://developer.apple.com/technotes/tn2005/tn2083.html for more info.
> 
> --Kyle Sluder

___

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

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

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

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

Re: Programmatically opening an NSComboBox list

On Sat, Feb 21, 2009 at 7:17 AM, Peter Hudson  wrote:
> I notice from the docs that the button and text field are encapsulated in an
> NSComboBoxCell.  Have checked the cell docs - can't see any means to get to
> the button.

Probably because there is no "button", per se.  Unlike views, which
exist in a hierarchy and are accessible as such, cells are much more
lightweight beasts.  Often times (NSTableView being a great example),
the cell doesn't actually exist in any way related to the view, but it
simply used to draw the view's content.  In NSTableView's case, the
table view takes care of things related to the overall view, like what
portion of the view is visible, and just uses each column's cell to
draw the contents of each row.

In short, the relationship between views and visible on-screen objects
is *much* tighter than that between cells and on-screen objects.

--Kyle Sluder
___

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

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

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

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

Re: Programmatically opening an NSComboBox list

On Sat, Feb 21, 2009 at 11:11 AM, Paul Sanders  wrote:
> And indeed how do you programatically close it, which is what I would like
> to do.

The problem with programmatically closing the drop-down comes from the
way that NSComboBoxCell might handle mouse tracking.  If the cell runs
the runloop itself in its own tracking mode, your code will never even
get the opportunity to execute until the user closes the menu himself.

--Kyle Sluder
___

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

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

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

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

Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock).

2009-02-22 Thread Ken Ferry

It sounds like you got the idea choosing to lock the context rather than
using multiple contexts would be more efficient, though harder to write.
That was not the intent of the warning.  CoreData is designed with threading
in mind, but not by sharing objects between threads.  The caution is saying
that the separate-contexts-for-separate-threads approach is likely
to outperform and be easier to write than the context locking approach
unless you're in very specific situations.

Memory accessed by multiple threads is the enemy of multithreaded
performance and correctness.  The multiple-contexts approach isolates the
sharing to a well controlled layer in the store.

-Ken

On Sun, Feb 22, 2009 at 12:46 PM, Luke Evans  wrote:

> Indeed.
>
> I certainly saw all the references you highlight, many times.  I am not
> saying there aren't warnings, and true, "suckered" implies an act of
> inducement on the part of the documentation, which certainly is not there.
>
> However,
> "If you try to pass actual objects, share contexts between threads, and so
> on, you must be *extremely* careful about locking (and as a consequence you
> are likely to negate any benefit you may otherwise derive from
> multi-threading)."
> (and the others) told me that I was choosing an option that required
> programmer discipline - perhaps a harder path, but one that remained
> practical if you were willing to be liturgical about locking.
>
> My discovery (and life is full of them, so nothing particularly unusual
> here) is that the practicality of doing the locking appears to 'tip over' if
> you have binding to your Core Data.  I have my main thread, and one
> background thread trawling for files - both scrupulously locked on the MOC
> around _any_ access, i.e. even reading a property.  At the time, I
> considered this to be conformant to the documentation that strongly
> discourages the approach but nevertheless discusses it while warning about
> the need for locking diligence... but you live and learn.  AFAICS, locking
> the MOC like this does seem to be at least a viable option (saying nothing
> of its ergonomics) if you don't use binding to UI controls.  There's perhaps
> yet more locking you can do in various UI-related hooks that would yet make
> this work, but I think the code torture level really crosses an acceptable
> threshold somewhere along that line (I had the briefest look at how to get
> in between the MOC signaling KVO notifications and the controllers updating
> the UI).
>
> If I have a enduring comment about the relevant docs, it would be that I
> wouldn't have tried to use this technique in the first place if I had read
> that it was essentially incompatible with binding.  That would have overcome
> what was, in retrospect, taking the warnings too lightly.  Still, you can't
> practically expect docs to universally dot every 'i' and cross every 't'.
>  Thankfully, we have mailing lists and the like.
>
> Anyway, life moves fast and so does code - now that I'm educated, despite
> what you might think was a blind impetuousness to use a feature that was
> "strongly discouraged", my code is having all its Core Data access done on
> the main thread.
>
> -- lwe
>
>
>
> On 21-Feb-09, at 7:47 PM, mmalc Crawford wrote:
>
>
>> On Feb 20, 2009, at 3:25 PM, Luke Evans wrote:
>>
>>  OK, that's too bad.  I was suckered into thinking that following a
>>> locking regime (one of the suggested "how to use Core Data in a
>>> multithreaded environment" approaches) would allow things to work
>>> satisfactorily and provide the freedom to mutate the model on any thread so
>>> long as MOC level locking was done diligently.
>>>
>>>  It's not clear how you might get "suckered" into following a locking
>> regime -- the documentation consistently discourages this approach, e.g.:
>>
>> "If you try to pass actual objects, share contexts between threads, and so
>> on, you must be *extremely* careful about locking (and as a consequence you
>> are likely to negate any benefit you may otherwise derive from
>> multi-threading)."
>> <
>> http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdMultiThreading.html
>> >
>> (Emphasis in original.)
>>
>> It immediately goes on in a similar vein to the rest of the article:
>> "Working with a managed object across different threads is therefore
>> strongly discouraged..."
>>
>>  I have to say that I was surprised to find that simply asking executing a
>>> fetch request caused the MOC to hijack my call and go off to write to
>>> controllers, but I suppose that has to happen in order to ensure the
>>> correctness of my result (in case there are pending changes in the
>>> controller - though wouldn't that be a _read_?
>>>
>>>
>> "Thread Safety Fundamentals
>> There are several issues to bear in mind when using multi-threading in a
>> Core Data application:
>>
>> • Any time you manipulate or access your object graph, you may be using
>> the associated managed object context.
>> Core Data does not pr

Re: Name to PSN

On Sun, Feb 22, 2009 at 3:37 PM, Pierce Freeman
 wrote:
> As I said above, I'm just not sure.  If it's an application an Apple Event
> probably will work, but if it's a daemon (as you pointed out) it probably
> won't.

Don't forget that there are also "agents".  See
http://developer.apple.com/technotes/tn2005/tn2083.html for more info.

--Kyle Sluder
___

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

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

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

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

Re: How to get strings like for all objects

2009-02-22 Thread Clark Cox

On Sun, Feb 22, 2009 at 6:22 AM, Paul Sanders  wrote:
> Try %p.  Not sure if this works in 64 bit code.

FYI: %p is part of the C Standard and is guaranteed to work regardless
of the size of a pointer.

-- 
Clark S. Cox III
clarkc...@gmail.com
___

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

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

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

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

Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock).

2009-02-22 Thread Luke Evans


Indeed.

I certainly saw all the references you highlight, many times.  I am  
not saying there aren't warnings, and true, "suckered" implies an act  
of inducement on the part of the documentation, which certainly is not  
there.


However,
"If you try to pass actual objects, share contexts between threads,  
and so on, you must be *extremely* careful about locking (and as a  
consequence you are likely to negate any benefit you may otherwise  
derive from multi-threading)."
(and the others) told me that I was choosing an option that required  
programmer discipline - perhaps a harder path, but one that remained  
practical if you were willing to be liturgical about locking.


My discovery (and life is full of them, so nothing particularly  
unusual here) is that the practicality of doing the locking appears to  
'tip over' if you have binding to your Core Data.  I have my main  
thread, and one background thread trawling for files - both  
scrupulously locked on the MOC around _any_ access, i.e. even reading  
a property.  At the time, I considered this to be conformant to the  
documentation that strongly discourages the approach but nevertheless  
discusses it while warning about the need for locking diligence... but  
you live and learn.  AFAICS, locking the MOC like this does seem to be  
at least a viable option (saying nothing of its ergonomics) if you  
don't use binding to UI controls.  There's perhaps yet more locking  
you can do in various UI-related hooks that would yet make this work,  
but I think the code torture level really crosses an acceptable  
threshold somewhere along that line (I had the briefest look at how to  
get in between the MOC signaling KVO notifications and the controllers  
updating the UI).


If I have a enduring comment about the relevant docs, it would be that  
I wouldn't have tried to use this technique in the first place if I  
had read that it was essentially incompatible with binding.  That  
would have overcome what was, in retrospect, taking the warnings too  
lightly.  Still, you can't practically expect docs to universally dot  
every 'i' and cross every 't'.  Thankfully, we have mailing lists and  
the like.


Anyway, life moves fast and so does code - now that I'm educated,  
despite what you might think was a blind impetuousness to use a  
feature that was "strongly discouraged", my code is having all its  
Core Data access done on the main thread.


-- lwe


On 21-Feb-09, at 7:47 PM, mmalc Crawford wrote:



On Feb 20, 2009, at 3:25 PM, Luke Evans wrote:

OK, that's too bad.  I was suckered into thinking that following a  
locking regime (one of the suggested "how to use Core Data in a  
multithreaded environment" approaches) would allow things to work  
satisfactorily and provide the freedom to mutate the model on any  
thread so long as MOC level locking was done diligently.


It's not clear how you might get "suckered" into following a locking  
regime -- the documentation consistently discourages this approach,  
e.g.:


"If you try to pass actual objects, share contexts between threads,  
and so on, you must be *extremely* careful about locking (and as a  
consequence you are likely to negate any benefit you may otherwise  
derive from multi-threading)."


(Emphasis in original.)

It immediately goes on in a similar vein to the rest of the article:
"Working with a managed object across different threads is therefore  
strongly discouraged..."


I have to say that I was surprised to find that simply asking  
executing a fetch request caused the MOC to hijack my call and go  
off to write to controllers, but I suppose that has to happen in  
order to ensure the correctness of my result (in case there are  
pending changes in the controller - though wouldn't that be a _read_?




"Thread Safety Fundamentals
There are several issues to bear in mind when using multi-threading  
in a Core Data application:


• Any time you manipulate or access your object graph, you may be  
using the associated managed object context.
Core Data does not present a situation where reads are "safe" but  
changes are "dangerous"—every operation is "dangerous" because every  
operation can trigger faulting."




mmalc





___

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

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

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

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

Re: Name to PSN

2009-02-22 Thread Pierce Freeman

> Is there one specific application that you will be quitting?  You can
> look into its application bundle at its Info.plist file to get its
> bundle ID.

It's not a application per say, but a daemon.  At least I think... It's
rather confusing.  You see, the dock is a daemon (I think) but there is an
application in Core Services that is Dock.app

> As I recall, you were planning to send a "quit" Apple Event to the
> process to ask it to quit.  Are you sure it will respond to such an
> event?  If it's a BSD-level tool or daemon or the like, it very likely
> won't.  If it's an LSUIElement application, then it probably will.

As I said above, I'm just not sure.  If it's an application an Apple Event
probably will work, but if it's a daemon (as you pointed out) it probably
won't.

> In addition to the documentation that Jerry Krinock referred you to,
> you might want to read this technote
> > , especially the caveats regarding Process Serial Number-based APIs.

Okay Ken, I'll look into it...


___

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

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

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

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

iPhone MPMoviePlayerController stops iPod

2009-02-22 Thread Sebastian Morsch

I tried to implement a short modal and full-screen animation with  
MPMoviePlayerController within my application. It is only meant as a  
nice transition between two different working modes of the app.  
Understandably, playing a movie with MPMoviePlayerController pauses  
music playback of the iPod app, but this is not what I want. My  
application doesn't even use sound, so it feels totally weird for the  
user when his/her music just stops.


Does anyone have an idea how I can work around this?


Thanks!
Sebastian
___

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

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

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

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

Re: Creating Subclass in Core Data

2009-02-22 Thread Volker in Lists

Hi Paul,

I recommend not use the add: / addChild: methods of the
TreeController, but create yur own methods for that. In each
instantiate an object of the entitytype you want as parent/child. See http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/CoreData/Articles/cdCreateMOs.html#/
/apple_ref/doc/uid/TP40001654 for how to create objects in code. Set
the proper parent objects , that is nil for "parents" and the parent
entity for the children.

I have the same solution in a couple of apps with exactly the same
structure and needs as I gather you have.

Cheers,
Volker

Am 22.02.2009 um 20:19 schrieb Paul Franz:

I have a simple class hierarchy defined in Model for the Core Data
Entity:

Class: AbstractClass (Abstract Class is checked as abstract
Parent Class: None
Attributes:
Name
Children

Class: Class1
Parent Class: AbstractClass
Attributes: None

Class: Class2
Parent Class: AbstractClass
Attributes:
Description
Cost

How do I create a subclass of Class1 or Class2 instead of the
abstract class AbstractClass?

I have created a NSTreeController in IB. The Attributes tab for the
NSTreeController, the Key Paths (Children) is set to "Children" and
Object Controller (Mode) is set to "Entity" with the Entity Name is
set to "AbtractClass". I have a NSOutlineView which is bound to this
NSTreeController. And a "New" button to create a new entity is bound
to the "add" method of the NSTreeController and a "New Child" button
to create a new child is bound to the "addChild" method of the
NSTreeController. It seems to work. But I have no idea what types of
entities are being created. My assumption is that they are of type
"AbstractClass".

Paul Franz
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/volker_lists%40ecoobs.de

This email sent to volker_li...@ecoobs.de

___

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

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

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

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

Creating Subclass in Core Data

2009-02-22 Thread Paul Franz


I have a simple class hierarchy defined in Model for the Core Data Entity:

Class: AbstractClass (Abstract Class is checked as abstract
Parent Class: None
Attributes:
   Name
   Children

Class: Class1
Parent Class: AbstractClass
Attributes: None

Class: Class2
Parent Class: AbstractClass
Attributes:
   Description
   Cost

How do I create a subclass of Class1 or Class2 instead of the abstract class 
AbstractClass?


I have created a NSTreeController in IB. The Attributes tab for the 
NSTreeController, the Key Paths (Children) is set to "Children" and Object 
Controller (Mode) is set to "Entity" with the Entity Name is set to 
"AbtractClass". I have a NSOutlineView which is bound to this NSTreeController. 
And a "New" button to create a new entity is bound to the "add" method of the 
NSTreeController and a "New Child" button to create a new child is bound to the 
"addChild" method of the NSTreeController. It seems to work. But I have no idea 
what types of entities are being created. My assumption is that they are of type 
"AbstractClass".


Paul Franz
___

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

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

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

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

Re: Small animation inside NSCell (progress bar)

2009-02-22 Thread Andy Lee


On Feb 22, 2009, at 1:18 PM, malcom wrote:

Hello,
I'm working on a subclass of NSCell that draws a custom style  
progress bar.

Everything works fine, it draws correctly and I've made the code to
make indeterminate animation (the method should be called by a timer).
So I've created a NSTimer in my NSCell subclass, but when I try to run
the program itself it only animates the last row of the table. In fact
seems only a timer is created (while I'm pretty sure that each NSCell
displayed is a different subclass because it display correctly
different data).
What's the problem in here?


I assume you mean "different instance" rather than "different  
subclass," in which case you need to know there actually *isn't* a  
different cell instance for each row.  There is one cell instance per  
column and the cell is reused as needed to draw each row.  I suspect  
that's your problem.



... However my big question is another. If I can get this method
working I'll have n timers for n cell istances that draw a short
portion of the entire tableview. It seems to be pretty expensive... so
what? What's the correct way to update only "indeterminate" cells with
a single timer? Is there a better way.


Just off the top of my head... rather than tie the timer to the cell,  
I wonder if having a timer that tells the table view to  
setNeedsDisplay:YES would work.  This would force it to redraw all its  
cells when the timer fires.  Feels like there should be a better  
solution, but again this is off the top of my head.


--Andy




The code below is my class.



#define DEFAULT_PROGRESSBAR_LEN 100
#define DEFAULT_PROGRESSBAR_HEG 12

@implementation WGUICell_ProgressBar

- (id) init
{
self = [super init];
if (self != nil) {
[self setIndeterminate: YES];
_bar_width = DEFAULT_PROGRESSBAR_LEN;
_bar_height = DEFAULT_PROGRESSBAR_HEG;
_bar_includeCloseButton = YES;
_bar_maxValue = 100.0;
_bar_currentValue = 75.0;
}
return self;
}

- (void) setDoubleValue:(double) _val {
if (_val > _bar_maxValue) _val = _bar_maxValue;
_bar_currentValue = _val;
}

- (void) setMaxValue:(double) _max {
_bar_maxValue = _max;
}

- (BOOL) isIndetermimate {
return _indeterminate;
}

- (void) setIndeterminate:(BOOL) _ind {
_indeterminate = _ind;
if (!_ind) {
[_timer invalidate];
} else {
_stepOfIndeterminate = 0;
_timer = [[NSTimer scheduledTimerWithTimeInterval:2

   target:self

 selector:@selector(_updateIndeterminateProgress)

 userInfo:nil repeats:YES] retain];
		[ ((WGUITorrents_Table*)[self controlView])  
_changeProgressBarsStyle];


}
}

#define BAR_WIDTH 100

- (NSRect) progressBarRect {
return _barRect;
}

- (void) _updateIndeterminateProgress {
NSLog(@"refresh %@",self);
[[self controlView] setNeedsDisplayInRect: _barRect];
//  [[self controlView] setNeedsDisplay: YES];

_stepOfIndeterminate++;
}

- (void) setRepresentedObject:(id) _obj forColumn:(NSTableColumn *)  
_col {

[_representedObj release];
_representedObj = [_obj retain];
}


- (void)drawWithFrame:(NSRect)cellFrame inView:(NSView *)controlView {

// the point where the progress bar starts
	NSPoint originBar = NSMakePoint(cellFrame.origin.x+75,  
cellFrame.origin.y+19);


// draw bar itself
NSImage *backgroundStructure = [self _createProgressBarStructure];
NSRect barRect = NSMakeRect(originBar.x, originBar.y, BAR_WIDTH, 12);
_barRect = barRect;
[backgroundStructure drawInRect: barRect fromRect:NSZeroRect
operation:NSCompositeSourceOver fraction:1.0];

if (!_indeterminate) {  
		NSImage *progression_value = [self  
_drawDeterminateProgressBarValue: barRect];

NSRect _fillRect = NSMakeRect(originBar.x, originBar.y,
[progression_value size].width, _bar_height);
[progression_value setFlipped:YES]; 
[progression_value drawInRect: _fillRect
			 fromRect:NSZeroRect operation:NSCompositeSourceOver fraction: 
1.0];

} else {
NSImage *indeterminateProgression = [self _drawIndetermination];
NSRect _fillRect = NSMakeRect(originBar.x+1, originBar.y+1,
[indeterminateProgression size].width, [indeterminateProgression
size].height);
[indeterminateProgression setFlipped:YES];  
[indeterminateProgression drawInRect: _fillRect
	fromRect:NSZeroRect operation:NSCompositeSourceOver  
fracti

Re: NSNotificationCenter : multiple messages sent tothe same observer?

2009-02-22 Thread Paul Sanders

I think the second call to addObserver should fail, perhaps even throw an 
exception.  It's almost certainly a programming error.  Just my $0.02 worth.

But it's probably too late to change the behaviour now, if it might break 
somebody's app.

- Original Message - 
From: "Iceberg-Dev" 
To: "Cocoa-dev List" 
Sent: Sunday, February 22, 2009 6:23 PM
Subject: Re: NSNotificationCenter : multiple messages sent tothe same 
observer?



On Feb 22, 2009, at 7:06 PM, Bill Bumgarner wrote:

> On Feb 22, 2009, at 9:59 AM, Iceberg-Dev wrote:
>> [...]
>>> The current behavior makes it possible to implement architectures
>>> where a client could take "more action" for any given
>>> notification by registering more than once.   Not supporting this
>>> pattern would make such a pattern significantly more inconvenient
>>> to implement.
>>>
>>> As well, any kind of a coalescing in the notification center is
>>> going to increase the complexity/overhead of the observer and, in
>>> particularly, might likely impact notification delivery speed
>>> (or, alternatively, require the notification center to use a
>>> bunch more memory to differentiate between "set of registered
>>> observers" and "list of observers that I actually deliver stuff
>>> to").
>>
>> I think it would just require to make the search once on
>> registration, not every time a notification is sent.
>
> Assuming that your statement is made in light of trying to avoid
> the bloat I alluded to in the previous paragraph, this would lead
> to some very surprising behavior.
>
> Imagine this sequence of calls...
>
> - (void)addObserver:self selector:(SEL)aSelector
> name:BobsYourUncleNotification object:(id)anObject;
> - (void)addObserver:self selector:(SEL)aSelector
> name:BobsYourUncleNotification object:(id)anObject;
> - (void)removeObserver:self name:BobsYourUncleNotification object:
> (id)anObject;
>
> If the notification center coalesced observers on registration, the
> above would mean that the notification would no longer be sent.

If anObject is the same object in the 3 calls, this is probably
already the case if I am to believe the documentation. Which is the
behavior I would expect/wish for.
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/p.sanders%40dsl.pipex.com

This email sent to p.sand...@dsl.pipex.com 

___

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

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

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

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

Re: Unexpected mouse-handling behaviour

2009-02-22 Thread Andy Lee

I'm not sure there is a problem.  If the clicked NodeView is receiving  
all the rightMouseDragged: messages, even when the mouse leaves the  
view, it would be consistent for it to receive the rightMouseUp:  
message as well.  Note that at the time the user releases the mouse,  
it might not be over any view, so it makes sense for the initially  
clicked view to handle all the events for the entire drag sequence.


If the start node and end node are guaranteed to have the same  
VSGraphView as their superview, it seems to me your code should still  
work, since that superview will still get the setEndPoint message.


--Andy

On Feb 22, 2009, at 9:21 AM, Manuel Meyer wrote:


Hey,

I just started to learn obj-c/Cocoa. As my first application I am  
writing a networkgraph-editor. Each node got it own view.
To connect to nodes, I thought of using rightMouseDown,  
rightMouseDragged and rightMouseUp.
So the NodeView, where a rightMouseDown event is triggered will be  
the starting-node for the connection and those NodeView, where the  
rightMouseUp event is triggered, will be the end-node.  
rightMouseDragged is used to show a line as visual feedback.


But I got another behaviour: the rightMouseUp-event will allways be  
triggered on the first node, no matter if the mouse was moved to  
another or to no NodeView.


What is my mistake?

Here is my code: http://paste.lisp.org/display/75958
Thanks for your help,

Manuel
___

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

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

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

This email sent to ag...@mac.com



aglee



___

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

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

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

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

Re: NSNotificationCenter : multiple messages sent to the same observer?


On Feb 22, 2009, at 10:23 AM, Iceberg-Dev wrote:
If the notification center coalesced observers on registration, the  
above would mean that the notification would no longer be sent.


If anObject is the same object in the 3 calls, this is probably  
already the case if I am to believe the documentation. Which is the  
behavior I would expect/wish for.


And you'd be correct.  I tested it (see below).

[Session started at 2009-02-22 10:43:24 -0800.]
2009-02-22 10:43:24.137 foobar[11347:10b] Notif: {
times = 2;
}
2009-02-22 10:43:24.142 foobar[11347:10b] Notif: {
times = 2;
}

The Debugger has exited with status 0.

So... it'd appear that NSNotificationCenter is implemented entirely  
around being as small and fast as possible.  "Remove" removes  
everything matching and "add" adds without consideration.   No stack  
or reference counting involved.


And you are correct that the documentation says that: "Removes  
matching entries from the receiver’s dispatch table."  Which, given  
the minimal and similar description on -addObserver: would imply that  
it adds the same without consideration for what is already in the  
center.


b.bum
(The code below assumes GC is on, obviously.  And it is only written  
to test the question at hand -- not to even remotely be a correct  
pattern of implementation).


#import 

#define BobsYourUncle @"BobsYourUncle"

@interface Foo: NSObject

@end

@implementation Foo
- (void) bob: (NSNotification *) aNotif
{
NSLog(@"Notif: %@", [aNotif userInfo]);
}

- init
{
NSNotificationCenter *dc = [NSNotificationCenter defaultCenter];
NSNotification *n;
[super init];
[dc addObserver:self selector:@selector(bob:) name:BobsYourUncle  
object:self];
[dc addObserver:self selector:@selector(bob:) name:BobsYourUncle  
object:self];
n = [NSNotification notificationWithName:BobsYourUncle  
object:self userInfo: [NSDictionary dictionaryWithObject:@"2"  
forKey:@"times"]];

[dc postNotification: n];
[dc removeObserver:self name:BobsYourUncle object:self];
n = [NSNotification notificationWithName:BobsYourUncle  
object:self userInfo: [NSDictionary dictionaryWithObject:@"1"  
forKey:@"times"]];

[dc postNotification: n];
return self;
}
@end

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


___

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

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

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

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

Re: immutable collection given to mutating function error


On Feb 22, 2009, at 11:17 AM, Michael Domino wrote:

I have a situation where I'm writing a preferences file and I have a  
major section and one or more minor sections, like this:


Settings
Logging
Initialization

Everything actually works fine, except that I get this error when  
writing a minor section:


2009-02-22 10:10:56.466 Identity Finder[40754:813]  
CFDictionarySetValue(): immutable collection 0x11ad8f0 given to  
mutating function


[...]

The question is: does CFDictionaryGetValueIfPresent always return an  
immutable object


No.  It returns the value that's in the dictionary.

and is there another api call that will return a mutable dictionary?  
Am I doing this the wrong way?


The problem isn't in how you're getting stuff out of your dictionary,  
it's how the dictionary is created and filled.  I suspect you're using  
the CFPropertyList or CFPreferences APIs, which by default give you  
immutable object graphs.


By the way, none of this is Cocoa-specific.  Perhaps Cocoa-Dev isn't  
the best list for this.


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

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

Obtaining Display EDID (DDC) Information From User Level App

2009-02-22 Thread Tobias Zimmerman

Apologies if this is the wrong forum  I am not entirely sure what category
this question properly falls under.  If someone suggests a better list, I
will move the question there.

I want to obtain the name of a display (monitor) by manufacturer and brand.
Most (not all) displays report this using EDID.  Examining ³Graphics² in the
System Profiler shows that higher-level software can access this info, since
System Profiler  (And System Prefs ³Displays² pane) report it.

I have looked in bewilderment at the documentation for IOKit (IOFrameBuffer
in particular), and seen the ³getDDCBlock² function that gets the raw EDID
info.  I have no idea how to actually implement that or translate the
result.  So my question:

(1)  Is there a ³higher level² method of obtaining the brand/model of the
displays  e.g., from the system preferences?

(2)  Does anyone have an example of code that they are willing to share that
shows accessing the EDID info?

Thanks, and apologies if I am spamming the wrong list here.

(Note, I am aware of the CGVendorNumber and CGModelNumber functions.  If
someone knows a header file or similar that translates the numbers to actual
names, that would work too, but AFAICT, these functions only return code
numbers).
___

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

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

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

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

Re: Question on threads running in my Foundation tool


On Feb 22, 2009, at 11:35 AM, Charles E. Heizer wrote:

I reworked my test app so that I could isolate the threads and to  
see what's going on a little better, and I'm now using a NSTimer and  
a NSRunLoop. The issue I'm seeing is that for every time I call  
NSThread so not to block the run loop it runs it's course but when  
it completes it leaves a hanging thread. So every 60 seconds I see  
an additional thread get added and never drops it once completed.


You don't need to use a secondary thread to avoid blocking the main  
thread when you use an NSTask.  Just don't use the blocking methods of  
NSTask or NSFileHandle; use the asynchronous versions.


That is, don't invoke -[NSFileHandle readDataToEndOfFile].  Register  
for the NSFileHandleReadToEndOfFileCompletionNotification notification  
and invoke -readToEndOfFileInBackgroundAndNotify.  Similarly, don't  
invoke -[NSTask waitUntilExit].  Register for the  
NSTaskDidTerminateNotification notification.


If you decide to continue using a secondary thread, try invoking - 
[NSTask waitUnitExit] after you've read the task's output.  I believe  
that NSTask needs the run loop of the thread from which it is launched  
to run in order for it to detect the termination of the task, deliver  
its notification, and perform some housekeeping cleanup.  The fact  
that you're not running the run loop of the thread is the reason it's  
failing to clean up.  The -waitUntilExit method runs the run loop, so  
it should be sufficient.


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

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

Re: Programmatically opening an NSComboBox list

2009-02-22 Thread Andy Lee


On Feb 21, 2009, at 11:11 AM, Paul Sanders wrote:
And a question: is there a utility, similar to Spy++ under windows,  
Which
can show you the window and view hierarchy of a running app?  I find  
Spy++

extremely useful on occasion when doing Windows development.


I think F-Script can do that.

--Andy


___

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

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

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

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

Re: NSNotificationCenter : multiple messages sent to the same observer?

2009-02-22 Thread Iceberg-Dev



On Feb 22, 2009, at 7:06 PM, Bill Bumgarner wrote:


On Feb 22, 2009, at 9:59 AM, Iceberg-Dev wrote:

[...]
The current behavior makes it possible to implement architectures  
where a client could take "more action" for any given  
notification by registering more than once.   Not supporting this  
pattern would make such a pattern significantly more inconvenient  
to implement.


As well, any kind of a coalescing in the notification center is  
going to increase the complexity/overhead of the observer and, in  
particularly, might likely impact notification delivery speed  
(or, alternatively, require the notification center to use a  
bunch more memory to differentiate between "set of registered  
observers" and "list of observers that I actually deliver stuff  
to").


I think it would just require to make the search once on  
registration, not every time a notification is sent.


Assuming that your statement is made in light of trying to avoid  
the bloat I alluded to in the previous paragraph, this would lead  
to some very surprising behavior.


Imagine this sequence of calls...

- (void)addObserver:self selector:(SEL)aSelector  
name:BobsYourUncleNotification object:(id)anObject;
- (void)addObserver:self selector:(SEL)aSelector  
name:BobsYourUncleNotification object:(id)anObject;
- (void)removeObserver:self name:BobsYourUncleNotification object: 
(id)anObject;


If the notification center coalesced observers on registration, the  
above would mean that the notification would no longer be sent.


If anObject is the same object in the 3 calls, this is probably  
already the case if I am to believe the documentation. Which is the  
behavior I would expect/wish for.

___

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

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

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

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

Re: How to get strings like for all objects


On Feb 22, 2009, at 9:02 AM, Jean-Daniel Dupas wrote:


Le 22 févr. 09 à 15:14, Ken Tozier a écrit :


Hi

I need to get unique identifiers for all objects I'm passed for use  
as keys in an NSMutableDictionary. I tried using hash but I don't  
know if that would really be unique. It seems like the console  
printout for classes with no "description" method would be perfect.  
I know how to get the class but how to get the object address in  
hex? Here's a partial solution


[NSString stringWithFormat: @"<%@ %???>", [[someObject class]  
description], someObject];


Is there a format code that would give me the address in hex?

Thanks for any help



Why you don't use the object directly as key instead of a generated  
string  ?
If this is the "copy key" behavior of the dictionary that bother  
you, you can either use the CoreFoundation API and use  
kCFTypeDictionaryKeyCallBacks to create your dictionary (warning: do  
not mix CF and NSDictionary call with a custom key callback, the  
NSDictionary API may call copy: whatever the callback is).

Else, you can use (as suggested by Andrew) NSHashTable or NSMapTable.


As still another option, which is convenient for Tiger deployment, you  
can use an NSValue (+[NSValue valueWithNonretainedObject:]) to make  
the object pointer the key for your dictionary.


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

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

Small animation inside NSCell (progress bar)

2009-02-22 Thread malcom

Hello,
I'm working on a subclass of NSCell that draws a custom style progress bar.
Everything works fine, it draws correctly and I've made the code to
make indeterminate animation (the method should be called by a timer).
So I've created a NSTimer in my NSCell subclass, but when I try to run
the program itself it only animates the last row of the table. In fact
seems only a timer is created (while I'm pretty sure that each NSCell
displayed is a different subclass because it display correctly
different data).
What's the problem in here?
... However my big question is another. If I can get this method
working I'll have n timers for n cell istances that draw a short
portion of the entire tableview. It seems to be pretty expensive... so
what? What's the correct way to update only "indeterminate" cells with
a single timer? Is there a better way.
The code below is my class.



#define DEFAULT_PROGRESSBAR_LEN 100
#define DEFAULT_PROGRESSBAR_HEG 12

@implementation WGUICell_ProgressBar

- (id) init
{
self = [super init];
if (self != nil) {
[self setIndeterminate: YES];
_bar_width = DEFAULT_PROGRESSBAR_LEN;
_bar_height = DEFAULT_PROGRESSBAR_HEG;
_bar_includeCloseButton = YES;
_bar_maxValue = 100.0;
_bar_currentValue = 75.0;
}
return self;
}

- (void) setDoubleValue:(double) _val {
if (_val > _bar_maxValue) _val = _bar_maxValue;
_bar_currentValue = _val;
}

- (void) setMaxValue:(double) _max {
_bar_maxValue = _max;
}

- (BOOL) isIndetermimate {
return _indeterminate;
}

- (void) setIndeterminate:(BOOL) _ind {
_indeterminate = _ind;
if (!_ind) {
[_timer invalidate];
} else {
_stepOfIndeterminate = 0;
_timer = [[NSTimer scheduledTimerWithTimeInterval:2

   target:self

 selector:@selector(_updateIndeterminateProgress)

 userInfo:nil repeats:YES] retain];
[ ((WGUITorrents_Table*)[self controlView]) 
_changeProgressBarsStyle];

}
}

#define BAR_WIDTH 100

- (NSRect) progressBarRect {
return _barRect;
}

- (void) _updateIndeterminateProgress {
NSLog(@"refresh %@",self);
[[self controlView] setNeedsDisplayInRect: _barRect];
//  [[self controlView] setNeedsDisplay: YES];

_stepOfIndeterminate++;
}

- (void) setRepresentedObject:(id) _obj forColumn:(NSTableColumn *) _col {
[_representedObj release];
_representedObj = [_obj retain];
}


- (void)drawWithFrame:(NSRect)cellFrame inView:(NSView *)controlView {

// the point where the progress bar starts
NSPoint originBar = NSMakePoint(cellFrame.origin.x+75, 
cellFrame.origin.y+19);

// draw bar itself
NSImage *backgroundStructure = [self _createProgressBarStructure];
NSRect barRect = NSMakeRect(originBar.x, originBar.y, BAR_WIDTH, 12);
_barRect = barRect;
[backgroundStructure drawInRect: barRect fromRect:NSZeroRect
operation:NSCompositeSourceOver fraction:1.0];

if (!_indeterminate) {  
NSImage *progression_value = [self 
_drawDeterminateProgressBarValue: barRect];
NSRect _fillRect = NSMakeRect(originBar.x, originBar.y,
[progression_value size].width, _bar_height);
[progression_value setFlipped:YES]; 
[progression_value drawInRect: _fillRect
 fromRect:NSZeroRect 
operation:NSCompositeSourceOver fraction:1.0];
} else {
NSImage *indeterminateProgression = [self _drawIndetermination];
NSRect _fillRect = NSMakeRect(originBar.x+1, originBar.y+1,
[indeterminateProgression size].width, [indeterminateProgression
size].height);
[indeterminateProgression setFlipped:YES];  
[indeterminateProgression drawInRect: _fillRect

fromRect:NSZeroRect operation:NSCompositeSourceOver fraction:1.0];
}


}

- (NSImage *) _drawIndetermination {
NSImage *_double_prog = [[NSImage alloc] initWithSize: NSMakeSize(
(_bar_width*2)-2, _bar_height-2)];
[_double_prog lockFocus];
[[NSColor colorWithPatternImage: [NSImage
imageNamed:@"ind_progressbar.png"]] set];
NSBezierPath *p =[NSBezierPath bezierPathWithRect: NSMakeRect(0, 0,
(_bar_width*2)-2, _bar_height-2)];
[p fill];
[_double_prog unlockFocus];

NSImage *_portionVisible = [[NSImage alloc]
initWithSize:

immutable collection given to mutating function error

2009-02-22 Thread Michael Domino


Hi all,

I have a situation where I'm writing a preferences file and I have a  
major section and one or more minor sections, like this:


Settings
Logging
Initialization

Everything actually works fine, except that I get this error when  
writing a minor section:


2009-02-22 10:10:56.466 Identity Finder[40754:813]  
CFDictionarySetValue(): immutable collection 0x11ad8f0 given to  
mutating function


I declare these pointers:

CFMutableDictionaryRef  prefMajorSectionCFMutableDictionaryRef = 0;
CFMutableDictionaryRef  prefMinorSectionCFMutableDictionaryRef = 0;

Then I obtain their values like this (this is just for a minor section):

const void* pVoid = 0;
			Boolean present =  
CFDictionaryGetValueIfPresent(prefMajorSectionCFMutableDictionaryRef,  
minorSectionKeyCFStringRef, &pVoid);


if(!present) {
prefMinorSectionCFMutableDictionaryRef =  
CFDictionaryCreateMutable(NULL, 0, &kCFTypeDictionaryKeyCallBacks,  
&kCFTypeDictionaryValueCallBacks);

} else {
prefMinorSectionCFMutableDictionaryRef =  
static_cast(const_cast(pVoid));

}

If the section is not there and I create a new mutable CFDictionary,  
there is no error. If the section is there, I get the error.


The question is: does CFDictionaryGetValueIfPresent always return an  
immutable object and is there another api call that will return a  
mutable dictionary? Am I doing this the wrong way?


Thanks for your advice.

Michael Domino
michael.dom...@identityfinder.com





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

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

Using a flip transition to a different view

2009-02-22 Thread David Hatch


Hi,
I'm writing an app that has a view that displays subviews to show  
information to the user.  I would like the user to click a button and  
have the clicked sub view transition to a different view where the  
user can edit the information.  I want to use the transition that is  
used with dashboard widgets when the user clicks the "i" for  
preferences but, upon looking through the documentation at Core  
Animation transitions, that was not an available transition.  Is there  
a way I can use the flip transition instead of one of the four  
included transitions?





___

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

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

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

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

Re: How to get strings like for all objects

2009-02-22 Thread Paul Sanders

Try %p.  Not sure if this works in 64 bit code.

- Original Message - 
From: "Ken Tozier" 
To: "Cocoa-Dev (Apple)" 
Sent: Sunday, February 22, 2009 2:14 PM
Subject: How to get strings like  for all objects

Hi

I need to get unique identifiers for all objects I'm passed for use as  
keys in an NSMutableDictionary. I tried using hash but I don't know if  
that would really be unique. It seems like the console printout for  
classes with no "description" method would be perfect. I know how to  
get the class but how to get the object address in hex? Here's a  
partial solution

[NSString stringWithFormat: @"<%@ %???>", [[someObject class]  
description], someObject];

Is there a format code that would give me the address in hex?

Thanks for any help
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/p.sanders%40dsl.pipex.com

This email sent to p.sand...@dsl.pipex.com
___

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

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

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

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

Unexpected mouse-handling behaviour

2009-02-22 Thread Manuel Meyer


Hey,

I just started to learn obj-c/Cocoa. As my first application I am  
writing a networkgraph-editor. Each node got it own view.
To connect to nodes, I thought of using rightMouseDown,  
rightMouseDragged and rightMouseUp.
So the NodeView, where a rightMouseDown event is triggered will be the  
starting-node for the connection and those NodeView, where the  
rightMouseUp event is triggered, will be the end-node.  
rightMouseDragged is used to show a line as visual feedback.


But I got another behaviour: the rightMouseUp-event will allways be  
triggered on the first node, no matter if the mouse was moved to  
another or to no NodeView.


What is my mistake?

Here is my code: http://paste.lisp.org/display/75958
Thanks for your help,

Manuel
___

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

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

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

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

Core Data: Multiple entities in same Table View

2009-02-22 Thread Desmond


Consider two entities

1) Customer having attributes:
Name
Id
Relationship: address (Has one of more Addresses)

2) Address having attributes:
Street
City
Zip
Relationship: customer (Belongs to one or more customer)

Now I would like to have a single Table View to where I can add/ edit the
customer info and *view* (only) the address information. Let's presume that
address entry/ editing is handled through another screen. I have created
two NSArrayControllers corresponding and binded them to each entity. I am
also able to display all Customer info in the NSTableView but I am not sure
how to get address info corresponding to each customer to show up in the
Table View. I can't use "selection" as the "Controller Key" as I want each
row to display it's corresponding address not the one corresponding to the
current selection. I have also tried binding a column to "Customers"
(controller), Controller Key as "arrangedObjects" and "Model Key Path" as
"address.street" but that hasn't worked.

I am sure it's really simple, but no amount of searching/ messing around
has given me a solution. So, how do I get this to work?

Desmond
___

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

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

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

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

Re: Programmatically opening an NSComboBox list

2009-02-22 Thread Paul Sanders

And indeed how do you programatically close it, which is what I would like 
to do.

To open it, I'm guessing you might work out where the button is and post a 
mousedown / mouse up event pair with those coordinates.  A little clunky 
perhaps but it sounds like it ought to work.  Alternatively, send a 
mouseDown and then a mouseUp to the button directly.  A superview can 
enumerate its subviews so you should be able to track it down.

And hello to all at Cocoa-Dev, my first post.  Coming as I do from the 
Windows world I am finding learning Cocoa both educational and fascinating. 
Makes Win32 (and Windows Forms) look positively stoneage.  I'm just worried 
I might wear out the square bracket keys on my keyboard :)

And a question: is there a utility, similar to Spy++ under windows, Which 
can show you the window and view hierarchy of a running app?  I find Spy++ 
extremely useful on occasion when doing Windows development.

Regards,

Paul Sanders.

- Original Message - 
From: "Peter Hudson" 
To: 
Sent: Saturday, February 21, 2009 12:17 PM
Subject: Programmatically opening an NSComboBox list


Have trawled the archives and can find only a suggestion to do a
performClick on the combo ( which fails )  or an undocumented method.

I notice from the docs that the button and text field are encapsulated
in an NSComboBoxCell.  Have checked the cell docs - can't see any
means to get to the button.

I also can see no means to get to it via the NSControl subclass.

Any help / suggestions appreciated.

PH

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/p.sanders%40dsl.pipex.com

This email sent to p.sand...@dsl.pipex.com 

___

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

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

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

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

Re: Name to PSN

On Feb 21, 2009, at 10:21 PM, Pierce Freeman wrote:

Is there some panel in Activity Monitor that I'm missing that shows
you the Bundle ID of
all the processes? I am not quitting my own application (as you may
have

guessed) but I do need some way to find it for another application.

Is there one specific application that you will be quitting? You can
look into its application bundle at its Info.plist file to get its
bundle ID.

On another topic: Is there someway to have NSWorkspace show all the
processes open? Right now it is showing me the applications, but the
process that I'm targeting isn't really an application and doesn't
have an

interface.

As I recall, you were planning to send a "quit" Apple Event to the
process to ask it to quit. Are you sure it will respond to such an
event? If it's a BSD-level tool or daemon or the like, it very likely
won't. If it's an LSUIElement application, then it probably will.

In addition to the documentation that Jerry Krinock referred you to,
you might want to read this technote , especially the caveats regarding Process Serial Number-based APIs.

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

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

Re: NSNotificationCenter : multiple messages sent to the same observer?


On Feb 22, 2009, at 9:59 AM, Iceberg-Dev wrote:
Thanks for the pointer. It would be nice to have this explanation  
available in the description of the  
addObserver:selector:name:object: as it might be where one could  
expect to find it. I filed an enhancement suggestion.


But then it would have to be repeated on -postNotification: and - 
removeObserver:, etc...


The documentation, in general, tries to avoid repeating stuff. 
Always click through to the programming topic as it gives the overall  
design philosophy and usage patterns for the given class.


The current behavior makes it possible to implement architectures  
where a client could take "more action" for any given notification  
by registering more than once.   Not supporting this pattern would  
make such a pattern significantly more inconvenient to implement.


As well, any kind of a coalescing in the notification center is  
going to increase the complexity/overhead of the observer and, in  
particularly, might likely impact notification delivery speed (or,  
alternatively, require the notification center to use a bunch more  
memory to differentiate between "set of registered observers" and  
"list of observers that I actually deliver stuff to").


I think it would just require to make the search once on  
registration, not every time a notification is sent.


Assuming that your statement is made in light of trying to avoid the  
bloat I alluded to in the previous paragraph, this would lead to some  
very surprising behavior.


Imagine this sequence of calls...

- (void)addObserver:self selector:(SEL)aSelector  
name:BobsYourUncleNotification object:(id)anObject;
- (void)addObserver:self selector:(SEL)aSelector  
name:BobsYourUncleNotification object:(id)anObject;
- (void)removeObserver:self name:BobsYourUncleNotification object: 
(id)anObject;


If the notification center coalesced observers on registration, the  
above would mean that the notification would no longer be sent.


b.bum


___

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

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

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

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

Re: NSNotificationCenter : multiple messages sent to the same observer?

2009-02-22 Thread Iceberg-Dev



On Feb 22, 2009, at 6:39 PM, Bill Bumgarner wrote:


On Feb 22, 2009, at 8:59 AM, Iceberg-Dev wrote:

On Feb 22, 2009, at 1:37 AM, Michael Ash wrote:
On Sat, Feb 21, 2009 at 6:06 PM, Iceberg-Dev  
 wrote:
I just discovered something recently. If you register an  
observer with the
same name/object/selector twice, you get the notification twice  
when you

post it.

Isn't the NSNotificationCenter supposed to prevent this?


Why, is there some place in the documentation where it says that?


There isn't. But it would make sense in 99% of cases.


Actually, the behavior is documented in the Cocoa Notifications  
programming topic:
It is possible for an observer to register to receive more than  
one message for the same notification. In such a case, the  
observer will receive all messages it is registered to receive for  
the notification, but the order in which it receives them cannot  
be determined.


Thanks for the pointer. It would be nice to have this explanation  
available in the description of the addObserver:selector:name:object:  
as it might be where one could expect to find it. I filed an  
enhancement suggestion.


The current behavior makes it possible to implement architectures  
where a client could take "more action" for any given notification  
by registering more than once.   Not supporting this pattern would  
make such a pattern significantly more inconvenient to implement.


As well, any kind of a coalescing in the notification center is  
going to increase the complexity/overhead of the observer and, in  
particularly, might likely impact notification delivery speed (or,  
alternatively, require the notification center to use a bunch more  
memory to differentiate between "set of registered observers" and  
"list of observers that I actually deliver stuff to").


I think it would just require to make the search once on  
registration, not every time a notification is sent. 
___


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

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

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

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

Re: How to get the "white shadow" effect when drawing NSStrings?

2009-02-22 Thread Ken Ferry

2009/2/21 Ulai Beekam 

>
> Is there no way to do it without a cell? I ask because I'm writing my own
> custom view and need to be able to do this with NSString's drawInRect, using
> a correct font attribute. The other poster's suggestion of just using a
> white text and shifting by 1.0 does not give me the desired effect since it
> also has the net effect of making the letters look thinner.


There's nothing to stop you from using a cell to do your drawing in a custom
view.

This effect cannot be implemented with text attributes.

-Ken


>
>
> 
> > CC: cocoa-dev@lists.apple.com
> > From: bwal...@gmail.com
> > To: ulaibee...@hotmail.com
> > Subject: Re: How to get the "white shadow" effect when drawing NSStrings?
> > Date: Sat, 21 Feb 2009 06:22:25 -0500
> >
> > Use a cell to draw your text and call -setBackgroundStyle: on it with
> > the parameter NSBackgroundStyleRaised. That'll apply the exact same
> > shadow that's used on toolbar item labels. Keep in mind that this
> > method is Leopard-only.
> >
> > On 21-Feb-09, at 6:10 AM, Ulai Beekam wrote:
> >
> >>
> >> Hi,
> >>
> >> Just take a look at any toolbar text in Leopard. It has a subtle,
> >> white shadow. How can I get this very same effect in my own app when
> >> using NSString's drawInRect method? What attributes to use? Do you
> >> have any sample code?
> >>
> >> Thanks, U.
> >>
> >>
> >>
> >> _
> >> More than messages–check out the rest of the Windows Live™.
> >>
> http://www.microsoft.com/windows/windowslive/___
> >>
> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> >>
> >> Please do not post admin requests or moderator comments to the list.
> >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> >>
> >> Help/Unsubscribe/Update your Subscription:
> >> http://lists.apple.com/mailman/options/cocoa-dev/bwalkin%40gmail.com
> >>
> >> This email sent to bwal...@gmail.com
> >
>
> _
> News, entertainment and everything you care about at Live.com. Get it now!
>
> http://www.live.com/getstarted.aspx___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/kenferry%40gmail.com
>
> This email sent to kenfe...@gmail.com
>
___

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

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

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

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

Re: NSNotificationCenter : multiple messages sent to the same observer?


On Feb 22, 2009, at 8:59 AM, Iceberg-Dev wrote:

On Feb 22, 2009, at 1:37 AM, Michael Ash wrote:
On Sat, Feb 21, 2009 at 6:06 PM, Iceberg-Dev  
 wrote:
I just discovered something recently. If you register an observer  
with the
same name/object/selector twice, you get the notification twice  
when you

post it.

Isn't the NSNotificationCenter supposed to prevent this?


Why, is there some place in the documentation where it says that?


There isn't. But it would make sense in 99% of cases.


Actually, the behavior is documented in the Cocoa Notifications  
programming topic:
It is possible for an observer to register to receive more than one  
message for the same notification. In such a case, the observer will  
receive all messages it is registered to receive for the  
notification, but the order in which it receives them cannot be  
determined.


The current behavior makes it possible to implement architectures  
where a client could take "more action" for any given notification by  
registering more than once.   Not supporting this pattern would make  
such a pattern significantly more inconvenient to implement.


As well, any kind of a coalescing in the notification center is going  
to increase the complexity/overhead of the observer and, in  
particularly, might likely impact notification delivery speed (or,  
alternatively, require the notification center to use a bunch more  
memory to differentiate between "set of registered observers" and  
"list of observers that I actually deliver stuff to").


b.bum
___

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

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

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

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

RE: Question on threads running in my Foundation tool

2009-02-22 Thread Charles E. Heizer

OK,
I reworked my test app so that I could isolate the threads and to see what's 
going on a little better, and I'm now using a NSTimer and a NSRunLoop. The 
issue I'm seeing is that for every time I call NSThread so not to block the run 
loop it runs it's course but when it completes it leaves a hanging thread. So 
every 60 seconds I see an additional thread get added and never drops it once 
completed.

I'm including my source, can someone please show me how to make sure the thread 
ends when the task is completed.

thanks,
- Charles

#import 

@interface MYTestObject : NSObject {
id myObjData;
}
- (void) sayHello;
- (void) runSoftwareUpdate;
- (void) runSWThread:(id)myObjData;
- (void) setupSWInSeperateThread;
@end

@implementation MYTestObject

- (void)sayHello
{
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

NSLog(@"Hello again...");

[pool release]; 
}

-(void)runSoftwareUpdate
{
NSTask *task;
task = [[NSTask alloc] init];
[task setLaunchPath: @"/usr/sbin/softwareupdate"];

NSArray *arguments;
arguments = [NSArray arrayWithObjects: @"-l", nil];
[task setArguments: arguments];

NSPipe *pipe;
pipe = [NSPipe pipe];
[task setStandardOutput: pipe];

NSFileHandle *file;
file = [pipe fileHandleForReading];

[task launch];

NSData *data;
data = [file readDataToEndOfFile];

NSString *string;
string = [[NSString alloc] initWithData: data encoding: 
NSUTF8StringEncoding];
NSLog (@"Got a result \n%@", string);
}

- (void) runSWThread:(id)myObjData
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

[self runSoftwareUpdate];

[pool release];
}

- (void) setupSWInSeperateThread
{
[NSThread detachNewThreadSelector:@selector(runSWThread:) toTarget:self 
withObject:myObjData];
}

@end

int main (int argc, const char * argv[]) {
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

[NSTimer scheduledTimerWithTimeInterval:2 //Say Hello every 2 seconds 
 
target:[[[MYTestObject alloc] init] autorelease]
   
selector:@selector(sayHello)
   userInfo:nil

repeats:TRUE];

[NSTimer scheduledTimerWithTimeInterval:60 // Run my NSTask that I know 
spawns a few other threads
 
target:[[[MYTestObject alloc] init] autorelease]
   
selector:@selector(setupSWInSeperateThread)
   userInfo:nil

repeats:TRUE];

[[NSRunLoop currentRunLoop] run];
[pool release];
return 0;
} ___

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

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

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

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

Re: How to get strings like for all objects


On Feb 22, 2009, at 6:14 AM, Ken Tozier wrote:
I need to get unique identifiers for all objects I'm passed for use  
as keys in an NSMutableDictionary. I tried using hash but I don't  
know if that would really be unique. It seems like the console  
printout for classes with no "description" method would be perfect.  
I know how to get the class but how to get the object address in  
hex? Here's a partial solution


[NSString stringWithFormat: @"<%@ %???>", [[someObject class]  
description], someObject];


Is there a format code that would give me the address in hex?


Could you use an NSMapTable instead?

Specifically, something like:

... [NSMapTable mapTableWithKeyOptions:  
NSPointerFunctionsObjectPointerPersonality  valueOptions:  
NSPointerFunctionsObjectPersonality] ...


b.bum

___

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

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

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

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

Re: NSNotificationCenter : multiple messages sent to the same observer?

2009-02-22 Thread Iceberg-Dev



On Feb 22, 2009, at 1:37 AM, Michael Ash wrote:

On Sat, Feb 21, 2009 at 6:06 PM, Iceberg-Dev  
 wrote:
I just discovered something recently. If you register an observer  
with the
same name/object/selector twice, you get the notification twice  
when you

post it.

Isn't the NSNotificationCenter supposed to prevent this?


Why, is there some place in the documentation where it says that?


There isn't. But it would make sense in 99% of cases.
___

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

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

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

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

Re: How to get strings like for all objects

2009-02-22 Thread Jean-Daniel Dupas



Le 22 févr. 09 à 15:14, Ken Tozier a écrit :


Hi

I need to get unique identifiers for all objects I'm passed for use  
as keys in an NSMutableDictionary. I tried using hash but I don't  
know if that would really be unique. It seems like the console  
printout for classes with no "description" method would be perfect.  
I know how to get the class but how to get the object address in  
hex? Here's a partial solution


[NSString stringWithFormat: @"<%@ %???>", [[someObject class]  
description], someObject];


Is there a format code that would give me the address in hex?

Thanks for any help



Why you don't use the object directly as key instead of a generated  
string  ?
If this is the "copy key" behavior of the dictionary that bother you,  
you can either use the CoreFoundation API and use  
kCFTypeDictionaryKeyCallBacks to create your dictionary (warning: do  
not mix CF and NSDictionary call with a custom key callback, the  
NSDictionary API may call copy: whatever the callback is).

Else, you can use (as suggested by Andrew) NSHashTable or NSMapTable.





___

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

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

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

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

Re: How to get strings like for all objects

2009-02-22 Thread Ken Tozier


%p did the trick, thanks!

On Feb 22, 2009, at 9:23 AM, Andrew Farmer wrote:



@"%p" will give a string representation of the address. However, if  
you're targeting 10.5 or later, you should probably consider  
NSMapTable instead - it implements this functionality for you  
without the overhead of generating string keys.


___

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

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

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

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

Re: How to get strings like for all objects

2009-02-22 Thread Andrew Farmer


On 22 Feb 09, at 06:14, Ken Tozier wrote:
I need to get unique identifiers for all objects I'm passed for use  
as keys in an NSMutableDictionary. I tried using hash but I don't  
know if that would really be unique.


It isn't. The only requirement for -[NSObject hash] is that two  
objects which are considered equal must have the same hash. It's  
perfectly valid (albeit silly) to implement the hash method as  
returning a constant value.


It seems like the console printout for classes with no "description"  
method would be perfect. I know how to get the class but how to get  
the object address in hex? Here's a partial solution


[NSString stringWithFormat: @"<%@ %???>", [[someObject class]  
description], someObject];


Is there a format code that would give me the address in hex?


@"%p" will give a string representation of the address. However, if  
you're targeting 10.5 or later, you should probably consider  
NSMapTable instead - it implements this functionality for you without  
the overhead of generating string keys.

___

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

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

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

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

How to get strings like for all objects

2009-02-22 Thread Ken Tozier


Hi

I need to get unique identifiers for all objects I'm passed for use as  
keys in an NSMutableDictionary. I tried using hash but I don't know if  
that would really be unique. It seems like the console printout for  
classes with no "description" method would be perfect. I know how to  
get the class but how to get the object address in hex? Here's a  
partial solution


[NSString stringWithFormat: @"<%@ %???>", [[someObject class]  
description], someObject];


Is there a format code that would give me the address in hex?

Thanks for any help
___

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

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

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

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

Re: Application Activation

2009-02-22 Thread Jean-Daniel Dupas



Le 22 févr. 09 à 11:56, Gerriet M. Denkmann a écrit :


There are two ways an app can become active:
1. by explicit user action (clicking in Finder, clicking in Dock,  
using Command-Tab)

or:
2. without user action (frontmost app is closed or hidden, so the  
next app becomes active).


I would like to perform some action (like displaying an NSOpenPanel)  
in case 1 (the user wants my app to be active) but not in case 2 (my  
app becomes active by accident).


Currently I am using NSApplication delegate method  
applicationDidBecomeActive: - but this gets called in both cases.


Is there a way to diffentiate between these two cases?



You can handle reopen event (using application delegate). This event  
is send when the user try to reopen your application by double  
clicking the icon, or when it click on the Dock icon to activate your  
application.

It will not handle the cmd+tab case thought.

___

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

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

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

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

Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock).

On Sat, Feb 21, 2009 at 9:34 PM, Ken Ferry  wrote:
>
>
> On Sat, Feb 21, 2009 at 4:25 PM, Michael Ash  wrote:
>>
>> On Fri, Feb 20, 2009 at 6:25 PM, Luke Evans  wrote:
>> > The more I'm getting to know Cocoa (we're still not intimate), the more
>> > it
>> > seems that regular apps with UI making use of features like Core Data
>> > etc.
>> > need to be architected very centrally around the main thread - it's only
>> > easy/safe to use background threads for activities that perform discrete
>> > processing and post their results back to some agent waiting back on the
>> > main thread.
>>
>> Cocoa is just fine with doing lots of stuff on background threads.
>> What's not fine is doing any UI stuff on background threads.
>> Practically speaking, it means that in such a multithreaded app, when
>> you do your MVC design, the view side must be done only from the main
>> thread. The model can run on any thread (assuming a proper
>> multithreaded design there), and then your controller layer needs to
>> mediate between the two to ensure that when the UI changes the model
>> the proper synchronization is performed, and that when the model
>> performs an update that needs to be reflected in the UI, all such
>> updates are shipped back to the main thread before hitting the UI.
>>
>> The trouble you're having here is not with Cocoa, but with Cocoa
>> bindings. Bindings fit into the controller layer of MVC and have
>> absolutely *no* awareness of multithreading whatsoever. If you want to
>> multithread your model, you either need to abandon bindings (my
>> favored course of action) or bind to a layer of your model which is
>> main-thread-only, and which serves as a proxy to the multithreaded
>> section.
>
> ..which isn't so hard with CoreData, because the objects aren't shared
> between threads anyway.  The UI is bound to objects in a context opened on
> the main thread.  Other contexts may be opened on other threads, modified,
> and committed.  When the context opened on the main thread picks up the
> changes, the UI updates.

The objects are shared between threads if you're sharing them between
threads like Luke was. Of course you shouldn't do this, for the
reasons outlined in the CoreData threading documents, but that's what
he was doing.

Mike
___

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

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

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

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

Re: protocol vs. subclassing NSView