2003-05-24 02:27:05 +08:00
|
|
|
/* LIBGIMP - The GIMP Library
|
|
|
|
* Copyright (C) 1995-1997 Peter Mattis and Spencer Kimball
|
|
|
|
*
|
|
|
|
* gimpwidgets-private.c
|
|
|
|
* Copyright (C) 2003 Sven Neumann <sven@gimp.org>
|
|
|
|
*
|
2009-01-18 06:28:01 +08:00
|
|
|
* This library is free software: you can redistribute it and/or
|
2003-05-24 02:27:05 +08:00
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
2009-01-18 06:28:01 +08:00
|
|
|
* version 3 of the License, or (at your option) any later version.
|
2003-05-24 02:27:05 +08:00
|
|
|
*
|
|
|
|
* 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
|
2009-01-18 06:28:01 +08:00
|
|
|
* License along with this library. If not, see
|
2018-07-12 05:27:07 +08:00
|
|
|
* <https://www.gnu.org/licenses/>.
|
2003-05-24 02:27:05 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
2017-05-28 22:32:52 +08:00
|
|
|
#include <babl/babl.h>
|
2023-11-15 03:04:14 +08:00
|
|
|
#include <gegl.h>
|
2003-05-24 02:27:05 +08:00
|
|
|
#include <gtk/gtk.h>
|
|
|
|
|
|
|
|
#include "libgimpbase/gimpbase.h"
|
|
|
|
|
|
|
|
#include "gimpwidgetstypes.h"
|
|
|
|
|
2015-12-13 03:44:46 +08:00
|
|
|
#include "gimpicons.h"
|
2003-05-24 02:27:05 +08:00
|
|
|
#include "gimpwidgets-private.h"
|
|
|
|
|
2010-06-11 15:53:08 +08:00
|
|
|
#include "libgimp/libgimp-intl.h"
|
|
|
|
|
2003-05-24 02:27:05 +08:00
|
|
|
|
2017-06-01 09:56:07 +08:00
|
|
|
static gboolean gimp_widgets_initialized = FALSE;
|
|
|
|
|
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;
|
2003-05-24 02:27:05 +08:00
|
|
|
|
|
|
|
|
2010-06-11 15:53:08 +08:00
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2003-05-24 02:27:05 +08:00
|
|
|
void
|
2021-10-23 07:43:57 +08:00
|
|
|
gimp_widgets_init (GimpHelpFunc standard_help_func,
|
|
|
|
GimpGetColorFunc get_foreground_func,
|
|
|
|
GimpGetColorFunc get_background_func,
|
|
|
|
GimpEnsureModulesFunc ensure_modules_func,
|
|
|
|
const gchar *test_base_dir)
|
2003-05-24 02:27:05 +08:00
|
|
|
{
|
2021-10-23 07:43:57 +08:00
|
|
|
GList *icons = NULL;
|
|
|
|
const gchar *cat_dir;
|
2021-07-06 19:26:24 +08:00
|
|
|
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;
|
2021-07-07 20:03:09 +08:00
|
|
|
GError *error = NULL;
|
2018-05-31 05:47:08 +08:00
|
|
|
|
2003-05-25 20:13:57 +08:00
|
|
|
g_return_if_fail (standard_help_func != NULL);
|
2003-05-24 02:27:05 +08:00
|
|
|
|
|
|
|
if (gimp_widgets_initialized)
|
2003-05-25 20:13:57 +08:00
|
|
|
g_error ("gimp_widgets_init() must only be called once!");
|
2003-05-24 02:27:05 +08:00
|
|
|
|
2003-05-25 22:23:43 +08:00
|
|
|
_gimp_standard_help_func = standard_help_func;
|
|
|
|
_gimp_get_foreground_func = get_foreground_func;
|
|
|
|
_gimp_get_background_func = get_background_func;
|
2003-11-12 01:55:45 +08:00
|
|
|
_gimp_ensure_modules_func = ensure_modules_func;
|
2003-05-24 02:27:05 +08:00
|
|
|
|
2017-05-28 22:32:52 +08:00
|
|
|
babl_init (); /* color selectors use babl */
|
|
|
|
|
2015-12-13 03:44:46 +08:00
|
|
|
gimp_icons_init ();
|
2003-05-24 02:27:05 +08:00
|
|
|
|
2021-10-23 07:43:57 +08:00
|
|
|
if (test_base_dir)
|
|
|
|
{
|
|
|
|
cat_dir = "";
|
|
|
|
base_dir = g_build_filename (test_base_dir, "desktop", NULL);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
cat_dir = "apps";
|
2021-07-06 19:26:24 +08:00
|
|
|
#ifdef ENABLE_RELOCATABLE_RESOURCES
|
2021-10-23 07:43:57 +08:00
|
|
|
base_dir = g_build_filename (gimp_installation_directory (), "share", "icons", "hicolor", NULL);
|
2021-07-06 19:26:24 +08:00
|
|
|
#else
|
2021-10-23 07:43:57 +08:00
|
|
|
base_dir = g_build_filename (DATAROOTDIR, "icons", "hicolor", NULL);
|
2021-07-06 19:26:24 +08:00
|
|
|
#endif
|
2021-10-23 07:43:57 +08:00
|
|
|
}
|
2021-07-06 19:26:24 +08:00
|
|
|
|
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.
|
|
|
|
*/
|
2021-10-23 07:43:57 +08:00
|
|
|
path = g_build_filename (base_dir, "16x16", cat_dir, "gimp.png", NULL);
|
2021-07-07 20:03:09 +08:00
|
|
|
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
|
2021-07-07 20:03:09 +08:00
|
|
|
g_printerr ("Application icon missing: %s (%s)\n", path, error->message);
|
|
|
|
g_clear_error (&error);
|
2021-07-06 19:26:24 +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
|
|
|
|
2021-10-23 07:43:57 +08:00
|
|
|
path = g_build_filename (base_dir, "32x32", cat_dir, "gimp.png", NULL);
|
2021-07-07 20:03:09 +08:00
|
|
|
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
|
2021-07-07 20:03:09 +08:00
|
|
|
g_printerr ("Application icon missing: %s (%s)\n", path, error->message);
|
|
|
|
g_clear_error (&error);
|
2021-07-06 19:26:24 +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
|
|
|
|
2021-10-23 07:43:57 +08:00
|
|
|
path = g_build_filename (base_dir, "48x48", cat_dir, "gimp.png", NULL);
|
2021-07-07 20:03:09 +08:00
|
|
|
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
|
2021-07-07 20:03:09 +08:00
|
|
|
g_printerr ("Application icon missing: %s (%s)\n", path, error->message);
|
|
|
|
g_clear_error (&error);
|
2021-07-06 19:26:24 +08:00
|
|
|
g_free (path);
|
2018-05-31 05:47:08 +08:00
|
|
|
|
2021-10-23 07:43:57 +08:00
|
|
|
path = g_build_filename (base_dir, "64x64", cat_dir, "gimp.png", NULL);
|
2021-07-07 20:03:09 +08:00
|
|
|
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);
|
2018-05-31 05:47:08 +08:00
|
|
|
else
|
2021-07-07 20:03:09 +08:00
|
|
|
g_printerr ("Application icon missing: %s (%s)\n", path, error->message);
|
|
|
|
g_clear_error (&error);
|
2021-07-06 19:26:24 +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
|
|
|
|
2021-10-23 07:43:57 +08:00
|
|
|
path = g_build_filename (base_dir, "scalable", cat_dir, "gimp.svg", NULL);
|
2021-07-07 20:03:09 +08:00
|
|
|
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);
|
|
|
|
|
2021-07-06 19:26:24 +08:00
|
|
|
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);
|
|
|
|
|
2021-07-06 19:26:24 +08:00
|
|
|
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);
|
|
|
|
|
2021-07-06 19:26:24 +08:00
|
|
|
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);
|
|
|
|
|
2021-07-06 19:26:24 +08:00
|
|
|
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);
|
|
|
|
|
2021-07-06 19:26:24 +08:00
|
|
|
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
|
|
|
|
{
|
2021-07-07 20:03:09 +08:00
|
|
|
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
|
|
|
}
|
2021-07-06 19:26:24 +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
|
|
|
|
2021-10-23 07:43:57 +08:00
|
|
|
path = g_build_filename (base_dir, "256x256", cat_dir, "gimp.png", NULL);
|
2021-07-07 20:03:09 +08:00
|
|
|
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
|
2021-07-07 20:03:09 +08:00
|
|
|
g_printerr ("Application icon missing: %s\n", path);
|
2021-07-06 19:26:24 +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
|
|
|
|
|
|
|
gtk_window_set_default_icon_list (icons);
|
|
|
|
g_list_free_full (icons, g_object_unref);
|
2003-05-24 02:27:05 +08:00
|
|
|
|
2010-06-11 15:53:08 +08:00
|
|
|
gimp_widgets_init_foreign_enums ();
|
|
|
|
|
2003-05-24 02:27:05 +08:00
|
|
|
gimp_widgets_initialized = TRUE;
|
2021-07-06 19:26:24 +08:00
|
|
|
g_free (base_dir);
|
2003-05-24 02:27:05 +08:00
|
|
|
}
|
2017-06-01 09:56:07 +08:00
|
|
|
|
2022-03-06 05:47:58 +08:00
|
|
|
/**
|
|
|
|
* 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.
|
|
|
|
*
|
2022-03-06 21:31:27 +08:00
|
|
|
* 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.
|
|
|
|
*
|
2022-03-06 05:47:58 +08:00
|
|
|
* 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);
|
|
|
|
}
|
|
|
|
|
2022-03-06 21:31:27 +08:00
|
|
|
/**
|
|
|
|
* 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);
|
|
|
|
}
|
|
|
|
|
2017-06-01 09:56:07 +08:00
|
|
|
/* 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
|