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.
Use the same syntax as was already in the bug template because some
people are still leaving out the howto text in the middle of their own
bug/feature description.
We were not building it by not installing libmng until now. But graphviz
must have pulled libmng. So disable explicitly the option in GIMP
configure step.
The issue has also been fixed on GEGL side (see commit 5ac40e3c3 in
GEGL), but since the fact that "gegl:introspect" relies on a runtime
tool (which is not the best thing), let's make an additional check
within GIMP to make sure we have a proper buffer as a result to
"gegl:introspect". Otherwise we might crash when trying to use this
NULL buffer.
- 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.
When creating a label bound to a property, only make the binding
directional if the property is read-write.
This fixes WARNINGs and broken label in the GimpDeviceInfoEditor widget,
such as this one:
> The source object of type GimpDeviceInfo has no writable property called 'vendor-id'
When not creating an image, we were always returning with status
GIMP_PDB_EXECUTION_ERROR even though it might have been GIMP_PDB_CANCEL
(which is not handled as an error, this is user choice, hence no dialog
pops up).
By using a logging domain we can filter the messages and can choose to
only see them when needed. They seem to be leftovers from coding or
debugging but I don't wanna invest too much time into this.
metadata-editor and metadata-viewer did return GIMP_PDB_SUCCESS when
loading the dialog ui failed, we changed this to GIMP_PDB_EXECUTION_ERROR
and now use a GError to report it back to GIMP.
In metadata-editor also improve the error handling when loading the calendar
dialog fails.
The error also only showed in the console so change that to show a dialog
or the error console.
The string parsing for gps longitude/latitude was not taking all
possible values into account and also the seconds part was
not saved with enough detail.
For altitude lets also increase the detail a bit from .1m to
.10m.
By using g_log with G_LOG_LEVEL_MESSAGE and empty domain
name we make sure the failure to write a tag will be seen by
the user in GIMP's user interface (error console or error
dialog).
Adding metadata-tags to meson.build and Makefile.am for
the metadata-viewer since until now it was only used in
the metadata-editor.
The Exif gps metadata tags for longitude, latitude and
altitude get special handling to show them with more
precision and let the string parts be translated.
The abbreviations M for meter and FT for foot/feet were written in uppercase.
However the offical abbreviations are lowercase so let's just follow that and
make them lowercase here too.
Above and Below Sea Level were using camel case with every word starting
with an uppercase letter and were used on the label of a combobox option
for gps altitude reference. Using standard casing with only the first word
using a capital seems better in this case.
a capital
Saving of longitude and latitude was duplicating the same code,
except that in latitude it forgot to free some strings.
Let's move this code into it's own function to make it easier to
improve it.
Make sure that the OK button ("Export", etc.) is always the default
action in a GimpProcedureDialog. This allows to quickly validate the
default settings.
The various generic metadata options did not have mnemonic in the base
language (US English).
Also add or fix metadata in file-png|jpeg|tiff so that every option has
a unique mnemonic.
This is nearly 600 lines less for basically the same logics! Removed
code is in particular all the GUI code is favor of the new GUI
generation.
I also cleaned a lot of stuff, removing many global variables or ugly
pieces of code. I also removed a lot of redundant code of things which
are now generic, such as handling of "gimp-comment" parasite (this is
now handled by GimpSaveProcedure and GimpImageMetadata) as well as
saving previous run's values (this is also handled generically).
Note that Advanced Options used to be in an expander. For now I chose to
get them immediately visible (still in their own "Advanced Options"
section, but it's now a normal frame, not an expander hidden by default)
since lately we got some input that many "advanced options" in various
dialogs should not be hidden away. So let's try like this for now (even
though it packs quite a lot of options in the same dialog!).
I thoroughly tested, yet that were so many changes that bugs may have
sneaked in. Please anyone, test JPEG export!
Though a GimpScaleEntry could already be created with
gimp_procedure_dialog_get_widget(), this specific function allows to add
a factor to the property range.
