display adjustment
Jon, sorry to be picking on you again :) but I have comments on the new command you added to View":
- "display adjustment" is too generic. It may mean a lot of things. The statusbar tip explains it, but why not rename the command itself to something like "display color management" or "display CMS" etc.
- if it's a toggle, it must be presented as a toggle and have a check mark against the command name in the menu.
- if you cannot yet disable the command on displays where it does nothing, you must at least provide some feedback when the command is invoked - the statusbar must flash one of "display cms mode turned on", "display cms mode turned off," or "cms mode is not supported by this display."
- what about windows? mac? if it never works on windows, please make it compiling conditionally, and mention that it's X-only in the release notes.
On Nov 30, 2007, at 2:15 PM, bulia byak wrote:
- "display adjustment" is too generic. It may mean a lot of things.
The statusbar tip explains it, but why not rename the command itself to something like "display color management" or "display CMS" etc.
Certainly. The prior text was just quick placeholder stuff while I added the functionality itself.
- if it's a toggle, it must be presented as a toggle and have a check
mark against the command name in the menu.
It's a toggle like the grid and guides are. However, all the other places we have toggle actions as main menu items we don't use check marks.
- if you cannot yet disable the command on displays where it does
nothing, you must at least provide some feedback when the command is invoked - the statusbar must flash one of "display cms mode turned on", "display cms mode turned off," or "cms mode is not supported by this display."
Dynamic disabling is now in (it was planned, just not completed). I think there are a few cases where things get out of sync, but the menu item (and verb) are consistent with the state of the toggle button.
- what about windows? mac? if it never works on windows, please make
it compiling conditionally, and mention that it's X-only in the release notes.
At the moment all except the per-monitor dynamic display profile fetching should be cross-platform. That dynamic stuff is XICC and is X11-specific. The code in there already has #ifdefs to only enable the X11 specific stuff when appropriate. Also our current support mac builds are all X11 based (native OS X version of GTK is not quite stable yet).
For Win32, we should be able to use native win23 calls in place of XICC. I was planning to check that this next week. If that code ends up not working, there's only one visible place in the UI (one preference) that would need to be disabled for Windows.
For native OSX GTK I know the calls and code needed, but I'm not planning on putting any of it in yet. I won't even start that part until after I'm able to get my own native GTK+ build going. I've tried the last couple of days, but it wasn't working so has moved down on my list of priorities.
On Dec 2, 2007 4:44 AM, Jon A. Cruz <jon@...18...> wrote:
- if it's a toggle, it must be presented as a toggle and have a check
mark against the command name in the menu.
It's a toggle like the grid and guides are. However, all the other places we have toggle actions as main menu items we don't use check marks.
I think all three must be made checkmarks. I think this wasn't done before out of pure lazyness :)
Dynamic disabling is now in (it was planned, just not completed). I think there are a few cases where things get out of sync, but the menu item (and verb) are consistent with the state of the toggle button.
That is cool, but statusbar diagnostic should still be added if not yet.
Thanks!
On Dec 2, 2007, at 10:26 AM, bulia byak wrote:
It's a toggle like the grid and guides are. However, all the other places we have toggle actions as main menu items we don't use check marks.
I think all three must be made checkmarks. I think this wasn't done before out of pure lazyness :)
Well... I was thinking more that it was an issue of one needing to choose between a checkmark and an icon, and choosing the icon.
We probably could look into the toolkit limitations more, but I personally like the icons. On the other hand, I've seen people discussing UI's who dislike more than a bare minimum of icons. I think to them the presence of an icon is the visual clue, and not the shape of the icon itself. Whatever the case, this seems like one of those tricky UI cases. But you seem good with those, so I've tried to lay out the factors I see for this issue.
Dynamic disabling is now in (it was planned, just not completed). I think there are a few cases where things get out of sync, but the menu item (and verb) are consistent with the state of the toggle button.
That is cool, but statusbar diagnostic should still be added if not yet.
At the moment the menu item gets disabled, so there is no statusbar message set. That is, once the menu item becomes disabled, the status bar is not affected by it.
Now *if* LCMS is not enabled, profile changes can't work. However in that case the "Color Management" pane in preferences has things disabled and a message explaining why is added.
If you or anyone else have suggestions about how we could present some message, I would love to hear it. About all I can think of at the moment is a warning dialog with a "don't show me this warning again" option.
On Dec 1, 2007 1:15 AM, bulia byak wrote:
Jon, sorry to be picking on you again :) but I have comments on the new command you added to View":
- "display adjustment" is too generic. It may mean a lot of things.
I actually owe Jon a patch to fix color management related terminology :)
One thing I would add is that just enabling color management is not enough. I'd love to see commands to enable/disable softproof and, optionally, mark color out of gamut available from View menu..
Alexandre
participants (3)
-
Alexandre Prokoudine -
bulia byak -
Jon A. Cruz