You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been working on a number of changes to Deckmaster (some for which there are active pull requests, some withdrawn, and some still contained within my public fork), and I wanted to discuss my goals to see if they are compatible with the vision of this repository.
I started with the graceful shutdown issue I was encountering, which was merged, and currently the screen blanking/timeout PR is under review.
The next few things I would like are pushing towards "reactive buttons". The idea is to have buttons that change visual state depending on what's going on in my system.
There's currently a pull request that proposes deck brightness controls. The next thing would be to show the deck brightness value on a button, followed by pulling all sorts of "telemetry" from my system to affect changes to button labels.
To this end, the direction I've been going is to add a smartButton widget whose font/color/label/icon are configurable from things like the brightness and the previously alluded to "telemetry". This would be a drop-in substitute for button except that it would allow things like ${brightness} and ${telemetry[mail:count]} to be substituted into the font/color/label/icon.
Regarding "telemetry," what I've been going towards is a command that's run by Deckmaster and which outputs a stream of concatenated JSON objects which are interpreted by Deckmaster as map[string]string and merged into a map[string]string stored within Deckmaster's memory. The idea is that the command will emit changes to telemetry values and Deckmaster would track them and update the smartButton widgets that need the given values.
Further, the telemetry command could emit base64-encoded images that Deckmaster could use for icons. Thus, I would propose the ability to draw icons base64-decoded from strings. What I've been using so far is that if the icon string begins with base64: then the rest of the string is base64-decoded into []byte and fed into image.Decode to be used as an icon.
This way, the workings of the telemetry don't need to be all built into Deckmaster monolithically. By way of example, I'm using this to display thumbnails of my i3wm workspaces on the deck, and this is probably not something generally helpful to everyone using Deckmaster.
Are these changes—smart buttons, telemetry command support, and base64 image decoding—compatible with the vision of this repository? If not, I won't waste your time with them as PRs.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I've been working on a number of changes to Deckmaster (some for which there are active pull requests, some withdrawn, and some still contained within my public fork), and I wanted to discuss my goals to see if they are compatible with the vision of this repository.
I started with the graceful shutdown issue I was encountering, which was merged, and currently the screen blanking/timeout PR is under review.
The next few things I would like are pushing towards "reactive buttons". The idea is to have buttons that change visual state depending on what's going on in my system.
There's currently a pull request that proposes deck brightness controls. The next thing would be to show the deck brightness value on a button, followed by pulling all sorts of "telemetry" from my system to affect changes to button labels.
To this end, the direction I've been going is to add a
smartButton
widget whose font/color/label/icon are configurable from things like the brightness and the previously alluded to "telemetry". This would be a drop-in substitute forbutton
except that it would allow things like${brightness}
and${telemetry[mail:count]}
to be substituted into the font/color/label/icon.Regarding "telemetry," what I've been going towards is a command that's run by Deckmaster and which outputs a stream of concatenated JSON objects which are interpreted by Deckmaster as
map[string]string
and merged into amap[string]string
stored within Deckmaster's memory. The idea is that the command will emit changes to telemetry values and Deckmaster would track them and update thesmartButton
widgets that need the given values.Further, the telemetry command could emit base64-encoded images that Deckmaster could use for icons. Thus, I would propose the ability to draw icons base64-decoded from strings. What I've been using so far is that if the icon string begins with
base64:
then the rest of the string is base64-decoded into[]byte
and fed intoimage.Decode
to be used as an icon.This way, the workings of the telemetry don't need to be all built into Deckmaster monolithically. By way of example, I'm using this to display thumbnails of my i3wm workspaces on the deck, and this is probably not something generally helpful to everyone using Deckmaster.
Are these changes—smart buttons, telemetry command support, and base64 image decoding—compatible with the vision of this repository? If not, I won't waste your time with them as PRs.
Beta Was this translation helpful? Give feedback.
All reactions