Piper Redesign
This page is kept for archival reasons only. The content may be outdated.
A Piper redesign is in the works under Google Summer of Code 2017. All ideas and mockups will be presented here, so that we can gather opinions and feedback to finalize the design. Please see the final paragraph for the designs of other, related software.
Unrelated to the mockups, Piper will handle the following scenarios:
- Device disconnected: if there are no configurable devices left, display the no device welcome screen (see below). If there are one or more devices left, display the regular welcome screen.
- New device connected while Piper was running: if the user is in the welcome screen, simply add it to the list. If the user is in the no devices welcome screen, switch to the regular welcome screen. Otherwise, simply make the back button visible if it wasn't already. Possibly later an in-app notification can be added to tell the user his device has been recognized.
The following mockups currently do not handle the following scenarios:
- Device found, but it went boom for some reason.
- hjdskes: I suppose we can just treat this as a disconnect.
- Configuring keyboards. This is a new development that is currently outside the scope of this GSoC project. Given that this will likely require a completely different set of interface elements than a mouse, the only change required to the current mockups is a change in the Welcome screen to differentiate between keyboards and mice -- after that, a new set of stack pages can be loaded that are specific to keyboards.
-
hjdskes: I suppose adding a second list under the current list in the Welcome screen to separate keyboards from mice is enough here
- whot: the difficult bit for that is that we don't quite know yet how/whether to identify mouse vs keyboard or just treat them for the capabilities they have. Open question still
-
hjdskes: I suppose adding a second list under the current list in the Welcome screen to separate keyboards from mice is enough here
The Welcome screen will be shown when Piper is opened and more than one configurable devices are found. It lists all recognized devices with their SVG to easily identify them. Selecting a device is done by clicking its list row or highlighting the list row and pressing the Select button.
The Welcome screen is skipped if only one device is found, as it wouldn't make sense to give the user an option in that case. If no devices are found, the following screen is presented instead:
Finally, if no running ratbagd instance can be detected, the following version is shown instead:
When a device has been selected, or when only one device is found, the main window is presented. This window is where all the configuration will take place. It is divided into three stack pages, one to configure resolutions, another to configure buttons and the last one to configure LEDs.
The default stack page and the one shown when the main window is opened is the page that configures resolutions:
It shows the SVG of the mouse being configured, without any leaders as this is not required for setting the resolution. The only exceptions are the buttons that are mapped to cycle through the resolutions.
All resolutions are presented in a list. The + row adds a new resolution if the device allows this; if devices only support a static number of resolutions this row will not be shown. When a list row is hovered, the x appears and when clicked removes that resolution (again, if supported by the device only).
Assigning resolutions to the mouse will most likely be done through a macro. This is however not available on all devices, so a fallback needs to be in place. Suggestions are welcome!
To actually configure a resolution the list row has to be clicked. When done, it will either expand downwards to reveal the controls or a popover will be displayed that contains the controls. The exact widgets to be used is not decided yet; ideally we would use a slider like the one used in Logitech Gaming Software but this requires experimentation. If that doesn't work, the range (100-12000) with steps of 50 is too large to be comfortably used in a slider and a spinbutton will have to be used instead. This will thus require some experimentation once we get there.
The < button in the left of the headerbar goes back to the Welcome screen to configure another device. It is not shown when there is only a single device.
The Profile button in the left of the headerbar opens a popover that can be used to switch or add and remove profiles. All available profiles are shown; clicking a list row switches to that profile. When the popover is opened, the currently active profile is pre-selected. The add and remove buttons are not shown when a device allows only a static number of profiles and are insensitive when their actions cannot be performed (e.g. when the maximum number of profiles is reached, or when there is only a single profile left). The scenario in which a device does not allow for the removal of profiles but does allow for them to be disabled works similar to "removing" a profile, but it is simply hidden instead. "Adding" a profile in this scenario simply makes the "removed" one visible again. The default profile is identified by the checkmark in its list row. Hovering a non-default profile shows the checkmark; when clicked, this profile is made the default instead.
The Save button in the right of the headerbar commits the changes made. There will also be a time-based commit, where after X seconds of inactivity the current profile is committed. We don't want to write for every change because it takes too long, but we can e.g. write when the user isn't actively doing stuff.
-
hjdskes: I'm not sure about the time-based commit; the save button gives the impression that the user has control over saving the changes made. A "hidden" time-based commit might be very confusing in that sense
- whot: fair call, let's leave it as a maybe for now
The second stack pages allows for the assignment of macros to buttons. It again shows the SVG of the mouse being configured, but this time it does show the leaders pointing to the button that remaps the respective device button. Devices that have too many buttons to comfortably fit on the right will also have leaders extending to the left. Clicking on the cog opens a dialog to assign a macro; the design of this dialog is not yet finished. Hovering this button highlights the respective button in the SVG.
The third and last stack page configures LEDs. It again shows the SVG of the mouse being configured, with leaders extending from the LEDs instead. In the case of exceptionally many LEDs, leaders will again also extend to the left. Clicking on an effect selects it and opens its configuration popover, if it has any settings to be configured. The color button opens a GtkColorChooserDialog.
It would also be fun to make the color in the SVG change depending on the selection, but this is more of a nice-to-have extra ;)
To discuss the current designs here we present related software. The images are not hosted by us, so they might disappear at any time. It's a selection of the most advanced/interesting projects out there, unmaintained and/or outdated projects are not shown.
According to Logitech "Logitech Gaming Software lets you customize Logitech G gaming mice, keyboards, headsets and select wheels". We only present the relevant gaming mice parts.
razorCommander (Linux)
Supports more than mice. Mouse support is limited to lighting effects and most macro features.
RazerGenie (Linux)
Standalone Qt application for configuring your Razer devices under GNU/Linux.
There is a mice configuration page, but there are no screenshots of that. I couldn't get it to work myself. There are more screenshots here.
Razorcfg (Linux)
"This is the next generation Razer device configuration tool bringing the Razer gaming experience to the free OpenSource world. The tool architecture is based on "razerd", which is a background daemon doing all of the lowlevel privileged hardware accesses. The user interface tools are "razercfg", a commandline tool; and "qrazercfg", a Qt based graphical device configuration tool (see screenshot below)."
