The mouse controller had many limitations:
* It was not per-device.
* It was a long hard-coded list of events, which made its evolution
annoying and scrolling the list boring.
* It was starting at button 8, while the first buttons were supposed to
be hardcoded interactions. And it stopped at button 12, while some
device might have more buttons nowadays. See !386.
* The "Grab event" does not seem to work in many cases, according to
feedbacks.
The new GimpModifiersEditor will now handle any button (except the first
button, which is reserved for tools), you can even override or change
default canvas actions (panning, rotation, etc.). It should not be
limited with a max button number either (though I haven't tested with a
device really having a lot of buttons since I don't have any such device
but I did emulate huge button numbers on my stylus with xsetwacom and it
did work well; hopefully I'll get feedbacks). And now it can even run
custom actions.
So basically it should deprecate the mouse controller as the modifiers
editor can do everything the controller could, and more (unless I missed
anything).
Custom actions are basically any action (currently GtkAction) which can
be assigned a shortcut. Now they can also be assigned to an input device
button (with modifier or not).
There is really no need to make back and forth between a string and
int/enum representations, and it actually cause problems at times.
It's also a problem for the button representation where a modifier will
be represented as a key.
When no accelerator was set yet, display relevant information, and when
the button is toggled (waiting for shortcut input), display also
relevant info.
A widget to grab a shortcut provided interactively. It can also grab
modifier-only shortcuts so we will be able to use it for the new
on-canvas interaction customizability.
Maybe we'll use this later for the shortcuts dialog which should really
be improved some day and has a lot of known issues. We'll see.
Moving the "Space Bar", the "Snapping" and the new "Zoom" (MR !570)
settings there. The idea is that it will also be where we'll customize
more on-canvas related abilities, such as the new zooming behavior
preferences, but also possibility to customizing or disabling the
various canvas action, and finally customizing the new contextual
settings such as brush sizing or other.
These actions can be activated with a double value. These will be useful
to create new types of size action, which are based on accurate pixel
values instead of an enum hacked to set per-mille values between a
min/max.
Uses the simulation rendering intent from GimpImage instead of
from GimpColorConfig. This affects the SamplePoint and Pointer dialogues
as well as the Color Info Window.
Adds a dropdown for Simulation Profile, Intent, and BPC
to the Create a New Image dialog.
This allows users to assign a soft-proofing profile when the image is
first created. It defaults to "None", however. Users can also set the
default simulation rendering intent and BPC status per image.
These options are also removed from the Preferences dialog.
Adds a simulation_bpc and simulation_intent to GimpImage to allow
plug-ins to access it
for CMYK import/export.
Four pdb functions were added to enable this access:
image_get_simulation_bpc (), image_set_simulation_bpc (),
image_get_simulation_intent (), and image_set_simulation_intent ().
Next, it updates menu options and code to support GimpImage's
internal simulation intent and bpc.
New 'simulation-intent-changed' and 'simulation-bpc-changed signal
are emitted via
GimpColorManagedInterface so that relevant tools
(such as the
CYMK color picker, GimpColorFrame, and future pop-overs)
are aware of these changes.
When zooming using scroll events it is possible to zoom out of gradient
bounds because the check for out of bounds zoom happens with the zoom
value before the delta is applied. The correct way is to limit the zoom
value after the delta is applied.
Zoom focus centers the point that we're zooming into at the location of
the mouse pointer.
Default zoom focus value is 0.5 which results in previous behavior.
Smooth scrolling requires that we keep the scroll (or zoom, as is in
this case) state as a floating-point number. The scroll deltas are often
less than one, thus storing scroll state as an integer will effectively
ignore most of the scroll events.
Generated *enums.c now have an additional stamp no-op header include
(see last 2 commits). Sync this change into the autotools generation
scripts to prevent back and forth useless generation of these files each
time we switch from one build system to another.
They are nearly the same as initially, except that now they include an
intermediate stamp header which will be generated by the build system.
The only 2 enums which don't need these includes (and are not versioned)
are libgimp/gimpenums.c and libgimpthumb/gimpthumb-enums.c.
Our meson build system was not properly building the enums.c file,
because they are versionned.
I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).
The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.
See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
g_warning() (as well as g_critical() and g_return_*()) are reserved for
core code bugs, and therefore triggers a debug dialog with a backtrace
to report.
Here I encountered such duplicate because ts-helloworld.scm was moved
around from scripts/ to plug-ins/ since commit d5a83429b4 and I hadn't
done a clean uninstall (so of course someone with package installation
should not have such a debug dialog). Yet it could actually happen for
various reasons, such as third-party plug-ins actually registering
identically named actions. Such reasons are not core code bugs and we
don't want to trigger a debug dialog (and have people report bugs to us
which are not actual bugs and which we have no power to fix) each time a
plug-in developer uses a too generic action name.
So instead let's just print to stderr for now. I also add the
information on which plug-in was discarded (otherwise if you actually
have 2 different plug-ins doing different things, you wouldn't know
which one is the visible one and which one can't be called).
Note that I hesitated with a g_message() which would pop-up a
user-facing error and would help them better handle their plug-in
conflict. But I'm not sure it's ideal in current state of things either.
It might be much better handled when we will have moved to recommending
extensions wrapping plug-ins.
Adds a simulation_profile to GimpImage to allow plug-ins to access it
for CMYK import/export.
Two pdb functions were added to enable this access:
image_get_simulation_profile () and image_set_simulation_profile()
Next, it updates menu options and code to support GimpImage's
internal simulation profile. Menu items are moved from View to Image's
Color Management section.
New 'simulation-profile-changed' signal is emitted via
GimpColorManagedInterface so that relevant tools (such as the
CYMK color picker, GimpColorFrame, and future dockable
dialogue) are aware of these changes.
- Some coding style fixes (alignment, etc.).
- Adding missing "Since: 3.0" annotations. We are still wondering
whether this should go in 2.10, in which case, it would become
"Since: 2.10.32" annotations. See discussion in !274.
- Changing gimp_checks_get_colors() signature: merge the 4 color
arguments into 2 (inout) arguments which seems a bit nicer in C,
whereas binding handles such arguments correctly. The other
alternative would have been to at least change the order to have out
arguments in the end.
I also hesitated to get another API in libgimp, which would have been
config-aware (just returning the 2 check colors, depending on user-set
Preferences), then having GimpPreviewArea handling 2 colors (without a
GimpCheckType input). But actually, doing this, we'd remove the nice
menu popup where one could choose a generic check type (not everyone
wants to play with specific non-gray colors) in Gimp*Preview widgets.
So in the end, I left this whole thing as-is.
Instead I document the function with code sample to initialize
properly the GimpPreviewArea (since libgimpwidgets/ are independent
with no knowledge of the core config) in order to respect user
preferences.
- Hide the color properties in gimp_preview_area_menu_new() because
anyway gimp_preview_area_menu_new() does not support GimpRGB
properties right now (so all we get are warnings). It's still possible
to select custom colors on GimpPreviewArea, simply we are stuck at the
ones set in Preferences globally for now (unless a plug-in creates
custom GUI to set these).
Fixed Conflicts from !274:
libgimp/gimp.h
libgimpwidgets/gimppreviewarea.c
Reviewer (Jehan) note: cherry picked from MR !274. Still deciding
whether this will be pushed to gimp-2-10 branch too.
Fixed Conflicts from !274:
app/dialogs/preferences-dialog.c
app/display/gimpdisplayshell-draw.c
app/plug-in/gimppluginmanager-call.c
libgimp/gimp.c
libgimp/gimp.h
libgimpwidgets/gimppreviewarea.c
libgimpwidgets/gimppreviewarea.h
libgimpwidgets/gimpscrolledpreview.c
This fixes the following warnings:
```
[2153/2321] Compiling C object app/widgets/libappwidgets.a.p/gimppanedbox.c.o
../app/widgets/gimppanedbox.c: In function ‘gimp_paned_box_dispose’:
../app/widgets/gimppanedbox.c:171:17: warning: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’ [-Wsign-compare]
171 | for (i = 0; i < G_N_ELEMENTS (paned_box->p->dnd_highlights); i++)
| ^
../app/widgets/gimppanedbox.c: In function ‘gimp_paned_box_drop_indicator_draw’:
../app/widgets/gimppanedbox.c:370:17: warning: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’ [-Wsign-compare]
370 | for (i = 0; i < G_N_ELEMENTS (paned_box->p->dnd_highlights); i++)
| ^
```
After some investigation, I am a bit unsure of why this happens exactly,
but I have a case that the device's axis number listed is not right and
this only becomes apparent after the stylus gets close then further from
the tablet-display. This fixes it, though I think we should look more
closely and reorganize a bit this whole part of our code, which seems
unecessarily complicated and duplicating some data already in GTK/GDK,
like the list of axis, etc. (though maybe it was necessary back when
this was first implemented before more logics got moved to GDK?)
Fixing broken coding style and factorize the code to avoid redundant
calls, in a separate commit as the contributor hasn't responded for
nearly 2 years. Also no need to get the character count as -1 offset is
equivalent to point after last character (or alternatively we could have
used gtk_text_buffer_get_end_iter()).
I had raised some more questions on a possible better implementation (or
maybe not), but since the discussion never happened, let's just push
as-is. It still improves things and the whole text editor should be
revamped some day anyway.
The MR commit (i.e. previous commit) fixes the specific case when
changing font size with no text selected (changing the size of the whole
text).
… in previous commit.
Also fix some coding style bugs.
Finally change s/"Single Dot"/"Single dot"/ to have the same label
syntax (only capitalize the first letter of the label) as other labels.
Cf. #7034 and !466.
The changes include:
* A popover will be displayed on tool buttons and relevant property
widgets.
* Now the welcome dialog gives focus up to its parent window because
really the whole focus styling issue in GTK is a bit maddening. The
colors are all faded, the popover widgets are barely visible, and so
on.
* Timing is tweaked a bit to give more time reading the popover tips.
… blinking it.
This will be necessary to demo new features available only in some
situations. E.g. a new option in line art detection mode of bucket fill
would require said mode to be enabled.
First I strip now every pieces of text. What it allows it to span the
script elements for instance on several lines, indent them and all that.
The second thing is that since all the dockable start with "gimp-", we
may as well allow use shorter names (both are allowed). Same for tool
(which we special-case), all the tool buttons ID start with "tools-"
since we reused the action names. So let's just allow the shorter
versions.
Finally I create a new gimp_blink_toolbox() which is a specialized
gimp_blink_dockable() for the toolbox in particular. I also move there
the whole code about selecting the right tool.
The idea is to add some "demo" attribute to a list item inside the
<release> tag, since we already decided that (for now at least) we'd
keep a strict "intro + list" logics, as we did until now.
This demo attribute uses an internal format to specify successive
widgets to blink (like a demo path towards a feature). For now, what it
allows is:
* raise the toolbox, select a tool and blink the tool button.
* raise a dockable, blink any widgets in there.
Now it is still limited and needs to evolve. In particular:
* What happens if the blinked tool button was explicitly removed from
Preferences? Should we re-add it for the demo? And once done, should
we remove it again? Then should we select back the tool previously
selected?
* What happens if the dockable widget is not visible? Should we allow
changing the settings to be able to demo correctly the new/changed
settings? Should it be temporary? If temporary, it can be annoying as
you'd still have to look attentively the demo to find back the path to
the new settings. If not temporary, some people may dislike we touch
their settings.
* What if docks are hidden? Should we unhide them, then hide them back
after demo time?
Also regarding the implementation: originally I wanted to just grab the
demo attribute directly from the AppStream metadata file, but I realized
that appstream-glib cleans out unknown attribute from the XML. I could
then simply parse the file with a generic XML parser, but I found
simpler to pre-parse it into a header built within GIMP. I still use
appstream-glib at runtime as it takes care of localization for us
(though in the same time, we also have the localization in the main po
files, so maybe we could just embed the release note strings as well).
See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
I add it in libgimpwidgets because we need to also use it on propwidgets
created from there, but it's actually only for core GUI usage, so it's
actually in a private part of the library.
Though it's actually doing quite a basic thing, it is nicer and more
foolproof than a manual g_object_set*() everywhere. Moreover it will be
nicer to grep.
… a given order, not at the same time.
This will be used for the release item notifications to show people
where new or changed features are, but in an ordered blink scenario. For
instance: select a tool first, then blink some tool icon, open the tool
options and finally blink the specific new/changed option. I am hoping
it would help awareness of changes (just words on a web news may make
some features a bit foreign when not used to look in details in advanced
options).
This function will help us raise attention to various widgets in
dockables by blinking them similarly to how we blink locks or visibility
icons.
I associate this with the fact that property widgets identifier will be
the property name, so we get identifiers for free when creating widgets
through the propwidgets API.
Since we can't select a source, the source tools would fail stroking
with an error. It was usable when stroking a path or selection as we
can have the source tool started while running these. Since only one
tool can be started at once, this is not possible when running bucket
fill tool (it would require some logics change on tools).
This change has 2 parts: add an "insensitive" column to
GimpContainerComboBox (allowing to mark some cells as insensitive), then
use this new attribute in the GimpBucketFillOptions to show all source
tools as insensitive.
Jehan