Re: menu item status

[Tim Schröder]

One way which should work would be to use the Accessibility Framework 
(NSAccessibility Protocol, Carbon Accessibility Reference and AXUIElement.h), 
but you would have to make your application a trusted app or ask the user to 
enable accessibility access. There is a AXMenuItemMarkChar type in the Carbon 
reference containing information on whether a specific menu item is checked or 
not.

Tim



Am 07.09.2011 um 01:44 schrieb Rainer Standke:

> Hello,
> 
> I am trying to determine the state of a menu item in another application. I 
> have tried via AppleScript UI scripting, and via AppleScript Studio's state 
> of menu item. I am coming up empty. I can get to the menu and select the item 
> fine - but I can't get the status. I am interested whether or not the menu 
> item has a check mark next to it.
> 
> I know this can be done programmatically, because QuicKeys knows about the 
> status.
> 
> I'd be grateful for any hints as to how to solve this problem.
> 
> 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/tim%40timschroeder.net
> 
> This email sent to t...@timschroeder.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

Getting sandbox(d into a corner?)

[Clarence Locke]

I have an app that is currently available on the Mac App Store that I am 
updating to support the new sandboxing requirements.

In order to provide a more convenient and integrated user experience, my app 
coordinates the optional installation of export plug-ins for Aperture, iPhoto 
and Lightroom, as well as a command-line tool for more advanced users.  
Currently, the installation and removal mechanism for these plug-ins 
essentially boils down to the use of NSFileManager functions and the invocation 
of /bin/cp and /bin/rm via AuthorizationExecuteWithPrivileges(), all from 
within the application's process space (i.e., no helper apps).

As for the functionality of these integration plug-ins: when invoked by their 
respective parent applications, they use NSWorkspace, NSRunningApplication, 
Apple Events and Launch Services to locate, launch and/or send information to 
my application.


There are two major issues that arise when enabling the sandbox and assigning 
entitlements:

1) Loss of access to specific directories outside of my app's container 
hierarchy (e.g., ~/Library/Application Support/Aperture/Plug-Ins/Export/, 
/usr/local/bin/).  I realize that I can ask for a temporary exception via the 
com.apple.security.temporary-exception.files.absolute-path.read-write 
entitlement, but this falls short as a proper solution because:

(a) it is only "temporary" and may be revoked in some future release.

(b) the directory list for this entitlement is a fixed, embedded and 
code-signed part of my executable.  However, my app treats these third-party 
integrations themselves as its own kind of plug-in, and technically anybody can 
author additional ones and make them available for use by my app.  If my app is 
sandboxed, then the installation/removal of those integrations will also not 
work because their needed directories will not be included in my 
com.apple.security.temporary-exception.files.absolute-path.read-write 
entitlement.

How do I resolve issues (a) and (b)?


2) Because the third-party integration plug-ins utilize Apple Events for 
communicating with my app, I am currently at the mercy of the hosting 
application's sandbox entitlements.  Currently, none of the applications 
involved (Aperture, iPhoto, Lightroom and my own command line tool) are taking 
advantage of sandboxing.  But when they do, the following issues will arise:

(a) Apple Event use may/may not be allowed.  I have to assume that 
(eventually) they will not be allowed; therefore, what mechanism for 
communicating from the plug-in to my application should be used in place of 
Apple Events?

(b) If the host apps become sandboxed themselves, how will my app know 
that (for example) the Aperture integration plug-in should now be installed in 
~/Library/Containers/com.apple.Aperture/Data/Library/Application 
Support/Aperture/Plug-Ins/Export/ instead of ~/Library/Application 
Support/Aperture/Plug-Ins/Export/ ?


Are there any suggestions for me to mitigate issue 2?



I also foresee a general problem to any application that supports the 
installation and use of plug-ins, where the location of its plug-in directory 
changes after it becomes sandboxed because the root location for locating the 
plug-ins directory has changed from $HOME (~/) to $CFFIXED_USER_HOME 
(~/Library/Containers//Data/).  How is Apple going to solve 
this?  And will there be a sandbox-sanctioned way of accessing other 
application's plug-in directories?






Clarence___

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

UINavigationBar Look and feel

[Flavio ceolin]

Hello guys,

I have an UINavigationController with a couple of UIViewControllers, each
view
controller should change the the color of the navigationbar and of the
title. My question is,
should i add a subview for the title and set the tintcolor for the
navigationbar every time the
view appears or there is a better way to do it ?

BR,
Ceolin
___

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

NSSecureTextField and dead chars (umlauts, etc)

[Evgeny Yakovlev]

Hi,

I noticed a very strange behavior. To type an umlaut vowel you have to
first type a dead char 'option + u' and then the actual vowel that
will be an umlaut, for example option + u and then 'a' will print ä.
The same goes for accents, etc just using a different dead char combo.

Normal NSTextField accepts these characters no problem. But
NSSecureTextField just drops the dead char and only takes what
follows. Instead of 'ä' it will only get 'a' because it dropped
'option + u'.You can actually try this out on any system password
field. Instead of any vowel in your password just type it accented or
umlaut'ed using corresponding dead char combo. The passwords will
match, because dead char was dropped.

Now for my application this is completely unacceptable, because i am
dealing with entities with passwords created on Windows and Linux
where umlauts do get passed. Since i can't type an umlaut in
NSSecureTextField on Mac i can't provide a correct password even if i
know it!

I tried playing around with NSSecureTextFieldCell
setAllowedInputSourceLocales: but with no result.

Are there any known workarounds?

Inso Reiges
___

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

Cocoa USB HID Development - Where to begin

[Sajjad Hussain]

Hi,

Where do I start to write a USB HID app in Cocoa.  Is there any examples 
I can try out?  I have several HID devices which will talk to my app.


Regards,

Saj


___

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

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

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

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

How to write song tags with iTunes and Scripting Bridge

[David Dengg]

Hello list,

I have all the songs from iTunes as iTunesFileTracks (via Scripting Bridge). I 
want to write new tag information back into the tracks. I can do "song.name = 
newSongTitle;" and that works most of the time. Sometimes it fails. Sometimes 
it writes "msng" into the name (which is a catatsrophy!). lastError does not 
recognize this as an error. So the only way to check if it worked is to do " if 
( [song.name isEqualTo: newSongTitle]). Thats a really slow and bad solution.

Is there a preferred way to write tags back into the tracks? Should I use apple 
events directly?

Thank you
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: Introductions to OOP? [was: Re: Large over 100K pixel high ruler scroll view]

[Bruno Candido Volpato da Cunha]

Hello.

Jens, please take a look at this site:
http://www.codeproject.com/KB/architecture/OOP_Concepts_and_manymore.aspx



Regards,
Bruno

---
Bruno Candido Volpato da Cunha


2011/9/2 Jens Alfke 

>
> On Sep 1, 2011, at 9:26 PM, Julie Porter wrote:
>
> > Again I am impressed with the help I received here.   Hopefully others
> will be able to read these threads and learn from the experience of others.
>
> Julie: You’re welcome!
>
> Gang: One result of this is that I’m realizing how difficult it is to
> explain the basic concepts of object-oriented programming to someone who’s
> confused by them. I’ve been using them so long, that it’s like a fish trying
> to explain how to swim. I’d like to be able to point people to a good
> introduction, either online or in a book, but unfortunately I don’t know of
> any. Can anyone recommend something? (It doesn’t have to be Objective-C
> specific, although ideally it would describe dynamic languages, not static
> ones like C++ or Java.)
>
> Another common stumbling block seems to be nib loading, and the concept of
> wiring up your non-view objects so they can find each other at runtime. I
> think I’m better at explaining this because I still remember learning it
> myself, but it would still be good to bookmark some clear descriptions.
>
> —Jens___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/brunocandidoo%40gmail.com
>
> This email sent to brunocandi...@gmail.com
>



-- 
Bruno Candido Volpato da Cunha
___

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

Fwd: NSURLConnection problem on Mac OS X 10.7

[Payal Mundhada]

Hi All,

I am making a web service call with NSURLConnection.

Response is received correctly on Mac OS X 10.5 and Mac OS X 10.6.

On Mac OS X 10.7,  I am getting response as "Bad Request" for the same request.

When I make a call for same request successively two times following is the 
output
1. In first call response is "Bad Request"
2. For second response is successful.

Is there any modification for using NSURLConnection on Mac OS X 10.7.

Any clue will be helpful.

Thanks,
Payal







DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Persistent Systems Ltd. It is intended only for the use of the 
individual or entity to which it is addressed. If you are not the intended 
recipient, you are not authorized to read, retain, copy, print, distribute or 
use this message. If you have received this communication in error, please 
notify the sender and delete all copies of this message. Persistent Systems 
Ltd. does not accept any liability for virus infected mails.

___

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

Fwd: Problem in updating NSTextView on Mac OS X 10.7

[Payal Mundhada]

Hi All,

I have programatically added NSTextView Object.

I want to remove old text from  it and insert the new text. This NSTextView 
object is not editable. I am setting value in it using function setString.

I want to update textView continuously, but the text is not updated in 
continuos manner and if we click on text view, text get updated but throws 
exception
(NSRangeException) NSMutableRLEArray objectAtIndex:effectiveRange:: Out of 
bounds

I am facing this problem on Mac OS X 10.7, while application is behaving as per 
expectation on Mac OS X 10.5 and Mac OS X 10.6


Any clue will be very helpful

Thanks,
Payal







DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Persistent Systems Ltd. It is intended only for the use of the 
individual or entity to which it is addressed. If you are not the intended 
recipient, you are not authorized to read, retain, copy, print, distribute or 
use this message. If you have received this communication in error, please 
notify the sender and delete all copies of this message. Persistent Systems 
Ltd. does not accept any liability for virus infected mails.

___

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

Open NSPanel with button click in PDE

[Bartosz Białecki]

___

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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Oleg Krupnov]

So, gentlemen, the OP has ended up completely baffled with your discussion :)

