Can be tested by installing the .xml into /usr/share/metainfo/, then running
gnome-software --prefer-local (after killing any running g-s instance). This
may take a while to refresh and if you have a repo that contains piper it may
still be preferred for some reason.
Piper is under "Utilities", if the search doesn't find it immediately, wait
for a while? Or start searching for "org.freedesktop.Piper".
Technically appdata requires 16:9 screenshots but it seems to work with the
ones we have online for the wiki already (they're a little bit too high for
16:9).
Fixes#236
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libratbag/libratbag#422 introduced effect duration in ms for LEDs as opposed to
effect rate in Hz, as was discussed in #175. This commit updates Piper's
UI to reflect these changes.
Fixes#175.
Ah, what a beautiful night sky...
The CSS background taken from the control-center scroll test page. Apparently
we can't use the SVG background and have to do this manually.
Fixes#45
This size is determined to be the best one with the current set of
device SVGs in libratbag. It is set to ensure that the jump in size
caused by the MousePerspective populating itself when switched to is
minimal and the least disturbing. We can't populate the MousePerspective
in advance because we need to know the device.
The welcome and error screens both require a different "perspective"
into Piper, while being in the same window. For this reason, we
introduce a titlebar and a regular stack and the concept of a
"perspective", which is defined as a certain view into Piper.
A perspective needs to implement an interface of sorts of two methods:
one to retrieve its string name, and another to retrieve its widget titlebar.
Different scenarios can then show different perspectives, that have full
control over the main widget and the titlebar displayed. This commit
introduces the MousePerspective, which is a perspective showing the
mouse configuration. Future commits will add an ErrorPerspective and a
WelcomePerspective, and even further into the future we can add a
KeyboardPerspective as well.
This commits adds the necessary bits in the UI to switch between
popovers. Following commits will propagate profile changes through the
rest of Piper so that all control widgets update corresponding to
profile changes.
For the user anyway, all different mappings will look the same. It makes
no sense to make this more complicated for them by separating them into
different concepts.
ratbag's key mapping signature is forcing us to treat modifiers
different from regular keys. To detect them, we need several workarounds
over Gdk.EventKey which makes the code uglier than it could be. Perhaps
we should just skip this altogether and implement macros only; since
they don't differentiate between modifiers and regular keys all these
workaround can then be removed while providing the same functionality.
