Re: NSWindowController for Prefs XIB Question (Core Data involved) - Solved

[Steve Cronin]

Folks;

I have figured at least part of this out.
My PrefsController had an instance variable that was of a class from the Core 
Data Model.
Since the MOC was not available until after the initWithWindow, anything 
derived from NSManagedObject is not valid.

Once I removed this instance variable the window now now opens.

Hopefully this is helpful to someone else….
Steve

>> On May 20, 2010, at 10:08 PM, Steve Cronin wrote:
>> 
>>> Folks;
>>> 
>>> I have a feeling that this is an embarrassing one so try and go easy on me…
>>> XC 3.2.2 
>>> 
>>> I have a main nib that opens a window and that works fine.
>>> I used to have an NSPanel in this nib to handle preferences.
>>> I've decided it's a good idea to split the nib into two different nibs: the 
>>> main nib and a preferences nib.
>>> 
>>> I've looked over the Sketch project and used it as a model.
>>> I've also read over the Document-Based App Overview FAQ
>>> 
>>> I've added a window nib to the project and then subclassed a 
>>> NSWindowController.
>>> I've made the xib's files owner this window controller
>>> At this point I can get a simple empty window to open just fine.
>>> 
>>> However, I'm using CoreData and I want to pass the existing MOC to the pref 
>>> window:
>>> I have added an array controller to the pref nib with its MOC set to files 
>>> owner's MOC in IB.
>>> The controller manages an entity not a mutable dictionary.
>>> MOC is a synthesized property of the PrefController (the windowController 
>>> mentioned above).
>>> 
>>> if (!prefPanelController) {
>>> prefPanelController = [[PreferencesController alloc] 
>>> initWithWindowNibName:@"testPref"];
>>> [prefPanelController setManagedObjectContext:[self 
>>> managedObjectContext]];
>>> }
>>> [prefPanelController showWindow:sender];
>>> 
>>> No window opens and I get a console error:  Cannot perform operation 
>>> without a managed object context
>>> 
>>> Could someone give me the gentle head slap I need here?
>>> Steve
>> 
>> 
>> ___
>> 
>> 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/billy%40deviltrain.co.uk
>> 
>> This email sent to bi...@deviltrain.co.uk
> 

___

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: Core data model persistence, independent of document

[Jerry Krinock]

On 2010 May 21, at 11:30, James Maxwell wrote:

> I built a model that seems about right, to me, but I can't seem to bind it to 
> anything

I don't know how you "bind it [a model]".  The only thing which you can bind 
are bindings.  Admittedly, the terminology is very confusing and the word 
"binding" in particular has several definitions.  But you've got to read the 
Cocoa Bindings documentation and learn it.

> I've been looking around at various Core Data tutorials, and I noticed that 
> they're either for document-based apps, or they're created from a template, 
> which I guess must provide the appropriate AppDelegate (at least, that's 
> implied by one of the tutorials, at mactech.com). My app is document-based, 
> but I don't want this data stored with the document -- it should persist 
> across all documents, pretty much like a user default

Although your stated requirement of persistent application data as well as 
persistent document data is fairly common in real life, Apple's Core Data 
tutorials are fairly simple and do not demonstrate this.  But it's 
straightforward.  You can have a persistent store in ~/Library/Application 
Support, as well as one in each document.

>  (and besides, I'm subclassing GCDrawKit's "DKDrawingDocument" already).

DKDrawingDocument inherits NSDocument, not NSPersistentDocument.  Therefore, 
you're not going to get a Core Data document.  By the way, this might also be 
the reason why whatever it is you're binding doesn't find a managed object 
context in whatever it is you're binding to.  You could try changing the 
declaration of DKDrawingDocument to make it inherit from NSPersistentDocument, 
but I expect that a lot of pain might lie ahead. 

> I get the same error when binding to Shared User Defaults, so I'm kinda 
> stumped...

Again, no one can figure out what you're "binding".

___

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

PopupButton image scaling

[Trygve Inda]

I have a popup button in either the square or gradient style with an image
of NSActionTemplate. I set the image scaling to proportionally down, and in
IB it looks fine, but when I run the app, the image is completely filling
the button, instead of a nice small image.

Any Ideas?

Trygve


___

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: Getting TextEdit to Recognise UTF-8 Output [solved]

[Darcy Otto]

Bingo.  Completely and utterly solved.  Thanks Gus!

I was writing to the file with:

[[textStream dataUsingEncoding:NSUTF8StringEncoding] writeToFile:[sheet 
filename] atomically:YES];

Now, I'm writing with:

[textStream writeToFile:[sheet filename] atomically:YES 
encoding:NSUTF8StringEncoding error:&error];

When using the latter, TextEdit picks up the encoding, no problem.

On 2010-05-21, at 12:48 PM, Gus Mueller wrote:

> On May 21, 2010, at 12:42 PM, K.Darcy Otto wrote:
> 
>> [textStream appendFormat:@"%C%C%C",0x00EF,0x00BB,0x00BF]; // textStream is 
>> an empty NSMutableString that gets added to, and then written to a file
> 
> 
> How are you writing the string to a file?  Are you using NSString's 
> writeToFile:atomically:?  I'm pretty sure that doesn't write it out as UTF8.  
> You'll probably want to use writeToFile:atomically:encoding:error: with 
> NSUTF8StringEncoding as the encoding if you aren't already.
> 
> -gus
> 
> --  
> 
> August 'Gus' Mueller
> Flying Meat Inc.
> http://flyingmeat.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: Forcing NSImage to cache images at certain sizes

[Ken Ferry]

Hi BJ,

On Fri, May 21, 2010 at 2:44 PM, B.J. Buchalter  wrote:

> I read the NSImage and Cocoa drawing guide docs, which tends to indicate
> that calling drawInRect:fromRect:operation:fraction: on an NSImage will
> cause it to create a cached image rep that matches the scaled image so that
> the next time it is drawn it does not need to be scaled again.
>

The docs haven't fully integrated new info from 10.6, when NSImage changed a
bunch.  Take a look at the AppKit release
notes
.


>
> That is not what I am seeing here, and the scaling is definitely taking a
> nontrivial amount of time when redrawing my views. I have played around with
> setting the caching and scaling on the NSImage, but it doesn't appear to be
> having any impact (the internal image rep for the image never changes).
>

Could you attach a test app please?  There's more than one thing that could
be the issue.


>
> What is the proper way to ensure that the NSImage is cached to match the
> required drawing size? Do I need to build my own cache?
>
> Thanks!
>
> B.J. Buchalter
> Metric Halo
> http://www.mhlabs.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/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: Compatibility of Data iPhone / Mac

[Kyle Sluder]

On Fri, May 21, 2010 at 4:35 PM, Eiko Bleicher  wrote:
> When transferring data between Mac and iPhone/iPad, serializing via 
> NSKeysedArchiver seems simple and easy. Wrapping up some "trivial" Objects 
> like NSData, NSDictionary, NSNumber, NSString seems to work.
>
> But the question is: is it considered safe to transfer data like that? How 
> likely is this scenario going to fail? I imagine how a simple binary change 
> makes everything crash; but given that there might be tons of Applications 
> that store data in a similar fashion, this probably is just not going to 
> happen.

This isn't really a safe thing to do. If you want to archive simple
stuff like strings, arrays, and dictionaries, use
NSPropertyListSerialization. Otherwise, write a custom serialization
scheme. Archiving (keyed or not) is very fragile, if for no other
reason than it relies on the existence of classes at unarchive time
that existed at archive time.

> So I would need to worry about changes on one platform that generates 
> compatibilty problems on the other. Have there ever been issues with that?

Not to my knowledge, but I don't see any versioning mechanism so it's
quite possible there might be in the future.

> It wouldn't be a big deal if I needed to package my data on my own, but this 
> also opens room for bugs

Better to do the right thing in this case.

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

Compatibility of Data iPhone / Mac

[Eiko Bleicher]

When transferring data between Mac and iPhone/iPad, serializing via 
NSKeysedArchiver seems simple and easy. Wrapping up some "trivial" Objects like 
NSData, NSDictionary, NSNumber, NSString seems to work.

But the question is: is it considered safe to transfer data like that? How 
likely is this scenario going to fail? I imagine how a simple binary change 
makes everything crash; but given that there might be tons of Applications that 
store data in a similar fashion, this probably is just not going to happen.

So I would need to worry about changes on one platform that generates 
compatibilty problems on the other. Have there ever been issues with that? 

It wouldn't be a big deal if I needed to package my data on my own, but this 
also opens room for bugs

Eiko___

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: Layer-hosting views and layer-backed scroll views

[Kyle Sluder]

On Fri, May 21, 2010 at 11:06 AM, Troy Stephens  wrote:
> Sure.  Let us know if you run into further difficulty with this.

Unfortunately I have indeed hit more difficulty.  I've attached an
updated demo project to the Radar as well as uploaded it to
http://www.lanechng.com/ScrolledLayerHostingView.zip , and despite (I
believe) correctly handing over the layer to AppKit, it still has the
repositioning problem.

Instructions to trigger it:

1. Open the app.
2. Scroll the document around such that the scrollers are left at a
non-zero position.
3. Save the document.
4. Close the document.
5. Reopen the document.