Do I have to build and ship two separate versions of my app, for 10.6
and for 10.7??! This would be a nightmare!

At the bottom line, what is the legitimate way of supporting older
versions of Mac OS X (10.6) in an app designed for newer ones (10.7)?

This should be an easy and well-known topic, because Mac OS X gets
updated all the time! How can it cause so much discussion at all? Is
there an official recommendation in the docs regarding this question?



On Wed, Sep 7, 2011 at 7:23 AM, Chris Hanson  wrote:
> On Sep 6, 2011, at 8:52 PM, Ken Thomases wrote:
>
>>> And has been discussed in the rest of the thread, you should not leave your 
>>> Base SDK set to an earlier OS and then invoke methods introduced in a later 
>>> OS, because the new methods may require new-OS framework behavior.
>>
>> When did I say anything about invoking methods introduced in a later OS?
>
> This thread is the result of someone trying to take advantage of 10.7 
> features in code that needs to run on 10.6.
>
> If a developer who wants to do that builds against the 10.6 SDK, and invokes 
> new-in-10.7 methods when running on 10.7, they can get incorrect behavior as 
> a result.  That's because the frameworks are allowed to call their own 
> methods too, they're not public-only entry points.
>
> So the new-in-10.7 -bar may invoke -foo, which has different behavior when 
> linked on 10.6 or before, but expect -foo's 10.7 behavior.  Boom, the app is 
> broken.  Don't do that.
>
>>  If one develops an app for, say, 10.7 and has tested/validated it, but has 
>> set their SDK to Latest, then merely building it on the next generation of 
>> the OS/tools _will_ break it.  Without one having made any changes to their 
>> code.
>
> Merely building it with any different tool chain at all — and even a 
> different build of "the same" SDK — invalidates all of your testing and 
> validation as well.  (SDKs can and do change over time too; an SDK is "an 
> artifact that describes the API of an OS version" not "guaranteed to be the 
> exact bits from the headers and libraries of an OS version.")
>
> Since you need to re-test/re-validate any time you switch tools, it should be 
> no more burden to have an updated SDK at the same time any more than it is to 
> have an updated compiler, linker, or IDE.
>
> You don't actually win anything just by preserving the SDK version you're 
> building against. And as I explained above (and others have explained in this 
> thread) you can run into significant compatibility issues when attempting to 
> build for an older SDK but use new-than-that-SDK methods.
>
>>> It is a very strong recommendation that you set your Base SDK to Latest and 
>>> use the Deployment Target to specify the least recent OS on which your 
>>> application will be run.
>>
>> It may be a very strong recommendation, but it isn't a wise one.
>
> You're welcome to think anything you want about it.  Nonetheless, it doesn't 
> change how developers should be building their software for OS X.
>
> It's already how developers are used to building applications for iOS, so it 
> can't be that huge a burden.
>
>  -- Chris
>
>
___

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: using AppKit additions in background threads

[Michael Thon]

On Sep 6, 2011, at 9:23 PM, Douglas Davidson wrote:

> 
> On Sep 6, 2011, at 11:53 AM, Jens Alfke wrote:
> 
>> On Sep 6, 2011, at 11:11 AM, Michael Thon wrote:
>> 
>>> Yup, they're HTML, all right. Now I'm thinking of moving this code to a 
>>> separate command line app that I can call from the main application. It 
>>> should work, but I'm not sure if I'd need to provide a runloop for the HTML 
>>> importing to work.
>> 
>> The background tool will need to link against WebKit and AppKit, so it won’t 
>> be strictly-speaking ‘background’. You can mark its bundle with a special 
>> key (LSBackgroundOnly?) to keep it from showing up in the Dock or getting a 
>> menu-bar though.
>> 
>> The bigger problem is how this tool sends results back to the main app. An 
>> NSAttributedString is an in-memory object, and the tool has a separate 
>> address space. I guess you could try archiving the string and sending back 
>> the data, but I’m not sure whether all the different attribute values used 
>> in parsed HTML are archivable.
>> 
>> What do you use the attributed string for, if this is a background-only 
>> operation? Maybe there’s a less expensive way to accomplish it.
> 
> One possibility would be to convert the HTML to RTF or RTFD, which could be 
> loaded in the background.  For that sort of conversion we already have a tool 
> on the system, /usr/bin/textutil.  There are also other potential methods for 
> parsing HTML, if the intent is for something other than full editable rich 
> text support.
> 
> Douglas Davidson
> 


The app is to be used to find potential cases of plagiarism.  I'm importing 
documents that the users have on their local computers as well as web pages 
that they select from the www.  In the case of HTML, the user does not need to 
edit it, and it will be presented to the user in a WebView.  I need to extract 
plain text from the html in order to compare it to the user's document.  The 
html has not been loaded into the WebView instance yet, so there is no 
possibility to extract the plain text from there.  So, in a background thread 
(an NSOperation) I fetch the url using NSURLConnection, and then convert the 
NSData object to NSAttributedString, and from there I convert it to an 
NSString.  Later, if a potential case of plagiarism is detected, the user will 
view the web page by loading the original url into a WebView.  The previous 
conversion to plain text is accurate, such that if I select a substring of it 
(a potential plagiarized sentence) and use [webView searchFor:subString ...] in 
the  WebView instance, the webView can find the string and highlight it for the 
user.

So, I don't need editable rich text, but I do need a plain text string that 
faithfully represents the text content of the original html displayed in a 
WebView.  I've found that NSAttributedString's initWithData:... method does a 
good job of the conversion, and now I see why, because its using WebKit to do 
the actual conversion.  There might be a lighter weight way to do the 
conversion, but I haven't investigated alternatives yet.  One drawback to my 
approach is that I can't get the web page title using NSAttributesString. I 
don't know how to get to that yet.  I've considered trying to parse the html 
myself, but I think that will eventually just cause me a lot of grief.

Mike




___

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

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

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

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

Re: using AppKit additions in background threads

[Mark Munz]

>Yes that is a good question.  Another is whether I can execute utilities in 
>/usr/bin from a App Store app.

Typically that is not a problem if you are executing something that
already exists there and then use paths that point to an approved
location. But this does become an issue with sandboxing and sandboxing
will become a requirement for MAS apps.

I do believe you can use one of the temporary exceptions to allow you
to read anything on the disk. Not sure if there is one that isn't more
narrowly defined that might work -- info on much of sandboxing,
solutions to numerous issues encountered, remains fairly minimal,
despite the fast approaching deadline for Mac App Store requirement.

If you're concerned about sandboxing (and many of us that want to be
in the App Store will need to be concerned), I recommend going to the
Apple's dev forum on the topic.


On Tue, Sep 6, 2011 at 9:37 PM, Michael Thon  wrote:
>
> On Sep 7, 2011, at 4:22 AM, Glenn L. Austin wrote:
>
>> I would ship the files pre-converted.
>>
> If I could do that I wouldn't have any of these problems in the first place.  
> The app is converting users' documents.
>
>> On Sep 6, 2011, at 4:29 PM, Mark Munz wrote:
>>
>>> One thing that 3rd party developers *now* have to also consider: Can
>>> you call /usr/bin/textutil in a sandboxed app? Based on all the
>>> limitations I'm seeing when trying to sandbox an app, my bet is no --
>>> although I haven't tested this particular case.
>
> Yes that is a good question.  Another is whether I can execute utilities in 
> /usr/bin from a App Store app.
>
>>>
>>>
>>> On Tue, Sep 6, 2011 at 1:48 PM, Jens Alfke  wrote:

 On Sep 6, 2011, at 12:23 PM, Douglas Davidson wrote:

> One possibility would be to convert the HTML to RTF or RTFD, which could 
> be loaded in the background.  For that sort of conversion we already have 
> a tool on the system, /usr/bin/textutil.

 Wow, that is good to know about; I didn’t know it existed.

 According to the man page it can translate between: txt, html, rtf, rtfd, 
 doc, docx, wordml, odt, webarchive.
 I should file a Radar to add Markdown and Textile to that list ;-)
>>
>>
>> --
>> Glenn L. Austin, Computer Wizard and Race Car Driver         <><
>> "Where there's breath, there's hope!"
>> 
>>
>> ___
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/mike%40michaelrthon.com
>>
>> This email sent to m...@michaelrthon.com
>
>
>



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

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

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

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

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

Re: using AppKit additions in background threads

[Michael Thon]

On Sep 7, 2011, at 4:22 AM, Glenn L. Austin wrote:

> I would ship the files pre-converted.
> 
If I could do that I wouldn't have any of these problems in the first place.  
The app is converting users' documents.  

> On Sep 6, 2011, at 4:29 PM, Mark Munz wrote:
> 
>> One thing that 3rd party developers *now* have to also consider: Can
>> you call /usr/bin/textutil in a sandboxed app? Based on all the
>> limitations I'm seeing when trying to sandbox an app, my bet is no --
>> although I haven't tested this particular case.

Yes that is a good question.  Another is whether I can execute utilities in 
/usr/bin from a App Store app.  

>> 
>> 
>> On Tue, Sep 6, 2011 at 1:48 PM, Jens Alfke  wrote:
>>> 
>>> On Sep 6, 2011, at 12:23 PM, Douglas Davidson wrote:
>>> 
 One possibility would be to convert the HTML to RTF or RTFD, which could 
 be loaded in the background.  For that sort of conversion we already have 
 a tool on the system, /usr/bin/textutil.
>>> 
>>> Wow, that is good to know about; I didn’t know it existed.
>>> 
>>> According to the man page it can translate between: txt, html, rtf, rtfd, 
>>> doc, docx, wordml, odt, webarchive.
>>> I should file a Radar to add Markdown and Textile to that list ;-)
> 
> 
> -- 
> Glenn L. Austin, Computer Wizard and Race Car Driver <><
> "Where there's breath, there's hope!"
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/mike%40michaelrthon.com
> 
> This email sent to m...@michaelrthon.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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Chris Hanson]

