even if we don't have private members (yet). Also make class padding 8
pointers in all headers. This commit moves nothing to private, it just
makes all headers consistent and adjusts .c files accordigly.
Add CSS names using gtk_widget_class_set_css_name(), remove styling in
code and instead do it properly in CSS, so far in the System theme.
All horribly incomplete but a start.
We have this problem with flatpak that the common directory
("/usr/share/color/icc") is not visible from inside the sandbox. With
proper permissions, it is actually accessible, yet the host's /usr is
mounted at /run/host/usr/.
Since sandbox systems are getting more common, we need to make this path
customizable. I am therefore adding a --with-icc-directory configure
option to change the default color profile folder at build time.
See: https://github.com/flathub/org.gimp.GIMP/issues/15
Last commit caused -xobjective-c to be passed during linking on
Mac, causing object files to be treated as source files. Add a
-xnone flag to AM_LDFLAGS, canceling the effect of -xobjective-c.
Additinally, add a -xobjective-c++ flag to AM_CXXFLAGS, so that we
can use Objective-C in C++ files on Mac, if we ever need to.
On Mac, pass -xobjective-c to the compiler through AM_CFLAGS, not
AM_CPPFLAGS, so that it's only used for C sources, and not C++
sources. In the latter case, it clashes with the -std=... flag,
spewing an error. Thanks, Partha :)
The symbol CGColorSpaceCopyICCData() is only available on macOS 10.12
and higher. We want GIMP to run from 10.9 onwards, so use the older
symbol CGColorSpaceCopyICCProfile() even though this one is deprecated.
Redo the entire thing again:
- Rename the values of enum GimpColorSelectorModel to include "MODEL"
- Change GimpColorSelector API from set_model() to set_model_visible()
so visibility of each model can be toggled individually and is not
exclusive any longer
- The GUI is back to what it was before, except that the "GIMP" page
now honors the model visibility and has a resonable minimum height
Quartz/macOS implementation for the color picker.
This is untested but I am trying to advance our 2.10 blockers by
implementing the base code for this feature. Please anyone with macOS
machine access, review and fix if needed!
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.
If the compiler supports destructors (which should cover at least
GCC and Clang), pair the call to babl_init() in gimp_widgets_init()
with a call to babl_exit() when the library in unloaded. This is
important in particular since the babl fish cache is constructed/
updated upon the last matched call to babl_exit().
libgimpwidgets now needs an initialized babl if color selectors are
used, call babl_init() in gimp_widgets_init(). It can be safely called
redundantly.
Commit 1e6acbd4e1 modified the
generated enum recipes to run gimp-mkenums from the source
directory, instead of the build directory, so that only the
basenames of the corresponding header files would appear in
the comment at the top of the generated files. This was a
mistake -- $(GIMP_MKENUMS) is expecting to be invoked from the
build directory.
Switch back to running gimp-mkenums from the build directory. To
avoid including the relative path from the build directory to the
source directory in the generated file, add a @basename@ production
variable to gimp-mkenums, which exapnds to the basename of the
input file, and use it instead of @filename@ in the recipes for the
generated enum files.
When regenerating an enum file, don't copy it back to the source
directory if it hasn't actually changed. This allows using a read-
only source directory where the enum header is newer than the
generated file, as long as they're not really out of sync.
OTOH, *do* touch the generated source-dir file even when unchanged,
in order to avoid re-running its recipe on the next build, however,
allow this to silently fail (which is harmless).
Last bit for now: allow GimpColorScales' spinbuttons to go further
than its color scales. Please review the new min/max values of the
individual channels.
Always use separate GtkAdjustments for the scale and the spinbutton,
and link them with a GBinding, either 1:1 or using logarithmic
transform functions.
This change also enables modifying both widgets' ranges independently
after construction, thus enabling the "constrain" feature also for
gimp_color_scale_entry_new().
Add LCH to the color selectors, patch by Elle Stone and myself.
- Extend enum GimpColorSelectorChannel by LCH channels
- Support them in GimpColorScale, GimpColorScales and GimpColorSelect
- Did not yet remove the HSV channels until things are working 100% ok
- Change drawing in GimpColorSelect to be much faster, to compensate
for babl_process() making the LCH modes pretty slow
- Clean up stuff in GimpColorSelect
This is WIP and should not be considered finished, biggest TODO is
displaying out-of-gamut values in GimpColorScales' spinbuttons.
We check them into git, so this makes it easier to keep them in
sync when using a separate build directory.
Case in point -- this commit also syncs a few enum files that went
out-of-sync with their headers.
One cannot just use the min/max values since the precision digits must
also be accounted for (as well as one additional character for the
decimal separator).
Current implementation is not perfect yet because GimpSizeEntry code
itself does not yet use gimp_unit_get_scaled_digits(). Moreover the
entry size could be updated when changing units (or the original size
be actually based of the bigger width considering every possible unit).
This is a bad hack that hardcodes a special case for
GIMP_TYPE_DESATURATE_MODE right into gimp_prop_enum_combo_box_new(),
we should think of something better if we get more special cases.
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
Remove all stock items added since 2.8, restore accidentially removed
ones, and rename the newly added GIMP_STOCK_* defines to GIMP_ICON_*.
(will move to having GIMP_ICON_* defines instead of magic hardcoded
strings for all icons).
Still using perceptual TRC - making 50% middle gray. This for all of 8bit and
16bit integer, as well as for floating point precisions. Also added a decimal point, to make use of more precision for both RGB and HSV entries.
If the store has invalid enum values the function segfaults,
instead of just ignoring them. We use -1 to represent separator
rows in the layer mode combo; if we end up adding icons to this
combo, we need it... not to segfault. Since this is public API,
it should probably be prepared to handle such uses regardless.
...(scroll up decreases the value)
Implement GtkWidget::scroll_event() and turn GDK_SCROLL_UP into RIGHT
and DOWN into LEFT. The default behaviour or good for scrollbars but
not for widgets where "right" == "higher value" == "up" like
GimpColorScale.
Commit 82737bf got rid of the only pieces of code where these icons were
used. Since they were never available in any version release of GIMP,
let's delete them from libgimpwidgets API as well.
These are file search paths, not vector shape paths, so the new icons
were using the wrong metaphor.
This reverts the only functional part of commit
92a9117ae0, we should
probably get rid of the icons too (they are now unused).
We completely replace GtkFrame's implementation here, and chaining up
caused an infinite loop in the widget layout apparatus in some cases.
This reverts 53f34ebc0b for this file.
Michael Natterer