New Touch/SteamDeck-optimized UI

[DavidoTek]

Is your feature request related to a problem? Please describe. Current UI isn't optimized for touch screens. Built up using multiple windows which doesn't work that well with SteamDeck's handheld-mode.

Describe the solution you'd like Provide new UI, made using QtQuick/QML, consisting of a single view/window with different pages.

[teppyboy]

But Qt with QtQuick file size will be very large, and also users are already needed to switch to Desktop mode before installing & using this application anyway

[KAMiKAZOW]

But Qt with QtQuick file size will be very large

Why? Isn't QtQuick in the KDE runtime? It's definitively in the repos of all regular desktop Linux distributions.

and also users are already needed to switch to Desktop mode before installing & using this application anyway

Installing: Yes

Using: I think the point of this request is that any further use should preferably happen in Game Mode.

[teppyboy]

But Qt with QtQuick file size will be very large

Why? Isn't QtQuick in the KDE runtime? It's definitively in the repos of all regular desktop Linux distributions.

You do realize that the official packages are Flatpak and AppImage right? They ignore system dependencies and pack with their own.

all regular desktop Linux distributions.

If you're talking about Arch Linux/SteamOS then you're right at "Isn't QtQuick in the KDE runtime?", but KDE is Qt5, while we uses Qt6, and Qt6 would take 971,49 MiB spaces when you install using sudo pacman -S qt6 (yes there are some unnecessary components but qt6 is more convenient than listing all necessary packages)

Since this uses Qt6, say hello to Ubuntu < 22.04 :smile:

and also users are already needed to switch to Desktop mode before installing & using this application anyway

Installing: Yes

Using: I think the point of this request is that any further use should preferably happen in Game Mode.

It's possible, but you need to create a script to add non-Steam game to Steam.

[KAMiKAZOW]

You do realize that the official packages are Flatpak and AppImage right?

Yes. So? Flatpak supports runtimes with the KDE runtime being hosted by Flathub, so I don't see the argument here: https://docs.flatpak.org/en/latest/available-runtimes.html#kde

They ignore system dependencies and pack with their own.

No, Flatpak supports dependencies: https://docs.flatpak.org/en/latest/available-runtimes.html#kde

If you're talking about Arch Linux/SteamOS then you're right at "Isn't QtQuick in the KDE runtime?"

I think this comment makes it very clear that you don't know that "runtimes" in Flatpak terminology are.

[DavidoTek]

Why? Isn't QtQuick in the KDE runtime? It's definitively in the repos of all regular desktop Linux distributions.

Currently, both Flatpak and the AppImage use the PySide6 pip package (which includes all Qt libraries), but QtQuick/Qml stuff is removed before packaging.

already needed to switch to Desktop mode

This would be a nice to have feature so people can use it after installation in SteamOS' Game Mode. But as you said, people have to use the desktop mode anyway, so it's a low priority.

[woj-tek]

But as you said, people have to use the desktop mode anyway, so it's a low priority.

I was just searching for a way to add ProtonUp-QT to Steam to run/update it directly without Switching to desktop mode. Yes, people have to switch to DM to install ProtonUp but after that the only time I switch to desktop mode is... to run ProtonUp to update proton. It would be awesome to be able to do it from within Steam :-)

[DavidoTek]

