Re: GC Basic questions

[Quincey Morris]

On Oct 19, 2009, at 23:35, Nick Rogers wrote:

How do I release everything associated with an ivar (pointer to a  
class) in AppController?

Currently I'm doing it by setting this pointer as nil. Is it ok?


Urg, I missed the part where you said "AppController". Since that  
object is (presumably) never going away, then setting the ivar to nil  
is the correct thing to do.


If you do that and the memory isn't freed, then one of two things has  
happened. Either the collector hasn't decided to collect this memory  
*yet*, or there's another live pointer somewhere that's keeping it  
from being collected.


If you suspect the latter, you can use the 'info gc-roots' command in  
the debugger to find out what reference is keeping a block of memory  
alive.


Hope that's a bit more helpful than my first reply.


___

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: Custom NSURLProtocol crashes when using Garbage Collection

[Keith Duncan]

At this point I expect there's a GC bug in the NSURLProtocol  
machinery, specifically the bridge between NSURLProtocol and  
CFURLProtocol. We'll look further in 7314551.


Thanks for checking for me, I was holding out on hope that there was  
actually bug in my code so that I could still get it working.


Keith
___

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 make cocoa application run as a command line tool?

[XiaoGang Li]

Greetings,
I have created an document-based cocoa application, now I need to
provide a command line interface for my users.
for example, users input this into the terminal:
./myApplication.app/Contents/MacOS/myApplication -c --srcFolder "A/B/C"
--dstFolder "A/B/D";
I can get the argument information through [[NSProcessInfo processInfo]
arguments] in the init method of the application
delegate, and parse the arguments, then step by step.
My question is that, I don't want the window and other document be displayed
on the screen, even the menu.
I want all the action be processed  without user's interventio.
Maybe, this feature seems odd. anyway, however, user can open my application
in the Finder, and open a document to edit it. but they
also can run it like a shell command utility to do some other faceless work,
like convert the type the document to another type.

I don't know whether I have a detailed description for my issue, but I will
be very appreciated for your feedback.
___

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 make cocoa application run as a command line tool?

[Kai Brüning]

The clean solution for this is to refactor your application into a  
framework, a Cocoa application and a command line tool.


The framework contains all the document logic (the model part of the  
MVC pattern). Both the Cocoa application and the command line tool use  
the framework.


The tricky part is probably to find the right border between framework  
and application/tool. I haven’t done it myself yet, therefore I am for  
instance not sure whether NSDocument sub classes can/should be part of  
such a framework.


Others may know whether it is possible/feasible at all to run a Cocoa  
application faceless.


Good luck
Kai


On 20.10.2009, at 11:58, XiaoGang Li wrote:


Greetings,
   I have created an document-based cocoa application, now I  
need to

provide a command line interface for my users.
for example, users input this into the terminal:
./myApplication.app/Contents/MacOS/myApplication -c --srcFolder "A/B/ 
C"

--dstFolder "A/B/D";
I can get the argument information through [[NSProcessInfo  
processInfo]

arguments] in the init method of the application
delegate, and parse the arguments, then step by step.
My question is that, I don't want the window and other document be  
displayed

on the screen, even the menu.
I want all the action be processed  without user's interventio.
Maybe, this feature seems odd. anyway, however, user can open my  
application

in the Finder, and open a document to edit it. but they
also can run it like a shell command utility to do some other  
faceless work,

like convert the type the document to another type.

I don't know whether I have a detailed description for my issue, but  
I will

be very appreciated for your feedback.
___

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/lists%40kai-bruening.de

This email sent to li...@kai-bruening.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

Re: how to make cocoa application run as a command line tool?

[Paul M]

On 20/10/2009, at 10:58 PM, XiaoGang Li wrote:


Greetings,
I have created an document-based cocoa application, now I need 
to

provide a command line interface for my users.
for example, users input this into the terminal:
./myApplication.app/Contents/MacOS/myApplication -c --srcFolder "A/B/C"
--dstFolder "A/B/D";
I can get the argument information through [[NSProcessInfo processInfo]
arguments] in the init method of the application
delegate, and parse the arguments, then step by step.
My question is that, I don't want the window and other document be 
displayed

on the screen, even the menu.
I want all the action be processed  without user's interventio.
Maybe, this feature seems odd. anyway, however, user can open my 
application

in the Finder, and open a document to edit it. but they
also can run it like a shell command utility to do some other faceless 
work,

like convert the type the document to another type.

I don't know whether I have a detailed description for my issue, but I 
will

be very appreciated for your feedback.


Your app has to detect whether it's been started from the finder or 
whether
it's being called from the command line. I'm not sure off the top of my 
head

how best to do this, but it shouldn't be too hard to figure out a way.
Then it'll either show or not show your UI, as appropriate. Simple.

There's multiple ways to structure this though. You could have 2 
separate
apps, but built with as much common code as possible; you could have a 
single
app which shows or doesnt show the UI - as described above; you could 
even have
a 3rd app which does the heavy lifting, but is called by either a 
command line

tool or by a regular cocoa based app.
Without knowing what exactly you're trying to do, it's hard to comment 
on the

best aproach.

By the way, an alternative aproach to calling into your application 
bundle
from the command line is to simply type 'open -a myApplication', 
however I

dont think this will allow you to pass args as you've described above.


paulm

___

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: Dirty rects getting merged together makes for inefficient drawing

[Uli Kusterer]

On 19.10.2009, at 23:58, Ben Haller wrote:


On 19-Oct-09, at 5:27 PM, Dave Keck wrote:


Would NSView's -getRectsBeingDrawn:count: help?


 Well, I'm already using it in my own code where appropriate.  (Or  
