dnrops
/
gimp
mirror of https://github.com/GNOME/gimp.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
gimp/libgimpwidgets/gimplabelcolor.h

59 lines
2.2 KiB
C
Raw Normal View History

libgimpwidgets: new GimpLabelColor widget (color area with a label). I tried to have a not too overwhelming API, so we just ask for the label and initial color at construction. We keep sane defaults for the rest and let people tweak the result by getting the color area widgets themselves (if they need to force-showing flat colors or change the drag buttons in particular). Another thing I wondered about was the initial size of the color area. Without a size request or being in some container expanding its children (which may also be ugly), it ends up too small. I can imagine such widget being used especially when you want to display several color rectangles next to each other with a label each. So I just set it this way. Anyone is free to request a resize after constructing the object. Last but not least, the position of the label was especially of interest here. For my idea of a list of colors, I could definitely imagine color blocks aligned with vertically-oriented labels above or below. It might be worth adding an API for this later on.
2022-02-17 05:20:46 +08:00
/* LIBGIMP - The GIMP Library
* Copyright (C) 1995-1997 Peter Mattis and Spencer Kimball
*
* gimplabelcolor.h
* Copyright (C) 2022 Jehan
*
* 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/>.
*/
#if !defined (__GIMP_WIDGETS_H_INSIDE__) && !defined (GIMP_WIDGETS_COMPILATION)
#error "Only <libgimpwidgets/gimpwidgets.h> can be included directly."
#endif
#ifndef __GIMP_LABEL_COLOR_H__
#define __GIMP_LABEL_COLOR_H__
#include <libgimpwidgets/gimplabeled.h>
G_BEGIN_DECLS
#define GIMP_TYPE_LABEL_COLOR (gimp_label_color_get_type ())
libgimpwidgets: More widgets are now FINAL types
2024-10-19 10:27:07 +08:00
G_DECLARE_FINAL_TYPE (GimpLabelColor, gimp_label_color, GIMP, LABEL_COLOR, GimpLabeled)
libgimpwidgets: new GimpLabelColor widget (color area with a label). I tried to have a not too overwhelming API, so we just ask for the label and initial color at construction. We keep sane defaults for the rest and let people tweak the result by getting the color area widgets themselves (if they need to force-showing flat colors or change the drag buttons in particular). Another thing I wondered about was the initial size of the color area. Without a size request or being in some container expanding its children (which may also be ugly), it ends up too small. I can imagine such widget being used especially when you want to display several color rectangles next to each other with a label each. So I just set it this way. Anyone is free to request a resize after constructing the object. Last but not least, the position of the label was especially of interest here. For my idea of a list of colors, I could definitely imagine color blocks aligned with vertically-oriented labels above or below. It might be worth adding an API for this later on.
2022-02-17 05:20:46 +08:00
libgimpwidgets: allow editable GimpLabelColor. I was initially considering a second widget, but it makes actually much more sense to make the editability a property of the GimpLabelColor. It also mean it can be switched on or off depending on situations.
2022-02-18 04:29:13 +08:00
GtkWidget * gimp_label_color_new (const gchar *label,
app, libgimp*, plug-ins, tools: settings custom check colors now space-invaded. We pass 2 GeglColor through the wire now. Since it is passed very early (when sharing the configuration), I had some issues with initialization order of GEGL, and in particular when calling gegl_init() before gegl_config() inside _gimp_config(), I had a bunch of such criticals: > Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core' Anyway in the end, I store the passed colors as raw bytes and strings in the GPConfig object, and re-construct the GeglColor last minute in _gimp_config().
2023-11-21 04:38:11 +08:00
GeglColor *color,
libgimpwidgets: allow editable GimpLabelColor. I was initially considering a second widget, but it makes actually much more sense to make the editability a property of the GimpLabelColor. It also mean it can be switched on or off depending on situations.
2022-02-18 04:29:13 +08:00
gboolean editable);
libgimpwidgets: new GimpLabelColor widget (color area with a label). I tried to have a not too overwhelming API, so we just ask for the label and initial color at construction. We keep sane defaults for the rest and let people tweak the result by getting the color area widgets themselves (if they need to force-showing flat colors or change the drag buttons in particular). Another thing I wondered about was the initial size of the color area. Without a size request or being in some container expanding its children (which may also be ugly), it ends up too small. I can imagine such widget being used especially when you want to display several color rectangles next to each other with a label each. So I just set it this way. Anyone is free to request a resize after constructing the object. Last but not least, the position of the label was especially of interest here. For my idea of a list of colors, I could definitely imagine color blocks aligned with vertically-oriented labels above or below. It might be worth adding an API for this later on.
2022-02-17 05:20:46 +08:00
/* TODO: it would be interesting for such a widget to have an API to
* customize the label being also above or below, left or right. I could
* imagine wanting to pretty-list several colors with specific layouts.
*/
libgimpwidgets: allow editable GimpLabelColor. I was initially considering a second widget, but it makes actually much more sense to make the editability a property of the GimpLabelColor. It also mean it can be switched on or off depending on situations.
2022-02-18 04:29:13 +08:00
void gimp_label_color_set_value (GimpLabelColor *color,
app, libgimp*, plug-ins, tools: settings custom check colors now space-invaded. We pass 2 GeglColor through the wire now. Since it is passed very early (when sharing the configuration), I had some issues with initialization order of GEGL, and in particular when calling gegl_init() before gegl_config() inside _gimp_config(), I had a bunch of such criticals: > Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core' Anyway in the end, I store the passed colors as raw bytes and strings in the GPConfig object, and re-construct the GeglColor last minute in _gimp_config().
2023-11-21 04:38:11 +08:00
GeglColor *value);
GeglColor * gimp_label_color_get_value (GimpLabelColor *color);
libgimpwidgets: new GimpLabelColor widget (color area with a label). I tried to have a not too overwhelming API, so we just ask for the label and initial color at construction. We keep sane defaults for the rest and let people tweak the result by getting the color area widgets themselves (if they need to force-showing flat colors or change the drag buttons in particular). Another thing I wondered about was the initial size of the color area. Without a size request or being in some container expanding its children (which may also be ugly), it ends up too small. I can imagine such widget being used especially when you want to display several color rectangles next to each other with a label each. So I just set it this way. Anyone is free to request a resize after constructing the object. Last but not least, the position of the label was especially of interest here. For my idea of a list of colors, I could definitely imagine color blocks aligned with vertically-oriented labels above or below. It might be worth adding an API for this later on.
2022-02-17 05:20:46 +08:00
libgimpwidgets: allow editable GimpLabelColor. I was initially considering a second widget, but it makes actually much more sense to make the editability a property of the GimpLabelColor. It also mean it can be switched on or off depending on situations.
2022-02-18 04:29:13 +08:00
void gimp_label_color_set_editable (GimpLabelColor *color,
gboolean editable);
gboolean gimp_label_color_is_editable (GimpLabelColor *color);
GtkWidget * gimp_label_color_get_color_widget (GimpLabelColor *color);
libgimpwidgets: new GimpLabelColor widget (color area with a label). I tried to have a not too overwhelming API, so we just ask for the label and initial color at construction. We keep sane defaults for the rest and let people tweak the result by getting the color area widgets themselves (if they need to force-showing flat colors or change the drag buttons in particular). Another thing I wondered about was the initial size of the color area. Without a size request or being in some container expanding its children (which may also be ugly), it ends up too small. I can imagine such widget being used especially when you want to display several color rectangles next to each other with a label each. So I just set it this way. Anyone is free to request a resize after constructing the object. Last but not least, the position of the label was especially of interest here. For my idea of a list of colors, I could definitely imagine color blocks aligned with vertically-oriented labels above or below. It might be worth adding an API for this later on.
2022-02-17 05:20:46 +08:00
G_END_DECLS
#endif /* __GIMP_LABEL_COLOR_H__ */