On Sep 6, 2011, at 8:52 PM, Ken Thomases wrote:

>> And has been discussed in the rest of the thread, you should not leave your 
>> Base SDK set to an earlier OS and then invoke methods introduced in a later 
>> OS, because the new methods may require new-OS framework behavior.
> 
> When did I say anything about invoking methods introduced in a later OS?

This thread is the result of someone trying to take advantage of 10.7 features 
in code that needs to run on 10.6.

If a developer who wants to do that builds against the 10.6 SDK, and invokes 
new-in-10.7 methods when running on 10.7, they can get incorrect behavior as a 
result.  That's because the frameworks are allowed to call their own methods 
too, they're not public-only entry points.

So the new-in-10.7 -bar may invoke -foo, which has different behavior when 
linked on 10.6 or before, but expect -foo's 10.7 behavior.  Boom, the app is 
broken.  Don't do that.

>  If one develops an app for, say, 10.7 and has tested/validated it, but has 
> set their SDK to Latest, then merely building it on the next generation of 
> the OS/tools _will_ break it.  Without one having made any changes to their 
> code.

Merely building it with any different tool chain at all — and even a different 
build of "the same" SDK — invalidates all of your testing and validation as 
well.  (SDKs can and do change over time too; an SDK is "an artifact that 
describes the API of an OS version" not "guaranteed to be the exact bits from 
the headers and libraries of an OS version.")

Since you need to re-test/re-validate any time you switch tools, it should be 
no more burden to have an updated SDK at the same time any more than it is to 
have an updated compiler, linker, or IDE.

You don't actually win anything just by preserving the SDK version you're 
building against. And as I explained above (and others have explained in this 
thread) you can run into significant compatibility issues when attempting to 
build for an older SDK but use new-than-that-SDK methods.

>> It is a very strong recommendation that you set your Base SDK to Latest and 
>> use the Deployment Target to specify the least recent OS on which your 
>> application will be run.
> 
> It may be a very strong recommendation, but it isn't a wise one.

You're welcome to think anything you want about it.  Nonetheless, it doesn't 
change how developers should be building their software for OS X.

It's already how developers are used to building applications for iOS, so it 
can't be that huge a burden.

  -- Chris

___

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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Ken Thomases]

On Sep 6, 2011, at 6:52 PM, Chris Hanson wrote:

> On Sep 6, 2011, at 4:44 PM, Ken Thomases wrote:
> 
>> On Sep 6, 2011, at 6:31 PM, Chris Hanson wrote:
>> 
>>> Furthermore, Xcode 3.2.6 and 4.0 added "Latest Mac OS X" and "Latest iOS" 
>>> options to the Base SDK pop-up, which is preferable to specifying a 
>>> particular OS version for the SDK against which you wish to build.
>> 
>> "Preferable" only if you want unpredictable changes in behavior, as has been 
>> discussed elsewhere in this thread.  One should only change the SDK being 
>> used after careful deliberation and a plan to cope with the changed behavior 
>> (possibly while also coping with the old behavior if you continue to deploy 
>> to older OS versions).  Automatic switching, as embodied in those options, 
>> is an awful idea, in my opinion.
> 
> And has been discussed in the rest of the thread, you should not leave your 
> Base SDK set to an earlier OS and then invoke methods introduced in a later 
> OS, because the new methods may require new-OS framework behavior.

When did I say anything about invoking methods introduced in a later OS?  If 
one develops an app for, say, 10.7 and has tested/validated it, but has set 
their SDK to Latest, then merely building it on the next generation of the 
OS/tools _will_ break it.  Without one having made any changes to their code.

> It is a very strong recommendation that you set your Base SDK to Latest and 
> use the Deployment Target to specify the least recent OS on which your 
> application will be run.

It may be a very strong recommendation, but it isn't a wise one.

Regards,
Ken

___

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

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

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

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

Re: using AppKit additions in background threads

[Glenn L. Austin]

I would ship the files pre-converted.

On Sep 6, 2011, at 4:29 PM, Mark Munz wrote:

> One thing that 3rd party developers *now* have to also consider: Can
> you call /usr/bin/textutil in a sandboxed app? Based on all the
> limitations I'm seeing when trying to sandbox an app, my bet is no --
> although I haven't tested this particular case.
> 
> 
> On Tue, Sep 6, 2011 at 1:48 PM, Jens Alfke  wrote:
>> 
>> On Sep 6, 2011, at 12:23 PM, Douglas Davidson wrote:
>> 
>>> One possibility would be to convert the HTML to RTF or RTFD, which could be 
>>> loaded in the background.  For that sort of conversion we already have a 
>>> tool on the system, /usr/bin/textutil.
>> 
>> Wow, that is good to know about; I didn’t know it existed.
>> 
>> According to the man page it can translate between: txt, html, rtf, rtfd, 
>> doc, docx, wordml, odt, webarchive.
>> I should file a Radar to add Markdown and Textile to that list ;-)


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


___

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

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

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

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

Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Wim Lewis]

On 6 Sep 2011, at 4:31 PM, Chris Hanson wrote:
> It may be better to actually check whether your code is running on Snow 
> Leopard rather than make -respondsToSelector: checks.

Another reason to do this is that occasionally the method or class you're 
interested in actually appeared in an earlier OS revision but was private: in 
that case they might not have quite the same behavior as their 
eventually-public versions.

The NSAppKitVersionNumber (and similar) global variables are a quick and easy 
way to check the runtime version of a framework.


___

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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Shane Stanley]

On Sep 7, 2011, at 9:54 AM, Chris Hanson wrote:
> 
> I don't understand - above you say you set your Deployment Target to 10.7 and 
> then ran your code under 10.6.

Oh dear -- the caffeine hasn't kicked in down here yet. I meant Base SDK when I 
said Deployment Target. Let me try again:

I have a GC app written under 10.6 (which it requires as a minimum because it 
uses a small amount of AppleScriptObjC). I have updated it to support 
versioning and the find bar when run under 10.7. When I set the Base SDK to 
10.7 and run the result under 10.6, I get regular "malloc: reference count 
underflow for 0x200796140, break on auto_refcount_underflow_error to debug" 
errors. They don't happen when I run the same binary under 10.7, and they don't 
happen under 10.6 if I change the Base SDK to 10.6.

And of course I have no way to "break on auto_refcount_underflow_error to 
debug", because the error doesn't happen under 10.7, and I can't set a Base SDK 
of 10.7 when running under 10.6.

So for now, the easy way out is to keep the Base SDK at 10.6. But I'd be 
interested in any other thoughts/suggestions.



-- 
Shane Stanley 
'AppleScriptObjC Explored' 

___

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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Chris Hanson]

On Sep 6, 2011, at 4:50 PM, Shane Stanley wrote:

> On Sep 7, 2011, at 9:31 AM, Chris Hanson wrote:
>> 
>> You should set your Base SDK to the most recent OS whose features you are 
>> going to use (in this case 10.7) and set your Deployment Target to the least 
>> recent OS you want to run on (in this case 10.6).
> 
> I have a GC app written under 10.6 (which it requires as a minimum because it 
> uses a small amount of AppleScriptObjC). I have updated it to support 
> versioning and the find bar when run under 10.7. When I set the deployment 
> target to 10.7 and run the result under 10.6, I get regular "malloc: 
> reference count underflow for 0x200796140, break on 
> auto_refcount_underflow_error to debug" errors. They don't happen under 10.7, 
> and they don't happen under 10.6 if I set a deployment target of 10.6.

I don't understand - above you say you set your Deployment Target to 10.7 and 
then ran your code under 10.6.  Don't do that.  *Deployment Target and Base 
SDK are different.*

  -- Chris

___

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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Chris Hanson]

On Sep 6, 2011, at 4:44 PM, Ken Thomases wrote:

> On Sep 6, 2011, at 6:31 PM, Chris Hanson wrote:
> 
>> Furthermore, Xcode 3.2.6 and 4.0 added "Latest Mac OS X" and "Latest iOS" 
>> options to the Base SDK pop-up, which is preferable to specifying a 
>> particular OS version for the SDK against which you wish to build.
> 
> "Preferable" only if you want unpredictable changes in behavior, as has been 
> discussed elsewhere in this thread.  One should only change the SDK being 
> used after careful deliberation and a plan to cope with the changed behavior 
> (possibly while also coping with the old behavior if you continue to deploy 
> to older OS versions).  Automatic switching, as embodied in those options, is 
> an awful idea, in my opinion.

And has been discussed in the rest of the thread, you should not leave your 
Base SDK set to an earlier OS and then invoke methods introduced in a later OS, 
because the new methods may require new-OS framework behavior.

It is a very strong recommendation that you set your Base SDK to Latest and use 
the Deployment Target to specify the least recent OS on which your application 
will be run.

(This is the only choice available for iOS development.)

  -- Chris

___

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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Shane Stanley]

On Sep 7, 2011, at 9:31 AM, Chris Hanson wrote:
> 
> You should set your Base SDK to the most recent OS whose features you are 
> going to use (in this case 10.7) and set your Deployment Target to the least 
> recent OS you want to run on (in this case 10.6).

I have a GC app written under 10.6 (which it requires as a minimum because it 
uses a small amount of AppleScriptObjC). I have updated it to support 
versioning and the find bar when run under 10.7. When I set the deployment 
target to 10.7 and run the result under 10.6, I get regular "malloc: reference 
count underflow for 0x200796140, break on auto_refcount_underflow_error to 
debug" errors. They don't happen under 10.7, and they don't happen under 10.6 
if I set a deployment target of 10.6.

And of course I have no way to "break on auto_refcount_underflow_error to 
debug", because the error doesn't happen under 10.7, and I can't set a 
deployment target of 10.7 when running under 10.6.

So for now, the easy way out is to keep the deployment target at 10.6. But I'd 
be interested in any other thoughts/suggestions.

-- 
Shane Stanley 
'AppleScriptObjC Explored' 

___

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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Ken Thomases]

