gimp/app/gui/themes.c

670 lines
20 KiB
C
Raw Normal View History

/* GIMP - The GNU Image Manipulation Program
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
* (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
* along with this program. If not, see <https://www.gnu.org/licenses/>.
*/
#include "config.h"
#include <stdlib.h>
#include <gegl.h>
#include <gtk/gtk.h>
#include "libgimpbase/gimpbase.h"
2005-01-25 19:11:26 +00:00
#include "libgimpconfig/gimpconfig.h"
#include "gui-types.h"
#include "config/gimpguiconfig.h"
#include "core/gimp.h"
#include "display/gimpimagewindow.h"
#include "widgets/gimpwidgets-utils.h"
#include "icon-themes.h"
#include "themes.h"
#include "gimp-intl.h"
/* local function prototypes */
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_change_notify (GimpGuiConfig *config,
GParamSpec *pspec,
Gimp *gimp);
static void themes_theme_paths_notify (GimpExtensionManager *manager,
GParamSpec *pspec,
Gimp *gimp);
/* private variables */
static GHashTable *themes_hash = NULL;
static GtkStyleProvider *themes_style_provider = NULL;
/* public functions */
void
themes_init (Gimp *gimp)
{
GimpGuiConfig *config;
g_return_if_fail (GIMP_IS_GIMP (gimp));
config = GIMP_GUI_CONFIG (gimp->config);
/* 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);
themes_style_provider = GTK_STYLE_PROVIDER (gtk_css_provider_new ());
/* 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);
g_signal_connect (config, "notify::theme",
G_CALLBACK (themes_theme_change_notify),
gimp);
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",
G_CALLBACK (themes_theme_change_notify),
gimp);
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);
g_signal_connect (config, "notify::font-relative-size",
G_CALLBACK (themes_theme_change_notify),
gimp);
themes_theme_change_notify (config, NULL, gimp);
#ifdef G_OS_WIN32
themes_set_title_bar (gimp);
#endif
}
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;
}
g_clear_object (&themes_style_provider);
}
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);
qsort (themes, *n_themes, sizeof (gchar *), themes_name_compare);
return themes;
}
return NULL;
}
GFile *
themes_get_theme_dir (Gimp *gimp,
const gchar *theme_name)
{
g_return_val_if_fail (GIMP_IS_GIMP (gimp), NULL);
if (! theme_name)
theme_name = GIMP_CONFIG_DEFAULT_THEME;
return g_hash_table_lookup (themes_hash, theme_name);
}
GFile *
themes_get_theme_file (Gimp *gimp,
const gchar *first_component,
...)
{
GimpGuiConfig *gui_config;
GFile *file;
const gchar *component;
va_list args;
g_return_val_if_fail (GIMP_IS_GIMP (gimp), NULL);
g_return_val_if_fail (first_component != NULL, NULL);
gui_config = GIMP_GUI_CONFIG (gimp->config);
file = g_object_ref (themes_get_theme_dir (gimp, gui_config->theme));
component = first_component;
va_start (args, first_component);
do
{
GFile *tmp = g_file_get_child (file, component);
g_object_unref (file);
file = tmp;
}
while ((component = va_arg (args, gchar *)));
va_end (args);
if (! g_file_query_exists (file, NULL))
{
g_object_unref (file);
file = g_object_ref (themes_get_theme_dir (gimp, NULL));
component = first_component;
va_start (args, first_component);
do
{
GFile *tmp = g_file_get_child (file, component);
g_object_unref (file);
file = tmp;
}
while ((component = va_arg (args, gchar *)));
va_end (args);
}
return file;
}
/* private functions */
static void
themes_apply_theme (Gimp *gimp,
GimpGuiConfig *config)
{
GFile *theme_css;
2014-07-05 01:42:19 +02:00
GOutputStream *output;
GError *error = 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
gboolean prefer_dark_theme;
g_return_if_fail (GIMP_IS_GIMP (gimp));
g_return_if_fail (GIMP_IS_GUI_CONFIG (config));
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 = (config->theme_scheme != GIMP_THEME_LIGHT);
theme_css = gimp_directory_file ("theme.css", NULL);
if (gimp->be_verbose)
g_print ("Writing '%s'\n", gimp_file_get_utf8_name (theme_css));
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)
{
gimp_message_literal (gimp, NULL, GIMP_MESSAGE_ERROR, error->message);
2014-07-05 01:42:19 +02:00
g_clear_error (&error);
}
2014-07-05 01:42:19 +02:00
else
{
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);
switch (config->theme_scheme)
{
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;
}
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
{
gchar *tmp;
tmp = g_build_filename (gimp_data_directory (),
"themes", "Default", "gimp.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
css_files = g_slist_prepend (css_files, g_file_new_for_path (tmp));
g_free (tmp);
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
switch (config->theme_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:
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:
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;
}
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
}
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;
path = g_file_get_uri (file);
g_output_stream_printf (
output, NULL, NULL, &error,
"@import url(\"%s\");\n",
path);
g_free (path);
}
}
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",
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" : "");
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";
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";
break;
case GIMP_ICON_SIZE_MEDIUM:
tool_icon_size = "large-toolbar";
tab_icon_size = "small-toolbar";
button_icon_size = "small-toolbar";
break;
case GIMP_ICON_SIZE_LARGE:
tool_icon_size = "dnd";
tab_icon_size = "large-toolbar";
button_icon_size = "large-toolbar";
break;
case GIMP_ICON_SIZE_HUGE:
tool_icon_size = "dialog";
tab_icon_size = "dnd";
button_icon_size = "dnd";
break;
}
g_output_stream_printf (
output, NULL, NULL, &error,
"\n"
"* { -GimpToolPalette-tool-icon-size: %s; }"
"\n"
"* { -GimpDockbook-tab-icon-size: %s; }"
"\n"
"* { -GimpEditor-button-icon-size: %s; }",
tool_icon_size,
tab_icon_size,
button_icon_size);
}
if (! error && config->font_relative_size != 1.0)
g_output_stream_printf (output, NULL, NULL, &error,
"\n"
"* { font-size: %frem; }",
config->font_relative_size);
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");
}
if (error)
2014-07-05 01:42:19 +02: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"),
gimp_file_get_utf8_name (theme_css), error->message);
2014-07-05 01:42:19 +02:00
g_clear_error (&error);
/* 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
}
g_slist_free_full (css_files, g_object_unref);
2014-07-05 01:42:19 +02:00
g_object_unref (output);
}
g_object_unref (theme_css);
}
static void
themes_list_themes_foreach (gpointer key,
gpointer value,
gpointer data)
{
gchar ***index = data;
**index = g_strdup ((gchar *) key);
(*index)++;
}
static gint
themes_name_compare (const void *p1,
const void *p2)
{
return strcmp (* (char **) p1, * (char **) p2);
}
static 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 ()),
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
"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
}
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)))
{
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)
{
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);
}
}
void
themes_set_title_bar (Gimp *gimp)
{
#ifdef G_OS_WIN32
GList *windows = gimp_get_image_windows (gimp);
GList *iter;
for (iter = windows; iter; iter = g_list_next (iter))
{
GtkWidget *window = GTK_WIDGET (windows->data);
gimp_window_set_title_bar_theme (gimp, window, TRUE);
}
if (windows)
g_list_free (windows);
#endif
}