date:20100521

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

Re: Calling allObjects memory allocation problem

2010-05-21 Thread 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 n...@chronosnet.com 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
 http://www.chronosnet.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: NSPrintInfo printSettings archiving

2010-05-21 Thread 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

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

2010-05-21 Thread 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: NSPrintInfo printSettings archiving

2010-05-21 Thread 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: Calling allObjects memory allocation problem

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

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

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

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

On Fri, May 21, 2010 at 7:52 AM, Alex Kac a...@webis.net 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: iPhone/iPad: Desktop wallpaper can't be set.

2010-05-21 Thread 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 a...@webis.net 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

NSWindow dataWithEPSInsideRect: giving error on 10.5

2010-05-21 Thread David Alter

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

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

NSXMLParser initWIthData - Encoding?

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

Re: NSXMLParser initWIthData - Encoding?

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

Re: NSXMLParser initWIthData - Encoding?

On Fri, May 21, 2010 at 9:39 AM, Patrick Rutkowski rutsk...@gmail.com 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?

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 rutsk...@gmail.com 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?

2010-05-21 Thread 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?

On Fri, May 21, 2010 at 10:23 AM, Patrick Rutkowski rutsk...@gmail.com 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?

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 rutsk...@gmail.com 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 rutsk...@gmail.com
 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: Layer-hosting views and layer-backed scroll views

2010-05-21 Thread 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 kyle.slu...@gmail.com 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: Layer-hosting views and layer-backed scroll views

2010-05-21 Thread 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: NSXMLParser initWIthData - Encoding?

2010-05-21 Thread 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 rutsk...@gmail.com 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 rutsk...@gmail.com 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 rutsk...@gmail.com
 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: NSXMLParser initWIthData - Encoding?


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

 On Fri, May 21, 2010 at 10:23 AM, Patrick Rutkowski rutsk...@gmail.com 
 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?


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

On Fri, May 21, 2010 at 10:37 AM, Troy Stephens tsteph...@apple.com 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! grin)

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

2010-05-21 Thread Troy Stephens

On May 21, 2010, at 10:52 AM, Kyle Sluder wrote:
 On Fri, May 21, 2010 at 10:37 AM, Troy Stephens tsteph...@apple.com 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! grin)

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 herring that I was using to visually
 establish which end of the layer was up.
 
 You

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

On Fri, May 21, 2010 at 11:06 AM, Troy Stephens tsteph...@apple.com 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

Core data model persistence, independent of document

2010-05-21 Thread 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: NSXMLParser initWIthData - Encoding?

2010-05-21 Thread 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

Re: migrating CoreData data model doesn't work

2010-05-21 Thread 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

Getting TextEdit to Recognise UTF-8 Output

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

2010-05-21 Thread 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

Re: Getting TextEdit to Recognise UTF-8 Output

2010-05-21 Thread Sixten Otto

On Fri, May 21, 2010 at 3:42 PM, K.Darcy Otto do...@csusb.edu 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: migrating CoreData data model doesn't work

2010-05-21 Thread 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

2010-05-21 Thread 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

Forcing NSImage to cache images at certain sizes

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

On Fri, May 21, 2010 at 11:06 AM, Troy Stephens tsteph...@apple.com 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

Compatibility of Data iPhone / Mac

2010-05-21 Thread 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: Compatibility of Data iPhone / Mac