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.
gimp_ruler_draw_pos(): when remembering the just drawn rectangle's
position, don't just unconditionally overwrite the previous position's
rectangle. Instead, if the previous position's rectangle has not been
cleared yet (has a non-zero size), remember the union of old and new
rectangle.
Why this only happened to the vertical ruler with statusbar off is
beyond my mind, it should have always produced artifacts.
Unrelated: make sure the idle function is removed if we decide to
immediately redraw in gimp_ruler_set_position().
... and GIMP_STOCK_BUFFER redefined to "edit-paste", half-reverting
commit cb7d93d (except we use standard Freedesktop icon naming instead
of the GTK stock name).
The gimp-buffer icon was indeed definitely looking like a typical copy
icon, which was missing, and this has priority over a buffer icon.
They are deprecated in GTK+ 3.x and cause tons of warnings, now we can
port calls to gtk_misc_set_alignment(label) to the new API and have
the same code in master and gtk3-port.
It's deprecated in GTK+ 3.x, so we get rid of some deprecation
warnings. Also, it has always only been a utility function that hides
what is really going on in the widget hierarchy.
Commit c6f1761 deletes a stock item id. But this is also part of our API
and cannot be deleted. Yet since the associated label ("_Edit") is
identical to the one for GTK_STOCK_EDIT, we can simply redefine it
to "gtk-edit".
Ideally we would also add a deprecation warning when this macro is used,
but I can't find a good way to add deprecation on macros.
so we can potentially ship profiles and they will be found reliably,
and users can store profiles in their gimpdir. Still parses the old
uri-based locations.
... standard icon names and GTK+ icon names as second choice.
We should only use GIMP specific icon names as last resort, when there
is no standard or GTK+ names dedicated to the function.
This is made possible thanks to commit 3cc77b0.
s/gimp-document-recent/document-open-recent/
s/gimp-indent/format-indent-more/
s/gimp-next/go-next/
s/gimp-previous/go-previous/
s/gimp-save/document-save/
s/gimp-save-as/document-save-as/
s/gimp-revert/document-revert/
s/gimp-open/document-open/
s/gimp-document-recent/document-open-recent/
s/gimp-quit/window-close/ ou s/gimp-quit/application-exit/
s/gimp-warning/dialog-warning/
s/gimp-edit-clear/edit-clear/
s/gimp-justify-.*/gtk-justify-.*/
s/gimp-font/gtk-select-font/
s/gimp-color-palette/gtk-select-color/
s/gimp-cancel/gtk-cancel/
Even though many documentations will tell of $XDG_DATA_HOME/color/icc/,
some programs actually store color profiles in $XDG_DATA_HOME/icc/.
This is at least the case for GNOME color management.
Test it after $XDG_DATA_HOME/color/icc/ but before $HOME/.color/icc/.
add
gimp-justify-block
gimp-justify-center
gimp-justify-left
gimp-justify-right
patch
gimpicons.c
gimpicons.h
to get active and replace gtk-justify-*
'gimp/app/tools/gimptextoptions.c: box = gimp_prop_enum_icon_box_new (config, "justify", "gtk-justify", 0, 0);
must be patched
Honor them in gimp_widget_get_color_transform() and make them
configurable in prefs. The code and GUI avoid the negation in
the lcms "NOOPTIMIZE" flag.
to gimp_color_config_get_simulation_color_profile(), along with
various internal "printer" strings. Also reduce the number of
user-visible "print" stuff from the preferences color management page.
Use cmsFLAGS_NOOPTIMIZE only for actual image buffer or single color
transforms, but not for previews or the image display. Makes things a
lot more responsive again.
Rather than just discovering them by chance, a simple grep and some
search and replace are much more efficient! :-)
Cleaning only done on C and automake files.
and update their color transforms with the new monitor's color
profile. A widget is considered changing monitors when its toplevel
window's center crosses, in order to let widgets within one window
have consistent colors.
Which installs a callback that behaves as if GtkWidget had a
"monitor-changed" signal. Additionally, moving widgets around between
windows is handled automatically.
symbolic-scalable
add 'pixel-perfect' 24px vectorial twins (as replacement for 22px)
gimp-prefs-folders-dynamics
gimp-prefs-folders-environ
gimp-prefs-folders-fonts
gimp-prefs-folders-gradients
gimp-prefs-folders-icon-themes
gimp-prefs-folders-interp
gimp-prefs-folders-modules
symbolic-scalable & color-scalable
add new icons
gimp-color-cmyk
gimp-color-water
patch
color-selector-cmyk.c
color-selector-water.c
gimpicons.c
This is the first patch to solve Bug 759904
many more have to follow
Thanks to Jehan for the assistance
Now that more and more widgets are color managed, we need transforms
for all of them. Creating them is very expensive.
The new cache returns the same transform for a combination of (config,
src_profile, src_format, dest_format) and invalidates itself
automatically on config changes. The number of transforms goes down
from potentially hundreds to a handful, and the cost of a config
change from many seconds to virtually instant.
which encapsulates a cmsHTRANSFORM and does all the pixel format
conversion magic. It has API to create transforms and proofing
transforms, and to convert pixels arrays and GeglBuffers.
Before, each place which has a transform had to keep around the
transform and its input and output Babl formats, and had to implement
lots of stuff itself. Now all that lives in GimpColorTransform,
removing lots of logic from many places, and pretty much removing lcms
from the public API entirely.
This removes including <lcms2.h>, LCMS_LIBS and LCMS_CFLAGS from
almost all directories and potentially allows to replace lcms by
something else.
If a config is set, apply its settings when drawing the preview's
pixels. This is preparation for fixing:
Bug 467930 - color selectors are not color managed
Bug 556608 - Monitor color profile is not applied to filter preview
... when the button is clicked
Previously, the old color retained its previous value, so when the color
selection dialog was canceled, the button's color would go back to a
potentially outdated value, instead of the color it had when it was
clicked (for continuously-updated color buttons, at least.)
Add the right action buttons, enable overwrite confirmation, and add
user-writable folders to the shortcuts pane. Also use the right API on
OS X instead of hardcoding /Library and ~/Library.
Its API was too limited, and adding parameters for what we need next
would be equally random. It's a rarely used and mostly internal
widget, so simply use g_object_new().