The layer will be positioned incorrectly. :(

I'm hoping I've done something wrong in setting up the layer. Is it
perhaps because of the way I've turned off the redraw policy and set
the layer resizing behavior? The documentation seems to imply that I
have done the correct thing (setting the "resize independently"
behavior and turning off layer redraw).

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

Forcing NSImage to cache images at certain sizes

[B.J. Buchalter]

I read the NSImage and Cocoa drawing guide docs, which tends to  
indicate that calling drawInRect:fromRect:operation:fraction: on an  
NSImage will cause it to create a cached image rep that matches the  
scaled image so that the next time it is drawn it does not need to be  
scaled again.


That is not what I am seeing here, and the scaling is definitely  
taking a nontrivial amount of time when redrawing my views. I have  
played around with setting the caching and scaling on the NSImage, but  
it doesn't appear to be having any impact (the internal image rep for  
the image never changes).


What is the proper way to ensure that the NSImage is cached to match  
the required drawing size? Do I need to build my own cache?


Thanks!

B.J. Buchalter
Metric Halo
http://www.mhlabs.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: Getting TextEdit to Recognise UTF-8 Output

[Greg Guerin]

K.Darcy Otto wrote:

Question: Is there any header I can put at the beginning of the  
text file to get it automatically recognised as UTF-8?



It's not a header, but there is the com.apple.TextEncoding xattribute.

See post #4 in the following thread:
http://forums.macrumors.com/showthread.php?t=839674

  -- GG

___

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: migrating CoreData data model doesn't work

[Gustavo Pizano]

Hehee,, it makes me remember EOVelocity .. or the Wonder generators from 
WebObjects

On 21.5.2010, at 20:54, Hal Mueller wrote:

> MOGenerator (from Wolf Rentzsch) is one solution to this problem. It uses one 
> file for human-written custom code, another file for machine-generated 
> boilerplate code.
> 
> http://github.com/rentzsch/mogenerator
> 
> Hal
> 
> On May 21, 2010, at 4:53 AM, Gustavo Pizano wrote:
> 
>> Now if you have custom methods in your MO's then what I do is that I don't 
>> delete, or create a new one, but simply add by had the new(s) attributes I 
>> set in the new model version. Im pretty sure there i another way to do this,
> 

___

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: Getting TextEdit to Recognise UTF-8 Output

[Sixten Otto]

On Fri, May 21, 2010 at 3:42 PM, K.Darcy Otto  wrote:
> I've tried prefacing the text file with a BOM in this way:

You may well already know this, and that may be something you're
attempting out of desperation, but:

"The endian order entry for UTF-8 in Table 2-4 is marked N/A because
UTF-8 code units
are 8 bits in size, and the usual machine issues of endian order for
larger code units do not
apply. The serialized order of the bytes must not depart from the
order defined by the UTF-
8 encoding form. Use of a BOM is neither required nor recommended for
UTF-8, but may
be encountered in contexts where UTF-8 data is converted from other
encoding forms that
use a BOM or where the BOM is used as a UTF-8 signature. See the “Byte
Order Mark”
subsection in Section 16.8, Specials, for more information."

http://www.unicode.org/versions/Unicode5.0.0/ch02.pdf, p36
___

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: Getting TextEdit to Recognise UTF-8 Output

[Gus Mueller]

On May 21, 2010, at 12:42 PM, K.Darcy Otto wrote:

> [textStream appendFormat:@"%C%C%C",0x00EF,0x00BB,0x00BF]; // textStream is an 
> empty NSMutableString that gets added to, and then written to a file


How are you writing the string to a file?  Are you using NSString's 
writeToFile:atomically:?  I'm pretty sure that doesn't write it out as UTF8.  
You'll probably want to use writeToFile:atomically:encoding:error: with 
NSUTF8StringEncoding as the encoding if you aren't already.

-gus

--  

August 'Gus' Mueller
Flying Meat Inc.
http://flyingmeat.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

Getting TextEdit to Recognise UTF-8 Output

[K . Darcy Otto]

I'm working on a feature that will see my program automatically export to a 
UTF-8 text file.  This process works fine. What doesn't work fine is that 
TextEdit.app (and others) does not recognise it automatically as a UTF-8 text 
file, even when "Plain Text Encoding: Opening Files:" (in Preferences) is set 
to "Automatic".

Question: Is there any header I can put at the beginning of the text file to 
get it automatically recognised as UTF-8? 

Here is some background, and what I'm trying to do:

T.txt - a UTF-8 file:

1. When opened in TextEdit, UTF-8 is not detected.
2. When opened in Pages, UTF-8 is not detected.
3. When opened in TextMate, UTF-8 is detected.
4. When opened in MacVim, UTF-8 is detected.

If I rename T.txt to T.utf8:

1. When opened in TextEdit, UTF-8 is detected.
2. When opened in Pages, file is not loaded.
3. When opened in TextMate, UTF-8 is detected.
4. When opened in MacVim, UTF-8 is detected.

What I need is for TextEdit to open it properly, with the .txt extension (I 
include the rest just for comparison). I can get TextEdit to do this if I set 
"Plain Text Encoding: Opening Files:" to "UTF-8". But I'd rather not have my 
users make this change if not absolutely necessary (it screams support issues). 
I've tried prefacing the text file with a BOM in this way:

[textStream appendFormat:@"%C%C%C",0x00EF,0x00BB,0x00BF]; // textStream is an 
empty NSMutableString that gets added to, and then written to a file

Is there any way to do what I'm trying to do?  
Thanks.___

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

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

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

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

Re: migrating CoreData data model doesn't work

[Hal Mueller]

MOGenerator (from Wolf Rentzsch) is one solution to this problem. It uses one 
file for human-written custom code, another file for machine-generated 
boilerplate code.

http://github.com/rentzsch/mogenerator

Hal

On May 21, 2010, at 4:53 AM, Gustavo Pizano wrote:

> Now if you have custom methods in your MO's then what I do is that I don't 
> delete, or create a new one, but simply add by had the new(s) attributes I 
> set in the new model version. Im pretty sure there i another way to do this,

___

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: NSXMLParser initWIthData - Encoding?

[Scott Anguish]

On May 21, 2010, at 1:52 PM, Patrick Rutkowski wrote:

> When docs are bad, and I'm frustrated, I might throw out a mild pejorative; 
> it's a reflex, sorry :-/
> 

You were warned by an Apple employee (David Duncan) that your tone wasn’t going 
to get you help. 

Behavior on the list is expected to be at a minimum polite and, preferably, 
professional.

> When someone who ought to see that I'm rightfully frustrated by bad docs 
> tells me to change my tone, I'll start throwing out more serious pejoratives, 
> and for that I'm not sorry. I don't like being ordered around by strangers.

None the less, this type of behavior (and even worse comments made to list 
members off-list) are cause for moderation.

Scott Anguish
Moderator___

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 model persistence, independent of document

[James Maxwell]

Looking over the type of model I want to build for my music app, I realized 
that perhaps Core Data would be a good way to manage it. The reason being that 
I want an arbitrary number of "Instruments", each of which has a MIDI port, 
channel, and an arbitrary number of "Articulations." The total set of 
user-defined Articulations is stored in an "Articulation Library", so that the 
user can create articulations, and assign them to whatever instruments they 
desire. Given these relationships, Core Data seemed reasonable...
 
I built a model that seems about right, to me, but I can't seem to bind it to 
anything without getting the "this class is not key value coding-compliant for 
the key managedObjectContext" error. I've been looking around at various Core 
Data tutorials, and I noticed that they're either for document-based apps, or 
they're created from a template, which I guess must provide the appropriate 
AppDelegate (at least, that's implied by one of the tutorials, at mactech.com). 
My app is document-based, but I don't want this data stored with the document 
-- it should persist across all documents, pretty much like a user default (and 
besides, I'm subclassing GCDrawKit's "DKDrawingDocument" already). 
I get the same error when binding to Shared User Defaults, so I'm kinda 
stumped...

thanks,

J.


James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca

___

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: Layer-hosting views and layer-backed scroll views

[Kyle Sluder]

On Fri, May 21, 2010 at 11:06 AM, Troy Stephens  wrote:
> You can use geometryFlipped on your documentView's layer for this purpose, if 
> and only if your documentView isn't going to have any subviews.  If you 
> control all the content (build it out of your own layers) from there on down, 
> you're OK.  If AppKit has to position subview backing layers within the 
> documentView's layer, it won't take the geometryFlipped setting into account 
> and the positioning won't turn out right.

We're already following David's advice and putting our field editors
in a companion layer-backed view that is a peer of our document view
(but whose layer we don't disturb). But it was briefly funny when
field editors would appear upside down and at the opposite end of the
document from the content they were editing. :)

> You should never modify the anchorPoint of a view backing layer.  If you 
> modify your code to override -makeBackingLayer, AppKit will set the returned 
> layer's anchorPoint automatically the way it wants it (to (0,1) if the 
> superview is flipped, or (0,0) if the superview is unflipped).

Hmm. Are we free to move the bounds origin, though? We always want to
put the layer's bounds origin at the upper left, and for one instance
of this view we want to inset the origin by about 20px. This has
wreaked havoc with AppKit's custom layer content provider (which
apparently maps layer positions directly to CGImageSource points for
the purposes of calling -drawRect:, and has trouble when either
coordinate is negative). The result was a black 20px-wide stripe down
the left side of the view.

