Local display scaling options

[baoverulk]

I just recently added a Pi Touch 2 DSI display to my MoOde setup and it is a great improvement, easily letting anyone control the music without much instructions. It also nicely displays artwork for local files, radio and now Spotify and looks great!

However, while it looks pretty the controls are too small in my opinion, especially play/pause and volume control. I feel the user shouldn't have to aim very precisely to pause the music. 

I have zoomed the chromium browser in 200% which is better but still not quite what I'm looking for. I tried to start the browser in this zoom level with the --force-device-scale-factor=2.0 option of chromium-browser but for some reason this results in a zoomed in top left corner of the browser.

Any ideas how I could increase the button sizes? I have no experience with CSS but I guess there's such a file controlling this somewhere, right?

Thanks!

[TheOldPresbyope]

...
Any ideas how I could increase the button sizes? I have no experience with CSS but I guess there's such a file controlling this somewhere, right?

There's 23 .css files in the directory /var/www/css on your player. At least two have entries seemingly related to your problem: media.css and panels.css (I just searched for occurrences of  "knob" as a quick-n-dirty first step).


Fiddling with CSS rules and seeing their effect will certainly give you an "experience". Keep in mind that the HTML, Javascript, and CSS are all intertwined and that the code is crafted to give a reasonably satisfactory user experience on everything from a small phone screen to a large monitor. You probably should read Tim's moOde Application document.

Have fun.

Regards,
Kent

[Tim Curtis]

Most Smartphone GUI's have several settings that can adjust parts of the GUI larger or smaller to account for individual preferences and these usually work pretty good as long as the app that you use also honors these settings.

In moode Preferences the only such setting is "Font size". It prolly could be used to also proportionally adjust the size of various buttons. The challenge is that it was never fully implemented due to lack of developer manpower.

As far as hand modifying the CSS goes, the source files are "compiled" down to a few minified runtime files during the build and so one would need to bring up a local Gulp dev/build environment in order to modify and deploy for testing.

[TheOldPresbyope]

Oops. Forgot about mimification. I was looking at the directory on the Pi I use to “gulp” current GitHub repo contents.

Regards,
Kent

[baoverulk]

Ah, ok. I guess this isn't big enough of a problem to set up a dev/build environment. I've already tried changing the font sizes and that helped a little bit. I guess I'll just try to find a way to fix the browser on the local display to 200% without needing to connect a keyboard to do it.

And while I was thinking this through a different approach crossed my mind. I think I might just end up getting a tactile rotary encoder with a push button for volume and play/pause, assuming I can make it look decent.

Thank you both for your input!

[Tim Curtis]

Much easier to get a USB volume control like the one I've used for years. It has a nice heavy base and you can simply assign the push function of the knob to the "mpc toggle" command which toggles between play and pause.

https://www.amazon.com/dp/B01MV411BR?ref...tle_1&th=1

# Default /etc/triggerhappy/triggers.d/media.conf

Code:

KEY_VOLUMEUP     1 /var/www/util/vol.sh -up 1
KEY_VOLUMEDOWN   1 /var/www/util/vol.sh -dn 1
KEY_MUTE         1 /var/www/util/vol.sh -mute

# Modified

Code:

KEY_VOLUMEUP     1 /var/www/util/vol.sh -up 1
KEY_VOLUMEDOWN   1 /var/www/util/vol.sh -dn 1
KEY_MUTE         1 /usr/bin/mpc toggle

[baoverulk]

Yes, maybe I'll do that 

I thought play/pause would map to different commands and I'd have to add some logic to check the state but if /usr/bin/mpc toggle does this job it couldn't be simpler!

Thanks

[TheOldPresbyope]

Yes, maybe I'll do that 

I thought play/pause would map to different commands and I'd have to add some logic to check the state but if /usr/bin/mpc toggle does this job it couldn't be simpler!

Thanks

Probably should start a new thread if you want to discuss input devices and triggerhappy.

Keep in mind that pretty much any USB HID-class device can be used---keyboards, keypads, "knobs", purpose-built controllers, etc.---as long as the correct event mapping to moOde functions is done in triggerhappy.

Looking backwards 4 years, I see a FAQ/Guide of my own ("Using FLIRC and other USB devices...") and there are threads/posts by others as well.

I have the same USB volume knob that Tim cites and like  it...but...it is tethered, which can be a nuisance. I've explored lots of different wireless devices (see, e.g., the above link) and they all work to one extent or another. It's a matter of the number of control functions desired and, of course, personal taste.

If you like exploring fresh tech, I recently came across a promising device based on the open-source SmartKnob work of a few years ago. It's the  MaTouch SmartKnob. This is not a finished product but it looks like a good basis for a week or more of fun turning it into one.

ETA - That's not the only such device, as exercising your favorite search engine will tell you.

Regards,
Kent

[Tim Curtis]

The nice thing about triggerhappy is that it can monitor and print the events emitted from whatever device is connected making it easy to customize media.conf

[baoverulk]

Great advice, I'll check it out (and start a new thread if I need to discuss).

Thanks!