gimp/libgimpwidgets/gimpwidgets-private.c

283 lines
9.2 KiB
C
Raw Normal View History

/* LIBGIMP - The GIMP Library
* Copyright (C) 1995-1997 Peter Mattis and Spencer Kimball
*
* gimpwidgets-private.c
* Copyright (C) 2003 Sven Neumann <sven@gimp.org>
*
* This library is free software: you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 3 of the License, or (at your option) any later version.
*
* This library 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
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see
* <https://www.gnu.org/licenses/>.
*/
#include "config.h"
#include <babl/babl.h>
#include <gtk/gtk.h>
#include "libgimpbase/gimpbase.h"
#include "gimpwidgetstypes.h"
#include "gimpicons.h"
#include "gimpwidgets-private.h"
#include "libgimp/libgimp-intl.h"
static gboolean gimp_widgets_initialized = FALSE;
added new API gimp_color_button_[get|set]_update() which configures the 2003-11-11 Michael Natterer <mitch@gimp.org> * libgimpwidgets/gimpcolorbutton.[ch]: added new API gimp_color_button_[get|set]_update() which configures the button to emit "color_changed" continuously while the color in the color selection dialog is being changed. Fixes bug #90091. Renamed GimpColorButton struct member "GtkItemFactory *item_factory" to a /*< private >*/ member named "gpointer popup_menu". This is ugly but fixes bug #125115, * app/display/gimpdisplayshell-callbacks.c * app/display/gimpdisplayshell.c * app/widgets/gimpcolorpanel.c: changed accordingly. * libgimpwidgets/gimpcolorbutton.c: use a GimpColorSelection with a handmade GimpDialog instead of GtkColorSelectionDialog. Enabled module loading for plug-ins so the color selection can show the color selectors which are implemented in modules: * libgimpwidgets/gimpwidgets-private.[ch]: added GimpEnsureModlesFunc which can be called by modules users. * app/gui/gui.c (gui_libs_init): pass NULL as GimpEnsureModulesFunc since the core loads the modules itself. * libgimp/gimpui.c (gimp_ui_init): pass new private function gimp_ensure_modules() which will load the modules upon first invocation. * libgimp/Makefile.am: link libgimpui against libgimpmodule. * libgimpwidgets/gimpcolorselection.c: call _gimp_ensure_modules_func() if it is non-NULL so color selector modules are available for plug-ins. * tools/pdbgen/pdb/gimprc.pdb: added new PDB wrapper gimp_get_module_load_inhibit(). * app/pdb/gimprc_cmds.c * app/pdb/internal_procs.c * libgimp/gimpgimprc_pdb.[ch]: regenerated.
2003-11-12 01:55:45 +08:00
GimpHelpFunc _gimp_standard_help_func = NULL;
GimpGetColorFunc _gimp_get_foreground_func = NULL;
GimpGetColorFunc _gimp_get_background_func = NULL;
GimpEnsureModulesFunc _gimp_ensure_modules_func = NULL;
static void
gimp_widgets_init_foreign_enums (void)
{
static const GimpEnumDesc input_mode_descs[] =
{
{ GDK_MODE_DISABLED, NC_("input-mode", "Disabled"), NULL },
{ GDK_MODE_SCREEN, NC_("input-mode", "Screen"), NULL },
{ GDK_MODE_WINDOW, NC_("input-mode", "Window"), NULL },
{ 0, NULL, NULL }
};
gimp_type_set_translation_domain (GDK_TYPE_INPUT_MODE,
GETTEXT_PACKAGE "-libgimp");
gimp_type_set_translation_context (GDK_TYPE_INPUT_MODE, "input-mode");
gimp_enum_set_value_descriptions (GDK_TYPE_INPUT_MODE, input_mode_descs);
}
void
gimp_widgets_init (GimpHelpFunc standard_help_func,
GimpGetColorFunc get_foreground_func,
GimpGetColorFunc get_background_func,
GimpEnsureModulesFunc ensure_modules_func,
const gchar *test_base_dir)
{
GList *icons = NULL;
const gchar *cat_dir;
gchar *base_dir;
gchar *path;
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
GdkPixbuf *pixbuf;
GError *error = NULL;
g_return_if_fail (standard_help_func != NULL);
if (gimp_widgets_initialized)
g_error ("gimp_widgets_init() must only be called once!");
_gimp_standard_help_func = standard_help_func;
_gimp_get_foreground_func = get_foreground_func;
_gimp_get_background_func = get_background_func;
added new API gimp_color_button_[get|set]_update() which configures the 2003-11-11 Michael Natterer <mitch@gimp.org> * libgimpwidgets/gimpcolorbutton.[ch]: added new API gimp_color_button_[get|set]_update() which configures the button to emit "color_changed" continuously while the color in the color selection dialog is being changed. Fixes bug #90091. Renamed GimpColorButton struct member "GtkItemFactory *item_factory" to a /*< private >*/ member named "gpointer popup_menu". This is ugly but fixes bug #125115, * app/display/gimpdisplayshell-callbacks.c * app/display/gimpdisplayshell.c * app/widgets/gimpcolorpanel.c: changed accordingly. * libgimpwidgets/gimpcolorbutton.c: use a GimpColorSelection with a handmade GimpDialog instead of GtkColorSelectionDialog. Enabled module loading for plug-ins so the color selection can show the color selectors which are implemented in modules: * libgimpwidgets/gimpwidgets-private.[ch]: added GimpEnsureModlesFunc which can be called by modules users. * app/gui/gui.c (gui_libs_init): pass NULL as GimpEnsureModulesFunc since the core loads the modules itself. * libgimp/gimpui.c (gimp_ui_init): pass new private function gimp_ensure_modules() which will load the modules upon first invocation. * libgimp/Makefile.am: link libgimpui against libgimpmodule. * libgimpwidgets/gimpcolorselection.c: call _gimp_ensure_modules_func() if it is non-NULL so color selector modules are available for plug-ins. * tools/pdbgen/pdb/gimprc.pdb: added new PDB wrapper gimp_get_module_load_inhibit(). * app/pdb/gimprc_cmds.c * app/pdb/internal_procs.c * libgimp/gimpgimprc_pdb.[ch]: regenerated.
2003-11-12 01:55:45 +08:00
_gimp_ensure_modules_func = ensure_modules_func;
babl_init (); /* color selectors use babl */
gimp_icons_init ();
if (test_base_dir)
{
cat_dir = "";
base_dir = g_build_filename (test_base_dir, "desktop", NULL);
}
else
{
cat_dir = "apps";
#ifdef ENABLE_RELOCATABLE_RESOURCES
base_dir = g_build_filename (gimp_installation_directory (), "share", "icons", "hicolor", NULL);
#else
base_dir = g_build_filename (DATAROOTDIR, "icons", "hicolor", NULL);
#endif
}
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
/* Loading the application icons. Unfortunately GTK doesn't know how
* to load any size from a single SVG, so we have to generate common
* sizes ourselves.
* To be fair, it could with gtk_window_set_default_icon_name() but
* then the application icon is dependant to the theme and for now at
* least, we want the installed icon.
*/
path = g_build_filename (base_dir, "16x16", cat_dir, "gimp.png", NULL);
pixbuf = gdk_pixbuf_new_from_file (path, &error);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
if (pixbuf)
icons = g_list_prepend (icons, pixbuf);
else
g_printerr ("Application icon missing: %s (%s)\n", path, error->message);
g_clear_error (&error);
g_free (path);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
path = g_build_filename (base_dir, "32x32", cat_dir, "gimp.png", NULL);
pixbuf = gdk_pixbuf_new_from_file (path, &error);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
if (pixbuf)
icons = g_list_prepend (icons, pixbuf);
else
g_printerr ("Application icon missing: %s (%s)\n", path, error->message);
g_clear_error (&error);
g_free (path);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
path = g_build_filename (base_dir, "48x48", cat_dir, "gimp.png", NULL);
pixbuf = gdk_pixbuf_new_from_file (path, &error);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
if (pixbuf)
icons = g_list_prepend (icons, pixbuf);
else
g_printerr ("Application icon missing: %s (%s)\n", path, error->message);
g_clear_error (&error);
g_free (path);
path = g_build_filename (base_dir, "64x64", cat_dir, "gimp.png", NULL);
pixbuf = gdk_pixbuf_new_from_file (path, &error);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
if (pixbuf)
icons = g_list_prepend (icons, pixbuf);
else
g_printerr ("Application icon missing: %s (%s)\n", path, error->message);
g_clear_error (&error);
g_free (path);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
path = g_build_filename (base_dir, "scalable", cat_dir, "gimp.svg", NULL);
pixbuf = gdk_pixbuf_new_from_file_at_size (path, 128, 128, &error);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
if (pixbuf)
{
/* Various common sizes from the same SVG. Why I go into such
* exhaustive list of sizes is that nowadays desktops/OSes use
* quite big icon sizes and in some cases, when they don't find
* the right one, GTK may render quite ugly resized/skewed image.
*/
icons = g_list_prepend (icons, pixbuf);
pixbuf = gdk_pixbuf_new_from_file_at_size (path, 144, 144, NULL);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
icons = g_list_prepend (icons, pixbuf);
pixbuf = gdk_pixbuf_new_from_file_at_size (path, 160, 160, NULL);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
icons = g_list_prepend (icons, pixbuf);
pixbuf = gdk_pixbuf_new_from_file_at_size (path, 176, 176, NULL);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
icons = g_list_prepend (icons, pixbuf);
pixbuf = gdk_pixbuf_new_from_file_at_size (path, 192, 192, NULL);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
icons = g_list_prepend (icons, pixbuf);
pixbuf = gdk_pixbuf_new_from_file_at_size (path, 224, 224, NULL);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
icons = g_list_prepend (icons, pixbuf);
}
else
{
g_printerr ("Application icon missing: %s (%s)\n", path, error->message);
g_clear_error (&error);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
}
g_free (path);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
path = g_build_filename (base_dir, "256x256", cat_dir, "gimp.png", NULL);
pixbuf = gdk_pixbuf_new_from_file (path, &error);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
if (pixbuf)
icons = g_list_prepend (icons, pixbuf);
else
g_printerr ("Application icon missing: %s\n", path);
g_free (path);
app, libgimpwidgets: drop the thumbnail icon feature. From years of discussions, it turns out that: - The thumbnailed-Wilber icon replacing the generic icon of GIMP often makes the application harder to spot in the icon list of running processes. - In single-window mode in particular, it makes even less sense as we just show the one active image anyway. - Even in multi-window mode, nowadays many OSes or desktop group windows of a same application under one icon. So we end up with several image windows under a thumbnail only showing the top image. This happens in KDE, GNOME, Cinnamon and Windows at least apparently (as far as is being reported). - Some platforms would just use only the OS-declared icon and not care about runtime-declared ones. This is apparently the case on macOS, and also on GNOME when the desktop file is seen by the desktop environment. So all our code about generating thumbnailed icon is wasted on these platform anyway. - When intensively testing the current behavior, I had cases when the icon was not properly updated. We could of course investigate and fix the issues, but considering all the previous points, it might make more sense to simply drop the feature which is mostly useless, or worse bothersome, hence simplify the code greatly. - Finally API to set icons from GdkPixbuf data has been removed in GTK4. So long term, trying to keep this whole machinery feels like just making our life difficult for a feature which all OSes seem to deprecate and which might not be possible anymore soon (or just get harder and harder to implement). Note that I don't use gtk_window_set_default_icon_name() because it would use the icon from our theme, yet so far we are not sure it makes sense for the application icon which we probably always want to be the same, whatever the chosen theme. Finally I just list various common icon sizes because GTK API doesn't seem to be clever enough yet. I can't just give it 1 SVG image (e.g. with gtk_window_set_default_icon_from_file()) and hope it does the resizing at the last minute. It turns out it doesn't and we get an extra-small icon. So instead, let's generate common sizes ourselves from the same SVG.
2021-07-06 07:16:36 +08:00
gtk_window_set_default_icon_list (icons);
g_list_free_full (icons, g_object_unref);
gimp_widgets_init_foreign_enums ();
gimp_widgets_initialized = TRUE;
g_free (base_dir);
}
/**
* gimp_widget_set_identifier:
* @widget:
* @identifier:
*
* Set an identifier which can be used by the various gimp_blink_*()
* API. As a default, property widget will use the synced property name
* as widget identifier. You can always use this function to override a
* given widget identifier with a more specific name.
*
* Note that when a widget is bound to a property, in other words when
* in one of our propwidgets API, you should rather use
* gimp_widget_set_bound_property() because it allows more easily to
* tweak values.
* gimp_widget_set_identifier() is more destined to random widgets which
* you just want to be able to blink.
*
* It's doesn't need to be in public API because it is only used for
* internal blinking ability in core GIMP GUI.
*/
void
gimp_widget_set_identifier (GtkWidget *widget,
const gchar *identifier)
{
g_return_if_fail (GTK_IS_WIDGET (widget));
g_object_set_data_full (G_OBJECT (widget),
"gimp-widget-identifier",
g_strdup (identifier),
(GDestroyNotify) g_free);
}
/**
* gimp_widget_set_bound_property:
* @widget:
* @config:
* @property_name:
*
* This is similar to gimp_widget_set_identifier() because the
* property_name can be used as identifier by our blink API.
* You can still set explicitly (and additionally)
* gimp_widget_set_identifier() for rare cases where 2 widgets in a same
* container would bind the same property (or 2 properties named the
* same way for 2 different config objects). The identifier will be used
* in priority to the property name (which can still be used for
* changing the widget value, so it remains important to also set it).
*
* It's doesn't need to be in public API because it is only used for
* internal blinking ability in core GIMP GUI.
*/
void
gimp_widget_set_bound_property (GtkWidget *widget,
GObject *config,
const gchar *property_name)
{
g_return_if_fail (GTK_IS_WIDGET (widget));
g_object_set_data_full (G_OBJECT (widget),
"gimp-widget-property-name",
g_strdup (property_name),
(GDestroyNotify) g_free);
g_object_set_data_full (G_OBJECT (widget),
"gimp-widget-property-config",
g_object_ref (config),
(GDestroyNotify) g_object_unref);
}
/* clean up babl (in particular, so that the fish cache is constructed) if the
* compiler supports destructors
*/
#ifdef HAVE_FUNC_ATTRIBUTE_DESTRUCTOR
__attribute__ ((destructor))
static void
gimp_widgets_exit (void)
{
if (gimp_widgets_initialized)
babl_exit ();
}
#elif defined (__GNUC__)
#warning babl_init() not paired with babl_exit()
#endif