Re: [xmonad] Regarding X.A.GroupNavigation
Raghavendra D Prabhu [2012.10.22 0327 +0530]:
Hi,
I am using one of your Xmonad extensions - X.A.GroupNavigation.
I needed something like ability to toggle between alternate windows like toggleWS which is for workspaces.
However,
, ((modm , xK_BackSpace), nextMatch History (return True))
didn't work for me since I wanted it to toggle within the workspace.
So, I tried
.... nextMatchWithThis History currentWs)
But this is not working for me. Do you know why that may be the case? (currentWs from ManageHelpers).
My loghook is as follows:
logHook = fadeWindowsLogHook myFadeHook <+> myLogHook xmproc <+> G.historyHook
The reason why this doesn't work is simple: currentWs returns the current workspace. nextMatchWithThis focuses the next window for which the given query returns the same result as for the current window. Since currentWs is independent of the given window, nextMatchWithThis History currentWs should produce the exact same effect as nextMatch History (return True), as long as there currently is a focused window. The answer probably a bit more interesting to you is: can what you want to do be done? Of course it can ;) but not out of the box it seems. What you need is a query that returns the workspace a given window is on. As far as I can tell, there is is no such query provided in ManageHelpers, and it is certainly not provided as part of GroupNavigation. Cheers, Norbert
Hi,
* On Sun, Oct 21, 2012 at 08:06:45PM -0300, Norbert Zeh
Raghavendra D Prabhu [2012.10.22 0327 +0530]:
Hi,
I am using one of your Xmonad extensions - X.A.GroupNavigation.
I needed something like ability to toggle between alternate windows like toggleWS which is for workspaces.
However,
, ((modm , xK_BackSpace), nextMatch History (return True))
didn't work for me since I wanted it to toggle within the workspace.
So, I tried
.... nextMatchWithThis History currentWs)
But this is not working for me. Do you know why that may be the case? (currentWs from ManageHelpers).
My loghook is as follows:
logHook = fadeWindowsLogHook myFadeHook <+> myLogHook xmproc <+> G.historyHook
The reason why this doesn't work is simple: currentWs returns the current workspace. nextMatchWithThis focuses the next window for which the given query returns the same result as for the current window. Since currentWs is independent of the given window, nextMatchWithThis History currentWs should produce the exact same effect as nextMatch History (return True), as long as there currently is a focused window.
The answer probably a bit more interesting to you is: can what you want to do be done? Of course it can ;) but not out of the box it seems. What you need is a query that returns the workspace a given window is on. As far as I can tell, there is is no such query provided in ManageHelpers, and it is certainly not provided as part of GroupNavigation.
Cheers, Norbert
Thank you. I think my confusion stemmed from fact that currentWs had nearly the same signature as className, appName and other helpers in ManageHook. It would be nice to have a workspace delimited navigation in GroupNavigation. Regarding returning the workspace id of a window, I don't see it maintained by X (not atleast from Xorg); though I wonder if there is a way for xmonad to return that (or intercept request like EWMH module does). Thanks again. Regards, -- Raghavendra Prabhu GPG Id : 0xD72BE977 Fingerprint: B93F EBCB 8E05 7039 CD3C A4B8 A616 DCA1 D72B E977 www: wnohang.net
On Thu, Oct 25, 2012 at 5:33 PM, Raghavendra D Prabhu < raghu.prabhu13@gmail.com> wrote:
Regarding returning the workspace id of a window, I don't see it maintained by X (not atleast from Xorg);
Workspaces do not exist at the X11 level; they're an implementation detail of the window manager, and the only standard concerning them is opendesktop.org's EWMH. You won't find any X11 or Xorg calls that know anything about them. xmonad's workspaces exist as part of the StackSet. At the time a window goes through the ManageHook, it is on the current workspace; any attempt to specify the current workspace before that will fail because it's not yet part of the StackSet (that is, the ManageHook executes as the window is being added to the StackSet, and as a result it will be on the current workspace when the ManageHook executes). So, while you can easily query the StackSet to see where the window is, there's no real point in doing so. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net
participants (3)
-
Brandon Allbery -
Norbert Zeh -
Raghavendra D Prabhu