No, since #3658 refers to missing WM_CLASS property only for Update
window. All others do have it:
$ xprop | grep -i class
WM_CLASS(STRING) = "Steam", "Steam"
This bug says that the class property isn't set and as you point out the only place it isn't set is for update so I was guessing that's where the report was referring to.
This was what I reported. Although, this bug report may appear invalid,
since most windows created by Steam Client App do have WM_CLASS
property, both in release and beta. Hope I clarified that
a) this bug report requires more info provided by the OP;
b) this bug report is not a dup of #3658.
Cheers!
as far as i can tell it is similar to 3658, except not a single one of the steam windows will go to the workspace i want it to go. they always open up in the current workspace.
edit: they also will not go to the correct workspace if i use window title either.
if there is anything i can get you to help out, let me know.
You'll probably also want to ask around on compiz forums as your problem is not necessarily Steam related. The class name is set and should be usable, and as you report that the window title isn't working either it seems like it's possible the problem lies elsewhere.
i would have thought the same thing if any of the other programs i have going to specific workspaces did the same thing steam did. a cursory search on google shows several other people with the same problem where steam just wont go to the correct workspace.
Nothing extracted yet.
I have been attempting to set up steam to automatically load in a different workspace, but it will not. i usually use 'class name' in the compiz config to move it automatically, but it seems like steam doesnt have the class set.