Disabled controls are visually too light. #1788

Closed
BlairDuncan opened this Issue Feb 21, 2013 · 24 comments

Comments

Projects
None yet
7 participants
Contributor

BlairDuncan commented Feb 21, 2013

And combined with the type not changing to grey, they look odd and almost disappear.
Attached are screen caps of disabled buttons and radios vs their appearance in cocoa.
Screen shot 2013-02-21 at 9 57 25 AM
Screen shot 2013-02-21 at 9 56 53 AM
Screen shot 2013-02-21 at 10 08 36 AM

cappbot commented Feb 21, 2013

Milestone: Someday. Label: #new. What's next? A reviewer should examine this issue.

Owner

aljungberg commented Feb 21, 2013

That does look very light.

Contributor

aparajita commented Feb 21, 2013

#accepted

cappbot commented Feb 21, 2013

Milestone: Someday. Label: #accepted. What's next? A reviewer should examine this issue.

Contributor

aparajita commented Feb 21, 2013

#need-patch

Contributor

ahankinson commented Mar 26, 2013

So after a fair amount of digging, I've discovered the problem. It seems that the disabled controls are rendered with an opacity of 0.35 which, when combined with the disabled image, makes the control too light.

So, there are two options:

  1. Create lighter disabled images and render them at an opacity of 1, or,
  2. Duplicate the regular images and render them at an opacity of 0.35.

Any preferences, one way or another?

Edit: I think option 1 looks better. On the left is a regular checkbox set at 0.5 opacity; on the right is a PNG of a 68% transparent control rendered at full CSS opacity. You should ignore the text.

disabled_checkbox_test

Contributor

aparajita commented Mar 26, 2013

I don't think opacity is the correct way to handle dimming. It should be straight disabled images with opacity of 1.0.

Owner

aljungberg commented Mar 26, 2013

That depends though - if we could use the original images with a decreased opacity (specified in the theme), we would save quite a bit of download size. Of course this choice would have to be up to theme.

Contributor

ahankinson commented Mar 26, 2013

I think I might agree with @aljungberg. It also gives us quite a bit more flexibility with the theming.

If we decide that the controls are still too light, it's a simple change in the CSS to fix it rather than re-generating new images.

Contributor

ahankinson commented Mar 26, 2013

If we make a decision either way, though, I will implement it.

assignee=ahankinson

Contributor

aparajita commented Mar 26, 2013

Interesting...I just checked a disabled control against a colored background in Cocoa, and it actually does use opacity -- the color bleeds through. So opacity actually is correct and I was wrong.

We already have disabled images for most controls. If we are going to use opacity for disabling, we can eliminate them and specify the opacity in the theme.

Contributor

ahankinson commented Mar 26, 2013

Ok, so if I understand correctly I will create a PR that does the following:

-- Remove the "-disabled.png" images;
-- Changes the theme description to use the "regular" images, but ensure that the controls disabled mask is set so that the disabled look is produced via CSS opacity.

I am planning on separating them into separate commits for each control type, just so I'm not committing one big chunk of code, in theory making it easier to review. Does this sound OK?

Contributor

aparajita commented Mar 26, 2013

-- Remove the "-disabled.png" images;
-- Changes the theme description to use the "regular" images, but ensure that the controls disabled mask is set so that the disabled look is produced via CSS opacity.

Sounds right. Let's see how it looks before committing it. We will probably have to play around with the opacity on a per-control basis.

Contributor

ahankinson commented Mar 26, 2013

Ok, I've started a PR (#1882) and will commit there. Please don't merge it just yet.

Member

mrcarlberg commented Mar 26, 2013

One question: If we are creating our own theme are we still able to use a .png image for disabled controls without any opacity change from the CSS?

Contributor

ahankinson commented Mar 26, 2013

Yes -- this just touches code in AppKit/Themes/Aristo2, so it doesn't touch anything else (e.g., nib2cib).

You will have to create your own disabled images, though, but I presume that since you're creating your own theme, that's not a big problem.

Member

mrcarlberg commented Mar 26, 2013

Ok, good!

You have my blessing.

Contributor

ahankinson commented Mar 26, 2013

Ok, so for popup buttons, pulldown buttons, etc. we have separate colours for the enabled/disabled states. Should we set the disabled state on the coloured button, or should we create a new disabled state at full opacity that removes the colour?

Contributor

aparajita commented Mar 26, 2013

Cocoa removes the color AND reduces opacity.

Owner

aljungberg commented Mar 26, 2013

You can bake the opacity into the image if that's more convenient. It probably is since you'll be slicing them from the PSD.

@ahankinson ahankinson added a commit to ahankinson/cappuccino that referenced this issue Mar 28, 2013

@ahankinson ahankinson Fixed: Change default disabled opacity
Previously some disabled controls would be set with an opacity of 0.35, which resulted in controls that were visually too light.

This commit changes the default disabled opacity to 0.5.

Refs #1788
4956218

aparajita closed this in #1882 May 21, 2013

Contributor

daboe01 commented Jun 26, 2013

the selection of a tableview is barely legible in the non-focussed state.

bildschirmfoto 2013-06-26 um 08 16 32

Contributor

BlairDuncan commented Jun 26, 2013

Yes, the background colour is correct but in cocoa the text changes back to black for selected non-focused tableview selections.

screen shot 2013-06-26 at 9 09 40 am

Contributor

daboe01 commented Jul 17, 2013

i guessed that inserting the following line into Aristo2's ThemeDescriptors.j could fix this:

    [@"text-color",         [CPColor blackColor],                CPThemeStateTableDataView | CPThemeStateSelectedDataView],

however, i did not figure out how to swich back to white text in focussed state selected rows. has this to be hard-coded into CPTableView.j? any suggestions?
many thanks and best greetings,
daniel

Owner

aljungberg commented May 12, 2014

The hard to read table view situation is now fixed by a4702d4 and f151920.

screen shot 2014-05-12 at 16 04 48
screen shot 2014-05-12 at 16 05 01

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment