Pyra Omni-Settings


Askarus

Forum Addict!
Joined
Sep 28, 2011
Messages
4,839
Location
Germany
In case you wonder what if I'm doing anything useful with my Prototyp.
Unfortunately I still can't do the fancy and important work others do.
So I've used my semester holidays to learn a little about Linux and GTK programming.
I made a simple settings menu for all the Pyra specific stuff that's not within the MATE settings menu.
It's written in GTK and C.

So far it includes:
- Keyboard and Screen backlight brightness
- LED Trigger and brightness
- Brightness Key shortcut customization (needs to add an interface for custom commands)
- Nub Settings

Below are some screenshots from my laptop.

The later two still need testing on the Pyra as I've developed them on my Laptop.

What I plan to do:
- Quick settings page with toggle switches (USB, Wifi, HDMI, if someone tells me how to do it, then SD-ass storage as well)

Maybe it will find it's way into the main OS. Else I might release a DBP :)
It's the my first program with real life relevance and not a University project. So don't expect it to be perfect ;)

If you have some ideas and imporvements I'm happy to discuss them and improve :)
Anyways, as my semester has started again I don't have too much time for private projects. I'm not the person to work on multiple things at once.
 

Attachments

  • Tab-Brightkey.png
    Tab-Brightkey.png
    67.7 KB · Views: 311
  • Tab-LED.png
    Tab-LED.png
    35.8 KB · Views: 294
  • Tab-Nub-2.png
    Tab-Nub-2.png
    46.2 KB · Views: 309
  • Tab-Screen-Brightness.png
    Tab-Screen-Brightness.png
    20.2 KB · Views: 292
  • Tb-Nub-1.png
    Tb-Nub-1.png
    46.2 KB · Views: 305
Some of these may be good or bad ideas - I tend to lean toward greater control & flexibility, but others could see it as adding too much complexity.

Another option class for the Brightness key assignment list: Software volume control
Master volume, headphone volume, speaker volume, hdmi volume, bluetooth volume (did I miss any?)

Another device to govern: The "Volume wheel". It could have the same dropdown options as the brightness button. It could even be subjected to modifiers (Fn, Shift, Alt, Ctrl, Super)

Would there be any interest in having the left/right versions of the modifiers being capable of different results when used in combination with the controls? I.e. keyboard Super + volume doing something different than lidswitch Super + volume.

I recall seeing that the volume wheel is software interpreted. Does it turn infinitely in both directions or does it have a defined top/bottom stop? If top/bottom stops, then how many discrete points can it measure from lowest to highest value?

Great work so far!

On a side note - the Pyra will also have gyro-like sensors, right? Would it be hypothetically possible to use light taps on X,Y,Z axis as interpreted controls? Tap the Right side for next song, Left side for previous, tap the lid to pause. (Talking fingertip taps here - not striking it or the like). If so, should there be the options to use 'light impacts' as a controls option in configuration as above?
 
Having a graphical interface is definitely a step in the right direction.
These are probably too obvious to mention, but since you've shown us screenshots:
You'll want to use more and consistent padding, left aligned labels and right aligned controls for the most part.
Related controls should have a consistent look. The lengths of the slider bars on the nub tab are all over the place.
Perhaps less borders too. The outer-most one around the tabs is definitely out of place, though. Looking consistent with the rest of the settings apps may be a good goal (until somebody switched their DE, I guess).
The bottom buttons should have their respective system symbols. Unless that's already the case and you disabled icons on buttons.

Some of the options are very verbose. The LED selection could be split up in their position and have a color mixer for example.

What I can't see: Is the UI window freely resizeable? Is the dialog DPI-aware?


Just writing what comes to mind when looking at it. The efforts are appreciated, of course. This stuff can suck up time.
 
Some of these may be good or bad ideas - I tend to lean toward greater control & flexibility, but others could see it as adding too much complexity.
That's why we have defaults and you never should have to enter he settings menu.

Volume Wheel might also be interesting.
It is the same as on the Pandora so it can not turn infinitely.

I did not implement the backend. Nub and Brightkey options simply read and write a file that's loaded by sebt3's pyrainput daemon.
Everything is possible ;)

Unfortunately I have no idea of how to read the gyro input. But if there is a daemon to read them it might work...


hese are probably too obvious to mention, but since you've shown us screenshots:
You'll want to use more and consistent padding, left aligned labels and right aligned controls for the most part.
Related controls should have a consistent look. The lengths of the slider bars on the nub tab are all over the place.

I can see that. This is something I need to improve.
I've read somewhere that GTK can use CSS. All I use now is Boxes and Grids to place the elements.
For me it looks ok. I'm not a designer like you are ;)

Perhaps less borders too. The outer-most one around the tabs is definitely out of place, though. Looking consistent with the rest of the settings apps may be a good goal (until somebody switched their DE, I guess).

It looks completely different when I use a different theme. On my computer it fits perfectly to the XFCE settings. (See the attached picture.

Some of the options are very verbose. The LED selection could be split up in their position and have a color mixer for example.

That was more of a practice for me... That Tab is badly coded as well. It uses the LED path as name. I need to rework that.
Unfortunately the LEDs are not nice to control.
You can either set a trigger or a custom brightness for one of the main colors (Red Green Blue).
If a Trigger is set it is always at max brightness. So I cant set a trigger for any color like that needs let's say 255 RED and 100 BLUE. The driver does not allow that...
I've also thought about the color picker to set a brightness. I have to look how it's done.

What I can't see: Is the UI window freely resizeable? Is the dialog DPI-aware?

It's resizable and font size changes when I adjust the DPI.
That's default.

This stuff can suck up time.
I've noticed that ...

Thanks for your comment :)
 

Attachments

  • Bildschirmfoto_2017-10-16_19-34-49.png
    Bildschirmfoto_2017-10-16_19-34-49.png
    62.6 KB · Views: 230
It might be nice also to have to option to set the screen backlight to a specified brightness with a single press - people could use it to set it to minimum brightness (but not off) when using the device in the dark, without blowing out their night vision completely.
 
It might be nice also to have to option to set the screen backlight to a specified brightness with a single press - people could use it to set it to minimum brightness (but not off) when using the device in the dark, without blowing out their night vision completely.

I also had that idea. My brightkey.sh script already supports things like "brightnes up 5" so it increases the brightness for 5 levels. Also it can do "screen set x" so it sets it to level x.
I want to add a third column to the brightkey tab to set how much it will increase the brightness and to add an option to set it.
Good you mentioned it. I did forget that I already added the set function ...
Max and Min should be an easy option (set 1 and set 10 or whatever max will be later).
And one option to add a custom command.


Seems like that menu will keep me busy for some time.
I wanted to add the most important features first. More can always be added later even after release.
 
It looks completely different when I use a different theme. On my computer it fits perfectly to the XFCE settings.
I was referring to the border around the tab control. You know, that line you can see right below the title bar.

The LED driver seems weird to me then. I thought the point was to be able to set different colors for different events.
I only did simple brightness settings when playing around with the logo LED at last year's Gamescom, so I wasn't quite aware of that. Color picker for that? ;)
A color picker for the just the brightness would be kinda weird, though.

Do these settings apply in real-time actually? Otherwise an Apply button would be neat.
I'm actually wondering about the Prev and Next buttons. Are they for switching between the tabbed pages? Wouldn't say they're useless, but they feel unfamiliar at first.

Edit: Quiet honored to get called a designer, which I don't consider myself as. UX is complicated and can be overbearing, so I just check if it feels right compared to other applications. I only skimmed the UX guidelines of several OS' and toolkits. It helps a bit for stuff, but I don't adhere to all details of them.
 
The LED driver seems weird to me then. I thought the point was to be able to set different colors for different events.
Yeah That should be the case. The /etc/defaults/leds config file you should be able to specify the LED color of the RGB LEDS. It looks like he's parsing the lines from that config file. It looks like the RGB LEDS are broken up so you can control each color & brightness individually.
 
Last edited:
Yeah That should be the case. The /etc/defaults/leds config file you should be able to specify the LED color of the RGB LEDS. It looks like he's parsing the lines from that config file. It looks like the RGB LEDS are broken up so you can control each color & brightness individually.

Exactly.
It is like having one Red, one Green and one Blue LED.
I can add the same trigger for Blue and Red to get a very bluish purple but that's it.


The settings do apply in real time. I preferr that even if it's more work.
I might need to add an Apply Button for the scale as I need to restart the pyrainput daemon euch time and that might be too much when the slider moves rapidly.
 
On the Pandora, USB, Wi-Fi and mass storage are basically handled with a modprobe/rmmod.
For the details, check /usr/pandora/scripts/

HDMI should be handled by a xrandr, but it applies when running X.
I guess the HDMI console part will be handled by a boot parameter.
 
Back
Top