… in the gimp-release file.
This will be useful to disable the update check for the Windows Store
even though we use the same build as the installer. All it will take
will be to append the line `check-update=false` to the file
`share/gimp/2.10/gimp-release` and it will behave as though the update
check is disabled (even though it is actually built-in).
- Slightly nicer layout for the checkboard color widgets.
- Also set the 2 color widgets insensitive when the check type is not
GIMP_CHECK_TYPE_CUSTOM_CHECKS.
- Default the custom colors to the same colors as the basic default
grayscale. I mean, red and blue defaults are fun and all, but that's
like radioactive colors burning the eyes! Ahahah!
- Unlike the gimp-2-10 commit (cf. !274), on the main dev branch, use
the new GimpLabelColor widget.
Fixed Conflicts from !274:
app/dialogs/preferences-dialog.c
Reviewer (Jehan) note: cherry picked from MR !274. Still deciding
whether this will be pushed to gimp-2-10 branch too.
Fixed Conflicts from !274:
app/dialogs/preferences-dialog.c
app/display/gimpdisplayshell-draw.c
app/plug-in/gimppluginmanager-call.c
libgimp/gimp.c
libgimp/gimp.h
libgimpwidgets/gimppreviewarea.c
libgimpwidgets/gimppreviewarea.h
libgimpwidgets/gimpscrolledpreview.c
When you change a settings in Preferences which requires a restart of
GIMP, the current list was pretty ugly. I am still not fond of the popup
but at least now the list formatting is slightly better:
- Use a unicode bullet point character in UTF-8 encoding (since
gtk_message_dialog_new() expects UTF-8 input) on each list element,
instead of just writing them without any kind of formatting.
- Use the "nick" of the changed config, not the name. The "name" is an
internal string which is really not meant to be viewed by people,
while the "nick" is more like a short human-readable name or title,
exactly what we want to show here.
Some strings might be generated during query() call, in particular all
strings related to procedure parameters. The core will only know the
localized version at query() time, so you could end up in situation with
the core showing you the wrong language. This can be reproduced in the
Procedure Browser when it shows localized procedure data: when you
change the language and restart GIMP, if the plug-ins aren't re-queried,
then it will still show the localization of query time.
Note that it doesn't matter on plug-in side, i.e. anything in the run()
call is properly localized, included the plug-in GUI using the same
procedure parameters for widget labels or tooltips. Only the "vision" of
the core is stuck at what it got when the plug-in was last queried, and
until the next update of the plug-in.
Adds the new configuration option "drag-zoom-speed" to adjust the rate
at which mouse movement can zoom the canvas, ranging from 25% to 300%
of the base rate and applying to both drag-to-zoom modes.
This option can be found in the preferences dialog as:
Image Windows -> Zoom & Resize Behavior -> Drag-to-zoom speed
Adds a new configuration option "drag-zoom-mode" to choose whether to
zoom by distance of movement (newly added) or by duration of movement
(previous behavior) when zooming via dragging the mouse, defaulting to
distance.
This option can be found in the preferences dialog as:
Image Windows -> Zoom & Resize Behavior -> Drag-to-zoom behavior
- Rename "Mouse Pointers" frame to just "Pointers". It's not just about
mice but all input devices.
- Move the "Pointers" options from "Image Windows" to "Input Devices"
tab in Preferences. It looks to me it's more about how you configure
the device pointers than anything really image window-related.
- Move the paint tool options in their own frame "Paint Tools" to really
differentiate the generic pointer options from the ones specific to
paint tools. This frame is added side by side to the "Pointers" frame
to hopefully underline they are related.
I'm still annoyed by the fact that if you uncheck both the "Show brush
outline" and the "Show pointers for paint tools", it will actually show
a big crosshair in such case. I can understand the logic (not to end up
in a case with absolutely no indication of your pointer position). But
then shouldn't we rather forbid unchecking them both at once? It would
be clearer IMO. On the other hand, are they people who like this big
crosshair and use this?
Other thing I was annoyed about was whether you would not want to have
the "Single dot" only on paint tools. But as Aryeom told me, maybe let's
just try it like this and see if people ask for a double option (pointer
on paint tools vs. pointer on other tools) as it is already very
complicated settings as it is. I mean, at some point, I even thought
about a per-device pointer. I also studied the possibility of detecting
whether you are on a display-tablet (when you are more likely to want an
unobtrusive pointer) or not (then you may be very annoyed each time you
can't even spot easily your pointer on screen). But GTK doesn't give
this later information, and as Carlos reminded me, even a display-tablet
can be mapped to another display, so even if we could detect a
display-tablet, it would not mean it is reliable information for making
a decision on whether we want a light pointer.
Since we are pre-processing anyway the AppStream metadata file (because
appstream-glib doesn't pass unknown XML attributes, cf. a previous
commit), it does feel silly now to continue loading the file at runtime
too. Let's just pre-process more data into the constructed C files, i.e.
get the introduction paragraphs and the change items too.
The only other remaining advantage of appstream-glib was that it was
handling the localization but since we also have these localized strings
in our gettext files, we can as well translate with gettext as any other
strings and it works just fine.
It will also get rid of any packaging issue, forgetting to package the
metadata file (as we had on the Windows installer, and still have on the
macOS package). Now it will just always work because data is internal.
The changes include:
* A popover will be displayed on tool buttons and relevant property
widgets.
* Now the welcome dialog gives focus up to its parent window because
really the whole focus styling issue in GTK is a bit maddening. The
colors are all faded, the popover widgets are barely visible, and so
on.
* Timing is tweaked a bit to give more time reading the popover tips.
… blinking it.
This will be necessary to demo new features available only in some
situations. E.g. a new option in line art detection mode of bucket fill
would require said mode to be enabled.
First I strip now every pieces of text. What it allows it to span the
script elements for instance on several lines, indent them and all that.
The second thing is that since all the dockable start with "gimp-", we
may as well allow use shorter names (both are allowed). Same for tool
(which we special-case), all the tool buttons ID start with "tools-"
since we reused the action names. So let's just allow the shorter
versions.
Finally I create a new gimp_blink_toolbox() which is a specialized
gimp_blink_dockable() for the toolbox in particular. I also move there
the whole code about selecting the right tool.
Make a different bullet points for items with demos and items without,
and add an info text explaining you can click on items with the right
bullet point to get a demo.
Hopefully it will fix the following CI errors:
> make[4]: *** No rule to make target '../../tools/generate-welcome-dialog-data.py', needed by 'welcome-dialog-data.h'. Stop.
I thought using relative paths was fine too here, but I might have been
wrong (even though it worked locally).
Even when using a GtkListBox, it's just prettier and clearer when having
a text list with dots IMO, especially since some text might wrap on
several lines. Let's just go with that.
The idea is to add some "demo" attribute to a list item inside the
<release> tag, since we already decided that (for now at least) we'd
keep a strict "intro + list" logics, as we did until now.
This demo attribute uses an internal format to specify successive
widgets to blink (like a demo path towards a feature). For now, what it
allows is:
* raise the toolbox, select a tool and blink the tool button.
* raise a dockable, blink any widgets in there.
Now it is still limited and needs to evolve. In particular:
* What happens if the blinked tool button was explicitly removed from
Preferences? Should we re-add it for the demo? And once done, should
we remove it again? Then should we select back the tool previously
selected?
* What happens if the dockable widget is not visible? Should we allow
changing the settings to be able to demo correctly the new/changed
settings? Should it be temporary? If temporary, it can be annoying as
you'd still have to look attentively the demo to find back the path to
the new settings. If not temporary, some people may dislike we touch
their settings.
* What if docks are hidden? Should we unhide them, then hide them back
after demo time?
Also regarding the implementation: originally I wanted to just grab the
demo attribute directly from the AppStream metadata file, but I realized
that appstream-glib cleans out unknown attribute from the XML. I could
then simply parse the file with a generic XML parser, but I found
simpler to pre-parse it into a header built within GIMP. I still use
appstream-glib at runtime as it takes care of localization for us
(though in the same time, we also have the localization in the main po
files, so maybe we could just embed the release note strings as well).
See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
What it means is that we will be a bit strict over our <release>
formatting which will have to always be a <p> introduction followed by a
list of items. This is what gimp_appstream_to_pango_markups() expects.
Since so far, this is how all our <release> tags were formatted anyway,
this is not too much of a problem.
Note that I keep the less strict gimp_appstream_to_pango_markup() and
use it for extension's appstream description as we will have no control
over these.
The main reason for this new rule and new display of our release notes
is that I am going to add the ability to click independent release items
so that people can get "blinking" indications of what changed when
relevant.
For some reason, our flatpak is moving the appstream file elsewhere,
after installation (since all our scripts explicitly install it under
metainfo/).
So in flatpak, it is in /app/share/appdata/ (i.e. $DATADIR/appdata/).
This is not right and should not be done by the flatpak system, but
let's still verify this other location as it is legacy so it would not
be totally impossible that some distributions do something similar when
packaging GIMP.
See also: https://github.com/flatpak/flatpak/issues/4775
As Jacob reports in #6445, on a big-size monitor, the dialog is just too
big, this can be seen in particular with all the space left between info
text. Trying a new logic where I simply leave the dialog to be
allocated, then once I get its size, I generate an image roughly this
same size. This should avoid overly big images.
Thanks to Liam for the fix/feedback on IRC. There was a typo (s/if/it)
and some better wording proposition.
s/You can call if again/You can show it again/
I realized the "recent-contributor" template was checking
`last-active >=2 and minor version >= 8`. Because of the second part of
this test, anyone with a last a last-active value of 3.0 was ironically
not included as recent contributors!
Meanwhile, I am bumping the definition of recent as 2.10 and over
(rather than 2.8 and over), for GIMP 3.0 release. Last thing, I am now
sorting by descending last-active (so contributors in GIMP 3.0 are shown
first).
There is really nothing specific to the core application, it is quite a
generic widget, so it would be nice for plug-ins to be able to use this
widget.
The 3 available formats are: simple text search, regular expressions and
glob patterns (cf. previous commit). I did a small step back from
previous commit by getting "is-pattern" property back in GimpItemList
instead of having this case as a value of GimpSelectMethod. The reason
is that it would render a useless value in the Preferences combo box.
Text search is the default.
Saving a thumbnail is closely related to the other metadata preferences,
but so far this was the only one that didn't have a preference for a
default user value.
This commit adds a preference in the metadata section where a user can
select whether thumbnail saving is enabled by default or not.
Fix the search for previous folders, which was broken as it was
specifically expecting 1-digit numbers so far.
The differences of the GIMP 3 config import are:
- update sizes and positions in the sessionrc according to the scale
factor, because GTK2 doesn't have scale support. It means that, e.g.
with a 2× display, all sizes and positions in GIMP 2.x must be divided
by 2 (otherwise the first thing many people will get when testing GIMP
3 for the first time is an off-screen window).
Of course, I even wondered if it would not be nice to just drop the
sessionrc altogether and start with a nice blank slate, but then you
also lose the opened dock and their organization and some settings
(such as whether you chose single or multi window mode, etc.).
- scripts/ and plug-ins/ are not imported. Probably makes no sense so
far as they would end up broken (but maybe it's not true for all
script-fu scripts?).
Since the recent changes to add template ability, there are just too
many widgets stacked up vertically. Let's use a little better the
horizontal space.
To do this, I moved the preview on the right side of the "Canvas Size"
and "Offset" number fields, and the "Center" button just below it.
Let's move the g_date_time_format() to the inner block when it's
actually used, hence also make sure we allocate and free at the same
code level, which is a better practice to limit leaks.
Reported by Massimo.
As explained in GTK docs, size groups are referenced by every internal
widget hence can be immediately unref-ed after we added widgets in it.
In the end, when the widgets are destroyed (thus removed from the
group), the group will end up freed too.
Reported by Massimo.
In Linux, I never paid attention to it because it was already working as
expected (i.e. Ctrl-n followed by Enter for instance would directly
create the image), but when testing GIMP on Windows for the installer,
these last few days, I realized that hitting Enter when focus was on the
dimension entries was doing nothing. Having to move the pointer to click
a button on Windows was frustrating. So let's make OK the official
"default response" directive for this dialog.
In some cases, in particular for actions generated from plug-in
procedure right now, we were displaying the reason of the insensitivity
(typically right now, only the drawable type is cited). This was done by
appending the reason to the tooltip, separated by 2 newlines, which
resulted in extra ugly design, no nice way to style this info directly
(with pango for instance if the widget display allows it, or on a
separate info widget in a possible future, or whatnot).
Also it would mean that the action search could match a disabled action
by mistake if a search word happens to be in the reason message.
This improves the situation with the following changes:
* gimp_action_set_sensitive() now takes an optional reason string to set
the reason message.
* Same for gimp_action_group_set_action_sensitive().
* gimp_action_get_sensitive() returns an optional reason string.
* gimp_procedure_get_sensitive()'s tooltip return value now becomes a
reason (it won't contain anymore the tooltip and the reason
concatenated, only the reason for separate processing).
which will be shown when selected template pixel density don't
match the image pixel density.
Then user can either keep current image ppi and scale the
template or set image ppi to match the template ppi.
Density selector displayed only when template and image ppi
differs and template unit is matches one of real world units
(e.g. inch, mm, etc).
Closes: GNOME/gimp#1140
This should not be necessary and I could not find the bug in GIMP. It
might be in GTK. In any case, after hiding, then showing back the export
dialog, the file name is right but not the output folder (apparently
revert to current working directory?).
With this, we force it to be the same folder as we left the dialog.
Adds option for selecting predefined page sizes using the same
template selector as on "New Image" dialog.
Syncs up size and offset unit selectors to have the same value
when changing template and when resetting whole dialog.
Since we now hide the file dialog when exporting, progression ends up
invisible, which is especially a problem with big files. Therefore use
the image display as a GimpProgress to show progression.
When running several times an export plug-in while one is still running,
the export file dialog may get destroyed and the second running plug-in
would try to call functions on a destroyed dialog, hence crashing core
GIMP.
Using a `GtkListBox` allows us to make more complex widgets when trying
to showcase an icon theme. For example, we can make the example icon a
bit bigger so you don't have to squeeze your eyes to distinsguish them
one from another.
Other possibilities we can do with this widget, is for example making
the folder label clickable to open the file explorer, or add a flat
button at the end with the same purpose. Since it's now just a
`GtkLabel`, we can also make the path selectable (for copy-pasting).
Using a `GtkListBox` in the "Image Window Title & Statusbar formats"
preference pane allows us to make more complex rows, such as adding a
visual example of how the format string behaves on a given image title.
This commit just converts the `GtkTreeView` into a `GtkListBox`, so
nothing has functionally changed (yet), except that rows now give
feedback when the user hovers over them.
In gimp_dialog_factory_register_entry(), strings were passed to gettext
without checking for a NULL pointer. The gettext documentation [1]
points out that that's undefined behavior, and musl libc's
implementation of gettext segfaults in that case.
[1] https://www.gnu.org/software/gettext/manual/gettext.html#Interface-to-gettext
We are piling up the export dialog, then the specific plug-in dialog,
then possibly more dialog (cf. upcoming commits for metadata handling).
It's just too much and we end up in a mess of dialogs.
Of course, if the export fails or it is canceled, we are back to the
file dialog, which gets shown again, whereas if it succeeds, the file
dialog is destroyed (just as it already used to be).
Also anyway the file dialog is completely deactivated while the export
dialog is displayed, so it's just useless. Finally some export support
have features where looking at the canvas is useful, for instance JPEG
preview feature. With all these dialogs, it's nearly impossible to look
at the canvas (with a single display at least).
A -quick done- first step towards the addition of a smart selection tool.
Require the gegl:paint-select workshop operation.
Still LOT of work to do (wip):
- fluctuations removal (GEGL side)
- multilevels pyramid approach + banded graphcut for instant result on large
image (GEGL ? GIMP ?)
- Gaussian Mixtures for color models (GEGL side)
- drawable offsets (GIMP side)
- undo / redo (GIMP side)
- scribbles edition mode (GIMP side)
- dedicated icons
- ...
Renaming the temporary function gimp_scale_entry_new2() into
gimp_scale_entry_new() now that the original code is entirely gone. This
is now a fully-fledged widget with a nice and proper introspectable API.
Instead of setting always manually the step and page increments when
creating a GimpScaleEntry, let's just generate some common cases
automatically. Indeed the increments are rarely something you want to
care about. The algorithm used is:
- For a range under 1.0, use a hundredth and a tenth (typically a [0,
1.0] range will step-increment of 0.01 and page-increment of 0.1).
- For small ranges (under 40), step-increment by 1, page-increment by 2.
- For bigger ranges, step-increment by 1, page-increment by 10.
For use cases when you absolutely want specific increment values, I add
the gimp_scale_entry_set_increments() function. It is much better to
have a small and understandable constructor call followed by
configuration calls (only when needed) rather than a constructor with a
crazy amount of parameters. Hence gimp_scale_entry_new() went from 17
arguments (absolutely unreadable calls) to now 5.
* Add a gimp_scale_entry_get_value() because if we don't do a property
widget, getting the value of the widget easily is a main point.
* Move gimp_scale_entry_(set|get)_logarithmic() to the new class API.
* Internally edit the GtkSpinButton width depending on min/max values,
place digits, and possible value sign.
* Emit a "value-changed" signal (similarly to other widgets with a
value), for cases when just binding the "value" property is not
enough.
* Finally use the new API in palette-import-dialog.
Some people had been complaining that they couldn't find some actions in
some case, which was only because they were in states where the actions
were non-sensitive. So it was "normal" (i.e. not a bug), yet I can see
how it can be disturbing especially when we don't realize that an action
is meant to be inactive in some given case.
Of course the option to show all actions already existed in the
Preferences. But as most options in Preferences, this is hardly
discoverable and many people only use default settings. Moreover showing
hidden action made the action search cluttered with non-sensitive
actions in the middle of sensitive ones.
This change gets rid of the "Show unavailable actions" settings and
always show all matching actions. In order not to clutter the list with
useless results, I simply updated the display logics to always show
non-sensitive action after sensitive ones. Note that even non-sensitive
actions will still be ordered in a better-match-on-top logics, yet they
will be after sensitive actions. So the top results will be the best
matches among sensitive actions (action in history), followed by various
levels of matches (actions with matching labels, tooltips, different
order matches, etc.); then they will be followed by best matches among
non-sensitive actions, followed by the same levels of matches as
sensitive ones.
This way, we still keep a very relevant result and there is no need to
have a settings for this.
The About dialog refreshes the release information relatively to
currently running version before being displayed. No check of the remote
JSON file is done, it only verifies whether any stored released
version/revision is not same (or even lower) than the actually running
version. Indeed existence of a stored release means that a newer version
exists at check time only. On later run, this stored information may
have become deprecated.
Make some of the bigger Preferences pages automatically scrollable if
needed. Based on my tests, this should be enough to fit on quite small
displays, at least with the default themes, even the 1366×768 reported
as too small. It should even fit in 1280×720 (in my tests, it did).
Targetting even smaller screens may be overdoing it for an image
manipulation software. We'll see if people still ask for a smaller
dialog.
Our Preferences exposes a concept of "Preferred color profile" (for RGB,
grayscale and CMYK), which is used in some places to be proposed as
default alternative to built-in profiles. But it was not used in the
import color profile dialog (only 2 choices were: keep the image profile
or convert to built-in RGB).
This commit now adds this third choice, which is even made default when
hitting the "Convert" button directly, without tweaking with the dialog.
Because we can assume that if someone made the explicit choice to label
such a profile as "Preferred", this is more likely the one to convert to
(if one even wants to convert from an embedded profile anyway).
As for the `Preferences > Image Import & Export > Color profile policy`,
they now propose 4 choices: Ask, Keep embedded profile, Convert to
built-in or preferred profiles.
Orientation is now handled by core code, just next to profile conversion
handling.
One of the first consequence is that we don't need to have a non-GUI
version gimp_image_metadata_load_finish_batch() in libgimp, next to a
GUI version of the gimp_image_metadata_load_finish() function in
libgimpui. This makes for simpler API.
Also a plug-in which wishes to get access to the rotation dialog
provided by GIMP without loading ligimpui/GTK+ (for whatever reason)
will still have the feature.
The main advantage is that the "Don't ask me again" feature is now
handled by a settings in `Preferences > Image Import & Export` as the
"Metadata rotation policy". Until now it was saved as a global parasite,
which made it virtually non-editable once you checked it once (no easy
way to edit parasites except by scripts). So say you refused the
rotation once while checking "Don't ask again", and GIMP will forever
discard the rotation metadata without giving you a sane way to change
your mind. Of course, I could have passed the settings to plug-ins
through the PDB, but I find it a lot better to simply handle such
settings core-side.
The dialog code is basically the same as an app/dialogs/ as it was in
libgimp, with the minor improvement that it now takes the scale ratio
into account (basically the maximum thumbnail size will be bigger on
higher density displays).
Only downside of the move to the core is that this rotation dialog is
raised only when you open an image from the core, not as a PDB call. So
a plug-in which makes say a "file-jpeg-load" PDB call, even in
INTERACTIVE run mode, won't have rotation processed. Note that this was
already the same for embedded color profile conversion. This can be
wanted or not. Anyway some additional libgimp calls might be of interest
to explicitly call the core dialogs.
After discussions on IRC, it was decided that our current level of
support of OpenCL was not good enough. As a normal settings, people just
see it as a normal acceleration checkbox, even despite the warning text
and emoticone saying the opposite (i.e. it may even slow things down in
some cases).
Basically this feature needs more love to be back into mainstream
Preferences.
In other dialogs, it is not a revert to how it was before opening the
dialog, but a reset to default settings.
To just revert to dialog opening values, we can just use "Cancel" and
reopen the dialog (a bit cumbersome, but not something done often
anyway).
Currently what "Reset" does is to set back the device mode and any
customized axe curve. It doesn't touch customized keys, but these will
disappear anyway in a further commit.
Rather than the "Save" and "Close" buttons which were very weird, if not
misleading. When Aryeom was giving a course to students, several thought
the buttons were broken because "nothing happened" when clicking "Save".
So instead, "OK" will just save and exit (equivalent to click "Save"
then "Close" on old GUI) as it is the common usage and should be doable
in a single click.
"Cancel" closes while resetting to how the settings were before opening
the dialog.
Finally "Reset" just reset the settings to how they were before opening,
without closing the dialog.
This also makes the buttons look/behave like the ones on Preferences,
which is nice consistency-wise too.
When creating a palette out of an image without checking "Sample
Merged", it will now extract the colors out of each individual selected
layers separately. This allows to create palettes even out of all layers
of an image but still considering these individually.
Multi selection actually only really matter when "Merge within active
groups only" option is checked, in which case we are able to merge
layers within several layer groups simultaneously, and end up with
multi-selected merged layers.
Also not sure why both layers-merge-layers and image-merge-layers exist,
as they are exactly the same (exact same callback called when
activated).
These actions raise a GimpViewableDialog. For this to work, I made this
widget work with a list of GimpViewable, not a single viewable anymore
(so maybe the widget class name should change?).
When this list contains only a single GimpViewable, it will display
exactly like before, with a viewable preview. With several viewables,
the preview won't show.
This allows to add masks to all selected layers at once, with the same
basic options for all masks, as set in the dialog.
Though it's not finished yet, I am changing "active layer" into
"selected layers" logics. Probably the "active layer" concept will be
back eventually (i.e. even in a multi-selection a specific layer could
be said "active", highlighted in the list a bit differently, hence one
could edit this specific layer only). But for simplicity, for now, it's
better to first get rid of it, otherwise it's just messy.
This whole drag'n drop code is quite overwhelming, I'm pretty sure this
commit introduced various bugs, and there are already several areas of
improvements I noticed. But at some point, I need to split at a not-too
broken code state or I'll just make things worse.
I wanted to enable it in the end, but it makes my work tree messy. Just
commit this now. Multi-selection basically works but there are still a
lot of broken features which are to be taken care of one by one.
Only enabled for layer tree so far.
After discussing with Schumaml and Houz on IRC, let's just drop the
generic comment which may be confusing and is probably unecessary,
especially now that I write the revision number (present and new ones).
So let's just assume people understand that they should update, even
when GIMP version stays the same (this was the case I was the most wary
about, that people think the notification is an error as since they have
the last version, they don't have to update GIMP).
I hesitated to at least leave just the simple "It is recommended to
update." sentence but after much hesitation, let's go with no generic
comment at all. The download button by itself should suffice.
Of course, when a specific revision comment is set in
gimp_versions.json, it is still displayed.
- Instead of the download link being just a link button (similar to
browser "blue text" links), make it a proper button encompassing the
update icon and the download text "Download GIMP X.Y.Z".
- Make also the revision number part of the download information.
- Frame title is now "Update available!" instead of "New version
available!" (because it's not necessarily a new version, it can also
be just a package revision. "Update" is more generic).
- When no update is available, the "Check for updates" button is big and
has a label, and also now an icon. When an update is available, hence
we display now a button for the download link, the "Check for updates"
button becomes small with icon only in order not to take visual
priority over the download itself (yet allowing to re-check for even
newer information).
As noted on IRC, after the first update check on a given day, it looks
like the check button does nothing. Therefore also display the check
time to clearly show the button click was taken into account (simply
there are no updates, hence only displayed check time is updated).
When checking for updates, write the new timestamp and version info
to Gimp::edit_config, instead of Gimp::config, and rely on its
auto-save mechanism to save the changes, in order to avoid having
to save Gimp::config on exit, which overrides modified settings
that require a restart, such as the UI language, as they are only
reflected in Gimp::edit_config.
This fixes the bug, but can cause the new update info to be
discarded if the Preferences dialog is open while checking for
updates, and is subsequently canceled. Ideally, the update info
should live in a separate file, rather than in gimprc.
Allow horizontal scrollbars in all the Preferences dialog tree-
views, so that they don't limit the minimal width of the dialog (in
particular, the UI- and icon-theme tree-views may contain
arbitrarily-long paths).
If for instance you've got no internet connection or other reasons that
a check might fail, the check-update-timestamp will be 0, which is
1970-01-01.
Thanks to Alexandre Prokoudine for noticing it!
Even when we already notify of an update, we should leave the ability to
query the last gimp_versions.json manually.
It would allow also people who disabled automatic check at startup
(whether through preferences or because the build disabled the feature
altogether) to still make update checks, and to not be forever stuck
with the result of an outdated version check.
The idea is to be able to advertize a new revision of the same version
of GIMP. For instance, this would apply when we release a
`gimp-2-10-14-setup-3.exe` Windows installer (then we are at revision
3, provided we started at revision 0).
The revision number is obviously only relevant to a given platform and
version. Also the concept of build ID allows to differentiate various
builds for a same platform, in particular to not look at revisions of
third-party builds. The build ID can be any string. Maybe we could just
use reverse DNS build id (such as "org.gimp.GIMP_official") to identify
the official GIMP build. So in the end, we only compare revisions for an
identical (version, platform, build-id) tuple.
Add a new "Snap brush outline to stroke" toggle to the "Image
Windows" preferences page. When enabled, the brush outline in
paint tools snaps to the individual dabs while painting, instead of
following the cursor precisely (this is the existing behavior).
When disabled, the brush outline follows the cursor while painting
in the same way it does while not painting.
Disable the option by default. This seems to be what most other
programs are doing, and it does give paitning a smoother feel.
Add a new Gimp::tool_item_ui_list, which is a GimpTreeProxy over
Gimp::tool_item_list. This allows us to use either a hierarchical
or a flat tool list in the UI, by setting the "flat" property of
the new list.
Use Gimp::tool_item_ui_list in GimpToolPalette, so that the toolbox
layout is affected by this choice.
Add a "Use tool groups" toggle to the toolbox preferences, and bind
it to the "flat" property of Gimp::tool_item_ui_list.
Add tool-group support to GimpToolEditor, used to organize tools in
the Preferences dialog, including creating, rearranging, and
deleting groups. Also, major cleanup.
gimp_int_radio_group_new() was still complaining about the scope of
radio_button_callback(). Make it (scope notified) because it needs to
stay alive after the function returns and may be called multiple times.
Also adding a GDestroyNotify to free the callback data once the widget
is destroyed (additionally it will also serve as a notifier for bindings
to properly free the callback closure itself, not only it's data).
With this last one done, GObject Introspection generation now happens
without any warning output.
Add a new 3D Transform tool, based on GimpToolTransform3DGrid,
added in the previous commit. The tool UI provides a notbook with
three tabs, corresponding to the three GimpToolTransform3DGrid
modes:
Camera - allows setting the primary vanishing point, as well as
the camera's focal length, expressed either directly, or as the
camera's angle of view, relative to the whole image or the
transformed item. By default, the vanishing point is aligned
with the item's center, and the angle of view is fixed relative
to the item; this essentially means that each item is transformed
using a local perspective, independent of its position and size
relative to the image. A global perspective can be achieved by
using a common vanishing point and focal length (or an image-
relative angle of view).
Move - allows moving the item using X, Y, and Z offsets.
Rotate - allows rotating the item using X, Y, and Z Euler angles.
The order of rotation of the different axes can be controlled by
a set of numbered buttons next to the sliders, and the rotation's
pivot can be controlled using a pivot selector.
Instead of making the focus on bug reporting, the debug dialog will now
make the focus on updating the application if it is found that one is
not using the last version.
Debug data (backtraces and co.) will still be available and copiable,
but under an expander, and bug report button won't be displayed (i.e.
data will still be available upon request but we don't push anymore
people to submit it directly if they are using old versions of GIMP).
Of course, if you are using the last version (or version check was not
possible), the dialog still stays the same.
When an update is available, a big frame is visible, proposing to go to
the download page. Now a button is also available to explicitly request
for an update check in other cases (bypassing the wait delay for a
future startup).
I was wondering which shape should take the new version notification
(again some ugly pop-up?!) and realized using the About dialog was a
good idea.
This is preparatory work for this to happen.
GIMP will now process the remote gimp_versions json file to look if one
is using the last version of GIMP. This initial code doesn't act up yet
on this information. This will come in further commits.
Here are the characteristics:
- Since this requires internet access, a new checkbox is available in
the Preferences dialog, allowing to disable version checks. Note that
it is enabled by default as it is an important security feature, but
it has to be deactivatable.
- The remote access is done as an async operation because we don't want
it to block the startup in any way (for whatever reason). Also it
doesn't output errors if it fails to not be a bother (you don't
technically need internet access for an image program).
- We don't check at every startup. At each successful check, we save a
timestamp to prevent too frequent useless checks (I set it the timer
to a week or more for now).
export it to libgimp via GPConfig and add new API gimp_export_comment().
Bump the protocol version and improve variable names in both GPConfig
and libgimp/gimp.c.
and remove a gazillion gtk_widget_show() all over the place, some
places need a gtk_widget_hide() now, and I'm pretty sure I broke at
least one thing in all those files...
Add a new "Swap compression" option to the preferences, allowing
explicit control over the tile-swap compression algorithm.
Previously, control over swap compression was only possible through
GEGL command-line options/environment variables. Since the GEGL
API to list all available compression algorithms is still private
for now, we currently only list the three predefined compression
levels -- "best performance" (the default), "balanced", and "best
compression" -- and a "none" option, to disable compression
altogether. Selecting a custom compression algorithm is possible
by entering its name manually.
Add an option to keep the normal canvas padding in "show all" mode,
instead of extending the checkerboard pattern indefinitely. This
is useful when wanting to show the image content beyond the canvas,
while still keeping the focus on the canvas; further commits will
extend this mode to behave in more view-related cases as if "show
all" wasn't enabled.
Add a new 'View -> Padding Color -> Keep Padding in "Show All"
Mode" toggle, which controls this behavior, with a corresponding
default-value option in the preferences, under "Image Windows ->
Appearance".
It's an ancient concept from ancient times when we didn't have URIs
and only filenames (not to speak of GFile), and actually even from
before the ancient time before that ancient time when we first had
ones and zeros, and only had zeros.
paste as brush, paste as pattern, select to new brush, select to new pattern
fill selection outline, fill path, stroke selection, distort, rounded rectangle
indexed color conversion, merge visible layers, new guide, new guide (by percent)
image properties, newsprint, fractal explorer, sample colorize, new layer
metadata editor (just a button), spyroplus (only common buttons)
Add a "show canvas boundary" display option, and a corresponding
"View" menu item and default-apperance preferences option. When
enabled (the default), the canvas boundary is shown as an orange/
black dashed line in "show all" mode.
Add a "show all" mode to GimpDisplayShell, controlled through a
corresponding "View -> Show All" menu item. When enabled, the
entire image content is displayed, instead of cropping the image
to the canvas size. More generally, the display behaves as if the
canvas were infinite. The following commits improve the overall
behavior in this mode.
Add a prefernces option to control the default "show all" state.
Step one: get rid of all those deprecation warnings that make
it hard to see any other warnings:
- add a lot of dummy API to GimpAction, GimpActionGroup, GimpUIManager
etc. which simply forwards to the deprecated GTK functions, they
will all go away again later
- rename GimpAction to GimpActionImpl
- add interface GimpAction that is implemented by all action classes,
creates a common interface and allows to remove some duplicated
logic from GimpToggleAction and GimpRadioAction, and at the same
time adds more features
file_open_location_response(): guard against g_file_new_for_uri()
returning NULL (which it shouldn't) and an error being NULL (which it
shouldn't either for the same reason). Spotted by Massimo.
...doesn't work
Rename the labels to "built-in sRGB color profile" and "built-in
grayscale color profile" because that's what the option does, it never
converted to the preferred profiles from preferences.
Add a "gboolean edge_lock" parameter to GimpChannel::feather() and a
"Selected areas continue outside the image" toggle to the "Feather
Selection" dialog, just like they exist for shrink selection and
border selection. At the end, convert the boolean to the right abyss
policy for gegl:gaussian-blur.
Add a new Offset filter tool, as a front-end to gimp:offset. The
tool replaces, and provides the same interface as, the drawable-
offset dialog, while also providing live preview and on-canvas
interaction.
Note that we don't simply use a custom propgui constructor for
gimp:offset, since we need a little more control.
There should never be an image using GIMP_TRC_PERCEPTUAL, but things
should work if one is encountered anyway.
In the Image -> Precision menu and the Convert Precision dialog, have
menu items / radio buttons for both non-linear and perceptual, but
hide the perceptual choice unless the image is in perceptual TRC mode.
This should eliminate the possibility to create perceptual TRC images
from the GUI.
...to the Configure Keyboard Shortcuts dialog
Add the button, based on an old patch from Sven Neumann, and make the
buttons in the keyboard shortcuts and input devices dialogs look and
behave the same.
In gimp_open_dialog_set_image(), use a weak pointer for storing the
current image, to avoid a segfault in file_open_dialog_response()
if the active image at the time of the open action has been closed
before confirming the dialog.
This is useful to be able to support file formats other than image
formats. In particular I will use this in the next commit to support a
"GIMP extension" format. When GIMP will open such file, it will
install an extension (not open an image on canvas).
This is an internal flag only, i.e. only usable from core GIMP. File
formats which a plug-in can register are still only image file formats.
When loading indexed images, the image type is not obvious at all
(basically only reference is in the title bar). The main issue is that
if you don't realize it when editing, GIMP appear broken when the
expected colors don't appear on canvas.
Commit e48c239459 was a first step by showing various color widgets with
out-of-gamut warnings contextually. This additional commits will also
allows color selection for painting tools (i.e. foreground and
background colors) to be done within the image palette by default. This
way, the fact that this image impose working with limited color palette
is obvious as soon as you try to edit colors.
In gimp_image_merge_layers() -- the internal function used by the
various layer-merging/flattenning functions -- process the merged-
layer graph in chunks, using gimp_gegl_apply_operation(), instead
of in one go, using gegl_node_blit_buffer(). Processing in chunks
better utilizes the cache, since it reduces the size of
intermediate buffers, reducing the chances of hitting the swap when
merging large images (see, for example, issue #3012.)
Additionally, this allows us to show progress indication. Have the
relevant gimpimage-merge functions take a GimpProgress, and pass it
down to gimp_image_merge_layers(). Adapt all callers.
We were doing it all the wrong way, fixing one combo box object at a
time. So this commit basically reverses commits 68a33ab5bd, 6dfca83c2a
and a9a979b2d0 and instead runs the same code in the class code. This
way, all objects based on these base classes will have the fix from
scratch.
These improved various other drop-down lists (I found some of them, and
probably not all) as I fixed all GIMP custom widgets based on
GtkComboBox.
Note that it has to be run after filling the list apparently (I had the
problem especially with GimpIntComboBox if running in the _init() code,
then the list widget showed wrong).
...closing this image while the file is being loaded
Ref the image around all calls to file_open_layers() and
gimp_image_add_layers() so it stays around even if the user closes the
display in the meantime.
This commit completely removes the "Edit -> Fade..." feature,
because...
- The main reason is that "fade" requires us to keep two buffers,
instead of one, for each fadeable undo step, doubling (or worse,
since the extra buffer might have higher precision than the
drawable) the space consumed by these steps. This has notable
impact when editing large images. This overhead is incurred even
when not actually using "fade", and since it seems to be very
rarely used, this is too wasteful.
- "Fade" is broken in 2.10: when comitting a filter, we copy the
cached parts of the result into the apply buffer. However, the
result cache sits after the mode node, while the apply buffer
should contain the result of the filter *before* the mode node,
which can lead to wrong results in the general case.
- The same behavior can be trivially achieved "manually", by
duplicating the layer, editing the duplicate, and changing its
opacity/mode.
- If we really want this feature, now that most filters are GEGL
ops, it makes more sense to just add opacity/mode options to the
filter tool, instead of having this be a separate step.
Move swap/cache and temporary files out the GIMP user config dir:
libgimpbase: add gimp_cache_directory() and gimp_temp_directory()
which return the new default values inside XDG_CACHE_HOME and the
system temp directory. Like all directories from gimpenv.[ch] the
values can be overridden by environment variables. Improve API docs
for all functions returning directories.
Add new config file substitutions ${gimp_cache_dir} and
${gimp_temp_dir}.
Document all the new stuff in the gimp and gimprc manpages.
app: default "swap-path" and "temp-path" to the new config file
substitutions. On startup and config changes, make sure that the swap
and temp directories actually exist.
In the preferences dialog, add reset buttons to all file path pages.
file_save(): make sure we always set an error on failure
file_save_dialog_save_image(): additionally, check that "error" exists
before dereferencing it.
A single icon theme can contain both regular and symbolic icons. Let's
give possibility to switch from one style to the other within GIMP
Preferences.
This won't work very well in all cases yet, especially if an icon theme
only has symbolic icons (and no regular ones) because of inconsistencies
in glib which are being fixed (patches which I submitted and which were
merged in glib on 2018-08-17).
So this will work as expected when we will bump our glib requirement to
whatever is the next release.
All babl formats now have a space equivalent to a color profile,
determining the format's primaries and TRCs. This commit makes GIMP
aware of this.
libgimp:
- enum GimpPrecision: rename GAMMA values to NON_LINEAR and keep GAMMA
as deprecated aliases, add PERCEPTUAL values so we now have LINEAR,
NON_LINEAR and PERCPTUAL for each encoding, matching the babl
encoding variants RGB, R'G'B' and R~G~B~.
- gimp_color_transform_can_gegl_copy() now returns TRUE if both
profiles can return a babl space, increasing the amount of fast babl
color conversions significantly.
- TODO: no solution yet for getting libgimp drawable proxy buffers in
the right format with space.
plug-ins:
- follow the GimpPrecision change.
- TODO: everything else unchanged and partly broken or sub-optimal,
like setting a new image's color profile too late.
app:
- add enum GimpTRCType { LINEAR, NON_LINEAR, PERCEPTUAL } as
replacement for all "linear" booleans.
- change gimp-babl functions to take babl spaces and GimpTRCType
parameters and support all sorts of new perceptual ~ formats.
- a lot of places changed in the early days of goat invasion didn't
take advantage of gimp-babl utility functions and constructed
formats manually. They all needed revisiting and many now use much
simpler code calling gimp-babl API.
- change gimp_babl_format_get_color_profile() to really extract a
newly allocated color profile from the format, and add
gimp_babl_get_builtin_color_profile() which does the same as
gimp_babl_format_get_color_profile() did before. Visited all callers
to decide whether they are looking for the format's actual profile,
or for one of the builtin profiles, simplifying code that only needs
builtin profiles.
- drawables have a new get_space_api(), get_linear() is now get_trc().
- images now have a "layer space" and an API to get it,
gimp_image_get_layer_format() returns formats in that space.
- an image's layer space is created from the image's color profile,
change gimpimage-color-profile to deal with that correctly
- change many babl_format() calls to babl_format_with_space() and take
the space from passed formats or drawables
- add function gimp_layer_fix_format_space() which replaces the
layer's buffer with one that has the image's layer format, but
doesn't change pixel values
- use gimp_layer_fix_format_space() to make sure layers loaded from
XCF and created by plug-ins have the right space when added to the
image, because it's impossible to always assign the right space upon
layer creation
- "assign color profile" and "discard color profile" now require use
of gimp_layer_fix_format_space() too because the profile is now
embedded in all formats via the space. Add
gimp_image_assign_color_profile() which does all that and call it
instead of a simple gimp_image_set_color_profile(), also from the
PDB set-color-profile functions, which are essentially "assign" and
"discard" calls.
- generally, make sure a new image's color profile is set before
adding layers to it, gimp_image_set_color_profile() is more than
before considered know-what-you-are-doing API.
- take special precaution in all places that call
gimp_drawable_convert_type(), we now must pass a new_profile from
all callers that convert layers within the same image (such as
image_convert_type, image_convert_precision), because the layer's
new space can't be determined from the image's layer format during
the call.
- change all "linear" properties to "trc", in all config objects like
for levels and curves, in the histogram, in the widgets. This results
in some GUI that now has three choices instead of two.
TODO: we might want to reduce that back to two later.
- keep "linear" boolean properties around as compat if needed for file
pasring, but always convert the parsed parsed boolean to
GimpTRCType.
- TODO: the image's "enable color management" switch is currently
broken, will fix that in another commit.
Add a gimp-register-file-handler-priority procedure, which can be
used to set the priority of a file-handler procedure. When more
than one file-handler procedure matches a file, the procedure with
the lowest priority is used; if more than one procedure has the
lowest priority, it is unspecified which one of them is used. The
default priority of file-handler procedures is 0.
Add the necessary plumbing (plus some fixes) to the plug-in manager
to handle file-handler priorities. In particular, use two
different lists for each type of file-handler procedures: one meant
for searching, and is sorted according to priority, and one meant
for display, and is sorted alphabetically.
The extension dialog will show details about an extension (long
description, screenshot, upstream URLs, etc.) with this widget.
Update the GimpExtensionList to send a "extension-activated" signal on
double click, and make the extensions dialog react on it to display the
extension details for the activated extension.
This is all still mostly a skeleton GUI, but it is starting to get into
shape.
This is using GTK+3 widgets, so I make sure to keep it well separated
from core code. The gimp-2-10 version will have to rework the GUI, but
the GtkListBox and GtkSwitch are nice and make things easier, so it is
worth using them here).
Preview generation for layer groups is more expensive than for
other types of drawables, mostly since we can't currently generate
layer-group previews asynchronously. Add a preferences option for
enabling layer-group previews separately from the rest of the
layer/channel previews; both of these options are enabled by
default. This can be desirable regardless of performance
considerations, since it makes layer groups easily distinguishable
from ordinary layers.
In the preferences dialog, make the "dither images when promoting
to floating point" option insensitive when the "promote impoprted
images to floating point precision" option is unchecked.
...upon exporting an image
Step 1: make it configurable just like "Export EXIF" etc.
app, libgimp: add "export-color-profile" config option
Add it to the preferences dialog, and pass it on to plug-ins in the
GPConfig message. Add gimp_export_color_profile() to libgimp.
Nothing uses this yet.
resize_dialog_new(): create the preview with "popup = TRUE", so we
really get a preview of layer size and not of the layer within the
image context like used for the layers dialog.
Also remove all traces of it from the plug-in protocol and raise the
protocol version to 0x0100 (we now allow features and therefore
version bumps in stable, and the master protocol version should always
be higher). Fix the code that aborts plug-in startup on protocol
version mismatch, we can't use gimp_message() because we have no
protocol.
With GTK+3, high or low density is taken care by the screen scale
factor. Having a separate preferences for this is redundant, and likely
even wrong.
It may be interesting though to have a new preference later, which would
allow smaller scale icon sizing since some people like their icon
slightly smaller or bigger, and also when you are using screens whose
density is at a limit scale factor. Right now, this can be done through
themes, but a GUI settings may be interesting. If I add such feature,
let's just do it from scratch later.
Use a cairo surface with scale factor in the list cell, instead of
pixbuf property, so that the example icon keeps sharpness even on high
density (when possible, i.e with vector icons, or available high res
version).
Also if an example icon was not set, search for the symbolic variant
first, then fallback to non-symbolic.
The window will be raised soon after anyway. No need to do it too early,
which makes setting a transient parent useless afterwards. In particular
we were still getting a "GtkDialog mapped without a transient parent"
message.
GTK+ has the concept of theme variants, and in particular if we prefer
the dark variant of a theme. This can be chosen globally but also
per-application. Make this choice customizable in the Theme tab of
Preferences.
By default, the dark variant will be prefered.
Use the "activate-link" signal instead of "clicked" on tip links, so
that we can stop signal propagation.
Otherwise it opens "http://docs.gimp.org/" everytime.
