GNOME Bugzilla – Bug 682205
Add the gamepads panel
Last modified: 2021-06-09 16:14:00 UTC
A gamepads panel for the GNOME Control Center was part of my GSoC 2012
The panel, as currently designed, allows the user to see whether the connected device is supported. If supported and also possible to calibrate, the user can calibrate specific axes to his taste.
The calibration is currently a bit limited and still requires some fixes. GNOME Settings Daemon's gamepads plugin (bug #682204) exposes a few DBus methods that the panel uses to query the device support and current calibration data and also set the newly-calibrated data.
The design is only to show the intended functionality of the panel but should be left to proper designers. The design proposal was recently updated to propose the current functionality. It's located here:
Created attachment 221755 [details] [review]
This is the current patch, generated by diffing the master branch of the
gnome-control-center repository at git.gnome.org and the master branch of my
I'll mark this as something for designers to review. We probably also want the panel hidden if there's no joysticks.
I also added bug 519439 as dependent on this bug, as we probably want to offer _testing_ of joysticks if there are any (rather than just the list of devices that need calibration).
Review of attachment 221755 [details] [review]:
Some style comments before we get to reviewing the architecture.
@@ +213,3 @@
+# Gamepads panel
+# Should be disabled by default
Why? If it doesn't have any dependencies besides the ones already required, it shouldn't be optional.
@@ +153,3 @@
+ CcGamepadsCalibrationWidgetPrivate *priv = widget->priv;
+ priv->fd = open (priv->device_file, O_RDONLY | O_NONBLOCK);
Error checking? Use g_debug() to print helpful debug. I would certainly expect not to see the joystick, or get an error message if there was a permission problem.
@@ +201,3 @@
+ markup = g_markup_printf_escaped ("Calibrating device <b>'%s'</b>", priv->device_name);
+ gtk_label_set_markup (GTK_LABEL (priv->name_label), markup);
+ g_free (markup);
You shouldn't do this in the property setting, but in a "set" function.
@@ +215,3 @@
+ if (priv->panel != NULL)
+ g_object_unref (priv->panel);
@@ +110,3 @@
+ case PROP_IS_SUPPORTED:
+ priv->is_supported = g_value_get_boolean (value);
Don't do this in the set property function.
@@ +146,3 @@
+ g_free (priv->device_file);
+ priv->device_file = NULL;
@@ +161,3 @@
+cc_gamepads_device_widget_finalize (GObject *object)
+ G_OBJECT_CLASS (cc_gamepads_device_widget_parent_class)->finalize (object);
Remove this if you're only going to be chaining up to the parent implementation.
@@ +196,3 @@
+ gtk_widget_show_all (GTK_WIDGET (widget));
+ // Hide the calibrate button at the start
No C++-style comments.
@@ +15,3 @@
+# Translators: those are keywords for the color control-center panel
Gamepad, not gamepads, same for joysticks.
Those are full-text-search keywords, make them as short as possible, and have variants if needed. For example, I'd put:
What happened here?
This seems like a whole GSoC project that finished and never made it in.
Was no-one prepared to make the necessary changes?
This functionality is useful and is needed, could it be revived.
Would we need to start again?
It does make me wonder should more mentoring be given to GSoc project students to ensure the standard of meets the coding standards required.
(In reply to Laurence Brown from comment #5)
> What happened here?
The student never came back, and his primary project wasn't working on gnome-control-center.
Could it be added to GSoC proposals for another year?
Whilst only KDE is marginally better in this area it is an area that could use the work in desktop environments as a whole particularly with increase in popularity and availability of Linux games and emulator platforms.
As mentioned on IRC, I still don't see the use for this panel. The calibration shouldn't be needed in most cases, and the testing part will already be in a lot of games, when necessary.
If calibration is really dependent on the hardware (eg. the values would be different for the same model of device), then this would make sense, but only if we 1) detect that the device has axis that could be decalibrated 2) supported calibration for all the knobs it would have.
So until somebody shows the necessity of the plugin, this will stay in "needs-work".
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).
If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
and create a new bug report at
Thank you for your understanding and your help.