Since the entry behaves differently based on whether the user
provided an explicit input or not, it makes sense to have a button
for clearing the entry.
... when focus is lost/enter is pressed
When a GimpNumberPairEntry loses focus, or when enter is pressed,
set its user-override property by calling
gimp_number_pair_entry_set_user_override(), instead of setting the
corresponding member directly, so that the entry's font is updated
correctly.
"gimp-detach" does not just use "gtk-convert" anymore and has its own
design. As for "gimp-attach", this is not used anywhere (yet), but it
could be soon as reverse action of gimp-detach. For instance, this icon
can be used for bug 791859 when we implement re-attaching overlay
dialogs.
Normally, the model would try to avoid notifications when a set()
doesn't change anything, but with g_object_set() that's not possible.
Do the same in the propwidgets' callbacks and avoid potentially
expensive notifications at the cost of a cheap g_object_get().
Also fix the syntax of "Since:" and "Deprecated:" annotations.
This way, we get proper CRITICAL if ever there is a logic error (or in
this case, if we add new values to enums and forget to append them to
switch cases.
This will make these bugs much easier to debug if (when!) they happen.
This allows to have a smaller and cleaner color dock instead of just
listing all possible channels (which may only grow up as we may add more
color spaces).
The API gimp_color_scales_(set|get)_show_hsv() are removed in favor of
more generic gimp_color_selector_(set|get)_model(). I assume this is
ok since they have only been available in the dev version (commit
6258d525ae, a month ago).
This is WIP in the middle of cleaning up GimpColorSelector subclasses:
Add the possibility to switch between LCH and LSV and between 0..100
and 0..255 RGB in to GimpColorScales. Works almost fine, but needs
different UI to change the options...
The dashboard dockable shows the current GEGL cache and swap sizes,
and their recent history. It has options to control the update
rate and history duration of the data, and an option to warn (by
raising/blinking the dialog) when the swap size approaches its
limit.
Though forward declarations of the implementations are ok, it is cleaner
to have proper header files for each variant (default, kwin, quartz
right now). Of course these new header files are not installed and must
be kept private for build only.
Add support for KWin API, for KDE on Wayland.
Unfortunately though, KWin's "pick" API seems to have failures, so I
fallback to the default color picking when this happens. This will still
not work on Wayland, but at least won't cause regression for color
picking on KDE/X11.
See also KDE bug: https://bugs.kde.org/show_bug.cgi?id=387720
The "layout" proerty controls the combo-box layout (but not its
menu layout), and can be one of:
- ICON_ONLY: Only show icons.
- ABBREVIATED: Show icons and abbreviated labels (or full
labels, when there is no abbreviation).
- FULL: Show icons and full labels. Default.
Avoid reconstructing the combo's cell-layout when the menu is
shown/hidden, by maintaining the combo's cell-layout and the menu's
cell-layout separately (probably a terrible hack, but one we already
use :P).
Update the dprod production of generated enum files to include
abbreviated value descriptions, as per the previous commits.
Add a comment for translators above the abbreviated descriptions,
specifying the full description they abbreviate.
In GimpPickButton, try to pick from the local window under the
cursor, before falling back to picking from the root window, so
that we can at least pick from local windows on Wayland.
When a size entry has exactly two fields, enable ratio expressions
in eevl. Set the reference value to the value of the field that is
not currently being evaluated, and invert the ratio when evaluating
the second field.
Ratio expressions have the form 'x : y' (the ':' operator has the
highest precedence for a binary operator, and is left-associative).
Given a reference value 'a', the expression evaluates to
'a * (x / y)'.
Ratio expressions can be controlled by the caller by:
- Enabling or disabling them: They're meant to be used when the
eevl servers two paired entries, and can be disabled otherwise.
- Setting the reference value: That's normally the value of the
"other" entry of the pair--the one not currently being
evaluated.
- Inverting the ratios: Normally, one entry refers to the
antecedent term of the ratio, and the other entry refers to the
consequent term of the ratio. When evaluating the latter one,
the ratio should be inverted.
Pass the evaluation options to gimp_eevl_evaluate() using a single
parameter of type GimpEevlOptions, instead of using individual
parameters for each option. Add a GIMP_EEVL_OPTIONS_INIT macro,
used to initialize a GimpEevlOptions struct to the default set of
options. This would allow us to add evaluation options more
easily.
glib-genmarshal was rewritten in glib 2.53.4, and as of now (2.53.6)
it has a bug where it unconditionally generates marshaler bodies,
even for standard marshalers, even with --stdinc. This causes
libgimpwidgets to define and export g_cclosure_marshal_VOID__INT()
and g_cclosure_marshal_VOID__OBJECT(), which upsets defcheck, and
breaks the build.
Work around this for now by using --header --body when generating
the marshal.c files, which includes the prototypes in the source,
instead of including the header ourselves. This is the only code
path where the new glib-genmarshal doesn't generate bodies for
standard marshalers. Note, however, that this usage is deprecated,
so we'll probably want to change it back once it's fixed.
Initialize GimpColorHexEntry's text (to "000000") in constructed(),
instead of init(). Otherwise, it gets cleared during construction,
so that color entries set initially to black are empty.
This patch increases the LCH Chroma slider maximum value from 100 to
200 and also makes the Chroma slider properly display out of gamut
Chroma selections for any given Hue/Lightness combinations.
The current Chroma slider only runs to 100. But quite a few sRGB
colors have LCH chroma values that are greater than 100. For example
reddest red has a chroma of 107, and bluest blue has a chroma of 131.
So it's inconvenient to have to deal with a Chroma slider limit of
100.
Also, the current Chroma slider doesn't properly show out of gamut
areas on the Chroma slider. So for example picking a given LCH Hue and
then moving the Lightness slider doesn't allow to see which Lightness
value allows for choosing the maximum in-gamut chroma for the chosen
Hue.
Lionel N