On Sep 6, 2011, at 6:31 PM, Chris Hanson wrote:

> Furthermore, Xcode 3.2.6 and 4.0 added "Latest Mac OS X" and "Latest iOS" 
> options to the Base SDK pop-up, which is preferable to specifying a 
> particular OS version for the SDK against which you wish to build.

"Preferable" only if you want unpredictable changes in behavior, as has been 
discussed elsewhere in this thread.  One should only change the SDK being used 
after careful deliberation and a plan to cope with the changed behavior 
(possibly while also coping with the old behavior if you continue to deploy to 
older OS versions).  Automatic switching, as embodied in those options, is an 
awful idea, in my opinion.

Regards,
Ken

___

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

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

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

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

menu item status

[Rainer Standke]

Hello,

I am trying to determine the state of a menu item in another application. I 
have tried via AppleScript UI scripting, and via AppleScript Studio's state of 
menu item. I am coming up empty. I can get to the menu and select the item fine 
- but I can't get the status. I am interested whether or not the menu item has 
a check mark next to it.

I know this can be done programmatically, because QuicKeys knows about the 
status.

I'd be grateful for any hints as to how to solve this problem.

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/archive%40mail-archive.com

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

Error opening xib file: "-[IBUIScreenMetrics initWithCoder:]: unrecognized selector"

[Jens Alfke]

I’ve got an iOS project that works fine in Xcode 4, and tried for the first 
time to build it with Xcode 3.2.5. I’m getting an error while compiling one of 
the xib files:

The document “RootViewController.xib” could not be opened. The operation 
couldn’t be completed. -[IBUIScreenMetrics initWithCoder:]: unrecognized 
selector sent to instance 0x10187aba0.

I get the same error message in an alert box if I try to open that xib file in 
Interface Builder.

Any idea what this means?

—Jens___

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

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

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

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

Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Chris Hanson]

On Sep 6, 2011, at 3:33 AM, Oleg Krupnov wrote:

> I'm implementing a new Lion's API, namely the resume. I need to make
> the following call:
> 
> [window setRestorationClass:someClass];
> 
> I'd like my app to also work on Snow Leopard, so I do this:
> 
> if ([window respondsToSelector:@selector(setRestorationClass:)])
> {
> [window setRestorationClass:someClass];
> }

It may be better to actually check whether your code is running on Snow Leopard 
rather than make -respondsToSelector: checks.

> however, because I compile for Snow Leopard, the compiler will still
> give me a warning that the setRestorationClass: method is not defined.

What do you mean "compile for Snow Leopard"?  You should set your Base SDK to 
the most recent OS whose features you are going to use (in this case 10.7) and 
set your Deployment Target to the least recent OS you want to run on (in this 
case 10.6).

Furthermore, Xcode 3.2.6 and 4.0 added "Latest Mac OS X" and "Latest iOS" 
options to the Base SDK pop-up, which is preferable to specifying a particular 
OS version for the SDK against which you wish to build.

  -- Chris

___

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: using AppKit additions in background threads

[Mark Munz]

One thing that 3rd party developers *now* have to also consider: Can
you call /usr/bin/textutil in a sandboxed app? Based on all the
limitations I'm seeing when trying to sandbox an app, my bet is no --
although I haven't tested this particular case.


On Tue, Sep 6, 2011 at 1:48 PM, Jens Alfke  wrote:
>
> On Sep 6, 2011, at 12:23 PM, Douglas Davidson wrote:
>
>> One possibility would be to convert the HTML to RTF or RTFD, which could be 
>> loaded in the background.  For that sort of conversion we already have a 
>> tool on the system, /usr/bin/textutil.
>
> Wow, that is good to know about; I didn’t know it existed.
>
> According to the man page it can translate between: txt, html, rtf, rtfd, 
> doc, docx, wordml, odt, webarchive.
> I should file a Radar to add Markdown and Textile to that list ;-)
>
> —Jens___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/unmarked%40gmail.com
>
> This email sent to unmar...@gmail.com
>



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

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

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

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

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

Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[jonat...@mugginsoft.com]

On 6 Sep 2011, at 22:41, Kyle Sluder wrote:

> On Tue, Sep 6, 2011 at 2:34 PM, jonat...@mugginsoft.com
>  wrote:
>> On 6 Sep 2011, at 22:11, Kyle Sluder wrote:
>>> Framework versions haven't been used since the OpenStep days.
>> Really?
>> It is still documented:
> 
> Lots of things are still documented that aren't used anymore. :) There
> may have been a time since Mac OS X 10.0 that framework versions were
> used, but I can't think of any examples. They are certainly not used
> today.
Not quite true.
The system frameworks that implement support for Python and some other 
scripting languages use major framework versioning - but they are a special 
case.

However I agree that in general system framework versioning is now almost 
exclusively implemented using compatibility versions (aka framework minor 
versions).

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[jonat...@mugginsoft.com]

On 6 Sep 2011, at 22:41, Greg Parker wrote:

> On Sep 6, 2011, at 2:34 PM, jonat...@mugginsoft.com wrote:
>> On 6 Sep 2011, at 22:11, Kyle Sluder wrote:
>>> On Tue, Sep 6, 2011 at 1:55 PM, jonat...@mugginsoft.com
 To me this means that a framework will make its judgement of whether to 
 modify its internal behaviour based on introspecting the application 
 linkage.
 This behaviour though seems to be rare and implementation details scare on 
 the ground.
>>> 
>>> The system frameworks often check the SDK version the application
>>> they're running within was linked against.
>>> 
>> Can otool extract the SDK version?
> 
> The LC_LOAD_DYLIB output from `otool -lv` shows the library version number as 
> seen at link time. That's usually the value that is checked at runtime. To 
> get an SDK number, you'd have to know which library version was present in 
> each SDK.
> 
Thanks Greg. Looking at the LC_LOAD_DYLIB output helped me clarify things.
I was totally overlooking the way in which minor framework versioning is 
implemented.
see 
http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html
The doc above below even explicitly states :

"When a program is linked with a framework during development, the linker 
records the compatibility version of the development framework in the program’s 
executable file."

Running otool -lv on the 10.6 SDK version of AppKit gives:

Load command 4
  cmd LC_ID_DYLIB
  cmdsize 88
 name /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 
(offset 24)
   time stamp 1 Thu Jan  1 01:00:01 1970
  current version 1038.35.0
compatibility version 45.0.0

Running otool -lv on the 10.7 SDK version of AppKit gives:

Load command 4
  cmd LC_ID_DYLIB
  cmdsize 88
 name /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 
(offset 24)
   time stamp 1 Thu Jan  1 01:00:01 1970
  current version 1138.0.0
compatibility version 45.0.0

A test project confirms that when built against the 10.6 SDK the app references 
1038.35.0 as the AppKit current version.
When  built against 10.7 it references 1138.0.0.

Within the context of an application binary then a frameworks recorded "current 
version" is the framework current version as recorded at link time.
The actual current version of the framework loaded at runtime may well be 
different.

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[jonat...@mugginsoft.com]

On 6 Sep 2011, at 22:17, Jens Alfke wrote:

> 
> On Sep 6, 2011, at 1:55 PM, jonat...@mugginsoft.com wrote:
> 
>> Surely the choice of SDK normally only has an effect at build time.
>> My understanding is that the SDK frameworks are there to provide feedback 
>> during the linking that is performed as part of the build.
>> When the app is actually run the dynamic linker links to the specified 
>> versions (A, B, C, etc) of the system frameworks as specified in the binary 
>> (see otool -l).
>> The binary knows nothing about the SDK (correct me on this if I am wrong).
> 
> You are wrong :)

Wrong again!

> 
> The app binary captures the version number of the framework that it linked 
> against. The system framework code can and does check this version and act 
> accordingly. Thus in the AppKit/Foundation release notes you will find 
> statements like “This behavior occurs only in apps linked against OS X 10.5 
> or later; in earlier apps, the previous behavior occurs, for backward 
> compatibility”.
> 
> (This may sound kludgey, but it’s sometimes the only way to fix bugs or add 
> new functionality without breaking binary compatibility with existing apps. 
> Breaking binary compatibility in an OS release is Very Very Bad.)
> 
> —Jens

Kludgey it certainly sounds.
I was under the impression that explicit major framework versioning was used to 
maintain binary compatibility.
Old apps were linked against old framework versions and new apps against new 
ones.
Seems this is not the case.

Let's see if I can get it right this time:

In general system frameworks, when required, query the app for the target SDK 
and modify their code paths as necessary to provide binary compatibly across 
different OS versions.

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Kyle Sluder]

On Tue, Sep 6, 2011 at 2:41 PM, Kyle Sluder  wrote:
> I'm pretty sure the function that gets used for this is
> CFGetExecutableLinkedLibraryVersion, implemented here:
> http://www.opensource.apple.com/source/CF/CF-550/CFUtilities.c

Or perhaps _CFExecutableLinkedOnOrAfter, defined above…

--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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Kyle Sluder]

On Tue, Sep 6, 2011 at 2:34 PM, jonat...@mugginsoft.com
 wrote:
> On 6 Sep 2011, at 22:11, Kyle Sluder wrote:
>> Framework versions haven't been used since the OpenStep days.
> Really?
> It is still documented:

Lots of things are still documented that aren't used anymore. :) There
may have been a time since Mac OS X 10.0 that framework versions were
used, but I can't think of any examples. They are certainly not used
today.

>> The system frameworks often check the SDK version the application
>> they're running within was linked against.
>>
> Can otool extract the SDK version?

Don't think so, but I might be wrong.

I'm pretty sure the function that gets used for this is
CFGetExecutableLinkedLibraryVersion, implemented here:
http://www.opensource.apple.com/source/CF/CF-550/CFUtilities.c

--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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Greg Parker]

