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…
https://gitlab.com/Robotista/shuttle-lander
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…
By semi-transparent, it should look somewhat like this:
Perhaps I am employing the keystroke combination incorrectly?
I see… You may need to patch the program yourself and compile it from source. Robotista’s seems to cover both ShuttlePro and ShuttleXpress so you may be able to use its code for reference.
You could also compile Shuttle Lander from source on the Raspberry Pi. All build dependencies are satisfied on Debian 11 for arm64.
Maybe QHotkey couldn’t register because the keys are bound by a different program or the desktop itself, or the desktop session is a Wayland session. QHotkey is incompatible with Wayland.
Thank you. I will let you know if I discover the cause.
1 Like
Checked and I’m running X11.
Hello… new here. I was able to set all the buttons and scroll controls on Contour Shuttle Express. I saved the configuration file and others should be able to simply import this after pointing to QPrompt as the target app. If there is a way to share an attachment here I will upload.
Robert Whitman
Hi @whitmanrf,
We don’t have means to upload files in the forum, but if you could send it to me via email I could host it in one of our servers. You can find my email address by going into QPrompt’s about page and clicking on icon with a letter next to my name. That will open an email client or a web browser in a page ready for you to compose your email. I don’t type my address here because of data mining bots.
Having said that, I think @videosmith was working on a preset like this as of recent. Maybe you should exchange your ideas with regards for this preset. Recent QPrompt v2.0 early access betas allow you to jump to specific velocities by pressing a number to jump to that velocity. This new feature integrates itself really well with the Shuttle’s jog.
If we were to create an official Shuttle preset, it should look something like this…
Have buttons for:
- Toggle Prompter (F9)
- Full Stop (Ctrl+P in QPrompt v2.0)
- Pause (Space in QPrompt v2.0)
- Esc (maybe)
Jog actions:
- Jog left, Up or reduce speed
- Jog right, Down or increase speed
Wheel actions:
- Outer Wheel Right, numbers from 1 through 7.
- Outer Wheel Left, numbers from 1 through 7 with Ctrl modifier pressed
- Outer Wheel Center, also Full Stop (Ctrl+P in QPrompt v2.0)
My prefs are set up like this:
Button 1 is Control-P to start/stop prompting
Button 2 is Ctrl-PageUp to go to previous marker
Button 3 is Page Up (user has to hold down the button, “rewinding” ) to re-cue to top. This should work with Home but it does not, yet, in this software.
(this is a feature request… for the Home key to re-cue to top of script… standard behavior)
Button 4 is Ctrl-Page Down to go to next marker
Button 5 is F9 to toggle prompter state between edit and prompt. To prompt, first you click button 5, then button 1 to enter prompt mode.
Center jog wheel: jog left is up arrow, hold down
jog right is down arrow, hold down
Center position: set to do nothing
Outer ring: do nothing
Thank you!
Button 1 will break with the new defaults in QPrompt 2.0. The rest looks great!
I have it on queue to add a keyboard shortcut to go back to the start, but that won’t be out for 2.0 because of the string freeze that we do for translations to catch up. Button 3 could be set to that when the time comes, that way users won’t need to press and hold.
Using it with Windows
If anyone is looking for help using the the Contour Design ShuttleXpress controller, or the Contour Multimedia Controller Xpress (as it now seems to be called) in the Windows operating system then I have created another thread to detail my own experiences in getting this to work well. It can be found here
1 Like