I‘m currently preparing a way to automatically add ProtonUp-Qt as a Steam shortcut (https://github.com/DavidoTek/ProtonUp-Qt/pull/177).

You can manually add a Non-Steam game to your library, that should work on Steam Deck too.

update it directly

I wonder, do Flatpaks update automatically on Steam Deck?

[woj-tek]

I‘m currently preparing a way to automatically add ProtonUp-Qt as a Steam shortcut (https://github.com/DavidoTek/ProtonUp-Qt/pull/177).

Awesome, subscribed!

update it directly

I wonder, do Flatpaks update automatically on Steam Deck?

Not sure. When I'm in desktop mode I see notification about updated packages that I can run manually. Haven dug too much there to see if there is an option to update those automatically (probably it would be possible to add cron job to do it I guess?).

[DavidoTek]

Okay. Apparently there is a plugin for DeckyLoader that will automatically update Flatpaks: https://github.com/0xD34D/FlatpakUpdater (haven’t tested this myself).

[ttang4299]

Okay. Apparently there is a plugin for DeckyLoader that will automatically update Flatpaks: https://github.com/0xD34D/FlatpakUpdater (haven’t tested this myself).

@DavidoTek I've tested it myself and it does work. Touchscreen optimization would definitely be nice, but I think many folks would like to have a UI that can be navigated with mostly gamepad buttons (would be more convenient for desktop PCs as well). I hope to see the new UI soon, as fiddling around in Desktop Mode is the main reason I haven't given Proton-GE a try yet.

[ttang4299]

@DavidoTek Do you have an ETA on this? The current interface still feels very primitive and its alienating a lot of potential users who would not like to switch back to Desktop Mode every time something needs to be reconfigured.

[sonic2kk]

ProtonUp-Qt targets more than just the Steam Deck, and is built with a modern graphics toolkit called Qt6, using standard desktop widgets. I'm not sure "Primitive" is the right word, perhaps "desktop-oriented". It fits the regular Linux Desktop well. It's the same toolkit that is used by emulators such as Dolphin and Yuzu, and the entire KDE Plasma desktop uses Qt as its toolkit of choice. I certainly would not call Qt applications primitive.

Also, when installing compatibility tools, the Steam Deck would need to be restarted anyway whether you use ProtonUp-Qt to install them or not, either by going to desktop mode and back to game mode. This is because Steam needs restarted to pick up new compatibility tools, and switching desktop sessions accomplishes this (since Game Mode is just Steam running in a TTY with GameScope + some launch options).

If ProtonUp-Qt had some new UI and was used from Game Mode, Steam would still need to be restarted after the tools are installed. Unless you close Steam via SSH (Steam will restart if closed from Game Mode this way automatically), the fastest way to do this is either a reboot or switching to Desktop Mode and back to Game Mode (the latter is probably faster in most cases). Remember, Game Mode is simply the Steam Client running in GameScope in Big Picture, exactly how you can do it from a TTY on the Linux Desktop.

Not to mention, Desktop Mode is a large feature of the Steam Deck, I don't know that it's that much of a deterrent. Buying a PC and finding the desktop mode to be a deterrent or to find a desktop application alienating in desktop mode seems unusual to me, unless I'm misunderstanding.

A new UI would not solve the issue that going back into desktop mode resolves.

[KAMiKAZOW]

ProtonUp-Qt targets more than just the Steam Deck, and is built with a modern graphics toolkit called Qt6, using standard desktop widgets. I'm not sure "Primitive" is the right word, perhaps "desktop-oriented". It fits the regular Linux Desktop well. It's the same toolkit that is used by emulators such as Dolphin and Yuzu, and the entire KDE Plasma desktop uses Qt as its toolkit of choice. I certainly would not call Qt applications primitive.

Well, this bug report is about leveraging QtQuick to make a GUI that works fine in all environments.

Also, when installing compatibility tools, the Steam Deck would need to be restarted anyway whether you use ProtonUp-Qt to install them or not, either by going to desktop mode and back to game mode. This is because Steam needs restarted to pick up new compatibility tools

Minor updates to Proton-GE and such should not be a new installation anyway, and just update a single installation of Proton-GE-8 but that would be a bug report to https://github.com/AUNaseef/protonup

the fastest way to do this is either a reboot or switching to Desktop Mode and back to Game Mode (the latter is probably faster in most cases).

It may be technically the fastest but it's not the most convenient way when one sits on a park bench and has no mouse at hand. Using desktop more using touch alone is a chore. Personally, I'd rather reboot the device.

[DavidoTek]

As much as I‘d like to give an ETA on this, there isn’t one at the moment.

It isn’t just as simple as recreating the UI in QtQuick, there are quite a few things to consider:

• First, one needs to design a good looking and user friendly ui in QML. With QtWidgets, it is quite easy to do as you only need to add the ui components you need to fitting layout containers and Qt will handle everything else, including adjusting the style for your desktop. With QML there are a bit more options and you probably want some HIG to follow. I‘m not a ui designer so it could end up looking ugly if not designed carefully. I wonder what elements are easiest to use on a touch screen or with a gamepad. We could keep the combobox at the top and just make the ui larger. Alternatively, we could utilize a sidebar as ProtonPlus has it.
• A great part of the codebase handles ui functionality. All of that would need to be rewritten.
• The code isn‘t cleanly divided into frontend and backend, but rather some of the logic is mixed with the code which is used for the QtWidgets ui functionality. I don’t like this, but that’s just how it is at the moment. Some more requirements engineering work would need to go into fixing that. Also, ProtonUp-Qt isn’t actually using AUNaseef‘s protonup as a dependency anymore. There were some parts inspired from it, but most of the codebase is now independent.
• As sonic2kk pointed out, Steam needs to be restarted between changes anyway, so we need to find a way to handle that.
• Shipping QtQuick increases the AppImage size. Not so relevant for the Flatpak as KDE Runtime should include this anyway.

If you or anyone is experienced and wants to create a mock-up (e.g., in Lunacy), or create a PR, feel free to do so. I can’t say definitively when I will find time for the ui rework.

[sonic2kk]

Well, this bug report is about leveraging QtQuick to make a GUI that works fine in all environments.

This is not a bug report, this is a feature request. The existing UI is not a bug, as ProtonUp-Qt was made before the Steam Deck.

Minor updates to Proton-GE and such should not be a new installation anyway, and just update a single installation of Proton-GE-8

This isn't desirable as default behaviour and goes against how Proton is meant to be used. It may be feasible as an option, I think an AUR package can do this, but it is preferable to have individual Proton installations all separate. This is for many reasons but two big ones:

• Updating Proton versions, or Wine versions I'm general, has a chance of breaking prefixes. This is why the GE-Proton AUR package is disliked. When you change the Proton version, the prefix gets updated with all of the new library versions.
• Proton version changes often have minor regressions, so it is best practice to have at least two GE-Proton versions: The latest, and the one before it. Also, some games only work with slightly older Proton versions or work better.

The idea of having one single GE-Proton version installation by default for each major Proton version is a no-go. That simply should not be default.

It may be technically the fastest but it's not the most convenient way when one sits on a park bench and has no mouse at hand.

Not sure that you should be doing tinkering on a park bench. I'm sorry if Desktop Mode is a chore, but here's the thing: The Steam Deck is a Linux PC. What you do in Desktop Mode is the same that everyone else on the Linux Desktop does to install Proton. Remember, GE-Proton or any other flavor isn't to be installed lightly or just for the hell of it, and you should be aware of the risks of using community Proton flavours.

To make desktop mode easier to use, you can always change the desktop configuration layout. But I see no reason why it should be a chore. The Steam Deck is a PC.

[sonic2kk]

We could keep the combobox at the top and just make the ui larger.

@DavidoTek Before considering a rewrite, we should wait for KDE Plasma 6, when ProtonUp-Qt (and other Qt6 apps I believe) should fit more in the style of the KDE desktop. Qt5 apps fit the look and feel, including PySide2 apps, but Qt6 apps (like Dolphin and Strawberry) don't yet. We should wait and see if/how the UI changes from this. It isn't going to magically switch to QML or anything but buttons will probably become bigger and things like that.

And, the Steam Deck is likely to get Plasma 6, if nothing else for the improved Wayland support (Valve are eager to move to Wayland) and color management (to help with the Steam Deck OLED). Plus, if the Deckard is going to have a desktop mode, they'll want a VR desktop powered by Wayland.

In the meantime, Qt has a scale factor environment variable. I can't remember the exact name now but I did use it before for some hiDPI stuff. I think it's something like QT_QPA_SCALE_FACTOR=1.5 for 150% scaling (too much, just an example). It's QT_SCALE_FACTOR. Here is a screenshot running from source, where the buttons are bigger (the Flatpak buttons, maybe because of font differences, are slightly smaller), using QT_SCALE_FACTOR=1.0, 1.25, and1.5`:

Maybe we could look into something like this? It might be better to have a preferences modal with a setting to control this (which may eventually get replaced with QML I guess, but for now, we use Qt modals, so it would have to work that way for now). It could replace the "About" button with a "Settings" button, and "About" could be a tab on this modal.

We could possibly find a "hack" to check if we're running in game mode by looking for some processes (STL does this with I think looking for generate-drm-mode but I'll have to double check). We could try to maximise the window if we're running on Game Mode and set a scale factor.

That wouldn't solve the "modal" issue, for things like the games list and so on, but I'm perhaps in the minority that would prefer we didn't go that road. I like the standard Qt desktop application feel as it is 🙂 For touch optimisations, ProtonUp-Qt already makes efforts here more than other applications, by having dedicated close buttons along the bottom.

---

Though if we do go the route of having a QML rewrite, KDE I believe have some HIG documentation that could be followed loosely. It's mostly for their own Kirigami I believe, their library in top of QtQuick that has gotten a notable amount of pushback from the Linux Desktop community, but I'm sure some of it could serve as a bit of a baseline :-)