We did solve this at one point (when we were still abusing
layer-backed drawing) by turning off drawsBackground on the scroll
view, and inserting a custom sublayer with a background color. Then
AppKit's image source isn't invoked at all (or if it is, it doesn't
draw anything, and then our sublayer draws on top of it). I suppose if
I return my own layer from -makeBackingLayer, then AppKit won't attach
its image source since it won't be trying to hook up the -drawRect:
rendering path?

>>> Arguably it would actually be OK for us to modify the layer's position in 
>>> this case (and clearly our "hands off" policy isn't quite consistent about 
>>> this, since, as you noted, scrolling will "fix" the incorrect document 
>>> layer position).
>>
>> The inconsistency is what's so maddening. I thought I had just failed
>> to do something on initialization.
>
> We'll look at improving the consistency of this behavior.

Thanks.

> Once you're using -makeBackingLayer, just size the documentView the way you 
> want it, and let AppKit automatically resize the layer to match.

If AppKit does in fact try to attach an image source to the layer
returned by -makeBackingLayer, then we need to match our
background-fill sublayer's size, but that's made a heck of a lot
easier by being able to return a layer with a custom
-resizeSublayersWithOldSize: implementation. Or, at the very worst,
our background-fill layer could listen for bounds KVO from the
view-backing layer.

--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: Layer-hosting views and layer-backed scroll views

[Troy Stephens]

On May 21, 2010, at 10:52 AM, Kyle Sluder wrote:
> On Fri, May 21, 2010 at 10:37 AM, Troy Stephens  wrote:
>> CALayers don't support the same notion of "flippedness" that NSView's 
>> geometry model uses.  (CALayer's "geometryFlipped" property is recursive in 
>> its effect, so isn't semantically identical.)
> 
> Hmm. Perhaps instead of using geometryFlipped on our layer, we should
> manually calculate the bounds rectangle as appropriate? Or would
> setting the anchor point to (0,1) suffice? Basically, we want to lay
> out our contents like a text view would, which means that we want our
> first row of stuff (which is contained in a child layer) to appear at
> the upper left of the view, which should be at (0,0) in the layer's
> bounds coordinate space.

You can use geometryFlipped on your documentView's layer for this purpose, if 
and only if your documentView isn't going to have any subviews.  If you control 
all the content (build it out of your own layers) from there on down, you're 
OK.  If AppKit has to position subview backing layers within the documentView's 
layer, it won't take the geometryFlipped setting into account and the 
positioning won't turn out right.

You should never modify the anchorPoint of a view backing layer.  If you modify 
your code to override -makeBackingLayer, AppKit will set the returned layer's 
anchorPoint automatically the way it wants it (to (0,1) if the superview is 
flipped, or (0,0) if the superview is unflipped).

>> Therefore, whenever AppKit resizes the backing layer of a flipped NSView, we 
>> have to compute and assign new "position" values for its sublayers, to keep 
>> them in the same place relative to the top left.  (Don't count on this not 
>> changing in a future release, but for debugging purposes you can look for 
>> -_updateSublayerPositionsForFlippedSuperview, which gets invoked from 
>> -setFrameSize:)
>> 
>> We do this for sublayers that we created and therefore consider ourselves to 
>> "own", but in your test app you're instantiating and assigning a layer of 
>> your own to the documentView.  Therefore, when we resize the ClipView's 
>> backing layer (and the ClipView is flipped, because it always matches the 
>> flippedness of the ScrollView's documentView), we don't touch the position 
>> of your documentView's layer.  (If you modify your example to omit the 
>> custom layer creation and -setLayer:, and instead override -drawRect: to 
>> draw your content into the view's AppKit-provided backing layer, you'll see 
>> the problem goes away.)
> 
> Indeed it does. :) I had tested that, and was actually contemplating
> adding a button to toggle that behavior, but I wound up heading down
> the road of "rewrite NSScrollView using CAScrollLayer" instead.

There should be no need for that.  Just change your backing layer instantiation 
to user -makeBackingLayer.

>> Arguably it would actually be OK for us to modify the layer's position in 
>> this case (and clearly our "hands off" policy isn't quite consistent about 
>> this, since, as you noted, scrolling will "fix" the incorrect document layer 
>> position).
> 
> The inconsistency is what's so maddening. I thought I had just failed
> to do something on initialization.

We'll look at improving the consistency of this behavior.

>> Meanwhile, the simplest solution, if you require a custom backing layer, is 
>> to override NSView's -makeBackingLayer method (added in 10.6) to instantiate 
>> and return your (autoreleased) layer.  When layer instantiation goes through 
>> this path, AppKit considers the layer AppKit-owned, so you won't run into 
>> the positioning problem.
> 
> I can't believe we've overlooked this method. We do, however, need to
> resize the layer vertically as our document grows/shrinks, and we need
> it to always be at least as high as the visible area of the scroll
> view. Does this have the same potential for conflict with AppKit's
> layer resizing? (Or perhaps if we just resize the view to the
> appropriate size, this entire question just goes away. But that can't
> be right, it doesn't involve impossible contortions and overriding
> private methods! )

Once you're using -makeBackingLayer, just size the documentView the way you 
want it, and let AppKit automatically resize the layer to match.

For "document view should always be at least as big as the clip area" behavior, 
you'll want to monitor the ClipView for size changes, and resize the 
documentView as desired in response.

>> By the way: I don't know whether CAGradientLayer disregards -setNeedsDisplay 
>> (since the layer renders its content programmatically), possibly making this 
>> irrelevant in practice, but in cases like this, where you provide a layer of 
>> your own that already has content, and you don't want AppKit to ever invoke 
>> the view's -drawRect: to draw view content into the layer, it's a good idea 
>> to -setLayerContentsRedrawPolicy:NSViewLayerContentsRedrawNever on the view.
> 
> The CAGradientLayer is a red 

Re: Layer-hosting views and layer-backed scroll views

[Kyle Sluder]

On Fri, May 21, 2010 at 10:37 AM, Troy Stephens  wrote:
> CALayers don't support the same notion of "flippedness" that NSView's 
> geometry model uses.  (CALayer's "geometryFlipped" property is recursive in 
> its effect, so isn't semantically identical.)

Hmm. Perhaps instead of using geometryFlipped on our layer, we should
manually calculate the bounds rectangle as appropriate? Or would
setting the anchor point to (0,1) suffice? Basically, we want to lay
out our contents like a text view would, which means that we want our
first row of stuff (which is contained in a child layer) to appear at
the upper left of the view, which should be at (0,0) in the layer's
bounds coordinate space.

> Therefore, whenever AppKit resizes the backing layer of a flipped NSView, we 
> have to compute and assign new "position" values for its sublayers, to keep 
> them in the same place relative to the top left.  (Don't count on this not 
> changing in a future release, but for debugging purposes you can look for 
> -_updateSublayerPositionsForFlippedSuperview, which gets invoked from 
> -setFrameSize:)
>
> We do this for sublayers that we created and therefore consider ourselves to 
> "own", but in your test app you're instantiating and assigning a layer of 
> your own to the documentView.  Therefore, when we resize the ClipView's 
> backing layer (and the ClipView is flipped, because it always matches the 
> flippedness of the ScrollView's documentView), we don't touch the position of 
> your documentView's layer.  (If you modify your example to omit the custom 
> layer creation and -setLayer:, and instead override -drawRect: to draw your 
> content into the view's AppKit-provided backing layer, you'll see the problem 
> goes away.)

Indeed it does. :) I had tested that, and was actually contemplating
adding a button to toggle that behavior, but I wound up heading down
the road of "rewrite NSScrollView using CAScrollLayer" instead.

> Arguably it would actually be OK for us to modify the layer's position in 
> this case (and clearly our "hands off" policy isn't quite consistent about 
> this, since, as you noted, scrolling will "fix" the incorrect document layer 
> position).

The inconsistency is what's so maddening. I thought I had just failed
to do something on initialization.

> Meanwhile, the simplest solution, if you require a custom backing layer, is 
> to override NSView's -makeBackingLayer method (added in 10.6) to instantiate 
> and return your (autoreleased) layer.  When layer instantiation goes through 
> this path, AppKit considers the layer AppKit-owned, so you won't run into the 
> positioning problem.

I can't believe we've overlooked this method. We do, however, need to
resize the layer vertically as our document grows/shrinks, and we need
it to always be at least as high as the visible area of the scroll
view. Does this have the same potential for conflict with AppKit's
layer resizing? (Or perhaps if we just resize the view to the
appropriate size, this entire question just goes away. But that can't
be right, it doesn't involve impossible contortions and overriding
private methods! )

> By the way: I don't know whether CAGradientLayer disregards -setNeedsDisplay 
> (since the layer renders its content programmatically), possibly making this 
> irrelevant in practice, but in cases like this, where you provide a layer of 
> your own that already has content, and you don't want AppKit to ever invoke 
> the view's -drawRect: to draw view content into the layer, it's a good idea 
> to -setLayerContentsRedrawPolicy:NSViewLayerContentsRedrawNever on the view.

The CAGradientLayer is a red herring that I was using to visually
establish which end of the layer was "up."

You and David have been thoroughly amazing with your help. Thanks so much!

