shell subprocessing + keyboard support? questions

[epibirikka]

This is an interesting repository as I recently did web development and is into r/unixporn, but I have some questions assuming if this project is still active.

Is there any API or a workaround for subprocessing for getting external information? (active workspace number, filesystem utilizing, dbus utilizing, or powering or rebooting from a powermenu window made with this)

I'm planning to add keyboard support for my powermenu window, but apparently, I saw your pull request about keyboard support, can I utilize it?

At first glance, I felt like this API is a bit lacking, because I feel like it's specifically made for HUDs or status bars to show time, computer performance, etc., unless if this is something made for fun.

Using i3 as my window manager.

[anko]

Hi! Thanks for writing down your thoughts.

Some answers:

I recently did web development and is into r/unixporn

Me too! :smiley: I first wrote this to blow minds in /g/ desktop threads.

Is there any API or a workaround for subprocessing for getting external information?

In short: No such API, because security. But you can do it with a web server.

• First, the "workaround":

  I'd suggest creating a simple local web server (e.g. with Node.js, or Python), and serving your overlay web page from it, then communicating with it from the overlay page, through an HTTP or WebSocket API. The web server can then launch appropriate sub-processes to service those requests. This keeps the web context and the rest of your machine neatly separated.

  That's what I do on my own machine: Node.js web server, with WebSocket to stream events from the server to the overlay page, from processes like ping, sensors, amixer, i3-msg, and so on.

• Second, why a Hudkit.spawn API doesn't exist:

  It's possible to give a web browser's JavaScript context powers to directly execute arbitrary code through just Hudkit.spawn. I implemented it to try it, in the uv-shell branch I pushed just now. I wrote it quite a while ago, but abandoned it because I couldn't find a way to make it safe. If at any point the overlay web view loads a malicious web page or script tag, that page can just directly run rm -rf ~! :scream:

  It requires libuv as an additional dependency, which is the same stuff Node.js uses internally. It adds a usage example, but no proper documentation. I don't recommend it, but it's your life.

At first glance, I felt like this API is a bit lacking, because I feel like it's specifically made for HUDs or status bars to show time, computer performance, etc.

I agree it's lacking for that. I've tried to keep hudkit focused on just the task of "put a transparent web view over your whole desktop", to keep it useful also for programs other than taskbars.

It would be very cool to have a separate project that uses hudkit, which is focused specifically on taskbars. It could automatically start a web server, exposing an API that lets the page JS access the sorts of data you mention. If you want to have a go at making one, I'd be happy to advise and answer questions.

I'm planning to add keyboard support for my powermenu window, but apparently, I saw your pull request about keyboard support, can I utilize it?

(For other readers' reference, that's PR https://github.com/anko/hudkit/pull/12.)

The PR lists its outstanding problems, but if those don't bother you, feel free to use it.

[epibirikka]

Thanks for replying!

While waiting for your response, I tried eww and stylizing with CSS was very limited for someone who takes CSS for granted (cannot position: relative in SCSS :skull:).

I didn't know that there were branches for things that I just admitted about, nice to know. I admire your statement about the subprocess functionality of Hudkit, never thought of a random suspicious "website" made for Hudkit would be that destructive.

The workaround seems better, because you can put any external necessary data (e.g. desktop.ini files for a rofi-like application), as I saw that not only Hudkit supports files but any link given. Never thought of that because of a scenario what if a port already got preoccupied, and how it should run because you have 2 processes running (in my case, flask and hudkit).

All that is left is to know how I would use them and it would be handled by me. So who would put in the tags [python + hudkit] when posting a rice? :eyes:

EDIT: Besides how do you think one would put the system tray icons on Hudkit?

[anko]

how it should run because you have 2 processes running (in my case, flask and hudkit).

I use a run script like this, which is run from ~/.xinitrc:

#!/usr/bin/env bash
PORT=5004
echo "Starting web server"
( node server.js "$PORT" ) &

echo "Waiting for server port to open"
while ! (ss --tcp --listening "( sport = :$PORT )" | grep LISTEN > /dev/null); do
    sleep 0.1
done

echo "Starting hudkit"
( hudkit "http://localhost:$PORT" ) &

# Wait for any child process to exit
wait -n
# Kill all child processes
kill 0

what if a port already got preoccupied

I "solved" that above by making the port configurable. If there's a conflict with port 5005, it's easy to change.

The proper way to do this on Linux would be to bind the server to port 0, which would make the OS open an arbitrary open port for you. You could then have the server process start hudkit, targeting whatever port the OS gave your server. But I was lazy. :+1:

how do you think one would put the system tray icons on Hudkit?

GTK3's StatusIcon API is deprecated, so I'd rather not depend on it. Hudkit may have to migrate to GTK4 eventually, if/when WebkitGTK gets GTK4 support.

[epibirikka]

How would I let my status bar dock into the windows instead of overlapping it?

[anko]

I currently do that by having i3bar running with no status_command, so all it does is reserve space at the edge of the screen and show the desktop switcher. Then I use hudkit to render the actual status bar contents in that area.

You can also disable the desktop switcher with an i3bar config property workspace_buttons no if you want the bar completely empty. It's also possible to run multiple i3bar instances, if you need multiple such areas. Or any other status bar program; they all use the EWMH _NET_WM_STRUT_PARTIAL window property.

[epibirikka]

Alright that should probably take care of my concerns on making a "desktop environment" with Hudkit.