It's also worth pointing out that GameScope's handling of multiple windows in Desktop Mode and graphical applications in general has improved since the early days of SteamOS. Mouse sensitivity is still somethings a little odd, and sure it looks a bit odd due to the nature of how Steam Deck handles compositing desktop applications, but I don't think switching to QML would fix that, either. Even web apps when sized to fit GameScope (like web game wrappers on the Steam Store i.e. Cookie Clicker) still look and perform strangely. Plus, navigating the Steam Deck with a touch screen is like navigating a Switch with a touch screen, I'm not sure how beneficial it actually is.

A UI change might make ProtonUp-Qt easier for some folks in Desktop Mode, sure, but for some reason Steam Deck users don't like Desktop Mode, and I think it's just going to have to be a trial-by-fire of those users getting used to Desktop Mode and how desktop applications work. I don't see a UI change being a saving grace and suddenly removing the "issue" that is using a desktop application. Having said that, the Steam Deck isn't the only handheld target, but it seems to be a focus here, and I think people might miscalculate how much of a difference a UI change will make. It's still a desktop UI toolkit, it's still a desktop application, and it will still require restarting Steam in some way for the changes to take effect (or other launchers too, such as Lutris or Heroic). And because of all of this, using ProtonUp-Qt in Desktop Mode will still be the best way to use it, to avoid sluggish UI, cursor speed issues, poor filtering, and a host of other issues. It would be like running a game launcher in GameScope: It works, but it's not ideal, even when optimised for a touchpad, because GameScope is made with game applications in mind. Anything that uses a more traditional UI such as game launchers start to break down a little bit.