--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: NSXMLParser initWIthData - Encoding?

[Patrick Rutkowski]

On May 21, 2010, at 1:29 PM, David Duncan wrote:

> On May 21, 2010, at 10:23 AM, Patrick Rutkowski wrote:
> 
>> Any API that accepts binary data needs to give at least a hint as to what 
>> format the binary data should be. Saying that just it accepts "data" is 
>> disgusting. Period, end of argument.
> 
> The problem is that XML specifies the text encoding inside of the XML itself. 
> Technically it is not possible to know the true encoding of an XML file until 
> you have started parsing the file, hence you cannot actually specify the 
> correct encoding before that point.
> 
> The API is doing what is appropriate for the technology. An "encoding" 
> variant would at best be a hint as to how to start parsing before you get the 
> actual encoding and switch encodings, and at worst would be a complete lie as 
> to what encoding to use.

Ah, right; that all rings a bell now. I think I remember that line from my 
HTML days, way back when. Thanks :-)

> 
>> If you want to advocate that it's perfectly fine to omit information about 
>> the format of binary data, then you're just a moron. I'm not saying that 
>> you're a moron for accidentally forgetting to document it, but if you want 
>> to say (as you seem to be doing) that it's OK to consciously leave it out, 
>> then you're just a moron.
> 
> Insulting people is not a good way to get help on a public mailing list.

When docs are bad, and I'm frustrated, I might throw out a mild pejorative; 
it's a reflex, sorry :-/

When someone who ought to see that I'm rightfully frustrated by bad docs tells 
me to change my tone, I'll start throwing out more serious pejoratives, and for 
that I'm not sorry. I don't like being ordered around by strangers.

> --
> David Duncan
> Apple DTS Animation and Printing
> 

-Patrick

___

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: NSXMLParser initWIthData - Encoding?

[Patrick Rutkowski]

On May 21, 2010, at 1:31 PM, Kyle Sluder wrote:

> On Fri, May 21, 2010 at 10:23 AM, Patrick Rutkowski  
> wrote:
>> Milder tone? No thanks.
> 
> Awfully strong words from someone who waltzes onto a mailing list,
> lambastes the documentation, and admits in the very next sentence he
> has no idea what he's talking about.

Don't be telling me to not lambast documentation that leaves out obviously 
critical information.

In fact, don't be ordering me around general, thank you very much.


>> 
>> Any API that accepts binary data needs to give at least a hint as to what 
>> format the binary data should be. Saying that just it accepts "data" is 
>> disgusting. Period, end of argument.
> 
> Did you read the spec that tells you how encodings are deduced from
> unhinted data?

I have now, but it's for us XML admitted newbies that the doc section for 
initWithData ought to mention such about how the encoding detection works. THE 
API IS ACCEPTING BINARY DATA FOR CRYING OUT LOUD! 


> 
>> If you want to advocate that it's perfectly fine to omit information about 
>> the format of binary data, then you're just a moron. I'm not saying that 
>> you're a moron for accidentally forgetting to document it, but if you want 
>> to say (as you seem to be doing) that it's OK to consciously leave it out, 
>> then you're just a moron.
> 
> I've referred you to the moderator for being a disruptive jerk.
> 

I'd like to properly respond to this with a few choice words, but I think I'd 
get banned from the list if I did.

Don't be telling people who are already frustrated by bad docs to "change their 
tone". And if you do then don't be surprised when they get even more aggravated.

> --Kyle Sluder

-Patrick

___

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: NSXMLParser initWIthData - Encoding?

[Gary L. Wade]

You can read more about the XML spec here:

http://www.w3.org/standards/xml/

Citing your other example, the PNG specification is here:

http://www.w3.org/TR/PNG/

>From the documentation, you can learn how the character set is specified in
XML and how PNG data is stored, be that in 24-bit, 8-bit, interlaced, etc.

On 05/21/2010 10:34 AM, "Patrick Rutkowski"  wrote:

> I really hope you're joking.
> 
> Do you really not see that it's completely non-obvious if it's supposed to be
> UTF-8 or UTF-16?
> 
> -Patrick
> 
> On May 21, 2010, at 1:31 PM, Gary L. Wade wrote:
> 
>> The name of the class makes it pretty obvious to everyone that the data is
>> XML.
>> 
>> On 05/21/2010 10:23 AM, "Patrick Rutkowski"  wrote:
>> 
>>> Milder tone? No thanks.
>>> 
>>> Any API that accepts binary data needs to give at least a hint as to what
>>> format the binary data should be. Saying that just it accepts "data" is
>>> disgusting. Period, end of argument.
>>> 
>>> Actually, maybe there is one more thing to be said:
>>> 
>>> Perhaps if the class is something like PNGImage then you can have an
>>> initWithData method which says that it accepts just "data", because in that
>>> that case it's plainly obviously what format it's supposed to be. But this
>>> isn't such a case.
>>> 
>>> If you want to advocate that it's perfectly fine to omit information about
>>> the
>>> format of binary data, then you're just a moron. I'm not saying that you're
>>> a
>>> moron for accidentally forgetting to document it, but if you want to say (as
>>> you seem to be doing) that it's OK to consciously leave it out, then you're
>>> just a moron.
>>> 
>>> -Patrick
>>> 
>>> On May 21, 2010, at 1:07 PM, Kyle Sluder wrote:
>>> 
 On Fri, May 21, 2010 at 9:39 AM, Patrick Rutkowski 
 wrote:
> I find it disgusting that the doc section for NSXMLParser initWithData
> takes
> binary data, but doesn't tell you which encoding it's supposed to be?
> 
> Link:
> http://developer.apple.com/mac/library/documentation/cocoa/reference/found
> at
> ion/Classes/NSXMLParser_Class/Reference/Reference.html#//apple_ref/occ/ins
> tm
> /NSXMLParser/initWithData:
> 
> I'm still pretty new to XML though, does the encoding always have to be
> UTF-8, or perhaps always UTF-16?
 
 You find it "disgusting," yet you admit you're new? Perhaps a milder
 tone is warranted here?
 
> Either way, which encoding does initWithData expect to get? Does it
> perhaps
> detect which encoding is being used, based on the data you give it?
 
 Please read the relevant section of the XML spec, keeping in mind that
 it is non-normative:
 
 http://www.w3.org/TR/REC-xml/#sec-guessing
 
 --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: Layer-hosting views and layer-backed scroll views

[David Duncan]

On May 21, 2010, at 10:37 AM, Troy Stephens wrote:

> By the way: I don't know whether CAGradientLayer disregards -setNeedsDisplay 
> (since the layer renders its content programmatically), possibly making this 
> irrelevant in practice, but in cases like this, where you provide a layer of 
> your own that already has content, and you don't want AppKit to ever invoke 
> the view's -drawRect: to draw view content into the layer, it's a good idea 
> to -setLayerContentsRedrawPolicy:NSViewLayerContentsRedrawNever on the view.


The CAGradientLayer (and the CAShapeLayer) both respect -setNeedsDisplay and go 
through the normal CG drawing path, so it would definitely be recommended to 
specify the never redraw policy.
--
David Duncan
Apple DTS Animation and Printing

___

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: Layer-hosting views and layer-backed scroll views

[Troy Stephens]

Hi Kyle,

On May 20, 2010, at 12:12 PM, Kyle Sluder wrote:
> On Thu, May 20, 2010 at 9:52 AM, Kyle Sluder  wrote:
>> I have uploaded a sample project to
>> http://www.lanechng.com/ScrolledLayerHostingView.zip. Resize the
>> window to see the problem in action; then click one of the scroll
>> arrows to see it fix itself.
> 
> Well, I've filed rdar://problem/8009542 with this demo project
> attached. I've also been informed that IKImageBrowserView isn't
> flipped, perhaps because of this very same issue. It's also the only
> class besides NSView to implement _updateLayerGeometryFromView.
> Needless to say, I'm more than a little suspicious that scroll views
> are just plain broken.
> 
> --Kyle Sluder

CALayers don't support the same notion of "flippedness" that NSView's geometry 
model uses.  (CALayer's "geometryFlipped" property is recursive in its effect, 
so isn't semantically identical.)

Therefore, whenever AppKit resizes the backing layer of a flipped NSView, we 
have to compute and assign new "position" values for its sublayers, to keep 
them in the same place relative to the top left.  (Don't count on this not 
changing in a future release, but for debugging purposes you can look for 
-_updateSublayerPositionsForFlippedSuperview, which gets invoked from 
-setFrameSize:)

We do this for sublayers that we created and therefore consider ourselves to 
"own", but in your test app you're instantiating and assigning a layer of your 
own to the documentView.  Therefore, when we resize the ClipView's backing 
layer (and the ClipView is flipped, because it always matches the flippedness 
of the ScrollView's documentView), we don't touch the position of your 
documentView's layer.  (If you modify your example to omit the custom layer 
creation and -setLayer:, and instead override -drawRect: to draw your content 
into the view's AppKit-provided backing layer, you'll see the problem goes 
away.)

Arguably it would actually be OK for us to modify the layer's position in this 
case (and clearly our "hands off" policy isn't quite consistent about this, 
since, as you noted, scrolling will "fix" the incorrect document layer 
position).

Meanwhile, the simplest solution, if you require a custom backing layer, is to 
override NSView's -makeBackingLayer method (added in 10.6) to instantiate and 
return your (autoreleased) layer.  When layer instantiation goes through this 
path, AppKit considers the layer AppKit-owned, so you won't run into the 
positioning problem.

By the way: I don't know whether CAGradientLayer disregards -setNeedsDisplay 
(since the layer renders its content programmatically), possibly making this 
irrelevant in practice, but in cases like this, where you provide a layer of 
your own that already has content, and you don't want AppKit to ever invoke the 
view's -drawRect: to draw view content into the layer, it's a good idea to 
-setLayerContentsRedrawPolicy:NSViewLayerContentsRedrawNever on the view.

Troy Stephens
AppKit

___

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: NSXMLParser initWIthData - Encoding?

[Patrick Rutkowski]

I really hope you're joking.

Do you really not see that it's completely non-obvious if it's supposed to be 
UTF-8 or UTF-16?

-Patrick

On May 21, 2010, at 1:31 PM, Gary L. Wade wrote:

> The name of the class makes it pretty obvious to everyone that the data is
> XML.
> 
> On 05/21/2010 10:23 AM, "Patrick Rutkowski"  wrote:
> 
>> Milder tone? No thanks.
>> 
>> Any API that accepts binary data needs to give at least a hint as to what
>> format the binary data should be. Saying that just it accepts "data" is
>> disgusting. Period, end of argument.
>> 
>> Actually, maybe there is one more thing to be said:
>> 
>> Perhaps if the class is something like PNGImage then you can have an
>> initWithData method which says that it accepts just "data", because in that
>> that case it's plainly obviously what format it's supposed to be. But this
>> isn't such a case.
>> 
>> If you want to advocate that it's perfectly fine to omit information about 
>> the
>> format of binary data, then you're just a moron. I'm not saying that you're a
>> moron for accidentally forgetting to document it, but if you want to say (as
>> you seem to be doing) that it's OK to consciously leave it out, then you're
>> just a moron.
>> 
>> -Patrick
>> 
>> On May 21, 2010, at 1:07 PM, Kyle Sluder wrote:
>> 
>>> On Fri, May 21, 2010 at 9:39 AM, Patrick Rutkowski 
>>> wrote:
 I find it disgusting that the doc section for NSXMLParser initWithData 
 takes
 binary data, but doesn't tell you which encoding it's supposed to be?
 
 Link:
 http://developer.apple.com/mac/library/documentation/cocoa/reference/foundat
 ion/Classes/NSXMLParser_Class/Reference/Reference.html#//apple_ref/occ/instm
 /NSXMLParser/initWithData:
 
 I'm still pretty new to XML though, does the encoding always have to be
 UTF-8, or perhaps always UTF-16?
>>> 
>>> You find it "disgusting," yet you admit you're new? Perhaps a milder
>>> tone is warranted here?
>>> 
 Either way, which encoding does initWithData expect to get? Does it perhaps
 detect which encoding is being used, based on the data you give it?
>>> 
>>> Please read the relevant section of the XML spec, keeping in mind that
>>> it is non-normative:
>>> 
>>> http://www.w3.org/TR/REC-xml/#sec-guessing
>>> 
>>> --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: NSXMLParser initWIthData - Encoding?

[Kyle Sluder]

On Fri, May 21, 2010 at 10:23 AM, Patrick Rutkowski  wrote:
> Milder tone? No thanks.

Awfully strong words from someone who waltzes onto a mailing list,
lambastes the documentation, and admits in the very next sentence he
has no idea what he's talking about.

>
> Any API that accepts binary data needs to give at least a hint as to what 
> format the binary data should be. Saying that just it accepts "data" is 
> disgusting. Period, end of argument.

Did you read the spec that tells you how encodings are deduced from
unhinted data?

> If you want to advocate that it's perfectly fine to omit information about 
> the format of binary data, then you're just a moron. I'm not saying that 
> you're a moron for accidentally forgetting to document it, but if you want to 
> say (as you seem to be doing) that it's OK to consciously leave it out, then 
> you're just a moron.

I've referred you to the moderator for being a disruptive jerk.

--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: NSXMLParser initWIthData - Encoding?

[David Duncan]

On May 21, 2010, at 10:23 AM, Patrick Rutkowski wrote:

> Any API that accepts binary data needs to give at least a hint as to what 
> format the binary data should be. Saying that just it accepts "data" is 
> disgusting. Period, end of argument.

The problem is that XML specifies the text encoding inside of the XML itself. 
Technically it is not possible to know the true encoding of an XML file until 
you have started parsing the file, hence you cannot actually specify the 
correct encoding before that point.

The API is doing what is appropriate for the technology. An "encoding" variant 
would at best be a hint as to how to start parsing before you get the actual 
encoding and switch encodings, and at worst would be a complete lie as to what 
encoding to use.

> If you want to advocate that it's perfectly fine to omit information about 
> the format of binary data, then you're just a moron. I'm not saying that 
> you're a moron for accidentally forgetting to document it, but if you want to 
> say (as you seem to be doing) that it's OK to consciously leave it out, then 
> you're just a moron.

Insulting people is not a good way to get help on a public mailing list.
--
David Duncan
Apple DTS Animation and Printing

___

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: NSXMLParser initWIthData - Encoding?

[Patrick Rutkowski]

Milder tone? No thanks.

Any API that accepts binary data needs to give at least a hint as to what 
format the binary data should be. Saying that just it accepts "data" is 
disgusting. Period, end of argument.

Actually, maybe there is one more thing to be said:

Perhaps if the class is something like PNGImage then you can have an 
initWithData method which says that it accepts just "data", because in that 
that case it's plainly obviously what format it's supposed to be. But this 
isn't such a case.

If you want to advocate that it's perfectly fine to omit information about the 
format of binary data, then you're just a moron. I'm not saying that you're a 
moron for accidentally forgetting to document it, but if you want to say (as 
you seem to be doing) that it's OK to consciously leave it out, then you're 
just a moron.

-Patrick

On May 21, 2010, at 1:07 PM, Kyle Sluder wrote:

> On Fri, May 21, 2010 at 9:39 AM, Patrick Rutkowski  wrote:
>> I find it disgusting that the doc section for NSXMLParser initWithData takes 
>> binary data, but doesn't tell you which encoding it's supposed to be?
>> 
>> Link:
>> http://developer.apple.com/mac/library/documentation/cocoa/reference/foundation/Classes/NSXMLParser_Class/Reference/Reference.html#//apple_ref/occ/instm/NSXMLParser/initWithData:
>> 
>> I'm still pretty new to XML though, does the encoding always have to be 
>> UTF-8, or perhaps always UTF-16?
> 
> You find it "disgusting," yet you admit you're new? Perhaps a milder
> tone is warranted here?
> 
>> Either way, which encoding does initWithData expect to get? Does it perhaps 
>> detect which encoding is being used, based on the data you give it?
> 
> Please read the relevant section of the XML spec, keeping in mind that
> it is non-normative:
> 
> http://www.w3.org/TR/REC-xml/#sec-guessing
> 
> --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: NSXMLParser initWIthData - Encoding?

[Kyle Sluder]

On Fri, May 21, 2010 at 9:39 AM, Patrick Rutkowski  wrote:
> I find it disgusting that the doc section for NSXMLParser initWithData takes 
> binary data, but doesn't tell you which encoding it's supposed to be?
>
> Link:
> http://developer.apple.com/mac/library/documentation/cocoa/reference/foundation/Classes/NSXMLParser_Class/Reference/Reference.html#//apple_ref/occ/instm/NSXMLParser/initWithData:
>
> I'm still pretty new to XML though, does the encoding always have to be 
> UTF-8, or perhaps always UTF-16?

You find it "disgusting," yet you admit you're new? Perhaps a milder
tone is warranted here?

> Either way, which encoding does initWithData expect to get? Does it perhaps 
> detect which encoding is being used, based on the data you give it?

Please read the relevant section of the XML spec, keeping in mind that
it is non-normative:

http://www.w3.org/TR/REC-xml/#sec-guessing

--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: NSXMLParser initWIthData - Encoding?

[Keary Suska]

On May 21, 2010, at 10:39 AM, Patrick Rutkowski wrote:

> I find it disgusting that the doc section for NSXMLParser initWithData takes 
> binary data, but doesn't tell you which encoding it's supposed to be?
> 
> Link:
> http://developer.apple.com/mac/library/documentation/cocoa/reference/foundation/Classes/NSXMLParser_Class/Reference/Reference.html#//apple_ref/occ/instm/NSXMLParser/initWithData:
> 
> I'm still pretty new to XML though, does the encoding always have to be 
> UTF-8, or perhaps always UTF-16?
> 
> Either way, which encoding does initWithData expect to get? Does it perhaps 
> detect which encoding is being used, based on the data you give it?

I imagine that it expects the encoding to match the doctype declaration. 
Whether it does any conversions is just gravy--my understanding of the XML spec 
is that parsers aren't expected to do any encoding conversions.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

___

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

NSXMLParser initWIthData - Encoding?

[Patrick Rutkowski]

I find it disgusting that the doc section for NSXMLParser initWithData takes 
binary data, but doesn't tell you which encoding it's supposed to be?

Link:
http://developer.apple.com/mac/library/documentation/cocoa/reference/foundation/Classes/NSXMLParser_Class/Reference/Reference.html#//apple_ref/occ/instm/NSXMLParser/initWithData:

I'm still pretty new to XML though, does the encoding always have to be UTF-8, 
or perhaps always UTF-16?

Either way, which encoding does initWithData expect to get? Does it perhaps 
detect which encoding is being used, based on the data you give it?

-Patrick

___

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

NSWindow dataWithEPSInsideRect: giving error on 10.5

[David Alter]

I have a NSWindow that when I call dataWithEPSInsideRect: on it, I get the
following error appearing in the Console.

: CMSStreamPSDefinition : CMGetPS2ColorSpace: returned -4200

I only get the error if it is running on 10.5. It works great on 10.6

What I'm trying to do is create an image of the window. Here is the code.

NSData * data = [myWindow dataWithEPSInsideRect: rect];
NSImage * image = [[[NSImage alloc] initWithData:data] autorelease];

I'm not sure why I'm getting the error. Also the NSData returned on 10.5
does not build a sufficient image.
1) Is there something I can do to prevent this error from happening and get
the correct NSData to make an image?

