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.
Milestone: Someday. Label: #new. What's next? A reviewer should examine this issue.
That does look very light.
Milestone: Someday. Label: #accepted. What's next? A reviewer should examine this issue.
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:
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.
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.
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.
If we make a decision either way, though, I will implement it.
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?
Ok, I've started a PR (#1882) and will commit there. Please don't merge it just yet.
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?
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.
You have my blessing.
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?
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.
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.
the selection of a tableview is barely legible in the non-focussed state.
Yes, the background colour is correct but in cocoa the text changes back to black for selected non-focused tableview selections.
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,
The hard to read table view situation is now fixed by a4702d4 and f151920.