Due to a bug in commit de5c805cbb, which
changed the choice widget between line and paint tool to a
GtkStackSwitcher, changing that choice did not work anymore.
The reason being that the stroke method wasn't being updated on clicking
stroke. We fix this by setting the stroke method when OK is clicked.
When creating the dialog we also set the stroke method, to reflect the
last used choice, since that was also missing.
The UI is heavily inspired in the existing one for midi devices
and the such, as the restrictions are somewhat similar. Since there
is not enough information to introspect the device without the help
of libwacom (and the UI should work with tablets unsupported by
it, regardless) the list starts empty, and there exists a "grab
event" button to press pad buttons (or use rings/strips) and
create/focus a list item for the button/mode.
Double clicking on an action (or pressing the "edit" button) spawns
a different dialog with a GimpActionEditor to select an action.
And lastly, actions can be deleted with the "delete" button.
Pads may have different modes (e.g. leds in the tablet) that apply
to all pad features, the list will allow different actions to be
set on the same button in different modes. This basically multiplies
the amount of mappable actions by the number of available modes.
Also added option in Edit->Preferences->"Tool Options"->"Paint Options
Shared Between Tools" that decides weather the options should be shared
between different tools.
On Windows, the title bar can be set to light or dark mode via DwmSetWindowAttribute ().
This adds code to update the main title bar and dialogue title bars based on the current theme.
The main title bar uses "prefer-dark-theme", while the dialogue title bars
uses the color of the widget background to assume the correct color.
Though GTK+3 is supposed to take care of scaling fonts with high density
displays, it turns out it is not enough for many, for various reasons (taste,
eyesight, distance to the display…). So we add this additional settings to tweak
further the font size.
With Aryeom, we experimented/discussed both a percentage UI vs. an absolute font
size field (e.g. as they provide in GNOME Tweaks). In the end, we went for a
percentage UI because we realize that we don't necessarily know what is the
current size at all. Mostly you just want bigger or smaller, and don't
necessarily care so much at which value is the font size.
This settings only has a single limitation (that we could find), which is when
used on a theme with widget rules using absolute font-size rules (px, or
keywords such as small/medium/large). As long as the CSS rules are relative
though (either to the parent widget, or to the root size), then it works fine.
Basically a theme hard-coding font sizes won't fare well with this settings, but
since we can consider this bad practice, it's an acceptable limitation.
Adds a class "gimp-offset-area-frame" to the frame containing a GimpOffsetArea in resize dialogues.
This allows the styling from 2.10 to be applied to indicate canvas size when resizing layers.
Since GimpOffsetArea is a GtkDrawingArea object, it can't have CSS directly
applied to it - that's why the class is added to the frame instead.
GIMP's .gpl palette format and Swatchbooker's .sbz format can contain
metadata on the number of columns. This value was ignored before;
now the import dialogue checks for this value and uses it.
We use US English which uses behavior. So we replace all occurrences of
behaviour.
Most notable is File Open behavior in preferences. Besides that several
mentions in function documentation and a few in comments.
We already search for a compatible Python version in the root meson file, no
need to look up Python 3 again in the PATH, each time we run an external Python
script in the build.
This should hopefully fix#9687.
Resolves issue with #8461.
This provides a conditional value for the fill options to only show
a color and pattern, rather than fore/background colors.
Currently only used for the text editor.
Though not a bug, this change will get rid of the following warning:
> app/dialogs/module-dialog.c:291:28: warning: ‘location’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> 291 | text[INFO_LOCATION] = gimp_module_is_on_disk (module) ?
This patch does the following things:
- An option "Merge menu and title bar" (this is hopefully more understandable
than calling it "Client-side decoration" or again "header bar") is added in
Preferences > Image Windows. This option triggers the restart warning.
Moreover when checked a small warning message will tell that in some cases, it
may not work (there are feedbacks of people having 2 title bars when using GTK
applications using CSD).
- For the reason evoked above (sometimes 2 title bars) and also because the CSD
concept seem really to divide people a lot (some love this as much as others
hate this), this new option "custom-title-bar" on GimpGuiConfig is FALSE by
default.
- When the option is checked, the image windows will use a GTK header bar
containing the menu, the window title (image name and information) as well as
the usual minimize/maximize/close buttons per your OS conventions.
- Since the header bar is set to be hidden when maximizing, if you checked "Show
menubar" for the "Default Appearance in Fullscreen Mode" in Preferences >
Image Windows > Appearance, the menu will be moved to its "old style"
position, i.e. above the canvas. This makes the menu possibly visible (if
relevant option is checked) even in fullscreen mode.
- I tweaked the Default theme to show the header bar with minimal height,
because I find GTK default theme's headerbar height unreasonably high
(especially if the point of the header bar is to save screen space). I am
unsure if this was the right move though, because maybe the default theme
should not do such choices (maybe this should go in the Compact theme?).
The Extensions dialogue assumed that it had a header bar. Since this is
not always the case, conditional checks were added to prevent
GtkHeaderBar code from running. This also fixes a crash when you
double-click to expand the extension description.
This commit converts `GimpModuleDB` into a `GListModel`. This allows us
to drop quite a bit of custom code to have an adaptive list of modules
by just becoming a `GListModel` implementation.
Next to that, this commit also rewrites `GimpModule` to use the `notify`
signal for its 2 new properties: "auto-load" and "on-disk", rather than
trying to define a custom signal for that. This in turn allows us to use
basic methods like `g_object_bind_property()`.
Finally, the module manager dialog now uses `GtkListBox`, which can
easily bind to that new `GListModel` infrastructure.
Use a `GtkListBox` to show the list of GIMP themes rather than a
treeview. The idea is that we can expand this a bit more to give a
preview of the theme later on.
Five icons in the Layer dockable were being replaced by GTK defaults at
runtime. A "gimp-" prefix was added so that GIMP's version would always
be used. A few dialogues were fixed to use constants rather than
hardcoding the filename, to make it easier to update the icon in the
future.
This was always confusing to people that they had to click "Save" then "Close".
With new code anyway, any change is instantly put into effect, and the only
point of "Save" is to actually store immediately in the shortcutsrc file. But
this is clearly not very clear to people (and it can be done in the Preferences
dialog too).
Instead let's just have a "OK" button. The file will be actually updated on exit
only (if "Save keyboard shortcuts on exit" is checked). And that's it.
The only missing feature would be the ability to cancel the latest changes
before hitting OK, i.e. having a "Cancel" button too. Let's see to do this
later.
Pre-GIMP-3.0 code logics would re-allocate several GimpMenuFactory or
GimpUIManager for no good reason. While it was still working with old GtkAction
code, with our new GAction-based code, we were ending up overriding an action
with a new version of the same action, while keeping reference to old actions.
This made for discrepancies of the enabled or visible state of actions.
The new code keeps singleton of some objects and references to already
registered GimpUIManager or GimpActionGroups objects and make sure no actions
with the same name are created twice.
Note that I could edit the GimpUiManager directly to use the GAction API, but I
feel like it is adding a level of complexity to existing GIO/GTK API. So right
now, I am planning to either get rid of it or really simplifying it a lot.
We had this feature "can-change-accels" where people could change their shortcut
directly by browsing the menu. It was on the property "gtk-can-change-accels" in
GtkSettings. Unfortunately this got deprecated in GTK+ 3.10 (more accurately in
dev version 3.9.8, according to GTK's NEWS file), and is therefore ignored since
then. In other words, whether we check the box or not in our Preferences, it
doesn't do a difference.
If we want to get the feature back some day, we'll have to reimplement it with
custom code. In the meantime, there is no need to leave this visible in
Preferences.
I find these options always a bit unwise when people have no idea how to change
their mind. Therefore adding a tooltip with the information (though maybe we
should even do it even more clearly and adding that in checkbox text too?).
For this to happen, I've updated the main question to be "Keep the Embedded
Working Space?" instead of "Convert to * Working Space?". Basically now we put
emphasis on keeping the image's color profile as being the proposed action.
Therefore "Keep" is the default answer, on the right.
Yet "Convert" stays on the right too. There is no "Cancel" button anymore
because it is not a question we can really escape even though "Esc" still works,
and it still corresponds to "Keep", same as Enter now. The reason is that "Keep"
is actually the non-destructive option. So if someone really doesn't want to
answer and make an explicit choice, we do it for them with the only
non-destructive choice possible.
Also I'm changing "Convert" mnemonic to 'c'. I guess that earlier devs might
have used 'o' because it is the usual mnemonic for "OK", so it was right when
the question was "Convert?". But since now the question is the opposite, there
is no reason to make it look like "OK". Let's just use the first letter, which
is easier to guess (and not taken by any other button here).
I've been hesitating because I don't think "Convert" was the right default
anymore with our anyRGB move. Until now, it was kinda implying that sRGB (when
no preferred color profile was set) was kinda the recommended space. It's not.
If a file already has another space, it's probably much better to keep it.
First because "Convert" is often a destructive change (even more if the target
is sRGB), so for people who don't necessarily understand all the ins and outs,
we were kinda promoting a destructive default behavior.
On the other hand (and that's why I was hesitating):
* "Keep" is also what happens when we hit "Esc" so some might complain that
there is no easy "Convert" key anymore (there is alt-c, but it's for sure not
as easy as Esc or Enter). Basically it makes the "Convert" option always a
much more explicit choice (yet it is likely for the best for people who care
about their colors).
* There might have been many people who would just use the default (Convert
until now) without thinking too much of what was asked, and that was working
good because they would just publish on the web or similar basic usage. If
they continue just accepting with Enter without reading and understanding what
is asked, now they could publish images with a color profile (and we know it
doesn't always work perfectly on the web).
In other words, it might be the best default for professional usage now, yet
it requires to understand a bit what you are doing.
It's really a hard call!
This kinda reverts commit 6aebd30de1 ("app: remove
icon sizing preferences"), except that the code base is different enough since
this old commit was mainly for GIMP 2.10.x.
In any case, after initially thinking that GTK+3 handling for high density
display would be enough, we finally decide that adding back a Preferences-wide
setting for overriding the theme-set icon size is a good idea (additionally to
GTK+3 automatic support).
The base idea for removing the feature was that GTK+3 has high density display
support, through the "scale factor". Typically a high density display will
normally be set as using a ×2 scale factor so all icons will be double size.
Unfortunately it turns out it's not enough.
For instance, on very small screen estate, even with a scale factor of 1, if the
theme sets 24px toolbox icons, it may still take too much space.
Oppositely on huge screens, even with ×2 factor scale detected by the OS, the
icons may still feel too small (this is possibly what happens with #7023).
Furthermore there is also a matter of taste. Some people like small icons even
when they have the space. Others may want bigger icons, easy to click on.
Finally you can like a theme for its color scheme for instance, but it may not
have the icon size you want. Right now, we'd need to duplicate every theme in
small or bigger size. Instead of doing so, let's just have this global setting
overriding the theme rules.
Comparison with the 2.10 implementation:
- We still provide 4 sizes: small, medium, large and huge.
- We don't have the "Guess ideal size" setting anymore. Instead this is now a
mix of the GTK+3 scale factor logic and the theme-set or custom size. I.e.
that on a high density display with ×2 scale factor, we could have toolbox
icons up to 96 pixels (48×2)!
- We now try to have less custom code in widgets as we append the CSS rules to
the theme (similar to what we were already doing for dark theme or icon
variants). What happens in widget code is mostly to connect to changes in
themes and redraw the widgets which need to be.
- The custom size will now affect: toolbox icons, the FG/BG editor widget (in
both the toolbox and the color dockable), dockable tab icons, the main
dockable buttons, eye and lock header icons in item tree views, eye and lock
cell icons in the item lists.
There are still a bunch of areas where it is not taken into account, such as
plug-ins, and various dialogs, but even in custom-made interface in dockables.
Ultimately it might be interesting to have a way to sync more buttons and
widgets to a global size settings.
Lastly, I fixed a bunch of existing bugs where we were updating icon sizes with
gtk_image_set_from_icon_name() using the const icon name taken from
gtk_image_get_icon_name(). As this was reusing the same string pointer, we were
ending with freeing the icon name.
This is shown in the About dialog when a new version is available, but
also in the debug dialog (also when a new version is available).
Of course, for stable versions, we should still show the main download
page (which I double-checked current code does).
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