actually I'm using -needsToDrawRect:).  But the problem is that a  
whole bunch of NSTableView cells are getting drawn that never got  
invalidated.


 That's like saying: "I'm using the setter, why would I need to use  
the getter?"


 The dirtyRect parameter passed to drawRect: is the union of all  
redraw rectangles. So, it's the smallest rect that encloses all the  
dirty rects. drawRect: does not get called for each redraw rect. If  
you want the individual sub-rects, use getRectsBeingDrawn:count: and  
loop over all those rects and draw the individual parts.


Cheers,
-- Uli Kusterer
"The witnesses of TeachText are everywhere..."



___

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: Dirty rects getting merged together makes for inefficient drawing

[Uli Kusterer]

On 20.10.2009, at 03:02, Ben Haller wrote:
As for NSTableView, it does appear to be doing minimal drawing.  So  
I guess all the string-drawing overhead I see in Sampler is just  
from the single column that is updating, which is unfortunate since  
it means I have no room for optimization.  I never imagined it would  
take so much time just to draw the one column I dirtied.



This may help to optimize after all:

http://zathras.de/blog-cocoa-text-system-everywhere.htm

Cheers,
-- Uli Kusterer
"The witnesses of TeachText are everywhere..."



___

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 make cocoa application run as a command line tool?

[Jeremy Pereira]

On 20 Oct 2009, at 11:42, Paul M wrote:


On 20/10/2009, at 10:58 PM, XiaoGang Li wrote:


Greetings,
  I have created an document-based cocoa application, now I  
need to

provide a command line interface for my users.
for example, users input this into the terminal:
./myApplication.app/Contents/MacOS/myApplication -c --srcFolder "A/ 
B/C"

--dstFolder "A/B/D";
I can get the argument information through [[NSProcessInfo  
processInfo]

arguments] in the init method of the application
delegate, and parse the arguments, then step by step.
My question is that, I don't want the window and other document be  
displayed

on the screen, even the menu.
I want all the action be processed  without user's interventio.
Maybe, this feature seems odd. anyway, however, user can open my  
application

in the Finder, and open a document to edit it. but they
also can run it like a shell command utility to do some other  
faceless work,

like convert the type the document to another type.

I don't know whether I have a detailed description for my issue,  
but I will

be very appreciated for your feedback.


Your app has to detect whether it's been started from the finder or  
whether
it's being called from the command line. I'm not sure off the top of  
my head

how best to do this, but it shouldn't be too hard to figure out a way.
Then it'll either show or not show your UI, as appropriate. Simple.


When I need to do this, I create a switch which puts the app into  
"command line" mode.


static int commandLine(int argc, const char* argv[]);

int main(int argc, char *argv[])
{
   if (argc > 1)
   {
   if (strcmp(argv[1], "-commandLine") == 0)
   {
   return commandLine(argc, argv);
   }
   }
   else
   {
   return NSApplicationMain(argc,  (const char **) argv);
   }
}

This way I can run the binary directly from the command line supplying  
the argument:


/Applications/MyApp.app/Contents/MacOS/MyApp -commandLine other args

Or

open /Applications/MyApp.app --args -commandLine other args

NB I haven't actually tried the open method to see if it works.



There's multiple ways to structure this though. You could have 2  
separate
apps, but built with as much common code as possible; you could have  
a single
app which shows or doesnt show the UI - as described above; you  
could even have
a 3rd app which does the heavy lifting, but is called by either a  
command line

tool or by a regular cocoa based app.
Without knowing what exactly you're trying to do, it's hard to  
comment on the

best aproach.

By the way, an alternative aproach to calling into your application  
bundle
from the command line is to simply type 'open -a myApplication',  
however I

dont think this will allow you to pass args as you've described above.


paulm

___

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/adc%40jeremyp.net

This email sent to a...@jeremyp.net


___

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

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

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

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

Re: how to make cocoa application run as a command line tool?

[Jeremy Pereira]

On 20 Oct 2009, at 12:20, Jeremy Pereira wrote:




When I need to do this, I create a switch which puts the app into  
"command line" mode.


static int commandLine(int argc, const char* argv[]);

int main(int argc, char *argv[])
{
 if (argc > 1)
 {
 if (strcmp(argv[1], "-commandLine") == 0)
 {
 return commandLine(argc, argv);
 }
 }
 else
 {
 return NSApplicationMain(argc,  (const char **) argv);
 }
}


Got that wrong.  I think

 if (argc > 1 && strcmp(argv[1], "-commandLine") == 0)
 {
return commandLine(argc, argv);
 }
 else
 {
 return NSApplicationMain(argc,  (const char **) argv);
 }

might be better.
___

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: Dirty rects getting merged together makes for inefficient drawing

[Ben Haller]

On 20-Oct-09, at 6:54 AM, Uli Kusterer wrote:


On 19.10.2009, at 23:58, Ben Haller wrote:


On 19-Oct-09, at 5:27 PM, Dave Keck wrote:


Would NSView's -getRectsBeingDrawn:count: help?


Well, I'm already using it in my own code where appropriate.  (Or  
actually I'm using -needsToDrawRect:).  But the problem is that a  
whole bunch of NSTableView cells are getting drawn that never got  
invalidated.


That's like saying: "I'm using the setter, why would I need to use  
the getter?"


The dirtyRect parameter passed to drawRect: is the union of all  
redraw rectangles. So, it's the smallest rect that encloses all the  
dirty rects. drawRect: does not get called for each redraw rect. If  
you want the individual sub-rects, use getRectsBeingDrawn:count: and  
loop over all those rects and draw the individual parts.


  Uh, Uli, reread what I typed.  I did not say "or actually I'm using  
