App store rejection, inappropriate sandboxing
Dear list, I recently submitted updates to three different apps on the app store. All three were rejected due to: "This app uses one or more entitlements which do not have matching functionality within the app. Apps should have only the minimum set of entitlements necessary for the app to function properly. Please remove all entitlements that are not needed by your app and submit an updated binary for review, including the following: com.apple.developer.maps “ None of these apps uses the maps entitlement. I’ve checked in Xcode that the entitlements file doesn’t contain this, and that under Capabilities the Maps switch is off. The resolution centre is suggesting that I use a DTS ticket to resolve this, but before I do, has anyone else had the same problem and found a solution? All submissions were made using Xcode Version 6.1 (6A1046a). Many thanks, 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: App store rejection, inappropriate sandboxing
I had the same issue: it turned out that Xcode's automatic provisioning profile choice was not as smart as I'd hoped and had picked a provisioning profile that had a maps entitlement. Setting the correct profile fixed it. I'd check there first before a DTS Iain > On 29 Oct 2014, at 7:01 am, Martin Hewitson > wrote: > > Dear list, > > I recently submitted updates to three different apps on the app store. All > three were rejected due to: > > "This app uses one or more entitlements which do not have matching > functionality within the app. Apps should have only the minimum set of > entitlements necessary for the app to function properly. Please remove all > entitlements that are not needed by your app and submit an updated binary for > review, including the following: > > com.apple.developer.maps > “ > > None of these apps uses the maps entitlement. I’ve checked in Xcode that the > entitlements file doesn’t contain this, and that under Capabilities the Maps > switch is off. The resolution centre is suggesting that I use a DTS ticket to > resolve this, but before I do, has anyone else had the same problem and found > a solution? > > All submissions were made using Xcode Version 6.1 (6A1046a). > > Many thanks, > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/iain%40falsevictories.com > > This email sent to i...@falsevictories.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: App store rejection, inappropriate sandboxing
Iain, I forgot to say that this was the first thing I checked when the apps were first rejected. I moved from the automatic provisioning profile to explicit ones, but still the apps were rejected. Maybe I still got the provisioning profiles wrong. I’ll double check. Thanks! Martin > On 29 Oct 2014, at 08:35, iain wrote: > > I had the same issue: it turned out that Xcode's automatic provisioning > profile choice was not as smart as I'd hoped and had picked a provisioning > profile that had a maps entitlement. Setting the correct profile fixed it. > > I'd check there first before a DTS > > Iain > > > >> On 29 Oct 2014, at 7:01 am, Martin Hewitson >> wrote: >> >> Dear list, >> >> I recently submitted updates to three different apps on the app store. All >> three were rejected due to: >> >> "This app uses one or more entitlements which do not have matching >> functionality within the app. Apps should have only the minimum set of >> entitlements necessary for the app to function properly. Please remove all >> entitlements that are not needed by your app and submit an updated binary >> for review, including the following: >> >> com.apple.developer.maps >> “ >> >> None of these apps uses the maps entitlement. I’ve checked in Xcode that the >> entitlements file doesn’t contain this, and that under Capabilities the Maps >> switch is off. The resolution centre is suggesting that I use a DTS ticket >> to resolve this, but before I do, has anyone else had the same problem and >> found a solution? >> >> All submissions were made using Xcode Version 6.1 (6A1046a). >> >> Many thanks, >> >> 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Flash without photo?
Is it possible to fire the flash (LED) on my iPhone 5(s) without taking a photo? (i.e. is there a programmatic interface to turn the LED on/off via an ObjC message send? Can I talk to it directly using C? Also, does iOS have OpenCV, or something like it, so the camera can detect flashing lights (either from the "flash" LED on another smartphone, or even a flashlight)? I'd like to make a simple morse code sender/receiver using a pair of iPhones that have the "flash" LED, and the camera. The initial version would just have a UIView with a UIButton the user could tap to turn the LED on, and a UIImage (?) showing the current "view" the camera sees, and - under that - a UILabel showing the translated morse code as the user taps the button. Later, I'd like to have two UILabels, one for sending and one for receiving, so that it would also translate the incoming messages as well, by detecting the flashing with the camera itself. This is why I'm guessing I'll need OpenCV library. If not, no biggie. ___ 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: Flash without photo?
Given the number of flashlight apps in the store the answer had to be a yes. Check the docs for ‘torch’ and ‘flash', that seems to have interfaces for turning the LED on and off, whether the torch one or the flash one or possibly they are the same anyway. > On 29 Oct 2014, at 7:31 pm, William Squires wrote: > > Is it possible to fire the flash (LED) on my iPhone 5(s) without taking a > photo? (i.e. is there a programmatic interface to turn the LED on/off via an > ObjC message send? Can I talk to it directly using C? Also, does iOS have > OpenCV, or something like it, so the camera can detect flashing lights > (either from the "flash" LED on another smartphone, or even a flashlight)? > I'd like to make a simple morse code sender/receiver using a pair of iPhones > that have the "flash" LED, and the camera. The initial version would just > have a UIView with a UIButton the user could tap to turn the LED on, and a > UIImage (?) showing the current "view" the camera sees, and - under that - a > UILabel showing the translated morse code as the user taps the button. Later, > I'd like to have two UILabels, one for sending and one for receiving, so that > it would also translate the incoming messages as well, by detecting the > flashing with the camera itself. This is why I'm guessing I'll need OpenCV > library. > If not, no biggie. > > > ___ > > 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/rols%40rols.org > > This email sent to r...@rols.org ___ 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: Flash without photo?
On 29 Oct 2014, at 10:31 pm, William Squires wrote: > Is it possible to fire the flash (LED) on my iPhone 5(s) without taking a > photo? Have a look at AVCaptureDevice - it has various methods for detecting whether the hardware supports a torch and for turning it on and off. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Turn off background click behavior on a window?
Is there no way to turn off the annoying and dangerous behavior of views accepting background clicks, short of subclassing every view in a window and returning NO from acceptsFirstMouse:? The only docs I can find still state the opposite of what happens these days (https://developer.apple.com/library/mac/documentation/cocoa/conceptual/eventoverview/HandlingMouseEvents/HandlingMouseEvents.html#//apple_ref/doc/uid/1060i-CH6-SW17): "By default, a mouse-down event in a window that isn’t the key window simply brings the window forward and makes it key; the event isn’t sent to the NSView object over which the mouse click occurs." That's not what I get. Background clicks cause the window to become key AND the click is handled by the view that was clicked. I don't want that. The window should only become key and the clicked view should ignore the event. -- Steve Mills Drummer, Mac geek ___ 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: NSComboBox in the tab ring
On 18 Oct 2014, at 11:14 PM, Luther Baker wrote: > > Is it possible to keep an NSComboBox in the tabbing ring if I set its > "Behavior" to "Selectable". Tabbing reaches the control if the textfield is > editable but I don't want to allow the user to type randomly into the text > field ... but unfortunately, once I remove its editability, the tabbing > cycle skips the control. An NSComboBox is an instance of a subclass of NSTextField. Use as a free-form text-entry control, _assisted by_ suggested completions, is the essence of the class. Text fields are either editable or not. One might wish NSComboBox were a different object, but it isn’t. The text field delegate methods let you constrain the user’s input on-the-fly, and there are additional delegate methods and notifications for combo boxes; see if you can get what you want that way. Maybe CocoaPods has something, it’s a commonly-desired feature. — F ___ 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: Turn off background click behavior on a window?
> On 29 Oct 2014, at 15:21, Steve Mills wrote:
>
> Is there no way to turn off the annoying and dangerous behavior of views
> accepting background clicks, short of subclassing every view in a window and
> returning NO from acceptsFirstMouse:? The only docs I can find still state
> the opposite of what happens these days
> (https://developer.apple.com/library/mac/documentation/cocoa/conceptual/eventoverview/HandlingMouseEvents/HandlingMouseEvents.html#//apple_ref/doc/uid/1060i-CH6-SW17):
>
> "By default, a mouse-down event in a window that isn’t the key window simply
> brings the window forward and makes it key; the event isn’t sent to the
> NSView object over which the mouse click occurs."
>
> That's not what I get. Background clicks cause the window to become key AND
> the click is handled by the view that was clicked. I don't want that. The
> window should only become key and the clicked view should ignore the event.
>
Hmm.
I created a sample project with a single NSWindow and content view subclass
like so:
@implementation TestView
- (void)mouseDown:(NSEvent *)theEvent
{
NSLog(@"Mouse down");
}
/*
- (BOOL)acceptsFirstMouse:(NSEvent *)theEvent
{
return YES;
} */
@end
It seems to behave as the docs suggest on OS X 10.9.
Perhaps your app has some additional event handling in place.
Jonathan
___
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: Turn off background click behavior on a window?
On Oct 29, 2014, at 11:05:42, Jonathan Mitchell wrote:
> I created a sample project with a single NSWindow and content view subclass
> like so:
> @implementation TestView
>
> - (void)mouseDown:(NSEvent *)theEvent
> {
>NSLog(@"Mouse down");
> }
>
> /*
> - (BOOL)acceptsFirstMouse:(NSEvent *)theEvent
> {
>return YES;
> } */
>
> @end
>
> It seems to behave as the docs suggest on OS X 10.9.
> Perhaps your app has some additional event handling in place.
I tried that as well, but returned NO from acceptsFirstMouse:. It still came
forward and clicked subviews when I clicked them in the background. Did you add
subviews inside your subclass view and try clicking those while your app was in
the background? My app doesn't have any special event handling. I might try
overriding sendEvent:, but that just seems so brute-force when there should be
a way to tell the window to just come forward and ignore clicks like all
windows used to do.
--
Steve Mills
Drummer, Mac geek
___
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: Turn off background click behavior on a window?
> On 29 Oct 2014, at 16:16, Steve Mills wrote:
>
> On Oct 29, 2014, at 11:05:42, Jonathan Mitchell
> wrote:
>
>> I created a sample project with a single NSWindow and content view subclass
>> like so:
>> @implementation TestView
>>
>> - (void)mouseDown:(NSEvent *)theEvent
>> {
>> NSLog(@"Mouse down");
>> }
>>
>> /*
>> - (BOOL)acceptsFirstMouse:(NSEvent *)theEvent
>> {
>> return YES;
>> } */
>>
>> @end
>>
>> It seems to behave as the docs suggest on OS X 10.9.
>> Perhaps your app has some additional event handling in place.
>
> I tried that as well, but returned NO from acceptsFirstMouse:. It still came
> forward and clicked subviews when I clicked them in the background. Did you
> add subviews inside your subclass view and try clicking those while your app
> was in the background?
Yes. Works as docs suggest on 10.9 and 10.10.
> My app doesn't have any special event handling. I might try overriding
> sendEvent:, but that just seems so brute-force when there should be a way to
> tell the window to just come forward and ignore clicks like all windows used
> to do.
>
Does sound like overkill. I would put together a trivial test project and work
back from there.
J
___
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: Turn off background click behavior on a window?
On Oct 29, 2014, at 11:24:49, Jonathan Mitchell wrote: > > Does sound like overkill. I would put together a trivial test project and > work back from there. Same result. New Cocoa app project, subclassed NSView and handled acceptsFirstClick:, which returns NO, set the main window's content view to be that class, and added a button to the content view. Clicking the button while in the background works. I don't see how your test can possibly give you that result. You did have acceptsFirstClick: commented out, and it was returning YES. What happens if you uncomment it and return NO? If I instead subclass NSButton, set the button's class to that, and return NO from its acceptsFirstClick:, THEN it works. -- Steve Mills Drummer, Mac geek ___ 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: Turn off background click behavior on a window?
> On 29 Oct 2014, at 17:08, Steve Mills wrote: > > On Oct 29, 2014, at 11:24:49, Jonathan Mitchell > wrote: >> >> Does sound like overkill. I would put together a trivial test project and >> work back from there. > > Same result. New Cocoa app project, subclassed NSView and handled > acceptsFirstClick:, which returns NO, set the main window's content view to > be that class, and added a button to the content view. Clicking the button > while in the background works. I don't see how your test can possibly give > you that result. You did have acceptsFirstClick: commented out, and it was > returning YES. What happens if you uncomment it and return NO? > > If I instead subclass NSButton, set the button's class to that, and return NO > from its acceptsFirstClick:, THEN it works. Sure. This is expected behaviour for NSButton subclasses of NSView. The docs for NSView acceptsFirstMouse: state: Override this method in a subclass to allow instances to respond to click-through. This allows the user to click on a view in an inactive window, activating the view with one click, instead of clicking first to make the window active and then clicking the view. Most view objects refuse a click-through attempt, so the event simply activates the window. Many control objects, however, such as instances of NSButton and NSSlider, do accept them, so the user can immediately manipulate the control without having to release the mouse button. J ___ 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: Turn off background click behavior on a window?
On Oct 29, 2014, at 12:17:58, Jonathan Mitchell wrote: > Sure. This is expected behaviour for NSButton subclasses of NSView. > > The docs for NSView acceptsFirstMouse: state: > > Override this method in a subclass to allow instances to respond to > click-through. This allows the user to click on a view in an inactive window, > activating the view with one click, instead of clicking first to make the > window active and then clicking the view. Most view objects refuse a > click-through attempt, so the event simply activates the window. Many control > objects, however, such as instances of NSButton and NSSlider, do accept them, > so the user can immediately manipulate the control without having to release > the mouse button. I know. As I said in my first message, I'm trying to *prevent* this behavior on the entire window for all subviews withOUT having to subclass every conceivable class that I might add to my window. -- Steve Mills Drummer, Mac geek ___ 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: Turn off background click behavior on a window?
> On 29 Oct 2014, at 17:26, Steve Mills wrote: > > On Oct 29, 2014, at 12:17:58, Jonathan Mitchell > wrote: > >> Sure. This is expected behaviour for NSButton subclasses of NSView. >> >> The docs for NSView acceptsFirstMouse: state: >> >> Override this method in a subclass to allow instances to respond to >> click-through. This allows the user to click on a view in an inactive >> window, activating the view with one click, instead of clicking first to >> make the window active and then clicking the view. Most view objects refuse >> a click-through attempt, so the event simply activates the window. Many >> control objects, however, such as instances of NSButton and NSSlider, do >> accept them, so the user can immediately manipulate the control without >> having to release the mouse button. > > I know. As I said in my first message, I'm trying to *prevent* this behavior > on the entire window for all subviews withOUT having to subclass every > conceivable class that I might add to my window. Sorry. It wasn’t initially clear that you were referring to NSButton instances. Surely the issue then lies with the default behaviour of NSButton. Without subclassing you may indeed need to investigate overriding NSApplication -sendEvent: Why is this behaviour so undesirable? J ___ 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: Turn off background click behavior on a window?
On Oct 29, 2014, at 12:37:22, Jonathan Mitchell wrote: > > Why is this behaviour so undesirable? 1. Only rarely do I find it expected and useful. Otherwise, it's not good user experience. 2. It forces you to aim at empty spaces if you simply want to bring a window forward without inadvertently clicking something, so it slows you down. 3. It can be dangerous if you forget that an app exhibits this behavior and you accidentally click a control in the background when you simple wanted to activate the window, and that control deletes something, changes something, or otherwise messes stuff up. -- Steve Mills Drummer, Mac geek ___ 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: Turn off background click behavior on a window?
On Wed, Oct 29, 2014, at 11:46 AM, Steve Mills wrote: > 3. It can be dangerous if you forget that an app exhibits this behavior > and you accidentally click a control in the background when you simple > wanted to activate the window, and that control deletes something, > changes something, or otherwise messes stuff up. This is what I remember the guideline to be, and I believe it's why Safari prevents any clicks on background windows from going through to the WebView. (Safari doesn't know what clicks are "innocuous".) You can always click the close button on a window without bringing it to the foreground, though. And you can hold down the Command key to send a click to a background window without bringing it to the foreground (though I haven't tested whether this overrides the window's desire to avoid destructive background clicks). Steve, you might have to subclass NSWindow and override -sendEvent:. May I suggest you let background window clicks go through to certain key buttons, like "mute playback"? --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Turn off background click behavior on a window?
On Oct 29, 2014, at 10:26 , Steve Mills wrote: > > As I said in my first message, I'm trying to *prevent* this behavior on the > entire window for all subviews withOUT having to subclass every conceivable > class that I might add to my window. You can’t, because it’s not window behavior but rather view behavior (in spite of the way the documentation is worded) and the default NSView behavior *is* what you want/expect. What’s changed over the years is that particular NSView subclasses (especially NSButton, but probably some other controls too) have changed to return YES from “acceptsFirstMouse:’. To “fix” this, you don’t have to subclass every conceivable class. You can subclass NSButton and perhaps a few other controls that you might care about. However, this is the wrong solution. A button that doesn’t click through should *look* different when the app is in the background (and shouldn’t do rollover highlighting). So a better solution is to disable buttons you don’t want click-through for, when your app enters the background. Note that you don’t have to do this via code. If you provide a suitable property on (say) your app delegate, you can control the button enable state through a binding, so it’s no more onerous than hooking up action methods. > 1. Only rarely do I find it expected and useful. Otherwise, it's not good > user experience. You’re generalizing based on … personal preference? > 2. It forces you to aim at empty spaces if you simply want to bring a window > forward without inadvertently clicking something, so it slows you down. Converse: having the buttons be unclickable in the background forces you to click twice if you want to click something you can see, so it slows you down. > 3. It can be dangerous if you forget that an app exhibits this behavior and > you accidentally click a control in the background when you simple wanted to > activate the window, and that control deletes something, changes something, > or otherwise messes stuff up. Dangerous things should be undoable or have a confirming alert anyway. ___ 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: Turn off background click behavior on a window?
> On Oct 29, 2014, at 10:57 AM, Quincey Morris > wrote: > > However, this is the wrong solution. A button that doesn’t click through > should *look* different when the app is in the background (and shouldn’t do > rollover highlighting). So a better solution is to disable buttons you don’t > want click-through for, when your app enters the background. +1. This is what the 'classic' OS (Mac OS ≤ 9) did. That way you could tell whether a button was directly pressable or not. (The downside was increased flicker / visual noise when switching windows.) >> 1. Only rarely do I find it expected and useful. Otherwise, it's not good >> user experience. > > You’re generalizing based on … personal preference? +1 again. Steve, be wary of disabling long-established system-wide UI behaviors in your app just because you _personally_ dislike them. Chances are there are a lot of users who do like them, or at least have learned them subliminally, and may be confused/annoyed when they for some reason don't work in your app. Anecdotally, a lot of casual/inexperienced users don't really understand the distinction between active and inactive windows, especially when the windows aren't overlapping. So having buttons work differently based on that distinction is likely to be confusing to them. That was one of the reasons the original Aqua UI design deliberately changed the behavior of controls to leave them enabled in non-active windows. —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Turn off background click behavior on a window?
On Wed, Oct 29, 2014, at 11:57 AM, Quincey Morris wrote: > However, this is the wrong solution. A button that doesn’t click through > should *look* different when the app is in the background (and shouldn’t > do rollover highlighting). So a better solution is to disable buttons you > don’t want click-through for, when your app enters the background. Huh. I am surprised, but apparently this is precisely what Mail does: you can't Trash a message in a background window, even if you Command-click it. > Dangerous things should be undoable or have a confirming alert anyway. Steve writes music software. To pick an example, disabling recording on an active input track should NOT require a confirmation alert, even though it's a destructive action. --Kyle ___ 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: Turn off background click behavior on a window?
On Oct 29, 2014, at 12:15 PM, Kyle Sluder wrote: > On Wed, Oct 29, 2014, at 11:57 AM, Quincey Morris wrote: >> However, this is the wrong solution. A button that doesn’t click through >> should *look* different when the app is in the background (and shouldn’t >> do rollover highlighting). So a better solution is to disable buttons you >> don’t want click-through for, when your app enters the background. > > Huh. I am surprised, but apparently this is precisely what Mail does: > you can't Trash a message in a background window, even if you > Command-click it. > >> Dangerous things should be undoable or have a confirming alert anyway. > > Steve writes music software. To pick an example, disabling recording on > an active input track should NOT require a confirmation alert, even > though it's a destructive action. I vote for binding the button's enabled flag to something, then - if the button looks active, nothing's covering the window, and I don't notice the color of the title stoplight, I'm going to be annoyed if nothing happens when I click. ___ 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: Turn off background click behavior on a window?
On Oct 29, 2014, at 14:15:50, Kyle Sluder wrote: > Huh. I am surprised, but apparently this is precisely what Mail does: > you can't Trash a message in a background window, even if you > Command-click it. I'm glad to see that now (on 10.9 and 10.10), as I'm almost sure it didn't do that at some point in the past. I thought I'd submitted a bug about that, but I don't see it now (could've been under a previous job's login). > Steve writes music software. To pick an example, disabling recording on > an active input track should NOT require a confirmation alert, even > though it's a destructive action. In this case, it's one of my personal apps, but "dangerous" still applies: There is a button named Search, which can perform a long search through thousands of image files. If the user had already done so, and the search took some good amount of time, and they'd scrolled through the list to select one of the resulting images, accidentally clicking the Search button while the app is in the background will cause all that time to be wasted and they'll have to wait for the search to complete again, etc. There are also NSPathControls in my window, which also accept background clicks - it just seems careless when things happen to a background window. If a user can't tell which window is active, then perhaps it's Apple's fault for not making it more graphically apparent, not the user's fault for not understanding why they shouldn't be able to click a button that looks enabled. The fact that some controls will appear slightly different in the background when you hover over them is a step in the right direction, but human reaction speed isn't always quick enough to abort a click action that they started over a background window before they noticed that the button *slightly* changed its appearance to signal that it can be background-clicked. The toolbar buttons in Mail is a great example of this. Not everyone can easily see how that new icons in 10.10 slightly darken. I'm going with the background disabling for my app. Ten bucks says nobody will complain about it. -- Steve Mills Drummer, Mac geek ___ 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: NSComboBox in the tab ring
On 19 Oct 2014, at 3:14 pm, Luther Baker wrote: > I don't want to allow the user to type randomly into the text > field It *is* a text field. Sounds like what you really want is a pop-up menu button. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Turn off background click behavior on a window?
On Oct 29, 2014, at 12:15 , Kyle Sluder wrote: > >> Dangerous things should be undoable or have a confirming alert anyway. > > Steve writes music software. To pick an example, disabling recording on > an active input track should NOT require a confirmation alert, even > though it's a destructive action. Sorry, I was a bit lazy in what I said. I agree that there are cases where the button shouldn’t work in the background, and even undo or a confirming alert aren’t a good way of dealing with buttons that *shouldn’t* (for separate reasons) be enabled in the background. I think I was trying to say that disabling seems justifiable only in a minority of cases, not routinely. I also wanted to emphasize my agreement with the sentiment (expressed in a couple of posts) that there’s an issue of what we who’ve used Macs since the very old days have *trained* ourselves to expect. It’s worth remembering that even back then, background Unix windows (in X11 or whatever) were active, and Unix users used to laugh at us for having disabled background windows, and the world didn’t end just because they did it their own way. ___ 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: NSComboBox in the tab ring
Yep - I ended up going with a Pop Up Button for the reason's you've both mentioned. Thanks for replying with a bit of explanation and suggestions! -Luther On Wed, Oct 29, 2014 at 3:16 PM, Graham Cox wrote: > > On 19 Oct 2014, at 3:14 pm, Luther Baker wrote: > > > I don't want to allow the user to type randomly into the text > > field > > > It *is* a text field. Sounds like what you really want is a pop-up menu > button. > > --Graham > > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