On Sep 6, 2011, at 2:34 PM, jonat...@mugginsoft.com wrote:
> On 6 Sep 2011, at 22:11, Kyle Sluder wrote:
>> On Tue, Sep 6, 2011 at 1:55 PM, jonat...@mugginsoft.com
>>> To me this means that a framework will make its judgement of whether to 
>>> modify its internal behaviour based on introspecting the application 
>>> linkage.
>>> This behaviour though seems to be rare and implementation details scare on 
>>> the ground.
>> 
>> The system frameworks often check the SDK version the application
>> they're running within was linked against.
>> 
> Can otool extract the SDK version?

The LC_LOAD_DYLIB output from `otool -lv` shows the library version number as 
seen at link time. That's usually the value that is checked at runtime. To get 
an SDK number, you'd have to know which library version was present in each SDK.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___

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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[jonat...@mugginsoft.com]

On 6 Sep 2011, at 22:11, Kyle Sluder wrote:

> On Tue, Sep 6, 2011 at 1:55 PM, jonat...@mugginsoft.com
> 
>> My understanding is that the SDK frameworks are there to provide feedback 
>> during the linking that is performed as part of the build.
>> When the app is actually run the dynamic linker links to the specified 
>> versions (A, B, C, etc) of the system frameworks as specified in the binary 
>> (see otool -l).
> 
> Framework versions haven't been used since the OpenStep days.
Really?
It is still documented:
http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html#//apple_ref/doc/uid/20002255-BCIECADD
I presumed versioning was still actively used in system frameworks.

> 
>> The binary knows nothing about the SDK (correct me on this if I am wrong).
> 
> You are wrong. ;-)
So it would seem!

> 
>> To me this means that a framework will make its judgement of whether to 
>> modify its internal behaviour based on introspecting the application linkage.
>> This behaviour though seems to be rare and implementation details scare on 
>> the ground.
> 
> The system frameworks often check the SDK version the application
> they're running within was linked against.
> 
Can otool extract the SDK version?

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Jens Alfke]

On Sep 6, 2011, at 1:55 PM, jonat...@mugginsoft.com wrote:

> Surely the choice of SDK normally only has an effect at build time.
> My understanding is that the SDK frameworks are there to provide feedback 
> during the linking that is performed as part of the build.
> When the app is actually run the dynamic linker links to the specified 
> versions (A, B, C, etc) of the system frameworks as specified in the binary 
> (see otool -l).
> The binary knows nothing about the SDK (correct me on this if I am wrong).

You are wrong :)

The app binary captures the version number of the framework that it linked 
against. The system framework code can and does check this version and act 
accordingly. Thus in the AppKit/Foundation release notes you will find 
statements like “This behavior occurs only in apps linked against OS X 10.5 or 
later; in earlier apps, the previous behavior occurs, for backward 
compatibility”.

(This may sound kludgey, but it’s sometimes the only way to fix bugs or add new 
functionality without breaking binary compatibility with existing apps. 
Breaking binary compatibility in an OS release is Very Very Bad.)

—Jens___

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

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

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

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

Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Kyle Sluder]

On Tue, Sep 6, 2011 at 1:55 PM, jonat...@mugginsoft.com
 wrote:
> Surely the choice of SDK normally only has an effect at build time.

No. That's what the "linked-on-or-after" phrase in the release notes
is all about.

> My understanding is that the SDK frameworks are there to provide feedback 
> during the linking that is performed as part of the build.
> When the app is actually run the dynamic linker links to the specified 
> versions (A, B, C, etc) of the system frameworks as specified in the binary 
> (see otool -l).

Framework versions haven't been used since the OpenStep days.

> The binary knows nothing about the SDK (correct me on this if I am wrong).

You are wrong. ;-)

> To me this means that a framework will make its judgement of whether to 
> modify its internal behaviour based on introspecting the application linkage.
> This behaviour though seems to be rare and implementation details scare on 
> the ground.

The system frameworks often check the SDK version the application
they're running within was linked against.

However, not all frameworks check in all relevant places. I've been
told of a time back in the way long ago when we were building on 10.4
against the 10.2 SDK, and using -respondsToSelector: and such to
optionally bring in 10.4 features. These 10.4-only features didn't
bother doing the linked-on-or-after check, so they were relying on
Foundation behaving in the 10.4 manner, whereas Foundation saw that we
were linked against the 10.2 SDK and was behaving in a
backwards-compatible (and forwards-incompatible) way.

--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: KVO on objects in NSArrayController

[Sean McBride]

On Sat, 3 Sep 2011 09:23:43 -0700, Kyle Sluder said:

>> I understand that... I think the alternative would be to register an
>> observer on all 8000+ objects in the array.
>
>Yes, this is the expected pattern with KVO. Contrary to what you might
>think at first, it is *fast*.

Unless you are using garbage collection, in which case it is an order of 
magnitude slower than with MRC (manual ref counting).  ie horribly slow.

--

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[jonat...@mugginsoft.com]

On 6 Sep 2011, at 19:47, Jens Alfke wrote:

> Linking against the 10.6 libraries is the correct behavior if the app hasn’t 
> been fully updated to use 10.7 features/behaviors. There are a lot of cases 
> where a system framework will change its behavior based on which version the 
> app linked against, as a backward-compatibility measure. For this reason, 
> changing the SDK setting in Xcode can often set you up for a lot more work 
> than you’d intended, as it can break your app until you update your code 
> accordingly.
> 
> (If you want an example: starting in 10.5, AppKit started tracking ref-counts 
> of NSFont objects. Before that there was a bug in which they were never 
> dealloced. Unfortunately there were apps that kept NSFont instances around 
> without retaining them. To keep these apps from crashing on 10.5, NSFont 
> would keep the old always-retained behavior for apps linked against the 10.4 
> SDK, but not the 10.5 SDK. This was called out in the release notes, but who 
> reads every line of the release notes? So some developers found out by seeing 
> their apps start to crash after they innocently changed the SDK setting from 
> 10.4 to 10.5.)

Surely the choice of SDK normally only has an effect at build time.
My understanding is that the SDK frameworks are there to provide feedback 
during the linking that is performed as part of the build.
When the app is actually run the dynamic linker links to the specified versions 
(A, B, C, etc) of the system frameworks as specified in the binary (see otool 
-l).
The binary knows nothing about the SDK (correct me on this if I am wrong).
 
Behaviour that arises as the result of switching the SDK normally only effects 
execution if it results in the app linking to a different system framework 
version (A, B, C etc).
http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/cross_development/Overview/overview.html#//apple_ref/doc/uid/20002001-BABEBGCF

The fact that most of the system frameworks only seem to contain a single 
version (appkit is at C) suggests that the runtime effect of compiling with 
different SDKs is normally minimal.
Of course, running on a new release often sees applications break but this is 
mainly as a result of framework bug fixes, subtle changes in behaviour or 
unjustified assumptions about black boxes.
In most cases I don't think that linking against an older SDK will prevent the 
need to port apps to new OS versions.

However the above link states:

"As a backward-compatibility mechanism, Apple frameworks sometimes check for 
the version of the SDK an application is built against, and, if it is an older 
SDK, modify the behavior for compatibility. This is done in cases where Apple 
predicts or discovers compatibility problems.Typically, frameworks detect how 
an application is built by looking at the version of the system frameworks the 
application is linked against. Thus, when relinking your application using a 
newer SDK, you might notice different behaviors—some of which might cause 
incompatibilities. In these cases, because your application is being rebuilt, 
you should address these issues at the same time. For this reason, if you are 
doing a small update of your application, to address a few bugs, for example, 
it's usually best to continue building with the same build environment and 
libraries used originally; that is, against the original SDK."

To me this means that a framework will make its judgement of whether to modify 
its internal behaviour based on introspecting the application linkage.
This behaviour though seems to be rare and implementation details scare on the 
ground.

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.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: using AppKit additions in background threads

[Jens Alfke]

On Sep 6, 2011, at 12:23 PM, Douglas Davidson wrote:

> One possibility would be to convert the HTML to RTF or RTFD, which could be 
> loaded in the background.  For that sort of conversion we already have a tool 
> on the system, /usr/bin/textutil.

Wow, that is good to know about; I didn’t know it existed.

According to the man page it can translate between: txt, html, rtf, rtfd, doc, 
docx, wordml, odt, webarchive.
I should file a Radar to add Markdown and Textile to that list ;-)

—Jens___

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

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

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

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

Re: Set a view's delegate using IB

[Quincey Morris]

On Sep 6, 2011, at 12:20 , Luc Van Bogaert wrote:

> I've been struggling trying to set a viewcontroller (loaded by its own nib) 
> as the delegate of another (main) viewcontroller's view in IB, while at the 
> same time avoiding  'awakefromnib' being called twice on the former 
> viewcontroller object, because of it being part of the latter 
> viewcontroller's nib. I haven't succeeded so far, so I finally decided to use 
> code. But, I'm still wondering if this is at all possible using IB. Any ideas?

It's not clear which of the 2 nib files contains the view controller. You first 
say it's "loaded by its own nib", then you say it's "part of the [main view 
controller's] nib". Which is it?

It's also not clear what the "this" is that you want to do using IB. Clearly, 
you can't use IB to prevent 'awakeFromNib' being called twice. Why do you care 
if 'awakeFromNib' is called twice, and if you care why don't you solve the 
problem it causes in 'awakeFromNib' itself (such as setting a flag to prevent 
your custom initialization being done twice), for which you're presumably 
writing code anyway?

Also, you can perhaps take the alternative path of overriding the view 
controller's 'loadView' instead of 'awakeFromNib'. That should be executed only 
once, although at a different point in the view life cycle.


___

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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Quincey Morris]

On Sep 6, 2011, at 11:47 , Jens Alfke wrote:

