2006-12-09 21:33:38 +00:00
|
|
|
/* GIMP - The GNU Image Manipulation Program
|
2003-09-10 23:42:59 +00:00
|
|
|
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
|
|
|
|
*
|
2009-01-17 22:28:01 +00:00
|
|
|
* This program is free software: you can redistribute it and/or modify
|
2003-09-10 23:42:59 +00:00
|
|
|
* it under the terms of the GNU General Public License as published by
|
2009-01-17 22:28:01 +00:00
|
|
|
* the Free Software Foundation; either version 3 of the License, or
|
2003-09-10 23:42:59 +00:00
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
2018-07-11 23:27:07 +02:00
|
|
|
* along with this program. If not, see <https://www.gnu.org/licenses/>.
|
2003-09-10 23:42:59 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
2014-03-06 11:56:18 +01:00
|
|
|
#include <stdlib.h>
|
2003-11-12 12:56:31 +00:00
|
|
|
|
2017-10-16 11:38:28 -04:00
|
|
|
#include <gegl.h>
|
2003-09-10 23:42:59 +00:00
|
|
|
#include <gtk/gtk.h>
|
|
|
|
|
2025-06-05 02:03:07 +02:00
|
|
|
#ifdef G_OS_WIN32
|
|
|
|
#include <windows.h>
|
|
|
|
#endif
|
|
|
|
|
2003-09-10 23:42:59 +00:00
|
|
|
#include "libgimpbase/gimpbase.h"
|
2005-01-25 19:11:26 +00:00
|
|
|
#include "libgimpconfig/gimpconfig.h"
|
2003-09-10 23:42:59 +00:00
|
|
|
|
|
|
|
#include "gui-types.h"
|
|
|
|
|
|
|
|
#include "config/gimpguiconfig.h"
|
|
|
|
|
|
|
|
#include "core/gimp.h"
|
|
|
|
|
2023-10-16 16:43:17 +00:00
|
|
|
#include "display/gimpimagewindow.h"
|
|
|
|
|
|
|
|
#include "widgets/gimpwidgets-utils.h"
|
|
|
|
|
2024-01-29 19:39:38 +01:00
|
|
|
#include "icon-themes.h"
|
2003-09-10 23:42:59 +00:00
|
|
|
#include "themes.h"
|
|
|
|
|
|
|
|
#include "gimp-intl.h"
|
|
|
|
|
|
|
|
|
|
|
|
/* local function prototypes */
|
|
|
|
|
2025-05-03 22:25:56 -04:00
|
|
|
static void themes_apply_theme (Gimp *gimp,
|
|
|
|
GimpGuiConfig *config);
|
|
|
|
static void themes_list_themes_foreach (gpointer key,
|
|
|
|
gpointer value,
|
|
|
|
gpointer data);
|
|
|
|
static gint themes_name_compare (const void *p1,
|
|
|
|
const void *p2);
|
|
|
|
static void themes_theme_paths_notify (GimpExtensionManager *manager,
|
|
|
|
GParamSpec *pspec,
|
|
|
|
Gimp *gimp);
|
|
|
|
#if defined(G_OS_UNIX) && ! defined(__APPLE__)
|
|
|
|
static void themes_theme_settings_portal_changed (GDBusProxy *proxy,
|
|
|
|
const gchar *sender_name,
|
|
|
|
const gchar *signal_name,
|
|
|
|
GVariant *parameters,
|
|
|
|
Gimp *gimp);
|
|
|
|
#endif
|
2003-09-10 23:42:59 +00:00
|
|
|
|
2025-06-05 02:03:07 +02:00
|
|
|
#ifdef G_OS_WIN32
|
2025-06-06 01:26:16 +02:00
|
|
|
static gboolean themes_win32_is_darkmode_active (void);
|
2025-06-05 02:03:07 +02:00
|
|
|
#endif
|
|
|
|
|
2003-09-10 23:42:59 +00:00
|
|
|
|
|
|
|
/* private variables */
|
|
|
|
|
2025-05-03 22:25:56 -04:00
|
|
|
static GHashTable *themes_hash = NULL;
|
|
|
|
static GtkStyleProvider *themes_style_provider = NULL;
|
|
|
|
#if defined(G_OS_UNIX) && ! defined(__APPLE__)
|
|
|
|
static GDBusProxy *themes_settings_portal = NULL;
|
|
|
|
#endif
|
2003-09-10 23:42:59 +00:00
|
|
|
|
|
|
|
|
|
|
|
/* public functions */
|
|
|
|
|
|
|
|
void
|
|
|
|
themes_init (Gimp *gimp)
|
|
|
|
{
|
|
|
|
GimpGuiConfig *config;
|
2025-06-05 02:03:07 +02:00
|
|
|
#if defined(G_OS_UNIX) && ! defined(__APPLE__)
|
2025-05-03 22:25:56 -04:00
|
|
|
GError *error = NULL;
|
2025-06-05 02:03:07 +02:00
|
|
|
#endif
|
2003-09-10 23:42:59 +00:00
|
|
|
|
|
|
|
g_return_if_fail (GIMP_IS_GIMP (gimp));
|
|
|
|
|
|
|
|
config = GIMP_GUI_CONFIG (gimp->config);
|
|
|
|
|
2018-08-07 15:49:21 +02:00
|
|
|
/* Check for theme extensions. */
|
|
|
|
themes_theme_paths_notify (gimp->extension_manager, NULL, gimp);
|
|
|
|
g_signal_connect (gimp->extension_manager, "notify::theme-paths",
|
|
|
|
G_CALLBACK (themes_theme_paths_notify),
|
|
|
|
gimp);
|
2003-09-10 23:42:59 +00:00
|
|
|
|
2010-12-29 15:16:23 +01:00
|
|
|
themes_style_provider = GTK_STYLE_PROVIDER (gtk_css_provider_new ());
|
2003-11-12 12:56:31 +00:00
|
|
|
|
2010-12-29 15:16:23 +01:00
|
|
|
/* Use GTK_STYLE_PROVIDER_PRIORITY_APPLICATION + 1 so theme files
|
|
|
|
* override default styles provided by widgets themselves.
|
|
|
|
*/
|
|
|
|
gtk_style_context_add_provider_for_screen (gdk_screen_get_default (),
|
|
|
|
themes_style_provider,
|
|
|
|
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION + 1);
|
|
|
|
|
2025-05-03 22:25:56 -04:00
|
|
|
#if defined(G_OS_UNIX) && ! defined(__APPLE__)
|
|
|
|
themes_settings_portal =
|
|
|
|
g_dbus_proxy_new_for_bus_sync (G_BUS_TYPE_SESSION,
|
|
|
|
G_DBUS_PROXY_FLAGS_NONE, NULL,
|
|
|
|
"org.freedesktop.portal.Desktop",
|
|
|
|
"/org/freedesktop/portal/desktop",
|
|
|
|
"org.freedesktop.portal.Settings",
|
|
|
|
NULL, &error);
|
|
|
|
|
|
|
|
if (error)
|
|
|
|
{
|
|
|
|
g_printerr ("Could not access portal: %s", error->message);
|
|
|
|
g_clear_error (&error);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
g_signal_connect (themes_settings_portal,
|
|
|
|
"g-signal::SettingChanged",
|
|
|
|
G_CALLBACK (themes_theme_settings_portal_changed),
|
|
|
|
gimp);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2003-11-11 23:56:00 +00:00
|
|
|
g_signal_connect (config, "notify::theme",
|
|
|
|
G_CALLBACK (themes_theme_change_notify),
|
|
|
|
gimp);
|
2024-01-29 19:39:38 +01:00
|
|
|
g_signal_connect_after (config, "notify::icon-theme",
|
|
|
|
G_CALLBACK (themes_theme_change_notify),
|
|
|
|
gimp);
|
app, themes: merge the Gray and Default themes and add theme color scheme concept.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
2024-01-25 18:16:15 +01:00
|
|
|
g_signal_connect (config, "notify::theme-color-scheme",
|
2018-05-01 04:43:33 +02:00
|
|
|
G_CALLBACK (themes_theme_change_notify),
|
|
|
|
gimp);
|
2018-06-08 03:29:47 +02:00
|
|
|
g_signal_connect (config, "notify::prefer-symbolic-icons",
|
|
|
|
G_CALLBACK (themes_theme_change_notify),
|
|
|
|
gimp);
|
Issue #7023: icon size selection on GIMP 2.99.
This kinda reverts commit 6aebd30de142286c41e6cd90abedc4082a13fcea ("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.
2022-09-26 22:56:08 +02:00
|
|
|
g_signal_connect (config, "notify::override-theme-icon-size",
|
|
|
|
G_CALLBACK (themes_theme_change_notify),
|
|
|
|
gimp);
|
|
|
|
g_signal_connect (config, "notify::custom-icon-size",
|
|
|
|
G_CALLBACK (themes_theme_change_notify),
|
|
|
|
gimp);
|
Issue #2902: Preference option to set "Interface/Theme" font size.
Though GTK+3 is supposed to take care of scaling fonts with high density
displays, it turns out it is not enough for many, for various reasons (taste,
eyesight, distance to the display…). So we add this additional settings to tweak
further the font size.
With Aryeom, we experimented/discussed both a percentage UI vs. an absolute font
size field (e.g. as they provide in GNOME Tweaks). In the end, we went for a
percentage UI because we realize that we don't necessarily know what is the
current size at all. Mostly you just want bigger or smaller, and don't
necessarily care so much at which value is the font size.
This settings only has a single limitation (that we could find), which is when
used on a theme with widget rules using absolute font-size rules (px, or
keywords such as small/medium/large). As long as the CSS rules are relative
though (either to the parent widget, or to the root size), then it works fine.
Basically a theme hard-coding font sizes won't fare well with this settings, but
since we can consider this bad practice, it's an acceptable limitation.
2023-09-25 22:09:42 +02:00
|
|
|
g_signal_connect (config, "notify::font-relative-size",
|
|
|
|
G_CALLBACK (themes_theme_change_notify),
|
|
|
|
gimp);
|
2010-12-29 15:16:23 +01:00
|
|
|
|
|
|
|
themes_theme_change_notify (config, NULL, gimp);
|
2023-10-16 16:43:17 +00:00
|
|
|
|
|
|
|
#ifdef G_OS_WIN32
|
|
|
|
themes_set_title_bar (gimp);
|
|
|
|
#endif
|
2003-11-11 23:56:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
themes_exit (Gimp *gimp)
|
|
|
|
{
|
|
|
|
g_return_if_fail (GIMP_IS_GIMP (gimp));
|
|
|
|
|
|
|
|
if (themes_hash)
|
|
|
|
{
|
|
|
|
g_signal_handlers_disconnect_by_func (gimp->config,
|
|
|
|
themes_theme_change_notify,
|
|
|
|
gimp);
|
|
|
|
|
|
|
|
g_hash_table_destroy (themes_hash);
|
|
|
|
themes_hash = NULL;
|
|
|
|
}
|
2018-04-07 12:27:53 +02:00
|
|
|
|
2010-12-29 15:16:23 +01:00
|
|
|
g_clear_object (&themes_style_provider);
|
2025-05-03 22:25:56 -04:00
|
|
|
|
|
|
|
#if defined(G_OS_UNIX) && ! defined(__APPLE__)
|
|
|
|
g_clear_object (&themes_settings_portal);
|
|
|
|
#endif
|
2003-11-11 23:56:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
gchar **
|
|
|
|
themes_list_themes (Gimp *gimp,
|
|
|
|
gint *n_themes)
|
|
|
|
{
|
|
|
|
|
|
|
|
g_return_val_if_fail (GIMP_IS_GIMP (gimp), NULL);
|
|
|
|
g_return_val_if_fail (n_themes != NULL, NULL);
|
|
|
|
|
|
|
|
*n_themes = g_hash_table_size (themes_hash);
|
|
|
|
|
|
|
|
if (*n_themes > 0)
|
|
|
|
{
|
|
|
|
gchar **themes;
|
|
|
|
gchar **index;
|
|
|
|
|
|
|
|
themes = g_new0 (gchar *, *n_themes + 1);
|
|
|
|
|
|
|
|
index = themes;
|
|
|
|
|
|
|
|
g_hash_table_foreach (themes_hash, themes_list_themes_foreach, &index);
|
|
|
|
|
2014-03-06 11:56:18 +01:00
|
|
|
qsort (themes, *n_themes, sizeof (gchar *), themes_name_compare);
|
|
|
|
|
2003-11-11 23:56:00 +00:00
|
|
|
return themes;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2014-07-17 10:09:19 +02:00
|
|
|
GFile *
|
2003-11-11 23:56:00 +00:00
|
|
|
themes_get_theme_dir (Gimp *gimp,
|
|
|
|
const gchar *theme_name)
|
|
|
|
{
|
|
|
|
g_return_val_if_fail (GIMP_IS_GIMP (gimp), NULL);
|
|
|
|
|
|
|
|
if (! theme_name)
|
2016-01-11 03:03:28 +01:00
|
|
|
theme_name = GIMP_CONFIG_DEFAULT_THEME;
|
2003-11-11 23:56:00 +00:00
|
|
|
|
|
|
|
return g_hash_table_lookup (themes_hash, theme_name);
|
|
|
|
}
|
|
|
|
|
2014-07-17 10:09:19 +02:00
|
|
|
GFile *
|
2003-11-15 17:53:18 +00:00
|
|
|
themes_get_theme_file (Gimp *gimp,
|
|
|
|
const gchar *first_component,
|
|
|
|
...)
|
|
|
|
{
|
|
|
|
GimpGuiConfig *gui_config;
|
2014-07-17 10:09:19 +02:00
|
|
|
GFile *file;
|
|
|
|
const gchar *component;
|
2003-11-15 17:53:18 +00:00
|
|
|
va_list args;
|
|
|
|
|
|
|
|
g_return_val_if_fail (GIMP_IS_GIMP (gimp), NULL);
|
|
|
|
g_return_val_if_fail (first_component != NULL, NULL);
|
|
|
|
|
2014-07-17 10:09:19 +02:00
|
|
|
gui_config = GIMP_GUI_CONFIG (gimp->config);
|
|
|
|
|
|
|
|
file = g_object_ref (themes_get_theme_dir (gimp, gui_config->theme));
|
|
|
|
component = first_component;
|
2003-11-15 17:53:18 +00:00
|
|
|
|
|
|
|
va_start (args, first_component);
|
|
|
|
|
2014-07-17 10:09:19 +02:00
|
|
|
do
|
2003-11-15 17:53:18 +00:00
|
|
|
{
|
2014-07-17 10:09:19 +02:00
|
|
|
GFile *tmp = g_file_get_child (file, component);
|
|
|
|
g_object_unref (file);
|
2003-11-15 17:53:18 +00:00
|
|
|
file = tmp;
|
|
|
|
}
|
2014-07-17 10:09:19 +02:00
|
|
|
while ((component = va_arg (args, gchar *)));
|
2003-11-15 17:53:18 +00:00
|
|
|
|
|
|
|
va_end (args);
|
|
|
|
|
2014-07-17 10:09:19 +02:00
|
|
|
if (! g_file_query_exists (file, NULL))
|
|
|
|
{
|
|
|
|
g_object_unref (file);
|
2003-11-15 17:53:18 +00:00
|
|
|
|
2014-07-17 10:09:19 +02:00
|
|
|
file = g_object_ref (themes_get_theme_dir (gimp, NULL));
|
|
|
|
component = first_component;
|
2003-11-15 17:53:18 +00:00
|
|
|
|
2014-07-17 10:09:19 +02:00
|
|
|
va_start (args, first_component);
|
2003-11-15 17:53:18 +00:00
|
|
|
|
2014-07-17 10:09:19 +02:00
|
|
|
do
|
|
|
|
{
|
|
|
|
GFile *tmp = g_file_get_child (file, component);
|
|
|
|
g_object_unref (file);
|
|
|
|
file = tmp;
|
|
|
|
}
|
|
|
|
while ((component = va_arg (args, gchar *)));
|
2003-11-15 17:53:18 +00:00
|
|
|
|
2014-07-17 10:09:19 +02:00
|
|
|
va_end (args);
|
|
|
|
}
|
2003-11-15 17:53:18 +00:00
|
|
|
|
2014-07-17 10:09:19 +02:00
|
|
|
return file;
|
2003-11-15 17:53:18 +00:00
|
|
|
}
|
|
|
|
|
2025-06-07 16:29:09 +02:00
|
|
|
void
|
|
|
|
themes_theme_change_notify (GimpGuiConfig *config,
|
|
|
|
GParamSpec *pspec,
|
|
|
|
Gimp *gimp)
|
|
|
|
{
|
|
|
|
GFile *theme_css;
|
|
|
|
GError *error = NULL;
|
|
|
|
|
|
|
|
g_object_set (gtk_settings_get_for_screen (gdk_screen_get_default ()),
|
|
|
|
"gtk-application-prefer-dark-theme",
|
|
|
|
config->theme_scheme != GIMP_THEME_LIGHT,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
themes_apply_theme (gimp, config);
|
|
|
|
|
|
|
|
theme_css = gimp_directory_file ("theme.css", NULL);
|
|
|
|
|
|
|
|
if (gimp->be_verbose)
|
|
|
|
g_print ("Parsing '%s'\n",
|
|
|
|
gimp_file_get_utf8_name (theme_css));
|
|
|
|
|
|
|
|
if (! gtk_css_provider_load_from_file (GTK_CSS_PROVIDER (themes_style_provider),
|
|
|
|
theme_css, &error))
|
|
|
|
{
|
|
|
|
g_printerr ("%s: error parsing %s: %s\n", G_STRFUNC,
|
|
|
|
gimp_file_get_utf8_name (theme_css), error->message);
|
|
|
|
g_clear_error (&error);
|
|
|
|
}
|
|
|
|
|
|
|
|
g_object_unref (theme_css);
|
|
|
|
|
|
|
|
gtk_style_context_reset_widgets (gdk_screen_get_default ());
|
|
|
|
|
|
|
|
#ifdef G_OS_WIN32
|
|
|
|
themes_set_title_bar (gimp);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2010-12-18 22:42:09 +01:00
|
|
|
|
|
|
|
/* private functions */
|
|
|
|
|
|
|
|
static void
|
2019-01-04 15:25:40 +01:00
|
|
|
themes_apply_theme (Gimp *gimp,
|
|
|
|
GimpGuiConfig *config)
|
2003-11-11 23:56:00 +00:00
|
|
|
{
|
2025-06-05 01:08:01 +02:00
|
|
|
GFile *theme_css;
|
|
|
|
GOutputStream *output;
|
|
|
|
GError *error = NULL;
|
|
|
|
gboolean prefer_dark_theme;
|
|
|
|
GimpThemeScheme color_scheme;
|
2003-11-11 23:56:00 +00:00
|
|
|
|
|
|
|
g_return_if_fail (GIMP_IS_GIMP (gimp));
|
2019-01-04 15:25:40 +01:00
|
|
|
g_return_if_fail (GIMP_IS_GUI_CONFIG (config));
|
2003-11-11 23:56:00 +00:00
|
|
|
|
2025-05-03 22:25:56 -04:00
|
|
|
#if defined(G_OS_UNIX) && ! defined(__APPLE__)
|
|
|
|
if (themes_settings_portal && config->theme_scheme == GIMP_THEME_SYSTEM)
|
|
|
|
{
|
2025-06-05 02:03:07 +02:00
|
|
|
GVariant *tuple_variant;
|
|
|
|
GVariant *variant;
|
|
|
|
|
2025-05-03 22:25:56 -04:00
|
|
|
tuple_variant = g_dbus_proxy_call_sync (themes_settings_portal,
|
|
|
|
"ReadOne",
|
|
|
|
g_variant_new ("(ss)", "org.freedesktop.appearance", "color-scheme"),
|
|
|
|
G_DBUS_CALL_FLAGS_NONE,
|
|
|
|
G_MAXINT,
|
|
|
|
NULL,
|
|
|
|
&error);
|
|
|
|
if (error)
|
|
|
|
{
|
|
|
|
g_clear_error (&error);
|
|
|
|
|
|
|
|
tuple_variant = g_dbus_proxy_call_sync (themes_settings_portal,
|
|
|
|
"Read",
|
|
|
|
g_variant_new ("(ss)", "org.freedesktop.appearance", "color-scheme"),
|
|
|
|
G_DBUS_CALL_FLAGS_NONE,
|
|
|
|
G_MAXINT,
|
|
|
|
NULL,
|
|
|
|
&error);
|
|
|
|
if (!error)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Since the org.freedesktop.portal.Settings.Read method returns
|
|
|
|
* two layers of variant, re-assign the tuple.
|
|
|
|
* https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Settings.html#org-freedesktop-portal-settings-read
|
|
|
|
*/
|
|
|
|
g_variant_get (tuple_variant, "(v)", &tuple_variant);
|
|
|
|
|
|
|
|
g_variant_get (tuple_variant, "v", &variant);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
g_variant_get (tuple_variant, "(v)", &variant);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!error)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* 1 means "Prefer dark", see:
|
|
|
|
* https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Settings.html#description
|
|
|
|
*/
|
|
|
|
prefer_dark_theme = (g_variant_get_uint32 (variant) == 1);
|
|
|
|
|
2025-06-05 01:08:01 +02:00
|
|
|
/*
|
|
|
|
* Note that normally it's a tri-state flag, with a
|
|
|
|
* prefer-light and no-preference case too, except that it
|
|
|
|
* looks like both in KDE and GNOME at least, they only set
|
|
|
|
* prefer-dark or no-preference and for us, the latter should
|
|
|
|
* also mean dark.
|
|
|
|
* Therefore for this setting to actually mean something, we
|
|
|
|
* are currently breaking the spec by having no-preference
|
|
|
|
* mean prefer-light. This should be fixed if/when the main
|
|
|
|
* desktops actually implement all 3 options some day.
|
|
|
|
*/
|
|
|
|
color_scheme = prefer_dark_theme ? GIMP_THEME_DARK : GIMP_THEME_LIGHT;
|
2025-05-03 22:25:56 -04:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
g_printerr ("%s\n", error->message);
|
|
|
|
g_clear_error (&error);
|
|
|
|
|
2025-06-05 01:08:01 +02:00
|
|
|
color_scheme = (config->theme_scheme == GIMP_THEME_SYSTEM) ? GIMP_THEME_DARK : config->theme_scheme;
|
2025-05-03 22:25:56 -04:00
|
|
|
prefer_dark_theme = (color_scheme == GIMP_THEME_DARK ||
|
|
|
|
color_scheme == GIMP_THEME_GRAY);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
2025-06-05 02:03:07 +02:00
|
|
|
#elif defined(G_OS_WIN32)
|
|
|
|
if (config->theme_scheme == GIMP_THEME_SYSTEM)
|
|
|
|
{
|
2025-06-06 01:26:16 +02:00
|
|
|
prefer_dark_theme = themes_win32_is_darkmode_active ();
|
2025-06-05 02:03:07 +02:00
|
|
|
color_scheme = prefer_dark_theme ? GIMP_THEME_DARK : GIMP_THEME_LIGHT;
|
|
|
|
}
|
|
|
|
else
|
2025-05-03 22:25:56 -04:00
|
|
|
#endif
|
|
|
|
{
|
2025-06-05 01:08:01 +02:00
|
|
|
color_scheme = (config->theme_scheme == GIMP_THEME_SYSTEM) ? GIMP_THEME_DARK : config->theme_scheme;
|
2025-05-03 22:25:56 -04:00
|
|
|
prefer_dark_theme = (color_scheme == GIMP_THEME_DARK ||
|
|
|
|
color_scheme == GIMP_THEME_GRAY);
|
|
|
|
}
|
|
|
|
|
|
|
|
g_object_set (gtk_settings_get_for_screen (gdk_screen_get_default ()),
|
|
|
|
"gtk-application-prefer-dark-theme", prefer_dark_theme,
|
|
|
|
NULL);
|
|
|
|
|
2010-12-29 15:16:23 +01:00
|
|
|
theme_css = gimp_directory_file ("theme.css", NULL);
|
2003-09-10 23:42:59 +00:00
|
|
|
|
2003-11-12 12:56:31 +00:00
|
|
|
if (gimp->be_verbose)
|
2010-12-29 15:16:23 +01:00
|
|
|
g_print ("Writing '%s'\n", gimp_file_get_utf8_name (theme_css));
|
2003-09-10 23:42:59 +00:00
|
|
|
|
2010-12-29 15:16:23 +01:00
|
|
|
output = G_OUTPUT_STREAM (g_file_replace (theme_css,
|
2014-07-05 01:42:19 +02:00
|
|
|
NULL, FALSE, G_FILE_CREATE_NONE,
|
|
|
|
NULL, &error));
|
|
|
|
if (! output)
|
2003-11-12 12:56:31 +00:00
|
|
|
{
|
2014-10-04 02:44:54 +02:00
|
|
|
gimp_message_literal (gimp, NULL, GIMP_MESSAGE_ERROR, error->message);
|
2014-07-05 01:42:19 +02:00
|
|
|
g_clear_error (&error);
|
2003-11-12 12:56:31 +00:00
|
|
|
}
|
2014-07-05 01:42:19 +02:00
|
|
|
else
|
|
|
|
{
|
2019-03-27 20:02:39 -04:00
|
|
|
GFile *theme_dir = themes_get_theme_dir (gimp, config->theme);
|
|
|
|
GFile *css_user;
|
|
|
|
GSList *css_files = NULL;
|
|
|
|
GSList *iter;
|
2014-07-05 01:42:19 +02:00
|
|
|
|
|
|
|
if (theme_dir)
|
|
|
|
{
|
app, themes: merge the Gray and Default themes and add theme color scheme concept.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
2024-01-25 18:16:15 +01:00
|
|
|
GFile *file = NULL;
|
|
|
|
GFile *fallback;
|
|
|
|
GFile *light;
|
|
|
|
GFile *gray;
|
|
|
|
GFile *dark;
|
|
|
|
|
|
|
|
fallback = g_file_get_child (theme_dir, "gimp.css");
|
|
|
|
if (! g_file_query_exists (fallback, NULL))
|
|
|
|
g_clear_object (&fallback);
|
|
|
|
|
|
|
|
light = g_file_get_child (theme_dir, "gimp-light.css");
|
|
|
|
if (! g_file_query_exists (light, NULL))
|
|
|
|
g_clear_object (&light);
|
|
|
|
|
|
|
|
gray = g_file_get_child (theme_dir, "gimp-gray.css");
|
|
|
|
if (! g_file_query_exists (gray, NULL))
|
|
|
|
g_clear_object (&gray);
|
|
|
|
|
|
|
|
dark = g_file_get_child (theme_dir, "gimp-dark.css");
|
|
|
|
if (! g_file_query_exists (dark, NULL))
|
|
|
|
g_clear_object (&dark);
|
|
|
|
|
2025-05-03 22:25:56 -04:00
|
|
|
switch (color_scheme)
|
app, themes: merge the Gray and Default themes and add theme color scheme concept.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
2024-01-25 18:16:15 +01:00
|
|
|
{
|
|
|
|
case GIMP_THEME_LIGHT:
|
|
|
|
if (light != NULL)
|
|
|
|
file = g_object_ref (light);
|
|
|
|
else if (fallback != NULL)
|
|
|
|
file = g_object_ref (fallback);
|
|
|
|
else if (gray != NULL)
|
|
|
|
file = g_object_ref (gray);
|
|
|
|
else if (dark != NULL)
|
|
|
|
file = g_object_ref (dark);
|
|
|
|
break;
|
|
|
|
case GIMP_THEME_GRAY:
|
|
|
|
if (gray != NULL)
|
|
|
|
file = g_object_ref (gray);
|
|
|
|
else if (fallback != NULL)
|
|
|
|
file = g_object_ref (fallback);
|
|
|
|
else if (dark != NULL)
|
|
|
|
file = g_object_ref (dark);
|
|
|
|
else if (light != NULL)
|
|
|
|
file = g_object_ref (light);
|
|
|
|
break;
|
|
|
|
case GIMP_THEME_DARK:
|
|
|
|
if (dark != NULL)
|
|
|
|
file = g_object_ref (dark);
|
|
|
|
else if (fallback != NULL)
|
|
|
|
file = g_object_ref (fallback);
|
|
|
|
else if (gray != NULL)
|
|
|
|
file = g_object_ref (gray);
|
|
|
|
else if (light != NULL)
|
|
|
|
file = g_object_ref (light);
|
|
|
|
break;
|
2025-06-05 01:08:01 +02:00
|
|
|
case GIMP_THEME_SYSTEM:
|
|
|
|
g_return_if_reached ();
|
app, themes: merge the Gray and Default themes and add theme color scheme concept.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
2024-01-25 18:16:15 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (file != NULL)
|
|
|
|
{
|
|
|
|
prefer_dark_theme = (file == dark || file == gray);
|
|
|
|
css_files = g_slist_prepend (css_files, file);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
gimp_message (gimp, NULL, GIMP_MESSAGE_ERROR,
|
|
|
|
_("Invalid theme: directory '%s' contains neither "
|
|
|
|
"gimp-dark.css, gimp-gray.css, gimp-light.css nor gimp.css."),
|
|
|
|
gimp_file_get_utf8_name (theme_dir));
|
|
|
|
}
|
|
|
|
|
|
|
|
g_clear_object (&fallback);
|
|
|
|
g_clear_object (&light);
|
|
|
|
g_clear_object (&gray);
|
|
|
|
g_clear_object (&dark);
|
2014-07-05 01:42:19 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2019-03-27 20:02:39 -04:00
|
|
|
gchar *tmp;
|
|
|
|
|
2010-12-29 15:16:23 +01:00
|
|
|
tmp = g_build_filename (gimp_data_directory (),
|
2022-08-21 00:51:47 +02:00
|
|
|
"themes", "Default", "gimp.css",
|
2010-12-29 15:16:23 +01:00
|
|
|
NULL);
|
app, themes: merge the Gray and Default themes and add theme color scheme concept.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
2024-01-25 18:16:15 +01:00
|
|
|
css_files = g_slist_prepend (css_files, g_file_new_for_path (tmp));
|
2010-12-29 15:16:23 +01:00
|
|
|
g_free (tmp);
|
2022-08-21 00:51:47 +02:00
|
|
|
|
2025-05-03 22:25:56 -04:00
|
|
|
switch (color_scheme)
|
2022-08-21 00:51:47 +02:00
|
|
|
{
|
app, themes: merge the Gray and Default themes and add theme color scheme concept.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
2024-01-25 18:16:15 +01:00
|
|
|
case GIMP_THEME_LIGHT:
|
|
|
|
tmp = g_build_filename (gimp_data_directory (),
|
|
|
|
"themes", "Default", "gimp-light.css",
|
|
|
|
NULL);
|
|
|
|
break;
|
|
|
|
case GIMP_THEME_GRAY:
|
|
|
|
tmp = g_build_filename (gimp_data_directory (),
|
|
|
|
"themes", "Default", "gimp-gray.css",
|
|
|
|
NULL);
|
|
|
|
break;
|
|
|
|
case GIMP_THEME_DARK:
|
2022-08-21 00:51:47 +02:00
|
|
|
tmp = g_build_filename (gimp_data_directory (),
|
|
|
|
"themes", "Default", "gimp-dark.css",
|
|
|
|
NULL);
|
app, themes: merge the Gray and Default themes and add theme color scheme concept.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
2024-01-25 18:16:15 +01:00
|
|
|
break;
|
2025-06-05 01:08:01 +02:00
|
|
|
case GIMP_THEME_SYSTEM:
|
|
|
|
g_return_if_reached ();
|
2022-08-21 00:51:47 +02:00
|
|
|
}
|
app, themes: merge the Gray and Default themes and add theme color scheme concept.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
2024-01-25 18:16:15 +01:00
|
|
|
|
|
|
|
css_files = g_slist_prepend (css_files, g_file_new_for_path (tmp));
|
|
|
|
g_free (tmp);
|
2014-07-05 01:42:19 +02:00
|
|
|
}
|
|
|
|
|
2019-03-27 20:02:39 -04:00
|
|
|
css_files = g_slist_prepend (
|
|
|
|
css_files, gimp_sysconf_directory_file ("gimp.css", NULL));
|
|
|
|
|
|
|
|
css_user = gimp_directory_file ("gimp.css", NULL);
|
|
|
|
css_files = g_slist_prepend (
|
|
|
|
css_files, css_user);
|
|
|
|
|
|
|
|
css_files = g_slist_reverse (css_files);
|
|
|
|
|
|
|
|
g_output_stream_printf (
|
|
|
|
output, NULL, NULL, &error,
|
|
|
|
"/* GIMP theme.css\n"
|
|
|
|
" *\n"
|
|
|
|
" * This file is written on GIMP startup and on every theme change.\n"
|
|
|
|
" * It is NOT supposed to be edited manually. Edit your personal\n"
|
|
|
|
" * gimp.css file instead (%s).\n"
|
|
|
|
" */\n"
|
|
|
|
"\n",
|
|
|
|
gimp_file_get_utf8_name (css_user));
|
|
|
|
|
|
|
|
for (iter = css_files; ! error && iter; iter = g_slist_next (iter))
|
|
|
|
{
|
|
|
|
GFile *file = iter->data;
|
|
|
|
|
|
|
|
if (g_file_query_exists (file, NULL))
|
|
|
|
{
|
|
|
|
gchar *path;
|
|
|
|
|
2020-09-25 13:24:28 -04:00
|
|
|
path = g_file_get_uri (file);
|
2019-03-27 20:02:39 -04:00
|
|
|
|
|
|
|
g_output_stream_printf (
|
|
|
|
output, NULL, NULL, &error,
|
|
|
|
"@import url(\"%s\");\n",
|
2020-09-25 13:24:28 -04:00
|
|
|
path);
|
2019-03-27 20:02:39 -04:00
|
|
|
|
2020-09-25 13:24:28 -04:00
|
|
|
g_free (path);
|
2019-03-27 20:02:39 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (! error)
|
|
|
|
{
|
|
|
|
g_output_stream_printf (
|
|
|
|
output, NULL, NULL, &error,
|
|
|
|
"\n"
|
|
|
|
"* { -gtk-icon-style: %s; }\n"
|
|
|
|
"\n"
|
Issue #7023: icon size selection on GIMP 2.99.
This kinda reverts commit 6aebd30de142286c41e6cd90abedc4082a13fcea ("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.
2022-09-26 22:56:08 +02:00
|
|
|
"%s",
|
2024-01-29 19:39:38 +01:00
|
|
|
icon_themes_current_prefer_symbolic (gimp) ? "symbolic" : "regular",
|
app, themes: merge the Gray and Default themes and add theme color scheme concept.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
2024-01-25 18:16:15 +01:00
|
|
|
prefer_dark_theme ? "/* prefer-dark-theme */\n" : "");
|
2024-01-29 19:39:38 +01:00
|
|
|
|
Issue #7023: icon size selection on GIMP 2.99.
This kinda reverts commit 6aebd30de142286c41e6cd90abedc4082a13fcea ("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.
2022-09-26 22:56:08 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (! error && config->override_icon_size)
|
|
|
|
{
|
|
|
|
const gchar *tool_icon_size = "large-toolbar";
|
|
|
|
const gchar *tab_icon_size = "small-toolbar";
|
|
|
|
const gchar *button_icon_size = "small-toolbar";
|
2024-01-31 14:37:57 +01:00
|
|
|
gint pal_padding = 4;
|
|
|
|
gint tab_padding = 1;
|
|
|
|
gint sep_padding = 1;
|
Issue #7023: icon size selection on GIMP 2.99.
This kinda reverts commit 6aebd30de142286c41e6cd90abedc4082a13fcea ("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.
2022-09-26 22:56:08 +02:00
|
|
|
|
|
|
|
switch (config->custom_icon_size)
|
|
|
|
{
|
|
|
|
case GIMP_ICON_SIZE_SMALL:
|
|
|
|
tool_icon_size = "small-toolbar";
|
|
|
|
tab_icon_size = "small-toolbar";
|
|
|
|
button_icon_size = "small-toolbar";
|
2024-01-31 14:37:57 +01:00
|
|
|
pal_padding = 1;
|
|
|
|
tab_padding = 0;
|
|
|
|
sep_padding = 1;
|
Issue #7023: icon size selection on GIMP 2.99.
This kinda reverts commit 6aebd30de142286c41e6cd90abedc4082a13fcea ("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.
2022-09-26 22:56:08 +02:00
|
|
|
break;
|
|
|
|
case GIMP_ICON_SIZE_MEDIUM:
|
|
|
|
tool_icon_size = "large-toolbar";
|
|
|
|
tab_icon_size = "small-toolbar";
|
|
|
|
button_icon_size = "small-toolbar";
|
2024-01-31 14:37:57 +01:00
|
|
|
pal_padding = 4;
|
|
|
|
tab_padding = 1;
|
|
|
|
sep_padding = 1;
|
Issue #7023: icon size selection on GIMP 2.99.
This kinda reverts commit 6aebd30de142286c41e6cd90abedc4082a13fcea ("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.
2022-09-26 22:56:08 +02:00
|
|
|
break;
|
|
|
|
case GIMP_ICON_SIZE_LARGE:
|
|
|
|
tool_icon_size = "dnd";
|
|
|
|
tab_icon_size = "large-toolbar";
|
|
|
|
button_icon_size = "large-toolbar";
|
2024-01-31 14:37:57 +01:00
|
|
|
pal_padding = 5;
|
|
|
|
tab_padding = 5;
|
|
|
|
sep_padding = 2;
|
Issue #7023: icon size selection on GIMP 2.99.
This kinda reverts commit 6aebd30de142286c41e6cd90abedc4082a13fcea ("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.
2022-09-26 22:56:08 +02:00
|
|
|
break;
|
|
|
|
case GIMP_ICON_SIZE_HUGE:
|
|
|
|
tool_icon_size = "dialog";
|
|
|
|
tab_icon_size = "dnd";
|
|
|
|
button_icon_size = "dnd";
|
2024-01-31 14:37:57 +01:00
|
|
|
pal_padding = 5;
|
|
|
|
tab_padding = 8;
|
|
|
|
sep_padding = 4;
|
Issue #7023: icon size selection on GIMP 2.99.
This kinda reverts commit 6aebd30de142286c41e6cd90abedc4082a13fcea ("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.
2022-09-26 22:56:08 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
g_output_stream_printf (
|
|
|
|
output, NULL, NULL, &error,
|
|
|
|
"\n"
|
|
|
|
"* { -GimpToolPalette-tool-icon-size: %s; }"
|
|
|
|
"\n"
|
2024-07-27 15:39:05 +00:00
|
|
|
"* { -GimpDock-tool-icon-size: %s; }"
|
|
|
|
"\n"
|
Issue #7023: icon size selection on GIMP 2.99.
This kinda reverts commit 6aebd30de142286c41e6cd90abedc4082a13fcea ("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.
2022-09-26 22:56:08 +02:00
|
|
|
"* { -GimpDockbook-tab-icon-size: %s; }"
|
|
|
|
"\n"
|
2024-06-25 12:40:04 +00:00
|
|
|
"* { -GimpColorNotebook-tab-icon-size: %s; }"
|
|
|
|
"\n"
|
2024-08-04 12:55:58 +00:00
|
|
|
"* { -GimpPrefsBox-tab-icon-size: %s; }"
|
|
|
|
"\n"
|
2024-01-31 14:37:57 +01:00
|
|
|
"* { -GimpEditor-button-icon-size: %s; }"
|
|
|
|
"\n"
|
2024-07-22 01:33:19 +00:00
|
|
|
"* { -GimpDisplayShell-button-icon-size: %s; }"
|
|
|
|
"\n"
|
2024-07-21 03:05:43 +00:00
|
|
|
"* { -GimpFgBgEditor-tool-icon-size: %s; }"
|
|
|
|
"\n"
|
2024-01-31 14:37:57 +01:00
|
|
|
"toolpalette button { padding: %dpx; }"
|
|
|
|
"\n"
|
|
|
|
"button, tab { padding: %dpx; }"
|
|
|
|
"\n"
|
|
|
|
"paned separator { padding: %dpx; }",
|
2024-07-27 15:39:05 +00:00
|
|
|
tool_icon_size, tool_icon_size, tab_icon_size, tab_icon_size,
|
2024-08-04 12:55:58 +00:00
|
|
|
tab_icon_size, button_icon_size, button_icon_size, tool_icon_size,
|
|
|
|
pal_padding, tab_padding, sep_padding);
|
Issue #7023: icon size selection on GIMP 2.99.
This kinda reverts commit 6aebd30de142286c41e6cd90abedc4082a13fcea ("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.
2022-09-26 22:56:08 +02:00
|
|
|
}
|
|
|
|
|
Issue #2902: Preference option to set "Interface/Theme" font size.
Though GTK+3 is supposed to take care of scaling fonts with high density
displays, it turns out it is not enough for many, for various reasons (taste,
eyesight, distance to the display…). So we add this additional settings to tweak
further the font size.
With Aryeom, we experimented/discussed both a percentage UI vs. an absolute font
size field (e.g. as they provide in GNOME Tweaks). In the end, we went for a
percentage UI because we realize that we don't necessarily know what is the
current size at all. Mostly you just want bigger or smaller, and don't
necessarily care so much at which value is the font size.
This settings only has a single limitation (that we could find), which is when
used on a theme with widget rules using absolute font-size rules (px, or
keywords such as small/medium/large). As long as the CSS rules are relative
though (either to the parent widget, or to the root size), then it works fine.
Basically a theme hard-coding font sizes won't fare well with this settings, but
since we can consider this bad practice, it's an acceptable limitation.
2023-09-25 22:09:42 +02:00
|
|
|
if (! error && config->font_relative_size != 1.0)
|
2024-03-15 03:10:26 +00:00
|
|
|
{
|
2024-03-15 15:27:27 +01:00
|
|
|
/* Intermediate buffer for locale-independent float to string
|
|
|
|
* conversion. See issue #11048.
|
|
|
|
*/
|
|
|
|
gchar font_size_string[G_ASCII_DTOSTR_BUF_SIZE];
|
2024-03-15 03:10:26 +00:00
|
|
|
|
|
|
|
g_output_stream_printf (output, NULL, NULL, &error,
|
|
|
|
"\n"
|
|
|
|
"* { font-size: %srem; }",
|
2024-03-15 15:27:27 +01:00
|
|
|
g_ascii_dtostr (font_size_string,
|
|
|
|
G_ASCII_DTOSTR_BUF_SIZE,
|
|
|
|
config->font_relative_size));
|
2024-03-15 03:10:26 +00:00
|
|
|
}
|
Issue #2902: Preference option to set "Interface/Theme" font size.
Though GTK+3 is supposed to take care of scaling fonts with high density
displays, it turns out it is not enough for many, for various reasons (taste,
eyesight, distance to the display…). So we add this additional settings to tweak
further the font size.
With Aryeom, we experimented/discussed both a percentage UI vs. an absolute font
size field (e.g. as they provide in GNOME Tweaks). In the end, we went for a
percentage UI because we realize that we don't necessarily know what is the
current size at all. Mostly you just want bigger or smaller, and don't
necessarily care so much at which value is the font size.
This settings only has a single limitation (that we could find), which is when
used on a theme with widget rules using absolute font-size rules (px, or
keywords such as small/medium/large). As long as the CSS rules are relative
though (either to the parent widget, or to the root size), then it works fine.
Basically a theme hard-coding font sizes won't fare well with this settings, but
since we can consider this bad practice, it's an acceptable limitation.
2023-09-25 22:09:42 +02:00
|
|
|
|
Issue #7023: icon size selection on GIMP 2.99.
This kinda reverts commit 6aebd30de142286c41e6cd90abedc4082a13fcea ("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.
2022-09-26 22:56:08 +02:00
|
|
|
if (! error)
|
|
|
|
{
|
|
|
|
g_output_stream_printf (
|
|
|
|
output, NULL, NULL, &error,
|
|
|
|
"\n\n"
|
|
|
|
"/* end of theme.css */\n");
|
2019-03-27 20:02:39 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
if (error)
|
2014-07-05 01:42:19 +02:00
|
|
|
{
|
2018-11-26 15:40:38 +01:00
|
|
|
GCancellable *cancellable = g_cancellable_new ();
|
|
|
|
|
2014-07-05 01:42:19 +02:00
|
|
|
gimp_message (gimp, NULL, GIMP_MESSAGE_ERROR,
|
|
|
|
_("Error writing '%s': %s"),
|
2010-12-29 15:16:23 +01:00
|
|
|
gimp_file_get_utf8_name (theme_css), error->message);
|
2014-07-05 01:42:19 +02:00
|
|
|
g_clear_error (&error);
|
2018-11-26 15:40:38 +01:00
|
|
|
|
|
|
|
/* Cancel the overwrite initiated by g_file_replace(). */
|
|
|
|
g_cancellable_cancel (cancellable);
|
|
|
|
g_output_stream_close (output, cancellable, NULL);
|
|
|
|
g_object_unref (cancellable);
|
|
|
|
}
|
|
|
|
else if (! g_output_stream_close (output, NULL, &error))
|
|
|
|
{
|
|
|
|
gimp_message (gimp, NULL, GIMP_MESSAGE_ERROR,
|
|
|
|
_("Error closing '%s': %s"),
|
|
|
|
gimp_file_get_utf8_name (theme_css), error->message);
|
|
|
|
g_clear_error (&error);
|
2014-07-05 01:42:19 +02:00
|
|
|
}
|
|
|
|
|
2019-03-27 20:02:39 -04:00
|
|
|
g_slist_free_full (css_files, g_object_unref);
|
2014-07-05 01:42:19 +02:00
|
|
|
g_object_unref (output);
|
|
|
|
}
|
2003-11-12 12:56:31 +00:00
|
|
|
|
2010-12-29 15:16:23 +01:00
|
|
|
g_object_unref (theme_css);
|
2003-09-10 23:42:59 +00:00
|
|
|
}
|
|
|
|
|
2003-11-11 23:56:00 +00:00
|
|
|
static void
|
|
|
|
themes_list_themes_foreach (gpointer key,
|
|
|
|
gpointer value,
|
|
|
|
gpointer data)
|
|
|
|
{
|
|
|
|
gchar ***index = data;
|
2003-09-10 23:42:59 +00:00
|
|
|
|
2003-11-11 23:56:00 +00:00
|
|
|
**index = g_strdup ((gchar *) key);
|
|
|
|
|
2004-01-21 12:03:26 +00:00
|
|
|
(*index)++;
|
2003-11-11 23:56:00 +00:00
|
|
|
}
|
2003-09-10 23:42:59 +00:00
|
|
|
|
2014-03-06 11:56:18 +01:00
|
|
|
static gint
|
|
|
|
themes_name_compare (const void *p1,
|
|
|
|
const void *p2)
|
|
|
|
{
|
|
|
|
return strcmp (* (char **) p1, * (char **) p2);
|
|
|
|
}
|
|
|
|
|
2018-08-07 15:49:21 +02:00
|
|
|
static void
|
|
|
|
themes_theme_paths_notify (GimpExtensionManager *manager,
|
|
|
|
GParamSpec *pspec,
|
|
|
|
Gimp *gimp)
|
|
|
|
{
|
|
|
|
GimpGuiConfig *config;
|
|
|
|
|
|
|
|
g_return_if_fail (GIMP_IS_GIMP (gimp));
|
|
|
|
|
|
|
|
if (themes_hash)
|
|
|
|
g_hash_table_remove_all (themes_hash);
|
|
|
|
else
|
|
|
|
themes_hash = g_hash_table_new_full (g_str_hash,
|
|
|
|
g_str_equal,
|
|
|
|
g_free,
|
|
|
|
g_object_unref);
|
|
|
|
|
|
|
|
config = GIMP_GUI_CONFIG (gimp->config);
|
|
|
|
if (config->theme_path)
|
|
|
|
{
|
|
|
|
GList *path;
|
|
|
|
GList *list;
|
|
|
|
|
|
|
|
g_object_get (gimp->extension_manager,
|
|
|
|
"theme-paths", &path,
|
|
|
|
NULL);
|
|
|
|
path = g_list_copy_deep (path, (GCopyFunc) g_object_ref, NULL);
|
|
|
|
path = g_list_concat (path, gimp_config_path_expand_to_files (config->theme_path, NULL));
|
|
|
|
|
|
|
|
for (list = path; list; list = g_list_next (list))
|
|
|
|
{
|
|
|
|
GFile *dir = list->data;
|
|
|
|
GFileEnumerator *enumerator;
|
|
|
|
|
|
|
|
enumerator =
|
|
|
|
g_file_enumerate_children (dir,
|
|
|
|
G_FILE_ATTRIBUTE_STANDARD_NAME ","
|
|
|
|
G_FILE_ATTRIBUTE_STANDARD_IS_HIDDEN ","
|
|
|
|
G_FILE_ATTRIBUTE_STANDARD_TYPE,
|
|
|
|
G_FILE_QUERY_INFO_NONE,
|
|
|
|
NULL, NULL);
|
|
|
|
|
|
|
|
if (enumerator)
|
|
|
|
{
|
|
|
|
GFileInfo *info;
|
|
|
|
|
|
|
|
while ((info = g_file_enumerator_next_file (enumerator,
|
|
|
|
NULL, NULL)))
|
|
|
|
{
|
2023-09-19 14:38:42 +02:00
|
|
|
if (! g_file_info_get_attribute_boolean (info, G_FILE_ATTRIBUTE_STANDARD_IS_HIDDEN) &&
|
|
|
|
g_file_info_get_attribute_uint32 (info, G_FILE_ATTRIBUTE_STANDARD_TYPE) == G_FILE_TYPE_DIRECTORY)
|
2018-08-07 15:49:21 +02:00
|
|
|
{
|
|
|
|
GFile *file;
|
|
|
|
const gchar *name;
|
|
|
|
gchar *basename;
|
|
|
|
|
|
|
|
file = g_file_enumerator_get_child (enumerator, info);
|
|
|
|
name = gimp_file_get_utf8_name (file);
|
|
|
|
|
|
|
|
basename = g_path_get_basename (name);
|
|
|
|
|
|
|
|
if (gimp->be_verbose)
|
|
|
|
g_print ("Adding theme '%s' (%s)\n",
|
|
|
|
basename, name);
|
|
|
|
|
|
|
|
g_hash_table_insert (themes_hash, basename, file);
|
|
|
|
}
|
|
|
|
|
|
|
|
g_object_unref (info);
|
|
|
|
}
|
|
|
|
|
|
|
|
g_object_unref (enumerator);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
g_list_free_full (path, (GDestroyNotify) g_object_unref);
|
|
|
|
}
|
|
|
|
}
|
2023-10-16 16:43:17 +00:00
|
|
|
|
2025-05-03 22:25:56 -04:00
|
|
|
#if defined(G_OS_UNIX) && ! defined(__APPLE__)
|
|
|
|
static void
|
|
|
|
themes_theme_settings_portal_changed (GDBusProxy *proxy,
|
|
|
|
const gchar *sender_name,
|
|
|
|
const gchar *signal_name,
|
|
|
|
GVariant *parameters,
|
|
|
|
Gimp *gimp)
|
|
|
|
{
|
|
|
|
const char *namespace;
|
|
|
|
const char *name;
|
|
|
|
GVariant *value = NULL;
|
|
|
|
|
|
|
|
if (g_strcmp0 (signal_name, "SettingChanged"))
|
|
|
|
return;
|
|
|
|
|
|
|
|
g_variant_get (parameters, "(&s&sv)", &namespace, &name, &value);
|
|
|
|
|
|
|
|
if (g_strcmp0 (namespace, "org.freedesktop.appearance") == 0 &&
|
|
|
|
g_strcmp0 (name, "color-scheme") == 0)
|
|
|
|
{
|
|
|
|
themes_theme_change_notify (GIMP_GUI_CONFIG (gimp->config), NULL, gimp);
|
|
|
|
}
|
|
|
|
|
|
|
|
g_variant_unref (value);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2024-04-11 14:59:15 +00:00
|
|
|
#ifdef G_OS_WIN32
|
2023-10-16 16:43:17 +00:00
|
|
|
void
|
|
|
|
themes_set_title_bar (Gimp *gimp)
|
|
|
|
{
|
|
|
|
GList *windows = gimp_get_image_windows (gimp);
|
|
|
|
GList *iter;
|
|
|
|
|
|
|
|
for (iter = windows; iter; iter = g_list_next (iter))
|
|
|
|
{
|
|
|
|
GtkWidget *window = GTK_WIDGET (windows->data);
|
|
|
|
|
2024-04-11 14:59:15 +00:00
|
|
|
gimp_window_set_title_bar_theme (gimp, window);
|
2023-10-16 16:43:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (windows)
|
|
|
|
g_list_free (windows);
|
|
|
|
}
|
2025-06-05 02:03:07 +02:00
|
|
|
|
|
|
|
static gboolean
|
2025-06-06 01:26:16 +02:00
|
|
|
themes_win32_is_darkmode_active (void)
|
2025-06-05 02:03:07 +02:00
|
|
|
{
|
|
|
|
DWORD val = 0;
|
|
|
|
DWORD val_size = sizeof (val);
|
|
|
|
LSTATUS status;
|
|
|
|
|
|
|
|
status = RegGetValueA(HKEY_CURRENT_USER,
|
|
|
|
"Software\\Microsoft\\Windows\\CurrentVersion\\Themes\\Personalize",
|
|
|
|
"AppsUseLightTheme",
|
|
|
|
RRF_RT_REG_DWORD,
|
|
|
|
NULL,
|
|
|
|
&val,
|
|
|
|
&val_size);
|
|
|
|
|
|
|
|
return status == ERROR_SUCCESS && val == 0;
|
|
|
|
}
|
2024-04-11 14:59:15 +00:00
|
|
|
#endif
|