Steam is "fighting" with AwesomeWM over size and position of windows

[DarkDefender]

When I use Awesome (http://awesome.naquadah.org) as my window manager steam tries to fight with the WM over how it's windows it positioned and what size they have.

It really apparent in tiling mode if one of the tiles that steam have is smaller than the arbitrary (?) minimum size of the current window. So for example if I'm in "Games Details" view and the window manager shrinks the size of the window below that minimum size it will try to grow itself again. However the WM will then shrink it back the size it tried to shrink it to and this repeats forever. It results in a rather ugly strobe effect. And the window it kinda annoying and unusable till steam gets it's way. The "Small Mode" view is less of a problem because the minimum size seems to be much smaller.

However it's even worse if I don't use the window managers tiling mode. If I put the steam window in "floating mode" and try to resize it steam tries to reposition it while I'm resizing it! This results in the window going out of control and moving around the screen resizing and moving kinda like the ball in the game "pong". If I then stop resizing the window it still jumps around the screen till I manually kill steam.

I managed to workaround this "pong" bug with the help of this thread: http://steamcommunity.com/app/221410/discussions/0/882966056287209213/#p1 I hope that thread will be useful as it point out some of the flaws in how steam currently handles windows. And on top of that it has code that fixes some of them: https://gist.github.com/06d6b6a5370c4f6979f3

However that workaround doesn't solve the size fighting. On some windows I think the minimum size could be smaller than it is right now. But I do understand that some of the view can't be function below a certain size. But it's a big no no to fight with the window manger over size and position. So I have two possible solutions for the size problem (when it's below minimum):

1. Don't care if the size is too small, just roll with it and let the user deal with it... IE just remove the minimum size limit. I think this is what most other programs does as I only have had this size fighting problem with steam.
2. If the size it too small remove the window contents and just have a simple text string saying "window size is too small". I've seen some terminal programs use this method when the terminal is too small. However I've never seen a GUI do this.

AwesomeWM is a tiling window manager so I think these problems I'm having will be true for any other tiling WM.

A addition problem is that steam doesn't seem to register it's tray icon. Does it follow the free desktop spec in this regard? http://standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html

My system info:

Processor Information:

Vendor:  GenuineIntel

Speed: 3203 Mhz

4 logical processors

4 physical processors

HyperThreading:  Unsupported

FCMOV:  Supported

SSE2:  Supported

SSE3:  Supported

SSSE3:  Supported

SSE4a:  Unsupported

SSE41:  Supported

SSE42:  Unsupported

Network Information:

Network Speed:  

Operating System Version:

"NAME=Gentoo" (64 bit)

Kernel Name:  Linux

Kernel Version:  3.5.7-gentoo

X Server vendor:  The X.Org Foundation

X Server release:  11204000

Video Card:

Driver:  ATI Technologies Inc. ATI Radeon HD 4800 Series        

Driver Version:  3.3.11672 Compatibility Profile Context

Desktop Color Depth: 24 bits per pixel

Monitor Refresh Rate: 59 Hz

VendorID Not Detected

DeviceID Not Detected

Number of Monitors:  1

Number of Video Cards Not Detected

Primary Display Resolution:  1920 x 1200

Desktop Resolution: 1920 x 1200