> I disagree. This is done all the time; for instance, as of June, Google 
> Chrome/Chromium still builds using the 10.5 SDK, but has code to call new 
> methods in 10.6 and 10.7. If your app is primarily written for the old OS but 
> wants to add a few new behaviors for the new one, I think this is the right 
> way to go. When moving to fully adopt the new OS, of course you should switch 
> to using its SDK.
> 
> Linking against the 10.6 libraries is the correct behavior if the app hasn’t 
> been fully updated to use 10.7 features/behaviors. There are a lot of cases 
> where a system framework will change its behavior based on which version the 
> app linked against, as a backward-compatibility measure. For this reason, 
> changing the SDK setting in Xcode can often set you up for a lot more work 
> than you’d intended, as it can break your app until you update your code 
> accordingly.

What I'm saying is that I don't recall there being any recognizance (being 
"done all the time" -- like adultery IRL -- notwithstanding) of the concept of 
an app being built against one version of the OS targeting a newer version. 
OTOH, it's very well understood that an app built against one version can 
target an earlier version -- there being, of course, build settings designed to 
represent this situation.

The case of "where a system framework will change its behavior based on which 
version the app linked against" was in fact my argument *against* the practice 
you're advocating. If you're starting to use (say) various new NSDocument 
features provided by 10.7, it seems to me that the last thing you want is for 
some (in effect) random subset of the API methods involved having their proper 
10.7 behavior suppressed because Lion thinks your app is linked against 10.6.

That whole "where a system framework will change its behavior based on which 
version the app linked against" mechanism is, I think, looking at the way it's 
described at the top of the release notes, predicated on the idea that your 
adoption of 10.7 API methods *implies* you've revisited your application's 
behavior to ensure that it works properly with the 10.7 behavior changes, even 
where you didn't use new APIs.

Furthermore, I'd argue that pasting pieces of the 10.7 SDK headers into your 
own header files is fraught with peril, both legal and technical.

But I'm happy to allow that I'm being too absolutist on this, if this is in 
fact the situation. It just struck me that the OP's problem really resulted 
from failing to adopt the 10.7 SDK formally while still trying to adopt the 
10.7 SDK haphazardly.


___

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: using AppKit additions in background threads

[Douglas Davidson]

On Sep 6, 2011, at 11:53 AM, Jens Alfke wrote:

> On Sep 6, 2011, at 11:11 AM, Michael Thon wrote:
> 
>> Yup, they're HTML, all right. Now I'm thinking of moving this code to a 
>> separate command line app that I can call from the main application. It 
>> should work, but I'm not sure if I'd need to provide a runloop for the HTML 
>> importing to work.
> 
> The background tool will need to link against WebKit and AppKit, so it won’t 
> be strictly-speaking ‘background’. You can mark its bundle with a special key 
> (LSBackgroundOnly?) to keep it from showing up in the Dock or getting a 
> menu-bar though.
> 
> The bigger problem is how this tool sends results back to the main app. An 
> NSAttributedString is an in-memory object, and the tool has a separate 
> address space. I guess you could try archiving the string and sending back 
> the data, but I’m not sure whether all the different attribute values used in 
> parsed HTML are archivable.
> 
> What do you use the attributed string for, if this is a background-only 
> operation? Maybe there’s a less expensive way to accomplish it.

One possibility would be to convert the HTML to RTF or RTFD, which could be 
loaded in the background.  For that sort of conversion we already have a tool 
on the system, /usr/bin/textutil.  There are also other potential methods for 
parsing HTML, if the intent is for something other than full editable rich text 
support.

Douglas Davidson

___

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

Set a view's delegate using IB

[Luc Van Bogaert]

Hi, 

I've been struggling trying to set a viewcontroller (loaded by its own nib) as 
the delegate of another (main) viewcontroller's view in IB, while at the same 
time avoiding  'awakefromnib' being called twice on the former viewcontroller 
object, because of it being part of the latter viewcontroller's nib. I haven't 
succeeded so far, so I finally decided to use code. But, I'm still wondering if 
this is at all possible using IB. Any ideas?

Thanks,

-- 
Luc Van Bogaert





___

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: using AppKit additions in background threads

[Chris Hanson]

On Sep 6, 2011, at 11:53 AM, Jens Alfke wrote:

> The background tool will need to link against WebKit and AppKit, so it won’t 
> be strictly-speaking ‘background’. You can mark its bundle with a special key 
> (LSBackgroundOnly?) to keep it from showing up in the Dock or getting a 
> menu-bar though.

Just running a tool that links AppKit won't give it an icon and menu bar, 
especially if you don't put it in a .app wrapper.  However, actually running an 
NSApplication within the tool will.

  -- Chris

___

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: using AppKit additions in background threads

[Jens Alfke]

On Sep 6, 2011, at 11:11 AM, Michael Thon wrote:

> Yup, they're HTML, all right. Now I'm thinking of moving this code to a 
> separate command line app that I can call from the main application. It 
> should work, but I'm not sure if I'd need to provide a runloop for the HTML 
> importing to work.

The background tool will need to link against WebKit and AppKit, so it won’t be 
strictly-speaking ‘background’. You can mark its bundle with a special key 
(LSBackgroundOnly?) to keep it from showing up in the Dock or getting a 
menu-bar though.

The bigger problem is how this tool sends results back to the main app. An 
NSAttributedString is an in-memory object, and the tool has a separate address 
space. I guess you could try archiving the string and sending back the data, 
but I’m not sure whether all the different attribute values used in parsed HTML 
are archivable.

What do you use the attributed string for, if this is a background-only 
operation? Maybe there’s a less expensive way to accomplish it.

—Jens

___

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

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

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

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

Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Jens Alfke]

On Sep 6, 2011, at 10:43 AM, Quincey Morris wrote:

> If so, that sounds like a terrible idea. It forces you to write your own 
> "fake" (subset of the) 10.7 SDK, which is a terrible idea (and probably not 
> supported), and it links your app agains the 10.6 libraries, which is a 
> terrible idea (in relation to its 10.7 behavior).

I disagree. This is done all the time; for instance, as of June, Google 
Chrome/Chromium still builds using the 10.5 SDK, but has code to call new 
methods in 10.6 and 10.7. If your app is primarily written for the old OS but 
wants to add a few new behaviors for the new one, I think this is the right way 
to go. When moving to fully adopt the new OS, of course you should switch to 
using its SDK.

Linking against the 10.6 libraries is the correct behavior if the app hasn’t 
been fully updated to use 10.7 features/behaviors. There are a lot of cases 
where a system framework will change its behavior based on which version the 
app linked against, as a backward-compatibility measure. For this reason, 
changing the SDK setting in Xcode can often set you up for a lot more work than 
you’d intended, as it can break your app until you update your code accordingly.

(If you want an example: starting in 10.5, AppKit started tracking ref-counts 
of NSFont objects. Before that there was a bug in which they were never 
dealloced. Unfortunately there were apps that kept NSFont instances around 
without retaining them. To keep these apps from crashing on 10.5, NSFont would 
keep the old always-retained behavior for apps linked against the 10.4 SDK, but 
not the 10.5 SDK. This was called out in the release notes, but who reads every 
line of the release notes? So some developers found out by seeing their apps 
start to crash after they innocently changed the SDK setting from 10.4 to 10.5.)

—Jens___

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

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

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

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

Re: Getting notification about new font is available

[Martin Wierschin]

> During weekend I was trying to figure out how to know when new font becomes 
> available.

You can use NSFontSetChangedNotification:

http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSFont_Class/Reference/Reference.html

Though in my experience it's posted a lot more often than necessary, so you 
might want to pay attention to how much work you do in response, or delay/batch 
your work.

~Martin

___

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: using AppKit additions in background threads

[Michael Thon]

On Sep 6, 2011, at 6:23 PM, Douglas Davidson wrote:

> 
> On Sep 6, 2011, at 9:20 AM, Michael Thon wrote:
> 
>> I'm importing data to an NSAttributedString using the method: 
>> initWithData:options:documentAttributes:error: which is an AppKit addition 
>> to NSAttributedString.  I'm doing this in an NSOperation running on a 
>> separate thread, and what I see is that the UI of the app becomes 
>> unresponsive while this method is called.  It doesn't happen all the time, 
>> but presumably the hang is related to the size of the data being converted.  
> 
> What kind of documents are you importing?  If this involves HTML, then it 
> will use WebKit to do part of the work, and WebKit runs exclusively on the 
> main thread.  The AppKit methods can be invoked on arbitrary threads, but 
> they will transfer WebKit work to the main thread as needed.
> 
> Douglas Davidson
> 

Yup, they're HTML, all right. Now I'm thinking of moving this code to a 
separate command line app that I can call from the main application. It should 
work, but I'm not sure if I'd need to provide a runloop for the HTML importing 
to work.  Well, easy enough to try.  If not, I'll have to find some other 
method for importing the HTML.___

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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Quincey Morris]

On Sep 6, 2011, at 03:33 , Oleg Krupnov wrote:

> I'm implementing a new Lion's API, namely the resume. I need to make
> the following call:
> 
> [window setRestorationClass:someClass];
> 
> I'd like my app to also work on Snow Leopard, so I do this:
> 
> if ([window respondsToSelector:@selector(setRestorationClass:)])
> {
> [window setRestorationClass:someClass];
> }
> 
> however, because I compile for Snow Leopard, the compiler will still
> give me a warning that the setRestorationClass: method is not defined.

Wait, what SDK are you compiling against? 10.6? I'm assuming so, since 
presumably you wouldn't get a *compiler* error if you were compiling against 
the 10.7 SDK.

If so, that sounds like a terrible idea. It forces you to write your own "fake" 
(subset of the) 10.7 SDK, which is a terrible idea (and probably not 
supported), and it links your app agains the 10.6 libraries, which is a 
terrible idea (in relation to its 10.7 behavior).


___

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: nonatomic vs atomic assign/retain

[Jens Alfke]

On Sep 6, 2011, at 10:09 AM, Preston Sumner wrote:

> Based on discussion on the dev forums, atomic properties are the recommended 
> default except for things like performance-critical code or frameworks that 
> assume they're running on a single thread.

Yes, that was the eventual decision. But it wasn’t unanimous.

