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().
Use a GType for the PROP_SYMMETRY property of GimpImage, and create
a default "identity" symmetry for an image.
I still use a GimpIntComboBox but store the property value in the
user-data column because gpointer isn't a subset of gint.
Adds in libgimpwidgets:
- gimp_int_combo_box_set_active_by_user_data()
- gimp_int_combo_box_get_active_user_data()
- gimp_int_store_lookup_by_user_data()
- gimp_prop_pointer_combo_box_new() to create a GimpIntComboBox and
attach it to a gpointer property.
Thanks Massimo and Mitch for reviewing my code.
You can now set any paint tool to mirror painting relatively
horizontal/vertical axis or a central point (any combination of these 3
symmetries).
This has been implemented as a new multi-stroke core, where every stroke
is actually handled as a multi-stroke (default of size 1).
This is also the first usage of custom guides for symmetry guiding.
Current version has to be activated in the playground.
Fixed "gimpicons.c:30:45: fatal error: icons/Default/gimp-icon-pixbufs.c:
No such file or directory" after commits :
ee512b610dfa9e5b8f98
Fixed "ln: failed to create symbolic link ‘12/gimp-default-colors.png’:
File exists" by forcing new symlinking on creating get-default-colors.png
for Symbolic-inverted to prevent error during make.
Create GIMP_CONFIG_DEFAULT_(ICON_)?THEME in gimpguiconfig.h to set
defaults in a single place, except for libgimpwidgets/ which cannot
include from app/.
- GimpContext API and property
- a GimpDataFactory
- List and grid views with GimpDataFactoryView
- actions and a context menu
None of this is connected to the actual tool yet, or depends on
libmypaint in any way.
Add gimp_stock_set_icon_theme() which can be called at any time, also
before gimp_stock_init(), in which case we avoid setting the configured
icon theme twice on startup. Call it from libgimp/gimpui.c and
from app/gui/icon-themes.c so the app and plug-ins use the same
icon theme.
Images originally created by Jakub Steiner and Barbara Muraus as the
"Art Libre" icon set.
The contributor jEsuSdA later worked on it.
It will now be available in the new icon theme selection through
preferences.
Many icons/size are still missing but this first commit makes a start
for complementary work.
Switch the axes of the GimpColorSelect color area so that on the X
axis, we always modify the first of the two channels of RGB or HSV
that are edited here, and on the Y axis the second.
The common code relies on X11 pointer grabbing semantics, which does
not work well on OS X. An attempt using event taps also proved
problematic, in particular with regard to setting the mouse cursor.
This patch implements a fully separate code for use on OS X platforms.
It works by simply overlaying the desktop with big transparent windows
on which the mouse cursor is set and motion events are captured. Evil,
but it works.
Ever since 72617e42b, whenever the user generated a lot of mouse
input, we would constantly queue redraws to the rulers. These redraws
had a higher idle priority than updating the canvas, so we would
rarely get around to canvas updates, which made certain tools
(painting with dynamics, the blend tool) feel very unresponsive.
This fixes it by only redrawing the rulers if the mouse has moved
far from the last location, or if there are no idle handlers with
a priority above LOW.
We now avoid drawing rulers in the position property setter and use
gtk's region invalidation instead. Previously, we were basically
redrawing the ruler inside the mouse event handler, which is pure evil.