setNeedsDisplayInRect:".  -needsToDrawRect is a shorthand for exactly  
what you propose: calling -getRectsBeingDrawn:count: and looping over  
those rects.  From the docs for -needsToDrawRect:


It gives you a convenient way to determine whether any part of a given  
graphical entity might need to be drawn. It is optimized to  
efficiently reject any rectangle that lies outside the bounding box of  
the area the receiver is being asked to draw in drawRect:.


  So whether -needsToDrawRect or -getRectsBeingDrawn:count: is a  
better solution depends mostly upon taste, and a little bit on how  
many tests you intend to do in your draw method (i.e. efficiency to  
testing).  For my purposes, doing a total of two tests, - 
needsToDrawRect is fine.


Ben Haller
Stick Software

___

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: Dirty rects getting merged together makes for inefficient drawing

[Graham Cox]

On 20/10/2009, at 10:42 PM, Ben Haller wrote:

 So whether -needsToDrawRect or -getRectsBeingDrawn:count: is a  
better solution depends mostly upon taste, and a little bit on how  
many tests you intend to do in your draw method (i.e. efficiency to  
testing).  For my purposes, doing a total of two tests, - 
needsToDrawRect is fine.



Yes, it's fine. -needsToDrawRect: is intended for when you have a  
simple list of objects that need drawing. The other is better suited  
when you have some form of spatial database storing the things to be  
drawn, so you can extract those directly from the database based on  
the dirty rects without iterating a (potentially very large) list.


--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: Dirty rects getting merged together makes for inefficient drawing

[Ben Haller]

On 20-Oct-09, at 6:59 AM, Uli Kusterer wrote:


On 20.10.2009, at 03:02, Ben Haller wrote:
As for NSTableView, it does appear to be doing minimal drawing.  So  
I guess all the string-drawing overhead I see in Sampler is just  
from the single column that is updating, which is unfortunate since  
it means I have no room for optimization.  I never imagined it  
would take so much time just to draw the one column I dirtied.


This may help to optimize after all:

http://zathras.de/blog-cocoa-text-system-everywhere.htm


  This is interesting, and I've done this sort of thing in the past  
quite a bit actually.  I'm surprised by one bit of it, though, where  
it says:


...sometimes you need better performance than the NSStringDrawing  
category will provide...


implying that doing things this way is faster than NSStringDrawing.   
Is that actually true?  Why would that be?  NSStringDrawing does more  
or less exactly this, doesn't it, using cached a cached textstorage/ 
layout/container set?  If NSStringDrawing is less efficient than doing  
it yourself, where does that inefficiency lie, and why doesn't Apple  
fix that inefficiency?  Presumably because Apple's way has some other  
benefit?  So what is that benefit?  I.e. I'm trying to understand what  
the tradeoffs are here.


  In the past, playing around with such things, the big win I've  
noticed over NSStringDrawing comes up only if you need to both measure  
and draw the same string.  Then you set everything up with your string  
once, measure and draw, and layout needs to happen only once.  So  
drawing centered or right-aligned text is faster -- almost twice as  
fast -- doing it yourself.  If there's a way to get the same speedup  
from Apple's API's I'm not aware of it; AFAIK even - 
[NSAttributedString drawWithRect:options:] doesn't let you draw a  
string centered or right-aligned in the rect, which seems like a big  
oversight.  I've just logged 7318495 on that.


  But if you're drawing text left-aligned, and thus don't need to  
measure it, is there any speedup doing things yourself?


Cheers,

Ben Haller
Stick Software

___

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: UIDatePicker plus touch events?

[Eric E. Dolecki]

I am curious if it's a bad idea to have touch enabled on a view while a
UIDatePicker is above in another view. Performance seems to be quite spotty
(choppy and slow to respond) in the animations in the UIDatePicker. Is this
a known issue?
Thanks,
Eric
___

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: Dirty rects getting merged together makes for inefficient drawing

[Graham Cox]

On 20/10/2009, at 11:03 PM, Ben Haller wrote:

AFAIK even -[NSAttributedString drawWithRect:options:] doesn't let  
you draw a string centered or right-aligned in the rect, which seems  
like a big oversight.  I've just logged 7318495 on that.



That's not the case - NSAttributedString takes its left/right/center/ 
justified setting from the NSParagraphStyle attribute attached to the  
string. If it's not there, it defaults to natural alignment for the  
font (left for English).



I.e. I'm trying to understand what the tradeoffs are here.


Convenience versus speed. Setting up a text layout system  
programatically is quite involved, and for a high-level solution that  
is equivalent to olde-worlde DrawThemeTextBox the string drawing  
methods do that for you. But they have to build up and tear down a  
text system for every call, so incur this overhead and can't cache any  
layout information. I still think it's the case (borne out by  
profiling here) that glyph rendering still dominates the process  
however.


But if you're drawing text left-aligned, and thus don't need to  
measure it, is there any speedup doing things yourself?


