Love what you’re doing! I’m looking to use QPrompt with a Contour ShuttleXpress. Are there any plans to support controlling the speed of the prompting with the ShuttleXpress?
1 Like
I have had partial success adapting this script and mapping the appropriate keystrokes on the function buttons and the jog wheel. So far, limited success with the shuttle ring.
1 Like
Hello @jlex,
A few users, including @videosmith, have asked for Shuttle support to be added. This was my reply to videosmith’s request over at GitHub:
Shuttle Pro/Xpress support · Issue #37 · Cuperino/QPrompt · GitHub
"Dedicated hardware support requires said device to be developed for individually on each supported platform. I’ve already identified a library that can be used to abstract some of the code so that its easier to support all platforms.If you or anyone is willing to donate one or more of these devices, I will add support for them."
Now to answer your question more directly, and update @videosmith on the matter:
I’m currently in the process of purchasing both the Shuttle Pro V2 and Shuttle Xpress with the intent of developing support for them, on all platforms, later this year. I will only be supporting these two devices for now, and none of their earlier versions.
QPrompt is meant to be a self sustaining project, so I may end up charging for the feature. Nevertheless, QPrompt will always be free software, as defined by the Free Software Foundation, and Open Source as defined by the Open Source Initiative.
Anyone interested in QPrompt having support for the Shuttle Pro V1, or any other device, is invited to donate one of such devices to the project, and I will gladly provide support for it. Code contributions (contributions in the form of software development time) are also welcome.
Quick update. I ended up purchasing the Shuttle Xpress and Shuttle Pro V1, and am still on the lookout for a Shuttle Pro V2.
I’ve also taken a quick look at nanosyzygy/ShuttlePRO’s source code and noticed that it is dependent on X11. This means that this library will only work on Linux and Unix systems that make use of the Xorg display server. Which doesn’t include modern versions of macOS, nor any version of Windows; and it will fail to work on future Linux distributions once distros have fully replaced Xorg with Wayland and start offering no X11 backwards compatibility. This shouldn’t be a problem for commonplace distributions until, at least, 2026.
A more cross platform approach is recommended to enable QPrompt’s Shuttle support on a wider range of devices, and for a longer term. I’ll be looking into a library called libusb, which supports multiple operating systems, is well established, and has the potential to work for a very long time.
Here’s what I’ll be working with: libusb: Asynchronous device I/O
Brief update: I have all Shuttle models, now all I need is time to work on this.
Awesome! Let us know if you need a beta tester.
Quick question @jlex. What operating system do you run or would you use to test ShuttleXpress support with? I know videosmith uses primarily Linux on arm64 Raspberry Pi hardware.
Planning on Windows 10 right now because our institution has a Windows site license. But we have Macs and Linux machines, and there’s a chance we will have to use one of them for our prompting solution.
@jlex I see. I’m just checking because this is the kind of feature that needs to be implemented once per operating system. There is sadly no cross-platform way to target all systems at once.
While looking into this topic, I realized that Linux actually doesn’t need any special drivers to access any of Countour’s devices as these actually come with the Linux Kernel. The challenge lies only in mapping these inputs because they’re not treated as mice, keyboards, or gamepads by default. Listening to them directly seems to be the only option to control QPrompt while none of its windows are focused, but this solution would be limited to QPrompt.
I’m thinking it would be nice to have a separate GUI and service to do the remapping, much like Contour offers for Windows and Mac. This would enable having different configurations for different apps, and, eventually, switch automatically between them, like what can be achieved with Contour’s software in other systems.
If I were to make this app, do you think you would use it? I’m thinking of maybe offering it to Contour or licensing it to users like you for a fee. A one time fee since an app like this rarely needs maintenance.
For myself, the method I’ve employed modifying nanosyzygy/ShuttlePRO’s code is adequate, albeit slightly labor intensive to rewrite changes to shortcuts, etc.
And since my needs are only for your app, switching is not necessary at this point.
I would suggest some sort of sale/barter/compensation with Contour would be the best approach, since they offer their drivers free of charge and your users may react to a licensing fee for only this function (although I support fees for your QPrompt app).
I see. Thanks for the reply.
I’m aware that Linux users in general may react negatively to charging for the software that I make. Charging usually prevents word of mouth from happening because paying for software in Linux is a controversial topic. This is because paid is associated with proprietary software, even when that isn’t the case; which is why I admire the Elementary OS and Flatpak projects, for their initiatives that push the boundaries.
Going back to the Shuttle’s interface, I see people could complain because this may seem like a simple app that Contour gives for free in other platforms, but there’s nothing simple about this software on Linux. There are over a dozen of window managers and desktop environments to support, and two completely different display technologies X11 and Wayland, that deal with inputs in very different ways.
Most developers out there also wouldn’t know how to tackle our desktop fragmentation in a way that is sustainable. To be honest I’m mostly interested in this side project because it seems like a fun challenge, but that’s only enough for me to get it started, not necessarily finished. Either way, it’s just an idea for now.
Sounds like an interesting project… perhaps if you were able to broaden the scope of the app or merge it with others to include more functionality like a linux usb peripheal tool box to work with devices like speech readers for the blind, home automation, ete.? That may attract more $$ especially from foundations and such.
Perhaps. I thought about implementing this as part of Piper/Ratbag, which are mice configuration tools, but the automatic switching between apps would go out of that project’s scope.
Found this today… haven’t got it working yet.
One observation, while installed, the prior method using nanosyzygy returns a resource busy error message.
Also does not appear to have a RPi release yet…
That means they’re probably employing the same technique to bind those keys. I’m using this library, called QHotkey, to listen for key presses in QPrompt. GitHub - Skycoder42/QHotkey: A global shortcut/hotkey for Desktop Qt-Applications
v1.1 already incorporates it as a testing ground. Pressing Meta+Alt+F10 should make all of QPrompt’s windows semi-transparent. Pressing the combination again will restore 100% opacity on the windows. Try binding that key combination into one of those apps and launching QPrompt afterwards. If the combination stops working on QPrompt, it means the method being employed to grab keys may be the same, and thus conflict between all of these apps.
I believe the issue is their app. I tried assigning one ShuttleXpress button to F11 to see if it would command a browser to fullscreen… failed silently.
Maybe… I’ve got to say, Robotista/shuttle-lander looks very promising! The program is grabbing the inputs straight from the Shuttle devices using native Linux APIs. That is the approach I was planning on taking for QPrompt because I couldn’t find a cross platform solution to read those inputs; but I decided to focus on global hotkeys instead for now, since they would allow routed keys to work even when QPrompt isn’t focused. Plus, the lack of a cross platform API means I’d have to do the same R&D on Windows and Mac, and Mac’s documentation on the topic is very lacking.
Shuttle-lander then converts device inputs into keys using what I think is the same approach as Nanosyzygy’s ShuttlePRO for X11 systems. It goes beyond that by also adding Wayland support. Wayland is great for visual performance but supporting for something like this is a very difficult task due to the lack of standardization when it comes to Wayland desktops.
QHotkeys currently does not work on Wayland. I’m waiting for more standardization to happen before jumping in to add support for it. This video is about an ongoing effort to accomplish this: XDG Desktop Portals Fix Waylands Biggest Problem - YouTube I’ve informed QHotkeys developers about the discussion referenced in the video. They’re also waiting for standardization to occur before adding Wayland support. I think it’ll be one or two years before we full Wayland support become a reality for hotkeys, so it’s good to see the shuttle-lander project tackling the key mapping aspect.
Going back to incorporating Shuttle support in QPrompt. I’m personally doubtful of this being the right approach anymore. But if it were required, I would re-write all of the multi-threading code in shuttle-lander using Qt instead of straight POSIX to increase compatibility with other platforms. Shuttle-lander’s UI would be scraped because it’s written using GTK and wxWidgets, which are two of Qt’s competing frameworks.
My only criticism is that similar to how QPrompt is stuck in Qt 5 because of KDE Frameworks, shuttle-lander is also stuck indefinitively with GTK 3 because they’re using wxWidgets. Many programs are going to be stuck to GTK 3 for a very long time because of wxWidgets. Distributions will likely provide many years of support to GTK 3 because of this. Now, because shuttle-lander will continue to only target Linux, if it were up to me, I would advice re-writing the interface using libadwaita and GTK 4.
I tried the key combination, no response here.
Nanosyzygy’s method, although a somewhat inelegant, works well enough for me at the moment. No real need for you to prioritize that, imo. My only wish is that the code for the shuttle ring worked, so far, I get jogshuttle(11,120) invalid code error messages… still trying to sus that out…