Skip to content
This repository was archived by the owner on May 3, 2023. It is now read-only.

Conversation

@samstokes
Copy link
Contributor

Prior to this change, on my Linux machine (XUbuntu + XMonad), Thyme would report all open windows as visible, even windows on other virtual desktops. Reporting those windows as "visible" doesn't match the colloquial definition, and also seems to go against the intended use case.

This checks the current desktop via wmctrl -d and then filters out windows on other desktops from the visible list.

Prior to this change, on my Linux machine (XUbuntu + XMonad), Thyme
would report all open windows as visible, even windows on other virtual
desktops.  Reporting those windows as "visible" doesn't match the
colloquial definition, and also seems to go against the intended use
case.

This checks the current desktop via `wmctrl -d` and then filters out
windows on other desktops from the visible list.
@giodamelio
Copy link

This is not working for me on AwesomeWM. It still lists all the windows as being visible.

@exekias
Copy link

exekias commented Aug 17, 2016

I've opened #24, works for me in i3

@exekias
Copy link

exekias commented Aug 17, 2016

My solution doesn't work in Unity, probably a mix of both would be best

@samstokes
Copy link
Contributor Author

@exekias FWIW, I tried compiling from your branch, and your xwininfo approach does work on my XMonad setup. I haven't tested mine in Unity though.

@exekias
Copy link

exekias commented Aug 17, 2016

Good to know @samstokes, will check Unity to see if I can get something there

@The-Compiler
Copy link

The-Compiler commented Aug 17, 2016

This doesn't seem to work on herbstluftwm either.

I have a gedit window on workspace 9 which isn't visible.

It's shown as visible by thyme (installed via go get -u github.com/samstokes/thyme/cmd/thyme):

$ ./bin/thyme track
{
  "Time": "2016-08-17T20:52:00.507689849+02:00",
    [...]
    {
      "ID": 62914808,
      "Name": "Untitled Document 1 - gedit"
    }
  ],
  "Active": 35651865,
  "Visible": [
    [...]
    62914808
  ]
}

wmctrl -d correctly shows that I'm on workspace 1:

$ wmctrl -d
0  * DG: N/A  VP: 0,18446744072057421568  WA: N/A  1
1  - DG: N/A  VP: N/A                     WA: N/A  2
2  - DG: N/A  VP: N/A                     WA: N/A  3
3  - DG: N/A  VP: N/A                     WA: N/A  4
4  - DG: N/A  VP: N/A                     WA: N/A  5
5  - DG: N/A  VP: N/A                     WA: N/A  6
6  - DG: N/A  VP: N/A                     WA: N/A  7
7  - DG: N/A  VP: N/A                     WA: N/A  8
8  - DG: N/A  VP: N/A                     WA: N/A  9

And wmctrl -l shows its workspace correctly:

$ wmctrl -l
[...]
0x03c000f8  8 ginny Untitled Document 1 - gedit

@beyang
Copy link
Member

beyang commented Aug 18, 2016

Given that different windowing systems appear to have different criteria for determining "visible" (at least as far as the output from wmctrl is concerned), perhaps the best solution is to have different implementations of Tracker for each. The windowing system can be detected in getTracker() (there must be a way to detect this by shelling out to some command) and the correct Tracker implementation can be returned.

This way we don't have to worry about breaking Thyme for people using other Linux windowing systems.

Also, thanks for all of these attempts at fixing this bug!

@samstokes
Copy link
Contributor Author

I agree it could make sense to add WM-specific code. Looks like you can detect the name reported by the window manager via wmctrl -m, e.g.:

sam@kobold:~$ wmctrl -m
Name: LG3D
Class: N/A
PID: N/A
Window manager's "showing the desktop" mode: N/A

(N.B. it's possible for the WM to lie, for example with XMonad it's common to set the WM name to "LG3D" as above to trick some Java-based applications into rendering correctly.)

However, from @The-Compiler's report I'm not sure why my patch doesn't work for them. All I do is parse wmctrl -l and wmctrl -d and check if the window's desktop had a star next to it, so from the sample output, it should do the right thing.

I'm not very familiar with Go so it's entirely possible I made a silly mistake in the implementation. Would anyone be able to sanity-check my code?

@beyang
Copy link
Member

beyang commented Sep 5, 2016

This works on Unity and on second look, it seems like it would not break any functionality on currently supported window managers. So merging. Thanks for submitting this!

@beyang beyang merged commit 5045e65 into sourcegraph:master Sep 5, 2016
@The-Compiler
Copy link

I just tried the latest master again with herbstluftwm, and it seems to run fine - so no idea what went wrong when I tested last time. Thanks and sorry for the noise! 😉

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants