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
_______________________________________________
gimp-gui-list mailing list
gimp-gui-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-gui-list
