Re: [Gimp-gui] How I modify gimp-2.99 to be more productive

[Jehan <jehan girinstud io>]

Hi!

On 4/25/22 01:04, Thomas Manni via gimp-gui-list wrote:
> Hi,
> since last summer, I occasionally make money as freelancer thanks to 
> my Gimp user skills.
> I create photo-montages for artisan builder either in the context of 
> obtaining building permit, or as a decision tool for their customers.
> Starting from a photo of the current existing place, I integrate 
> elements to visually match what the builder envisage to do.
> Depending of the complexity of the project, I use Gimp 2.99 alone or a 
> mixed of Gimp + Blender for modeling buildings.
>
> In each project, I create a lot of layers, layer masks and layer 
> groups via the buttons at the bottom of the layers dock.
> I also make a lot of temporary selections with selection tools.
> After spending hours behind the screen with deadlines in mind (often 
> from one day to the next), I have done several modifications to Gimp 
> 2.99 to accelerate my work when doing repetitive basic tasks.
>
> To reduce the time interacting with the "new layer" dialog, a click on 
> the new layer button automatically creates an empty layer with the 
> size of the canvas.
> The dialog is still accessible via menu Layer > New Layer... or by 
> shift-clicking the button.

Yes. This is a very hard topic.
We kind of agree too actually that it's better for efficiency of 
advanced users (who are anyway the prime target of GIMP) and more than 
once, we have hesitated to do just this.

As I understand, the main issues for current behavior was:

* Discoverability; but then it's a hard bargain because discoverability 
is basically a one-time thing (or a few-time thing) and once you know 
the feature exists and how to get it (by shift-click, i.e. reversing 
current logic), then you'd prefer the additional step gone.

* We are unsure how many are just so used to current workflow or maybe 
even prefer it and would be very unhappy to have the logic reversed. 
GIMP being used by millions or even dozens of millions of people, 
changing something as basic as the "new layer" dialog is not something 
you do lightly.

What I always thought of, as a possible way to handle these issues was 
to make the "New layer" dialog still appear as a default, but with a 
checkbox in there basically saying "Show this dialog only when 
shift-clicking the 'New layer' button". Basically a checkbox to invert 
the logic. This way, we keep the discoverability (always shown at first 
usage), until users decide current defaults are good enough and they 
just want to keep using these.

Also probably right-clicking on the "New Layer" icon should pop-up a 
small menu proposing the variant actions; because as much as the Shift 
modifier is obvious for people who always use GIMP, as much it can be 
forgotten when you use it less often, as all modifiers and all shortcuts 
are quite forgettable after enough time one non-usage. On the other 
hand, the contextual menu on secondary click is an action common to most 
software and so ingrained in computing these days that most people (at 
least the ones using computers regularly, but not necessary GIMP) know.

