2008-02-15 01:02:47 +08:00
|
|
|
/* LIBGIMP - The GIMP Library
|
|
|
|
* Copyright (C) 1995-1997 Peter Mattis and Spencer Kimball
|
|
|
|
*
|
2008-02-15 01:49:53 +08:00
|
|
|
* gimpscaleentry.c
|
2008-02-15 01:02:47 +08:00
|
|
|
* Copyright (C) 2000 Michael Natterer <mitch@gimp.org>
|
2020-11-01 04:55:57 +08:00
|
|
|
* Copyright (C) 2020 Jehan
|
2008-02-15 01:02:47 +08:00
|
|
|
*
|
2009-01-18 06:28:01 +08:00
|
|
|
* This library is free software: you can redistribute it and/or
|
2008-02-15 01:02:47 +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.
|
2008-02-15 01:02:47 +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
|
|
|
|
* Library 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/>.
|
2008-02-15 01:02:47 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
2012-05-03 09:36:22 +08:00
|
|
|
#include <gegl.h>
|
2008-02-15 01:02:47 +08:00
|
|
|
#include <gtk/gtk.h>
|
|
|
|
|
|
|
|
#include "libgimpmath/gimpmath.h"
|
|
|
|
#include "libgimpbase/gimpbase.h"
|
|
|
|
|
|
|
|
#include "gimpwidgets.h"
|
|
|
|
|
2008-02-15 01:49:53 +08:00
|
|
|
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
/**
|
|
|
|
* SECTION: gimpscaleentry
|
|
|
|
* @title: GimpScaleEntry
|
|
|
|
* @short_description: Widget containing a scale, a spin button and a
|
|
|
|
* label.
|
|
|
|
*
|
|
|
|
* This widget is a #GtkGrid showing a #GtkSpinButton and a #GtkScale
|
|
|
|
* bound together. It also displays a #GtkLabel which is used as
|
|
|
|
* mnemonic on the #GtkSpinButton.
|
|
|
|
**/
|
|
|
|
|
2020-11-01 07:35:54 +08:00
|
|
|
typedef struct _GimpScaleEntryPrivate
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
{
|
2020-11-01 09:23:03 +08:00
|
|
|
GtkWidget *scale;
|
|
|
|
GBinding *binding;
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
|
2020-11-01 09:23:03 +08:00
|
|
|
gboolean logarithmic;
|
2020-11-06 00:30:20 +08:00
|
|
|
gboolean limit_scale;
|
2020-11-01 07:35:54 +08:00
|
|
|
} GimpScaleEntryPrivate;
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
|
|
|
|
|
2020-11-01 09:23:03 +08:00
|
|
|
static void gimp_scale_entry_constructed (GObject *object);
|
|
|
|
|
|
|
|
static gboolean gimp_scale_entry_linear_to_log (GBinding *binding,
|
|
|
|
const GValue *from_value,
|
|
|
|
GValue *to_value,
|
|
|
|
gpointer user_data);
|
|
|
|
static gboolean gimp_scale_entry_log_to_linear (GBinding *binding,
|
|
|
|
const GValue *from_value,
|
|
|
|
GValue *to_value,
|
|
|
|
gpointer user_data);
|
2020-11-06 02:23:35 +08:00
|
|
|
static void gimp_scale_entry_configure (GimpScaleEntry *entry);
|
2017-05-19 00:24:35 +08:00
|
|
|
|
|
|
|
|
2020-11-06 00:30:20 +08:00
|
|
|
G_DEFINE_TYPE_WITH_PRIVATE (GimpScaleEntry, gimp_scale_entry, GIMP_TYPE_LABEL_SPIN)
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
|
|
|
|
#define parent_class gimp_scale_entry_parent_class
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_scale_entry_class_init (GimpScaleEntryClass *klass)
|
|
|
|
{
|
|
|
|
GObjectClass *object_class = G_OBJECT_CLASS (klass);
|
|
|
|
|
|
|
|
object_class->constructed = gimp_scale_entry_constructed;
|
|
|
|
|
2020-11-01 04:55:57 +08:00
|
|
|
klass->new_range_widget = NULL;
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_scale_entry_init (GimpScaleEntry *entry)
|
|
|
|
{
|
2020-11-01 09:23:03 +08:00
|
|
|
GimpScaleEntryPrivate *priv = gimp_scale_entry_get_instance_private (entry);
|
|
|
|
|
2020-11-06 00:30:20 +08:00
|
|
|
priv->limit_scale = FALSE;
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_scale_entry_constructed (GObject *object)
|
|
|
|
{
|
2020-11-01 07:35:54 +08:00
|
|
|
GimpScaleEntryClass *klass;
|
|
|
|
GimpScaleEntry *entry = GIMP_SCALE_ENTRY (object);
|
|
|
|
GimpScaleEntryPrivate *priv = gimp_scale_entry_get_instance_private (entry);
|
|
|
|
GtkAdjustment *scale_adjustment;
|
2020-11-06 00:30:20 +08:00
|
|
|
GtkAdjustment *spin_adjustment;
|
|
|
|
GtkWidget *spinbutton;
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
|
2020-11-06 00:30:20 +08:00
|
|
|
G_OBJECT_CLASS (parent_class)->constructed (object);
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
|
2020-11-06 00:30:20 +08:00
|
|
|
spinbutton = gimp_label_spin_get_spin_button (GIMP_LABEL_SPIN (entry));
|
|
|
|
spin_adjustment = gtk_spin_button_get_adjustment (GTK_SPIN_BUTTON (spinbutton));
|
|
|
|
scale_adjustment = gtk_adjustment_new (gtk_adjustment_get_value (spin_adjustment),
|
|
|
|
gtk_adjustment_get_lower (spin_adjustment),
|
|
|
|
gtk_adjustment_get_upper (spin_adjustment),
|
|
|
|
gtk_adjustment_get_step_increment (spin_adjustment),
|
|
|
|
gtk_adjustment_get_page_increment (spin_adjustment),
|
|
|
|
gtk_adjustment_get_page_size (spin_adjustment));
|
2020-10-30 08:05:43 +08:00
|
|
|
|
2020-11-01 04:55:57 +08:00
|
|
|
klass = GIMP_SCALE_ENTRY_GET_CLASS (entry);
|
|
|
|
if (klass->new_range_widget)
|
|
|
|
{
|
2020-11-01 07:35:54 +08:00
|
|
|
priv->scale = klass->new_range_widget (scale_adjustment);
|
|
|
|
g_return_if_fail (GTK_IS_RANGE (priv->scale));
|
|
|
|
g_return_if_fail (scale_adjustment == gtk_range_get_adjustment (GTK_RANGE (priv->scale)));
|
2020-11-01 04:55:57 +08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2020-11-01 07:35:54 +08:00
|
|
|
priv->scale = gtk_scale_new (GTK_ORIENTATION_HORIZONTAL, scale_adjustment);
|
|
|
|
gtk_scale_set_draw_value (GTK_SCALE (priv->scale), FALSE);
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
|
2020-11-06 00:30:20 +08:00
|
|
|
g_object_bind_property (G_OBJECT (spinbutton), "digits",
|
|
|
|
G_OBJECT (priv->scale), "digits",
|
|
|
|
G_BINDING_BIDIRECTIONAL |
|
|
|
|
G_BINDING_SYNC_CREATE);
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
}
|
app, libgimpwidgets, plug-ins: default increments for GimpScaleEntry.
Instead of setting always manually the step and page increments when
creating a GimpScaleEntry, let's just generate some common cases
automatically. Indeed the increments are rarely something you want to
care about. The algorithm used is:
- For a range under 1.0, use a hundredth and a tenth (typically a [0,
1.0] range will step-increment of 0.01 and page-increment of 0.1).
- For small ranges (under 40), step-increment by 1, page-increment by 2.
- For bigger ranges, step-increment by 1, page-increment by 10.
For use cases when you absolutely want specific increment values, I add
the gimp_scale_entry_set_increments() function. It is much better to
have a small and understandable constructor call followed by
configuration calls (only when needed) rather than a constructor with a
crazy amount of parameters. Hence gimp_scale_entry_new() went from 17
arguments (absolutely unreadable calls) to now 5.
2020-10-30 18:58:05 +08:00
|
|
|
|
2020-11-06 00:30:20 +08:00
|
|
|
gtk_widget_set_hexpand (priv->scale, TRUE);
|
2020-10-31 00:33:53 +08:00
|
|
|
|
2020-11-06 00:30:20 +08:00
|
|
|
/* Move the spin button to the right. */
|
|
|
|
gtk_container_remove (GTK_CONTAINER (entry), g_object_ref (spinbutton));
|
|
|
|
gtk_grid_attach (GTK_GRID (entry), spinbutton, 2, 0, 1, 1);
|
2020-10-31 00:33:53 +08:00
|
|
|
|
2020-11-06 00:30:20 +08:00
|
|
|
gtk_grid_attach (GTK_GRID (entry), priv->scale, 1, 0, 1, 1);
|
|
|
|
gtk_widget_show (priv->scale);
|
2020-10-31 00:33:53 +08:00
|
|
|
|
2020-11-06 00:30:20 +08:00
|
|
|
g_signal_connect_swapped (spin_adjustment, "changed",
|
|
|
|
G_CALLBACK (gimp_scale_entry_configure),
|
|
|
|
entry);
|
|
|
|
gimp_scale_entry_configure (entry);
|
app, libgimpwidgets, plug-ins: default increments for GimpScaleEntry.
Instead of setting always manually the step and page increments when
creating a GimpScaleEntry, let's just generate some common cases
automatically. Indeed the increments are rarely something you want to
care about. The algorithm used is:
- For a range under 1.0, use a hundredth and a tenth (typically a [0,
1.0] range will step-increment of 0.01 and page-increment of 0.1).
- For small ranges (under 40), step-increment by 1, page-increment by 2.
- For bigger ranges, step-increment by 1, page-increment by 10.
For use cases when you absolutely want specific increment values, I add
the gimp_scale_entry_set_increments() function. It is much better to
have a small and understandable constructor call followed by
configuration calls (only when needed) rather than a constructor with a
crazy amount of parameters. Hence gimp_scale_entry_new() went from 17
arguments (absolutely unreadable calls) to now 5.
2020-10-30 18:58:05 +08:00
|
|
|
}
|
|
|
|
|
2017-05-19 00:24:35 +08:00
|
|
|
static gboolean
|
|
|
|
gimp_scale_entry_linear_to_log (GBinding *binding,
|
|
|
|
const GValue *from_value,
|
|
|
|
GValue *to_value,
|
|
|
|
gpointer user_data)
|
2008-02-15 01:02:47 +08:00
|
|
|
{
|
2017-05-19 00:24:35 +08:00
|
|
|
GtkAdjustment *spin_adjustment;
|
|
|
|
gdouble value = g_value_get_double (from_value);
|
2008-02-15 01:02:47 +08:00
|
|
|
|
2021-10-16 21:41:03 +08:00
|
|
|
spin_adjustment = GTK_ADJUSTMENT (g_binding_dup_source (binding));
|
2008-02-15 01:02:47 +08:00
|
|
|
|
2017-05-19 00:24:35 +08:00
|
|
|
if (gtk_adjustment_get_lower (spin_adjustment) <= 0.0)
|
|
|
|
value = log (value - gtk_adjustment_get_lower (spin_adjustment) + 0.1);
|
2008-02-15 01:02:47 +08:00
|
|
|
else
|
2017-05-19 00:24:35 +08:00
|
|
|
value = log (value);
|
2008-02-15 01:02:47 +08:00
|
|
|
|
2017-05-19 00:24:35 +08:00
|
|
|
g_value_set_double (to_value, value);
|
2008-02-15 01:02:47 +08:00
|
|
|
|
2021-10-16 21:41:03 +08:00
|
|
|
g_clear_object (&spin_adjustment);
|
|
|
|
|
2017-05-19 00:24:35 +08:00
|
|
|
return TRUE;
|
2008-02-15 01:02:47 +08:00
|
|
|
}
|
|
|
|
|
2017-05-19 00:24:35 +08:00
|
|
|
static gboolean
|
|
|
|
gimp_scale_entry_log_to_linear (GBinding *binding,
|
|
|
|
const GValue *from_value,
|
|
|
|
GValue *to_value,
|
|
|
|
gpointer user_data)
|
2008-02-15 01:02:47 +08:00
|
|
|
{
|
2017-05-19 00:24:35 +08:00
|
|
|
GtkAdjustment *spin_adjustment;
|
|
|
|
gdouble value = g_value_get_double (from_value);
|
2008-02-15 01:02:47 +08:00
|
|
|
|
2021-10-16 21:41:03 +08:00
|
|
|
spin_adjustment = GTK_ADJUSTMENT (g_binding_dup_source (binding));
|
2008-02-15 01:02:47 +08:00
|
|
|
|
2017-05-19 00:24:35 +08:00
|
|
|
value = exp (value);
|
2008-02-15 01:02:47 +08:00
|
|
|
|
2017-05-19 00:24:35 +08:00
|
|
|
if (gtk_adjustment_get_lower (spin_adjustment) <= 0.0)
|
|
|
|
value += gtk_adjustment_get_lower (spin_adjustment) - 0.1;
|
2008-02-15 01:02:47 +08:00
|
|
|
|
2017-05-19 00:24:35 +08:00
|
|
|
g_value_set_double (to_value, value);
|
|
|
|
|
2021-10-16 21:41:03 +08:00
|
|
|
g_clear_object (&spin_adjustment);
|
|
|
|
|
2017-05-19 00:24:35 +08:00
|
|
|
return TRUE;
|
2008-02-15 01:02:47 +08:00
|
|
|
}
|
|
|
|
|
2020-11-06 02:23:35 +08:00
|
|
|
static void
|
|
|
|
gimp_scale_entry_configure (GimpScaleEntry *entry)
|
|
|
|
{
|
|
|
|
GimpScaleEntryPrivate *priv;
|
|
|
|
GBinding *binding;
|
|
|
|
GtkWidget *spinbutton;
|
|
|
|
GtkAdjustment *spin_adj;
|
|
|
|
GtkAdjustment *scale_adj;
|
|
|
|
gdouble scale_lower;
|
|
|
|
gdouble scale_upper;
|
|
|
|
|
|
|
|
g_return_if_fail (GIMP_IS_SCALE_ENTRY (entry));
|
|
|
|
|
|
|
|
priv = gimp_scale_entry_get_instance_private (entry);
|
|
|
|
scale_adj = gtk_range_get_adjustment (GTK_RANGE (priv->scale));
|
|
|
|
|
|
|
|
spinbutton = gimp_label_spin_get_spin_button (GIMP_LABEL_SPIN (entry));
|
|
|
|
spin_adj = gtk_spin_button_get_adjustment (GTK_SPIN_BUTTON (spinbutton));
|
|
|
|
|
|
|
|
g_clear_object (&priv->binding);
|
|
|
|
|
|
|
|
if (priv->limit_scale)
|
|
|
|
{
|
|
|
|
scale_lower = gtk_adjustment_get_lower (scale_adj);
|
|
|
|
scale_upper = gtk_adjustment_get_upper (scale_adj);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
scale_lower = gtk_adjustment_get_lower (spin_adj);
|
|
|
|
scale_upper = gtk_adjustment_get_upper (spin_adj);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (priv->logarithmic)
|
|
|
|
{
|
|
|
|
gdouble correction;
|
|
|
|
gdouble log_value, log_lower, log_upper;
|
|
|
|
gdouble log_step_increment, log_page_increment;
|
|
|
|
|
|
|
|
correction = (scale_lower > 0 ? 0 : 0.1 + - scale_lower);
|
|
|
|
|
|
|
|
log_value = log (gtk_adjustment_get_value (scale_adj) + correction);
|
|
|
|
log_lower = log (scale_lower + correction);
|
|
|
|
log_upper = log (scale_upper + correction);
|
|
|
|
log_step_increment =
|
|
|
|
(log_upper - log_lower) / ((scale_upper - scale_lower) /
|
|
|
|
gtk_adjustment_get_step_increment (spin_adj));
|
|
|
|
log_page_increment =
|
|
|
|
(log_upper - log_lower) / ((scale_upper - scale_lower) /
|
|
|
|
gtk_adjustment_get_page_increment (spin_adj));
|
|
|
|
|
|
|
|
gtk_adjustment_configure (scale_adj,
|
|
|
|
log_value, log_lower, log_upper,
|
|
|
|
log_step_increment, log_page_increment, 0.0);
|
|
|
|
|
|
|
|
binding = g_object_bind_property_full (G_OBJECT (spin_adj), "value",
|
|
|
|
G_OBJECT (scale_adj), "value",
|
|
|
|
G_BINDING_BIDIRECTIONAL |
|
|
|
|
G_BINDING_SYNC_CREATE,
|
|
|
|
gimp_scale_entry_linear_to_log,
|
|
|
|
gimp_scale_entry_log_to_linear,
|
|
|
|
NULL, NULL);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
gtk_adjustment_configure (scale_adj,
|
|
|
|
gtk_adjustment_get_value (spin_adj),
|
|
|
|
scale_lower, scale_upper,
|
|
|
|
gtk_adjustment_get_step_increment (spin_adj),
|
|
|
|
gtk_adjustment_get_page_increment (spin_adj),
|
|
|
|
0.0);
|
|
|
|
|
|
|
|
binding = g_object_bind_property (G_OBJECT (spin_adj), "value",
|
|
|
|
G_OBJECT (scale_adj), "value",
|
|
|
|
G_BINDING_BIDIRECTIONAL |
|
|
|
|
G_BINDING_SYNC_CREATE);
|
|
|
|
}
|
|
|
|
|
|
|
|
priv->binding = binding;
|
|
|
|
}
|
|
|
|
|
2020-11-01 09:23:03 +08:00
|
|
|
/* Public functions */
|
2008-02-15 01:02:47 +08:00
|
|
|
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
/**
|
2020-11-01 09:35:03 +08:00
|
|
|
* gimp_scale_entry_new:
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
* @text: The text for the #GtkLabel which will appear left of
|
|
|
|
* the #GtkHScale.
|
|
|
|
* @value: The initial value.
|
|
|
|
* @lower: The lower boundary.
|
|
|
|
* @upper: The upper boundary.
|
|
|
|
* @digits: The number of decimal digits.
|
|
|
|
*
|
|
|
|
* This function creates a #GtkLabel, a #GtkHScale and a #GtkSpinButton and
|
|
|
|
* attaches them to a 3-column #GtkGrid.
|
|
|
|
*
|
2020-10-31 21:11:16 +08:00
|
|
|
* Returns: (transfer full): The new #GimpScaleEntry.
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
**/
|
|
|
|
GtkWidget *
|
2020-11-01 09:35:03 +08:00
|
|
|
gimp_scale_entry_new (const gchar *text,
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
gdouble value,
|
|
|
|
gdouble lower,
|
|
|
|
gdouble upper,
|
|
|
|
guint digits)
|
|
|
|
{
|
|
|
|
GtkWidget *entry;
|
|
|
|
|
|
|
|
entry = g_object_new (GIMP_TYPE_SCALE_ENTRY,
|
|
|
|
"label", text,
|
|
|
|
"value", value,
|
|
|
|
"lower", lower,
|
|
|
|
"upper", upper,
|
|
|
|
"digits", digits,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
return entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2020-11-01 04:55:57 +08:00
|
|
|
* gimp_scale_entry_get_range:
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
* @entry: The #GtkScaleEntry.
|
|
|
|
*
|
2020-11-01 04:55:57 +08:00
|
|
|
* This function returns the #GtkRange packed in @entry. This can be
|
|
|
|
* useful if you need to customize some aspects of the widget
|
|
|
|
*
|
|
|
|
* By default, it is a #GtkScale, but it can be any other type of
|
Fix typos
Found via:
```
codespell -q 3 -S ./ChangeLog*,*.po,./.git,./NEWS* -L als,ang,ba,chello,daa,doubleclick,foto,hist,iff,inport,klass,mut,nd,ower,paeth,params,pard,pevent,sinc,thru,tim,uint
```
2020-11-06 00:43:53 +08:00
|
|
|
* #GtkRange if a subclass overrode the new_range_widget() protected
|
2020-11-01 04:55:57 +08:00
|
|
|
* method.
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
*
|
GIR: Try to return more specific GtkWidget subclass
In GTK, a common scheme is to let a function creating a specific widget
to return a `GtkWidget *`, rather than the specific subtype, since you
often need to call API of GtkWidget, avoiding some useless casts.
For bindings however (and especially bindings to compiled languages),
this is a bit annoying, as you have to explicitly change the type of the
return value (downcast), which is not trivial (or at least desirable) in
each language.
Luckily, we can use `(type ...)` annotation for this use case, leaving
the C API unchanged, while improving the experience for bindings.
2020-12-25 22:05:16 +08:00
|
|
|
* Returns: (transfer none) (type GtkRange): The #GtkRange contained in @entry.
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
**/
|
|
|
|
GtkWidget *
|
2020-11-01 04:55:57 +08:00
|
|
|
gimp_scale_entry_get_range (GimpScaleEntry *entry)
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
{
|
2020-11-01 07:35:54 +08:00
|
|
|
GimpScaleEntryPrivate *priv = gimp_scale_entry_get_instance_private (entry);
|
|
|
|
|
2020-10-31 21:11:16 +08:00
|
|
|
g_return_val_if_fail (GIMP_IS_SCALE_ENTRY (entry), NULL);
|
|
|
|
|
2020-11-01 07:35:54 +08:00
|
|
|
return priv->scale;
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2020-11-01 09:54:02 +08:00
|
|
|
* gimp_scale_entry_set_bounds:
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
* @entry: The #GtkScaleEntry.
|
|
|
|
* @lower: the lower value for the whole widget if @limit_scale is
|
|
|
|
* %FALSE, or only for the #GtkScale if %TRUE.
|
|
|
|
* @upper: the upper value for the whole widget if @limit_scale is
|
|
|
|
* %FALSE, or only for the #GtkSpinButton if %TRUE.
|
|
|
|
* @limit_scale: Whether the range should only apply to the #GtkScale or
|
|
|
|
* if it should share its #GtkAdjustement with the
|
2022-06-17 21:39:19 +08:00
|
|
|
* #GtkSpinButton. If %TRUE, both @lower and @upper must be
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
* included in current #GtkSpinButton range.
|
|
|
|
*
|
2020-11-06 00:30:20 +08:00
|
|
|
* By default the #GtkSpinButton and #GtkScale will have the same range.
|
|
|
|
* In some case, you want to set a different range. In particular when
|
|
|
|
* the finale range is huge, the #GtkScale might become nearly useless
|
|
|
|
* as every tiny slider move would dramatically update the value. In
|
|
|
|
* this case, it is common to set the #GtkScale to a smaller common
|
|
|
|
* range, while the #GtkSpinButton would allow for the full allowed
|
|
|
|
* range.
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
* This function allows this. Obviously the #GtkAdjustment of both
|
|
|
|
* widgets would be synced but if the set value is out of the #GtkScale
|
|
|
|
* range, the slider would simply show at one extreme.
|
|
|
|
*
|
|
|
|
* If @limit_scale is %FALSE though, it would sync back both widgets
|
|
|
|
* range to the new values.
|
app, libgimpwidgets, plug-ins: default increments for GimpScaleEntry.
Instead of setting always manually the step and page increments when
creating a GimpScaleEntry, let's just generate some common cases
automatically. Indeed the increments are rarely something you want to
care about. The algorithm used is:
- For a range under 1.0, use a hundredth and a tenth (typically a [0,
1.0] range will step-increment of 0.01 and page-increment of 0.1).
- For small ranges (under 40), step-increment by 1, page-increment by 2.
- For bigger ranges, step-increment by 1, page-increment by 10.
For use cases when you absolutely want specific increment values, I add
the gimp_scale_entry_set_increments() function. It is much better to
have a small and understandable constructor call followed by
configuration calls (only when needed) rather than a constructor with a
crazy amount of parameters. Hence gimp_scale_entry_new() went from 17
arguments (absolutely unreadable calls) to now 5.
2020-10-30 18:58:05 +08:00
|
|
|
*
|
|
|
|
* Note that the step and page increments are updated when the range is
|
|
|
|
* updated according to some common usage algorithm which should work if
|
|
|
|
* you don't have very specific needs. If you want to customize the step
|
2020-11-06 00:30:20 +08:00
|
|
|
* increments yourself, you may call gimp_label_spin_set_increments()
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
**/
|
|
|
|
void
|
2020-11-01 09:54:02 +08:00
|
|
|
gimp_scale_entry_set_bounds (GimpScaleEntry *entry,
|
|
|
|
gdouble lower,
|
|
|
|
gdouble upper,
|
|
|
|
gboolean limit_scale)
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
{
|
2020-11-01 07:35:54 +08:00
|
|
|
GimpScaleEntryPrivate *priv;
|
2020-11-06 00:30:20 +08:00
|
|
|
GtkWidget *spinbutton;
|
2020-11-01 07:35:54 +08:00
|
|
|
GtkAdjustment *spin_adjustment;
|
|
|
|
GtkAdjustment *scale_adjustment;
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
|
2020-10-31 21:11:16 +08:00
|
|
|
g_return_if_fail (GIMP_IS_SCALE_ENTRY (entry));
|
|
|
|
g_return_if_fail (lower <= upper);
|
|
|
|
|
2020-11-01 07:35:54 +08:00
|
|
|
priv = gimp_scale_entry_get_instance_private (entry);
|
|
|
|
scale_adjustment = gtk_range_get_adjustment (GTK_RANGE (priv->scale));
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
|
2020-11-06 00:30:20 +08:00
|
|
|
spinbutton = gimp_label_spin_get_spin_button (GIMP_LABEL_SPIN (entry));
|
|
|
|
spin_adjustment = gtk_spin_button_get_adjustment (GTK_SPIN_BUTTON (spinbutton));
|
|
|
|
|
|
|
|
priv->limit_scale = limit_scale;
|
|
|
|
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
if (limit_scale)
|
|
|
|
{
|
|
|
|
g_return_if_fail (lower >= gtk_adjustment_get_lower (spin_adjustment) &&
|
|
|
|
upper <= gtk_adjustment_get_upper (spin_adjustment));
|
|
|
|
|
2020-10-30 08:05:43 +08:00
|
|
|
gtk_adjustment_set_lower (scale_adjustment, lower);
|
|
|
|
gtk_adjustment_set_upper (scale_adjustment, upper);
|
2020-11-06 00:30:20 +08:00
|
|
|
|
|
|
|
gimp_scale_entry_configure (entry);
|
libgimpwidgets: make GimpScaleEntry into its own widget.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
2020-10-30 07:30:03 +08:00
|
|
|
}
|
|
|
|
else if (! limit_scale)
|
|
|
|
{
|
|
|
|
g_object_set (entry,
|
|
|
|
"lower", lower,
|
|
|
|
"upper", upper,
|
|
|
|
NULL);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-30 08:05:43 +08:00
|
|
|
/**
|
|
|
|
* gimp_scale_entry_set_logarithmic:
|
|
|
|
* @entry: a #GimpScaleEntry as returned by gimp_scale_entry_new()
|
2023-07-22 03:35:23 +08:00
|
|
|
* @logarithmic: a boolean value to set or reset logarithmic behavior
|
2020-10-30 08:05:43 +08:00
|
|
|
* of the scale widget
|
|
|
|
*
|
|
|
|
* Sets whether @entry's scale widget will behave in a linear
|
|
|
|
* or logarithmic fashion. Useful when an entry has to attend large
|
|
|
|
* ranges, but smaller selections on that range require a finer
|
|
|
|
* adjustment.
|
|
|
|
*
|
|
|
|
* Since: 2.2
|
|
|
|
**/
|
|
|
|
void
|
|
|
|
gimp_scale_entry_set_logarithmic (GimpScaleEntry *entry,
|
|
|
|
gboolean logarithmic)
|
|
|
|
{
|
2020-11-01 07:35:54 +08:00
|
|
|
GimpScaleEntryPrivate *priv;
|
2020-11-06 00:30:20 +08:00
|
|
|
|
|
|
|
g_return_if_fail (GIMP_IS_SCALE_ENTRY (entry));
|
|
|
|
|
|
|
|
priv = gimp_scale_entry_get_instance_private (entry);
|
|
|
|
|
|
|
|
if (logarithmic != priv->logarithmic)
|
|
|
|
{
|
|
|
|
priv->logarithmic = logarithmic;
|
|
|
|
gimp_scale_entry_configure (entry);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-30 08:05:43 +08:00
|
|
|
/**
|
|
|
|
* gimp_scale_entry_get_logarithmic:
|
|
|
|
* @entry: a #GimpScaleEntry as returned by gimp_scale_entry_new()
|
|
|
|
*
|
|
|
|
* Returns: %TRUE if @entry's scale widget will behave in
|
2023-07-22 03:35:23 +08:00
|
|
|
* logarithmic fashion, %FALSE for linear behavior.
|
2020-10-30 08:05:43 +08:00
|
|
|
*
|
|
|
|
* Since: 2.2
|
|
|
|
**/
|
|
|
|
gboolean
|
|
|
|
gimp_scale_entry_get_logarithmic (GimpScaleEntry *entry)
|
|
|
|
{
|
2020-11-01 07:35:54 +08:00
|
|
|
GimpScaleEntryPrivate *priv = gimp_scale_entry_get_instance_private (entry);
|
|
|
|
|
2020-10-31 21:11:16 +08:00
|
|
|
g_return_val_if_fail (GIMP_IS_SCALE_ENTRY (entry), FALSE);
|
|
|
|
|
2020-11-01 07:35:54 +08:00
|
|
|
return priv->logarithmic;
|
2020-10-30 08:05:43 +08:00
|
|
|
}
|