Current defaults are from another time. Acceptable defaults could be
common screen resolutions. 1366x768 is apparently the most common
(according to various stats on the web), but since we target advanced
graphics artists, let's go for 1920x1080, which is the second most
common resolution, also known as Full HD.
For unstable builds, let's have at least one odd number, uncommon ratio
and higher values, encouraging tests with less common numbers and bigger
images. I chose 2001x1984. Feel free to update to any other funky values
following these "unstable" rules.
... with something more suitable.
72 PPI is from a time where people thought this was a common screen
resolution. This is not the case nowadays, and anyway images targetted
for screen display should not bother with PPI resolution at all, only
with actual pixel dimensions.
PPI resolution is more useful for printing. And for this case, 300 is
quite an accepted OK value for most cases. So this is likely a better
default for GIMP.
There is no reasons not to translate the "occurs" text which will be
in the color names in palettes extracted from images. It indicates on
how many pixels a given extracted color was occuring. We should also
translate the full string (not just "occurs") since some language will
have to reorder words, and may even use different bracket characters.
So I also add a translator comment to make sure the translators get
what the %s and %d stand for in this string.
Introduce virtual function GimpViewable::is_name_editable() and class
member "gboolean name_editable" for the default value. Default to
FALSE and only return TRUE if the name can actually be edited by the
user.
When attemting an edit, check the new API and beep instead of starting
the edit.
The new properties are "virtual", they share their storage with the
"precision" property and are not serialized, they are meant for GUI
property widgets.
...instead of transforming it
Add gimp_matrix3_will_explode() which determines if a transform
matrix will blow up something in a rectangle to infinity, and use
the function so set both the GIMP and GEGL code paths to clip the
transform to the input size.
Don't migrate any paths from an older gimprc. This unfortunately kills
all manually added paths, but makes sure all paths default to the
files of the new GIMP version, could be improved by parsing the path
and replacing only the right elements.
Add color management to GimpDrawableFilter and GimpFilterTool, GEGL
ops applied to drawables can be applied in color managed space
now. Sadly, this is very slow, so disabled by default.
I'm sure the profile guessing based on the operation's format doesn't
always work, but this general bug counts as fixed now.
Fix cursor rotation jump when tablet pen is tilted horizontally.
This changes to the correct values for the special case of tilt_x == 0.0.
Reviewer (Jehan)'s note: computing the convergence of the tilt function
in the `else` block, when tilt_x approaches 0, tilt value indeed
converges to 0.25 with tilt_y > 0 and 0.75 (or -0.25 which is the same)
with tilt_y < 0.
gimp_drawable_equalize(): is mask_only is FALSE, suspend the selection
around gimp_drawable_apply_operation() so the operation affects the
entire drawable.
Add property "color-tag" of type enum GimpColorTag to GimpItem so all
layers, channels and paths can be tagged with a color.
For interoperability, use the color list from Krita which is a
superset of Photoshop's colors.
Features a "Color Tag" submenu in the layers, channels and paths
menus, a row of color radio buttons in the properties dialogs,
undo and PDB API.
As a side effect, some common code is now factores out into
items-actions.[ch] and items-commands.[ch] which adds visible, linked
and lock actions for layers and channels.
This fixes restoring of brush properties (size, spacing angle etc.)
from presets, which was utterly broken before. The fix consists of
two parts:
- In tool_manager_preset_changed(), always copy the brush properties
again after setting the preview on the tool options, in order to
override brush properites that get copied from a linked brush when
that brush gets set on the tool options.
But no amount of copying stuff again and again would help without:
- In gimp_context_set_by_type(), don't use g_object_set() to set the
object (brush, pattern etc.). Instead, build a GValue and call
gimp_context_set_property(). This may seem odd, but avoids a
g_object_freeze_notify()/thaw_notify() around the g_object_set(),
which was causing "notify" to be emitted at the very end, after
everything this context change has triggered. GimpContext is an
essential core object and there is an expectation of a reasonable
order of signal emissions and callbacks being called. The "notify"
at the end was keeping any callbacks of the context's "foo-changed"
signals to override anything an earlier callback had done, if a
"notify" callback was overriding that overriding again.
This was probably the reason for a lot of odd behavior observed over
the years. In fact, I have been searching for this for at least 5
years.
...are not submitted to respective Tool Options sliders
Treat brush angle and aspect ratio like all other paint options values
that can be linked to brush defaults and take their default values
from the brush. They were special casing their defaults to constants,
and GimpBrushGenerated was adding the passed dynamic radius and aspect
values to its own. This was totally incomprehensible.
Now GimpBrushGenerated's transform_size() and transform_mask()
implementations just translate between these APIs value ranges and the
brush's own value range and only use the passed values (not the
brush's native values), which makes the editor <-> tool options
interaction and the painted brush shape predictable.
Also connect the active brush's property notifications to the paint
options properties, so the paint options follow a brush edit live if
the respective "linked" toggles are checked.
And some cleanup.
Add a GimpFillType argument to GimpItem::resize() and fill type
widgets to the canvas and layer resize dialogs. Fill the new parts of
the drawable according to fill type in gimp_drawable_resize(). Make
sure places that need the old behavior get GIMP_FILL_TRANSPARENT
passed by hardcoding it in the GimpItem::resize() implemetations of
channel, mask, selection etc.
We didn't convert patterns to the target drawable's profile when using
gimp_drawable_fill().
Introduce gimp_drawable_fill_buffer() as single filling utility
function that does things right and use it from gimp_drawable_fill()
and gimp_fill_options_create_buffer().
making its external API "complete". Remove the redundant
"new_base_type" and "new_precision" from the internal (vfunc) API (the
Babl format has the same information).
Don't change the paste_type to NEW_LAYER just because there is a
complex thing in the clipboard. Instead, honor the request to paste
FLOATING or FLOATING_INTO and reduce the pasted thing to a simple flat
layer. Also remove the message and paste_type change from edit_paste()
in edit-commands.c, it had the same purpose, just with a user
notification.
In order to paste the full layer one needs to explicitly invoke
"Paste as new layer" now.
It still changes the paste_type to NEW_LAYER if it's impossible to
attach a floating selection to the target, the menu item was simply
insensitive before.
They have a size of 1x1, treat them a image-sized when pasting layers
on top of them.
(my commit below was also about gimp_edit_get_paste_offset(), not
about gimp_edit_paste() as the log claims)
Use the newly added clipboard for entire images to copy/paste layers
(we only create single-layer clipboard images, and use only the first
layer of any recieved image, the layers can be arbitrarily complex
though):
- change gimp_edit_copy,cut,paste() to return/take a GimpObject
that can be a GimpImage or GimpBuffer
- cut/copy the whole layer if there is no selection
- always paste layers as new layers, not floating selections
- always paste news layers on top of the active layer, where
we would attach a floating selection
- add enum GimpPasteType { FLOATING, FLOATING_INTO, NEW_LAYER }
- add GimpPasteType parameter to gimp_edit_paste() and handle all
three cases there because there is now a lot of common code
involved
- change all callers accordingly, use only legacy buffer pasting
from the PDB for now
...when threshold > 0
Add an "Antialias" toggle to the bucket fill options and set it on the
GimpFillOptions. In gimp_drawable_bucket_fill(), pass it to
gimp_pickable_contiguous_region_by_seed() instead of always defaulting
to TRUE.
The position of the toggle and its huge tooltip may need some
adjustment.
Add GimpFillOptions and GimpStrokeOptions to GimpDialogConfig and use
them in the Fill/Stroke Selection/Path dialogs and for the "with last
values" commands. Add GUI for them to Preferences -> Dialog Defaults.
This requires most of the stuff in my last few commits, and some
more changes:
GimpFillOptions is a GimpContext which has all sorts of connections to
everything, including a Gimp pointer. Hack around in GimpDialogConfig
to add a Gimp property, and add "gimp" parameters to quite some GimpRC
functions. Treat the Gimp* as a GObject* in all public API because
core/ stuff is not known in config/.
Move fonts, data factories, document list, paint methods and user
context creation to gimp_init() or gimp_constructed() so that most
members are created when gimp_new() is done. This does not load any
data earlier, it just makes sure that all containers exist when
gimp_load_config() is called. It's also cleaner and less fragile,
and initialize units in gimp_init(). This was completely
over-engineered but in the end boils down to a bad hack that needs a
static "the_unit_gimp" pointer anyway, so let's at least have the hacks
in one file.
... 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/
Separate clearing/creating the image's cached color transforms from
clearing/creating its color profile. Clear the transforms when the
color profile changes, and when image type or precision change. Create
the transforms only on demand, so clearing them multiple times doesn't
trigger any redundant (and expensive) transform creations.
As proposed by Mitch. This completes first renaming attempt (commit
08ffc10) with even less ambiguous names.
"horizontal-axis-position" and "vertical-axis-position" are now
respectively "mirror-position-y" and "mirror-position-x".
"Horizontal position" and "Vertical position" could be mistaken as
meaning respectively the x and y coordinates, hence the vertical (resp.
horizontal) guide's positions.
The more accurate "horizontal-axis-position" and "vertical-axis-position"
namings are less misleading.
Mitch gets a better idea to deal with soft limits (i.e. min/max values
different from the property min/max) applied to a spin scale created by
gimp_prop_spin_scale_new().
So let's just remove the current implementation (using locale data on
the GimpConfig object). The symmetry spin scales are back with crazy
huge maximums, which makes quite a horrible GUI, but this is only
temporary until Mitch commits his new implementation.
... in gimp_drawable_bucket_fill()
gimp_drawable_apply_buffer() already takes the selection mask into
account. Intersecting the selection mask with the fill region
prior to that leads to wrong (too low) alpha values, in general,
when partial selection is involved.
This commit eliminates the intersection of the fill region and
selection mask data before the apply_buffer() call, although it
does calculate the intersection of their bounds, to avoid
processing regions that won't be visible anyway.
Previously, activating quick mask while the selection was empty
would use the image's channel format for the mask, instead of its
mask format; these formats are different for sRGB images.
Currently a GimpSpinScale created with gimp_prop_spin_scale_new() will
use the associated property's lower and upper values.
Unfortunately these generic values may not be always relevant and we
may want to construct a spin scale UI adapted to the current image.
For instance, several symmetry painting have a x/y property which has
to stay within the image's dimension, but changing the property's lower
and upper values would affect the symmetry on the class level (i.e. for
all similar symmetries on all images).
Let's allow setting data on object with key "property-name:min|max" to
provide locale min/max values specifically for this object.
This is used only on the symmetry dock for now, but could be used as
well on GEGL op UIs.
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.
Now all previews and the display shell connect to the color config
itself, there is no need any longer to connect to the global color
config's "notify" any longer from GimpImage. Also, the settings there
are for display purposes only, so nothing in the image itself needs
to be notified of the config change.
Which creates a buffer from GimpFillOptions that can be applied to a
drawable. Eliminates three slightly different copies of the same
code. Also adds to the color history for each color fill, we missed
two places before.
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.
which isn't really for "picking", but it just fits too nicely into
GimpPickable to not put it there.
Also add utility function gimp_pickable_srgb_to_image_color() which
takes a "real" (sRGB) GimpRGB value, transforms it to the pickable's
colorspace and puts it into an "image color" GimpRGB.
...when a color profile is active
Add GimpPickable::pixel_to_srgb() which puts a picked raw image
pixel into a GimpRGB. Default to gimp_rgba_set_pixel() but implement
pixel_to_srgb() in GimpLayer, GimpProjection and GimpImage and
run the pixel through gimp_image_color_profile_pixel_to_srgb().
Not only the logic was broken, a local variable was also shadowing the
"dest_profile" variable and preventing the broken logic to be applied
at all. Double fail.
They are unreliable because every type checking cast discards them,
they are useless anyway, visual clutter, added inconsistently, and
generally suck. Wanted to do this a long time ago, it was a bad idea
in the first place.
Remove the filter area calculation code from gimp_image_map_apply().
Instead, automatically update the area when adding the filter to the
drawable, and when the selection changes. Also, connect to the
drawable's "removed" and remove the filter when the drawable gets
removed from the image.
Reduces members and all sorts of duplication and is a much better
abstraction of what it does. Also make it a lot smarter and
self-updating, chop up the apply() function and move its parts where
they belong. Also, it's now aware of selection changes and does the
right thing.
Don't abort GimpImageMapTool on selection changes, it now nicely
handles that.
Add "gboolean color_managed" and "GFile *color_profile" to
GimpTemplate. Add a toggle and profile combo to GimpTemplateEditor.
Honor the new template properties in gimp_image_new_from_template().
Using a GFile property instead of a GIMP_TYPE_CONFIG_PATH is
preliminary, see the previous commit. I'd like to use GFile more
directly when dealing with config files, this is for testing that.
isntead of the feather parameter, and pass it to
gimp_gegl_apply_border().
Make the necessary changes to the rest of the code to maintain the
current behavior.
Mass parameter alignment changes to gimpchannel.h. Sigh #2...
instead of the feather parameter.
The BORDER_STYLE_HARD and BORDER_STYLE_FEATHERED styles are implemented
using the "gimp:border" operation, as was done previously. The
BORDER_STYLE_SMOOTH style is implemented by performing a "gimp:grow" and
a "gimp:shrink", and subtracting the shrunk image from the grown image
using "gegl:substract".
gimp_channel_border() is modified to pass either BORDER_STYLE_HARD or
BORDER_STYLE_FEATHER, depending on its feather parameter, to maintain
the current behavior. The next commit replaces it with a style
parameter as well.
Mass parameter alignment changes to gimp-gegl-apply-operation.h. Sigh...
Will be used as a parameter to control the behavior of
gimp_channel_border(), and the corresponding "Select -> Border..."
action, instead of the feather flag.
Can be one of:
- GIMP_CHANNEL_BORDER_STYLE_HARD: Current behavior, unfeathered.
- GIMP_CHANNEL_BORDER_STYLE_SMOOTH: Smooth border, better handling
partial selection, implemented as explained in the next commit.
- GIMP_CHANNEL_BORDER_STYLE_FEATHERED: Current behavior, feathered.
This doesn make any difference because a NULL profile would do the
same, but it's safer to pass the actual profile instead of relying on
the magic meaning of NULL in the call to
gimp_layer_new_from_gegl_buffer().
Don't use the (wrong) global display color managment switch to
determine whether or not to convert the buffer to the image's
profile. Use the image's "is color managed" switch.
We used to depend on the global color management OFF switch from
prefs, but that's meant for display color management. Now, don't do a
profile transform if the target image's color management is disabled.
The bottom visible layer must be rendered in normal mode because
every other mode on top of nothing renders nothing.
Before, we would display a stack's last layer in normal mode, which
was a braindead attempt to make the layer stack look like in 2.8. Now
we set GimpFilter's "is-last-node" property the right way by looking
at the filters' visibility in GimpFilterStack.
instead of just a boolean "convert_profile". This takes the logic to
figure the right target profile out of gimp_layer_convert_type(), it
can't possibly know everything about how to convert anyway, and having
the logic in the callers conveniently splits it up and distributes its
parts to the places they belong.
This commit should cause no behavor change and is just preparation for
fixing bug 765176.
g_free the lru 'unit' when removed from the cache
and keep track of the list length and last item
while looking for a duplicate already present in
the cache.
... to avoid long pause on start
On non-Linux operating systems the fontconfig cache is often not
initialized by default. The first time GIMP was launched, this led
to a non-responding application, confusing many users.
The initialization of fontconfig has now been moved to a separate
thread. The main thread will wait for this fontconfig thread to
complete, regularly pulsing the UI.
This patch was partly based on an earlier patch by Tor Lillqvist.
We needed to get rid of these images at a later point. This fixes (at
least) a crash seen on Mac OS X, where the images were being unreffed
before the last GimpActions (with a reference to the image) were
unreffed.
Plus, implement GimpColorManaged so the view renderer can ask the
buffer for its profile.
This also fixes colors in cross-application copy & paste when GIMP
is the source.
Change gimp_viewable_get_[new]_preview() to return buffers of the
image's and layers' colorspace, but in u8. This way layer and image
previews can transform them correctly to the display profile.
Note: this makes plug-ins receive thumbnail buffers in that
pixel format too.
Also change gimp_viewable_get_[new]_pixbuf() to always return sRGB
buffers that can reasonably be put to screen directly, or put into DND
buffers. This is at least more correct now.
Keep around transforms not only to/from the image's pixels to
"R'G'B'A double" (GimpRGB's format), but also to/from "R'G'B'A u8"
(GdkPixbuf's format). Also add API to access all cached transforms
and the Babl formats expected when calling lcms.
...for the preview?
Change to allow for split previews in all 4 directions. Remove the
direction controls from the filter dialog, and instead implement
shift- and control-clicking on the split guide to switch
original/filtered sides, or orientation.
Rename profile constructors to say "d65_gray" instead of just "gray",
"srgb_trc" instead of "srgb_gamma", and drop the "srgb" from
"srgb_linear" because we now say "d65". This should be a naming scheme
that doesn't conflict with whatever future functions we might add.
After discussion in IRC some weeks ago give the Selection-Flood items
the more meaningful name Selection-Remove holes.
modified: app/actions/select-actions.c
modified: app/core/gimpselection.c
Pass the display scroll offset down to gimp_cairo_stipple_pattern_create()
and set it as offset on the created cairo pattern, so stipple patterns
look the same no matter how the display is scrolled.
Themes from 2.8 and before are not fully compatible with 2.10.
In particular, embedded icons would not work and you would end up with
the Symbolic icon theme (light colors), which may not work well with a
custom theme.
It is better to reset to the new defaults upon migration and users can
still try and configure the theming afterwards if they wish.
For selections, it's different from gimp_edit_fill() because it
ignores the selection while filling, just as stroking does. Currently
unused, stay tuned...
and remove lots of labels from calls to gimp_prop_foo_new(). Also
had to manually remove some unwanted labels that are now added
automatically, fixes bug #761880.
I am still not sure whether custom guides should follow snapping rules.
Yet I could easily imagine you could want some normal guides with
snapping and in the same time symmetry without snapping to axis of
symmetry. So for the time being, let's disable snapping to custom guides
all the time and see if logic could be improved later.
This is not ideal since the scale widget is crazy huge, thus
impractical, but the solution used on properties of other symmetries
(updating min/max of the class property) is wrong since it applies to
the whole class.
For the time being, it avoid setting obviously bad values until we
figure out the ideal automatic UI construction.
Remove GimpSymmetry::get_settings() and instead tag the properties that
should have a GUI with the GIMP_SYMMETRY_PARAM_GUI flag. Also use plain
g_object_class_install_property() because that allows for separate nick
and blurb. Finally, use gimp_prop_gui_new() to generate the GUI,
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.
With gimp_guide_custom_new(), you can create a custom guide with a different
style on canvas (other pattern/color/width). A custom guide won't be saved
and could be used, for instance, for specific GEGL op guiding.
While the tool should definitely use the new op, we want the code in
gimpdrawable-blend to use the old one for compat reasons. The new op
will be exposed via a separate pdb call in the future.
This reverts commit 8af3fec689.
Old themes should not be copied over to the GIMP 2.9/2.10 config at
first launch since they won't be compatible anyway. Let's go the less
painful way by dropping old themes rather than trying to salvage themes
which we know will be broken by design.
When checked, diagonally neighboring pixels are considered connected
when calculating the affected area.
This commit also adds a corresponding diagonal_neighbors parameter to
gimp_drawable_bucket_fill(), and modifies the callers, other than the
bucket fill tool, to pass FALSE for this parameter, to retain the
current behavior.
Alexia Death