2) Maybe there is a better way to capture an image of a window. This method
of creating the image of the window is very slow. I would be interested in
alternatives.

Thank you for the help
-dave
___

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

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

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

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

Re: iPhone/iPad: Desktop wallpaper can't be set.

[Alex Kac]

In many ways true. This is not one of them. I can see many valid reasons to do 
this.

On May 21, 2010, at 11:13 AM, Kyle Sluder wrote:

> On Fri, May 21, 2010 at 7:52 AM, Alex Kac  wrote:
>> Don't limit the users just because you don't want something. Its not being 
>> forced.
> 
> One of the best things about the Mac ecosystem is that developers are
> willing to stand up to users. Otherwise you wind up with kitchen-sink
> software.
> 
> --Kyle Sluder

Alex Kac - President and Founder
Web Information Solutions, Inc.

"The person who is not hungry says that the coconut has a hard shell."
-- African Tribal Saying





___

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: iPhone/iPad: Desktop wallpaper can't be set.

[Kyle Sluder]

On Fri, May 21, 2010 at 7:52 AM, Alex Kac  wrote:
> Don't limit the users just because you don't want something. Its not being 
> forced.

One of the best things about the Mac ecosystem is that developers are
willing to stand up to users. Otherwise you wind up with kitchen-sink
software.

--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: Calling allObjects memory allocation problem

[Jean-Daniel Dupas]

Le 21 mai 2010 à 17:54, Keary Suska a écrit :

> On May 21, 2010, at 9:18 AM, Paul Sanders wrote:
> 
>>> Also be aware that just because memory is released, doesn't mean it is 
>>> returned to the system (e.g. you will not
>>> see your apps memory usage go down in Activity Monitor). In fact,  AFAIK, 
>>> it is never returned to the system,
>>> except perhaps in low memory situations.
>> 
>> I don't actually think that's true.  At least, it's not what I observe.  I 
>> think it's more accurate to say that you cannot predict when memory which 
>> has been allocated and then freed will be returned to the operating system, 
>> nor how much.  It happens, I believe, in 4k pages, but probably not one at a 
>> time and will be heavily dependent on fragmentation of the process's heap.  
>> No doubt there is much more to know.
>> 
>> I agree with the sentiment of keeping an eye on your peak memory usage.  I 
>> use Instruments for this, and it found one instance where memory usage was 
>> creeping steadily up when the app was playing audio but otherwise idle.
> 
> Maybe AFAIK should be "As Far As I have Observed", as although using tools 
> like instruments I have seen constant tiny increases and decreases, I have 
> yet to see peak memory reduce over the lifetime of an application. 
> Fragmentation could certainly play a role--I don't know of any means to check 
> that. If this truly is the issue most of the time, it seems to me that for 
> most practical points and purposes that the memory won't get returned anyway, 
> as fragmentation seems to be so common. 

The heap and vmmap command line tools can give you some interesting values. 
(like the % of used memory in each malloc zone, and other useful stats)


-- Jean-Daniel




___

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

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

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

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

Re: Calling allObjects memory allocation problem

[Keary Suska]

On May 21, 2010, at 9:18 AM, Paul Sanders wrote:

> > Also be aware that just because memory is released, doesn't mean it is 
> > returned to the system (e.g. you will not
> > see your apps memory usage go down in Activity Monitor). In fact,  AFAIK, 
> > it is never returned to the system,
> > except perhaps in low memory situations.
>  
> I don't actually think that's true.  At least, it's not what I observe.  I 
> think it's more accurate to say that you cannot predict when memory which has 
> been allocated and then freed will be returned to the operating system, nor 
> how much.  It happens, I believe, in 4k pages, but probably not one at a time 
> and will be heavily dependent on fragmentation of the process's heap.  No 
> doubt there is much more to know.
>  
> I agree with the sentiment of keeping an eye on your peak memory usage.  I 
> use Instruments for this, and it found one instance where memory usage was 
> creeping steadily up when the app was playing audio but otherwise idle.

Maybe AFAIK should be "As Far As I have Observed", as although using tools like 
instruments I have seen constant tiny increases and decreases, I have yet to 
see peak memory reduce over the lifetime of an application. Fragmentation could 
certainly play a role--I don't know of any means to check that. If this truly 
is the issue most of the time, it seems to me that for most practical points 
and purposes that the memory won't get returned anyway, as fragmentation seems 
to be so common. 

My main point though, is that if the OP thinks that his array is not getting 
released because he doesn't see memory usage decrease, then he is barking up 
the wrong tree.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

___

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: NSWindowController for Prefs XIB Question (Core Data involved)

[Keary Suska]

On May 21, 2010, at 12:09 AM, Quincey Morris wrote:

> On May 20, 2010, at 20:08, Steve Cronin wrote:
> 
>> if (!prefPanelController) {
>>  prefPanelController = [[PreferencesController alloc] 
>> initWithWindowNibName:@"testPref"];
>>  [prefPanelController setManagedObjectContext:[self 
>> managedObjectContext]];
>> }
>> [prefPanelController showWindow:sender];
>> 
>> No window opens and I get a console error:  Cannot perform operation without 
>> a managed object context
> 
> This could well be a time, or order of things happening, problem.
> 
> At the time the nib is loaded, the MOC property of the controller hasn't been 
> set yet, so the array controller fetches a nil MOC, and throws an exception 
> which aborts the rest of the loading process.
> 
> You probably need to write a custom initializer for your custom window 
> controller and pass the MOC as a parameter, instead of trying to set it later.
> 
> That's my theory, anyway.

This specific issue is unlikely the case, as NSWindowController lazily loads 
its nib--i.e. not until something asks for the window object. The nib would not 
be loaded on initialization, unless subclassed to specifically do so.

Anyway, Steve, if you want useful answers, you must give specific information 
using specific language.

>> However, I'm using CoreData and I want to pass the existing MOC to the pref 
>> window:
>> I have added an array controller to the pref nib with its MOC set to files 
>> owner's MOC in IB.

How did you set the MOC? Using bindings or outlet? If you used outlet, I am 
sorry to say, that is very wrong.

In any case, you are being told the problem--your MOC is not being properly 
set. Debug appropriately.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

___

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 allObjects memory allocation problem

[Paul Sanders]

> Also be aware that just because memory is released, doesn't mean it is 
> returned to the system (e.g. you will not
> see your apps memory usage go down in Activity Monitor). In fact,  AFAIK, it 
> is never returned to the system,
> except perhaps in low memory situations.

I don't actually think that's true.  At least, it's not what I observe.  I 
think it's more accurate to say that you cannot predict when memory which has 
been allocated and then freed will be returned to the operating system, nor how 
much.  It happens, I believe, in 4k pages, but probably not one at a time and 
will be heavily dependent on fragmentation of the process's heap.  No doubt 
there is much more to know.

I agree with the sentiment of keeping an eye on your peak memory usage.  I use 
Instruments for this, and it found one instance where memory usage was creeping 
steadily up when the app was playing audio but otherwise idle.

Paul Sanders.
___

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: NSPrintInfo printSettings archiving

[Gideon King]

The dictionary method only returns standard attributes:

