El jue, 30-04-2015 a las 17:40 -0400, Elle Stone escribió:
> On 04/29/2015 03:57 PM, Joao S. O. Bueno wrote:
> > Now help us think on the next steps. For example get that e-mail
> > worked into a feasible specification: If you can, refine it, then
> > maybe try to get someone with UI expertise that could fine tune that
> > your suggestions into specifications that could be really great - now
> > we don't have Peter helping the project anymore.
> > (could be someone from your area, to whom you could get face to face
> > meetings)
> - (I'd rather have another switch along the layer modes than
> > to duplicate all layer modes in the UI, for example) -
> This link has three screenshots illustrating a proposed UI for allowing
> the user to easily choose between linear and perceptually uniform RGB
> and to know at a glance whether s/he's using the default set by the
> Is what's shown in the screenshots feasible in terms of linking the
> operations to the proposed UI?
You know I'm with you regarding giving users more control over how
operations are performed, but tossing buttons for toggling between
linear and perceptual everywhere in the UI is not a proper solution.
It would be extremely confusing, and people would start toggling them
randomly without knowing what exactly they are for, and only a few
people would benefit from it.
I think that allowing that would complicate the UI and the the tools
themselves, as all of them should have both paths available.
A better solution would probably have to wait until proper
no-destructive editing is finally implemented, and operations are
visualized as a stack/chain/whatever.
I mean, instead of putting toggles on EVERYTHING, why not adding a tool
that says "from this point, the following operation/s will be performed
in linear/perceptual gamma"?
People used to node-based UIs will understand exactly what I mean.
The difference would be that only users who need the toggle will add an
operation that makes the switch when it's required. The UI will remain
lean, without extra options that could potentially confuse less advanced
gimp-developer-list mailing list
List address: email@example.com
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list