I also worry that a UI overhaul would end up creating more issues with a lot of disagreement around how to go about a UI change.

[DavidoTek]

Before considering a rewrite, we should wait for KDE Plasma 6, when ProtonUp-Qt (and other Qt6 apps I believe) should fit more in the style of the KDE desktop.

Mouse sensitivity is still somethings a little odd, and sure it looks a bit odd due to the nature of how Steam Deck handles compositing desktop applications, but I don't think switching to QML would fix that, either

I also worry that a UI overhaul would end up creating more issues with a lot of disagreement around how to go about a UI change.

I'd prefer staying with QtWidgets too. What I didn't consider is that we could actually create a custom style for ProtonUp-Qt that is loaded when using it on the Steam Deck. Styling can be done using CSS like code.

Qt has a scale factor environment variable We could try to maximise the window if we're running on Game Mode and set a scale factor.

I thought about that too. We're already checking if "steamos" not in self.distinfo: for STL. Maybe this could be adopted for adjusting the scaling factor/styling.

It could replace the "About" button with a "Settings"

Yeah, the name is not very intuitive. I think we even had someone asking where to find the settings.

It's also worth pointing out that GameScope's handling of multiple windows in Desktop Mode and graphical applications in general has improved since the early days of SteamOS That wouldn't solve the "modal" issue

That feels a bit ugly. I played around with that a while back and tried to add the dialogs as sub-widgets of the main window. That sadly didn't work. Is there a way to show both the dialog and the main window with Gamescope?

Mouse sensitivity is still somethings a little odd, and sure it looks a bit odd due to the nature of how Steam Deck handles compositing desktop applications

I wonder how many people are using the joysticks for navigating the menus. Ideally, the ui should be usable with only the joysticks and the touch screen

---

sonic2kk has made a number of good points here. Summarized, what we could do is to add logic that detects whether ProtonUp-Qt is currently running on the Steam Deck and then apply following changes to improve the user experience:

• [ ] Adjust scaling factor and adjust size to make it fullscreen
• [ ] Optional: Apply a Steam-like Theme --> https://github.com/DavidoTek/ProtonUp-Qt/discussions/309
• [ ] If possible: "Integrate" the dialogs into the main window, so it doesn't vanish when a dialog is opened
• [ ] (Improve the joystick menu navigation)

[sonic2kk]

What I didn't consider is that we could actually create a custom style for ProtonUp-Qt that is loaded when using it on the Steam Deck. Styling can be done using CSS like code.

I like this idea. We do this a little bit in some places, like when we set the text color for ProtonDB rating on the Steam games list. Since this could be more significant, can we create a stylesheet file to load from? It might be cleaner and more maintainable to read from a file instead of doing this inline :-)

We're already checking if "steamos" not in self.distinfo: for STL. Maybe this could be adopted for adjusting the scaling factor/styling.

That should work I think.

That feels a bit ugly. I played around with that a while back and tried to add the dialogs as sub-widgets of the main window. That sadly didn't work. Is there a way to show both the dialog and the main window with Gamescope?

As far as I understand, this is not possible. GameScope only shows one window at a time, and this is problematic in a handful of instances. Applications such as ProtonUp-Qt are impacted, as well as things like game launchers that may show an additional popup for settings (including launchers for native games, not limited to Wine/Proton), tools like ModOrganizer 2 -- It's a wide-ranging "limitation" though I believe the single-window focus is by design.

ProtonUp-Qt already shows a close button, is there any technical issue with having the dialog take focus in a GameScope session? It doesn't look great because the dialog is scaled up, but this isn't exclusive to ProtonUp-Qt, it's simply how applications that show pop-ups work under GameScope.

I wonder how many people are using the joysticks for navigating the menus. Ideally, the ui should be usable with only the joysticks and the touch screen

Agreed, and supposedly the Steam Deck OLED has improved touch accuracy, which can help also. A very, very minor thing to keep in mind is third-party screens. Some may not have touch-screen support. I think while making the UI bigger etc is of course good all around for Steam Deck, controller navigation support should be prioritised over touch-screen when we think about the Steam Deck UI improvements.