Yes, if you are drawing the same string over and over again (as in  
repeated refreshes of the same string in a view). The question is  
whether the speed-up matters. If you have thousands of text objects in  
your view, probably yes. If just one or two, probably not. There's no  
need to (and you can't) draw faster than 60 fps so you have ~16mS to  
draw everything. If it takes longer, text caching etc may help.


--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: Dirty rects getting merged together makes for inefficient drawing

[Uli Kusterer]

On 20.10.2009, at 13:42, Ben Haller wrote:
So whether -needsToDrawRect or -getRectsBeingDrawn:count: is a  
better solution depends mostly upon taste, and a little bit on how  
many tests you intend to do in your draw method (i.e. efficiency to  
testing).  For my purposes, doing a total of two tests, - 
needsToDrawRect is fine.



 Oh, right. Sorry. Mixed that up.

Cheers,
-- Uli Kusterer
"The witnesses of TeachText are everywhere..."



___

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: Dirty rects getting merged together makes for inefficient drawing

[Uli Kusterer]

On 20.10.2009, at 14:03, Ben Haller wrote:
implying that doing things this way is faster than NSStringDrawing.   
Is that actually true?  Why would that be?  NSStringDrawing does  
more or less exactly this, doesn't it, using cached a cached  
textstorage/layout/container set?  If NSStringDrawing is less  
efficient than doing it yourself, where does that inefficiency lie,  
and why doesn't Apple fix that inefficiency?  Presumably because  
Apple's way has some other benefit?  So what is that benefit?  I.e.  
I'm trying to understand what the tradeoffs are here.


 Apple's code has to be generic. It can only cache the last call, or  
maybe a few. It has to be conservative in its decision whether to  
cache so it doesn't cache stuff that's actually changed. You know your  
array storage, so you could cache more aggressively. Only you know  
your code, it might not make sense there, but in a lucky case, you  
could probably keep around the text system objects for each of your  
cells, and thus draw way faster than the OS's functions could do.


 AFAIK even -[NSAttributedString drawWithRect:options:] doesn't let  
you draw a string centered or right-aligned in the rect, which seems  
like a big oversight.  I've just logged 7318495 on that.


 Haven't tried that, but have you tried setting the paragraph style  
in the attributed string to use the right alignment?


 But if you're drawing text left-aligned, and thus don't need to  
measure it, is there any speedup doing things yourself?



 If you draw the same bunch of strings repeatedly, and you know their  
lifetime, you can definitely make them draw faster.


Cheers,
-- Uli Kusterer
"The witnesses of TeachText are everywhere..."



___

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: Dirty rects getting merged together makes for inefficient drawing

[Ben Haller]

On 20-Oct-09, at 8:15 AM, Graham Cox wrote:


On 20/10/2009, at 11:03 PM, Ben Haller wrote:

AFAIK even -[NSAttributedString drawWithRect:options:] doesn't let  
you draw a string centered or right-aligned in the rect, which  
seems like a big oversight.  I've just logged 7318495 on that.


That's not the case - NSAttributedString takes its left/right/center/ 
justified setting from the NSParagraphStyle attribute attached to  
the string. If it's not there, it defaults to natural alignment for  
the font (left for English).


  Oh!  Good to know.  Didn't occur to me somehow!


I.e. I'm trying to understand what the tradeoffs are here.


Convenience versus speed. Setting up a text layout system  
programatically is quite involved, and for a high-level solution  
that is equivalent to olde-worlde DrawThemeTextBox the string  
drawing methods do that for you. But they have to build up and tear  
down a text system for every call, so incur this overhead and can't  
cache any layout information. I still think it's the case (borne out  
by profiling here) that glyph rendering still dominates the process  
however.


But if you're drawing text left-aligned, and thus don't need to  
measure it, is there any speedup doing things yourself?


Yes, if you are drawing the same string over and over again (as in  
repeated refreshes of the same string in a view). The question is  
whether the speed-up matters. If you have thousands of text objects  
in your view, probably yes. If just one or two, probably not.  
There's no need to (and you can't) draw faster than 60 fps so you  
have ~16mS to draw everything. If it takes longer, text caching etc  
may help.


  Ah, yes, that is true, repeated drawing of the same string would be  
a big win for this.


  Uli had much the same to say.  Good points.  Thanks guys.

Ben Haller
Stick Software

___

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: CPU utilization in Snow Leopard

[Joar Wingfors]

On 19 okt 2009, at 23.37, Graham Cox wrote:

Since there's no autorelease pool inside your do...while loop, of  
course it isn't going to get autoreleased then. Autorelease isn't  
magic, someone has to tell it when it can release - that's you. Put  
your pool inside the loop so it is created and destroyed each time.



In all fairness, this isn't your responsibility for the most part. For  
high frequency / long lived loops it typically is though.



On 19 okt 2009, at 23.41, Graham Cox wrote:


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


//Some operations...


do  //Keeps thread alive till date
{
		[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode   
beforeDate:[NSDate dateWithTimeIntervalSinceNow: 0.1]];


	} while (mShouldThreadAlive); //Waiting for other process to  
complete


 [pool release];

}



Mind you, having said what I just said, this is a bad approach  
anyway. You should not "keep a thread alive" until it gets some  
flag, that's just wasting CPU time doing nothing but spinning.  
Instead the thread should sleep until it has something to do. If you  
need to wait for another thread to finish, use a NSConditionLock to  
do it properly. Also, if this code is representative, you are  
spinning it after all the processing has finished, which is  
pointless. Just let it terminate if it has nothing more to do.



It's unclear what the purpose of the loop at the end of this method is  
intended to serve. From the code posted here I would agree with Graham  
that it seems likely that a condition lock is more appropriate.


Do you need a run loop for some reason? Are you using it to  
communicate with the thread?


j o a r


___

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: CPU utilization in Snow Leopard

[Alastair Houghton]

On 20 Oct 2009, at 07:41, Graham Cox wrote:

If you need to wait for another thread to finish, use a  
NSConditionLock to do it properly.


Either that, or if the run loop is required for some other reason,  
make a custom run loop source and, add it to the run loop and signal  
it from the other thread.  You rarely need to do that, but there are  
uses for it.


Kind regards,

Alastair.

--
http://alastairs-place.net



___

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

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

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

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

I don't understand this leak

[Eric E. Dolecki]

Instruments:
Malloc 128 Bytes   0x7100780  128 Bytes   CoreGraphics
open_handle_to_dylib_path
Malloc 128 Bytes   0x3d0aa50  128 Bytes   CoreGraphics
open_handle_to_dylib_path