Why I never acted on this was because I wanted to discuss this first 
with a few of the artists surrounding GIMP, e.g. Aryeom who works with 
me, or Sevenix who is always on IRC, or patdavid of course, this mailing 
list too obviously, and so on. Basically gather more input. And maybe 
when we get an agreement to a good workflow (such as the one I propose, 
if others agree it's decent), even proposing a small poll on social 
networks would be worth it IMO (since, as I said, we are really touching 
a very core feature of the GUI: how layers are created!).

Note though that there are more UX work that I have been working on 
regarding layer creation. One of them is having modifiers to create new 
layers above (as currently) or alternatively below.
Then as I recall, there are also the questions of how to handle various 
cases of new layer positions when creating a layer when a layer group is 
selected (something we discussed a few times with Aryeom since she 
obviously work with a lot of layers). And so on.

My goal was to have a bigger discussion about the whole layer creation 
workflow and try to find the best UX choices and abilities. It also 
needs to be discussed as a "big picture" change, among other things for 
consistency. If we do such changes, it has to be done well.
For other similar features, I started to write behavior specs so that 
the whole code logic follows a real consistent logic not changes done 
randomly on one button then differently somewhere else.

> To reduce the time interacting with the "new layer mask" dialog, a 
> click on the new layer mask button automatically creates a layer mask:
> - from the selection if the selection is not empty
> - white otherwise
> The dialog is still accessible via menu Layer > Mask > Add layer 
> masks... or by shift-clicking the button.

Hmmm… as much as I agree for new layers, it feels that layer masks are 
less used so discoverability might be even more important, or even 
re-discoverability (since you might forget). Also layer initialization 
options are usually quite standard (most of the time, I think most 
people want transparent layers as default), but this is much less the 
case for layer mask. White or from selections are indeed pretty common 
usage, but I can definitely see cases where I want to create a white 
mask while having to delete my selection.

Also creating masks from channels is not unheard of at all. Many pros 
seem to use channels basically as a way to store complex selections they 
want to reuse for various things (such as for masks!).

Basically I think most initialization options make sense there and I 
feel having the dialog disappear would be more harmful for people with a 
diverse workflow.

This being said: if we add the checkbox thingy on "New Layer" dialog, we 
might as well do the same thing on "Add Layer Mask", if anything for 
consistency. Then it would make everyone happy and be consistent at least.
> A click on the "new layer group" button creates a group at the 
> position of the upper selected layer (in the layers hierarchy), and 
> all selected layers are moved inside the group.

Yes I believe this was requested by Aryeom to me and I never took the 
time yet to implement it. I will ask her again.

For this one, it is anyway much less controversial, first because 
multiple selection of layers is very new (so not in any stable release 
and we can't say people are used to this) and second because the current 
implementation (which might be considered a bit placeholder) is not the 
best default (creating as many layer groups as there are selected 
layers: I mean I'm sure it is a use case of someone, somewhere, but I'm 
pretty sure it's not the best default as a general rule for people who 
click the "Layer group" when having multiple layers selected).

> When only one layer is selected and its mask is in edition mode, a 
> click on the "delete selected layers" button deletes the layer mask.
This is quite a decent idea. To be discussed.
> When a copy-paste is done, the floating selection is automatically 
> transformed to a new layer.

Yes, the floating selection is a big topic and doing what you propose is 
what I was planning to implement before GIMP 3.0, but it cannot be an 
all-case implementation. There is actually one big usage of floating 
selection: when you paste on a layer mask. In this case, you need to be 
able to tweak your pasted data before merging it (consider the fact when 
the layer mask also has data already).

So the basic idea so far (this topic was discussed on this list) was 
that the "floating selection" concept would survive for this specific 
case (then maybe renamed "floating mask"?) allowing to tweak the paste, 
but for paste on layer cases, yes making new layers make sense.

See the discussion on this topic: 
https://mail.gnome.org/archives/gimp-gui-list/2020-December/msg00000.html

Then if the "floating mask" is the only surviving useful case of the old 
"floating selection", the small preview would need to be moved to the 
right, above the mask, which would make clear it applies to the mask, 
not the layer.

> To reduce the time spend to deselect, the selection is automatically 
> empty when
> - the selection is save to a channel
> - the selection is used to create a layer mask
> - the image or a layer is crop to the selection
> - the content of the selection is pasted as a new layer
I'm really not sure it's a good idea. Especially as what if you didn't 
want this (i.e. you wanted to save to a channel/mask/other while keeping 
your selection alive)? Then you can't undo only the "Selection None" 
because it was all done as a single atomic action, hence you would undo 
both the selection save/layer mask creation/crop/paste (which you 
wanted) and the selection removal (which you didn't want). So it's even 
quite a bad idea so far.

On the other hand:

* "Selection None" is one simple shortcut away which any advanced user 
will know (or have tweaked to their favorite shortcut). I don't think it 
can really be considered a huge time loss;

* If really you have a workflow where you *always* need to "Selection 
None" after these actions, then creating a script which do both actions 
at once is extra-simple, and then assign your shortcut to this new 
action rather than using the default action.

You could tell me that some people don't have the ability to script but 
the plan for GIMP 3.0 is to have a plug-in infrastructure where 
third-party developers will be able to publish their plug-ins and 
creators will be able to search and install these plug-ins from within 
GIMP itself (think similar to Firefox plug-ins). If something like this 
is really useful, then someone will make it and will publish it.

The second point is that some people don't like to use shortcuts and 
prefer to just click a button. But one of my goals is to have the GIMP 
GUI much more customizable. In particular I'd like to have a toolbar 
with customizable buttons (and ability to assign any action to a 
button). So people who have some action they really want to always have 
a handy button for will be able to have it. I don't expect this to 
happen for GIMP 3.0, but possibly GIMP 3.2 (or one intermediate micro 
release point).

> Also I have other modifications in my to-do list, like:
> - when removing the alpha channel of a layer, simply remove the alpha 
> channel without affecting the pixels colors.

What do you mean exactly? It looks like you are talking about the "Apply 
Layer Mask" action, but I guess it's not it (since it already exists). 
Or is it like transforming the RGB into the premultiplied values (with 
the respective mask value) while dropping the mask (keeping the layer 
alpha only)?

If there is a use case for this (I guess there is, if you want this; 
what is your use case, for information?), sure why not as an additional 
action. But it can't replace the current default action which is also 
definitely useful.

> - right-clicking on a layer mask will pop a dedicated menu for the 
> mask (apply the mask, delete, show, edit, disable, to selection).
> This will make the layer menu shorter and easier to navigate on. (Only 
> the Add layer masks will stay in the Layer menu).

Sure. More really-contextual menus are definitely good, for usability 
and discoverability. So yes a shorter and more mask-dedicated menu is 
definitely a good thing.

Clearly our current contextual menus are a bit shitty because they are 
really not contextual enough IMO.

> - add an option to apply transformation tools on a layer without 
> affecting its layer mask.

For this, what we want is to have the ability for layer masks to be 
independent from their layers: 
https://gitlab.gnome.org/GNOME/gimp/-/issues/31

This is something we often wanted and that I was planning for GIMP 3.2. 
Having the ability to also tie or crop the dimensions to the layer is 
still absolutely needed. Yet having the ability to not lose data because 
you move the mask, or — as you propose — move the layer without moving 
the mask (and again, not lose data which goes out of the layer bounds) 
is definitely a must-have too. And so on.

So yes, it's needed.

> Finally,  one thing I do a lot is to change the opacity of a layer 
> with the mouse, move the cursor to the canvas and tip a keyboard 
> shortcut (i.e to switch the active tool).
> Unfortunately, this does not work because the focus stays on the 
> opacity slider, which is very frustrating (I have to first tip Escape 
> every time).
> When the mouse cursor is on the canvas, keyboard shortcuts should 
> trigger the action related to the canvas in priority, wherever the 
> focus is.

Yeah that's a difficult topic. First because GTK is not made with these 
logic in mind and doesn't have a "switch" logic where we could ask GTK 
to just behave this way as a whole (some people requested this feature 
for years in GIMP, then went on asking GTK to have such a thing; believe 
me, they tried). This would be the nice, correct and simple way.

Now we could implement this, but it would require hacking each widget by 
connecting their "leave-notify-event" and "enter-notify-event" and 
acting accordingly to move focus here and there. It means a lot of work, 
necessarily bugs we would discover and have to fix, for years and years 
to come (so more maintenance work, I predict it) and we would 
necessarily forget one usage here or there, so we'd have to fix the 
thing all the time for the years  to come.

Of course maybe we could do it more easily if we never used pure GTK 
widgets, but only GIMP custom widgets. But that's also still a lot of 
work (a different way).

Last thing, but not least, not everyone likes this focus-hover logic. 
There are definitely people who crave this (especially in Linux world) 
and there are desktops out there who base their whole focus logic on 
this on-hover event, but many don't. And I can't say for sure that the 
focus-hover people are the most. I know that personally I like to get my 
cursor out of the way when I write things down (so I could click the 
cursor in the opacity widget then I could want to move the cursor out of 
the widget, yet I would certainly not like that I lose focus doing this).

Of course, then it can be an option, but once again, it means 2 code 
paths and a lot more maintenance.

Anyway the canvas focus thing is a big topic, it has been for years, and 
it is not easy at all. I was also one of the people who tried to improve 
things. For instance many years ago, I made so that toolbox buttons 
don't take the focus at all, so they don't steal the focus from the 
canvas. Much more recently, I even went further: I made so that the 
whole toolbox actively gives the focus to the canvas (so the toolbox now 
work like `Esc`). This is quite easy here for just buttons. This is a 
whole other deal for any widget in general and widgets accepting 
keyboard input in particular such as these sliders.

> That said, I simply wanted to share with the community a feedback in a 
> professional context where productivity matter and how changes can be 
> done to improve the end-user experience.
Sure. We also use GIMP in a professional context, so we definitely agree 
that it helps. And we definitely welcome your own experience there. :-)
> I think these changes could benefit to any user's workflow and could 
> be integrated to the master branch since Gimp 3.0 is the opportunity 
> for changes.

Note one thing: I have been trying to limit things we include in GIMP 
for the 3.0 release lately, even severely blocking our own wishes, and 
pushing them to 3.2. If we don't do this and constantly add new stuff, 
GIMP 3.0 will never be out.

So now I'd like to only accept stuff which really really matter a lot or 
which are so total crap in current interface that even unfinished logic 
is better than current logic; or new features which are basically in a 
finished state (and even then, the review takes time so something 
finished but huge might not be reviewed in time for GIMP 3.0.0). In 
particular I don't want to accept anymore in the 3.0 branch anything 
which is unfinished at contribution time. I.e. we start implementing 
something, then if you disappear for a while (which is perfectly fine, 
any contributor has the right to do whatever they want!), we are stuck 
finishing it so it delays GIMP 3.0 release that much (possibly weeks or 
months).

Now it absolutely doesn't mean it can't get in GIMP soon after. Even 
when I say I pushed some of my stuff to 3.2, actually it can as well be 
any of the coming micro release (3.0.2, 3.0.4, etc.) as I remind that 
since GIMP 2.10, we allow new features in micro releases.

GIMP 3.0 is an opportunity for change, but GUI is less of a blocked 
interface than say the API (which here must absolutely stay stable). So 
some of the proposed features can appear soon after if implementation is 
not finished yet. :-)

Anyway we can discuss some of your propositions more in details here, 
then feel very free to propose your patches when we get to a point we 
all agree and that it's basically in finished or at least usable state 
(modulo the yet unknown bugs which can happen, of course). :-)

Jehan

> Regards,
> Thomas Manni
>
> _______________________________________________
> gimp-gui-list mailing list
> gimp-gui-list gnome org
> https://mail.gnome.org/mailman/listinfo/gimp-gui-list

--
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay:https://liberapay.com/ZeMarmot/
Patreon:https://patreon.com/zemarmot
Tipeee:https://www.tipeee.com/zemarmot