Although, in Desktop Mode, unless launched via Steam I'm not sure that ProtonUp-Qt picks up the Steam Deck controls as a controller. Since it's reported as a keyboard/mouse without Steam Input wrapping just like the Steam Controller.

[DavidoTek]

[...] can we create a stylesheet file to load from? It might be cleaner and more maintainable to read from a file instead of doing this inline :-)

According to this post (from 2011, but seems to be the same in 2023), we have to load the file and pass it as a string. Fine, I guess.

https://stackoverflow.com/questions/4810729/qt-setstylesheet-from-a-resource-qss-file

I believe the single-window focus is by design. It doesn't look great because the dialog is scaled up, but this isn't exclusive to ProtonUp-Qt, it's simply how applications that show pop-ups work under GameScope.

I guess then we can't do much about it on that side. We could do something like "(Create a different main window and) load the ProtonUp-Qt main window as a central widget. Then add the dialog as a floating widget over the main window and darken/blur the background"

I did some research and this may be possible using QMenu or by changing some properties of the window. I have to look into that.

third-party screens. Some may not have touch-screen support I think while making the UI bigger etc is of course good all around for Steam Deck, controller navigation support should be prioritised

Ah, I didn't think of that. Yeah, good controller navigation should be our goal and a large ui should help the readability from a distance.

[ttang4299]

I think a screen at the end of Proton installation should prompt users to reboot the system, if one is needed.

And yes, prioritize controller navigation > touch, though touch would be nice to have in the future once controller navigation is figured out. Larger UI would definitely be useful, especially in cases where the Steam Deck is docked to a monitor/television.

[sonic2kk]

I think a screen at the end of Proton installation should prompt users to reboot the system, if one is needed.

This would only apply to SteamOS, and only for Steam. Although, from desktop mode, Steam can just be restarted like it can on your Linux PC.

I think perhaps this is overkill? I'm also not sure that restarting SteamOS (or even Steam for that matter) is possible / ideal from the Flatpak scenario. Personally, I would be very creeped out if a program like ProtonUp-Qt prompted for a full system reboot like this.

To be honest, I think the responsibility should be on the user to know they have to restart their device, as they have to do that on their Linux PC anyway I think it should be fairly clear anyway. Restarting isn't even fully accurate either as again, only Steam has to be restarted. This can be done in a number of ways on SteamOS. Switching from Desktop Mode to Game Mode counts as a client restart (since it just logs out and logs in again to a GameScope session, like you can do with something like the ChrimeaOS-inspired gamescope-session package). Restarting the Steam Client in Desktop Mode or even in Game Mode if you kill the process via SSH / another program (compatibility tools can also do this by running a shell command to kill the Steam process). Anything that restarts the Steam Client (and remember, Game Mode is just the Steam Client running with a few extra flags in Big Picture Mode via a GameScope session) will restart Steam. I think it would be a big overreach for ProtonUp-Qt to have the ability to restart the Steam Client, and inaccurate to suggest a reboot.

A compromise may be to note on thee Readme / Install dialog that the Steam Client should be restarted for these changes to be effect, but I imagine anyone tinkering with a custom a compatibility tool should already be aware of this... This applies broadly to a lot of software and other launchers like Lutris also need to be restarted I believe. Maybe a general note that your launcher should be restarted for these changes to take effect would be better.

Also, to be clear, ProtonUp-Qt does not install Valve Proton. Those versions are tracked in appinfo.vdf and are fixed and synced by the Steam Client, they are managed entirely independently to third-party compatibility tools such as GE-Proton. Just wanted to make this distinction.

[ttang4299]

@sonic2kk Perhaps I used the wrong phrasing there, but I meant to say that the program should remind the user to perform a system restart whenever they want the changes to take effect, at a convenient time of their choosing.

And I'm well aware Valve Proton isn't installed, I was merely using Proton as a blanket term for all other versions of Proton.

In the end, the goal here is to not necessitate the use of Desktop Mode where mouse cursor use is required, after all the initial setup has been done, as some users may prefer to use a controller for reconfiguration.

[sonic2kk]