I am not sure what this is... AppDelegate adding subview? Is this a bug in
Instruments, or something else?


-- 
http://ericd.net
Interactive design and development
___

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

Child window shows up on top despite specifying NSWindowBelow

[Francisco Tolmasky]

The title says it all, I set up a child window as such:

[targetWindow addChildWindow:self ordered:NSWindowBelow];

But the child window shows up on top of "targetWindow" until the first  
click, at which point it immediately reorders itself to the back and  
behaves correctly from that point forward. My suspicion is that it has  
something to do with the fact that I set the child window before  
"targetWindow" is visible, but given the structure of the code it  
would be difficult to do otherwise (although not impossible if that is  
the only way to fix this problem). Are there any known issues or  
perhaps something obvious that I am doing incorrectly?


Thanks,

Francisco

___

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: I don't understand this leak

[Karolis Ramanauskas]

This may be a false positive. I recently had a similar leak:

> Category: Malloc 4.50 KB
> Event Type: Malloc
> RefCt: 1
> Address: 0x103108000
> Size: 4608
> Responsible Library: ImageIO
> Responsible Caller: du_block::set_max_bytes(int, bool)
>

Ken Ferry on this list explained it was a false positive. You may want to
show your stack trace, like I did in my recent post, to help people discover
the problem.

On Tue, Oct 20, 2009 at 12:36 PM, Eric E. Dolecki wrote:

> Instruments:
> Malloc 128 Bytes   0x7100780  128 Bytes   CoreGraphics
> open_handle_to_dylib_path
> Malloc 128 Bytes   0x3d0aa50  128 Bytes   CoreGraphics
> open_handle_to_dylib_path
>
> I am not sure what this is... AppDelegate adding subview? Is this a bug in
> Instruments, or something else?
>
___

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: Child window shows up on top despite specifying NSWindowBelow

[Jesper Storm Bache]

Your analysis (regarding window visibility) sounds plausible as non- 
visible Cocoa windows have no "z-order".
I have logged: "6802899 Please add latent z-order to hidden NSWindows"  
for this, but in the meantime I am left with having to move "hidden"  
windows off screen and make then visible (then override  
constrainFrameRect to not move the window back on screen).

Jesper Storm Bache

On Oct 20, 2009, at 10:43 AM, Francisco Tolmasky wrote:

> The title says it all, I set up a child window as such:
>
> [targetWindow addChildWindow:self ordered:NSWindowBelow];
>
> But the child window shows up on top of "targetWindow" until the first
> click, at which point it immediately reorders itself to the back and
> behaves correctly from that point forward. My suspicion is that it has
> something to do with the fact that I set the child window before
> "targetWindow" is visible, but given the structure of the code it
> would be difficult to do otherwise (although not impossible if that is
> the only way to fix this problem). Are there any known issues or
> perhaps something obvious that I am doing incorrectly?
>
> Thanks,
>
> Francisco
>
> ___
>
> 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/jsbache%40adobe.com
>
> This email sent to jsba...@adobe.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

Newbie query re checkboxes

[McLaughlin, Michael P.]

I have an NSArray (2 x 3) of NSButtonCell in IB.  The style is Checkbox.  I
made the Mode = list so that all might be unchecked.

The problem is that my array is behaving like a Radio Group.  If I check one
any other that is checked turns off.  This is not what I want.  [No other
Mode seems to fix this.]

What am I missing?

Thanks.

-- 
Mike McLaughlin

___

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: Newbie query re checkboxes

[Kyle Sluder]

On Tue, Oct 20, 2009 at 12:49 PM, McLaughlin, Michael P.
 wrote:
> I have an NSArray (2 x 3) of NSButtonCell in IB.  The style is Checkbox.  I
> made the Mode = list so that all might be unchecked.

This is incorrect.  You want the highlight mode as described in the
Matrix Programming Guide for Cocoa.

--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

Odd window drag bug

[Eric Gorr]

Here is a simple application which reproduces the problem:

 http://ericgorr.net/cocoadev/WindowDrag.zip

After building the application with Xcode 3.2, press the miniaturize  
button. This will cause the panel to be window shaded.


Now, try to drag the window from the right side of the title bar. You  
cannot.


You can drag the window around from the middle of the title bar.

If you disable the resize property of the window, you will be able to  
drag the window from the right side of the title bar when the window  
is shaded.


It seems as if the resize area in the bottom right corner of the  
window is getting shoved into the title bar and blocking the title bar  
drag code.


I have filed a bug report... rdar://7320825




___

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

Displaying a view modally

[Mike Manzano]

Hi,

I'd like to display a busy indicator view (HUD) regardless of whatever  
view is currently at the top of the view stack. I'd also like this  
view to display modally so that the user interface beneath it is dead  
to touch events. This is like Tweetie 2's HUD that appears when you've  
successfully posted something to Instapaper, with the difference that  
the UI underneath it wouldn't accept events as they do in Tweetie 2.  
I'd also like to have some control over animating the HUD onto and off  
of the screen.


My current thinking is to find the topmost view controller somehow and  
send it presentModalViewController:animated:. However, I don't know  
how much control over animation I'd get with that method as the built- 
in animation styles sort of assume a full screen view. Also, I've  
never tried to use this method with a view that's smaller than the  
screen size.


Another thought is to just add the view to the root view and bring it  
to the top (this however won't make the view modal as the views below  
will still respond to touch events).


Can anyone tell me if I'm thinking along the right directions? I'd  
like to have some confirmation before I invest a bunch of time only to  
find out it's the wrong method.


Thanks,

Mike Manzano
mike (at) instantvoodoomagic (dot) com
http://instantvoodoomagic.com
@instantvoodoo

