Re: [Gimp-gui] gimp-gui-list Digest, Vol 3, Issue 8

[Jehan <jehan girinstud io>]

Hi,

On 2015-12-15 13:51, Joseph Bupe wrote:
> > There are too many things to tell when creating a new layer and and
> > an
> > important one is missing....
> >
> > In my experience with Gimp, I haven't got that many use cases:
> >
> > - Fill: layer is either transparent, or filled with the background
> > color
> > - Size: layer is image sized, or the same size as the current layer
> > - Position (missing in current dialog): layer is at 0,0 (image
> > sized) or
> > overlaps current layer
> >
> > IMHO: asking for a size in the layer dialog is pointless, because
> > usually you cannot tell the size in pixels in advance (and when you
> > can
> > you also have a position in mind...). In real life you create an
> > image-sized layer and crop it later using its contents as a
> > reference.
> >
> > If we can skip the dialog then we have shortcuts for instant layer
> > creation, especially for the three most used:
> >
> > * image-sized filled with background color
> > * image-sized and transparent
> > * copy of the active layer, transparent
> >
> > You can always fill/crop/name the layer afterwards so no
> > functionality
> > is lost.
> >
> > A penny for your thoughts
>
> Possibly related to the topic on the following link:
>
> https://mail.gnome.org/archives/gimp-developer-list/2015-March/msg00075.html
> [1]

That's definitely the same topic. Actually I agree with most of what 
people says, even when they say the opposite of each others! :-)

The facts are this:

1/ I agree that at some point, someone has a workflow where you end up 
always making only 1 or at most 2 kinds of new layers.

2/ The first problem is that they are often not the same, as we can read 
in this thread of the one linked above. I, for one, nearly only use 
transparent layers. I read several people in the above thread, one who 
said mostly using white layers only, another mostly using either white 
layers or the foreground color, and the first email of this new thread 
says mostly using background or transparent.
We ended up in just a few emails showing how diverse the user base and 
habits are, and that all 4 fill types are used. Simply everyone just 
ends up always using the same fill type (cf 1/).

Because of this problem, we can't just decide to create actions or 
buttons for specific combinations because of this point 2/. Because what 
is your usual fill type is not your neighbour's. Or we should create 4 
new buttons/actions, and then the UI will end up at some point cluttered 
with hundreds of buttons.

There were propositions of inverting the click and shift-click (click 
would create directly a layer of your last type and shift-click open the 
dialog), like in the linked dialog. As an advanced user (well, more than 
many, but much less than many others too), I would not mind and actually 
would find it better for my workflow. Simon Budig explained that it was 
actually done this way for a while, since the shift-click is not easily 
discoverable: 
https://mail.gnome.org/archives/gimp-developer-list/2015-March/msg00100.html

As a consequence, we could say that for many users, the capacity to 
create new layers of different fills became more complicated. Of course, 
you can always add/remove an alpha channel afterwards and fill the whole 
layer with some color, but this is a little usability loss to being able 
to do it at layer creation.

It makes sense that the most discoverable UI should be the one to do the 
more, and later users learn progressively optimized UI logics to improve 
their workflow. For all theses reasons, the *default* UI seems 
acceptable.

For me, that's actually a good example of a need to be able to tweak the 
UI with plugins, which is not possible right now. That's something I'd 
like to implement (or see implemented) at some point. Our plugin API 
should allow people to have optimized UI, like for instance remapping 
the new layer button to create in one click a layer of your preferred 
fill type.
But the default UI should be a discoverable one.

Jehan