Add HTTP based integration with customizable port

[waydabber]

A HTTP based interface should be listening on a customizable port to receive commands. This is both for networked and CLI (with curl) integration.

[waydabber]

Added a built-in lightweight HTTP server. Command syntax is exactly the same as with the URL schema integration method.

[metawops]

Very nice feature! ❤️
Quick question: On my MacBook Pro the built-in screen has the name Color LCD so in the HTTP request in the parameter name I first tried to use Color%20LCD. This lead to a "Failed" response (HTTP code 404).
I then tried nameLike=color – same result.
When I tried OriginalNameLike=color the request finally worked.

What was I doing wrong when using the first two variations of the request? 😳

[waydabber]

Hi there, the name and nameLike will normally use the displayed name which is for the built-in display is "Built-in Display". That's why it did not work.

Note: with v2.2.1 a simpler syntax will be available as well (instead of using feature= + value=), but the app will remain compatible with the current syntax too.

Some examples:

curl http://localhost:55777/set\?namelike=xyz\&brightness=0.8

If you want the command to work for all displays in unison, you can simply use:

curl http://localhost:55777/set\?brightness=0.8

If you want the command to work for the active display (with the mouse), and decrease or increase the brightness by let's say 10% (this should be useful if you bind the action to let's say a brightness down key in Hammerspoon):

curl http://localhost:55777/set\?displaywithmouse\&brightness=-0.1\&offset
curl http://localhost:55777/set\?displaywithmouse\&brightness=0.1\&offset

[metawops]

Hi there, the name and nameLike will normally use the displayed name which is for the built-in display is "Built-in Display". That's why it did not work.

Ah, I see! 👍

Because these display identifying parameters have name in them I thought I'd try with what the app reports as "Display name" in the GUI:

I tried name=Built-in%20Display and this, too, didn't work ("Failed.", HTTP Code 404). 🤷‍♂️

I'm indeed just testing this new HTTP feature and started with a simple brightness change, so the whole request is http://127.0.0.1:55777/set?name=Built-in%20Display&feature=brightness&value=0.5.

Using the namelike version and specifying the full display name, too, doesn't work (404): http://127.0.0.1:55777/set?namelike=Built-in%20Display&feature=brightness&value=0.5

However, if I leave out the urlencoded space character %20 and the following "Display" together with namelike the request works: http://127.0.0.1:55777/set?namelike=Built-in&feature=brightness&value=0.5.

Is the %20 the problem? 😳

[waydabber]

no, the request processor (which is unified with what the CLI uses) won't accept space in a parameter as it interprets it as a whitespace and creates a separate command "Display" which it then does not understand. :) Sorry about that. Better to use namelike or some other identifier. I'll probably add some extra provision for spaces as it might be a problem in some of the future commands as well.