Oh BTW, the first reply that gets me closer to a solution gets a free  
promo code for Newsie (http://instantvoodoomagic.com/newsie), the  
Google Reader client for iPhone/iPod touch that I just released ;)



___

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: Child window shows up on top despite specifying NSWindowBelow

[Rob Keniger]

On 21/10/2009, at 4:40 AM, Jesper Storm Bache wrote:

> Your analysis (regarding window visibility) sounds plausible as non- 
> visible Cocoa windows have no "z-order".
> I have logged: "6802899 Please add latent z-order to hidden NSWindows"  
> for this, but in the meantime I am left with having to move "hidden"  
> windows off screen and make then visible (then override  
> constrainFrameRect to not move the window back on screen).


It's probably better to call NSDisableScreenUpdates(), set the child window 
ordering/placement/visibility and then call NSEnableScreenUpdates(). This is 
what I do and it works perfectly. It's one of the main reasons these calls 
exist, AFAIK.

--
Rob Keniger



___

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

Problems with NSCollectionView

[PCWiz]

I'm trying to set up an NSCollectionView (I have done this  
successfully in the past, but for some reason it fails this time).


I have a model class called "TestModel", and it has a NSString  
property that just returns a string (just for testing purposes right  
now). I then have an NSMutableArray property declaration in my main  
app delegate class, and to this array I add instances of the TestModel  
object.


I then have an Array Controller that has its Content Array bound the  
app delegate's NSMutableArray. I can confirm that everything up to  
here is working fine, NSLogging [[[arrayController arrangedObjects]  
objectAtIndex:0] teststring] worked fine.


I then have all the appropriate bindings for the collection view set  
up, (itemPrototype and content), and for the Collection View Item  
(view). I then have a text field in the collection item view that is  
bound to Collection View Item.representedObject.teststring. However  
NOTHING displays in the collection view when I start the app, just a  
blank white screen. What am I missing?


P.S. Im on Snow Leopard with Xcode 3.2 but im using the 10.5 sdk.
___

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

Questions about Nib Object Retention

[an0]

Nib Object 
Retention


 Mac OS X - managed memory model

Objects in the nib file are initially created with a retain count of 1. As
it rebuilds the object hierarchy, however, AppKit autoreleases any objects
that have a parent or owning object, such as views nested inside view
hierarchies. By the time the nib-loading code is done, only the top-level
objects in the nib file have a positive retain count and no owning object.
Your code is responsible for releasing these top-level objects.


Here are my questions:

Who owns the unarchived top-level objects' initial positive retain count?

Are they retained for outlet connections?

Or are they just not autoreleased only because they are top-level,
regardless of whether there are any outlet connected to them?


-- 
Hell boy is cool, but let me be healthy boy first.
___

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: Questions about Nib Object Retention

[Graham Cox]

On 21/10/2009, at 2:40 PM, an0 wrote:

Who owns the unarchived top-level objects' initial positive retain  
count?


Nobody. That's what "no owning object" means.


Are they retained for outlet connections?


No, because if there is an outlet to them then they are owned.


Or are they just not autoreleased only because they are top-level,
regardless of whether there are any outlet connected to them?



They are not autoreleased because that would presumably cause problems  
for the users of these objects, who don't own them either. If there's  
an outlet to them, they are owned by whoever declares the outlet.


As it says, "Your code is responsible for releasing these top-level  
objects".


This is not the big issue it seems. Most nibs don't contain top level  
objects with no owners. For the very few that do, the objects most  
likely leak but typically that's no big deal unless you're loading the  
same nib repeatedly many times.


--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: Child window shows up on top despite specifying NSWindowBelow

[Francisco Tolmasky]

So I've actually narrowed it down to the fact that my windows have a  
custom level. If the windows have the standard level then  
NSWIndowBelow works fine. Any known workarounds for this?


Thanks,

Francisco

On Oct 20, 2009, at 11:40 AM, Jesper Storm Bache wrote:


Your analysis (regarding window visibility) sounds plausible as non-
visible Cocoa windows have no "z-order".
I have logged: "6802899 Please add latent z-order to hidden NSWindows"
for this, but in the meantime I am left with having to move "hidden"
windows off screen and make then visible (then override
constrainFrameRect to not move the window back on screen).

Jesper Storm Bache

On Oct 20, 2009, at 10:43 AM, Francisco Tolmasky wrote:


The title says it all, I set up a child window as such:

   [targetWindow addChildWindow:self ordered:NSWindowBelow];

But the child window shows up on top of "targetWindow" until the  
first

click, at which point it immediately reorders itself to the back and
behaves correctly from that point forward. My suspicion is that it  
has

something to do with the fact that I set the child window before
"targetWindow" is visible, but given the structure of the code it
would be difficult to do otherwise (although not impossible if that  
is

the only way to fix this problem). Are there any known issues or
perhaps something obvious that I am doing incorrectly?

Thanks,

Francisco

___

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/jsbache%40adobe.com

This email sent to jsba...@adobe.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: Child window shows up on top despite specifying NSWindowBelow

[Rob Keniger]

On 21/10/2009, at 2:20 PM, Francisco Tolmasky wrote:

> So I've actually narrowed it down to the fact that my windows have a custom 
> level. If the windows have the standard level then NSWIndowBelow works fine. 
> Any known workarounds for this?


What happens when you call -setWindowLevel: on the child window to 
(yourWindowLevel - 1)?

--
Rob Keniger



___

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: Questions about Nib Object Retention

[Kyle Sluder]

On Tue, Oct 20, 2009 at 8:55 PM, Graham Cox  wrote:
>> Are they retained for outlet connections?
>
> No, because if there is an outlet to them then they are owned.

