- Indent all rules in Light theme with the same number of spaces for
style consistency.
- When GIMP was set in "Prefer dark variant", spin buttons and other
entries had too dark borders. Fix this.
- Fix the spinbutton entry's border radius which was at 0, but since the
buttons of the spin button are themselves rounded, it looks weird only
on the top and bottom left corners. So apply a 3px radius. I did this
in the System theme.
Makes the following changes:
*Toolbox Wilber is now visible
*Large black border removed from ScrolledWindow
*"Duplicate text" effect removed from labels
*Toolbox tabs are now stationary when changing selection
*"Add Tabs" menu background color changed to match Light theme
*Unnecessary border around Check Updates box removed
Optionally includes the previously saved
Duotone color space data on PSD export.
New load dialogue alerts user if duotone data was imported.
New export dialogue appears if the image is still grayscale and
the parasite exists.
If selected, the mode is set to PSD_DUOTONE in the header and
the original duotone data is written in the color space section.
These are issues which appeared to me only when GIMP was set to use the
dark theme variant. In such a case, I guess we see quite well CSS rules
coming from parent themes, such as the globally set system theme.
* Remove any background image (which may come from the system theme?) on
buttons.
* The headerbar was dark and when in the background, it had a dark
linear gradient (probably coming from my system theme). So make sure
the background color is right as a general rule, and add back a
(small) light gradient to indicate the background state.
* GtkListBox had a dark background. We don't have a lot of usage for
this widget yet, but a few (for instance in icon theme settings, or in
the modifiers editor).
* The GtkSwitch buttons were dark on dark. Set a light background. Also
when the switch is ON, I add a bit of color, not too strong, but
enough to indicate the checked status, because I find this widget
design not so obvious. Since I don't think we use switch buttons
anywhere else but in Preferences, this is probably not a big problem
as it should not affect color perception when working on the canvas.
Add the info about max dimension of WebP with WEBP_MAX_DIMENSION macro.
There is also a test about (picture->width / 4 > INT_MAX / 4), resp.
height, but this should anyway never happen as the C spec says the
smaller range for int is [-32767, 32767], which is an order bigger than
the current WEBP_MAX_DIMENSION (16383).
So we are probably fine assuming all VP8_ENC_ERROR_BAD_DIMENSION errors
will happen because of WEBP_MAX_DIMENSION.
Actually our X11 implementation is right, and the implementation from
the Freedesktop portal is "as far as it can do", i.e. that we get the
returned RGB value, which is unfortunately in display space. And it
doesn't return any space information together (we don't even know which
display the color comes from, in multi-display setups).
Therefore let's check if we are running GIMP on X11 and if so, let's
call this implementation first.
See this report on xdg-desktop-portal to get proper space info:
https://github.com/flatpak/xdg-desktop-portal/issues/862
We should set these explicitly, otherwise it will usually default to the
first of the enum, which is perceptual (which is usually not a proper
choice).
Relative colorimetric is usually the recommended default.
The GimpColorProfileComboBox widget requires the profile chooser dialog
to be explicitly constructed. It doesn't create it by itself.
I guess I hadn't tested clicking this "Select color profile from disk…"
combo item during review. I only selected visible profiles in the list!
This adds a Soft-Proofing pop-over menu when right-clicking the toggle
in GimpStatusBar. It lets users toggle proofing, using BPC and showing
out-of-gamut colors. It also lets users change the profile and
rendering intent.
Opacity and brush size are among the 2 most common tool options which
people might want to often change, though we should likely later add all
other common types of tool settings angle, aspect ratio, spacing, etc.
I am also unsure using the enum action is the right call because what it
does is just taking into account the distance from initial click to
compute an opacity. Instead it might be more interesting to increase or
decrease slowly or rapidly by going right or left from the initial
click. We'll see. But it's a first step.
The mouse controller had many limitations:
* It was not per-device.
* It was a long hard-coded list of events, which made its evolution
annoying and scrolling the list boring.
* It was starting at button 8, while the first buttons were supposed to
be hardcoded interactions. And it stopped at button 12, while some
device might have more buttons nowadays. See !386.
* The "Grab event" does not seem to work in many cases, according to
feedbacks.
The new GimpModifiersEditor will now handle any button (except the first
button, which is reserved for tools), you can even override or change
default canvas actions (panning, rotation, etc.). It should not be
limited with a max button number either (though I haven't tested with a
device really having a lot of buttons since I don't have any such device
but I did emulate huge button numbers on my stylus with xsetwacom and it
did work well; hopefully I'll get feedbacks). And now it can even run
custom actions.
So basically it should deprecate the mouse controller as the modifiers
editor can do everything the controller could, and more (unless I missed
anything).
Custom actions are basically any action (currently GtkAction) which can
be assigned a shortcut. Now they can also be assigned to an input device
button (with modifier or not).
* The relative brush size change was not implemented anyway. Maybe later.
* Also changing the defaults to GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE
which I think might be the most understandable size variant.
* Finally re-label "Rotate" to "Rotate View" as per Aryeom's feedback
because just "Rotate" is indeed confusing as it could mean several
different actions in GIMP.
Actually I am renaming GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE into
GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE, which allows to set the
brush size on-canvas, starting from center to border.
The new GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE now sets the brush size
from one border to another.
Space: panning
Ctrl-space: zooming
Shift-space: rotating
Ctrl-shift-space: constrained rotating
Note that these are still hardcoded, unlike the actions through
modifiers + pointer buttons.
There is really no need to make back and forth between a string and
int/enum representations, and it actually cause problems at times.
It's also a problem for the button representation where a modifier will
be represented as a key.
For now GimpModifiersManager returns the same modifiers as what was
previously hardcoded and we have no GUI yet to change the settings. But
the core of the new feature is in place.
This object's goal will be to manage customized modifiers per input
device button, which is why I add it to GimpDisplayConfig. It is in its
own new config file (`modifiersrc` in config dir) because it requires
GDK types access (well I could have done without, but it would have been
less semantic, hence not as good of an API). Anyway it is only useful
when running GIMP as GUI.
The GUI widget and the usage code to make this actually useful will come
in upcoming commits.
When no accelerator was set yet, display relevant information, and when
the button is toggled (waiting for shortcut input), display also
relevant info.
A widget to grab a shortcut provided interactively. It can also grab
modifier-only shortcuts so we will be able to use it for the new
on-canvas interaction customizability.
Maybe we'll use this later for the shortcuts dialog which should really
be improved some day and has a lot of known issues. We'll see.
Moving the "Space Bar", the "Snapping" and the new "Zoom" (MR !570)
settings there. The idea is that it will also be where we'll customize
more on-canvas related abilities, such as the new zooming behavior
preferences, but also possibility to customizing or disabling the
various canvas action, and finally customizing the new contextual
settings such as brush sizing or other.
… new action_pixel_size of GimpMyBrushTool.
MyPaint brush tool clearly shows the limits of my trick to have some
enum actions work with absolute values whereas others work with
per-mille values between the property min and max.
Indeed firstly MyBrush's "radius" value is logarithmic and can be
negative. Since the enum trick relies on the fact that negative values
are the semantic enumerated constants, it's broken in such case. The
second issue is that while it was acceptable to use int size for most
paint tools (even though they were double), here radius only goes from
-2.0 to 6.0; so using int values only would leave us with jumping brush
sizes.
So now I create a proper double action which simply takes pixel size and
use this from the on-canvas brush size changing. No weird trick, no int
or sign limitations.
I also add a new optional action_pixel_size in GimpToolControl.
Note: I'm also updating a bit the logic for the MyPaint brush outline
function gimp_mybrush_tool_get_outline(). Indeed after skimming a bit
through mypaint-brush.c code in libmypaint, I am not sure at all we need
to use the offset_by_random like this. And really this shown outline
seems more indicative than anything else when I see the actual size
printed by the various brushes. Finally here it was counter-productive
as I needed to get easily the logarithmic radius from the pointer
interaction on canvas.
These actions can be activated with a double value. These will be useful
to create new types of size action, which are based on accurate pixel
values instead of an enum hacked to set per-mille values between a
min/max.
Note that the other paint tool which is not as common as others is the
MyPaint brush tool. At first I thought the circle outline didn't work.
It does actually work, but the radius concept is simply very weird in
this tool so we have to move a lot. To be investigated.
Until now, it was only stopiing when releasing right click, but it's
actually more accurate when releasing the Alt key first as the button is
on the mouse/stylus (so releasing it can provoke small hand moves,
especially visible with stylus, I think). Now it stops whatever is
released first.
I started from mitch's patch (though code changed so it was not working,
yet I ended up with quite a different direction).
Modified from original proposition in #498:
* Do not mix opacity and brush size in a same action, one on horizontal
movement, the other on vertical. The problem is that it's hard to stay
perfectly horizontal or vertical, so you nearly necessarily change one
while changing the other and this would be frustrating.
* Do not just use modifiers, but modifiers + right click. The logics is
that left (or whatever is the first button) click is for the tool
actions. The middle click for navigation (panning, rotation, and even
layer navigation now). Right click for now is only for menu. With this
change, let's use right click for various settings-related changes
too. Also we already have people complaining with things like canvas
rotation happening unexpectedly even though it requires button clicks.
Imagine an action just made of modifiers! Many people would hit these
by mistake all the time!
* Focus on brush size only for now. Instead of just calling the action
repetitively with the "SElECT_NEXT" action as proposed in the original
patch by mitch, let's compute the actual size between the press and
release. This would allow to have a real visual hint and also would
make it a lot more useful and meaningful to be an on-canvas change.
Say you want to reproduce a stroke size on canvas. You can click the
center and expand to retrieve approximately the size without computing
it in pixels.
Limitations and future work:
* This is a first draft and I still want to test if it works well with
the "lock brush to view" and with scale factor > 1.
* I want to associate this with work done for #7034 so that visual hint
still appear even when we have no visual hint set.
* I am not so fond of with the way we use enum actions which doesn't
really make satisfying logics (I hacked a bit over it, but it's
getting ugly). I'm considering creating int/double actions to really
set some values with exact numbers through actions.
* Right now we need to stop the right click first. I want to be able to
stop the brush sizing with releasing Alt too.
* It would be nice to make this all more customizable, which is why I
called internal variable "mod1_setting". The goal will be to have
other types of actions possibly. Also it could be deactivatable for
people really not liking these or hitting these by mistake (while not
needing these). Same for the navigation shorcuts.
* Similarly the right-click menu could be deactivatable or switched to
other actions conditionally (through Preferences). It is doubtful how
useful it is (compared to using the same menus on top of the GUI)
though I don't want to just delete the option because some people
would clearly be used to it.
* I think we should start breaking down the whole tool events code a bit
more, in particular the function gimp_display_shell_canvas_tool_events().
* For more settings, a small on-canvas GUI could be of interest where
you could customize various values through sliders and buttons, and
also where you could put your favorite brushes or dynamics or whatnot.
It's not replacing the more complete dockable but could be a nice
quick version for fast editing.
Jehan