> Making the "safe" version the default is a sensible decision, in my humble 
> opinion.

It depends. I think you have to make individual decisions on safety/performance 
trade-offs (otherwise we’d all be using Ruby or Python).

One of the things that worries me about atomic accessors is that they could 
lead to a form of “death by a thousand cuts” — your code gets slower but no hot 
spots show up in profiles because the overhead is spread out among hundreds of 
accessor methods, no single one of which stands out. (Yes, some of the extra 
time will show up inside the implementations of -retain, -autorelease and 
-drain, but a significant amount is just the extra overhead in the accessor of 
making the calls.)

But it’s true, as you point out, that ARC introduces optimizations that lessen 
this overhead. I haven’t dived into ARC yet (I work on open-source code so I 
can’t until it’s available on all platforms) but hope to soon.

—Jens___

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

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

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

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

Re: nonatomic vs atomic assign/retain

[Preston Sumner]

On Sep 6, 2011, at 10:50 AM, Jens Alfke wrote:

> 
> On Sep 6, 2011, at 9:09 AM, Joar Wingfors wrote:
> 
>> There's an additional consideration to keep in mind - @synthesized getters 
>> use the retain+autorelease pattern which makes local variables acquired from 
>> such getters "safer" in certain (unusual) usage patterns.
> 
> And considerably more expensive in all cases, since calling a getter now 
> involves messing with retain counts and autorelease pools. It also means the 
> getter method has to contain a whole register-saving preamble and postamble 
> instead of just the couple of instructions to pull out the ivar value.
> 
> At the time ObjC-2 was in development there was a debate within Apple about 
> whether to make ‘nonatomic’ be the default, with an ‘atomic’ keyword to 
> enable the safety features. I really wish it had gone that way.


Based on discussion on the dev forums, atomic properties are the recommended 
default except for things like performance-critical code or frameworks that 
assume they're running on a single thread. Also note that the 
retain/autorelease pattern is optimized under ARC. Making the "safe" version 
the default is a sensible decision, in my humble opinion.

Preston___

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: nonatomic vs atomic assign/retain

[Scott Ribe]

On Sep 6, 2011, at 10:55 AM, Torsten Curdt wrote:

> Given that access to the outlets
> is only valid after a certain safe point (awakeFromNib) one could
> consider outlets final/immutable and therefor synchronization should
> not be required.

You can change outlets at any time after that. Consider changing the delegate 
for some reason, or swapping views in & out, and so on.

-- 
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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Jens Alfke]

On Sep 6, 2011, at 3:42 AM, Mike Abdullah wrote:

> performSelector really isn't cumbersome at all:
> [window performSelector:@selector(setRestorationClass:) withObject:someClass];

Not in this case, but it doesn’t work for methods that take non-object 
parameters, or more than two parameters.

The approach I prefer is to declare the method in a category:

@interface NSWindow (StuffAppleAddedIn10_7)
- (void) setRestorationClass:(Class)aClass;
@end

—Jens___

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

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

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

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

Re: nonatomic vs atomic assign/retain

[Torsten Curdt]

Thanks for all the input so far.

What's left for me to understand is why access to outlets could
possibly need synchronization. After all it's just the loading of the
NIB that is writing to the outlets. Given that access to the outlets
is only valid after a certain safe point (awakeFromNib) one could
consider outlets final/immutable and therefor synchronization should
not be required.

I guess if the NIB loading mechanism was multithreaded and would keep
state directly in the outlets it would somewhat make sense - I just
have a hard time picturing it was implemented that way. Anyway - since
we don't have the source code this is all guessing and we probably
should just stick to the Memory Management Programming Guide ...but it
would be super nice if someone from Apple could fill in the "why".

cheers,
Torsten
___

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: nonatomic vs atomic assign/retain

[Jens Alfke]

On Sep 6, 2011, at 9:09 AM, Joar Wingfors wrote:

> There's an additional consideration to keep in mind - @synthesized getters 
> use the retain+autorelease pattern which makes local variables acquired from 
> such getters "safer" in certain (unusual) usage patterns.

And considerably more expensive in all cases, since calling a getter now 
involves messing with retain counts and autorelease pools. It also means the 
getter method has to contain a whole register-saving preamble and postamble 
instead of just the couple of instructions to pull out the ivar value.

At the time ObjC-2 was in development there was a debate within Apple about 
whether to make ‘nonatomic’ be the default, with an ‘atomic’ keyword to enable 
the safety features. I really wish it had gone that way.

—Jens___

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

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

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

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

Re: using AppKit additions in background threads

[Douglas Davidson]

On Sep 6, 2011, at 9:20 AM, Michael Thon wrote:

> I'm importing data to an NSAttributedString using the method: 
> initWithData:options:documentAttributes:error: which is an AppKit addition to 
> NSAttributedString.  I'm doing this in an NSOperation running on a separate 
> thread, and what I see is that the UI of the app becomes unresponsive while 
> this method is called.  It doesn't happen all the time, but presumably the 
> hang is related to the size of the data being converted.  

What kind of documents are you importing?  If this involves HTML, then it will 
use WebKit to do part of the work, and WebKit runs exclusively on the main 
thread.  The AppKit methods can be invoked on arbitrary threads, but they will 
transfer WebKit work to the main thread as needed.

Douglas Davidson

___

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

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

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

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

using AppKit additions in background threads

[Michael Thon]

I'm importing data to an NSAttributedString using the method: 
initWithData:options:documentAttributes:error: which is an AppKit addition to 
NSAttributedString.  I'm doing this in an NSOperation running on a separate 
thread, and what I see is that the UI of the app becomes unresponsive while 
this method is called.  It doesn't happen all the time, but presumably the hang 
is related to the size of the data being converted.  

This method is from App Kit.  Does that mean that I can only call it on the 
main thread?
Mike


___

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

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

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

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

Re: nonatomic vs atomic assign/retain

[Joar Wingfors]

On 6 sep 2011, at 08:49, Thomas Davie wrote:

> There are two schools of thought on atomic/nonatomic, and both apply equally 
> to Mac/iOS:
> 
> 1) Atomicity provides a little bit of safety, and shouldn't be shrugged off 
> for no reason.  Because of that, only optimise the atomic set/get when you've 
> actually profiled and determined it's a problem.


There's an additional consideration to keep in mind - @synthesized getters use 
the retain+autorelease pattern which makes local variables acquired from such 
getters "safer" in certain (unusual) usage patterns. Nothing to do with thread 
safety - of course.


> 2) When multithreading you rarely if ever actually want atomicity at the 
> property level, instead you want somewhat larger critical sections in general.


Wholeheartedly agree.


j o a r


___

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

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

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

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

Re: nonatomic vs atomic assign/retain

[Richard Somers]

On Sep 6, 2011, at 9:30 AM, Torsten Curdt wrote:

> So what should one use e.g. for normal IBOutlets with AppKit?



The answer is in the 2010-12-21 revision of the Memory Management Programming 
Guide.

It seems to be missing however from the current 2011-03-24 revision of this 
document.

Here is the quote from the older revision.



Memory Management Programming Guide, Memory Management of Nib Objects

When a nib file is loaded and outlets established, the nib-loading mechanism 
always uses accessor methods if they are present (on both Mac OS X and iOS). 
Therefore, whichever platform you develop for, you should typically declare 
outlets using the Objective-C declared properties feature.

The general form of the declaration should be:

@property (attributes) IBOutlet UserInterfaceElementClass *anOutlet;

The behavior of outlets depends on the platform (see “Mac OS X” (page 47) and 
“iOS” (page 48)), so the actual declaration differs:

● For Mac OS X, you should use:

 @property (assign) IBOutlet UserInterfaceElementClass *anOutlet;

● For iOS, you should use:

 @property (nonatomic, retain) IBOutlet UIUserInterfaceElementClass 
*anOutlet;

You should then either synthesize the corresponding accessor methods, or 
implement them according to the declaration, and (in iOS) release the 
corresponding variable in dealloc.

This pattern also works if you use the modern runtime and synthesize the 
instance variables, so it remains consistent across all situations.



--Richard

___

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: nonatomic vs atomic assign/retain

[Thomas Davie]

There are two schools of thought on atomic/nonatomic, and both apply equally to 
Mac/iOS:

1) Atomicity provides a little bit of safety, and shouldn't be shrugged off for 
no reason.  Because of that, only optimise the atomic set/get when you've 
actually profiled and determined it's a problem.

2) When multithreading you rarely if ever actually want atomicity at the 
property level, instead you want somewhat larger critical sections in general.  
Because of that, atomic setters/getters are pointless cruft and everything 
should be made monatomic.

Chose which camp you live in.

Tom Davie
if (*ra4 != 0xffc78948) { return false; }

On 6 Sep 2011, at 16:30, Torsten Curdt wrote:

> On iOS properties are usually (unless required otherwise) defined as nonatomic
> 
> @property (nonatomic, assign)
> 
> On the Mac I have seen quite often just an "assign" or "retain" which
> AFAIK defaults to "atomic"
> 
> @property (assign)
> 
> So what should one use e.g. for normal IBOutlets with AppKit?
> I would think "nonatomic" should be good enough on Mac, too. No?
> 
> cheers,
> Torsten
> ___
> 
> 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/tom.davie%40gmail.com
> 
> This email sent to tom.da...@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

nonatomic vs atomic assign/retain

[Torsten Curdt]

On iOS properties are usually (unless required otherwise) defined as nonatomic

 @property (nonatomic, assign)

On the Mac I have seen quite often just an "assign" or "retain" which
AFAIK defaults to "atomic"

 @property (assign)

So what should one use e.g. for normal IBOutlets with AppKit?
I would think "nonatomic" should be good enough on Mac, too. No?

cheers,
Torsten
___

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: Long delay of NSPopUpButton first click

[Rimas M.]

M.. Actually not. I am using "setImage:" of NSMenuItem to keep default
highlighted item selection drawing and large menu scrolling with
scroll-wheel.

Rimas M.