This is not correct.  I have built a sample project and instantiated a
custom, do-nothing NSObject subclass in my nib.  It experiences the
same behavior (one allocation, one retain, and one release) whether it
is wired up to an outlet or not.

Someone needs to release your top level objects.  Since your file's
owner is usually doing the nib loading, it makes sense for that object
to do the releasing of those objects.  This is why the file's owner's
outlets are typically assigned, not retained.  The nib loading
machinery has taken care of the retain.

--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

Calling method in brand new view to set a variable?

[Eric E. Dolecki]

I am calling up a view from it's nib, and immediately calling a method in
that view controller class to set a variable. I can't access the newly set
variable in viewDidLoad, so I have a timer of 100ms inside the viewDidLoad
that actually uses the variable that is set (it's available by then).
Is there a better way (callback method) that I should use instead that would
be foolproof and not based on a NSTimer being long enough to properly
access? Or should I store the variable in my model class and just use a
getter at that point instead? It's a little easier to keep it in the view
using it, but if that's the way to do it, so be it.

Thanks,
Eric
___

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

Magic Mouse and NSTouch

[Kyle Sluder]

Can anyone confirm that the new Magic Mouse generates NSTouch events,
not just gestures?  I would like to now before dropping $70 on one.

TIA,
--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

How to run a panel that customizes a new NSDocument

[Ben Haller]

  Hi all.  I've got an NSDocument-based class that can be based upon  
a variety of "models".  The documents are the same type in any case,  
but they are configured differently based upon their model.  When the  
user chooses New, or when the app is launched, I want to run a panel  
for the user to choose their desired model.  Once they dismiss the  
panel, a document using that model will be created.  I.e. very much  
like how Interface Builder runs a panel where you choose the sort of  
nib you want to make, and then it makes you a new nib of that sort.
  The question is how to do this.  I see the stuff in NSDocument/ 
NSDocumentController having to do with "types" but that does not seem  
relevant; that would be for an app that could open and save both .txt  
and .rtf files, for example.  All of my documents are of the same  
type, they just have different initial state.
  What I have ended up with, after a fair amount of fruitless  
searching in the NSDocument docs, is this method in my application  
delegate:


- (BOOL)applicationOpenUntitledFile:(NSApplication *)theApplication
{
AKModel *chosenModel = [AKNewModelController runNewModelPanel];

if (chosenModel)
{
		AKDocument *newDocument = [[AKDocument alloc]  
initWithModel:chosenModel];


[newDocument makeWindowControllers];
[newDocument showWindows];

		[[NSDocumentController sharedDocumentController]  
addDocument:newDocument];


return YES;
}

return NO;
}

  I don't like it very much though.  It works, but it hard-codes the  
sequence of -makeWindowControllers, then -showWindows, then - 
addDocument:, all of which NSDocumentController ought to be doing for  
me.  I wonder if I need to subclass NSDocumentController instead, but  
it isn't really clear to me how to do that to achieve this. I could  
override -openUntitledDocumentAndDisplay:error:, and run my "model  
chooser" panel inside my override, but how do I get the model the user  
chose into the new document if the NSDocumentController creates it for  
me?  Right now I pass the model in to the document's -initWithModel:  
method.  I could refactor things so that the document created is  
generic and model-less, and then set a model on it after it has  
constructed; but that would be highly inconvenient, as it happens,  
because the windows the document makes depend upon its model, and the  
document's windows get shown by NSDocumentController before it would  
return control to me (i.e. inside [super  
openUntitledDocumentAndDisplay:error:] returns).

  There must be a good, clean way to do this.  Anyone?

Ben Haller
Stick Software

___

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: Questions about Nib Object Retention

[Joar Wingfors]

On 20 okt 2009, at 20.40, an0 wrote:

Who owns the unarchived top-level objects' initial positive retain  
count?



The "Files Owner" is responsible for the top level objects. It better  
have outlets to them so that it can manage and dispose of them  
appropriately. It sounds like you're asking about this in the context  
of Mac OS X and Reference Counting? As you've noted from the  
documentation, the rules differs between Mac and iPhone, and between  
GC and RC.




Are they retained for outlet connections?
Or are they just not autoreleased only because they are top-level,
regardless of whether there are any outlet connected to them?



They're retained regardless of if there are outlets for them or not.


If you use NSViewController or NSWindowController subclasses to load  
nib files, you don't have to care about this, since they manage the  
top level objects for you. This is a very good reason to always try to  
do your nib loading from subclasses of these classes if possible.



j o a r


___

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: Calling method in brand new view to set a variable?

[Graham Cox]

On 21/10/2009, at 3:39 PM, Eric E. Dolecki wrote:

I am calling up a view from it's nib, and immediately calling a  
method in
that view controller class to set a variable. I can't access the  
newly set
variable in viewDidLoad, so I have a timer of 100ms inside the  
viewDidLoad

that actually uses the variable that is set (it's available by then).
Is there a better way (callback method) that I should use instead  
that would

be foolproof and not based on a NSTimer being long enough to properly
access? Or should I store the variable in my model class and just  
use a
getter at that point instead? It's a little easier to keep it in the  
view

using it, but if that's the way to do it, so be it.



This sounds what -awakeFromNib is for (see NSNibAwaking protocol) . Is  
there some reason you can't use that?


--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 run a panel that customizes a new NSDocument

[Graham Cox]

On 21/10/2009, at 3:43 PM, Ben Haller wrote:


 There must be a good, clean way to do this.  Anyone?



Well, the expected way is to have different types for your documents.  
You can still map them all to the same class, and discriminate in the - 
initWithType:error: method to set up the appropriate model.


However, if you really can't or don't want to do that, I think what  
you've done is right. Because you have a special designated  
initializer, you have no option but to manually make the controllers  
and add the document to the controller.


--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: Questions about Nib Object Retention

[Graham Cox]

On 21/10/2009, at 3:50 PM, Joar Wingfors wrote:


They're retained regardless of if there are outlets for them or not.




Yes, my bad on that one. I've been misinterpreting the docs on what it  
means by "owner" in this sense for some time, it seems. Luckily, it  
has no practical consequences for me at the moment, but I will bear it  
in mind in future.


--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: Child window shows up on top despite specifying NSWindowBelow

[Francisco Tolmasky]

I've created a pretty trivial case that makes this happen:

NSWindow* ontop = [[NSWindow alloc]  
initWithContentRect:NSMakeRect(100.0, 100.0, 300.0, 400.0)  
styleMask:NSTitledWindowMask | NSClosableWindowMask  
backing:NSBackingStoreBuffered defer:NO];
NSWindow* onback = [[NSWindow alloc]  
initWithContentRect:NSMakeRect(100.0, 100.0, 500.0, 400.0)  
styleMask:NSBorderlessWindowMask backing:NSBackingStoreBuffered  
defer:NO];


[onback setContentView:[[View alloc] init]];

[ontop makeKeyAndOrderFront:self];
[ontop addChildWindow:onback ordered:NSWindowBelow];

[ontop setLevel:3];

The onback window ends up on top after this (which makes no sense to  
me). Changing defer: from YES to NO doesn't do anything useful.


On Oct 20, 2009, at 11:40 AM, Jesper Storm Bache wrote:


Your analysis (regarding window visibility) sounds plausible as non-
visible Cocoa windows have no "z-order".
I have logged: "6802899 Please add latent z-order to hidden NSWindows"
for this, but in the meantime I am left with having to move "hidden"
windows off screen and make then visible (then override
constrainFrameRect to not move the window back on screen).

Jesper Storm Bache

On Oct 20, 2009, at 10:43 AM, Francisco Tolmasky wrote:


The title says it all, I set up a child window as such:

   [targetWindow addChildWindow:self ordered:NSWindowBelow];

But the child window shows up on top of "targetWindow" until the  
first

click, at which point it immediately reorders itself to the back and
behaves correctly from that point forward. My suspicion is that it  
has

something to do with the fact that I set the child window before
"targetWindow" is visible, but given the structure of the code it
would be difficult to do otherwise (although not impossible if that  
is

the only way to fix this problem). Are there any known issues or
perhaps something obvious that I am doing incorrectly?

Thanks,

Francisco

___

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/jsbache%40adobe.com

This email sent to jsba...@adobe.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: Questions about Nib Object Retention

[an0]

So, to be a good memory-wise citizen:1. If there is only one outlet to a
top-level object from the nib owner, the outlet should have "assign"
attribute, and the nib owner is now in fact the "initial 1 retention"(which
seems reserved right for this predictable ownership)'s owner so is
responsible for the releasing. Otherwise if the outlet uses "retain" logic,
there will be a redundant retention to the top-level object so a memory
leak.
2. If there are other outlets to a top-level object from other objects, they
should use the "retain" logic to claim their share of ownership.
3. Outlets to non-top-level objects should always use the "retain" logic if
they want to claim their ownership, since there are no reserved initial
retain count for them.

Am I getting it all right?

On Wed, Oct 21, 2009 at 11:55 AM, Graham Cox  wrote:

>
> On 21/10/2009, at 2:40 PM, an0 wrote:
>
>  Who owns the unarchived top-level objects' initial positive retain count?
>>
>
> Nobody. That's what "no owning object" means.
>
>  Are they retained for outlet connections?
>>
>
> No, because if there is an outlet to them then they are owned.
>
>  Or are they just not autoreleased only because they are top-level,
>> regardless of whether there are any outlet connected to them?
>>
>
>
> They are not autoreleased because that would presumably cause problems for
> the users of these objects, who don't own them either. If there's an outlet
> to them, they are owned by whoever declares the outlet.
>
> As it says, "Your code is responsible for releasing these top-level
> objects".
>
> This is not the big issue it seems. Most nibs don't contain top level
> objects with no owners. For the very few that do, the objects most likely
> leak but typically that's no big deal unless you're loading the same nib
> repeatedly many times.
>
> --Graham
>
>
>


-- 
Hell boy is cool, but let me be healthy boy first.
___

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: Questions about Nib Object Retention

[Kyle Sluder]

I would tend to use a simpler pattern: make assign outlets on file's
owner for each top-level object, and release them in -dealloc.

This pattern is based on the tendency for nibs to be "part of" another
object.  For example, think of NSWindowController or NSViewController.
 Logically, the object graph living inside the associated nib is
really a necessary functional part of the controller object; it
doesn't make much sense to have a window controller with no window.
So the top level objects are almost always of interest only to other
objects in the nib (which don't factor into this whole scheme and
behave no differently than if they were created in code) and to file's
owner (which orchestrates the nib loading and therefore assumes
responsibility for curating its top level 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: Magic Mouse and NSTouch

[Chunk 1978]

i would be surprised if it didn't support NSTouch.  although you may have to
wait for 10.6.2:
http://www.macrumors.com/2009/10/20/magic-mouse-user-guide-suggests-mac-os-x-10-6-2-release-in-near-future/

On Wed, Oct 21, 2009 at 12:40 AM, Kyle Sluder  wrote:

> Can anyone confirm that the new Magic Mouse generates NSTouch events,
> not just gestures?  I would like to now before dropping $70 on one.
>
> TIA,
> --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/chunk1978%40gmail.com
>
> This email sent to chunk1...@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