-
Notifications
You must be signed in to change notification settings - Fork 175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add resolutions page #28
Conversation
0964b8c
to
18e1cb9
Compare
General comments to your questions, I'll skip 1) because it's in the libratbag issue.
|
In C/GTK+, templates allow one to define the UI in .ui files, from which implementations can be instantiated. This significantly reduces boilerplate code that creates widgets, sets their desired properties and connects their signals[1, 2]. For several reasons, this does not work in Python[3]. gi_composites.py[4] is an implementation in Python that does make this work. It's been used by several projects for a few months now and none report issues. See the project's README for more information[5]. Taking these facts into mind, let's experiment for a bit and see how it can serve Piper. [1]: https://wiki.gnome.org/HowDoI/CustomWidgets#Templates [2]: https://blogs.gnome.org/tvb/2013/04/09/announcing-composite-widget-templates/ [3]: https://bugzilla.gnome.org/show_bug.cgi?id=701843 [4]: https://github.com/virtuald/pygi-composite-templates/ [5]: https://github.com/virtuald/pygi-composite-templates/blob/master/README.rst
This list can set a profile's resolutions. Currently, it is limited to the active profile because there is no support for profiles other than the default. Adding and removing resolutions is not yet implemented because this is not yet exposed through libratbag (see [1]). [1]: libratbag/libratbag#211
Now the user will at least know why his or her changes have not been applied. In the future we may want to include why, but for now this suffices.
For now we only expose report rates of 500 and 1000 Hz; we can add more later when we know if people care about it.
This allows us to selectively draw paths, so that for example in the resolutions page only the page to the "Switch resolution" labels is drawn.
Without this, when scrolling through the list over a scale, the scale will steal the scroll event.
Mice don't do anything more fine-grained than this
@whot I fixed the issues you mentioned on IRC (scrolling over scales stops the scrolling in the list, separate X/Y resolutions being a niche case, hiding configuration when opening another and the scale snapping to multiples of 50). I also extracted the code for the resolutions stack page into its own class. As for point 2, I updated the instructions in libratbag/libratbag#182 and the current three SVGs in there. That leaves only point 3 (assuming we'll do point 1 later when this is done in libratbag). |
We can track the design for 3 in a separate issue, I think this branch is good enough to merge. Let's do it before it gets too unwieldy or before we get side-tracked. |
This PR adds the resolutions page according to the mockups (well, mostly). It's not entirely done but I would like some feedback and discussion:
buttonX-path
. Commit fb068e3 should explain itself, I think. If we don't do this, the MouseMap in the resolutions page will draw all the leaders, even those without a "Switch resolution" label next to it.I think that's all. Do try it out (any SVG from libratbag/libratbag#182 should work), and let me know what you think of it thus far. It would also be great if someone can test it with a device that supports separate X/Y resolutions, as I cannot do this myself.