You could add ProtonUp-Qt as a Steam shortcut (there is a button to do this on the About menu, #177), then with improved controller support, it can be launched from Desktop Mode hopefully with correct Steam Input wrapping for the controller support.

I think the goal of entirely negating the use of Desktop Mode is a bit futile, as inevitably it will have to be used if you're tinkering with a desktop prrogram, at the very least for installation. The Steam Deck is a PC, and when tinkering I don't think you can really get away from Desktop Mode. You'll still need to inspect prefixes or potentially juggle/rename/remove them manually when using custom compatibility tools, and you need to do most of that from Desktop Mode. Not to mention backing them up in case prefix upgrades fail (primarily an issue between major Wine rebases, but it can happen anytime).

I think Desktop Mode is essential to the Steam Deck tinkering experience, and trying to get away from it is probably not going to happen when using Desktop Linux software. Game Mode is good for games, Desktop Mode is good for desktop software. That's just my two cents :-)

[ttang4299]

I think the goal of entirely negating the use of Desktop Mode is a bit futile, as inevitably it will have to be used if you're tinkering with a desktop prrogram, at the very least for installation. The Steam Deck is a PC, and when tinkering I don't think you can really get away from Desktop Mode. You'll still need to inspect prefixes or potentially juggle/rename/remove them manually when using custom compatibility tools, and you need to do most of that from Desktop Mode.

The point is to at least try and minimize the use of Desktop Mode so there's as little friction as possible. I just found the Wine Cellar Decky plugin as well and it seems to be able to pull this off relatively well.

[sonic2kk]

This plugin, I believe, performs some kind of unorthodox "global" GE-Proton version. I don't know all the details, I dislike the Steam Deck plugin ecosystem and so have never used it, I can only go by what I see online.

But do not confuse a Steam Client plugin made specifically for SteamOS, with a primarily Linux Desktop Qt application. They are built separately, and ProtonUp-Qt does not have any influence over the Steam Client.

I think minimizing the use of Desktop Mode for software designed for desktops is a tall order. Especially when using compatibility tools, which while ProtonUp-Qt makes it easy, doesn't necessarily mean it should be done without context. A user should understand what they're doing before they install one.

The reason ProtonUp-Qt runs on SteamOS at all is because it runs a fixed snapshot of Desktop Arch Linux.

[ttang4299]

But do not confuse a Steam Client plugin made specifically for SteamOS, with a primarily Linux Desktop Qt application. They are built separately, and ProtonUp-Qt does not have any influence over the Steam Client.

Of course not, but alternative Proton layers have become more prominent because of its use in the Steam Deck, and minimizing that friction could help get more folks using it and perhaps supporting the development of said layers.

[sonic2kk]

Sorry, maybe this is just me being really out of touch, but I don't see Desktop Mode being that off-putting. If it is, I really just think people ought to "get used to it" when using desktop software to tinker, though I dislike how harsh that may sound.

By all means, skip using Desktop Mode if all you're doing is playing games, but once you start installing desktop software that is made for the broader Linux community, I think it should be expected that you will need to use Desktop Mode. As an example of other desktop Linux software: Installing an emulator regularly facilitates the need to use Desktop Mode. These tools have a lot of the same "drawbacks" that ProtonUp-Qt has, such as using dialogs that cause the main window to disappear, and needing to use the touchpads to navigate the UI. But it's desktop software, so I think it's normal to expect to interact with it as such.

---

To be clear, I think UI touch-ups for smaller screens / accessibility, and improving the already in place controller support, is a great idea. These benefit more than just Steam Deck users. But I don't think minimizing Desktop Mode use specifically should be a goal. It may be an outcome, but it isn't something ProtonUp-Qt (or any other Desktop Linux software) should necessarily be aiming for.

I don't want Linux software including ProtonUp-Qt to fall into a "Made for Steam Deck" category, it should be "Made for Linux".

[ttang4299]

@sonic2kk The whole idea of this feature request is to make ProtonUp-Qt easier to use. If people want to keep using it in Desktop Mode, it's still there. But adding a controller interface will only help expand its reach, not reduce it. Seems like an absolute win to me. And I don't think trying to convince folks to stick with Desktop Mode is a productive conversation to help achieve that goal.

[sonic2kk]

People may be able to stop using Desktop Mode as a result of these changes and that's fine, but I don't think that is or should be the goal here. General improvements to scaling / perhaps GameScope sessions (since ProtonUp-Qt can be launched in a nested GameScope session on the Linux Desktop to work around some edge-case Wayland issues), and improving controller support, is the goal. it isn't about "convincing" people to stick with Desktop Mode, the fact is that they will inevitably have to, that comes with the territory of tinkering. ProtonUp-Qt isn't responsible for eliminating that.

Also, just to be clear, ProtonUp-Qt does already have some controller support, however the Steam Deck's HID isn't wrapped with Steam Input when running outside of Steam. Improving the controller support is probably possible but I'm not sure if there's a way for ProtonUp-Qt to pick it up when not launched from Steam. On the Linux Desktop, controller support is picked up when an external controller is connected as this is handled by the system as a controller (the Steam Deck controls function as a keyboard/mouse pair just like the Steam Controller afaik, and is detected and wrapped by Steam Input when a program requesting controller support launches it).

I think going too deep into removing the "need" for Desktop Mode should not be a direct concern of these improvements, though. In other words while we should I agree aim to make ProtonUp-Qt easier to use in some aspects, it would be very difficult and imo counter-productive to try and eliminate the use of Desktop Mode when ProtonUp-Qt is desktop software. If one of the outcomes is that some people don't have to use Desktop Mode on SteamOS, that's fine, but that shouldn't be the all-encompassing goal imo because I don't think that will lead anywhere.

[ttang4299]

@sonic2kk We seem to be going back and forth rehashing the same points. I feel like the dev as well as the rest of the community can decide how to move forward. Other users here have already requested a controller interface. You can repeat the same points about sticking to Desktop Mode, but ultimately every user is going to decide for themselves.

[sonic2kk]

I'm not arguing against a controller interface though, and as I pointed out already, ProtonUp-Qt already supports controllers, it just seems like the Steam Deck ones may not be wrapped properly (yet?). External controllers may work already though, I'm not sure if/how Steam wraps external controllers in Desktop Mode. As well, there may also be improvement for the controller support. I am fully behind this.

What I'm arguing is, while yes these changes are good, it cannot be the goal to remove Desktop Mode usage for desktop Linux software on the Steam Deck. I think setting the goal as improving the experience with things like GameScope (which will bleed into Steam Deck Game Mode) and controller support on the whole (which will bleed into SteamOS usage as well) is much more reasonable, because trying to eliminate the need for Desktop Mode usage with a program that allows you to tinker, and when that program was made with a desktop GUI toolkit, and made and used by Linux Desktops, it is a lofty goal to remove the need for Desktop Mode altogether. Installing custom compatibility tools is heavily a desktop-orientated action.

As someone who is passionate about ProtonUp-Qt and the Linux Desktop in general, I am sharing my views just as the rest of the community have. But we can leave this discussion if we aren't getting anywhere and if I'm not getting my points across properly.

[DavidoTek]

I think we should not have to choose between either of the "ecosystems". ProtonUp-Qt must fully support both, the Linux Desktop, as well as the Steam Deck.

At the moment, the desktop mode is required to some degree for ProtonUp-Qt to function properly. As in providing a way to restart the Steam client and getting everything out of the "desktop look-and-feel" of ProtonUp-Qt.

I fully support improving the experience for the Steam Deck. That includes improving the navigation handling and scaling of the interface. But, if possible, it should also integrate into the Deck ecosystem.

As it seems to me, there currently is no "official" way to do this and I agree to sonic2kk that forcing a reboot or killing the Steam client isn't the best option.

The game list dialog will currently show a warning when the Steam client is detected. We could extend this to the main or install dialog.

Ideally, what happens is that Valve would give us an official way to add new compatibility tools while running the Steam client (either by adding some sort of reload-API or by detecting new compatibility tools when opening the settings)

---

So what we can do now is following as described in https://github.com/DavidoTek/ProtonUp-Qt/issues/55#issuecomment-1806946616:

• Improve the gamepad control
• Improve the look and feel (larger ui, Steam-like theme, maybe "floating dialogs")

We can then see if we find any better way to integrate ProtonUp-Qt with the Steam client, so it does not need to be restarted when adding new compatibility tools or changing the game mapping. Maybe someone knows anybody at or can bump @ValveSoftware ? :smile:

[sonic2kk]

I think we should not have to choose between either of the "ecosystems". ProtonUp-Qt must fully support both, the Linux Desktop, as well as the Steam Deck. [...] I fully support improving the experience for the Steam Deck. That includes improving the navigation handling and scaling of the interface. But, if possible, it should also integrate into the Deck ecosystem.

Maybe I'm just in the minority and will have to respectfully disagree based on the discussion today. I support feature improvements that can bleed over into SteamOS, which includes many of the improvements here, but am very cautious of software catering too heavily towards Steam Deck users specifically. Ideally, software would function as closely as possible on both, and users should expect as much. Though, my negative experience trying to balance and accommodate Steam Deck with my own projects has somewhat influenced this I think.

I agree with the improvements that are improving the look and feel (as this can help accessibility, regular GameScope usage, etc) and the controller support (broadly useful). I suppose what I'm trying to push back on is the part about the Deck ecosystem. But, if that's not desired, I'll leave it there. I have made my case and if it's not the desired approach, I'll have to live with that.

And, to be clear to you and @ttang4299 (as I fear reading back that the discussion may have escalated slightly), I mean no disrespect towards either of you, how you use the software, or ProtonUp-Qt. I don't and don't want to dictate how the project moves forward, though I wanted to give my input (I have been sticking my nose into the code for over a year now, and would say I'm pretty passionate about ProtonUp-Qt overall).

The game list dialog will currently show a warning when the Steam client is detected. We could extend this to the main or install dialog.

I think the question is the best way to do this. A pop-up dialogue may be a good idea though maybe a bit intrusive. If possible, a "don't show this again" checkbox would be good. Personally I would find such a dialogue each time I install a Proton version (particularly during testing) to be a bit on the intrusive side. I can definitely understand that it isn't just as simple as having this checkbox though, we'd likely have to introduce another preference somewhere, which isn't a terrible thing I don't think, it's just something to consider from an implementation perspective.

Adding it to the description of (all?) ctmods may work but it could still be missed, whereas a dialog is harder to miss :wink: I think as well noting on the Readme and the description on the About screen is also a good idea, that way if a user does disable the dialog, there are more opportunities to remember this. Maybe a combination of all of these would be the solution or at least a part of it.

Plus, adding another dialog, in the context of discussing Steam Deck improvements, may not be the way to go. But I also don't see a good alternative that has as much visibility. As you said earlier, GameScope limitations are outside of ProtonUp-Qt's control.

Ideally, what happens is that Valve would give us an official way to add new compatibility tools while running the Steam client (either by adding some sort of reload-API or by detecting new compatibility tools when opening the settings)

I agree, this would benefit many other projects as well. But this may be a general Steam Client limitation to do with how it picks up these changes. For example, Non-Steam Games usually aren't picked up until a client restart, but somehow Valve get around this with the "Add to Steam" option for .desktop entries on SteamOS. Other projects such as Lutris, Heroic Games Launcher, SteamTinkerLaunch, and Steam-ROM-Manager, all have to restart Steam for this. So maybe there is some API for an adjacently-related feature which means it may not be entirely unreasonable for Valve to implement an API like this.

So what we can do now is following as described in https://github.com/DavidoTek/ProtonUp-Qt/issues/55#issuecomment-1806946616:

For the Steam theme, I wonder how feasible/how much of a good idea it would be to have this as an option with the other Light/Dark/System themes dropdown, but to just select it by default if we detect SteamOS? That way it could be used on desktop as well, as a general "Steam" theme. Maybe it could be named "Mist" (Valve already took "Vapor" for the Steam Deck's KDE theme) :wink:

From my limited understanding of how the themeing works, I could see how this may be possible. It would just be another dropdown value we read and use it to set a custom theme. However, I could also see complications, if the theme name is simply passed to the Qt theme engine and resolved that way, we may have to "intercept" our custom theme value and divert to loading a custom theme string.

I don't know too much about how theming works internally in ProtonUp-Qt and even with Qt in general, so I could be talking nonsense :-)

[DavidoTek]

I think the question is the best way to do this. A pop-up dialogue may be a good idea though maybe a bit intrusive. If possible, a "don't show this again" checkbox would be good. Personally I would find such a dialogue each time I install a Proton version (particularly during testing) to be a bit on the intrusive side

Sounds like an idea.

Plus, adding another dialog, in the context of discussing Steam Deck improvements, may not be the way to go

Yeah...

So maybe there is some API for an adjacently-related feature which means it may not be entirely unreasonable for Valve to implement an API like this.

That's possible, maybe we find something in some other project, though I think ProtonUp-Qt is the largest project regarding compatibility tools...

For the Steam theme, I wonder how feasible/how much of a good idea it would be to have this as an option with the other Light/Dark/System themes dropdown, but to just select it by default if we detect SteamOS?

That's what I was thinking too

For the Steam-like ProtonUp-Qt Theme, see https://github.com/DavidoTek/ProtonUp-Qt/discussions/309

[DavidoTek]

This is because Steam needs restarted to pick up new compatibility tools, and switching desktop sessions accomplishes this

Not specifically related to this issue, but a method for updating the selected compatibility tool while running in Steam is described in this comment: https://github.com/luxtorpeda-dev/luxtorpeda/issues/236#issuecomment-1712289596

Apparently, one can change the compatibility tool by running steam "steam://open/console/ +app_change_compat_tool 32310 luxtorpeda \"\" 250" (where 32310 seems to be the app id). (I tested it with Steam Flatpak. It did open the Steam window and a new "CONSOLE" tab appeared, but it didn't set the compatibility tool for some reason. Luxtorpeda is installed and displayed in Steam. Also tested it with a captial "L". It only disabled "Force the use of a specific Steam Play compatibility tool".)

[sonic2kk]

Interesting side note: Valve appear to be using this project on SteamOS to give gamepad support to UI applications. It isn't on globally, only for a handful of applications in Proton Experimental, but the project appears to support X11 on Linux: https://github.com/madewokherd/xalia

This is not to say we should strip out controller support or anything of that nature, I just wanted to bring up that Valve are making pushes for better controller support for UI applications, so the situation may improve on SteamOS if this becomes a go-forward approach for Valve.

It has a few caveats, even if it worked perfectly right now:

• It doesn't support Wayland.
• It needs some manual configuration by the user (it couldn't be used by default outside of Steam Deck Game Mode even if it were a full solution for our use case)

But in future on Steam Deck at the very least this may help with the user experience.