-
Notifications
You must be signed in to change notification settings - Fork 174
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 the welcome and error screen #84
Conversation
Still need to test this with more than one device, but for that I'm going to need to get ratbagd.devel running with at least one test device. Also the MousePerspective is going to need a back button in case there is more than one connected device, and the WelcomePerspective needs to look a bit better still. |
Hello I have a Corsair Raptor M45 Gaming Mouse which isn't supported by ratbag and the screen seems to be working as intended :) I would recommend making the ratbag icon symbolic and put the text under. Like so:
It would more closely follow GNOME's empty state & explain why it's not working. See: https://github.com/gnome-design-team/gnome-mockups/tree/master/empty-app-states |
That's good news, thanks for trying :)
Thanks, that's a good suggestion. For the symbolic icon, see #87. |
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 is weirdly necessary in order to show all the widgets when the MousePerspective is opened from the WelcomePerspective; it doesn't seem to be required when the MousePerspective is started straight away as was the case before the introduction of perspectives.
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.
can we detect the device (it's on its own layer after all) and crop the SVG? |
I'm already retrieving the device on its own layer, but it keeps its "global" coordinates from the complete SVG it seems. Hence the issue. |
any way we can crop the image? or not with the current architecture? |
Doesn't look like it :\ I've tried a few things within the SVG, but ultimately it comes down to librsvg reporting the sub's position relative within the "global" SVG space. |
I'm not really sure about the limitations of Rsvg as I briefly read the docs but in SVG you can place groups inside of <svg width="500" height="500" xmlns="http://www.w3.org/2000/svg">
<style>
...
</style>
<defs>
<g id="Device">
...
</g>
<g id="Buttons">
...
</g>
<g id="LEDs">
...
</g>
</defs>
<use x="0" y="0" href="#Device" />
</svg> Maybe only have the groups inside of |
A quick test shows that librsvg doesn't support this; the SVG comes up empty now, but weirdly it does have the right dimensions. |
Merging this for now because it works, the welcome screen is a niche case anyway and we don't have a solution for the svg just yet. I'd still like you to figure out a solution for that, but for now let's get this in. |
No description provided.