Hello everyone,
I am a newcomer, and I have been playing for some time with xmonad.
I've been (well, and I still am) an fvwm user for quite a long time. But
xmonad seems to have an excellent support for xinerama. That alone is enough
to pick my attention, since no other wm that I know of has a proper support
for xinerama, even if lots of them claim to.
I have a mostly working setup now, though there's a lot of room for
improvements, and being new to haskell is not helping (the time will cure
that, though).
What I am after right now is for ideas about how to handle multiple
instances of firefox. My idea is to launch a firefox instance on startup
on a given workspace. But, I don't want all the firefox instances to be
open on that workspace (for example, if I click an url on sylpheed I want
it to be opened on a firefox window on the same workspace I am right at that
moment).
My current approach, right now, is to launch everything from my .xinitrc,
and then I have manageHook on my xmonad.hs file to W.shift the firefox
window to workspace 2. The problem is that, this method, effectively
shifts ALL the firefox windows to that workspace, which means that if I
click an url on sylpheed on workspace 3, then I have to go to workspace 2
to be able to see the firefox window containing the page associated to the
url I just clicked on sylpheed.
I don't know if the manageHook approach is correct. Maybe there's a way to
send the firefox instance I open at startup to workspace 2 without a hook.
I use something similar to manage some urxvt's I have for different
purposes, but the hooks approach there works just ok because terminals
usually have a way to change it's resource/class name, which makes matching
windows much easier. Firefox doesn't have this capability as far as I know,
that's why if I match firefox, it matches all the firefox windows, which
is not the intended effects.
I can't believe I am the first one to have such a problem, but I haven't
found anything though I have looked on many places (including the mailing
list archives).
For now, I just work around it using another browser as the associated
browser on syplheed and urxvt and floating the links windows.
Ideas and guidance is welcome.
Thanks everyone for reading.
Cheer.
--
Jesús Guerrero
* On Wednesday, June 11 2008, Jesús Guerrero wrote:
My current approach, right now, is to launch everything from my .xinitrc, and then I have manageHook on my xmonad.hs file to W.shift the firefox window to workspace 2. The problem is that, this method, effectively shifts ALL the firefox windows to that workspace, which means that if I
That is the point of the manageHook: windows go where they belong, no matter when you start them.
click an url on sylpheed on workspace 3, then I have to go to workspace 2 to be able to see the firefox window containing the page associated to the url I just clicked on sylpheed.
So you can either somehow run firefox with a different class (and match to that), but I don't know how, without using a function from xlib to do that: XSetClassHint(). An it isn't supposed to be used like that. Or you can scrap the manageHook and let firefox start on the currently visible workspace, which is pretty close to what you want anyways?
On Thu, 12 Jun 2008 15:54:20 -0400
Adam Vogt
So you can either somehow run firefox with a different class (and match to that), but I don't know how, without using a function from xlib to do that: XSetClassHint(). An it isn't supposed to be used like that.
Indeed -- and this is wrong. Older versions of Firefox used to have a --gtk-class flag which would allow you to change the Class of the window before it is mapped [1] for just this purpose, but it seems to have been removed. [1] The Class of a window is only allowed to be changed in the WithDrawn state, hence why you can't change it with xprop whilst it is mapped. This is in accordance with the ICCCM2. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci.
Hello, Adam,
On Thu, 12 Jun 2008 15:54:20 -0400
Adam Vogt
* On Wednesday, June 11 2008, Jesús Guerrero wrote:
My current approach, right now, is to launch everything from my .xinitrc, and then I have manageHook on my xmonad.hs file to W.shift the firefox window to workspace 2. The problem is that, this method, effectively shifts ALL the firefox windows to that workspace, which means that if I
That is the point of the manageHook: windows go where they belong, no matter when you start them.
I know. The problem is that I only want to send to workspace 2 the first instance, which is the one I launch from my .xinitrc. See below...
click an url on sylpheed on workspace 3, then I have to go to workspace 2 to be able to see the firefox window containing the page associated to the url I just clicked on sylpheed.
So you can either somehow run firefox with a different class (and match to that), but I don't know how, without using a function from xlib to do that: XSetClassHint(). An it isn't supposed to be used like that.
Well, firefox has a whole plethora of problems. Let alone the whole mass of child windows it creates for one or another purpose. I think we would need a whole layout just for it or something. The big problem is that all the children are "Firefox" or "Firefox-bin" depending on your distro and firerox version. You can match by title or resource, which is a real pain, because there's something called "localization", not to speak about the wonderful title changes that are tipical on a web browser. I don't think i'ts possible to change the firefox WM_CLASS without hacking a bit either. But I digress and this is anyway a different issue (as I said, firefox has lots of them). The original purpose of my original post was to find a better way to launch a firefox instance at workspace 2, without forcing the rest of firefox instances to be shifted to that workspace. I used manageHook because I don't have any other thing in my xmonad toolbox right now, but as I said, I doubt that's the correct way for what I intend.
Or you can scrap the manageHook and let firefox start on the currently visible workspace, which is pretty close to what you want anyways?
Yep. I can just erase the manageHook reference to firefox, yet one problem
remains: how to launch firefox at workspace 2 when I startx. Not that it's
a critical problem. I just was wondering if there's some way to do so. I just
wanted to know if there's a way to do so on xmonad. I am pretty new to this
stuff. If there is not, then I suppose I can open it myself, it's not a big
deal.
And, a bit off-topic, but related still: is there a way to tell xmonad
the desired size and position for a floated window?
Thanks for your response :)
--
Jesús Guerrero
On 2008 Jun 12, at 16:21, Jesús Guerrero wrote:
The original purpose of my original post was to find a better way to launch a firefox instance at workspace 2, without forcing the rest of firefox instances to be shifted to that workspace. I used manageHook because I don't have any other thing in my xmonad toolbox right now, but as I said, I doubt that's the correct way for what I intend.
Hm, does the ManageHook have a way to inspect the current set of windows? It should be possible to check if there is another firefox window, and if not then move the current one to workspace 2. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
On Thu, Jun 12, 2008 at 09:16:44PM -0400, Brandon S. Allbery KF8NH wrote:
On 2008 Jun 12, at 16:21, Jesús Guerrero wrote:
The original purpose of my original post was to find a better way to launch a firefox instance at workspace 2, without forcing the rest of firefox instances to be shifted to that workspace. I used manageHook because I don't have any other thing in my xmonad toolbox right now, but as I said, I doubt that's the correct way for what I intend.
Hm, does the ManageHook have a way to inspect the current set of windows? It should be possible to check if there is another firefox window, and if not then move the current one to workspace 2.
A hokier but simpler approach (if you plan on always leaving a firefox window open on workspace 2) would be to simply check if there are any windows in workspace 2. This is nice because it's a pure function of state (i.e. doesn't require any calling out to examine windows). But I can't say precisely how to implement it, as I haven't ever created a ManageHook (and am not looking at the code just now). -- David Roundy Department of Physics Oregon State University
On Thu, Jun 12, 2008 at 06:22:02PM -0700, David Roundy wrote:
A hokier but simpler approach (if you plan on always leaving a firefox window open on workspace 2) would be to simply check if there are any windows in workspace 2.
So, in addition to this approach, I can think of two others: 1. startupHook is run just after windows have been mapped (see the definition of xmonad in XMonad/Main.hsc), so you can check for any existing Firefox windows there and only there. At that point, you could either iterate over all windows and runQuery a special ManageHook that's not part of your usual manageHook, or use XMonad.Util.WindowProperties. (I'm not sure which is better.) 2. The cooler (but much harder) option would be something like XMonad.Hooks.ServerMode. You'd establish an EventHook that listened for a "shift-to-workspace" ClientMessageEvent. Then, you'd write a custom X11 client that looked up the Firefox window and sent the appropriate ClientMessage to the root window. Ideally, this could be generalized to something I've wanted to see: a `float` command that ran $*, tracked all of the windows it spawned, and asked xmonad to float them. (I'm not sure if that's possible, though. And, yes, I know you didn't want to float. I'm digressing.) Disclaimer: I may be on crack.
On Thu, 12 Jun 2008 21:55:40 -0700
Devin Mullins
On Thu, Jun 12, 2008 at 06:22:02PM -0700, David Roundy wrote:
A hokier but simpler approach (if you plan on always leaving a firefox window open on workspace 2) would be to simply check if there are any windows in workspace 2.
So, in addition to this approach, I can think of two others:
1. startupHook is run just after windows have been mapped (see the definition of xmonad in XMonad/Main.hsc), so you can check for any existing Firefox windows there and only there. At that point, you could either iterate over all windows and runQuery a special ManageHook that's not part of your usual manageHook, or use XMonad.Util.WindowProperties. (I'm not sure which is better.)
I will investigate this. With a bit of research I think this is doable (as in "doable by me").
2. The cooler (but much harder) option would be something like XMonad.Hooks.ServerMode. You'd establish an EventHook that listened for a "shift-to-workspace" ClientMessageEvent. Then, you'd write a custom X11 client that looked up the Firefox window and sent the appropriate ClientMessage to the root window.
Ideally, this could be generalized to something I've wanted to see: a `float` command that ran $*, tracked all of the windows it spawned, and asked xmonad to float them. (I'm not sure if that's possible, though. And, yes, I know you didn't want to float. I'm digressing.)
Although I understand it at conceptual level, I have zero haskell background,
so, I will leave advanced drugs for a later stage :P For now, I have enough
pain just trying to configure xmonad to do that I want it to do.
Thanks for all the feedback, it's been really helpful. :)
--
Jesús Guerrero
Devin Mullins
On Thu, Jun 12, 2008 at 06:22:02PM -0700, David Roundy wrote:
A hokier but simpler approach (if you plan on always leaving a firefox window open on workspace 2) would be to simply check if there are any windows in workspace 2.
So, in addition to this approach, I can think of two others:
1. startupHook is run just after windows have been mapped (see the definition of xmonad in XMonad/Main.hsc), so you can check for any existing Firefox windows there and only there. At that point, you could either iterate over all windows and runQuery a special ManageHook that's not part of your usual manageHook, or use XMonad.Util.WindowProperties. (I'm not sure which is better.)
2. The cooler (but much harder) option would be something like XMonad.Hooks.ServerMode. You'd establish an EventHook that listened for a "shift-to-workspace" ClientMessageEvent. Then, you'd write a custom X11 client that looked up the Firefox window and sent the appropriate ClientMessage to the root window.
Ideally, this could be generalized to something I've wanted to see: a `float` command that ran $*, tracked all of the windows it spawned, and asked xmonad to float them. (I'm not sure if that's possible, though. And, yes, I know you didn't want to float. I'm digressing.)
Disclaimer: I may be on crack.
maybe an other solution would be using the "session manager" of some desktop env such as XFCE, that lanch apps at starting on a given workspace. You should need XMonad.Hooks.EwmhDesktops. See http://haskell.org/haskellwiki/Xmonad/Using_xmonad_in_XFCE -- Guillaume Pinot http://www.irccyn.ec-nantes.fr/~pinot/ ``Computers are good at following instructions, but not at reading your mind.'' -- Donald E. Knuth, the TeXbook () ASCII ribbon campaign -- Against HTML e-mail /\ http://www.asciiribbon.org -- Against proprietary attachments
Jesús Guerrero wrote:
And, a bit off-topic, but related still: is there a way to tell xmonad the desired size and position for a floated window?
Using a ManageHook, indeed yes. This will work only when the window is spawned, of course, since that's the only time ManageHooks are called. XMonad.Hooks.ManageHelpers contains a function called doRectFloat. It works like the core doFloat ManageHook, but you specify an XMonad.StackSet.RationalRect to give its position and size as a fraction of the screen size. For an example, see XMonad.Util.Scratchpad, the module for which I wrote doRectFloat. Braden Shepherdson shepheb
On Fri, 13 Jun 2008 00:44:28 -0400
Braden Shepherdson
Jesús Guerrero wrote:
And, a bit off-topic, but related still: is there a way to tell xmonad the desired size and position for a floated window?
Using a ManageHook, indeed yes. This will work only when the window is spawned, of course, since that's the only time ManageHooks are called.
XMonad.Hooks.ManageHelpers contains a function called doRectFloat. It works like the core doFloat ManageHook, but you specify an XMonad.StackSet.RationalRect to give its position and size as a fraction of the screen size.
For an example, see XMonad.Util.Scratchpad, the module for which I wrote doRectFloat.
That's exactly what I needed, wonderful. After a couple of minutes I got it.
For example:
myManageHook = composeAll
[ [...snip...]
, resource =? "alsamixer" --> doRectFloat alsamixerRect
[...snip...]
where
alsamixerRect = W.RationalRect 0.8 0.0 0.2 0.3
Perfect for my needs. I have some more questions but I will look around a bit
more before spamming the lists. Thanks for all the assistance.
--
Jesús Guerrero
participants (8)
-
Adam Vogt -
Braden Shepherdson -
Brandon S. Allbery KF8NH -
David Roundy -
Devin Mullins -
Jesús Guerrero -
TeXitoi -
Thomas Adam