Add REST API for remote controlling QPrompt

[rse]

Is your feature request related to a problem or a limitation? Please describe...

Currently QPrompt can be controlled with mouse or keyboard events only. When running both QPrompt an a presenter software like PowerPoint in parallel, it is impossible to easily control both applications at the same time. For instance, a Logitech Presenter remote controller just emulates keystrokes and required PowerPoint to be the active window. But for controlling the speed of the teleprompter the operator at the same time needs the QPrompt window to be the active window.

Describe the solution you'd preffer

I would like to see a simple REST API of QPrompt on localhost which can be used to control QPrompt remotely (e.g. via a Stream Deck) while the QPrompt windows IS NOT active at all (to allow PowerPoint or other apps to be controlled via keyboard).

Describe alternatives you've considered

Currently there is no alternative. We just open PowerPoint and QPrompt in parallel and the operator switches active windows continiously and the presenter is not allowed to remote click to the next slides in PowerPoint. The only alternative is to open the PowerPoint presenter view on the teleprompter and keep the prompter texts in the slide notes. But this means QPrompt cannot be used at all.

Provide use examples

Just imagine having PowerPoint and QPrompt open in parallel and the presenter wants to manually remote click to the next slides (with a Logtech Presenter) and the operator wants to control the text speed in QPrompt.

[Cuperino]

Will do. I was already going to be adding remote control but enabling the API to be controlled by third party software and devices such as the Stream Deck seems like a great idea to me.

Another alternative I was looking into is enabling keystroke detection while QPrompt isn't focused. Unfortunately, APIs to implement this are specific to each OS, and compositors with strong security considerations by design, such as Wayland, simply don't allow keystrokes to be captured when the another window is being focused. Therefore, the solution you've proposed should be implemented first.

[rse]

Yes, exactly: global keystrokes (similar to what AutoHotKeys under Windows or Butler under macOS do) would be an option, but (1) this is very platform specific, (2) usually requires special privileges (under macOS one has to enable Accessibility control) and (3) it is still to inflexible (as it still would not allow real remote control). So, a simple REST API (with the help of something like e.g. libmicrohttpd?) would be a lot more flexible. It would even allow to map PTZ keyboard function keys (e.g. of a Birddog PTZ Keyboard) to control QPrompt from any other device.

[videosmith]

Is app dedicated cat5/network port support an option? Hardware such as Euphonics/Avid Artist support works across that protocol.

[Cuperino]

I can't say for sure @videosmith. The Cat5/network (RJ45) port you're describing can be used with several data communication protocols. TCP/IP is the most common one, and protocols such as HTTP are built on top of it. If the Artist can be programmed to send an HTTP request, it will certainly be able to communicate with a REST API like the one @rse suggests.

[rse]

The main point for HTTP/REST is that nearly all typical remote control equipment can out-of-the-box speak it: Elgato StreamDeck, Companion, Birddog PTZ Keyboard, Skaarhoj keyboards, Central Control, etc. By supporting REST endpoints, QPrompt will be open for a lot of such remote control devices...

[Cuperino]

Has either of you got any spare you'd be willing to donate to the project? I'll gladly add support to them.

[rse]

You could use Companion https://bitfocus.io/companion/ for free and they have a stream deck emulator built-in, so at least in order to support the popular Elgato Stream Deck devices (which you can find nearly everywhere) you don't need any hardware devices at all. But don't bother too much about the actual devices: they all do simple HTTP GET requests, so if your QPrompt API is based on simple HTTP GET endpoints, really all those devices will be able to speak to it. Don't fiddle around with the hardware devices at all. Just provide a simple HTTP API and the devices will be able to control QPrompt.

[videosmith]

Spare? On Wednesday, February 23, 2022, 03:56:47 PM EST, Javier O. Cordero Pérez @.***> wrote:

Has either of you got any spare you'd be willing to donate to the project? I'll gladly add support to them.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[Cuperino]

@rse You could use Companion https://bitfocus.io/companion/ for free and they have a stream deck emulator built-in, so at least in order to support the popular Elgato Stream Deck devices (which you can find nearly everywhere) you don't need any hardware devices at all. But don't bother too much about the actual devices: they all do simple HTTP GET requests, so if your QPrompt API is based on simple HTTP GET endpoints, really all those devices will be able to speak to it. Don't fiddle around with the hardware devices at all. Just provide a simple HTTP API and the devices will be able to control QPrompt.

That is awesome, I have plans to fully support the Stream Deck. This will make it easier to do so.

The only hardware I need to get my hands on still are widely requested USB devices that don't do HTTP, such as Contour Shuttle controls.

@videosmith Spare?

Spare, not in use, somewhat broken even. As long as it hurts no one to give it, and a PC recognizes it when you plug it in, it should do the work. Nevertheless, as rse explained, I do not need the hardware if it communicates over HTTP (a.k.a. over the network).

[progressmedia]

+1 for Bitfocus Companion