On Tue, Sep 6, 2011 at 4:40 PM, Glenn L. Austin wrote:
>
> Yes, you will need to set the item's title, unless accessibility isn't an
> issue for you or all of your customers.
>
> Since you're using a view for the menu item in order to draw the contents
> (right?), that view is what the user sees on the screen, but the text is
> what the accessibility system uses.
>
___

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

NSDatePickerCell in TableView/OutlineView

[Half Activist]

Hi,
I'm starting using a nsdatepickercell in an outlineview, but cannot 
edit the values.
The column is editable though, and my delegate returns YES for 
outlineView:(NSOutlineView *)outlineView shouldEditTableColumn:(NSTableColumn 
*)tableColumn item:(id)item.
I've read NSdatePickerCell was not editable back in Tiger's days, but 
is it editable in Snow Leopard & Lion?

Thanks in advance.

___

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: Long delay of NSPopUpButton first click

[Glenn L. Austin]

On Sep 5, 2011, at 11:44 PM, Rimas M. wrote:

> 
> 
> On Mon, Aug 29, 2011 at 6:40 PM, Glenn L. Austin  
> wrote:
> <...> 
> Also, just because you're using an image for the menu item doesn't mean that 
> you can't set the title of the item.
> 
> Yes - I can set the title of item with an image, but I don't need 
> "duplicated" title which is presented by both - image and title itself: 
> https://www.dropbox.com/s/9psws3vavxpkya4/Duplicated-menuitem-title.png
> All I need is "nice" font preview (which should be done by using image) and 
> keep first letter of title shortcut.

Yes, you will need to set the item's title, unless accessibility isn't an issue 
for you or all of your customers.

Since you're using a view for the menu item in order to draw the contents 
(right?), that view is what the user sees on the screen, but the text is what 
the accessibility system uses.

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


___

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

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

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

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

Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Mike Abdullah]

On 6 Sep 2011, at 12:10, Vyacheslav Karamov wrote:

> Cast window to the type id:
> 
> if ([window respondsToSelector:@selector(setRestorationClass:)])
> {
> [(id)window setRestorationClass:someClass];
> }

That will only quieten the warning if -setRestorationClass: has been declared 
for some other class, which in the 10.6 SDK is not the case.

___

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: Window closes on its own

[Alexander Reichstadt]

No, I haven't retained it explicitly. Thanks, makes sense.


Am 06.09.2011 um 11:23 schrieb jonat...@mugginsoft.com:

> 
> On 5 Sep 2011, at 21:25, Alexander Reichstadt wrote:
> 
>> I can't due to using the garbage collection.
>> 
>> Am 05.09.2011 um 20:47 schrieb Jens Alfke:
>> 
>>> 
>>> On Sep 5, 2011, at 12:08 AM, Alexander Reichstadt wrote:
>>> 
 the window created through the following code closes on its own after one 
 second. Why?
>>> 
>>> I’m guessing there’s an extra -release call (or insufficient -retains) and 
>>> the window’s getting dealloced after the autorelease pool drains.
>>> 
>>> Try setting a breakpoint in the -dealloc method, adding a generic -dealloc 
>>> if you don’t already have one.
>>> 
> 
> Jens' point is still valid. Have you retained a reference to your controller 
> object so that it is reachable? 
> 
> PWSuggestionsWindowController *newCon = [[PWSuggestionsWindowController 
> alloc] initWithWindowNibName:@"PWSuggestionsView"];
>   [[newCon window] makeKeyAndOrderFront:self];
> 
> In the above snippet newCon needs to be reachable or the collector will 
> finalise it.
> Normally controller objects are referenced via ivars, often in the 
> application delegate.
> This makes them reachable via the application root (NSApp).
> 
> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcEssentials.html
> 
> Regards
> 
> Jonathan Mitchell
> 
> Developer
> Mugginsoft LLP
> http://www.mugginsoft.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/lxr%40mac.com
> 
> This email sent to l...@mac.com

___

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

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

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

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

Re: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Vyacheslav Karamov]

Cast window to the type id:

if ([window respondsToSelector:@selector(setRestorationClass:)])
{
[(id)window setRestorationClass:someClass];
}



06-Sep-11 13:33, Oleg Krupnov пишет:

if ([window respondsToSelector:@selector(setRestorationClass:)])
{
[window setRestorationClass:someClass];
}


___

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: The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Mike Abdullah]

You're supposed to in such circumstances set your Deployment Target to 10.6, 
but SDK to 10.7. That will allow you to use new methods without warnings, but 
ship on 10.6.

performSelector really isn't cumbersome at all:

[window performSelector:@selector(setRestorationClass:) withObject:someClass];

On 6 Sep 2011, at 11:33, Oleg Krupnov wrote:

> Hi,
> 
> I'm implementing a new Lion's API, namely the resume. I need to make
> the following call:
> 
> [window setRestorationClass:someClass];
> 
> I'd like my app to also work on Snow Leopard, so I do this:
> 
> if ([window respondsToSelector:@selector(setRestorationClass:)])
> {
> [window setRestorationClass:someClass];
> }
> 
> however, because I compile for Snow Leopard, the compiler will still
> give me a warning that the setRestorationClass: method is not defined.
> 
> How do I work around this, other than using [NSObject
> performSelector:withObject:...], which looks too cumbersome, and other
> than deriving all windows from a base class that will define this
> method? Extensions are not suitable either, because there is no way to
> call super from them. Any other ideas?
> 
> 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/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

The best way to call Cocoa methods not implemented in previous versions of the SDK?

[Oleg Krupnov]

Hi,

I'm implementing a new Lion's API, namely the resume. I need to make
the following call:

[window setRestorationClass:someClass];

I'd like my app to also work on Snow Leopard, so I do this:

if ([window respondsToSelector:@selector(setRestorationClass:)])
{
[window setRestorationClass:someClass];
}

however, because I compile for Snow Leopard, the compiler will still
give me a warning that the setRestorationClass: method is not defined.

How do I work around this, other than using [NSObject
performSelector:withObject:...], which looks too cumbersome, and other
than deriving all windows from a base class that will define this
method? Extensions are not suitable either, because there is no way to
call super from them. Any other ideas?

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: NSBrowser column titles disappear when scrolled [SOLVED]

[Bill Cheeseman]

On Sep 5, 2011, at 8:39 AM, Bill Cheeseman wrote:

> Long ago, I found that NSBrowser column titles disappear when the user 
> manually scrolls the browser horizontally, or clicks a cell that forces the 
> browser to scroll horizontally to show the children of the new selection in 
> the next column. Manually resizing the window or any column causes them to 
> reappear immediately. (This is with the browser set so that each column takes 
> its title from the previous column's selection, and the user is allowed to 
> resize columns.) This seems like it must be a bug in NSBrowser.
> 
> For many years, I cured the problem by implementing the -browserDidScroll: 
> delegate method and calling -setNeedsDisplayInRect: on the title frame of the 
> last column.
> 
> That fix no longer works in Lion, and I can't find any other way to fix it.


The solution is very surprising. I had always called -[NSBrowser setTitled:], 
setting it to YES in my window controller's -awakeFromNib method. This does 
have the expected effect of showing column titles initially -- but they 
disappear when the browser is scrolled horizontally, although the rect where 
they initially appeared is still there above the browser.

The solution is to set the "Titled" checkbox in Interface Builder instead of 
calling -setTitled: in -awakeFromNib. Surely this is a bug in NSBrowser, and it 
must have been around since Jaguar or earlier.

I also notice that setting "Titled" in Interface Builder causes "Separators" to 
be checked when you close the Interface Builder editor and then reopen it. It 
isn't nice to have Interface Builder automatically changing settings behind my 
back like this. Also, if I call -setSeparatesColumns: along with -setTitled in 
-awakeFromNib instead of using Interface Builder, the column titles still don't 
work right. So this is clearly a case of Interface Builder settings working 
when the corresponding methods do not work correctly. To add to the mystery, 
the documentation for -setSeparatesColumns: says its value "is ignored if 
-isTitled: does not return no." The double negative must have confused the 
author of that sentence, because the value of YES does seem to be required (at 
least in Interface Builder) for column titles to work correctly.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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: Window closes on its own

[jonat...@mugginsoft.com]

On 5 Sep 2011, at 21:25, Alexander Reichstadt wrote:

> I can't due to using the garbage collection.
> 
> Am 05.09.2011 um 20:47 schrieb Jens Alfke:
> 
>> 
>> On Sep 5, 2011, at 12:08 AM, Alexander Reichstadt wrote:
>> 
>>> the window created through the following code closes on its own after one 
>>> second. Why?
>> 
>> I’m guessing there’s an extra -release call (or insufficient -retains) and 
>> the window’s getting dealloced after the autorelease pool drains.
>> 
>> Try setting a breakpoint in the -dealloc method, adding a generic -dealloc 
>> if you don’t already have one.
>> 

Jens' point is still valid. Have you retained a reference to your controller 
object so that it is reachable? 

PWSuggestionsWindowController *newCon = [[PWSuggestionsWindowController alloc] 
initWithWindowNibName:@"PWSuggestionsView"];
   [[newCon window] makeKeyAndOrderFront:self];

In the above snippet newCon needs to be reachable or the collector will 
finalise it.
Normally controller objects are referenced via ivars, often in the application 
delegate.
This makes them reachable via the application root (NSApp).

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcEssentials.html

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.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: Long delay of NSPopUpButton first click

[Rimas M.]

OK. Answering by myself - to avoid title "duplication" it is possible by
setting "small-invisible" attributed title.

Rimas M.

On Tue, Sep 6, 2011 at 9:47 AM, Rimas M.  wrote:

>
> Going to try masked image way right now. As for plain text title, I am
> confused, because if I do that, menu items have two titles - image and plain
> text:
> https://www.dropbox.com/s/9psws3vavxpkya4/Duplicated-menuitem-title.png
>
> Regards,
>
> Rimas M.
>
___

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