As noted by bootchk, docs of gtk_application_is_inhibited() says:
> Determines if any of the actions specified in flags are currently inhibited (possibly by another application).
The last part, between parentheses imply that it's possible for another
application to inhibit GIMP. So we should not rely on this function to
verify we inhibited the logout. Just check of we have an inhibition
cookie.
This is the only "language" from the list whose name is special and
should be localized at runtime, yet before we set any Preferences
language. It needs to be localized as the System Language itself which
will be run-dependant.
For instance, if your system is in French, it will be displayed as
"Langue système" but if you change your system to Korean, at next run,
it would show "시스템 언어". It is a per-run localization, independant
from the language selected in Preferences, and even less dependant from
build-time system language.
Instead of always parsing the ISO-639 listing at each and every startup,
let's just generate the list of languages, their English name, and the
self-localized names as static struct.
This will just be much faster, and no worrying on the size of the XML
(or json) to parse.
Inspired by Mark Sweeney's work.
This patch allows the icons in the tree
view in Preferences Dialog to scale based
on user icon scale preferences.
Rather than add a GimpGuiConfig to
GimpPrefsBox, we make a call to style_updated ()
from the Preferences Dialog to signal a
change.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes#10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
Inspired by Mark Sweeney's work.
This patch allows the active image, brush,
pattern, and gradient areas in the toolbox
to scale based on user icon scale
preferences.
Note that if the pattern itself is smaller
than the icon size, it currently won't scale
larger. This is a separate issue in the
renderer.
Inspired by Mark Sweeney's work.
This patch allows the four buttons on the
sides of the canvas (Zoom, Quick Mask,
Image Menu, and Navigation Image)
to resize based on the user's icon size
preferences.
...based on icon size preferences.
Inspired by Mark Sweeney's work.
Since the icon size is based on a formula,
the CSS value determines the maximum
size rather than being used directly.
Inspired by Mark Sweeney's work.
GimpColorNotebook has existing code to
update the color selector tab icon sizes
via CSS. However, it was not set up to be
notified of icon size changes from the GUI.
Since GimpColorNotebook is in libgimpwidgets,
we call its style_updated () function from
the style_updated () functions of the two
widgets its created in - GimpColorEditor
and GimpColorDialog.
Meson subprojects just have too many problems and limitations and I can foresee
the maintenance headache and the future incoming false-positive bug reports if
we start using meson subprojects.
Comparing to the simplicity of git submodule which also has much better
notifications to help people understand when the submodule is not in sync and
how to remedy to it.
See commit gimp-data@c364adb explaining the main reasons in detail.
This commit is separate from the previous to make it immediately clear (by
comparing files) that the previous commit is a simple move with no modification
whatsoever of the icons/ directory, i.e. the symmetrical removal of add commit
gimp-data@8b54490.
We now clone gimp-data as a meson subproject. I am currently testing the
subproject feature though I am doubting a bit because of its limitations: the
git clone is not updated automatically, nor are errors clear. Therefore it would
be easy to end up with outdated data for developers not manually and regularly
running:
> meson subprojects update
Worse, it looks like even when updating the suproject, it fails to be properly
reconfigured. See: https://github.com/mesonbuild/meson/issues/12898
Though commit a14caafa8c was not wrong per-se, it's a bit too much. ;-)
Functions like g_ascii_dtostr() already exists for this very purpose of
converting a double/float to string in a locale-independent format.
CSS breaks when given a number with a comma as the radix
instead of a decimal. Depending on the system localization,
printf () may return numbers in this format when resizing
the font. This causes the theme to break unless font size is
set to 100.
To prevent this issue, we create the font size string manually
using integer division and mod operations.
- app: gimp_context_get_(foreground|background)() are now returning a GeglColor.
- libgimp: PDB functions named similarly in libgimp are returning a newly
allocated GeglColor too.
- A few other PDB functions (the ones using these functions) were updated and
their signature changed to use GeglColor too, when relevant. Plug-ins which
use any of the changed libgimp functions were fixed.
- GimpContext: signals "(foreground|background)-changed" are now passing a
GeglColor.
- libgimpconfig: new macro GIMP_CONFIG_PROP_COLOR using gegl_param_spec_color().
- GimpContext: properties "foreground" and "background" are now GeglParamColor
properties.
- app: All code interacting with GimpContext objects were updated to receive a
GeglColor (that they may still convert, or no, to GimpRGB for now).
- app: gimp_prop_gegl_color_button_new() was added as an alternative to
gimp_prop_color_button_new() when the property is a GeglParamColor. Eventually
the former should replace completely the latter.
- libgimpwidgets: gimp_prop_color_area_new() now works on GeglParamColor
properties only.
- libgimp: gimp_procedure_dialog_get_widget() will generate a GimpColorArea for
GeglTypeParamColor arguments.
The Compact theme code is nearly the same as the Default one, apart from setting
palette icon size to small (which is already something done by the "Override
icon sizes" setting in Preferences), setting font-size to small (which can be
independently set by our "Font Scaling" setting) and setting 3 paddings.
Rather than having this separate theme, it feels like just moving the padding
changes as part of the icon size makes sense. In particular since, when setting
icons to "Small" right now, the default padding really feels a bit huge and out
of place. So all-in-one seems a better choice.
At first, I wanted to set a padding proportional to the icon size, but it didn't
work well. For now, I'll just choose padding sizes manually.
The current GTK algorithm for finding an icon seems to be:
main icon theme in choosen style > fallback icon theme in choosen style >
main icon theme in another style > fallback icon theme in another style
Where "style" is either color or symbolic variant of a given icon. The problem
is therefore if say your prefered style is "Symbolic" and you choose a
Color-only icon theme. In such a configuration, all icons which are also
available in the system theme with a symbolic variant will be used from the
system theme (even when they are actually available in the chosen icon theme
too, yet in a color variant) and you get a weird mix of part of the icons as
symbolic from system theme and another part as color from the chosen theme.
In order to avoid this weird situation, we only set -gtk-icon-style CSS value to
the prefer-symbolic-icons property if the chosen icon theme has both style
variants. Otherwise we force the only variant of the chosen icon theme.
The icon "gimp-wilber" is used to determine whether an icon theme has both
variants, which should be documented in the developer website for icon theme
makers.
The merged icon theme is simply named "Default" and contains a color and
symbolic variant for all icons. While in 2.10, it made sense to have both icon
themes because a theme had no concept of a "symbolic" variant back then, icon
themes in 3.0 have this concept and we support this in GIMP through the "Use
symbolic icons if available" option in Preferences.
Until now, it was confusing to have both themes + this option, even more as you
could use the Color icons with the "Use symbolic icons" option, which meant that
if some icons were missing, you could end up with a mix of color and symbolic
icons (and oppositely using the Symbolic theme with the option unchecked).
The new state is much simpler and less confusing. Just 1 icon theme with both
color and symbolic variants (the latter being used by default).
Note that the identical meson.build in each size subfolder is still mandatory
because of the inability of meson (still!) to generate files with
custom_target() in a subfolder as output.
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.
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.
Resolves the second half of #300.
This adds conditional code to the gtk_window_present () call in gui.c
to prevent it from running if the user requested it stay minimized in the shortcut
or commandline call on Windows.
It also keeps the splashscreen minimized in that case.
… with another default shortcut.
This won't happen with the standard US layout, but among all the layouts which
exist (or will exist), there is no say that the characters behing <shift>2-5
keys are not another one of our default shortcuts for other actions. We don't
want to print this case, because it is special enough that it's really not a
bug. In this case, we just ignore the transformed shortcut on the zoom action
and be done with it.
I am using the same GimpDrawableChooser with an additional drawable_type
argument to only show the appropriate tab if we want to limit what can be
chosen.
None of our plug-ins actually use a GimpLayer or GimpChannel only arg so far,
but if we have some day, or if some third-party plug-ins want to have such arg,
now they quite easily can!
Similarly to the various GimpResource select PDB calls, this allows to call a
core dialog in order to choose a drawable which will be returned back to the
calling plug-in.
This new GimpPickableSelect dialog is a subclass of GimpPdbDialog and uses the
same GimpPickableChooser widget as GimpPickablePopup, except that since it's
inter-process window management, it is harder to make a popup positioned
accurately relatively to a parent (especially on Wayland). This is why it's a
separate widget as a simpler dialog (which we will still try to make transient
as much as possible across platforms).
Brush, font, gradient, palette and pattern choices are currently chosen through
a dialog created by the core, which then returns the user choice to the calling
plug-in. This has the unfortunate consequence of having a pile of likely at
least 3 windows (main GIMP window by core process, plug-in window by plug-in
process, then the choice popup by the core process) shared in 2 processes, which
often end up under each other and that's messy. Even more as the choice popup is
kinda expected to be like a sub-part of the plug-in dialog.
So anyway, now the plug-in can send its window handle to the core so that the
resource choice dialog ends up always above the plug-in dialog.
Of course, it will always work only on platforms where we have working
inter-process transient support.
Having windows ID as guint32 is a mistake. Different systems have
different protocols. In Wayland in particular, Windows handles are
exchanged as strings. What this commit does is the following:
In core:
- get_window_id() virtual function in core GimpProgress is changed to
return a GBytes, as a generic "data" to represent a window differently
on different systems.
- All implementations of get_window_id() in various classes implementing
this interface are updated accordingly:
* GimpSubProgress
* GimpDisplay returns the handle of its shell.
* GimpDisplayShell now creates its window handle at construction with
libgimpwidget's gimp_widget_set_native_handle() and simply return
this handle every time it's requested.
* GimpFileDialog also creates its window handle at construction with
gimp_widget_set_native_handle().
- gimp_window_set_transient_for() in core is changed to take a
GimpProgress as argument (instead of a guint32 ID), requests and
process the ID itself, according to the running platform. In
particular, the following were improved:
* Unlike old code, it will work even if the window is not visible yet.
In such a case, the function simply adds a signal handler to set
transient at mapping. It makes it easier to use it at construction
in a reliable way.
* It now works for Wayland too, additionally to X11.
- GimpPdbProgress now exchanges a GBytes too with the command
GIMP_PROGRESS_COMMAND_GET_WINDOW.
- display_get_window_id() in gimp-gui.h also returns a GBytes now.
PDB/libgimp:
- gimp_display_get_window_handle() and gimp_progress_get_window_handle()
now return a GBytes to represent a window handle in an opaque way
(depending on the running platform).
In libgimp:
- GimpProgress's get_window() virtual function changed to return a
GBytes and renamed get_window_handle().
- In particular GimpProgressBar is the only implementation of
get_window_handle(). It creates its handle at object construction with
libgimpwidget's gimp_widget_set_native_handle() and the virtual
method's implementation simply returns the GBytes.
In libgimpUi:
- gimp_ui_get_display_window() and gimp_ui_get_progress_window() were
removed. We should not assume anymore that it is possible to create a
GdkWindow to be used. For instance this is not possible with Wayland
which has its own way to set a window transient with a string handle.
- gimp_window_set_transient_for_display() and
gimp_window_set_transient() now use an internal implementation similar
to core gimp_window_set_transient_for(), with the same improvements
(works even at construction when the window is not visible yet + works
for Wayland too).
In libgimpwidgets:
- New gimp_widget_set_native_handle() is a helper function used both in
core and libgimp* libraries for widgets which we want to be usable as
possible parents. It takes care of getting the relevant window handle
(depending on the running platform) and stores it in a given pointer,
either immediately or after a callback once the widget is mapped. So
it can be used at construction. Also it sets a handle for X11 or
Wayland.
In plug-ins:
- Screenshot uses the new gimp_progress_get_window_handle() directly now
in its X11 code path and creates out of it a GdkWindows itself with
gdk_x11_window_foreign_new_for_display().
Our inter-process transient implementation only worked for X11, and with
this commit, it works for Wayland too.
There is code for Windows but it is currently disabled as it apparently
hangs (there is a comment in-code which links to this old report:
https://bugzilla.gnome.org/show_bug.cgi?id=359538). NikcDC tested
yesterday with re-enabling the code and said they experienced a freeze.
;-(
Finally there is no infrastructure yet to make this work on macOS and
apparently there is no implementation of window handle in GDK for macOS
that I could find. I'm not sure if macOS doesn't have this concept of
setting transient on another processus's window or GDK is simply lacking
the implementation.
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.
This is not the main reason for the specific output in #9994. These ones are
more probably because of similar usage in GTK (which updated its own calls to
g_file_info_get_is_hidden|backup() in version 3.24.38). But we should likely
also update the various calls we have to use the generic
g_file_info_get_attribute_*() variants.
To be fair, it is unclear to me when we can be sure that an attribute is set.
For instance, when we call g_file_enumerate_children() or g_file_query_info()
with specific attributes, docs say that it is still possible for these
attributes to not be set. So I assume it means we should never use direct
accessor functions.
The only exception is that I didn't remove usage of g_file_info_get_name(),
since its docs says:
> * Gets a display name for a file. This is guaranteed to always be set.
Even though it also says just after:
> * It is an error to call this if the #GFileInfo does not contain
> * %G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME.
Which is very contradictory. But assuming that this error warning was
over-zealous documentation, I kept the direct accessors since they are supposed
to be slightly more optimized (still according to in-code documentation) so
let's priorize them when we know they are set for sure.
My previous commit was improving the case where we just get many "dirty" signals
and successful inhibition. But if the inhibition request was failing, we would
just retry again and again.
This new version will hold off on on requesting the inhibition for the next 10
minutes. Then it will try again, in case the failure reason might have been
temporary.
… the reason message changes (i.e. when number of dirty image changes).
Some actions in particular would trigger several "dirty" signals, there is no
reason to uninhibit then re-inhibit repeatedly. And as a more general rule,
there is no reason to do so even for different actions while we are not planning
to update the inhibition reason.
It may not be the main reason for #9446 (because if it hangs for several
minutes, there is likely something going on, deeper at the dbus call level), yet
it would definitely alleviate the issue (dividing the wait by as many times as
the dirty signal was emitted!).
When passing an application ID (which is necessary for application inhibition to
work, i.e. logoff/reboot/shutdown inhibition), GApplication will try to ensure
process uniqueness, which will trigger a new activation to an already running
process. Since our current code assumes that the application can be activated a
single time only, this was what was triggering a whole lot of errors (on the
first running process) in #9598 because there was all the initialization code
which ran again, whereas it was not supposed to.
This doubly-running initialization code was also what completely messed up the
session files, hence broke the GUI after a restart (#9599).
Therefore passing G_APPLICATION_NON_UNIQUE advertizes we don't want GIO to
handle process uniqueness for us.
Note that this is actually a very interesting feature which we have had in GIMP
codebase forever. It would be interesting to kill all our own uniqueness code in
favor of GIO code (and let them handle/maintain passing command line arguments
from one process to another, for all possible platforms). So I added a TODO for
this (for now, we just ignore this feature as it doesn't work well with current
codebase).
Resolves#5742.
From fa0a0212, the splash's upper text was scaled to PANGO_SCALE_MEDIUM
both when the image width was 2x or less than 2x. This was likely a
copy/paste issue, as the lower text code scaling does not duplicate.
This patch fixes it by changing the else condition to scale to
PANGO_SCALE_SMALL.
Note that this change is unlikely to be seen as it requires a very small
splash screen image to reach the else condition.
gtk_accel_map_load()/gtk_accel_map_save() are not working with the new
GAction-based code. GtkApplication does not seem to have helper functions to
simply load and save accelerators in a file, so we just implement it ourselves.
A few things are missing right now, namely:
- On parsing, it doesn't handle any kind of duplicate accelerators (possible
especially if someone edited the new shortcutsrc manually).
- On reading, maybe we should only write down the changed (from defaults)
actions, while keeping the old ones commented-out, as menurc used to be. This
is actually useful info both for debugging or even for users who want to look
at this file and see what they changed.
- We should add import code to transform the menurc into shortcutsrc when
updating GIMP, otherwise all custom shortcuts would get lost.
There is still the question on whether we should add the group name too. I think
we should, expecially for plug-in's procedure actions, though right now these
are just added in the GtkApplication's main action group anyway. I'll see later
to refine this.
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.
Unless mistaken, this is not needed anymore. New GtkApplication code should take
care of creating the native macOS application menu for us.
Cf. also contents of MR !558.
