Feature Request: Let Steam client windows be managed by the window manager
Totally agree. This is okay to do as steam does on windows, but on linux it's simply not applicable. The steam client actually tries to manage itself, which is not his job. Every window manager are different and every users/preferences are different.
Linux users don't like when an application behaves differently. Sometime users set specific rules/behaviour to window and the current steam client break almost all user preferences
Glad to see the original creator of the xlib workaround post here! :)
I've reported the effects of this in awesomeWM here #807
So if this one is fixed my bug report can be closed as well.
Thank you again @dscharrer for the fixes!
Definitely seems to be a good idea. Current behavior is very buggy.
Yes 100% ACK, please let the WM deal with it.
+1
+1
I agree with this request.
It annoys me that Steam steals focus. I'd like to let the WM decide and windows should just tell that they need attention.
And I'm missing always on top with chat windows, my WM has the feature but I can't use it with Steam.
it should at least let the window manager managing focus
This could help a lot with the weird problems of the "close window" cross misbehaviour. Please implement this. Having window decorations that don't mesh with the rest of the system is very irritating.
@DavidGriffith What do you mean by "the 'close window' cross misbehaviour"?
They explained -why- they did what they did; there's a lack of reliable tray icon. No tray icon means minimizing to tray (standard X-button action) breaks usability.
Lets not muddle this issue. This issue is not about the tray icon/minimizing thing. Its about using the WM to manage steam windows (like other applications) instead of steam managing itself. Let steam use the power of the WM.
@MrSchism But with the last (or the other) update from repositories, the tray icon is working in KDE and others enviroments (i don't know if in all) and like close to tray https://github.com/ValveSoftware/steam-for-linux/issues/1025 have other problems like new chats open window https://github.com/ValveSoftware/steam-for-linux/issues/266
Talking about the close to tray, there is a workaround in https://github.com/ValveSoftware/steam-for-linux/issues/1025 what works for me, but how they explained in https://github.com/ValveSoftware/steam-for-linux/issues/1720, it isn't a Steam bug, it's outside Steam, and it's concerner with the enviroment.
Although having Steam working in the WM would fix many of those problems, the cost of working for three plataforms together could be very high against the possibility to implement a full use of every desktop enviroment. They probably do (and i think they are doing it now) a global implementation what, in theory, have to work in all systems and enviroments, and if not, do only little tweaks in the Steam client or demand some tweaks to the enviroment itself.
Would love to have this. The WM just knows more than Steam, so Steam should leave the decisions to it.
+1
Close window and Minimize window both are doing nothing in XMonad.
I want to hide frame to tray icon.
Yes please! I would greatly appreciate this as steam is nearly unusable in Common Desktop Environment, UNIX Window Manager, and DWM without it.
+1
I can force KWin to use native window borders and use a skin without decoration but that way all windows move down by the size of the window border each restart. Please let the window manager do it's job: managing windows.
+1
On both awesome and i3, Steam windows fight with the WM to size themselves, and Steam loses. They should set the floating state properly. Bonus points if you set window groups for greater scriptability.
Steam currently insists on positioning it's own windows, while for X11 that task should be left to the WM - it knows more than you about the user's preferences and other windows and will likely be able to place them more intelligently.
Maybe yours does. I can't for the life of me get KDE to remember that Firefox snaps to the right side of the screen and Thunderbird snaps to the left. In the nine months I've been using it, it has never not tried to do the exact opposite. Meanwhile, Steam's Friends window stays where I put it, in the bottom left corner.
I also support the idea of letting the window manager deal with Steam. There are certain functions that are useful in KDE for example that I use on a daily basis but cannot use with Steam as it is managing its own window. The ability to tab applications together and send them to different desktops is quite a useful feature. An added benefit of letting the window manager deal with Steam is the close to tray icon feature will work as expected in environments that support a tray icon.
Issue #1879 was closed, but I don't see WM_CLASS mentioned in this bug. Having different instances for different windows would have been very useful to manage rules for steam windows in tiling window managers. Other than that I agree. I've just started using awesome and I have to deal with floating mode for steam although it would have worked much better if at least different instances in WM_CLASS were provided.
+1 to this: I haven't yet encountered a WM compatible with steam's close button (I don't doubt that Unity and such might be compatible but it'll be a cold day in hell before you catch me using that), and my current WM of choice (i3, unfortunately :wink: ) is incompatible with Steam's move and resize functionality as well as all of the title bar buttons. It also seems that using the WM's close window functionality can actually kill the steam process, which is definitely the wrong behaviour.
Combined with bug #53 , which should not be closed as it is unresolved, this means I am faced with a dilemma when I don't want to see steam's main window:
- Click Steam's close button: Nothing happens whatsoever
- Close Steam's main window: The entire application dies
Also, steam does a whole lot of focus stealing. Considering I start this up when I log in, it's very frustrating to be typing in keyring passwords only to find that steam's popup notifications (which should be using libnotify!) have stolen my keystrokes halfway through. If I recall correctly it also does this when it opens up a new chat window (or any window for that matter), so it could really happen at any time.
@ScoreUnder all "New" windows from Steam steals focus in Awesome for me (tiling/hybrid WM).
However, sometimes when closing a friend chat with the X or Alt-F4-esque Steam itself will be killed.
This also affects my small issue:
+1
+1
+1
Is there a chance we get similar functionality on Windows? This is by no means a problem exclusive to Linux.
This is true. I've often had all of Steam's windows come into focus when an event notification spawns. Not every time or even most of the time; just often.
+1
@marcinkurek Especially because KDE is working on KDE for Windows.
Yes please (atleast on Windows). Steam looks horrid with bbLean.
I would also like it very much if Steam used normal window borders so that I could manipulate the window normally and have all the buttons at their correct place with their correct look.
steamwm seems to be a good stopgap solution though. It's worked
perfectly for me on CDE.
+1
this + native notifications and it would be awesome client. Don't be different because you can.....
+1 get on this
2 and a bit year later this is still not fixed, and still not acceptable (won't ever be).
+1 from me!
+1 and me!
had a unclosable windows again today, cause steam wont let my wm focus the windows (notification send window).
pls Valve let the windowmanager do its job.
+1
How about some sort of comment from Valve?
I have a feeling they do not care about this at all. This behaviour completely breaks Steam in several window managers, and it just looks ugly compared to the rest of the user's themes.
+1, if I wanted a shitty MS Windows interface with no modern window management, I'd use Windows
Putting in my vote, Steam behaves terrible under something like WindowMaker.
+1
This should be the default way Steam behaves on every OS.
I don't get why some developers waste extra time and effort to make their apps non-compliant with established practices.
@battlesnake
#Brandthing just look how antivirus companies have their own window decoration and special behaviour just to stand out.
@CommanderAlchemy : I wasn't aware that Clam or AppArmor had any special decoration :D
@CommanderAlchemy
There are a few sane antiviruses that don't follow this ugly trend, such as Avira and ESET.
Have been 2 years that community as Steam to stop using Linux as Windows and do it in the right way... Steam's client is almost incompatible with half Linux's WM just 'cause refuses to use the libraries already identified.
+1 on this feature.
The design of the windowing toolkit we use in the desktop client for Steam makes this feature request very expensive to implement correctly. At this time we have no plans to make that change.
The question is why this was not done in the first place. Any Linux developer should know these kind of things should be left to the window manager. I think the need for this is pretty important, and should be high on the priority list.
There's rather huge bugs and slowdowns even on popular distros and WMs. And this is the root cause.
It's baffling to me that this wasn't done correctly in the first place.
@alfred-valve Thank you for your honesty. Perhaps this could be revisited when most major distros has made the jump from X11 to Wayland? It seems like it might happen sooner rather than later so it might be a waste to rewrite the X11 backend.
@alfred-valve : Thanks for the info. Out of curiosity, why did Valve try to create their own window management when originally designing the Linux client?
@battlesnake , we didn't, we made our own UI toolkit when making Half-Life 1 and used it for Steam. Now we are about 15 years on from that decision...
That makes more sense, thanks!
This would be very nice, indeed.
@alfred-valve, how much trouble would it be to alter the toolkit such that it leaves window handling to the window manager?
See, coding a brand-new UI engine is something that probably should have been done back when the client was redesigned from scratch for the 2010 Mac rollout, given how much had to be changed anyway. Or when you built Big Picture Mode. Or when you built your own in-house Linux distro. Or right now, while you're working on a brand-new game engine and contributing to a complete overhaul of OpenGL in the process.
It's not that using nonstandard window designs is a bad thing, as such. I've used plenty of Windows apps that have their own custom skins — because there are a lot out there — and I don't recall any of them ever having issues with stealing focus. I presume what it's doing now is the equivalent of running a fullscreen game in a borderless window? There must be a better way.
+1
+1
GTK intergration would be nice
On 14 Jan 2016 01:07, "Luca Weiss" [email protected] wrote:
+1
—
Reply to this email directly or view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-171272182
.
+1
Are there any updates to this feature/bug?
I have to ask the same. Any updates on this?
Also, instead of +1, give the OP a thumbs up instead.
This github issue has been around since long before github had a thumbs up feature.
@ScoreUnder, irrelevant.
Quite relevant, as most of the +1 comments were made when there was no alternative. You can't scold someone for not using a feature which didn't exist at the time.
On the other hand, we could not have a semantics debate that gets emailed to 50 people.
Does it? There is an unsubscribe button on the right if you don't want to be emailed about this issue.
It's not as if Valve will ever comment on it anyway.
(Also, there is an irony in emailing everyone to say "stop emailing people")
It's not very hard to read the thread and see that Valve already commented: https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-150274129
That's what I mean - their comment makes me think it's unlikely that they'll come back to this issue in the future.
Please don't fight here :)
I really wish they'll revisit this. Steam is particularly bad with tiling managers.
Bumping this thread. If anyone's running DWM and wants to have steam popups be floating, here's a set of rules for your rules section. Chats don't work (I can't seem to match part of the window name), and I doubt the deals window will work for the same reason.
UPDATE: chats still don't work, but the deals window does. I've added what works from @z3ntu's i3 config. Will update on chats again soon.
UPDATE: I got chats working through a pretty roundabout method: all steam windows are set as floating, then windows with the title Steam are set as titled. This sets everything but the main steam window as floating. It ain't pretty, but it works.
{ "Steam", NULL, "Friends", 0, True, -1 },
{ "Steam", NULL, "Music Player",0, True, -1 },
{ "Steam", NULL, "Add a Game",0, True, -1 },
{ "Steam", NULL, "Steam - System Information",0,True, -1 },
{ "Steam", NULL, "Steam Guard - Computer Authorization Required", 0, True, -1 },
{ "Steam", NULL, "Steam - News", 0, True, -1 },
{ "Steam", NULL, " - event started", 0, True, -1 },
{ "Steam", NULL, "CD key", 0, True, -1 },
{ "Steam", NULL, "Screenshot Uploader", 0, True, -1 },
For anyone running i3: https://github.com/z3ntu/dotfiles/blob/master/i3/.config/i3/config#L55
@hexadecatrienoic maybe you can find some useful things in there too.
HOW IS THIS STILL NOT CHANGED? I am using Common Desktop Environment, and the damn thing does not want to either move without pressing Meta, or resize at all! Sure, CDE's a Hobbyist's system, but what about MWM? what about FVWM, TWM (Which already makes its own title bar), VTWM (same), and all of the other window managers to which steam is completely alien in? FIX, PLEASE.
@roryyamm it's 15 year old code, most likely noone at Valve wants to touch this
On December 30, 2016 5:33:35 PM PST, Marcin Kurek [email protected] wrote:
@roryyamm it's 15 year old code, most likely noone at Valve wants to
touch this
If Steam behaved properly, it wouldn;t matter what WM is being used -- CDE, TWM, MWM, OpenLook, etc.
David Griffith
[email protected]
The window manager only handles the titlebar and window borders, not the
contents of the window.
On Mar 13, 2017 08:43, "IFo Hancroft" [email protected] wrote:
I may be mixing terms in here but if Steam is managed by the Window
manager how would Steam still be looking the way it is, separate from the
desktop theme currently in use?—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-286147216,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADj0N4FGGRc2EPO9BjRU-YejUsfjH1_Uks5rlWQPgaJpZM4AZKGN
.
That's still more than nothing, though. Even the MacOS version has a custom black titlebar, albeit a MacOS-themed one if I recall (though I haven't seen it since the redesign that squared off the corners on everything and added more blue, so who knows what's up lately). Stuffing every window inside a potentially-light-gray frame is probably a bigger sacrifice than Valve is willing to make.
But on Linux, some window managers, especially tiling ones, treat steam
oddly and sometimes very badly because it tries to force its own window
borders. If they're going to have a Linux version, they need to allow the
window manager to handle it properly.
On Mar 14, 2017 22:53, "stevethepocket" [email protected] wrote:
That's still more than nothing, though. Even the MacOS version has a
custom black titlebar, albeit a MacOS-themed one if I recall (though I
haven't seen it since the redesign that squared off the corners on
everything and added more blue, so who knows what's up lately). Stuffing
every window inside a potentially-light-gray frame is probably a bigger
sacrifice than Valve is willing to make.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-286647868,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADj0NxtkXx79hJveztSB1jQ3OU85PGb5ks5rl3zEgaJpZM4AZKGN
.
If there's no way to do that and still be allowed to determine their own visual design, then that's an issue with the window managers, not Valve. If Apple, of all companies—which is very picky about third party software following its UI guidelines—offers more freedom than Linux window managers in that department, then I believe we have a problem.
In order for a tiling window manager to work the way the user wants it to,
they have to be able to control the windows. The user should have the final
say in this, NOT Valve. The user has chosen to use a tiling window manager
and IMO it's insane to expect a program to violate the cohesive design of
the desktop by introducing its own window borders, that will always clash
with most desktop themes and styles.
It most certainly is a problem with Steam!
On Mar 14, 2017 23:10, "stevethepocket" [email protected] wrote:
If there's no way to do that and still be allowed to determine their own
visual design, then that's an issue with the window managers, not Valve. If
Apple, of all companies—which is very picky about third party software
following its UI guidelines—offers more freedom than Linux window managers
in that department, then I believe we have a problem.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-286650151,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADj0NzGlo-stVnBOh7a0BkK1qVR0UD4Wks5rl4DKgaJpZM4AZKGN
.
This wouldn't bug me if steam just decorated itself weird, but under windowmaker, you can't move/resize steam, which really sucks.
It's barely acceptable in i3 on my 1080p Desktop, but it's pretty much unusable in bspwm on my Laptop, because neither accepts the other's resize commands properly, so when bspwm forcefully resizes steam, buttons and textboxes are occluded... if I give steam free reign, it simply draws its windows outside of the screen...
Steam is not kind to 1366x768 displays on Linux.
4 years later... still the same. Step up your game, Valve.
Thanks for the excellent workaround, dscharrer, works great ! :)
The new client Beta should improve window manager interactions when re-sizing:
http://steamcommunity.com/groups/SteamClientBeta#announcements/detail/1655505073049286411
The beta fixes the resize problem for me. Good work @Plagman!
New problem: Remember how it used to use the default X11 resize pointers instead of the window manager's? Now it uses none at all. When I mouse over an edge or corner, the pointer remains the standard big white arrow. Only when I hold down the mouse to drag it does it does it change (albeit into the correct Plasma resize pointer).
Using Kubuntu 17.10, Plasma 5.whatever.
Hello @stevethepocket, you'll want to add your experience to #1831.
This is needed in the client. I hate it when steam screws up my i3wm setup.
I doubt that Valve really cares about us though...
Shame for valve, 2018 and still no adressing this. Not even a x64 client or native windows management, it's SO hugly seeing steam bar being diferent from the rest of the operating system. This company simply does not evolve, it's the same for almost 1 decade (same issue in windows, the bar is simply diferent from the rest of the system).
Look in the thread for a workaround for linux, I am using it, it works well.
For evolution, you'll notice the steam client is often updated, so they
evolve, it's just not that obvious !
2018-07-27 18:00 GMT+02:00 blastkrieg [email protected]:
Shame for valve, 2018 and still no adressing this. Not even a x64 client
or native windows management, it's SO hugly seeing steam bar being diferent
from the rest of the operating system. This company simply does not evolve,
it's the same for almost 1 decade (same issue in windows, the bar is simply
diferent from the rest of the system).—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-408463253,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACu5D2_-WJmiRv3YXa3Y_n-Sxn2rftQEks5uKzkhgaJpZM4AZKGN
.
I have generally been tolerant of this aspect of the Steam client, but whenever i have to mess around with the big picture mode to do something which would take me less than 1 second with KDE Plasma for more than 5 minutes whilst my friends are waiting holding Steam controllers, i am upset.
I have had some issue with big picture mode resizing oddly and since it doesnt take any input from the window manager (other than minimize and restore), i have had to fiddle around with screen resolution and reboot and restart Steam and so forth. Maybe ill figure out something more next time it happens. Might be because my laptop resolution is lower than the TV im trying to use with it.
Sorry for an unprofessional rant.
+1 from me here. It is a bit ridiculous that this is still an issue. I'd like to know, is GNOME a supported desktop environment? If so, then this is still an issue! Because Steam does not respect my window management preferences in any way, shape or form. This causes issues beyond just aesthetics as well, as is mentioned plenty of times in many comments and separate reports! This isn't just a feature request, it's an actual fix to a broken piece of software... It would be really appreciated if this got some attention by now.
I can't believe this is still a problem. I can't use Steam in WindowMaker to this day.
@i-need-to-tell-you-something when a company does something as unprofessional as let a bug like this linger for so long despite repeated calls to fix it, a rant like yours hardly counts as being unprofessional. It's well-justified exasperation.
I can confirm that this infuriating behaviour also affects WindowMaker. Valve / Steam really should fix this. It's really annoying. All they have to do, is stop doing there own thing and let the window manager handle it. That's what its there for!
Couldn't agree more with this request. On BSPWM I find that it's hugely problematic. When steam wants to pop up a new window it ends up floating off the screen, and I lose all mouse control on that desktop because of the awful interaction between my tiling WM and steam
This needs to happen.
When you open a video in Steam (not trailers), the video player have the window manager titlebar, but the Steam client does not.
I looks so unpolished.
Do we have an official answer about what's Valve's stance on this? I'm asking because I see it has the Reviewed tag.
Please do this.
There is ample room next to the Store/Library/Community/Profile tabs for the notification, wallet, profile, and BPM widgets, the menu bar is just a menu bar, and the minimise, maximise and close buttons are just awful. They look out of place on every Operating System.
Let the window manager manage the windows.
I understand that an organisation may want to control the entirety of how their assets are displayed, in order to create a strong brand identity. And using your own window decorations does send a strong message about the Steam brand: it says, "Valve is all that matters."
Does Steam work to ensure that it is available and functional to all its users? No, Valve is all that matters.
Does Steam follow standards and play nicely with others? No, Valve is all that matters.
Does Steam respect its users and their choices? No, Valve is all that matters.
Does Steam allow enhancements, or additional functionality? No, Valve is all that matters.
Valve's actions with Steam lead me to believe that they do care about the user experience, and do care about enhancing the gaming experience for everyone. So as an act of corporate branding, it completely fails in what it is trying to do; it creates a completely destructive impression of Valve's corporate identity.
It also doesn't look very good.
Why is there so much resistance from Valve to do anything in the direction of fixing this problem or even admitting there is a problem?
It is sad to see this issue not fixed for this many years.
Steam works horribly bad with my window manager. There's no UI application on my PC that works worse than Steam does.
Under KDE 5.47.0 / Plasma 5.12.9 / Kubuntu 18.04 with Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2) I don't have these problem any more. Steam seems to be completely under my window manager's control even when in BPM (Big Picture mode). I don't even have to exit fullscreen mode for that control.
In BPM I have the option "Start Big Picture mode Windowed" toggled off.
Other Interface settings in regular client:
[ X ] Enlarge text and icons based on monitor size (requires restart)
[ ] Run Steam when my computer starts
[ ] Start Steam in Big Picture Mode
[ ] Display Steam URL address bar when available
[ X ] Enable GPU accelerated rendering in web views (requires restart)
[ X ] Enable smooth scrolling in web views (requires restart)
So my original related complaint seems resolved. Not sure if all window managers work alright. And I understand some people have aesthetic grievances about things that I personally don't mind that much. An option to remove the built-in titlebar would be welcome I guess (so that I can add Kwin decorations via config).
I'm an engineer at System76, working on a tiling window management extension for GNOME in Pop!_OS. It would be great if Steam's dialog windows could declare that they are dialogs so that the window manager doesn't try to tile them. Tiling window managers determine if windows should be tiled or not based on the WM_WINDOW_TYPE and WM_TRANSIENT_FOR values.
Use XSetTransientForHint to set the parent of the dialog windows to Steam's root window.
You can use XChangeProperty to define the window type of a X11 window.
Atom type = XInternAtom(display, "_NET_WM_WINDOW_TYPE", False);
Atom value = XInternAtom(display, "_NET_WM_WINDOW_TYPE_DIALOG", False);
XChangeProperty(display, handle, type, XA_ATOM, 32, PropModeReplace, reinterpret_cast<unsigned char *>(&value), 1);
Workaround for now is to blacklist Steam altogether from tiling, since there's no way to differentiate between the root window and its dialogs.
+1, an annoying issue that would do a world of good for many to be resolved.
So, its 7 years now.
would be nice to get support for that so i can control steam windows with wmctrl. Currently it reports those windows as N/A
0x06600021 3 N/A N/A
0x06600083 -1 N/A N/A
0x06e06209 3 archlinux xpander@archlinux:/home/xpander
the last one is my terminal which reports itself correctly
+1
Steam client size is too big for proper tiling. This is the second issue alongside Follow XDG Base Directory Specification (#1890) that is affecting me and both are about Steam not following specifications and both are not addressed in years...
+1
Steam client size is too big for proper tiling. This is the second issue alongside Follow XDG Base Directory Specification (#1890) that is affecting me and both are about Steam not following specifications and both are not addressed in years...
I would fucking love it if Steam started supporting the XDG Basedir Spec
Please Valve, stop Steam from stealing window focus. It's so, so annoying.
This really needs to be fixed by the time the Steam Deck and SteamOS 3.0 comes out or it will leave a very bad impression for new Linux users when they discover Kwin isn't properly managing Steam app windows.
When?
Soon i hope
We'll see
This is the longest, angriest +1 thread I have seen on Github. More than half of the comments are actively distracting from any useful input. It feels sad to witness such a train of frustration and I fear for the well-being of any developers who might consider tackling this. Truly the only option left is to avoid communicating. :cry:
EDIT: I now realize it was not obvious in the least (outside my head) that I completely accept the validity of the shared frustration with this lacking in Steam. I just question the constructiveness of pouring it out (at others) in an issue thread.
omg such a important feature and so much ignorance..
This is the longest, angriest +1 thread I have seen on Github. More than half of the comments are actively distracting from any useful input. It feels sad to witness such a train of frustration and I fear for the well-being of any developers who might consider tackling this. Truly the only option left is to avoid communicating. cry
EDIT: I now realize it was not obvious in the least (outside my head) that I completely accept the validity of the shared frustration with this lacking in Steam. I just question the constructiveness of pouring it out (at others) in an issue thread.
What is the alternative? I'm sure most people would just feel this is their last resort.
What is the alternative? I'm sure most people would just feel this is their last resort.
I switch WMs while running Steam.
Steam in Window Maker can't be moved or resized at all, though minimizing and maximizing using Steam's own buttons works just fine. You pretty much just have to deal with wherever Steam puts itself and at what size (or switch WMs/DEs, of course).
Thought it was worth a mention considering I don't think I've seen a description of the problem as it relates to Window Maker — just two other people saying that this is still an issue without explaining how specifically this causes issues in Window Maker.
@ngoomie mentioned it Sept 2, 2018 for windowmaker, but it's not been fixed yet. lol. Give it another 20 years, someone might get around to it.
Steam in Window Maker can't be moved or resized at all, though minimizing and maximizing using Steam's own buttons works just fine.
Huh, IME with WM the initial splash window gets into the WM-fighting-steam bug that causes it to constantly reposition itself on the screen and I can never get so far as the behavior you see. Maybe different WM settings?
+1 Steam client size is too big for proper tiling.
This is the second issue alongside Follow XDG Base Directory Specification ( [#1890](https://github.com/ValveSoftware/steam-for-linux/issues/1890) ) that is affecting me and both are about Steam not following specifications and both are not addressed in years...
Perhaps it would be more apt to say that these should be named as bug reports in the title, atleast for this case? (Instead of the current "Feature Request:" names)
Re: @dscharrer & @brl1214
How, after this many years, is this still an issue?
this
I - stands for ignorance
I'm sure there's a /dev/null somewhere where these emails are going.
From: Yuriy Kuzin @.>
Sent: 02 February 2023 07:57
To: ValveSoftware/steam-for-linux @.>
Cc: Martyn Braithwaite @.>; Comment @.>
Subject: Re: [ValveSoftware/steam-for-linux] Feature Request: Let Steam client windows be managed by the window manager (#1040)
this
I - stands for ignorance
—
Reply to this email directly, view it on GitHubhttps://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FValveSoftware%2Fsteam-for-linux%2Fissues%2F1040%23issuecomment-1413295052&data=05|01||418113d1f1064beec15408db04f33097|f3b5c498716b4b69a14b78bbe5dd6155|0|0|638109214754416364|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=KAL0hJoIjw362mS1aHz1nMr5oaiWRedkLU1p12FleR4%3D&reserved=0, or unsubscribehttps://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FATTHPWPB3VM3FNB5YDZMV7TWVNSIDANCNFSM4ADEUGGQ&data=05|01||418113d1f1064beec15408db04f33097|f3b5c498716b4b69a14b78bbe5dd6155|0|0|638109214754416364|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=U8JssmIHDdkkvtUyTjhgMnLzuANRyx7zeOPy9sYArXg%3D&reserved=0.
You are receiving this because you commented.Message ID: @.***>
@docr0bot my experience in software development for small companies states that the development cycle goes:
- new feature or product is prioritised for developers
- developers get it to the point where it just about works, with maybe enough time for a little spit-polish
- two different new features are prioritised
- rinse and repeat
this doesn't leave much time for "low priority" tasks that aren't part of a larger feature
valve is likely different, but i can't imagine that it's too far off
realistically the small things like this feature aren't ever going to be a priority for the overall vision of a company so it's unlikely to be prioritised for the devs. this is the kind of feature that would really only end up being consistently implemented in a hobby project, but in a large company's flagship product like this one, this feature request is the digital equivalent of hopes and prayers. it's not impossible, but it's not something i would hold my breath for no matter how much noise is made about it, because those affected by the resulting accessibility issues will always be in the vanishing minority, and the time spent on this could be spent on getting 3 more games compatible with proton for example
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-1413828368
being that Valve Employees are finite in number and actually do have more important things to work on, why not do what Proton does and allow the community to waste our own time solving these types of small things ourselves? This model works very well for Proton.
There do exist members in our community who our more than willing to put time and effort into solving these issues.
if only there were some way for the community to develop our own forks of the Steam client. as is the case with Proton.
I never actually thought I'd see Valve/Steam apologists, but here we are.
Please stop replying with 0 information comments (am aware of the irony of this message), it just makes people unsubscribe from the issue.
@Rainyan I agree, however people can customize their notification settings, so they only get notified when the issue is closed, instead of being notified for every message.
@Pauan The problem with that is, there might be (hypothetically) replies with content of consequence, like from a Valve employee, and people want to see those. Better if people with nothing to add refrain from commenting.
(Like @Rainyan I am aware of the irony in what I've just typed.)
This solved the problem for me
If you need to access the menu once - alt+f3
And there you can enable the title bar manually, but it will work until you restart Steam
So, what can we do to increase the priority of this? It's already the second most commented issue.
So, what can we do to increase the priority of this? It's already the second most commented issue.
An issue that's been open for 10+ years is unlikely to ever be addressed. I switch WMs when running Steam now.
On Windows too, let the client windows all have real WIndows borders/headers and be managed by Windows itself.
@oddhack
I switch WMs when running Steam now.
How does that work exactly?
@oddhack
I switch WMs when running Steam now.
How does that work exactly?
On Linux, the window manager typically has an option to switch to another window manager. I normally use WindowMaker which suffers some of the problems described in this thread, but running with icewm works around them. Probably the best bet is to use GNOME or KDE though, since that's the default environment on many distributions and therefore most likely to get attention from Valve.
Is anyone ever going to fix this issue?
From: ryuukk @.>
Sent: 15 June 2023 19:51
To: ValveSoftware/steam-for-linux @.>
Cc: Martyn Braithwaite @.>; Comment @.>
Subject: Re: [ValveSoftware/steam-for-linux] Feature Request: Let Steam client windows be managed by the window manager (#1040)
"When in Rome, Do as the Romans Do"
Stop with that Gnome or Electron junk, and let me manage my windows
—
Reply to this email directly, view it on GitHubhttps://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-1593567335, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATTHPWM75NBYFP7T3UBE4EDXLNKUFANCNFSM4ADEUGGQ.
You are receiving this because you commented.Message ID: @.***>
Or better, let me start games using SteamCMD
If only...
Or better, let me start games using SteamCMD
If only...
Yeah, I also was searching of this. If Valve just gave us an api, we could even make our own Qt based GUI, properly made.
I used steamwm from there https://github.com/dscharrer/steamwm which worked wonderfully, until valve updated its client recently with its new look... now it's all broken again. The only way to get back the normal window controls in windowmaker is to use the "ignore decoration hints for gtk applications" in wmprefs.app but it's a global setting, so it's a nuisance for some applications...
Thanks to valve for creating something so crappy after so many years, really, it's a shame !
With new UI (steam version 1686880776), they made error dialogs to appear "inlined" in the main window, so now that problem of unmanaged windows of error dialogs disappears.
Hint: to invoke an "error" dialog, you can press "Login to another account" from the main window.
However, steam notifications are still unmanaged windows.
Hint: to invoke a steam notification, you can create another account, log in from web browser there, and write pm to your main account.
I would prefer notifications to respect system integration. I.e. notifications should use normal kde system notifier.
Also, I have created special window rules to force use titlebar and frame. This is privilege kde users have over users of another DEs until valve solves the problem of not setting titlebar.
But I would like if I could disable steam's "own" buttons for closing, minimizing and maximizing (maybe possible with steam skins?). Because now it seems closing with system close button no longer causes steam to exit. Previously, it was possible to close to tray only by steam's own close button.
Yeah finally you can do the same in windowmaker without the global setting, and without steamwm : just open the application menu in steam using the keyboard shortcut since you can't use the mouse since there is no title bar (should be control+escape, check in wmprefs otherwise). Then change the attributes to restore normal attributes, apply, in advanced configuration tick "ignore decoration changes", in concerned window just save with the default. Normally after that all steam windows will have normal decoration. As the previous post says it's too bad you get a double close button (the one from steam and the normal one) but this can't be helped as long as the window programming remains so crappy in steam, shame to valve for that.
If It try it via menu as @zelurker says, wmaker crashes. I submitted a bugreport. But IgnoreGtkHints = YES; works.
A crash ? Never saw a crash related to this application menu... maybe it's because I use the git version in arch ? Well there is not much choice, the only available package is a git version through aur... Anyway yes the ignore gtk hints works with its drawbacks, so if you can live with that it's fine, otherwise maybe try the git version then...
@ryuukk See https://github.com/Rosentti/opensteamclient/issues/24. The author says this is because he is more experienced with C#. Anybody can rewrite it with C++.
bloated and slow microsoft language
I'll take a well made app written in C# over a poorly made app in C++ any day of the week. Take a look at Git Credential Manager, the new cross platform one written in C#, maybe that will show you that you're wrong. C# can be compiled to a binary in the traditional C++ AOT way, and it's probably smaller than most Rust binaries. It does use a garbage collector, but so does Go, and I don't remember that language being called bloated or slow. Have you ever learned anything about judging a book by its cover?
@DexterHaxxor please don't go offtopic
And I can confirm such words from what I've learned not from book. I have tested lot of C# apps and they always leaking. The longest running that I've tested it was some server that needs to be restarted every one week because of leaks. Yes C# can be compiled to binary but usually you need few gigs .net libraries to make it work. oh whatever you can go with everything what you want....
Leaky programs are, in all but the rarest of cases, a result of buggy code. Implying that C# is an inherently leaky language is a huge claim to make and would at least deserve a bug report to the CLR. Or perhaps you were going the other way with that implication -- that C# programmers are unskilled in general to the point that they always leave huge memory leaks -- in which case I don't understand how you would be comfortable tasking those same programmers to a language in which they need to be even more conscious of their program's memory model.
On the topic of "bloat", we know that electron/CEF is slow, but it's not because it's JavaScript. JavaScript JIT has come a very long way in the last couple of decades. The real culprit for the unusual sluggishness and high RAM usage of electron/CEF products is the fact that they are built upon an entire web browser. It's not just the language, it's the rendering model, the DOM, the entire page being loaded and calculated on at once, the semi-automated fluid layout, the need to support everything that HTML5 can do. Sure, you don't have SIMD primitives and static dispatch and manual memory management and AOT compilation in JavaScript, but believe me the language itself isn't even in the top 10 when it comes to the performance bottlenecks holding Electron back.
C# is simply a rather unremarkable garbage-collected language. It is skinned to feel like C++ and Java, and its approach to OOP and memory management are so incredibly average that you probably guessed them correctly before you even started learning the language. Even if these features make it "slow", these are not the problem. Plenty of Linux software nowadays is written in Python, a language orders of magnitude slower than C#, and most people don't even notice. It is also worth noting that C# is one of the most popular languages in the game development industry and plenty of the games being launched by Steam will be written in it.
I understand the desire to squeeze every last drop of performance out of the CPU and GPU as a type of underground cyberpunk resistance against a corporate hellscape where the RAD prototypes of yesterday are the industry standard release-quality applications of today, where users have become unpaid QA, and where performance is treated as a matter of simply waiting for faster hardware to make up for the sixty-eight layers of indirection they're using in their BlubCodeFactoryManagers. If you want to write tight, optimised code in your favourite mix of C and assembly, then go for it, but if you want to know why this is so unpopular specifically for GUIs, it's because GUIs often spend most of their time being looked at rather than interacted with, and when they're interacted with they usually just show and hide a few components, and even if they did have any hard work to do, that usually gets handed off to a helper written in a faster language. With such intermittent and light workloads, a "slower" language is often seen as a valid tradeoff if it speeds up development, because most of the time spent by the program will be spent inside GUI libraries written in C++, or (the vast majority of the time) simply doing nothing waiting for messages from the windowing system.
That is to say, I strongly suggest that the ire against C# for a game launcher is misplaced, but if you believe it to be important then I suggest you band together some like-minded people and fork something off in a language you can agree on. There are plenty of programmers, especially 4chan /g/ types, who hold similar opinions on C#, so you will not find yourself alone in that task if you look around.
I had hoped they would actually fix this bug, and was subscribed to its updates to get informed on when they did, but given you lot being off-topic for a week straight, it's probably destroying any chances of that.
This bug was always a bit of a pipe dream. Not flashy enough, doesn't affect enough users, risks inconsistent branding. I don't think a long comment section is going to affect its chances at getting fixed.
If you use i3 i found making everything but the main steam window floating to work somewhat nice:
for_window [class="^steam$"] floating enable
for_window [class="^Steam$"] floating enable
for_window [class="^steam$" title="^Steam$"] floating disable
This pissue still stands in 2024, on both Windows and Linux. Let us use native window handling, and please kill the Electron crap - which is worse than VGUI. Use QT, you motherbleepers!
At this point, this thread has devolved into nothing but dickwad comments like the one above; the smart thing to do at this point is to just mark it WONTFIX and close it.
Yeah but it's never been so broken in 20 years or so, at this point it's
almost WONTUSE, at least on my side I'm happy to have finished recently my
latest steam game so that I can stay away from their client, and I'll try
to use it as little as possible from now on, it's really not a nice
experience anymore.
Le lun. 1 avr. 2024 à 02:29, stevethepocket @.***> a
écrit :
At this point, this thread has devolved into nothing but dickwad comments
like the one above; the smart thing to do at this point is to just mark it
WONTFIX and close it.—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-2028968264,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAV3SD5HH2PHASGTRWB66T3Y3CS5VAVCNFSM4ADEUGG2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSHA4TMOBSGY2A
.
You are receiving this because you were mentioned.Message ID:
@.***>
Yeah but it's never been so broken in 20 years or so, at this point it's almost WONTUSE, at least on my side I'm happy to have finished recently my latest steam game so that I can stay away from their client, and I'll try to use it as little as possible from now on, it's really not a nice experience anymore. Le lun. 1 avr. 2024 à 02:29, stevethepocket @.> a écrit :
…
At this point, this thread has devolved into nothing but dickwad comments like the one above; the smart thing to do at this point is to just mark it WONTFIX and close it. — Reply to this email directly, view it on GitHub <[#1040 (comment)](https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-2028968264)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAV3SD5HH2PHASGTRWB66T3Y3CS5VAVCNFSM4ADEUGG2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSHA4TMOBSGY2A . You are receiving this because you were mentioned.Message ID: @.>
Yup, I'm getting a black screen on steam since the latest update. Literally a CANTUSE.
Replying to [#1040 (comment)](https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-1595270204)
have a look at https://github.com/Rosentti/opensteamclient
Current status: Being rewritten in C#
it's being rewritten in a bloated and slow microsoft language, so it's worse, no thanks, i don't want that on my computer
C# is slow? Have you ever written a line of code with it?
At this point learn C or zig and write your own Steam client, we're all waiting for it.
The problem is that it's alpha, and it's probably going to be hard to have
all the official features without any official support for that.
Le lun. 1 avr. 2024 à 17:26, awsms @.***> a écrit :
Yeah but it's never been so broken in 20 years or so, at this point it's
almost WONTUSE, at least on my side I'm happy to have finished recently my
latest steam game so that I can stay away from their client, and I'll try
to use it as little as possible from now on, it's really not a nice
experience anymore. Le lun. 1 avr. 2024 à 02:29, stevethepocket @.> a écrit : … <#m_-97145762747278515_> At this point, this thread has
devolved into nothing but dickwad comments like the one above; the smart
thing to do at this point is to just mark it WONTFIX and close it. — Reply
to this email directly, view it on GitHub <#1040 (comment)
https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-2028968264>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAV3SD5HH2PHASGTRWB66T3Y3CS5VAVCNFSM4ADEUGG2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSHA4TMOBSGY2A
https://github.com/notifications/unsubscribe-auth/AAV3SD5HH2PHASGTRWB66T3Y3CS5VAVCNFSM4ADEUGG2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSHA4TMOBSGY2A
. You are receiving this because you were mentioned.Message ID: @.>Yup, I'm getting a black screen on steam since the latest update.
Literally a CANTUSE.Replying to #1040 (comment)
https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-1595270204have a look at https://github.com/Rosentti/opensteamclient
Current status: Being rewritten in C#
it's being rewritten in a bloated and slow microsoft language, so it's
worse, no thanks, i don't want that on my computerC# is slow? Have you ever written a line of code with it?
At this point learn C or zig and write your own Steam client, we're all
waiting for it.—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-2029972252,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAV3SD6H4RCYLVD6HK2KIITY3F4EDAVCNFSM4ADEUGG2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSHE4TOMRSGUZA
.
You are receiving this because you were mentioned.Message ID:
@.***>
Click-to-raise: I have this disabled. Steam does its own thing.
Client-side decorations: inconsistent with the rest of the desktop. (It may or may not be consistent on Windows, but I don't use Windows.) Also means that keyboard is required for some operations (such as lower, shade or toggle size along one axis).
Menus and transparency: menus aren't properly parented, and some menus aren't even proper windows – they're (presumably) just DOM constructs handled by embedded Chromium. Effect is that the WM doesn't know to leave the parent window opaque when the pointer's in a menu or to apply the configured transparency for the fake-window menus.
Misbehaviour: Steam doesn't take any notice of the standard window hints. Combined with recent window-handling bugs, my running instance of Steam wrongly thinks that its main window is maximised.
Personally, I would just throw out the client-side decorations for actual windows in favour of whatever window manager is running, and keep that code only for in-game.
@Ashark how did you make steam use the system titlebar? I havent been able to figure it out.
@Ashark how did you make steam use the system titlebar? I havent been able to figure it out.
This is a KDE-only feature. Alt + F3 in steam window, then uncheck checkbox "Additional" -> "Hide border and titlebar" (the translation may be slightly different).
https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-12876579
@gracicot, I don't see any reason to limit this modification to Linux-based OSes. I've been pained by this running Windows 11 Pro, macOS, and Fedora. It applies as much to other OSes' WMs as it does to KWin or GNOME's.
As an example, there are hooks for Windows's dwm.exe which provide additional functionality. However, unless these are set as key binds, they're unavailable in Steam (at least, until I locate an answer to https://superuser.com/q/1850632/904401).
This issue is now 11 years old, and the very single time a Valve employee bothered to have a look at it was to post something completely off-topic.
Safe to assume it will never be taken care of.
But it still has its usefulness to hear about possible workarounds or
alternatives sometimes.
Le jeu. 15 août 2024 à 02:52, awsms @.***> a écrit :
This issue is now 11 years old, and the very single time a Valve employee
bothered to have a look at it was to post something completely off-topic.
Safe to assume it will never be taken care of.—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-2290175827,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAV3SDZ5FSZAZ4ICE6PMIBLZRP3WHAVCNFSM4ADEUGG2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMRZGAYTONJYGI3Q
.
You are receiving this because you were mentioned.Message ID:
@.***>
Recently installed on arch and with my window manager I cant move maximize or interact with the steam window. Missing my WM's normal context bar for some reason. All this really needs is a launch flag
A workaround would be using Devilspie2 which will work on any freedesktop.org compliant window manager
You can use the following script:
if (get_window_name() == "Steam") then
decorate_window();
end
Save with .lua extension in ~/.config/devilspie2 and add devilspie2 to startup
@Ashark how did you make steam use the system titlebar? I havent been able to figure it out.
This is a KDE-only feature. Alt + F3 in steam window, then uncheck checkbox "Additional" -> "Hide border and titlebar" (the translation may be slightly different).
This still keeps steam's own window decorations underneath right? Or am I missing something?
This still keeps steam's own window decorations underneath right? Or am I missing something?
See this comment: https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-1597572748
It will be nice if we can at least change the window manipulation buttons from the top-right to the top-left corner.
13 years later the POS Steam window still can't be styled by the window manager. Love Linux on the server, always have, but on the desktop? Decades later there's still not a single Linux desktop environment where all windows get the same window controls and borders or where you can have a global menu panel where more than half the apps actually export a menu to it instead of <<BLANKETY FING BLANK>>. No what we need is another 10 desktops 50 compositors and 277 window managers and a billion apps that all do their own thing and all look different and weird in their own unique stupid ways.
It's very specific to steam this stupid resistance to window managers.
Slashdot says they are making a big update, so maybe finally... but let's
not hope too much!
Le sam. 11 avr. 2026 à 19:44, Eduard Rozenberg @.***> a
écrit :
edrozenberg left a comment (ValveSoftware/steam-for-linux#1040)
https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-422988145713 years later the POS Steam window still can't be styled by the window
manager. Love Linux on the server, always have, but on the desktop? Decades
later there's still not a single Linux desktop environment where all
windows get the same window controls and borders or where you can have a
global menu panel where more than half the apps actually export a menu to
it instead of .—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/1040#issuecomment-4229881457,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAV3SD3SBVRZW5A3DOFPSU34VJ77RAVCNFSM6AAAAAB5D7SPH2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMRZHA4DCNBVG4
.
You are receiving this because you were mentioned.Message ID:
@.***>
I came to this issue because I just tried to double-click the Steam client title bar, to maximize it, like happens on Windows and most Linux WMs. Nothing happened except my cursor twice briefly turning into the one for dragging a window.
If Steam doesnʼt want to support SSDs, can it at least have CSDs that work?
I came to this issue because I just tried to double-click the Steam client title bar, to maximize it, like happens on Windows and most Linux WMs.
That's exactly the kind of feature which I switch off; I'd be complaining about it if Steam started doing that without a way to switch it off.
If Steam doesnʼt want to support SSDs, can it at least have CSDs that work?
That includes things like middle- and right-click on the toggle-size button, neither of which Steam handles.
That's exactly the kind of feature which I switch off; I'd be complaining about it if Steam started doing that without a way to switch it off.
I donʼt know why youʼd switch that off; it wouldnʼt usually happen by accident so it doesnʼt get in the way if you donʼt use it. But in any case, wouldnʼt it be nice if there were a central place where you could set the behavior of window decorations how you want and I could set them how I want? Like, if they were provided by a central piece of software and not every single application individually?
I donʼt think you can turn it off on Discord any more than I can turn it on on Steam.
I donʼt know why youʼd switch it off; it wouldnʼt usually happen by accident so it doesnʼt get in the way if you donʼt use it.
I don't know why you'd leave it enabled. Every time that I've triggered maximisation (or whatever else is configured in its place) via double-click on the title bar, it's been accidental; I quite quickly switched it off (in “a central piece of software”, as it happens) precisely because it got in the way.
(Note: slightly sarcastic re. preceding comment. Americans probably won't get it.)
Classic "I don't use this feature and can't understand why anyone would want it" attitude.
The point is that apps should handle these events, if sent by the window manager, so users can have their global preferences and consistency.
Yeah; I donʼt understand how you can accidentally double click the title bar but it doesnʼt matter. You want to turn it off because it somehow gets in your way; I want it because itʼs a lot easier to hit a huge bar than a single small square. We could both have what we wanted if it used server-side decorations. Neither of us can have what we want now; dsalt is fine with (this aspect of) Steam but probably has issues with Discord or another program where you canʼt turn it off; I am fine with (that aspect of) other CSD apps but canʼt turn it on in Steam.
If everything used SSDs when available and only fell back to CSD in GNOME, then we could all have what we want consistently with a single checkbox. As it is, none of us can have what we want consistently, and Steam is adding to that.
+1
Upstream links
- ValveSoftware/steam-for-linux/issues/1040x16 2026-04
- ValveSoftware/steam-for-linux/issues/1890x1 2022-04
- ValveSoftware/steam-for-linux/issues/564x1 2014-01
- ValveSoftware/steam-for-linux/issues/1025x1 2013-02
- ValveSoftware/steam-for-linux/issues/1720x1 2013-02
- ValveSoftware/steam-for-linux/issues/266x1 2013-02
_NET_WM_WINDOW_TYPEproperty. At the minimum, dialog windows should be given the_NET_WM_WINDOW_TYPE_DIALOGvalue so that the WM can center them or put them under or near the mouse cursor - or whatever else the WM/user likes. Menu windows are already correctly classified as_NET_WM_WINDOW_TYPE_MENU. Also, initial window sizes need to be set before the window is shown (ideally before it is mapped).WM_HINTand theWM_CLIENT_LEADERproperty. This will prove interaction with the WM's focus stealing prevention (if the running WM has that feature). With KWin this also has the added benefit that "Dim Inactive" desktop effect will leave all Steam windows at full brightness when any Steam window has focus (if configured to apply the effect to window groups).I previously reported this here when Steam was still in closed beta, and some of the suggested enhancements/fixes have since been implemented - the remaining ones are listed above.
Here is my proof of concept implementing these changes on the Xlib level - of course a real solution would implement this in Steam. I have tested these changes on my own system, but others have found them useful with different WMs, including Ubuntu's Unity.