On 2015-12-30 18:05, Elle Stone wrote:
On 12/29/2015 08:57 PM, Akkana Peck wrote:
Both the light themes seem quite dark and not very contrasty
(with black text and icons) compared to the GIMP I currently see,
which has a background color of #dcdad5 rather than the #bdbdbd
used in both of the light themes for most icons and menus;
except the menus in the alternate light theme, which are pretty
close to what I see now in GIMP.
I'd like to see a theme option (whether or not it's the default)
that has similar contrast to the current theme; the new themes will
be harder to read for at least some users.
On my system the "light side of GIMP" theme and the current default
GIMP theme are very close in tonality, with the "light side of GIMP
theme being a tad lighter. Here's a screenshot showing the two themes
side by side:
If I had to choose any of the new themes, it would be the "Light side
of GIMP" theme. By comparison, the current default theme looks a bit
outdated and the new theme is very pretty and modern-looking. But I
like the current theme better for three reasons:
1. The "light side of GIMP" theme has a lot of darker tones in things
like sliders, boxes for choosing parameters, the menu bar, and really
just about everywhere. This makes for too little contrast between the
sliders, boxes, etc and any contained text. It seems to me that a
lighter shade of gray would make the text stand out better.
I agree. Also do we want the theme to get rid of colors? If I were to
decide, I'd say no. For sliders for instance, I quite prefer this
blue|white colors to the white|grey proposed.
2. Also the new theme UIs for things like Gaussian blur, Curves, etc,
are always larger than the corresponding current default GIMP theme.
As screen real estate matters a great deal, I prefer the smaller UIs.
I agree. Draekko, is it because of the UI images which adds pixels here
and there? If so, could these be made to the strict minimum, as a
compromise between "beautiful" and "don't waste real estate space".
3. Also the new themes lack a good indication of where the grab areas
are for resizing windows and subwindows. Maybe users already know that
the subframes can be resized? And they know where to find the
(completely unindicated) grab handle for reproportioning the space
between the upper and lower subframes?
I agree. Draekko, could this be fixed?