We had this feature "can-change-accels" where people could change their shortcut
directly by browsing the menu. It was on the property "gtk-can-change-accels" in
GtkSettings. Unfortunately this got deprecated in GTK+ 3.10 (more accurately in
dev version 3.9.8, according to GTK's NEWS file), and is therefore ignored since
then. In other words, whether we check the box or not in our Preferences, it
doesn't do a difference.
If we want to get the feature back some day, we'll have to reimplement it with
custom code. In the meantime, there is no need to leave this visible in
Preferences.
This kinda reverts commit 6aebd30de1 ("app: remove
icon sizing preferences"), except that the code base is different enough since
this old commit was mainly for GIMP 2.10.x.
In any case, after initially thinking that GTK+3 handling for high density
display would be enough, we finally decide that adding back a Preferences-wide
setting for overriding the theme-set icon size is a good idea (additionally to
GTK+3 automatic support).
The base idea for removing the feature was that GTK+3 has high density display
support, through the "scale factor". Typically a high density display will
normally be set as using a ×2 scale factor so all icons will be double size.
Unfortunately it turns out it's not enough.
For instance, on very small screen estate, even with a scale factor of 1, if the
theme sets 24px toolbox icons, it may still take too much space.
Oppositely on huge screens, even with ×2 factor scale detected by the OS, the
icons may still feel too small (this is possibly what happens with #7023).
Furthermore there is also a matter of taste. Some people like small icons even
when they have the space. Others may want bigger icons, easy to click on.
Finally you can like a theme for its color scheme for instance, but it may not
have the icon size you want. Right now, we'd need to duplicate every theme in
small or bigger size. Instead of doing so, let's just have this global setting
overriding the theme rules.
Comparison with the 2.10 implementation:
- We still provide 4 sizes: small, medium, large and huge.
- We don't have the "Guess ideal size" setting anymore. Instead this is now a
mix of the GTK+3 scale factor logic and the theme-set or custom size. I.e.
that on a high density display with ×2 scale factor, we could have toolbox
icons up to 96 pixels (48×2)!
- We now try to have less custom code in widgets as we append the CSS rules to
the theme (similar to what we were already doing for dark theme or icon
variants). What happens in widget code is mostly to connect to changes in
themes and redraw the widgets which need to be.
- The custom size will now affect: toolbox icons, the FG/BG editor widget (in
both the toolbox and the color dockable), dockable tab icons, the main
dockable buttons, eye and lock header icons in item tree views, eye and lock
cell icons in the item lists.
There are still a bunch of areas where it is not taken into account, such as
plug-ins, and various dialogs, but even in custom-made interface in dockables.
Ultimately it might be interesting to have a way to sync more buttons and
widgets to a global size settings.
Lastly, I fixed a bunch of existing bugs where we were updating icon sizes with
gtk_image_set_from_icon_name() using the const icon name taken from
gtk_image_get_icon_name(). As this was reusing the same string pointer, we were
ending with freeing the icon name.
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
- ...
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.
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.
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.
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.
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.
Add GimpGuiConfig::filter-tool-use-last-settings wchich defaults to FALSE.
Honor the new option in gimp_gegl_procedure_execute_async() and add
it to prefs -> dialog defaults.
... be used effectively.
We have had display pixel density detection for quite some time, but I
guess the step I set to switch to the "Huge" icon size (48px for the
toolbox icons) was too high at 300 PPI. Someone with a screen of about
280PPI reported the icons to be far too small on GIMP 2.9.8.
It seems that 240PPI is already even considered as XDPI already. Let's
just set our new "Huge" step at the 250PPI intermediate.
In any case, it seems GIMP 2.10 will have problems with even denser
displays, but the way GTK+2 handles icon sizes with a GTK_ICON_SIZE_*
enum is quite limited. That is quite a problem considering screens
getting denser in pixels nowadays. Hopefully GTK+ 3 will improve the
situation.
Currently, the error console is highlighted (shown/blinked) only
upon errors; however, warnings, which are not shown on the
statusbar while the error console is open, often also contain
important information.
Allow the user to configure which message types (errors, warnings,
and regular messages) highlight the error console, using a new
"highlight" submenu in the error-console menu. Add corresponding
config options, saved in sessionrc. By default, highlight the
error console unpon both errors and warnings.
It is a little fuzzy whether expected or not, architecturally-wise. On
one hand, I can see some core/ header includes under config/. Though on
the other hand, app/Makefile.am explicitly sorts config/ below core/.
Anyway let's just use g_cclosure_marshal_VOID__VOID which is the same as
gimp_marshal_VOID__VOID and get rid of the include.
This fixes builds from scratch.
Current code only guess resolution for a single monitor. Ideally
the widget sizes could be different depending on the window where a
given widget is on. But that's a start.
Allow overriding icon sizes set in themes from the preferences.
This initial commit updates only toolbox icons. More to come.
4 options are available: small, medium, large and huge (the later would
likely be useful for HiDPI screens).
Uses a new widget GimpIconSizeScale.
Add new setting GimpGuiConfig:devices-share-tool. When TRUE, we never
copy any properties between the user context and the GimpDeviceInfo's
context, so no tool or anything changes.
We do however still keep track of the active device so the setting can
be enabled/disabled at any time. Also hide GimpDeviceStatus' tool,
brush etc. indicators in "shared" mode.
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.
Create GIMP_CONFIG_DEFAULT_(ICON_)?THEME in gimpguiconfig.h to set
defaults in a single place, except for libgimpwidgets/ which cannot
include from app/.
There is now a preference option that determines whether windows
should be opened on the same monitor as before. It should be disabled
when the machine gets monitors plugged/unplugged dynamically ("laptop")
and enabled when there is a static multi-monitor setup ("wokstation").
This is merely the current simplistic policy on top of the newly added
underlying infrastructure:
- pass integer monitor numbers around in all places where we already
pass around a GdkScreen. Pass the "current" monitor to these changed
APIs, where "current" is either the monitor where the action-triggering
widget is, or if that is unavailable the monitor where the mouse is.
- add gimp_widget_get_monitor() in order to easily get to the monitor,
just like gtk_widget_get_screen().
- add screen and monitor parameters in some places that were missed
before.
- in sessionrc, save all window positions relative to the window's
monitor, and save the monitor separately, if it's not the screen's
primary monitor.
- when restoring window positions, use the stored monitor when the new
prefs options says so (use the screen's primary monitor if there is
no stored monitor), otherwise use current monitor that is now passed
around.
Fix various bugs, improve code design and efficiency, change feature
name, update the feature up to our standards (now uses GIMP preferences,
session management, less overwhelming settings...).
Also now action history is tightly tied to GimpAction and logs all
action activation (however it activates, and the show_unavailable
parameter also applies to history).
Search algorithm greatly improved with basic tokenization, better
ordering, filtering, etc.
- don't include <gdk-pixbuf/gdk-pixbuf.h> in headers in app/
- instead, include it in many .c files instead of <glib-object.h>,
finally acknowledging the fact that app/ depends on gdk-pixbuf almost
globally
- fix up includes as if libgimpbase depended in GIO, which it soon will
when window positions aren't automatically saved.
Save "hide-docks" and "single-window-mode" in sessionrc instead of
gimprc, so a session layout is always saved either completely or not
at all. Also change "last-tip-shown" saving a bit so all three
session-saved gimprc properties are implemented the same.
Jehan