(gdb) po [oldPrintInfo dictionary]
{
NSBottomMargin = 72;
NSCopies = 1;
NSDetailedErrorReporting = 0;
NSFaxNumber = "";
NSFirstPage = 1;
NSHorizonalPagination = 0;
NSHorizontallyCentered = 1;
NSJobDisposition = NSPrintSpoolJob;
NSJobSavingFileNameExtensionHidden = 0;
NSLastPage = 2147483647;
NSLeftMargin = 72;
NSMustCollate = 1;
NSOrientation = 0;
NSPagesAcross = 1;
NSPagesDown = 1;
NSPaperName = "iso-a4";
NSPaperSize = "NSSize: {595, 842}";
NSPrintAllPages = 1;
NSPrintProtected = 0;
NSPrintTime = "0001-01-01 10:00:00 +1000";
NSPrinter = "{\n\"Device Description\" = {\n
NSDeviceIsPrinter = YES;\n};\n\"Language Level\" = 2;\nName = 
\"Canon iP1700\";\nType = \"Canon iP1700\";\n}";
NSPrinterName = "Canon iP1700";
NSRightMargin = 72;
NSSavePath = "";
NSScalingFactor = 1;
NSTopMargin = 72;
NSVerticalPagination = 0;
NSVerticallyCentered = 1;
}
(gdb) po [oldPrintInfo printSettings]
{
borderColor = "#FF00";
"com_apple_print_DocumentTicket_PMSpoolFormat" = "application/pdf";
"com_apple_print_PrintSettings_PMColorSyncProfileID" = 1875;
"com_apple_print_PrintSettings_PMCopies" = 1;
"com_apple_print_PrintSettings_PMCopyCollate" = 1;
"com_apple_print_PrintSettings_PMFirstPage" = 1;
"com_apple_print_PrintSettings_PMLastPage" = 2147483647;
"com_apple_print_PrintSettings_PMPageRange" = (
1,
2147483647
);
"com_apple_print_ticket_type" = "com.apple.print.PrintSettingsTicket";
pagesHigh = 5;
pagesWide = 3;
printBorder = 1;
printMapBackground = 1;
whatToPrint = 0;
}

As you can see, there are some attributes that seem to be mirrored between the 
dictionary and printSettings, but some that are unique to each, and the 
printSettings is the only place where my custom attributes are set (the first 
item and last 5 items in the printSettings are my custom attributes).


Regards

Gideon

On 22/05/2010, at 12:46 AM, Scott Ribe wrote:

> You probably want to use [[self printInfo] dictionary] and then archive the 
> dictionary however you want.
> 

___

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

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

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

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

Re: iPhone/iPad: Desktop wallpaper can't be set.

[Alex Kac]

I never understand posts like this. If the app does it, and you don't want it, 
don't buy it. Some people may want it. I might want an app that creates fractal 
imagery and sets a wallpaper for me. I might want to be able to set a wallpaper 
of a screenshot of an app. In fact I get customers asking for that all the 
time. Personally I think there are better ways to do what they want and when I 
tell them they can take a screenshot and set it themselves, they find that a 
kludge and rightfully so. They want it automatically. 

Don't limit the users just because you don't want something. Its not being 
forced.

On May 19, 2010, at 11:23 AM, Phil Hystad wrote:

> I hope this feature is not supported.  The last thing I want is some 
> application changing my desktop background which is my choice, not one of the 
> application.  Yes, I know this can be done with some kind of dialog for 
> approval but then that really stresses the logic of why you would want to do 
> this -- OS X already provides a way for me to set my background, I don't need 
> to buy or use an app to do that.
> 
> I vote no -- don't do it.
> 
> phil
> 
> On May 19, 2010, at 9:08 AM, David Duncan wrote:
> 
>> On May 19, 2010, at 7:55 AM, sebi wrote:
>> 
>>> A customer wants an app that changes the desktop background image. I told 
>>> him that is not possible (and probably won't be in the near future) because 
>>> that would mean to play outside the sandbox. Is this correct?
>> 
>> 
>> Correct, this is not possible in the current API. I would recommend filing a 
>> bug report asking for this capability.
>> --
>> David Duncan
>> Apple DTS Animation and Printing
>> 
>> ___
>> 
>> 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/phystad%40mac.com
>> 
>> This email sent to phys...@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/alex%40webis.net
> 
> This email sent to a...@webis.net

Alex Kac - President and Founder
Web Information Solutions, Inc.
"To educate a person in mind and not in morals is to educate a menace to 
society."
-- Theodore Roosevelt






___

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 allObjects memory allocation problem

[Keary Suska]

On May 20, 2010, at 9:37 PM, Nick Zitzmann wrote:

> On May 19, 2010, at 5:36 AM, Vassilis Pantazis wrote:
> 
>> Hello,
>> 
>> I have in my code the following statement:
>> 
>>   NSDirectoryEnumerator* dirEnum;
>>   NSArray* inDirContents;
>> 
>>   dirEnum = [[NSFileManager defaultManager] enumeratorAtPath:inPath]; //
>> inPath is a valid path
>>   inDirContents = [dirEnum allObjects];
>> 
>> I have noticed that when the path contains many objects, a significant
>> amount of memory is allocated that is not released, neither when trying to
>> explicitly release inDirContents, nor when using an autorelease pool.
>> Can someone explain to me why this happens please and how to solve it?

Also be aware that just because memory is released, doesn't mean it is returned 
to the system (e.g. you will not see your apps memory usage go down in Activity 
Monitor). In fact,  AFAIK, it is never returned to the system, except perhaps 
in low memory situations. This is a key reason for recommendations on keeping a 
low peak memory footprint. Search the archives for more discussions on these 
issues.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

___

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: NSPrintInfo printSettings archiving

[Scott Ribe]

You probably want to use [[self printInfo] dictionary] and then archive the 
dictionary however you want.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice




___

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 allObjects memory allocation problem

[Vassilis Pantazis]

Hello Nick,

First of all thank you for your reply! My method has been monitoring the mem
usage of the specified (and other calls) while in the debugger and trusting
guard malloc for memory leaks. With this the mem allocated by the said call
is instantly in the scale of
tenths of MBs for just one line of code (that runs slow on top of all) - the
allObjects call. However I have to admit that
I have limited knowledge on using the performance tools, especially because
as far as i know they work outside the debugger.
So I will have to study and try your proposal in any case - Instuments and
its Leaks look really cool :) ; I find it almost compulsory knowledge and
feel a real noob to have discarded it so far. Any hints for me or whoever
might be reading this are welcome.

Thanks again,
Vas.

On Fri, May 21, 2010 at 6:37 AM, Nick Zitzmann  wrote:

>
> On May 19, 2010, at 5:36 AM, Vassilis Pantazis wrote:
>
> > Hello,
> >
> > I have in my code the following statement:
> >
> >NSDirectoryEnumerator* dirEnum;
> >NSArray* inDirContents;
> >
> >dirEnum = [[NSFileManager defaultManager] enumeratorAtPath:inPath]; //
> > inPath is a valid path
> >inDirContents = [dirEnum allObjects];
> >
> > I have noticed that when the path contains many objects, a significant
> > amount of memory is allocated that is not released, neither when trying
> to
> > explicitly release inDirContents, nor when using an autorelease pool.
> > Can someone explain to me why this happens please and how to solve it?
>
> Have you tried using the object alloc instrument in Instruments? That will
> show you what is really going on with your application's memory usage.
>
> Nick Zitzmann
> 
>
>
>
>
___

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

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

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

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

Re: Displaying NSPopUpButtonCells in NSTableView

[Keary Suska]

On May 20, 2010, at 3:28 PM, James Maxwell wrote:

> hmm... Well, I've tried returning the cell's selectedItem, 
> indexOfSelectedItem, and also:
> 
> [[inst MIDI_Inst_Ports] objectAtIndex:[ports indexOfSelectedItem]]
> 
> (that is, the port name at indexOfSelectedItem). 
> If I NSLog the [ports indexOfSelectedItem] it's always zero. So I'm obviously 
> not understanding how (or when) the cell gets selected.
> 
> Maybe the menu/cell selection is a separate process? Do I need to control the 
> popup separately? 
> I'll look into NSPopUpButtonCell again, but if anyone see's what I'm missing, 
> please pop me a note.

The first thing to always remember is that the designer of NSTableView was an 
unabashed sadist. Now that that is out of the way

What NSTableView needs from you is to tell it what the selected index *should* 
be, so *it* can set the selected item in the popupbutton. I.e., the tableview 
wants to control the popupbutton. All you should do is touch it during delegate 
calls. I believe if you return nil, the first item will be selected.

If every cell's popup will have the same content (albeit varying selections), 
your sanity will remain intact. Otherwise, I shudder to think

> On 2010-05-20, at 2:04 PM, James Maxwell wrote:
> 
>> On 2010-05-20, at 1:28 PM, Peter Ammon wrote:
>> 
>>> 
>>> On May 20, 2010, at 1:14 PM, James Maxwell wrote:
>>> 
 I thought I'd change the topic on this, since the content really has 
 changed.
 
 I have an table for setting up MIDI instruments with a name, port, and 
 channel. I've got the initial display of options for the table row 
 displaying correctly, and when I make changes to the name, port, and 
 channel, the data object is updated correctly. The only thing left is that 
 the popups in columns 2 and 3 are not holding the selected value. I 
 understand that this is probably because I'm reloading the menu in 
 tableView:objectValueForTableColumn:row, but I'm not sure how to get 
 around it. 
 
 Here's the code I've got so far. I'm not using an NSArrayController, 
 because that approach was driving me absolutely mental...
 I've copied all the code (except imports) to be thorough. Logging "Edited 
 MIDIInstrument" at the end shows that the instrument is set up correctly, 
 with the desire name, port, and channel. It's just that the popups always 
 display the 2nd item.


Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

___

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

NSPrintInfo printSettings archiving

[Gideon King]

In the NSPrintInfo documentation, when talking about the printSettings, it says:

"Adding keys to the dictionary is equivalent to calling the Core Printing 
function PMPrintSettingsSetValue. Your new keys are added to the current print 
settings and are saved with any user preset files generated by the Mac OS X 
printing system. Because the print settings are stored in a property list, any 
values you add to the dictionary must correspond to scalar types such as 
strings, numbers, dates, booleans, and data objects or collection types such as 
dictionaries and arrays."

