Re: inconsistencies in view renderings

2016-10-20 Thread Quincey Morris
On Oct 20, 2016, at 09:53 , Alan Snyder  wrote:
> 
> If you exclude textured controls in the window content area, then my examples 
> are all moot.

Here’s what the HIG has to say about this 
(developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/ControlsAll.html#//apple_ref/doc/uid/2957-CH46-SW2):

> Some Controls Can Be Used in the Window Frame
> 
> A small subset of controls have a display style that makes them suitable for 
> use in the window-frame areas (that is, in the toolbar or a bottom bar); 
> these controls are listed in Table 35-1.
> 
> [… table lists rounded textured buttons, along with textured segmented 
> controls and textured popup menus …]
> 
> *Don’t use the window frame–specific control styles in the window 
> body*[emphasis in original]. The control and style combinations listed Table 
> 35-1 are specially designed to look good on the window-frame, whether it’s 
> translucent or opaque. *These control styles don't look good in the window 
> body*[emphasis in original]. In particular, these control styles can use 
> inactive and other appearances that don't harmonize with standard control 
> styles.
> 
> Don’t use window-body controls or styles in the window frame. All 
> system-provided controls and styles other than those listed in Table 35-1 are 
> designed to look good in the window body and its content regions, and should 
> not be used in the window frame.

Isn’t that the answer to the question you’re asking? I’m not excluding textured 
controls from the content area, Apple is.

> Can you tell me how to create a window with a bottom status bar in IB? It 
> seems to depend on some sort of analysis by AppKit.

Select the window in IB and display the Size inspector. In the last section, 
“Content Border”, enter a manual value in the “Bottom” field. (I haven’t had 
much success with any of the menu choices that promise to set the bottom border 
height automatically.)

___

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: inconsistencies in view renderings

2016-10-20 Thread Alan Snyder
If you exclude textured controls in the window content area, then my examples 
are all moot.

Can you tell me how to create a window with a bottom status bar in IB? It seems 
to depend on some sort of analysis by AppKit.





> On Oct 19, 2016, at 8:16 PM, Quincey Morris 
>  wrote:
> 
> So, clearly, there is an intention to gray out toolbars and status bars in 
> inactive window, and an intention not to gray out controls in the body of a 
> window. At a high level, doesn’t that describe the things that you’ve been 
> seeing?

___

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: inconsistencies in view renderings

2016-10-19 Thread Quincey Morris
On Oct 19, 2016, at 17:34 , Alan Snyder  wrote:
> 
> Do you have a test of a textured button in a textured window that does not 
> gray out when inactive? (I’m ignoring the fact that textured buttons are not 
> supposed to be used in the content area.)
> 
> I have also noticed that if I add a template icon to the textured button, 
> then the text and the icon both gray out, even in a non-textured window.
> 
> However, if I use a textured segmented control with a label and a template 
> icon, the label grays out but the icon does not.
> 
> Perhaps the intent is to gray out all textured buttons in inactive windows 
> but the support is buggy?

I think the behavior is tailored (for each macOS version, so it’s not set in 
stone) to meet the human interface guidelines, not so much for absolute 
consistency in all possible scenarios. I don’t believe that textured windows 
are recommended any more (they’re not even mentioned in the current HIG 
document, that i can see), the question of what the buttons do is moot — or 
perhaps retains a behavior defined in earlier versions. Ditto for different 
button configurations, such as the ones with images. Segmented controls have 
always been weirdly different in appearance from buttons, for much the same 
reasons.

If I’m starting a new UI design from scratch, I generally go through the HIG 
and choose my layout, styles and behaviors from amongst those explicitly 
discussed, and avoid those on which nothing is said. That way, at least, if 
there’s some behavior that doesn’t follow the HIG rules, I can submit a bug 
report.

So, clearly, there is an intention to gray out toolbars and status bars in 
inactive window, and an intention not to gray out controls in the body of a 
window. At a high level, doesn’t that describe the things that you’ve been 
seeing?

___

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: inconsistencies in view renderings

2016-10-19 Thread Alan Snyder
My goal is understanding, and I'm not quite there yet.

I tried changing my program to use a textured window, and the textured buttons 
now gray out when the window is inactive.

However, the buttons are not in the toolbar or a bottom margin. At least I 
don’t think they are in a bottom margin, unless the entire window excluding the 
toolbar is a bottom margin. The buttons are within a box with a fill color.

Do you have a test of a textured button in a textured window that does not gray 
out when inactive? (I’m ignoring the fact that textured buttons are not 
supposed to be used in the content area.)

I have also noticed that if I add a template icon to the textured button, then 
the text and the icon both gray out, even in a non-textured window.

However, if I use a textured segmented control with a label and a template 
icon, the label grays out but the icon does not.

Perhaps the intent is to gray out all textured buttons in inactive windows but 
the support is buggy?

  Alan





> On Oct 18, 2016, at 8:53 PM, Quincey Morris 
>  wrote:
> 
> On Oct 18, 2016, at 19:43 , Alan Snyder  > wrote:
>> 
>> Well, try this on Sierra:
>> 
>> Use the Open File… menu item of Safari to open a dialog. Then activate a 
>> different application. On my system, the Cancel button in the dialog grays 
>> out (although it still looks different than the disabled Open button). Now 
>> click the Cancel button. Even though the button is grayed out, on my system 
>> the dialog is dismissed.
> 
> Yup, that works as you say. Guess why? (You won’t like the answer.)
> 
> The buttons change appearance when they’re in a window margin at the bottom 
> of an inactive window (and, I would expect, when they’re in a toolbar at the 
> top). If they’re in the body of the window, they don’t change.
> 
> I’ve lost track of what the point is here. Apparently there is no 
> programmatic way to control to inactive appearance, and 
> “acceptsFirstResponder” only affects the inactive behavior. Is there 
> something you were trying to do that you couldn’t, or was it only about 
> explaining the apparent inconsistency?
> 

___

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: inconsistencies in view renderings

2016-10-18 Thread Quincey Morris
On Oct 18, 2016, at 19:43 , Alan Snyder  wrote:
> 
> Well, try this on Sierra:
> 
> Use the Open File… menu item of Safari to open a dialog. Then activate a 
> different application. On my system, the Cancel button in the dialog grays 
> out (although it still looks different than the disabled Open button). Now 
> click the Cancel button. Even though the button is grayed out, on my system 
> the dialog is dismissed.

Yup, that works as you say. Guess why? (You won’t like the answer.)

The buttons change appearance when they’re in a window margin at the bottom of 
an inactive window (and, I would expect, when they’re in a toolbar at the top). 
If they’re in the body of the window, they don’t change.

I’ve lost track of what the point is here. Apparently there is no programmatic 
way to control to inactive appearance, and “acceptsFirstResponder” only affects 
the inactive behavior. Is there something you were trying to do that you 
couldn’t, or was it only about explaining the apparent inconsistency?

___

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: inconsistencies in view renderings

2016-10-18 Thread Alan Snyder
That sounds rather mysterious. What kind of project configuration would affect 
the display of buttons?

Well, try this on Sierra:

Use the Open File… menu item of Safari to open a dialog. Then activate a 
different application. On my system, the Cancel button in the dialog grays out 
(although it still looks different than the disabled Open button). Now click 
the Cancel button. Even though the button is grayed out, on my system the 
dialog is dismissed.

(I believe Cancel and Open are textured buttons on Sierra, as clicking them 
flashes gray, not blue.)


> On Oct 18, 2016, at 6:07 PM, Quincey Morris 
>  wrote:
> 
> If you are seeing a difference, something else is going one, such as a slight 
> configuration difference in my test project.

___

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: inconsistencies in view renderings

2016-10-18 Thread Quincey Morris
On Oct 18, 2016, at 17:58 , Alan Snyder  wrote:
> 
> Sounds like you were not using textured rounded buttons, which are the ones 
> that I wrote about.

I tried one of those and one regular button, and the textured rounded didn’t 
seem to change at all. Note that IIRC you’d normally use textured rounded in a 
tool or status bar, and the bar background changes color when the window goes 
inactive, but I can’t see any difference in the button itself. And there was no 
visible difference in the IB window, where it was stuck in the middle of a view.

If you are seeing a difference, something else is going one, such as a slight 
configuration difference in my test project.
___

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: inconsistencies in view renderings

2016-10-18 Thread Alan Snyder
Sounds like you were not using textured rounded buttons, which are the ones 
that I wrote about.



> On Oct 18, 2016, at 1:00 PM, Quincey Morris 
>  wrote:
> 
> On Oct 18, 2016, at 12:17 , Alan Snyder  > wrote:
>> 
>> The implication is that AppKit is probing the application at unspecified 
>> times with a fake event?
> 
> Well, I had to try it in a test project. I don’t see *any* difference in 
> appearance in the buttons, with acceptsFirstResponder YES or NO, regardless 
> of window state, regardless of IB canvas or running application, *except* 
> that colored highlights (the blue indicating a default button, or the blue 
> menu indicator on a popup button) change to gray in an inactive window.
> 
> This is with macOS Sierra. It’s possible that earlier iterations of the OS X 
> UI did have an inactive appearance for buttons, and my feeble recollection is 
> that this was so for a while in the 10.6-10.8 era, at least.
> 
> Perhaps what I did at the time was disable the button when the window went 
> inactive.
> 
>> Nothing in the documentation of acceptsFirstMouse suggests such a thing.
> 
> Well, the event parameter is allowed to be nil (and AppKit headers have been 
> audited for nullability, so it’s not likely to be an oversight).
> 

___

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: inconsistencies in view renderings

2016-10-18 Thread Quincey Morris
On Oct 18, 2016, at 12:17 , Alan Snyder  wrote:
> 
> The implication is that AppKit is probing the application at unspecified 
> times with a fake event?

Well, I had to try it in a test project. I don’t see *any* difference in 
appearance in the buttons, with acceptsFirstResponder YES or NO, regardless of 
window state, regardless of IB canvas or running application, *except* that 
colored highlights (the blue indicating a default button, or the blue menu 
indicator on a popup button) change to gray in an inactive window.

This is with macOS Sierra. It’s possible that earlier iterations of the OS X UI 
did have an inactive appearance for buttons, and my feeble recollection is that 
this was so for a while in the 10.6-10.8 era, at least.

Perhaps what I did at the time was disable the button when the window went 
inactive.

> Nothing in the documentation of acceptsFirstMouse suggests such a thing.

Well, the event parameter is allowed to be nil (and AppKit headers have been 
audited for nullability, so it’s not likely to be an oversight).

___

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: inconsistencies in view renderings

2016-10-18 Thread Alan Snyder
I was afraid you would say that…

The implication is that AppKit is probing the application at unspecified times 
with a fake event? Nothing in the documentation of acceptsFirstMouse suggests 
such a thing.

I have not found any other API so far.

  Alan



> On Oct 18, 2016, at 9:51 AM, Quincey Morris 
>  wrote:
> 
> On Oct 18, 2016, at 08:00 , Alan Snyder  wrote:
>> 
>> Is the choice to gray or not to gray when inactive under programmer control?
> 
> IIRC you can control this by the the value of “acceptsFirstMouse”. The NSView 
> default is NO, but NSButton overrides it to return YES. To change it back 
> again, you need to subclass NSButton and override the method. (But it’s a 
> while since I’ve had to deal with this, and there may be other API for 
> directly controlling the appearance.)
> 
> 


___

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: inconsistencies in view renderings

2016-10-18 Thread Quincey Morris
On Oct 18, 2016, at 08:00 , Alan Snyder  wrote:
> 
> Is the choice to gray or not to gray when inactive under programmer control?

IIRC you can control this by the the value of “acceptsFirstMouse”. The NSView 
default is NO, but NSButton overrides it to return YES. To change it back 
again, you need to subclass NSButton and override the method. (But it’s a while 
since I’ve had to deal with this, and there may be other API for directly 
controlling the appearance.)



___

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: inconsistencies in view renderings

2016-10-18 Thread Alan Snyder
Is the choice to gray or not to gray when inactive under programmer control?


> On Oct 18, 2016, at 12:08 AM, Quincey Morris 
>  wrote:
> 
> Keep in mind that buttons have *two* kinds of graying these days. One 
> indicates that the button is disabled. The other indicates that the button is 
> in an inactive window and does not accept mouse clicks until the window has 
> first been made active (thus preventing an inadvertent click on a non-front 
> window’s controls).
> 
> Typically, buttons in inactive windows *do* accept mouse clicks, and retain 
> their ungrayed appearance, which is why the appearance doesn’t change when 
> one of your windows is inactive.

___

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: inconsistencies in view renderings

2016-10-18 Thread Quincey Morris
On Oct 17, 2016, at 21:16 , Alan Snyder  wrote:
> 
> In IB, when the IB window is inactive, the buttons display in a grayed out 
> fashion. In the actual application, when the application window is inactive, 
> the button displays do not change.
> 
> What might be causing this difference in rendering?

Keep in mind that buttons have *two* kinds of graying these days. One indicates 
that the button is disabled. The other indicates that the button is in an 
inactive window and does not accept mouse clicks until the window has first 
been made active (thus preventing an inadvertent click on a non-front window’s 
controls).

Typically, buttons in inactive windows *do* accept mouse clicks, and retain 
their ungrayed appearance, which is why the appearance doesn’t change when one 
of your windows is inactive. Buttons in IB are really just graphic elements 
(clicking them selects them rather than performing an IBAction), so IB gets to 
draw them in inactive windows however it wants. Perhaps it’s intentionally 
indicating there’s no click-through behavior in this case, or perhaps it’s just 
a quirk of IB that it draws things grayed out.

___

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

inconsistencies in view renderings

2016-10-17 Thread Alan Snyder
I am not an expert on Interface Builder, so I hope to learn something about how 
IB simulates the display of views or how IB defined views are constructed at 
run time.

I have a UI that includes textured rounded buttons with text labels. In IB, 
when the IB window is inactive, the buttons display in a grayed out fashion. In 
the actual application, when the application window is inactive, the button 
displays do not change.

What might be causing this difference in rendering?

  Alan


___

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