gimp/app/widgets/gimpwidgets-utils.h

174 lines
11 KiB
C
Raw Normal View History

/* GIMP - The GNU Image Manipulation Program
app/Makefile.am app/gimphelp.[ch] new files 1999-09-27 Michael Natterer <mitch@gimp.org> * app/Makefile.am * app/gimphelp.[ch] * app/gimpui.[ch]: new files * app/interface.[ch] * app/preferences_dialog.[ch] The GIMP Help System part 1: Press "F1" in any dialog to pop up the help page for this dialog. Moved the widget constructors from preferences_dialog.[ch] and the query boxes from interface.[ch] to gimpui.[ch]. The dialog constructors take a help_func and a help_data parameter and install the "F1" accelerator which emits the new "help" signal. The "help" signal callback calls help_func(help_data) which finally has to call gimp_help() which in turn invokes the help browser. Still have to find a proper way to (1) prevent "F1" being assigned to some menu item and (2) to catch "F1" while browsing the menu trees in order to pop up the help for the selected item. * app/menus.c: a <Toolbox>/File/Help... menu item. * app/commands.[ch]: a command callback for the "Help..." menu item. * app/gimprc.[ch]: new boolean gimprc variable "use_help". * app/info_dialog.[ch]: pass a help function and data to the info dialog constructor. * app/tools.[ch]: store the tools help page names in the tool info structure. Export a special tools_help_func() which shows the help page for the active tool. * app/[all files calling a dialog constructor]: pass the dialog's help page to the constructor. Most dialogs are now created by gimp_dialog_new() which also sets up the action_area and the WM delete event callback, so I removed the resp. code from these files. Fixed some minor bugs and did some other stuff but didn't change any logic except dialog creation. * plug-ins/helpbrowser/helpbrowser.c: don't try to call a running help browser and don't install any menu path (all done in app/gimphelp.[ch] now).
1999-09-27 17:58:10 +00:00
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
* gimpwidgets-utils.h
* Copyright (C) 1999-2003 Michael Natterer <mitch@gimp.org>
app/Makefile.am app/gimphelp.[ch] new files 1999-09-27 Michael Natterer <mitch@gimp.org> * app/Makefile.am * app/gimphelp.[ch] * app/gimpui.[ch]: new files * app/interface.[ch] * app/preferences_dialog.[ch] The GIMP Help System part 1: Press "F1" in any dialog to pop up the help page for this dialog. Moved the widget constructors from preferences_dialog.[ch] and the query boxes from interface.[ch] to gimpui.[ch]. The dialog constructors take a help_func and a help_data parameter and install the "F1" accelerator which emits the new "help" signal. The "help" signal callback calls help_func(help_data) which finally has to call gimp_help() which in turn invokes the help browser. Still have to find a proper way to (1) prevent "F1" being assigned to some menu item and (2) to catch "F1" while browsing the menu trees in order to pop up the help for the selected item. * app/menus.c: a <Toolbox>/File/Help... menu item. * app/commands.[ch]: a command callback for the "Help..." menu item. * app/gimprc.[ch]: new boolean gimprc variable "use_help". * app/info_dialog.[ch]: pass a help function and data to the info dialog constructor. * app/tools.[ch]: store the tools help page names in the tool info structure. Export a special tools_help_func() which shows the help page for the active tool. * app/[all files calling a dialog constructor]: pass the dialog's help page to the constructor. Most dialogs are now created by gimp_dialog_new() which also sets up the action_area and the WM delete event callback, so I removed the resp. code from these files. Fixed some minor bugs and did some other stuff but didn't change any logic except dialog creation. * plug-ins/helpbrowser/helpbrowser.c: don't try to call a running help browser and don't install any menu path (all done in app/gimphelp.[ch] now).
1999-09-27 17:58:10 +00:00
*
* This program is free software: you can redistribute it and/or modify
app/Makefile.am app/gimphelp.[ch] new files 1999-09-27 Michael Natterer <mitch@gimp.org> * app/Makefile.am * app/gimphelp.[ch] * app/gimpui.[ch]: new files * app/interface.[ch] * app/preferences_dialog.[ch] The GIMP Help System part 1: Press "F1" in any dialog to pop up the help page for this dialog. Moved the widget constructors from preferences_dialog.[ch] and the query boxes from interface.[ch] to gimpui.[ch]. The dialog constructors take a help_func and a help_data parameter and install the "F1" accelerator which emits the new "help" signal. The "help" signal callback calls help_func(help_data) which finally has to call gimp_help() which in turn invokes the help browser. Still have to find a proper way to (1) prevent "F1" being assigned to some menu item and (2) to catch "F1" while browsing the menu trees in order to pop up the help for the selected item. * app/menus.c: a <Toolbox>/File/Help... menu item. * app/commands.[ch]: a command callback for the "Help..." menu item. * app/gimprc.[ch]: new boolean gimprc variable "use_help". * app/info_dialog.[ch]: pass a help function and data to the info dialog constructor. * app/tools.[ch]: store the tools help page names in the tool info structure. Export a special tools_help_func() which shows the help page for the active tool. * app/[all files calling a dialog constructor]: pass the dialog's help page to the constructor. Most dialogs are now created by gimp_dialog_new() which also sets up the action_area and the WM delete event callback, so I removed the resp. code from these files. Fixed some minor bugs and did some other stuff but didn't change any logic except dialog creation. * plug-ins/helpbrowser/helpbrowser.c: don't try to call a running help browser and don't install any menu path (all done in app/gimphelp.[ch] now).
1999-09-27 17:58:10 +00:00
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
app/Makefile.am app/gimphelp.[ch] new files 1999-09-27 Michael Natterer <mitch@gimp.org> * app/Makefile.am * app/gimphelp.[ch] * app/gimpui.[ch]: new files * app/interface.[ch] * app/preferences_dialog.[ch] The GIMP Help System part 1: Press "F1" in any dialog to pop up the help page for this dialog. Moved the widget constructors from preferences_dialog.[ch] and the query boxes from interface.[ch] to gimpui.[ch]. The dialog constructors take a help_func and a help_data parameter and install the "F1" accelerator which emits the new "help" signal. The "help" signal callback calls help_func(help_data) which finally has to call gimp_help() which in turn invokes the help browser. Still have to find a proper way to (1) prevent "F1" being assigned to some menu item and (2) to catch "F1" while browsing the menu trees in order to pop up the help for the selected item. * app/menus.c: a <Toolbox>/File/Help... menu item. * app/commands.[ch]: a command callback for the "Help..." menu item. * app/gimprc.[ch]: new boolean gimprc variable "use_help". * app/info_dialog.[ch]: pass a help function and data to the info dialog constructor. * app/tools.[ch]: store the tools help page names in the tool info structure. Export a special tools_help_func() which shows the help page for the active tool. * app/[all files calling a dialog constructor]: pass the dialog's help page to the constructor. Most dialogs are now created by gimp_dialog_new() which also sets up the action_area and the WM delete event callback, so I removed the resp. code from these files. Fixed some minor bugs and did some other stuff but didn't change any logic except dialog creation. * plug-ins/helpbrowser/helpbrowser.c: don't try to call a running help browser and don't install any menu path (all done in app/gimphelp.[ch] now).
1999-09-27 17:58:10 +00:00
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <https://www.gnu.org/licenses/>.
app/Makefile.am app/gimphelp.[ch] new files 1999-09-27 Michael Natterer <mitch@gimp.org> * app/Makefile.am * app/gimphelp.[ch] * app/gimpui.[ch]: new files * app/interface.[ch] * app/preferences_dialog.[ch] The GIMP Help System part 1: Press "F1" in any dialog to pop up the help page for this dialog. Moved the widget constructors from preferences_dialog.[ch] and the query boxes from interface.[ch] to gimpui.[ch]. The dialog constructors take a help_func and a help_data parameter and install the "F1" accelerator which emits the new "help" signal. The "help" signal callback calls help_func(help_data) which finally has to call gimp_help() which in turn invokes the help browser. Still have to find a proper way to (1) prevent "F1" being assigned to some menu item and (2) to catch "F1" while browsing the menu trees in order to pop up the help for the selected item. * app/menus.c: a <Toolbox>/File/Help... menu item. * app/commands.[ch]: a command callback for the "Help..." menu item. * app/gimprc.[ch]: new boolean gimprc variable "use_help". * app/info_dialog.[ch]: pass a help function and data to the info dialog constructor. * app/tools.[ch]: store the tools help page names in the tool info structure. Export a special tools_help_func() which shows the help page for the active tool. * app/[all files calling a dialog constructor]: pass the dialog's help page to the constructor. Most dialogs are now created by gimp_dialog_new() which also sets up the action_area and the WM delete event callback, so I removed the resp. code from these files. Fixed some minor bugs and did some other stuff but didn't change any logic except dialog creation. * plug-ins/helpbrowser/helpbrowser.c: don't try to call a running help browser and don't install any menu path (all done in app/gimphelp.[ch] now).
1999-09-27 17:58:10 +00:00
*/
#ifndef __APP_GIMP_WIDGETS_UTILS_H__
#define __APP_GIMP_WIDGETS_UTILS_H__
app/Makefile.am app/gimphelp.[ch] new files 1999-09-27 Michael Natterer <mitch@gimp.org> * app/Makefile.am * app/gimphelp.[ch] * app/gimpui.[ch]: new files * app/interface.[ch] * app/preferences_dialog.[ch] The GIMP Help System part 1: Press "F1" in any dialog to pop up the help page for this dialog. Moved the widget constructors from preferences_dialog.[ch] and the query boxes from interface.[ch] to gimpui.[ch]. The dialog constructors take a help_func and a help_data parameter and install the "F1" accelerator which emits the new "help" signal. The "help" signal callback calls help_func(help_data) which finally has to call gimp_help() which in turn invokes the help browser. Still have to find a proper way to (1) prevent "F1" being assigned to some menu item and (2) to catch "F1" while browsing the menu trees in order to pop up the help for the selected item. * app/menus.c: a <Toolbox>/File/Help... menu item. * app/commands.[ch]: a command callback for the "Help..." menu item. * app/gimprc.[ch]: new boolean gimprc variable "use_help". * app/info_dialog.[ch]: pass a help function and data to the info dialog constructor. * app/tools.[ch]: store the tools help page names in the tool info structure. Export a special tools_help_func() which shows the help page for the active tool. * app/[all files calling a dialog constructor]: pass the dialog's help page to the constructor. Most dialogs are now created by gimp_dialog_new() which also sets up the action_area and the WM delete event callback, so I removed the resp. code from these files. Fixed some minor bugs and did some other stuff but didn't change any logic except dialog creation. * plug-ins/helpbrowser/helpbrowser.c: don't try to call a running help browser and don't install any menu path (all done in app/gimphelp.[ch] now).
1999-09-27 17:58:10 +00:00
GtkWidget * gimp_menu_item_get_image (GtkMenuItem *item);
void gimp_menu_item_set_image (GtkMenuItem *item,
GtkWidget *image,
GimpAction *action);
void gimp_menu_position (GtkMenu *menu,
gint *x,
gint *y);
void gimp_grid_attach_icon (GtkGrid *grid,
gint row,
const gchar *icon_name,
GtkWidget *widget,
gint columns);
void gimp_enum_radio_box_add (GtkBox *box,
GtkWidget *widget,
gint enum_value,
gboolean below);
void gimp_enum_radio_frame_add (GtkFrame *frame,
GtkWidget *widget,
gint enum_value,
gboolean below);
GdkPixbuf * gimp_widget_load_icon (GtkWidget *widget,
const gchar *icon_name,
gint size);
GimpTabStyle gimp_preview_tab_style_to_icon (GimpTabStyle tab_style);
const gchar * gimp_get_mod_string (GdkModifierType modifiers);
gchar * gimp_suggest_modifiers (const gchar *message,
GdkModifierType modifiers,
const gchar *extend_selection_format,
const gchar *toggle_behavior_format,
const gchar *alt_format);
GimpChannelOps gimp_modifiers_to_channel_op (GdkModifierType modifiers);
GdkModifierType gimp_replace_virtual_modifiers (GdkModifierType modifiers);
GdkModifierType gimp_get_primary_accelerator_mask(void);
GdkModifierType gimp_get_extend_selection_mask (void);
GdkModifierType gimp_get_modify_selection_mask (void);
GdkModifierType gimp_get_toggle_behavior_mask (void);
GdkModifierType gimp_get_constrain_behavior_mask (void);
GdkModifierType gimp_get_all_modifiers_mask (void);
void gimp_get_monitor_resolution (GdkMonitor *monitor,
gdouble *xres,
gdouble *yres);
gboolean gimp_get_style_color (GtkWidget *widget,
const gchar *property_name,
GdkRGBA *color);
void gimp_window_set_hint (GtkWindow *window,
GimpWindowHint hint);
void gimp_window_set_transient_for (GtkWindow *window,
app, libgimp*, pdb, plug-ins: reimplement generic inter-process transient window. Having windows ID as guint32 is a mistake. Different systems have different protocols. In Wayland in particular, Windows handles are exchanged as strings. What this commit does is the following: In core: - get_window_id() virtual function in core GimpProgress is changed to return a GBytes, as a generic "data" to represent a window differently on different systems. - All implementations of get_window_id() in various classes implementing this interface are updated accordingly: * GimpSubProgress * GimpDisplay returns the handle of its shell. * GimpDisplayShell now creates its window handle at construction with libgimpwidget's gimp_widget_set_native_handle() and simply return this handle every time it's requested. * GimpFileDialog also creates its window handle at construction with gimp_widget_set_native_handle(). - gimp_window_set_transient_for() in core is changed to take a GimpProgress as argument (instead of a guint32 ID), requests and process the ID itself, according to the running platform. In particular, the following were improved: * Unlike old code, it will work even if the window is not visible yet. In such a case, the function simply adds a signal handler to set transient at mapping. It makes it easier to use it at construction in a reliable way. * It now works for Wayland too, additionally to X11. - GimpPdbProgress now exchanges a GBytes too with the command GIMP_PROGRESS_COMMAND_GET_WINDOW. - display_get_window_id() in gimp-gui.h also returns a GBytes now. PDB/libgimp: - gimp_display_get_window_handle() and gimp_progress_get_window_handle() now return a GBytes to represent a window handle in an opaque way (depending on the running platform). In libgimp: - GimpProgress's get_window() virtual function changed to return a GBytes and renamed get_window_handle(). - In particular GimpProgressBar is the only implementation of get_window_handle(). It creates its handle at object construction with libgimpwidget's gimp_widget_set_native_handle() and the virtual method's implementation simply returns the GBytes. In libgimpUi: - gimp_ui_get_display_window() and gimp_ui_get_progress_window() were removed. We should not assume anymore that it is possible to create a GdkWindow to be used. For instance this is not possible with Wayland which has its own way to set a window transient with a string handle. - gimp_window_set_transient_for_display() and gimp_window_set_transient() now use an internal implementation similar to core gimp_window_set_transient_for(), with the same improvements (works even at construction when the window is not visible yet + works for Wayland too). In libgimpwidgets: - New gimp_widget_set_native_handle() is a helper function used both in core and libgimp* libraries for widgets which we want to be usable as possible parents. It takes care of getting the relevant window handle (depending on the running platform) and stores it in a given pointer, either immediately or after a callback once the widget is mapped. So it can be used at construction. Also it sets a handle for X11 or Wayland. In plug-ins: - Screenshot uses the new gimp_progress_get_window_handle() directly now in its X11 code path and creates out of it a GdkWindows itself with gdk_x11_window_foreign_new_for_display(). Our inter-process transient implementation only worked for X11, and with this commit, it works for Wayland too. There is code for Windows but it is currently disabled as it apparently hangs (there is a comment in-code which links to this old report: https://bugzilla.gnome.org/show_bug.cgi?id=359538). NikcDC tested yesterday with re-enabling the code and said they experienced a freeze. ;-( Finally there is no infrastructure yet to make this work on macOS and apparently there is no implementation of window handle in GDK for macOS that I could find. I'm not sure if macOS doesn't have this concept of setting transient on another processus's window or GDK is simply lacking the implementation.
2023-08-14 14:23:06 +02:00
GimpProgress *progress);
void gimp_window_set_transient_for_handle (GtkWindow *window,
GBytes *handle);
void gimp_widget_set_accel_help (GtkWidget *widget,
GimpAction *action);
const gchar * gimp_get_message_icon_name (GimpMessageSeverity severity);
gboolean gimp_get_color_tag_color (GimpColorTag color_tag,
GimpRGB *color,
gboolean inherited);
void gimp_pango_layout_set_scale (PangoLayout *layout,
double scale);
void gimp_pango_layout_set_weight (PangoLayout *layout,
PangoWeight weight);
void gimp_highlight_widget (GtkWidget *widget,
gboolean highlight,
GdkRectangle *rect);
void gimp_widget_blink_rect (GtkWidget *widget,
GdkRectangle *rect);
void gimp_widget_blink (GtkWidget *widget);
void gimp_widget_blink_cancel (GtkWidget *widget);
void gimp_blink_toolbox (Gimp *gimp,
const gchar *action_name,
GList **blink_script);
void gimp_blink_dockable (Gimp *gimp,
const gchar *dockable_identifier,
const gchar *widget_identifier,
const gchar *settings_value,
GList **blink_script);
void gimp_widget_script_blink (GtkWidget *widget,
const gchar *widget_identifier,
GList **blink_script);
void gimp_blink_play_script (GList *blink_script);
GtkWidget * gimp_dock_with_window_new (GimpDialogFactory *factory,
GdkMonitor *monitor,
gboolean toolbox);
GtkWidget * gimp_tools_get_tool_options_gui (GimpToolOptions *tool_options);
void gimp_tools_set_tool_options_gui (GimpToolOptions *tool_options,
GtkWidget *widget);
void gimp_tools_set_tool_options_gui_func
(GimpToolOptions *tool_options,
GimpToolOptionsGUIFunc func);
gboolean gimp_widget_get_fully_opaque (GtkWidget *widget);
void gimp_widget_set_fully_opaque (GtkWidget *widget,
gboolean fully_opaque);
void gimp_gtk_container_clear (GtkContainer *container);
void gimp_button_set_suggested (GtkWidget *button,
gboolean suggested,
GtkReliefStyle default_relief);
void gimp_button_set_destructive (GtkWidget *button,
gboolean destructive,
GtkReliefStyle default_relief);
void gimp_gtk_adjustment_chain (GtkAdjustment *adjustment1,
GtkAdjustment *adjustment2);
const gchar * gimp_print_event (const GdkEvent *event);
gboolean gimp_color_profile_store_add_defaults
(GimpColorProfileStore *store,
GimpColorConfig *config,
GimpImageBaseType base_type,
GimpPrecision precision,
GError **error);
void gimp_color_profile_chooser_dialog_connect_path
(GtkWidget *dialog,
GObject *config,
const gchar *property_name);
void gimp_widget_flush_expose (void);
void gimp_make_valid_action_name (gchar *action_name);
gchar * gimp_utils_make_canonical_menu_label (const gchar *path);
app: allow a new attribute "section-name" to <section> of menus. This will replace the "placeholder" concept where I was using an invisible item with a label and no action, making it invisible. Instead let's just name (internally) our sections. This has the following advantages: * Conceptually more correct: basically we just want to place items among the same category of actions. * Easier to search for plug-in developers who'll want to place their plug-in procedures in menus, because it uses an actually searchable attribute ("section-name"). This is used by the core by allowing a special syntax in menu paths: if finished by "/[Section]" then the item will be place in the specific section named "Section". In case one actually wanted to create a submenu called "[Section]", they can use a double bracket: "[[Section]" and "[[Section]]" will both map to a normal submenu (not a section name) titled "[Section]". All other usage of square brackets will not be processed in a particular way. E.g. "Hello [World]" will end a submenu titled "Hello [World]" or "Bye]" will be a submenu and so on. Finally this system is currently limited to the position of the item itself, i.e. must be placed as last element in the path. In particular, you currently cannot use it to position a new submenu inside a section. E.g. say that I want to create a submenu "From Platforms" under the "Open" section of the File/ menu. This is currently impossible. With this syntax, we can create new items directly in the "Open" section, or create a "From Platforms" submenu in the end of the File/ menu, containing our new procedures. This could be a good improvement to come.
2023-07-13 15:29:55 +02:00
gchar ** gimp_utils_break_menu_path (const gchar *path,
gchar **mnemonic_path1,
app: allow a new attribute "section-name" to <section> of menus. This will replace the "placeholder" concept where I was using an invisible item with a label and no action, making it invisible. Instead let's just name (internally) our sections. This has the following advantages: * Conceptually more correct: basically we just want to place items among the same category of actions. * Easier to search for plug-in developers who'll want to place their plug-in procedures in menus, because it uses an actually searchable attribute ("section-name"). This is used by the core by allowing a special syntax in menu paths: if finished by "/[Section]" then the item will be place in the specific section named "Section". In case one actually wanted to create a submenu called "[Section]", they can use a double bracket: "[[Section]" and "[[Section]]" will both map to a normal submenu (not a section name) titled "[Section]". All other usage of square brackets will not be processed in a particular way. E.g. "Hello [World]" will end a submenu titled "Hello [World]" or "Bye]" will be a submenu and so on. Finally this system is currently limited to the position of the item itself, i.e. must be placed as last element in the path. In particular, you currently cannot use it to position a new submenu inside a section. E.g. say that I want to create a submenu "From Platforms" under the "Open" section of the File/ menu. This is currently impossible. With this syntax, we can create new items directly in the "Open" section, or create a "From Platforms" submenu in the end of the File/ menu, containing our new procedures. This could be a good improvement to come.
2023-07-13 15:29:55 +02:00
gchar **section_name);
gboolean gimp_utils_are_menu_path_identical (const gchar *path1,
app: allow a new attribute "section-name" to <section> of menus. This will replace the "placeholder" concept where I was using an invisible item with a label and no action, making it invisible. Instead let's just name (internally) our sections. This has the following advantages: * Conceptually more correct: basically we just want to place items among the same category of actions. * Easier to search for plug-in developers who'll want to place their plug-in procedures in menus, because it uses an actually searchable attribute ("section-name"). This is used by the core by allowing a special syntax in menu paths: if finished by "/[Section]" then the item will be place in the specific section named "Section". In case one actually wanted to create a submenu called "[Section]", they can use a double bracket: "[[Section]" and "[[Section]]" will both map to a normal submenu (not a section name) titled "[Section]". All other usage of square brackets will not be processed in a particular way. E.g. "Hello [World]" will end a submenu titled "Hello [World]" or "Bye]" will be a submenu and so on. Finally this system is currently limited to the position of the item itself, i.e. must be placed as last element in the path. In particular, you currently cannot use it to position a new submenu inside a section. E.g. say that I want to create a submenu "From Platforms" under the "Open" section of the File/ menu. This is currently impossible. With this syntax, we can create new items directly in the "Open" section, or create a "From Platforms" submenu in the end of the File/ menu, containing our new procedures. This could be a good improvement to come.
2023-07-13 15:29:55 +02:00
const gchar *path2,
gchar **canonical_path1,
gchar **mnemonic_path1,
app: allow a new attribute "section-name" to <section> of menus. This will replace the "placeholder" concept where I was using an invisible item with a label and no action, making it invisible. Instead let's just name (internally) our sections. This has the following advantages: * Conceptually more correct: basically we just want to place items among the same category of actions. * Easier to search for plug-in developers who'll want to place their plug-in procedures in menus, because it uses an actually searchable attribute ("section-name"). This is used by the core by allowing a special syntax in menu paths: if finished by "/[Section]" then the item will be place in the specific section named "Section". In case one actually wanted to create a submenu called "[Section]", they can use a double bracket: "[[Section]" and "[[Section]]" will both map to a normal submenu (not a section name) titled "[Section]". All other usage of square brackets will not be processed in a particular way. E.g. "Hello [World]" will end a submenu titled "Hello [World]" or "Bye]" will be a submenu and so on. Finally this system is currently limited to the position of the item itself, i.e. must be placed as last element in the path. In particular, you currently cannot use it to position a new submenu inside a section. E.g. say that I want to create a submenu "From Platforms" under the "Open" section of the File/ menu. This is currently impossible. With this syntax, we can create new items directly in the "Open" section, or create a "From Platforms" submenu in the end of the File/ menu, containing our new procedures. This could be a good improvement to come.
2023-07-13 15:29:55 +02:00
gchar **path1_section_name);
void gimp_window_set_title_bar_theme (Gimp *gimp,
GtkWidget *dialog,
gboolean is_main_window);
#endif /* __APP_GIMP_WIDGETS_UTILS_H__ */