Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

El sáb, 02-05-2015 a las 11:18 -0400, Robert Krawitz escribió:
On Sat, 02 May 2015 11:21:37 -0300, Gez wrote:
El sáb, 02-05-2015 a las 06:09 -0400, Elle Stone escribió:
I'd like to see this discussion heading towards a real world list of
examples of real needs for such options that can't be satisfied with
anything else than these toggles.

You are presupposing that the devs can foresee every possible use to 
which a user might put a given editing operation.

No, I'm saying that users like us should describe real world situations
where certain options are needed in order to convince developers of the
necessity of such options.
"Let me do whatever I want" is not a good argument.

Yes it is, because we don't know every possible use to which someone
will put something.

We've had the same issue come up in Gutenprint.  Gutenprint exposes
just about every internal control option to users, if they want to
play with them.  It allows things that could actually cause _physical_
damage to printers, in particular specifying ink limits so high that
they would completely soak through non-coated paper and would form
large puddles on coated papers that could gum up the print head.

But then it turned out that people wanted to do things with printers
that we had never envisioned: printing T-shirts, and doing chemical
deposition (in one case, literally printing circuits onto paper using
electroconductive inks).  It turned out to be very fortunate for those
users that we had never imposed limits of that kind because "that
isn't something anybody should be doing".

The one concession that we did make was to group options into
different levels of interface complexity, and add an option to the PPD
file generator to generate simplified PPD files with only the basic
options.  But the default is to use the full-featured interface.

Obviously there are resource constraints here; developers can only do
so much, and have to make decisions about what to do that are mutually
exclusive on time constraints alone.  But deliberately leaving
something out of this kind of project because there isn't an obvious
real world use case is not, in my view, a good thing.

Let me clarify that I'm not against flexibility or giving users control
on the processes.
It's not about choosing between no control and full control. Is finding
a balance where a UI provides the necessary tools for the regular job
without hindering the possibility of experimentation.
It's extremely difficult to create a UI that both exposes every possible
user and provides a fast and comfortable workflow.
Adding checkboxes and buttons for every need doesn't solve the issue.
Pretending that you can separate the "basic" and the "advanced" users in
two simple groups by providing insufficient tools for basic users and
the cluttered UI for advanced ones is not going to result in a good
Nodal UIs aren't perfect, but provide a good balance because every tool
is an individual node, and power and flexibility come from combining
those nodes.
In this case of linear vs. perceptual, a gamma node would allow to turn
every operation in a linear workflow into perceptual.
Notice how different is the paradigm: a single tool that changes how
other tools act instead of adding an extra option to every single tool.
And a tool that is added on demand, only people who want to use it will
be exposed to it, and the rest wouldn't be disturbed by a cluttered
Unfortunately, the UI paradigm in GIMP and similar applications makes
this really difficult, because it's inherited from a time where all the
operations were sequential and destructive.
Again legacy stopping progress.

Part of this is a UI problem, and adding buttons or checkboxes for every
possible alternative isn't a good way to design UIs.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]