I took this to mean that so long as I store my own custom settings in the 
printSettings dictionary, then if I used NSArchiver and NSUnarchiver to save 
and restore the NSPrintInfo object, that my custom items would be stored along 
with the dictionary. It appears this is not the case. If I set some custom keys 
in the print into printSettings, then do the following:

NSPrintInfo *oldPrintInfo = [self printInfo];
NSPrintInfo *newPrintInfo = [NSUnarchiver 
unarchiveObjectWithData:[NSArchiver archivedDataWithRootObject:[self 
printInfo]]];

My oldPrintInfo printSettings has all my added keys, and the newPrintInfo has 
only the standard keys.

I want to save my custom keys with the print info, and the documentation says 
that this happens when it is stored by the printing system, so what do I need 
to do to be able to save it in my document?

I realize that I could archive printSettings separately and re-populate the 
printinfo, but that seems pretty messy when the documentation says explicitly 
that there is a way of storing it so that the custom attributes are preserved.

Thanks

Gideon___

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

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

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

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

Re: NSManagedObject subclass mysteriously notifies observers for non-modeled properties

[David Hoerl]

On 5/21/10 9:10 AM, Mike Abdullah wrote:

What does +contextShouldIgnoreUnmodeledPropertyChanges return for your class? I 
am wondering if the two are interlinked.


This was an oversight on my part - this app is targeted at 10.5 (and 
thus uses the 10.5 SDK.) That Class method is not defined for 10.5 (or 
so says the documentation), and trying to compile a test fails as well.


David
___

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

controlAlternatingRowBackgroundColors

[Rick C.]

Hello,

Returning this method does exactly what I need in my NSTableView, but is there 
a way to use it somehow "locally" that it will not affect other areas of my 
project such as an NSOpenPanel?

Thanks,

rick___

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

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

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

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

Re: NSManagedObject subclass mysteriously notifies observers for non-modeled properties

[Mike Abdullah]

What does +contextShouldIgnoreUnmodeledPropertyChanges return for your class? I 
am wondering if the two are interlinked.

On 21 May 2010, at 13:24, David Hoerl wrote:

> Before doing my latest project, I poured over the "Model Object 
> Implementation Guide" and the NSManagedObject Class Reference. Both documents 
> state categorically that NSManagedObjects do NOT automatically provide KVO 
> notification unless one overrides +(BOOL)automaticallyNotifiesObserversForKey.
> 
> So, I dutifully sent willChangeValueForKey and didChangeValueForKey in the 
> setter method for my unmodeled property - an action that in the end caused a 
> difficult to find KVO related bug. After commenting out these two statements, 
> everything started working!
> 
> Well, it thus became obviously that KVO was already enabled for this 
> non-modeled property, so I added a log message to test this hypothesis:
> 
> NSLog(@"AUTO=%d", [Template 
> automaticallyNotifiesObserversForKey:@"topDSimObject"]);
> 
> Sure enough it prints out AUTO=1!  Yikes! How did that happen?
> 
> 
> Here is my interface:
> 
> @interface Template : NSManagedObject
> {
>   DSimObject  *topDSimObject;
> }
> @property (nonatomic, retain) NSString * name;
> ...
> 
> // tried both as a property and not, no change
> //@property (nonatomic, retain) DSimObject* topDSimObject;
> 
> - (void)setTopDSimObject:(DSimObject *)object;
> - (DSimObject *)topDSimObject;
> 
> @end
> 
> 
> So, what am I missing?
> 
> David
> 
> 
> 
> 
> ___
> 
> 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/cocoadev%40mikeabdullah.net
> 
> This email sent to cocoa...@mikeabdullah.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: scriptability of button in interface?

[Dan Ribe]

Hi All,

I am working on to make my cocoa application scriptable. I want to automate
the testing of my application and for that I want all the actions which user
can performs manually to be scriptable. Like apple script should be able to
open a dialog, type something in the text box (or any other UI element),
then save (or perform any action with that dialog as we do manually). I am
facing some problems with this and not able to make it work using apple
script.

Can someone please point me to the documentation or tutorial which show how
to make the UI actions scriptable for cocoa applications.

Thanks a lot for your help.
Cheers!


On Sat, May 3, 2008 at 4:37 PM, Uli Kusterer
wrote:

> Am 03.05.2008 um 12:09 schrieb Patrick J. Collins:
>
>  I am assuming there is something in interface builder that you need to do
>> to
>> accomplish this, but I just don't know what it is.
>>
>
>
>  No, not in IB. AppleScript in general doesn't script the UI, but rather
> what is the controller layer in a Cocoa app. So, what you need to do is
> create a scripting definition (.sdef and stuff like that) that maps
> AppleScript command names to methods on your controller object.
> http://developer.apple.com has some nice documentation on making Cocoa
> applications scriptable this way, using NSScriptCommand where you need to
> add your own commands that don't have objects associated with them.
>
> Cheers,
> -- Uli Kusterer
>
> "The Witnesses of TeachText are everywhere..."
> http://www.zathras.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/dan.ribe%40gmail.com
>
> This email sent to dan.r...@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

NSManagedObject subclass mysteriously notifies observers for non-modeled properties

[David Hoerl]

Before doing my latest project, I poured over the "Model Object 
Implementation Guide" and the NSManagedObject Class Reference. Both 
documents state categorically that NSManagedObjects do NOT automatically 
provide KVO notification unless one overrides 
+(BOOL)automaticallyNotifiesObserversForKey.


So, I dutifully sent willChangeValueForKey and didChangeValueForKey in 
the setter method for my unmodeled property - an action that in the end 
caused a difficult to find KVO related bug. After commenting out these 
two statements, everything started working!


Well, it thus became obviously that KVO was already enabled for this 
non-modeled property, so I added a log message to test this hypothesis:


NSLog(@"AUTO=%d", [Template 
automaticallyNotifiesObserversForKey:@"topDSimObject"]);


Sure enough it prints out AUTO=1!  Yikes! How did that happen?


Here is my interface:

@interface Template : NSManagedObject
{
   DSimObject  *topDSimObject;
}
@property (nonatomic, retain) NSString * name;
...

// tried both as a property and not, no change
//@property (nonatomic, retain) DSimObject* topDSimObject;

- (void)setTopDSimObject:(DSimObject *)object;
- (DSimObject *)topDSimObject;

@end


So, what am I missing?

David




___

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: migrating CoreData data model doesn't work

[Gustavo Pizano]

Rainer hello.

Have you created once again the ManagedObjects from the model?.. If so and you 
didn't remove the old ones, Xcode will start complaining A LOT (don't ask me 
why but it happened to me when I did it), then I realize I had to delete the 
old MO .m and .h files and generate again form the new model version. Now if 
you have custom methods in your MO's then what I do is that I don't delete, or 
create a new one, but simply add by had the new(s) attributes I set in the new 
model version. Im pretty sure there i another way to do this, better one, but 
this is what I do. But generally before creating the MO's Im make sure the 
model its normalized as much as I can, and in a consistent representation.

Now other thing to check is if you set the new model version as the current one.

Also, I think when changing things in the model you have to create a 
modelmapping file, this is done after making the changes in the new model 
version,  new file> resources, mappingmodel, call it whatever, then select the 
sources and the destination models, ..

I hope this helps.

Im not expert tough, but if this helps you Im glad.

Gustavo
 


On 21.5.2010, at 1:25, Rainer Standke wrote:

> Hello,
> 
> when I select my data model in the xcode project, and then select Design/Data 
> Model/Add Model Version I do get a new bundle in Xcode project, but now copy 
> of the existing datamodel. The bundle, both in Xcode and on the Finder level, 
> is empty. The app does not compile any more.
> 
> The only thing that might be unusual in this project - as far as I can tell - 
> is that I have iVars in the ManagedObject classes that calculate some things 
> on the fly, based on regular attributes. Could this be a reason for trouble?
> 
> I have no idea why this is going wrong, and would appreciate some help, 
> greatly.
> 
> Thanks,
> 
> Rainer___
> 
> 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/gustavxcodepicora%40gmail.com
> 
> This email sent to gustavxcodepic...@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: NSWindowController for Prefs XIB Question (Core Data involved)

[Quincey Morris]

On May 20, 2010, at 23:51, Steve Cronin wrote:

> I have created a brand new xib file: ptest
>   XCode creates the xib with a FilesOwner, FirstResponder, Application, 
> and Window (set to releaseOnClose and visibleAtLaunch)
...

> The new ptest.xib window will open once but never again if I close it.
>   this is true regardless of whether I set the window to releaseOnClose 
> or not

*Do not* set visibleAtLaunch to YES. You want the window to be shown via the 
window controller's 'showWindow:' method, not have it appear before that under 
its own initiative. There are *very* few situations where setting 
visibleAtLaunch is appropriate.

*Do not* set releaseOnClose to YES in this case. Once the window is released, 
you need to have the nib be re-loaded to get a new instance, which means you 
need to destroy and recreate your window controller too. (You could do that, 
but it's easier to leave both the window controller and the window in 
existence.) You'd normally want releaseOnClose for something like a document 
window -- when it's gone, so is the document and its window controller -- but 
not for a window belonging to a persistent window controller.


___

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