The "grabbing" cursor currently used is quite large on
newer versions of GTK3, and makes it difficult for users
to see where they're grabbing. This patch switches to
using "pointer" cursor for hovering over the slider area,
and "col-resize" when actually moving the slider.
It also reverts padding changes in CSS so that the progress
bar aligns with the place the user clicks. Padding is added
in Cairo for the label, though the number entry is now
flush against the input buttons.
Let's not try to align anymore the label text with the value (numbers
inside the GtkEntry) text. Our previous offset computation was wrong
anyway, but even correctly aligning the text, there could be cases where
the label's actual font was bigger than the number's font.
I had the case with GIMP set in Korean. The number text was 11-pixel
high but the Hangul text on 16 pixels in plug-ins using a GimpSpinScale,
most likely because the font used for numbers didn't have Hangul glyphs.
So we ended up with very ugly scale title on the bottom of the widget,
even out of the progress area. Instead, we just make sure that the label
is exactly in the vertical middle of the widget, disregarding the entry
layout's offset.
There were some complaint about the height of these scale.
The min-height was clearly too high. I also made the buttons a bit more
compact by removing a bit of padding.
Finally I add a CSS name to the class, in order to avoid using the
parent class name ("spinbutton"). This makes for clearer and more
customizable themes (ability to style the GimpSpinScale without styling
GtkSpinButton too).
The label was simply completely invisible because of broken progress
computation. Now it is visible at least when the progress fully cover
the label, but a part of the label is not drawn when the progression is
smaller than the label. I still have not figured out how to fix this,
though I am starting to wonder if we should not just drop this 2-color
fancy drawing of the label. Clearly the fact we can't get the exact
progression gadget dimension is biting us.
Another issue I noticed when playing with RTL layout is that when
editing the value, it gets printed on the right side (together with the
label) which gets messy. This is also something to figure out, hoping we
get an API for this on the GTK side.
Also I am setting "auto dir" to FALSE on the Pango layout, making sure
it follows the widget direction, whatsoever. In particular, even if the
contents is not RTL characters, we should keep a RTL layout to avoid
completely broken layout.
The logics to get the progress position is not proper because the text
area (as returned by gtk_entry_get_text_area()) is actually slightly
smaller than the progress area. Unfortunately it doesn't look like there
is an API to get the exact progress area. This commit improves a bit the
situation by starting the progress rectangle when excluding the
intersection of 2 rectangles in pango at the start of the text area (not
at 0).
It's still not perfect as the progress width will be anyway a bit too
small and we don't have the data to compute it properly, but it's better
than it used to be. I also set several variables to double instead of
int to be more accurate, though this part doesn't help much.
Finally I used the ink extents rather than the logical extents. Since we
are here to draw, this is the ink extents which is really needed.
Note: for the bug to be visible, you need to have a different text color
for the progress and non-progress part of the scale.
Also I'm unsure about the right-to-left logics which seems very broken.
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.
2022-02-17 23:13:42 +01:00
Renamed from app/widgets/gimpspinscale.c (Browse further)
