Per @brunolopesdsilv, the About and Quit
dialogues had custom buttons which did
not receive the text-button CSS style.
This patch adds those back so the buttons
match the styling of the others in the
dialogue.
...with the Enter key. Combines the single image
and multi-image opening methods so that no matter
how you open recent images (single click, button, or
multi-select and pressing Enter), it opens all selected
images in the Welcome Dialog.
The alternative solution would be to call:
> image_new_dialog_set (dialog, NULL, NULL);
This would have reset to default template. But it's still not exactly like the
"new image" action which defaults to the active image's size if there is an
opened image.
In order to avoid complicating the code further, as well as code duplication,
hence code divergence, let's call the "image-new" action, making sure that this
button will always behave exactly like the "File > New" menu item.
Then since we need to process the return value of this dialog (either re-showing
the welcome dialog in case of new image creation cancelation, or destroying the
hidden welcome dialog otherwise), I check for the singleton pointer and connect
the handlers to it.
Moreover I made the "response" signal of ImageNewDialog be handled as
G_CONNECT_AFTER otherwise we nearly never had the possibility to handle its
responses properly (because the base handler was doing it first, then often
destroying the dialog).
Allows users to quickly configure themes and other
"controversial" options when first installed.
Also allows the welcome dialogue to appear on start,
depending on user preference.
Since resources must now either belong to an image, or be tied to a file, or be
marked as internal, we must immediately save imported palettes, so that they are
tied to their file.
The invasion extended to some core widgets too, in particular GimpColorPanel (a
subclass of GimpColorButton). There was quite a lot of code depending on these
widgets.
This includes improvements on the out-of-gamut colored corner being shown for
unbounded component types out of the [0; 1] range (with some small margin of
error to avoid e.g. a -0.0000001 value to show as out-of-gamut).
There are still improvements to be made on the color rendering. In particular,
it still draws as CAIRO_FORMAT_RGB24 cairo surface. We should probably move to
draw as CAIRO_FORMAT_RGBA128F eventually (more precision and even allowing to
draw unbounded colors with a possible option, instead of always clipping).
Also adding the libgimpwidgets API gimp_widget_get_render_space().
- New function gimp_cairo_set_source_color() which is meant to replace
gimp_cairo_set_source_rgb(a?)() eventually. This new function sets the Cairo
source color, using the target monitor's profile of the widget where the Cairo
surface is meant to be drawn on. It also uses the color management settings
(such as whether a custom profile was set, instead of using system profile, or
also simply whether color management was disabled at all). It doesn't
soft-proof the color yet.
- Padding and out-of-gamut colors drawing now use the new
gimp_cairo_set_source_color(). These don't need any soft-proofing anyway.
- Out-of-gamut color property in GimpColorConfig is now a GeglColor property.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
If a system theme sets the background-image property for stacks,
it recolors the main canvas when empty. It also adds a border to
the toolbox Wilber area.
Additionally, the Credits page of the GtkAboutDialog has odd colors
due to general viewport grid styles overriding the GTK default.
This patch fixes these problems, and adds a custom CSS class to
the GimpAboutDialog for current and future work.
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.
