Same dog, different collar. The UI has been ported 1:1 to GTK+, using
GtkBuilder, CSS and event controllers fairly reduced the amount of code
needed for this.
It also allows us to stop initializing clutter-gtk across the several
executables.
Use GsdDeviceManager to monitor libwacom-supported tablets coming and
going. Hide the Wacom panel from the list when there's no supported
tablets plugged in.
Wacom's new "Pro Pen 3D" stylus is declared as a new stylus type within
libwacom: WSTYLUS_3D. Now that the Wacom panel supports arbitrary three-
button styli, we can add specific support for this new stylus type to
suppress the warning message that is generated.
https://bugzilla.gnome.org/show_bug.cgi?id=790028
Both 'remove_buttons' and 'remove_button' perform the same general task and
can be unified into a single function. This makes supporting an arbitrary
number of stylus buttons more straightforward.
https://bugzilla.gnome.org/show_bug.cgi?id=790028
Although the Wacom panel doesn't have explicit support for styli with more
than two buttons, it tries to at least allow configuration of the upper and
lower buttons. This commit fixes an incorrect conditional which prevents
the panel from setting the combo box for the upper switch to the current
setting.
https://bugzilla.gnome.org/show_bug.cgi?id=790028
Recent versions of Gettext are able to translate several formats
that are used in GNOME applications. This patch migrates from
Intltool to Gettext by using meson's i18n features.
https://bugzilla.gnome.org/show_bug.cgi?id=787588
With the old shell gone, there is no need to work around cut off panel
names (bug #647087). As it stands now, it only confuses translators
(invisible characters are hard to, well, see).
https://bugzilla.gnome.org/show_bug.cgi?id=792629
Meson is a build system focused on speed an ease of use, which
helps speeding up the software development. This patch adds meson
support along autotools.
https://bugzilla.gnome.org/show_bug.cgi?id=785414
Commit cf408c27b0 changed how the values stored in the "area" key were
calculated in order be compatible with its updated schema. Unfortunately,
it overlooked the fact that updated schema also changed the order of the
values from "left, top, right, bottom" to "left, right, top, bottom".
Because of this, corrections intended to be applied to the top and right
screen edges were swapped. This can cause a noticible cursor offset to
occur after finishing calibration.
https://bugzilla.gnome.org/show_bug.cgi?id=784009
The calibration utility was modified in cf408c27b0 to return unitless
padding measurements instead of axis values for storage in gsettings.
Unfortunately, the code still assumes in some places that it is working
with axes rather than paddings. This causes subtle math errors that
result in undesired cursor offsets after the calibration is applied.
Fortunately, this can be simplified, since tablet area is always reset
to the default state before starting calibration, we are sure that the
value will remain constant. Since both axes are in the same 0..1 scale,
calibration code doesn't need to swap X/Y back and forth to calculate
each axis scale.
Additionally, the code to get the calibrated axis values has been moved
into its own function along with a new function that returns padding
values suitable for consumption by g-c-c. All calculations are performed
internally in the 0..1 range.
https://bugzilla.gnome.org/show_bug.cgi?id=784009
Co-Authored-By: Carlos Garnacho <carlosg@gnome.org>
/usr/bin/ld: /mnt/wd20ezrx-00dc0b0/JHBuild/3.24/install/lib/libgnome-desktop-3.so: undefined reference to symbol 'XFree'
/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libX11.so: error adding symbols: DSO missing from command line
Change linking order to fix build.
Some improvements to fit better with the new design:
- "no configured ..." page for both stylus/tablet sections
- the navigation buttons are now children of GtkRevealers, so
size doesn't popup
- Empty placeholder in several containers have been removed.
The "area" setting has a different treatment in the gsettings-desktop-schemas
tablet schema, the 4 double values express the padding (in unitless 0..1
range) on each of the sides of the tablet. It's been done so we don't rely
on input/output units, which we might have not the luxury to access.
Besides that, the dependency on GsdWacomDevice has been cleared.
There's much going on under the hood here:
- Styli and tablets are now in split views, as per the mockups.
- CcWacomDevice and CcWacomTool are now in use, with the subsequent
API use changes. Moreover, using these objects means using the
newer schemas in gsettings-desktop-schemas, so there had to be
changes in the settings we store too.
- We now use CcTabletToolMap, plus listen to tool proximity events,
populating the "Stylus" sub-pane with those.
This can only be used for tablets that are not display nor system
integrated (eg. intuos models). The mapping of tablets with a builtin
display remain in g-s-d/GsdDeviceMapper.
In the wayland tablet input model, compositor and clients may
recognize the different physical styli in use, even if those are
used across compatible tablets.
This object is intended to be used as a persistent memory of
which stylus was used with which tablet. So you 1) can associate
tools and devices when such combination happens, and 2) query the
styli that were previously used with a tablet when it is detected/
plugged.
These associations are stored in two keyfiles in
~/.cache/gnome-control-center/wacom/, one for tablets and other
for styli.
Similar to CcWacomDevice vs GsdWacomDevice, CcWacomTool is meant to
replace the GsdWacomStylus object. There is a substantial difference
between these two objects, CcWacomTool offers constructor methods,
it expects the caller to maintain lifetime otherwise. while
GsdWacomStylus objects creation was rather fixed (GsdWacomDevice
created all possible styli on initialization). This latter model
doesn't help us use all the possibilities wrt wayland configurability.
This is a vast oversimplification of GsdWacomDevice. This one
has code that is largely unnecessary here (mostly devised for g-s-d),
plus it will be even eventually removed from g-s-d (the functionality
is moving into compositor domain), so the code sharing argument
remains pretty weak.
So, CcWacomDevice is thought to take over, just offering the basic
API we after all need in the gnome-control-center side.
