Re: NSScreen ID Unreliable
I¹m mostly using it for setting/retrieving/showing a capture region on the screen. If the user manually draws a capture region, I have to determine the relevant screen ID in order to know if the AVScreenCaptureInput object needs to be replaced with a new one. (You can only set it¹s capture screen ID in its init method.) I would also like to save the user¹s setup so he/she doesn¹t have to redo everything on each application launch, if the physical screens are the same. Getting two different IDs for the same screen within the same run is causing some grief. At least now I know the problem is real, and not something I did wrong in my code. I¹m just going to have to figure out how to deal with it. It really threw me when I could not reproduce it in sample code. Now I understand why. On 10/9/12 1:00 PM, "cocoa-dev-requ...@lists.apple.com" wrote: > I use frame comparisons. I think the answer is going to depend on what you > need it for. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Localising "dynamic" string resources in code
A better approach when using NSLocalizedString and its variants is to always use a highly non-user-friendly string for the key that matches the definitive meaning behind the particular string. One benefit is that when you see that string in your UI, you know you don't have a translated string for that key, and the problem is squarely within your strings files. Another benefit is for those cases where you really may want the same string in your development language (e.g., English) but at least one other language may need a very different string. Another benefit is that you use the strings files for what they were meant for, an encapsulation of human-readable textual resources rather than hard-coding something within your software. An example from a project I once worked on where the same string may be used in the development language but differ in other languages is the string "State". In US English, this word refers to a governmental body. It also means the current condition of some variable. To change either string to be more descriptive would be overkill: "State of your Residence/Vote/Used To Live" and "State of that Variable". In UK English, we wanted "County" in place of the governmental body and "State" for the variable condition. By using keys similar to these instead, we solved the collision issue and utilized the string files and source code for what they were meant to be: "--placeForCity" and "--stateOfVariable". And, if we ever saw those, we knew immediately we were in trouble. Also, you should always use named constant variables in your code rather than hard-coding these keys; this will save you from those cases where you want the same key but misspell it in one of the places used. Also, you should look at using APPKIT_EXTERN when defining your named constants in headers (allowing the key to be used across source files), since it can be useful in those cases where you may be needing to do Objective-C++ and Objective-C in the same project. Again, the benefit here is encapsulation: if you want to change the spelling of the key, you have its spelling in one place only (other than the key itself in the strings file) rather than in many different places and possibly missing one. -- Gary L. Wade http://www.garywade.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dropping alias file on NSPathControl with App Sandbox
On 10 Oct 2012, at 17:57, Uli Kusterer wrote: > On Oct 10, 2012, at 6:39 PM, Mike Abdullah wrote: >> * NSPathControl is more aware of the sandbox, and doesn't try to fetch icons >> it doesn't have access to > > Not if NSPathControl runs out-of-process. The NSPathControl you create could > just be an IOSurface drawn into your process's window by another process that > has permissions, or even a separate window that just moves with your > process's window like the accessory view in an NSOpenPanel, just the other > way round. Good point. Mine certainly wasn't an exhaustive list :) All evidence suggests it draws as a regular NSControl so far though. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dropping alias file on NSPathControl with App Sandbox
On Oct 10, 2012, at 6:39 PM, Mike Abdullah wrote: > * NSPathControl is more aware of the sandbox, and doesn't try to fetch icons > it doesn't have access to Not if NSPathControl runs out-of-process. The NSPathControl you create could just be an IOSurface drawn into your process's window by another process that has permissions, or even a separate window that just moves with your process's window like the accessory view in an NSOpenPanel, just the other way round. Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dropping alias file on NSPathControl with App Sandbox
On 10 Oct 2012, at 15:04, "Sean McBride" wrote: > On Wed, 10 Oct 2012 09:46:15 +0100, Mike Abdullah said: > Sandboxed apps can resolve aliases and follow symlinks, but unless the destination is within their sandbox already they do not gain access to it, sadly. I recommend filing a radar requesting this. >>> >>> I will. >>> >>> Do you agree with me that pathControl:acceptDrop: should pass the >> resolved alias instead of the original? Or perhaps provide a >> setResolvesAliases: like NSOpenPanel does? >> >> I don't know really. To resolve aliases properly would require it to be >> some sort of privileged UI component like NSOpenPanel. Or Apple would >> have to add a new entitlement for this, or adjust how the sandbox works. >> They all *work*, but the first option sucks for developers making other >> similar things. > > I'm pretty sure it already is a 'privileged UI component like NSOpenPanel'. > In the early seeds of 10.7, there were all sorts of sandbox violations > related to NSPathControl trying to draw the icons of the file hierarchy, and > failing to have access to those icons. Really? Three possible conclusions come to mind: * The sandbox has been relaxed to allow fetching of icons of ancestor folders * NSPathControl is more aware of the sandbox, and doesn't try to fetch icons it doesn't have access to * NSPathControl has some special privilege which allows it to fetch icons other components can't The last one seems least likely to me since it would be a sandbox hole application-level or malicious code could exploit. Number two also seems slightly improbably to me simply because NSPathControl still has a sandbox-related bug where it no longer recognises a path stems from the user's home directory. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: dropping alias file on NSPathControl with App Sandbox
On Wed, 10 Oct 2012 09:46:15 +0100, Mike Abdullah said: >>> Sandboxed apps can resolve aliases and follow symlinks, but unless the >>> destination is within their sandbox already they do not gain access to >>> it, sadly. I recommend filing a radar requesting this. >> >> I will. >> >> Do you agree with me that pathControl:acceptDrop: should pass the >resolved alias instead of the original? Or perhaps provide a >setResolvesAliases: like NSOpenPanel does? > >I don't know really. To resolve aliases properly would require it to be >some sort of privileged UI component like NSOpenPanel. Or Apple would >have to add a new entitlement for this, or adjust how the sandbox works. >They all *work*, but the first option sucks for developers making other >similar things. I'm pretty sure it already is a 'privileged UI component like NSOpenPanel'. In the early seeds of 10.7, there were all sorts of sandbox violations related to NSPathControl trying to draw the icons of the file hierarchy, and failing to have access to those icons. Cheers, -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Localising "dynamic" string resources in code
On 10 Oct 2012, at 11:45, Ken Thomases wrote:
> On Oct 10, 2012, at 4:25 AM, Luc Van Bogaert wrote:
>
>> I'm in the process of localising my application, and I'm having a problem
>> getting some of the string resources in my code localised. In several places
>> in my code, I'm using this kind of structure to implement "dynamic" menu
>> items:
>>
>> if (action == @selector(toggleInspectorPanel:)) {
>> if ([(NSObject *)item isKindOfClass:[NSMenuItem class]]) {
>> [(NSMenuItem *)item setTitle:([self isInspectorCollapsed] ?
>> NSLocalizedString(@"Show Inspector Panel", @"Menu item to show
>> the Inspector panel") :
>> NSLocalizedString(@"Hide Inspector Panel", @"Menu item to hide
>> the Inspector panel"))];
>> return ![self.inspectorSplitter isAnimating];
>> }
>>
>> Even though both string resources exist and have been translated in my
>> Localized.strings files, I'm always seeing the original English text when I
>> run my localized application.
>>
>> The exact same problem occurs with string resources that are provided to
>> some control in my interface (eg. e dropdown menu) through a binding:
>>
>> - (NSArray *)startupModeNames
>> {
>> return [NSArray arrayWithObjects:
>> NSLocalizedString(@"Sketch Mode", @"Title for SketchBook startup
>> mode"),
>> NSLocalizedString(@"Design Mode", @"Title for SketchBook startup
>> mode"),
>> NSLocalizedString(@"SketchBook Mode", @"Title for SketchBook
>> startup mode"),
>> nil];
>> }
>>
>> Here also, I'm only seeing the original English text instead of the
>> localized version that's available in the Localized.strings file.
>>
>> All the other string recources in my code get translated correctly.
>> Could anyone please help me find out what it is I'm missing here?
>
> There's nothing special about those uses of NSLocalizedString(), nor anything
> particularly "dynamic". If most of your localized strings are working but
> those aren't, you need to verify your assumptions. Check that your
> Localized.strings files are well-formed and properly encoded (UTF-8 or
> UTF-16). You can use the "plutil" program to check them. Check that the keys
> in the .strings files match the keys you're passing to NSLocalizedString().
> Check that your files don't have some invisible characters embedded in the
> keys, making them not match. Check that the values (the translated strings)
> are really translated and not the untranslated English. Do all of those
> checks on the .string files in your built app, not just the source files.
>
OK, thanks for the assistance and confirming there's nothing wrong with my code.
Adding the strings files to my project in XCode (even though they already
existed in the .lproj directories) solved the problem.
Thanks again,
--
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Localising "dynamic" string resources in code
On Oct 10, 2012, at 4:25 AM, Luc Van Bogaert wrote:
> I'm in the process of localising my application, and I'm having a problem
> getting some of the string resources in my code localised. In several places
> in my code, I'm using this kind of structure to implement "dynamic" menu
> items:
>
>if (action == @selector(toggleInspectorPanel:)) {
>if ([(NSObject *)item isKindOfClass:[NSMenuItem class]]) {
>[(NSMenuItem *)item setTitle:([self isInspectorCollapsed] ?
> NSLocalizedString(@"Show Inspector Panel", @"Menu item to show
> the Inspector panel") :
> NSLocalizedString(@"Hide Inspector Panel", @"Menu item to hide
> the Inspector panel"))];
>return ![self.inspectorSplitter isAnimating];
>}
>
> Even though both string resources exist and have been translated in my
> Localized.strings files, I'm always seeing the original English text when I
> run my localized application.
>
> The exact same problem occurs with string resources that are provided to some
> control in my interface (eg. e dropdown menu) through a binding:
>
> - (NSArray *)startupModeNames
> {
>return [NSArray arrayWithObjects:
>NSLocalizedString(@"Sketch Mode", @"Title for SketchBook startup
> mode"),
>NSLocalizedString(@"Design Mode", @"Title for SketchBook startup
> mode"),
>NSLocalizedString(@"SketchBook Mode", @"Title for SketchBook
> startup mode"),
>nil];
> }
>
> Here also, I'm only seeing the original English text instead of the localized
> version that's available in the Localized.strings file.
>
> All the other string recources in my code get translated correctly.
> Could anyone please help me find out what it is I'm missing here?
There's nothing special about those uses of NSLocalizedString(), nor anything
particularly "dynamic". If most of your localized strings are working but
those aren't, you need to verify your assumptions. Check that your
Localized.strings files are well-formed and properly encoded (UTF-8 or UTF-16).
You can use the "plutil" program to check them. Check that the keys in the
.strings files match the keys you're passing to NSLocalizedString(). Check
that your files don't have some invisible characters embedded in the keys,
making them not match. Check that the values (the translated strings) are
really translated and not the untranslated English. Do all of those checks on
the .string files in your built app, not just the source files.
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Localising "dynamic" string resources in code
Hi,
I'm in the process of localising my application, and I'm having a problem
getting some of the string resources in my code localised. In several places in
my code, I'm using this kind of structure to implement "dynamic" menu items:
if (action == @selector(toggleInspectorPanel:)) {
if ([(NSObject *)item isKindOfClass:[NSMenuItem class]]) {
[(NSMenuItem *)item setTitle:([self isInspectorCollapsed] ?
NSLocalizedString(@"Show Inspector Panel", @"Menu item to show
the Inspector panel") :
NSLocalizedString(@"Hide Inspector Panel", @"Menu item to hide
the Inspector panel"))];
return ![self.inspectorSplitter isAnimating];
}
Even though both string resources exist and have been translated in my
Localized.strings files, I'm always seeing the original English text when I run
my localized application.
The exact same problem occurs with string resources that are provided to some
control in my interface (eg. e dropdown menu) through a binding:
- (NSArray *)startupModeNames
{
return [NSArray arrayWithObjects:
NSLocalizedString(@"Sketch Mode", @"Title for SketchBook startup
mode"),
NSLocalizedString(@"Design Mode", @"Title for SketchBook startup
mode"),
NSLocalizedString(@"SketchBook Mode", @"Title for SketchBook
startup mode"),
nil];
}
Here also, I'm only seeing the original English text instead of the localized
version that's available in the Localized.strings file.
All the other string recources in my code get translated correctly.
Could anyone please help me find out what it is I'm missing here?
Many 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: dropping alias file on NSPathControl with App Sandbox
On 10 Oct 2012, at 00:16, Sean McBride wrote: > On Sat, 6 Oct 2012 10:59:46 +0100, Mike Abdullah said: > >> Sandboxed apps can resolve aliases and follow symlinks, but unless the >> destination is within their sandbox already they do not gain access to >> it, sadly. I recommend filing a radar requesting this. > > I will. > > Do you agree with me that pathControl:acceptDrop: should pass the resolved > alias instead of the original? Or perhaps provide a setResolvesAliases: like > NSOpenPanel does? I don't know really. To resolve aliases properly would require it to be some sort of privileged UI component like NSOpenPanel. Or Apple would have to add a new entitlement for this, or adjust how the sandbox works. They all *work*, but the first option sucks for developers making other similar things. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
