It's just better practice to not leave all these variables public,
implicitly allowing various code to use these directly (also making
debugging harder).
Axis names can now be returned with gimp_device_info_get_axis_name() and
I added a dedicated function gimp_device_info_ignore_axis() to handle
the case of an axis to ignore.
I also improved the code with less redundancy to handle the axes data
(both the use and name arrays will always exist and be created and will
be n_axes size, hence avoiding bad out-of-bound reads). This includes
some code refactorization avoiding near code duplication to make sure we
always have the same logics, by creating the gimp_device_info_updated()
static function.
- First only show the axes returned by GDK (which means the axes
returned by the driver if I understand correctly), and even within
these, ignore the ones set as "ignore" because they are likely bogus
axes (Carlos said drivers sometimes add a bunch of axis; I am guessing
this is because many are generic drivers for various models of tablets
so instead of have variable length of axes, they just set some to be
ignored).
- Also use the names returned by GDK instead of our fixed set of names.
The main advantage is that these are more accurate. For instance
rather than showing just "X" for the firxt axis, the GDK names would
be "Abs X" for a tablet and "Rel X" for a mouse. The drawbacks is that
it doesn't look like GDK is actually translating these, and since we
don't have the strings in our code, we don't either. This will have to
be figured out.
Note that we still need to use the fixed set of names
(axis_use_strings array) when a device is disconnected.
- If some device didn't have any axes at all, don't show an empty list.
Don't show the curve widget either.
- In the Axes list, select by default the first axis with curve (which
would be only pressure so far if a device has this axis), because this
is one of the main feature still doable with this dialog, so it's a
bit of a time-waste if we don't show this directly. In no axes has a
curve, just show the first axis in the list.
After discussion with Carlos Garnacho, we came to the conclusion this
list is a useless feature. Basically what we call "input device" here is
pretty much "pointer device" only. We are indeed explicitly ignoring any
device identified as GDK_SOURCE_KEYBOARD, leaving us only with various
types of pointer devices (and pads actually, which maybe we should also
ignore in fact).
Such devices don't usually come with "keys", only "buttons". And in rare
cases of very weird devices coming with both buttons and keys, they will
usually identify as 2 separate devices (a pointer device and a keyboard
one) anyway, in Carlos experience, so we would still wouldn't have
access to the real keys anyway.
Moreover these keys were not only useless, but also sometimes confusing,
because some pointer devices would actually list keys, but then if you
tried to map some key event, it would not do anything (as they are not
real keys). The tablets I was testing with were such, reporting hundreds
of keys which do nothing and only confused the hell out of me.
Carlos says it probably means that the tablet drivers send bogus data of
key descriptions (so a bug in the driver, harmless yet still confusing).
So let's just get rid of this key list as our tablet expert says these
are bogus and let's see if anyone ever reports feature loss of some
extra weird pointing device which one would have used in GIMP while
mapping keys. Note that I leave the concept of keys inside
GimpDeviceInfo for now (only removing the widget part listing these)
just in case we realize we have to bring these back (less chance of code
conflict in the future when reverting the small GUI commit). But chances
are high that we will have to clean GimpDeviceInfo too and just get rid
of key code there.
and remove a gazillion gtk_widget_show() all over the place, some
places need a gtk_widget_hide() now, and I'm pretty sure I broke at
least one thing in all those files...
which means that it's now included normally via gimpbase.h
and not any longer via gimpbasetypes.h which we only did out
of lazyness. A *lot* of files in libgimp* and app/ now need to
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
This fixes a crash when we were looping until GDK_AXIS_LAST, but our
existing code was expecting less values.
Also I note that GTK+3 has an additional GDK_AXIS_ROTATION since version
3.22, even though we were told that some pens with rotation support
would report rotation values with same valuator as for the wheel (at
least, the Wacom Art Pen would apparently use the same 6th valuator).
For proper support, it would be really worth testing such pens.
GimpDeviceInfo is the only way to store per-device settings like
color, brush etc. It used to be derived from GimpContext and therefore
limited to the context's properties, causing everything else (all
tool-individual options) to be lost on device change.
Derive it from GimpToolPreset instead, so it's capable of storing
arbitrary tool options.
Adapt things to the new class hierarchy and add a bunch of signal
handlers that make sure the active device's GimpDeviceInfo is updated
properly when the tool changes. Also change device switching
accordingly.
Change GimpDeviceStatus to only show the stuff that is relevant to
each device's tool.
And various small changes to make things work properly...
which is just a #define to g_assert for now, but can now easily be
turned into something that does some nicer debugging using our new
stack trace infrastructure. This commit also reverts all constructed()
functions to use assert again.
It turns out we already have the support since it uses the same axis as
the "wheel", used by other devices (for instance the Airbrush pen of
Wacom has a wheel reporting on this same axis).
We can't do any fancy support for this right now, but at least we can
clarify a bit the dynamics naming so that people understands it can be
used for both wheel and rotation input.
Fix the various "Wheel" dynamics strings into "Wheel/Rotation".
More than 2000 lines of code less in app/, instead of
if (instance->member)
{
g_object_unref/g_free/g_whatever (instance->member);
instance->member = NULL;
}
we now simply use
g_clear_object/pointer (&instance->member);
and redo how the curves tool sets its curves in order to support this
without code duplication. Also change the color of the yellow curve in
the dynamics output editor to orange because yellow is hardly visible.
Instead, inherit from GtkBox directly and set the orientation in
init(). Replace more gtk_container_add() by gtk_box_pack_start() in
the reparented classes.
Added two new widgets, GimpDeviceInfoEditor, which is an editor/view
widget for GimpDeviceInfo, and GimpDeviceEditor, which is an editor
widget for all devices. Both are pretty much ugly right now and look a
lot like the old GtkInputDialog, but are at least internally cleaned
up and easily changable code and ui wise. Consider this a completely
intermediate state.
Also cleaned up GimpDeviceInfo so it's possible to have a proper
view on it, and did the needed changes to the preferences dialog
to use the new stuff.