Primary Display Size: 20,39" x 12,76"  (24,02" diag)

                                        51,8cm x 32,4cm  (61,0cm diag)

Primary VRAM Not Detected

Sound card:

Audio device: 

Memory:

RAM:  3956 Mb

Miscellaneous:

UI Language:  English

LANG:  sv_SE.UTF-8

Microphone:  Not set

Total Hard Disk Space Available:  234143 Mb

Largest Free Hard Disk Block:  12133 Mb

Installed software:

Recent Failure Reports:

Thu Jan 24 10:41:36 2013 GMT: file ''/tmp/dumps/crash_20130124114134_1.dmp'', upload yes: ''CrashID=bp-01b00495-6c4c-4e04-a883-39e9b2130124''

[davidw-valve]

I'm afraid we don't support awesome.

[DarkDefender]

Well you don't have to support Awesome per se. Most other programs for linux doesn't have support for specific window managers. But they still work with with multiple WMs regardless.

As pointed out in the steam community thread I linked steam right now breaks some of the rules window clients should adhere to under X11 Xorg.

The problems I have is because steam tries to manage the windows while this is the job of the window manager. As I said before window clients should not try to manage themselves.

I would also like to point out that this would not only help awesome users but other users as well. The user that wrote the fixes that I use to workaround these bugs is using KDE for example. This should mean that Kubunutu and Xubuntu and Lubuntu users would benefit from this as well. And it will make steam more future proof I think.

I find it hard to believe that all other programs I use in Linux including Desura is working flawlessly in gnome, KDE and Awesome for me while Steam cannot do this.

Please, I don't ask you to officially support an absurd number of specific window managers. I only ask for some fixes so steam follows some of the standards of the desktop under linux (X11 xorg).

I only want steam to be as good as the other, be it open source or closed source, programs I've used under Linux.

I understand that you are currently focusing on Ubuntu support. But I hope that davidw response doesn't mean that you won't look into/fix these problems because it currently works under Unity...

[txdv]

I'm an awesome user myself, but he has a point, why does that particular window try to resize the width by 2 dots?

[ku1ik]

+1

This is not about AwesomeWM. This is about writing software in the proper way. If you target Linux than you should accept the fact that the app itself should not be in charge of window management. I suppose this rule could apply to non-Linux OS'es also.

[simontunnat]

+1

I'm also experiencing a very buggy Steam behaviour under the awesome wm and would appreciate any tipps as I'm very new to the whole tiling wm topic.

[christopherredden]

Steam should adhere to X Windowing guidelines.

[xgdgsc]

I have dual monitor setting, the external one smaller resolution and the laptop one larger resolution. The problem is that steam always start on the external one with a smaller resolution with awesome wm.

[EduardoOliveira]

@xgdgsc change your main screen on your X file, by text or nvidia settins if thats the case

[chinoto]

I remember this being a problem when using Steam on Wine. If you try to make Steam4Linux too small on KDE, it will snap to a minimum resolution as soon as you hover over something requiring a tooltip (e.g. STORE LIBRARY COMMUNITY [PLAYER NAME]).

[moshen]

+1

[rdb]

Being a Linux software developer myself, I want to emphasise that this is not a matter of 'supporting esoteric window managers'. It is a matter of properly implementing window manager protocols.

I'm a dwm user myself, and whenever I click a window that is not the main window, it becomes the main window. That means that whenever I click a window on the right of the screen, all windows reorganise themselves so that it is suddenly on the left side.

It is not proper for applications to rearrange their focus or position in the stack manually based on input events. The window manager is supposed to take care of which window has focus and which window is in front.

Almost every other program behaves correctly because they simply conform to specification and don't try to pull tricks that limit portability. When applications (like Steam) start doing that, they risk breaking every window manager that behaves even slightly differently than the one they tested for.

For now, I'm limited to using Steam on Wine, which is (sadly) far more reliable than Steam for Linux in this and other aspects.

[majutsushi]

Steam is clearly violating the ICCCM standard here. Quoting from §4.2.4:

"The response of the client to being resized should be to accept the size it has been given and to do its best with it. Clients must not respond to being resized by attempting to resize themselves to a better size. If the size is impossible to work with, clients are free to request to change to the Iconic state."

So this is not about supporting specific window managers, but about adhering to the standards that are being used in Linux.

[PotcFdk]

+1 Please improve the client-to-wm communication (Steam should not be in charge of window management).

[cjwijtmans]

+1

[thomas-louvigne]

+1

[gandalfx]

+1 adhere to standards please! Otherwise you'll just cause unnecessary issues. It's not worth the fancy window borders.

[krissen]

+1

[cjwijtmans]

you can still adhere to the standards and still have fancy window borders i am sure chrome/chromium does.

Live long and prosper,

Christ-Jan Wijtmans https://github.com/cjwijtmans http://facebook.com/cj.wijtmans http://twitter.com/cjwijtmans

On Fri, Aug 8, 2014 at 8:50 PM, krissen notifications@github.com wrote:

+1

— Reply to this email directly or view it on GitHub https://github.com/ValveSoftware/steam-for-linux/issues/807#issuecomment-51642719 .

[loansindi]

Steam's behavior with tiling WMs is still an issue and still frustrating.

[Plaque-fcc]

Yeah, it does. Honestly, this also can happen to other windows because of how Awesome WM works with window borders or like that, AFAIK.

There's a fix which helps for maximized windows, but I didn't try it, so I can't say if it fixes the subject.

[micaelbergeron]

+1, as a awesome user, I would also like to dedicate an entire workspace to steam related windows.

Please, be standard.

[Plaque-fcc]

Suddenly, I preferred to set client border (window border) to 0: this thing worked many issues around and this one too.

[0x647262]

+1

[ekisu]

+1

[txdv]

I think will we see HL3 sooner than this being fixed.

[0x647262]

But we can hope!

[Plaque-fcc]

…to behold both? ;D

I set

border_size = 0, size_hints_honor = false

rule for all windows and now I don't suffer of that. But I still think it's an issue on the sides of Steam and Awesome WM, both of them.

[jplatte]

Interestingly, i3-wm doesn't have any problems forcing the steam window into a small size and steam never changed its size or position automatically for me, even in floating mode. I think I'm using the beta version though (the Steam package version [which you can't copy-paste for no reason although it's very long] is 1424305157).

[whyrusleeping]

I use both i3 and awesome, I havent experienced issue in awesome, but i always keep steam as a floating window by default. In i3 I cant close the steam window with the "x" in the upper right corner. Although that is probably a separate issue...

[jplatte]

Haha, trying that out froze the Steam window for me. But yeah, I think that's a seperate issue too.

[micaelbergeron]

One thing I've found during my testing is that the Steam's windows seemingly share all the same WM_CLASS names, making it hard to use rules to position them correctly. Furthermore, they also seemed to have unstable WM_NAMES (i.e. Chat window changes name).

What about just separating the windows so we can rule them properly?

[xarvh]

Have the same problem under Qtile.

[LordReg]

I tested Steam package version 1444343307 and confirm that the Linux Steam client does indeed violate ICCCM section "4.2.4. Window Resize" and more generally section '4.1. Client’s Actions.' (see http://www.x.org/docs/ICCCM/icccm.pdf).

If the window size is anything less than the minimums specified in WM_NORMAL_HINTS, Steam continuously updates WM_NORMAL_HINTS and tries to configure the window. The WM is essentially spammed with ConfigureRequest events.

If the window is 'too small' for the Steam UI, then Steam should let it be that way and simply continue to draw the window contents for the provided window geometry. It's up to the WM to offer a mechanism to keep a window within the program-specified constraints. In the case of tiling WMs, the constraints may only be observed on windows that are floating (not tiled.) Even if the WM does constrain the window it may offer an override.

[DarkDefender]

This seems to be fixed for me in the latest steam beta. So I'll close this now

[LordReg]

The issue still exists on the latest beta: Steam client application Built: Jan 25 2018, at 21:25:07 Steam API: v018 Steam package versions: 1516948201

The issue may not be visible depending on the window manager, but if you monitor X11 event activity you will see Steam still hammers ConfigureRequest events when its windows are sized smaller than WM_NORMAL_HINT "program specified minimum size".

[j3ky]

haha still a issue (5 years late). I3wm or Dwm

[TerminalWitchcraft]

Same issue here, Archlinux with awesome v4.2-334-gd7e09a04 , The floating windows seem to get pulled down by some unknown gravitational force towards the bottom right of the screen!!!

[elevenchars]

I'm having the same issue as @TerminalWitchcraft in awesomewm. I haven't had this issue anywhere else, and interestingly enough it only happens when I set GDK_SCALE=2.

[chinoto]

Went back and looked at my problem (window snaps back to min res when triggering a tooltip), the new behavior is that it refuses to shrink smaller than its minimum resolution. While it is misbehaving on other DEs and possibly against some standards, I'm considering this fixed for my own use case. Hope everyone else gets their use case worked out, seeya.

Edit (minutes later): Steam doesn't have a resize handle anymore, so I used the window context menu to resize it, posted my results, then went to maximize it... maximize button didn't work. After a bit of testing it doesn't seem to have anything to do with resizing, the maximize button works once and then will only work as a restore afterward (I used the window context menu to force a maximize). So I guess I'll stick around.

Edit2: Btw, this is KDE on openSUSE 15. 4.14, 5.12, or 5.45 depending on which package you ask. Recently updated and only using standard repos for those packages, so I'm not sure what's up with that.

Edit3 (to avoid notifying subscribers): Thanks @kisak-valve, I'll switch my subscription to that issue.

[kisak-valve]

Hello @chinoto, you've described the issue being tracked at #3792.

[ssolidus]

Same issue here, Archlinux with awesome v4.2-334-gd7e09a04 , The floating windows seem to get pulled down by some unknown gravitational force towards the bottom right of the screen!!!

Same setup here - the new Steam chat UI moves downwards every time you click anything on it, and the windows break constantly.

[pavel-ruban]

Im on archlinux + awesomewm, found this thread as I had problem:

The floating windows seem to get pulled down by some unknown gravitational force towards the bottom right of the screen!!!

As I didn't find a proposition here, found myself a quickfix for that:

vim rc.lua

-- {{{ Signals
-- Signal function to execute when a new client appears.
client.connect_signal("manage", function (c, startup)
  awful.client.movetoscreen(c, awful.screen.focused())
  if c.class == 'cairo-dock' then
    return
  elseif c.class == 'conky' then
    return
  else
    client.focus = c
    client.focus:raise()
  end

    if not startup then
        -- Set the windows at the slave,
        -- i.e. put it at the end of others instead of setting it master.
        awful.client.setslave(c)

        -- Put windows in a smart way, only if they does not set an initial position.
        if not c.size_hints.user_position and not c.size_hints.program_position then
            awful.placement.no_overlap(c)
            awful.placement.no_offscreen(c)
        end
    end

    local titlebars_enabled = true
    if c and c.class ~= 'Steam' and c.class ~= 'Gimp' and c.class ~= 'gimp' and c.class ~= 'Virtualbox' and c.class ~= 'Chromium' and c.class ~= 'chromium' and c.class ~= 'MPlayer' and c.class ~= 'vdpau' and c.class ~= 'Google-chrome' and c.class ~= 'Google-chrome-beta' and c.class ~= 'URxvt' and c.class ~= 'google-chrome' and c.class ~= 'Cairo-dock' and c.class ~= 'Cairo-dock' and c.class ~= 'jetbrains-phpstorm'   and c.class ~= 'Firefox' and titlebars_enabled   then
            -- Widgets that are aligned to the left
        local left_layout = wibox.layout.fixed.horizontal()
        left_layout:add(awful.titlebar.widget.iconwidget(c))

        -- Widgets that are aligned to the right
        local right_layout = wibox.layout.fixed.horizontal()
        right_layout:add(awful.titlebar.widget.floatingbutton(c))
        right_layout:add(awful.titlebar.widget.maximizedbutton(c))
        right_layout:add(awful.titlebar.widget.stickybutton(c))
        right_layout:add(awful.titlebar.widget.ontopbutton(c))
        right_layout:add(awful.titlebar.widget.closebutton(c))

        -- The title goes in the middle
        local title = awful.titlebar.widget.titlewidget(c)
        title:buttons(awful.util.table.join(
                awful.button({ }, 1, function()
                    client.focus = c
                    c:raise()
                    awful.mouse.client.move(c)
                end),
                awful.button({ }, 3, function()
                    client.focus = c
                    c:raise()
                    awful.mouse.client.resize(c)
                end)
                ))

        -- Now bring it all together
        local layout = wibox.layout.align.horizontal()
        layout:set_left(left_layout)
        layout:set_right(right_layout)
        layout:set_middle(title)
   --     c.border_width = 1
        awful.titlebar(c, {size = "54"}):set_widget(layout)
    end

    if c and (c.class == 'Chromium' or c.class == 'chromium' or c.class == 'Google-chrome' or c.class == 'Google-chrome-beta' or c.class == 'google-chrome' or c.class == 'Firefox') then
            c.maximized = not c.maximized
            c.maximized_horizontal = not c.maximized_horizontal
            c.maximized_vertical   = not c.maximized_vertical
    end
end)

This is default piece of lua config + some custom code that doesn't apply above title bar for a set of different applications including Steam, I guess disabling titlebar can be done in a other way but I had this config for a while & just adjusted for steam, additionally Ive put style in the same rc.lua file:

-- {{{ Rules
awful.rules.rules = {
    -- All clients will match this rule.
    {
      rule = { },
      properties = {
        border_width = beautiful.border_width,
        border_color = beautiful.border_normal,
        --focus = awful.client.focus.filter,
        keys = clientkeys,
        size_hints_honor = false,
        buttons = clientbuttons
      },
      callback = function(c)

        local scr_area = screen[c.screen].workarea
        local cl_strut = c:struts()
        local geometry = c:geometry()

        c:geometry({
          x = scr_area.width / 2 - geometry.width / 2,
          y = scr_area.height / 2 -  geometry.height / 2
        })

       end
    },
    {
      rule_any = { {class = "Steam", class = "steam"} },
      properties = {
        border_width = 0,
        border_color = 0,
        size_hints_honor = false
      }
    }
}

[Orjanp]

Im on archlinux + awesomewm, found this thread as I had problem:

The floating windows seem to get pulled down by some unknown gravitational force towards the bottom right of the screen!!!

As I didn't find a proposition here, found myself a quickfix for that:

vim rc.lua

Tested it. Didn't work for me. Steam windows still moving to the bottom of screen.

steam 1.0.0.61-4 awesome 4.3-1

To bad they wont fix this issue after so many years.

[kuremu]

This is also happens on xmonad: the "connecting" window and certain others drift down and to the right. On the plus side, it is sometimes like a small minigame where I have to eg. set launch options before the window slides off the bottom right of the screen.

I haven't tried forcing these windows to tile by default, but on xmonad at least a workaround is to tile the drifting window with a binding like ((modm .|. shiftMask , xK_t ), withFocused $ windows . W.sink)

[DusanLesan]

+1 I have this issue on Arch with dwm. Client is enforcing its program specified minimum size I would not mind it if it was 960 by 520, but 1010 by 600 is too large to fit.

[TerminalWitchcraft]

The issue is open for 8 years :( I hope steam (or whoever is responsible for this issue) fixes them soon!

[idar]

Still a problem

[rejexy]

I don’t understand why this problem is still not solved, because part of the interface is chromium and in general it has a responsive design, and the restrictions are made just for limitation. But I hope that in the near future valve will do something with its gui, because there are more and more tiled wm users, and even in windows 11 a similar system will appear.

[oddhack]

I see the login window sliding down off the screen in WindowMaker. Presumably for the same standards-violating-behavior reasons cited many times upthread. Steam is unusable for me barring some known workaround for my WM.

[illusioon]

Steam still bad on any tilling window manager :(