Issue 143 in xmonad: XEvent hook or similar needed
Issue 143: XEvent hook or similar needed http://code.google.com/p/xmonad/issues/detail?id=143 Comment #11 by andrea.rossato: Spencer: yes, it's a bit more complicated (not that much I believe), still it could be done NOW - my runLayout approach has been pushed (btw, you are still the project leader, are you? it would be scary if this wouldn't be the case... but maybe you just changed you mind: I'd be delighted of that...:-) Anyway, nomeata could experiment with my event hook and see what is the needed interface. After that Spencer could decide the core implementation, if needed. I remember we had, in a far past, discussed about an event hook. At the time many ratpoisen users kept asking the possibility of sending commands to the Window Manager from the command line (for scripting purposes). I remember Spencer was contrary to adding hooks - an easy solution when you run out of ideas. I took it as a sounded guideline and I tried to follow it constantly. My attempt was to increase the expressiveness of the layout class in order to allow many hooks to be implemented in the layout hook: at first I thought about the layout combinator class - at the time it seemed to me the best solution - and then I came up with the runLayout solution, which makes the combinator class useless and indeed allows and event hook to be implemented as a layout. Joachim: attached you'll find my refined event hook patch, and ServerMode, the ratpoison command line interface, as an example. You wrote that you need to intercept ClientMessage, and ServerMode does exactly that (I think byorgey could even consider them for inclusion in the contrib library now that runLayout has been adopted). If you want to try to implement your EWMH stuff with this approach you can contact me - either privately or on IRC - and I'll be delighted to give you my help. Braden: I think you do not have a clear understanding of xmonad message handling. Messages are not consumed, they are just sent. There are 2 way of sending a message: 1. with sendMessage: the current workspace is taken from the XState, its layout field is used as an argument of handelMessage and, if a new layout is returned, the screen is refreshed and the workspace, with a new layout field and with the updated stack field, is saved in the XState. 2. with broadcastMessage: in this case the layout field of every workspace is updated without refreshing the screen. At the present time broadcastMessage is badly broken (it always has been): see issue #111. When handleMessage is called, the call may change the stack of some workspace. But since broadcastMessage is run within runOnWorkspaces, the workspace layout field is updated, but the stack of the workspace is not updated. That is to say, the stack field of the workspace before running handleMessage is used to save the XState after updating the layout field (I've discussed many times this issue, but no one seems to care). Just try with ServerMode and see what happens when you send a command that changes the stack of a workspace. You'll see the effect, but the effect will not be saved. This is obviously a general problem and a really bad and longstanding bug in the xmonad core. Implementing an EventHook as the startupHook, the logHook, the manageHook and many other hooks your imagination could come up with could be a way of forgetting about issue #111. And if you do not use decorated layouts you could even come to think that issue #111 is just the fixed idea of a psychopathic wannarebe developer who has nothing better to do. But this is out of the scope of this feature request. Attachments: eventHook_patches.dpatch 55.8 KB -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings
Hi Andrea, I just found some free time to try your patches, but it seems that your comments in the google bts were deleted. Was that a mistake? And where can I find your patches now? I also can’t find your repositories http://gorgias.mine.nu/repos/xmonad/ http://gorgias.mine.nu/repos/xmonad-contrib/ any more. Greetings, Joachim Am Donnerstag, den 13.03.2008, 05:03 -0700 schrieb codesite-noreply@google.com:
Issue 143: XEvent hook or similar needed http://code.google.com/p/xmonad/issues/detail?id=143
Comment #11 by andrea.rossato: Spencer: yes, it's a bit more complicated (not that much I believe), still it could be done NOW - my runLayout approach has been pushed (btw, you are still the project leader, are you? it would be scary if this wouldn't be the case... but maybe you just changed you mind: I'd be delighted of that...:-)
Anyway, nomeata could experiment with my event hook and see what is the needed interface. After that Spencer could decide the core implementation, if needed.
I remember we had, in a far past, discussed about an event hook. At the time many ratpoisen users kept asking the possibility of sending commands to the Window Manager from the command line (for scripting purposes). I remember Spencer was contrary to adding hooks - an easy solution when you run out of ideas. I took it as a sounded guideline and I tried to follow it constantly.
My attempt was to increase the expressiveness of the layout class in order to allow many hooks to be implemented in the layout hook: at first I thought about the layout combinator class - at the time it seemed to me the best solution - and then I came up with the runLayout solution, which makes the combinator class useless and indeed allows and event hook to be implemented as a layout.
Joachim: attached you'll find my refined event hook patch, and ServerMode, the ratpoison command line interface, as an example. You wrote that you need to intercept ClientMessage, and ServerMode does exactly that (I think byorgey could even consider them for inclusion in the contrib library now that runLayout has been adopted).
If you want to try to implement your EWMH stuff with this approach you can contact me - either privately or on IRC - and I'll be delighted to give you my help.
Braden: I think you do not have a clear understanding of xmonad message handling. Messages are not consumed, they are just sent. There are 2 way of sending a message:
1. with sendMessage: the current workspace is taken from the XState, its layout field is used as an argument of handelMessage and, if a new layout is returned, the screen is refreshed and the workspace, with a new layout field and with the updated stack field, is saved in the XState.
2. with broadcastMessage: in this case the layout field of every workspace is updated without refreshing the screen. At the present time broadcastMessage is badly broken (it always has been): see issue #111. When handleMessage is called, the call may change the stack of some workspace. But since broadcastMessage is run within runOnWorkspaces, the workspace layout field is updated, but the stack of the workspace is not updated. That is to say, the stack field of the workspace before running handleMessage is used to save the XState after updating the layout field (I've discussed many times this issue, but no one seems to care).
Just try with ServerMode and see what happens when you send a command that changes the stack of a workspace. You'll see the effect, but the effect will not be saved.
This is obviously a general problem and a really bad and longstanding bug in the xmonad core. Implementing an EventHook as the startupHook, the logHook, the manageHook and many other hooks your imagination could come up with could be a way of forgetting about issue #111. And if you do not use decorated layouts you could even come to think that issue #111 is just the fixed idea of a psychopathic wannarebe developer who has nothing better to do.
But this is out of the scope of this feature request.
Attachments: eventHook_patches.dpatch 55.8 KB
-- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org
Joachim, if you can revive this, and polish it up into something you can use, please do. -- Don mail:
Hi Andrea,
I just found some free time to try your patches, but it seems that your comments in the google bts were deleted. Was that a mistake? And where can I find your patches now?
I also can’t find your repositories http://gorgias.mine.nu/repos/xmonad/ http://gorgias.mine.nu/repos/xmonad-contrib/ any more.
Greetings, Joachim
Am Donnerstag, den 13.03.2008, 05:03 -0700 schrieb codesite-noreply@google.com:
Issue 143: XEvent hook or similar needed http://code.google.com/p/xmonad/issues/detail?id=143
Comment #11 by andrea.rossato: Spencer: yes, it's a bit more complicated (not that much I believe), still it could be done NOW - my runLayout approach has been pushed (btw, you are still the project leader, are you? it would be scary if this wouldn't be the case... but maybe you just changed you mind: I'd be delighted of that...:-)
Anyway, nomeata could experiment with my event hook and see what is the needed interface. After that Spencer could decide the core implementation, if needed.
I remember we had, in a far past, discussed about an event hook. At the time many ratpoisen users kept asking the possibility of sending commands to the Window Manager from the command line (for scripting purposes). I remember Spencer was contrary to adding hooks - an easy solution when you run out of ideas. I took it as a sounded guideline and I tried to follow it constantly.
My attempt was to increase the expressiveness of the layout class in order to allow many hooks to be implemented in the layout hook: at first I thought about the layout combinator class - at the time it seemed to me the best solution - and then I came up with the runLayout solution, which makes the combinator class useless and indeed allows and event hook to be implemented as a layout.
Joachim: attached you'll find my refined event hook patch, and ServerMode, the ratpoison command line interface, as an example. You wrote that you need to intercept ClientMessage, and ServerMode does exactly that (I think byorgey could even consider them for inclusion in the contrib library now that runLayout has been adopted).
If you want to try to implement your EWMH stuff with this approach you can contact me - either privately or on IRC - and I'll be delighted to give you my help.
Braden: I think you do not have a clear understanding of xmonad message handling. Messages are not consumed, they are just sent. There are 2 way of sending a message:
1. with sendMessage: the current workspace is taken from the XState, its layout field is used as an argument of handelMessage and, if a new layout is returned, the screen is refreshed and the workspace, with a new layout field and with the updated stack field, is saved in the XState.
2. with broadcastMessage: in this case the layout field of every workspace is updated without refreshing the screen. At the present time broadcastMessage is badly broken (it always has been): see issue #111. When handleMessage is called, the call may change the stack of some workspace. But since broadcastMessage is run within runOnWorkspaces, the workspace layout field is updated, but the stack of the workspace is not updated. That is to say, the stack field of the workspace before running handleMessage is used to save the XState after updating the layout field (I've discussed many times this issue, but no one seems to care).
Just try with ServerMode and see what happens when you send a command that changes the stack of a workspace. You'll see the effect, but the effect will not be saved.
This is obviously a general problem and a really bad and longstanding bug in the xmonad core. Implementing an EventHook as the startupHook, the logHook, the manageHook and many other hooks your imagination could come up with could be a way of forgetting about issue #111. And if you do not use decorated layouts you could even come to think that issue #111 is just the fixed idea of a psychopathic wannarebe developer who has nothing better to do.
But this is out of the scope of this feature request.
Attachments: eventHook_patches.dpatch 55.8 KB
-- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
Hi,
Hi Andrea,
I just found some free time to try your patches, but it seems that your comments in the google bts were deleted. Was that a mistake? And where can I find your patches now?
I also can’t find your repositories http://gorgias.mine.nu/repos/xmonad/ http://gorgias.mine.nu/repos/xmonad-contrib/ any more.
Greetings, Joachim
Am Sonntag, den 16.03.2008, 15:44 -0700 schrieb Don Stewart:
Joachim, if you can revive this, and polish it up into something you can use, please do.
That’s what I was just trying to do (well, I was hoping not to do any polishing outside EWMH :-), but I just can’t find Andrea’s event hook patches anywhere, so I’m stuck. How come Andrea’s comments are not in the bug tracking system any more? Greetings, Joachim
Am Donnerstag, den 13.03.2008, 05:03 -0700 schrieb codesite-noreply@google.com:
Issue 143: XEvent hook or similar needed http://code.google.com/p/xmonad/issues/detail?id=143
Comment #11 by andrea.rossato: Spencer: yes, it's a bit more complicated (not that much I believe), still it could be done NOW - my runLayout approach has been pushed (btw, you are still the project leader, are you? it would be scary if this wouldn't be the case... but maybe you just changed you mind: I'd be delighted of that...:-)
Anyway, nomeata could experiment with my event hook and see what is the needed interface. After that Spencer could decide the core implementation, if needed.
I remember we had, in a far past, discussed about an event hook. At the time many ratpoisen users kept asking the possibility of sending commands to the Window Manager from the command line (for scripting purposes). I remember Spencer was contrary to adding hooks - an easy solution when you run out of ideas. I took it as a sounded guideline and I tried to follow it constantly.
My attempt was to increase the expressiveness of the layout class in order to allow many hooks to be implemented in the layout hook: at first I thought about the layout combinator class - at the time it seemed to me the best solution - and then I came up with the runLayout solution, which makes the combinator class useless and indeed allows and event hook to be implemented as a layout.
Joachim: attached you'll find my refined event hook patch, and ServerMode, the ratpoison command line interface, as an example. You wrote that you need to intercept ClientMessage, and ServerMode does exactly that (I think byorgey could even consider them for inclusion in the contrib library now that runLayout has been adopted).
If you want to try to implement your EWMH stuff with this approach you can contact me - either privately or on IRC - and I'll be delighted to give you my help.
Braden: I think you do not have a clear understanding of xmonad message handling. Messages are not consumed, they are just sent. There are 2 way of sending a message:
1. with sendMessage: the current workspace is taken from the XState, its layout field is used as an argument of handelMessage and, if a new layout is returned, the screen is refreshed and the workspace, with a new layout field and with the updated stack field, is saved in the XState.
2. with broadcastMessage: in this case the layout field of every workspace is updated without refreshing the screen. At the present time broadcastMessage is badly broken (it always has been): see issue #111. When handleMessage is called, the call may change the stack of some workspace. But since broadcastMessage is run within runOnWorkspaces, the workspace layout field is updated, but the stack of the workspace is not updated. That is to say, the stack field of the workspace before running handleMessage is used to save the XState after updating the layout field (I've discussed many times this issue, but no one seems to care).
Just try with ServerMode and see what happens when you send a command that changes the stack of a workspace. You'll see the effect, but the effect will not be saved.
This is obviously a general problem and a really bad and longstanding bug in the xmonad core. Implementing an EventHook as the startupHook, the logHook, the manageHook and many other hooks your imagination could come up with could be a way of forgetting about issue #111. And if you do not use decorated layouts you could even come to think that issue #111 is just the fixed idea of a psychopathic wannarebe developer who has nothing better to do.
But this is out of the scope of this feature request.
Attachments: eventHook_patches.dpatch 55.8 KB
-- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
-- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org
* Joachim Breitner <mail@joachim-breitner.de> [2008-03-16 23:40:13+0100]
Hi Andrea,
I just found some free time to try your patches, but it seems that your comments in the google bts were deleted. Was that a mistake? And where can I find your patches now?
I also can’t find your repositories http://gorgias.mine.nu/repos/xmonad/ http://gorgias.mine.nu/repos/xmonad-contrib/ any more.
Greetings, Joachim
Also I'm not sure that Andrea reads this list. Try to send him a copy. -- Roman I. Cheplyaka (aka Feuerbach @ IRC)
participants (4)
-
codesite-noreply＠google.com -
Don Stewart -
Joachim Breitner -
Roman Cheplyaka