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



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



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