On Sat, May 2, 2015 at 3:12 PM, Elle Stone
> On 05/02/2015 02:44 PM, Øyvind Kolås wrote:
>> On Sat, May 2, 2015 at 9:45 AM, Elle Stone
>> <ellest...@ninedegreesbelow.com> wrote:
>>> To be more blunt, the babl flips are Pippin's brain-child. If Pippin says
>>> "no user choice", is there any real benefit to anyone if I write up a
>>> Wouldn't it just be a waste of everyone's time?
>> I have not stated *no*user*choice*, but I have stated that good ways
>> to let the user override these choices seem to be more along the lines
>> of what Gez is proposing, explicit conversions to and from other
>> working spaces / linearity / unpremultiplication. Let it be a separate
>> manual step to override sane defaults where sane defaults helps the
>> vast majority of uses by both operators of the software unaware of
>> these nuances as well as color management experts. This can be done as
>> separate actions without having additional, possibly confusing,
>> buttons in the UI.
> I'm not entirely sure what you are proposing or how it could be implemented
> in the UI. Is this what you mean?
> 1. Make a list of all RGB editing operations that are provided by GIMP.
> 2. Decide for each operation whether it should be done using linear or
> perceptual RGB and set that as the default way the operation will be done.
> 3. Figure out which RGB operations "legitimately" should also be allowed to
> be done using the opposite choice from what the developers decided.
> 4. For the operations for which users can choose other than the default, do
> what? I can think of two possibilities:
> i. Make an entirely new RGB editing operation. For example
> Curves-linear and Curves-perceptual, Gradient-linear and
> Gradient-perceptual, Soft-light-blend-linear and
> Soft-light-blend-perceptual, and so forth. Then stuff these new editing
> operations into the menu.
> ii. Put an override button on the UI for the particular layer blend
> mode or tools/operation UI. But you said specifically said you don't want to
> put additional, possibly confusing buttons in the UI.
> Is above close to what you are envisioning?
Nope, I envison the operator of GIMP to do a *separate* action before
a particular action to override the default/sane pixelformat for, and
then a *separate* action afterwards. For some particular operations
more direct ways of achieving it can be provided if it is common
tasks; like for instance adding the ability to do curves/levels in CIE
Lab instead of RGB; but in general the sledge hammer to offer the
operator this ability is additional actions.
> Sometimes babl/GEGL/GIMP developers say things that make me think that some
> of the devs think GIMP users as a whole are not very bright people.
Even though humans and other primates that glow in the dark are part
of our intended user base, too bright people might have problems - in
particular if their screens are reflective. Designing user interfaces
is tricky; and often it helps to try to make them work well also for
drunk or otherwise impaired operators; if they work well for that –
the tools should work even better for fully present and competent
gimp-developer-list mailing list
List address: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list