The window manager implements app indicator behavior so this isn't directly a Steam issue. In the cases with slow menu mouse-over behavior it looks like the window manager is relying on Steam to run GTK processing regularly. Steam only runs GTK when it needs to, and when a library page is up it doesn't need to, which seems fine for Steam to do so it's unclear what Steam should do here.
As a counter-example Unity has no issues.
This isn't about WM since i clearly stated that it's about one of the fallback states of libappindicator - which is just using regular systray.
It has nothing to do with Unity, which implements app/system indicators
Sorry, I should have said WM/libappindicator. Either way, this is not a Steam issue.
Steam, systray implementation and libappindicator can work easily without WM.
"Steam only runs GTK when it needs to, and when a library page is up it doesn't need to, which seems fine for Steam to do so it's unclear what Steam should do here."
So maybe steam should run GTK to do »nothing«. Or file more detailed bug report to libappidicator project so it could be fixed there.
We've had a number of discussions with Canonical about libappindicator. They are looking at several things.
Closing as this issue is not a Steam issue.
So if the issue is that Steam doesn't run the GTK error loop on the library page... Why not make it do it? It's not like it causes any performance issues on the other pages.
The issue isn't within Steam, app indicators have no requirements on the app running GTK. It's an issue within the app indicator and window manager handling.
@gdrewb-valve: From user's point of view, it's Steam's issue since you distribute it bundled with steam (as part of steam runtime). Also it was your choice to pick that sooooo buggy library for something that important as tray icon is. What I'm trying to say is that this appindicator library seems to be very bad choice (as proven by tons of issues).
Again WM has nothing to do with that, and this issue can be fixed in both places.
Steam and X11's libappindicator/systray doesn't need WM at all
If the issue is somehow within libappindicator, why not patch the copy you distribute in the Steam Runtime?
Alternatively, instead of libappindicator, you can borrow the KDE implementation of the new (D-Bus based) indicator, or implement the Status Notifier Specification yourself. Though I understand that the last option is really far-fetched.
libappindicator claims to support that (KSNI)
libappindicator IS an implementation of KSNI for GTK applications. Falling back to the old XEmbed style tray icons if necessary (e.g. for GNOME Shell or plain GNOME 2).
FWIW, there has been no delay anymore for some time here..
Define »here«
It still occurs at least on x86_64 system with enabled STEAM_RUNTIME, xfce 4.10.x, while library tab is active
ok, to be clear we're talking about the same thing: I used to have a long delay when I rightclicked on the steam systray icon before the menu would show up. In one of the latest updates (in the meanwhile a few weeks ago), it was fixed for me. I'm on KDE and since I know certain systray implementations go through DBus, I assumed the delay was caused by some dbus connection timeout.
Regarding the steam runtime, I didn't change anything about that, so I guess it's enabled, reading this line on startup:
"STEAM_RUNTIME is enabled automatically"
Here is my full sys info:
Processor Information:
Vendor: AuthenticAMD
Speed: 3200 Mhz
4 logical processors
4 physical processors
HyperThreading: Unsupported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Supported
SSE41: Unsupported
SSE42: Unsupported
Network Information:
Network Speed:
Operating System Version:
"openSUSE 12.2 (x86_64)" (64 bit)
Kernel Name: Linux
Kernel Version: 3.4.11-2.16-desktop
X Server Vendor: The X.Org Foundation
X Server Release: 11203000
X Window Manager: KWin
Steam Runtime Version: steam-runtime-release-i386_2013-02-22
Video Card:
Driver: NVIDIA Corporation GeForce GTX 275/PCIe/SSE2
Driver Version: 3.3.0 NVIDIA 310.19
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 59 Hz
VendorID: 0x10de
DeviceID: 0x5e6
Number of Monitors: 2
Number of Video Cards Not Detected
Primary Display Resolution: 1680 x 1050
Desktop Resolution: 2960 x 1050
Primary Display Size: 17.05" x 10.67" (20.08" diag)
43.3cm x 27.1cm (51.0cm diag)
Primary Bus: PCI Express 16x
Primary VRAM: 896 MB
Supported MSAA Modes: 2x 4x 8x 16x
Sound card:
Audio device: Nvidia MCP77/78 HDMI
Memory:
RAM: 8000 Mb
Miscellaneous:
UI Language: English
LANG: en_US.UTF-8
Microphone: Not set
Total Hard Disk Space Available: 379516 Mb
Largest Free Hard Disk Block: 72560 Mb
Installed software:
Recent Failure Reports:
Fri Feb 22 18:59:27 2013 GMT: file ''/tmp/dumps/assert_20130222195904_1.dmp'', upload yes: ''CrashID=bp-e3dc56b9-821f-42ff-8ce1-029c62130222''
I'm still getting the lag (on library tab). Archlinux x86_64.
aha! yes, I also have it on the library tab! I tried all other tabs, it only happens on the library tab! I didn't realize that :)
There is one exception on the lib tab: try switching to downloads in the lib tab, then switch to another tab, then return to the lib tab and rightclick on the systray icon -> in my case consistently no delay.
Confirmed on Arch linux x86_64 using:
If every other program gets it right and it only works in one or two window managers, then surely it's a sign that you're doing something wrong?
Also, I don't think contacting canonical is the way to go about it -- they're so Linux they actively refuse to put the word "Linux" on their website!
Closing as this issue is not a Steam issue
If Steam is using a faulty library simply for integration with what is probably the world's most terrible desktop environment (Unity -- the only way I could find it remotely tolerable is if I had touchscreen), then Steam should switch to something that works instead. GTK provides ample framework for this kind of thing.
so.. is there already a bug filed for the libappindicator project? I'd like to understand in detail what the problem is to see if I could help out.
Seems fixed for me now on Ubuntu 13.10.
@Sikon it seems to have been designed to work on Ubuntu alone. Or rather ubuntu+unity.
I had been seeing delays as well on KDE. I no longer have a delay. I'm not sure if it was an update to KDE 4.11.2 or a change in steam, but it appears fixed for KDE at least.
And X backend (used eg. in xfce4) has not changed its behavior.
But at least it's good to see it working in other indicators implementations
It works for me too in KDE, but I'd rather not switch desktop environments just to use one program.
And X backend (used eg. in xfce4)
How does steam determine what desktop environment it's running in? I would have thought that to be a near-impossible task.
I can confirm it works on KDE now and that it was not fixed by a KDE update since I'm still running 4.10.5
Is anybody still seeing this?
Yes, Xfce4 and anybody else using X11 fallback -.-
https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Custom_Fallbacks
OK, leaving as-is.
I have the same issue on ArchLinux x64 and Debian 7.3 (tested on stable, testing and sid)
However, the tray menu only becomes slow when the Library tab is open.
Still have this issue on Arch with Awesome Window Manager, only when Library tab is open or when the main window is closed.
Strange that you mention that, did I miss a changelog? I'm using i3 on Arch again and it's become as responsive as a normal program.
I can confirm though, that opening the library tab breaks it again.
The issue isn't within Steam, app indicators have no requirements on the app running GTK. It's an issue within the app indicator and window manager handling.
That's just plain wrong. You pick the libraries, you deliver your software. The user does not care about what libraries you use. And we will not file bugs for library maintainers saying "hey, there is some closed source application that produces a bug in conjunction with your library".
Despite that... I have not seen such an issue in over 10 years of using linux.
How is this bug resolved anyway?
Using a fresh install of ubuntu gnome with gnome 3.10.4, menu is very laggy, this doesn't happen with other applications
I still get lag using Xfwm4.
@gdrewb-valve This really needs to be reopened, No offense because what you guys are doing is great work but this is definitely an issue with your code. I haven't seen any other application have this kind of behavior, and your menu even looks different from all the others on my system, so I'm not sure how you're using the menu but all logic points to you're doing it wrong.
As discussed in this thread it's libappindicator and not Steam. For example, libappindicator is solely responsible for the appearance of the menu (that's part of the point of libappindicator).
I've reopened as there are some GTK plumbing changes coming in the next few months which might affect the lag (or might not, there's no work being done specifically for this). The various fallbacks and implementations within libappindicator are up to libappindicator and aren't changing as far as I know.
@gdrewb-valve Does no one else use libappindicator? If you can point me to another program that has the same issue using libappindicator then that would certainly go a long way to supporting your case. I see that no one reported a problem under Unity, which would make some sense as libappindicator is designed for Unity. If your goal is only to properly support this in Unity then i suppose you are at the state, if your goal is to support Linux then you might want to move away from libappindicator if you really believe it is a suboptimal experience outside of Unity. There are many many applications that have working systray menus across the range of WMs, somehow they pull it off so it's certainly possible. I understand how minor of a bug this is though.
As discussed in this thread it's libappindicator and not Steam.
I still see no explanation why a customer should care about what libraries you use. It's the features he cares about.
possible solutions include:
you might want to read this thread for a full explanation.
On Mon, Jun 16, 2014 at 9:08 PM, Julian Ospald [email protected]
wrote:
As discussed in this thread it's libappindicator and not Steam.
I still see no explanation why a customer should care about what libraries
you use. It's the features he cares about.possible solutions include:
- work with libappindicator developers to sort it out
- fix libappindicator yourself, you already bundle it
- use a different library
- write your own small library that does the same
—
Reply to this email directly or view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/673#issuecomment-46220849
.
you might want to read this thread for a full explanation.
Thanks, I have and I could not find an explanation why the customer should care about how valve implements anything or what libraries they use.
The customer cares about functionality, not implementation specific details.
@mxttie There is no such explanation, the user doesnt care what libraries the developer uses, just which features work and which don't. If the menu doesn't work, blaming libappindicator isn't the solution, the solution is one of the 4 things mentioned by @hasufell
Valve has chosen to release a version of Steam for Linux so Valve is now responsible for all of Linux? That doesn't make much sense. You would also be saying that a game developer that has released a game on Steam for Linux is not only responsible for all of Linux but also Steam too?
@gdrewb-valve As I said if your goal is to support Unity then it seems you're there. If you goal is to support anything else then your menus are an open bug.
Steam uses OpenGL. If there is no OpenGL support for your video card is that a Steam bug?
@gdrewb-valve You seem to be taking this kind of personally. I'm reporting a bug as I see it, this is supposed to be helping you. If you are not supporting anything other than Unity, then you're in good shape. This thread is about brainstorming ideas to fix systray menus on non-unity WMs, and several good ideas have already been thrown out there. If you don't want to fix it, then obviously nothing we as users can do about that.
@Queuecumber in any case, it works fine on KDE, so it's not only Unity. read @swiftgeek 's comment to see which case is not supported: I guess your WM uses the X11 fallback..
Steam uses OpenGL. If there is no OpenGL support for your video card is that a Steam bug?
My hardware supports libappindicator, so I am not sure what this analogy is for.
Remember that this problem was already pinpointed in 1st comment to the issue¹ -.-
It could be easily fixed / workarounded if not using GTK when unnecessary is so important with some new ENV variable (to make some gtk run all the time)
¹ https://github.com/ValveSoftware/steam-for-linux/issues/673#issuecomment-12244676
If You want to claim issue with libappindicator at least provide some code that trigger this "bug" (unless you are dropping absolutely everything including glib ;/)
@swiftgeek Which I don't see why it is, though what do I know
I'm responding to the "the user doesn't care what libraries the developer uses." That's true but it does not mean that Valve has sole responsibility for all behavior of everything that the user sees. To say "if you don't want to fix it" that's glossing over the fact that it isn't Valve software that is at fault. It's certainly true that Valve could try to work around libappindicator, try to fix the implementation itself or just totally ignore it and write entirely new code. Given that we have plenty of bugs in our own software we can't take on trying to work around or fix problems all around the system, we have to rely on other component owners taking action also.
work with libappindicator developers to sort it out
fix libappindicator yourself, you already bundle it
use a different library
write your own small library that does the same
possibility 5:
• facebook - maybe not raw code but the tools they are using to accelerate it
• even NDA would be enough but most people cannot just drop by to valve... (seriously the issue is this kind of annoying!)
The strange issue with this bug (as mentionned previously), is that the menu works correctly IF AND ONLY IF (in my own tests) :
If those two things are satisfied, then the menu in the system tray does not lag.
This means that if 1. or 2. is not satisfied, the menu lags.
Is this information correct for anyone else having this issue ?
I still believe this is a bug in Steam's implementation, as it works for every other app using libappindicator, and it does not lag if the two points above are "true".
Of course this is not a major issue (for example I always have my Store window opened on a virtual desktop to work around it), but considering this bug might be present on SteamOS (I haven't tested it), it could be something that would annoy future users.
As mentioned above Steam isn't a GTK app and so does not run a GTK event loop regularly and this is what is causing libappindicator problems. You are most likely comparing to GTK apps, which will not have issues.
One possible workaround is to change Steam's GTK handling and that's what will be happening in the next few months, thus the lag might improve. However, as Steam isn't a GTK app it won't necessarily always keep GTK happy. What would be preferable would be for libappindicator to work properly regardless and that is the expected behavior of libappindicator.
@gdrewb-valve
You are making valid points. However, have you taken the time to look at my two points in my previous message ? There must be a reason why the menu works correctly when those two things are safistied..
Essentially it's when the window is minimized or that the Library tab is open, then we get that lag. Otherwise, it works as expected (and it responds fasts to click / hover events)
Since you said you are going to change how GTK is used by Steam I will wait and test again when that is completed! Thanks!
The reason is what I mentioned: Steam doesn't always run a GTK event loop at full speed. When the window is minimized it doesn't and when the library page is active it doesn't.
That would explain things, thanks for the explanation!
@gdrewb-valve This is a bit out there but have you guys considered Qt? It is perhaps more appropriate for what is "not a full GTK app" (eg. the Chromium guys are considering it since Aura). And what with every other distro switching to Qt (including Ubuntu for Unity) I'm sure it'd be a welcome change.
I'm mentioning this because libappindicator is a product of Unity and I'm guessing the gtk version will be deprecated or less worked on.
@jpleau You described the bug perfectly.
Steam doesn't always run a GTK event loop at full speed.
Is there a good reason for that? It seems counterintuitive when there is a GTK-dependent graphical widget being displayed, and I can't think of a good reason to slow down a loop which would spend most of its time idle.
@jleclanche , Qt is fine but we haven't seriously looked at it as the cross-platform framework used in the client matches up best with something low level (it currently uses raw X11). That's not to say Qt couldn't work but there's no plan to switch.
@ScoreUnder , Steam's library page is handled by Steam's GUI framework and has no GTK elements, thus when it is displayed there is no need for GTK to be taking up cycles. libappindicator handles the indicator menu in a black-box way, so if it happens to be using GTK internally that's invisible to Steam (you provide a GTK menu but that's the extent of it). libappindicator has multiple implementations and fallbacks, so for example on Unity everything runs perfectly and GTK is a non-issue. In other situations it looks like GTK event pumping is more important, but again that's part of libappindicator's internal implementation and not a formal part of their API.
And what with every other distro switching to Qt
Distros are not "switching" to Qt. You probably mean desktop environments. Gtk will stay in probably every distro which is out there.
@hasufell A lot of distros (Ubuntu and so on) come with very specific desktop environments installed. Those DEs are switching or have switched to Qt. By extension, distros are switching.
@hasufell A lot of distros (Ubuntu and so on) come with very specific desktop environments installed. Those DEs are switching or have switched to Qt. By extension, distros are switching.
So no, distros are not switching. Variety is part of the linux philosophy and we will not take away sensible user choice.
This is off topic, can we please not spam everyone subscribed here.
@jpleau Thank you, from now on I'll go to the store page to start a game via the indicator...
If it's not in Steam, can't you fix it in the libappindicator?
I just wanted to report that after a beta update which I just recieve today this issue is completely gone for me. I'm on openbox using the tint2 panel.
The update I'm referring to also brings a new UI look, so you should know when you get it. (there is a blue tint around the borders of the steam client)
I've tested it with a few things like switching tabs, using STEAM_FRAME_FORCE_CLOSE both on and off, and launching games. The menu appears to remain completely responsive at all times.
The changes that I mentioned above are out now in the client beta, that's good that they seem to help. I'll wait for feedback from more people before closing this.
Confirming as well on arch / openbox / lxqt.
Thanks guys.
Confirmed on arch / awesomewm.
Thank you so much for fixing this bug in the beta. It makes Steam significantly more usable.
Works silky smooth now on Ubuntu with Awesome WM. Thanks for the fix.
Works on all my PCs. Thanks!
Ah, but it still appears to be slow if all Steam windows are minimized.
Working on Manjaro XFCE, thank you!
The lag is gone (Arch Linux + Xfce + Xfwm + Nvidia).
The lag is gone (Arch Linux + Xfce + Xfwm + Nvidia).
+1 from satan
Confirming working here too, Arch + i3 + Radeon HD 7770
Are people also seeing the behavior that @komiga notes where it is still slow when all windows are minimized (that would not be surprising since Steam tries to do less when put away)?
I can't test minimized on i3 (no minimize function), but when Steam is switched to a different workspace or swapped to the scratchpad, the tray menu still functions as expected.
In openbox/tint2, it works as expected (for me) when all visible windows are minimized.
The menu is now just as fast when all Steam windows are minimized. I'm not sure what update fixed it, but it's all nice now.
Thanks all, closing.
Prerequisite: desktop environment with regular systray (eg. xfce4, fluxbox, lxde, cinnamon)