-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Nathaniel, On 09.01.2012 02:15, Nathaniel Filardo wrote:

Would it be possible to rework this to avoid looping around the X event stream? Not with this form of generalization.

IMHO it would be nicer if it updated its internal state and then let the main event loop dispatch events its way. If you do it that way, you cannot cycle over your workspaces. It would be effectively a key for toggling your last viewed workspace, due to the way XMonad updates its internal Workspace list. E.g. workspaces: current: 0, others: [1,2,3,4] view $ head others: current 1, others: [0,2,3,4] view $ head others: current 0, others: [1,2,3,4], etc. If you want to cycle you have to preserve the state of the initial list.

Modules creating their own event loops just doesn't seem right (and in the case of XMonad.Prompt causes usability problems for me where I will start filling out a prompt and then want to change focus before finishing). First of, XMonad takes Events from the X event queue in a single threaded event based loop. Reading from the event queue and processing the events our specific function is interested in should normally cause no harm since we are still within the X state monad without concurrency.

Furthermore, events we are not interested in lead to an immediate break of the function and are put back into the event queue (putBackEvent) so nothing is lost. In general, there are currently two ways I see how to accomplish this recent workspace cycling problem. I've tried them both and opted for this method, I'll give you the reasons later. The first method would be to use Extensible State. This allows to store a Show- and Tybeable -able Type in the X Monad, which means that anything that contains layouts (LayoutClass), like Screens, Workspaces or WindowSets is out. You can do this by saving a list of tags (Strings) and use this list for cycling. Pros: * no need to read events from x event queue Cons: * limited to types which are (at least) Show and Typeable, Read would be preferrable * without Read there is no PersistentState, so your Workspace cycling order is lost on restarts * not a general solution, rather a very specific one The other solution is what I did. Keeping a state myself in the function loop, thus unlimited on the type. The state is retrieved from the X state monad *once* and then passed through. So every time we apply a function for altering the state it is done with the initial state. Since this is a functional programming language there is no such thing as a global state, only what you pass either from one function to the other or in the case of XMonad in the outer event loop (which is just function itself. But you cannot declare your own state in a module and have it globally available. Pros: * general solution, unlimited on types, does no harm to the x event loop (afais) cons: own event processing Now this is a rather long read and I apologize for that. However, I hope that I clearly pointed out, that there are only two possibilities to implement this and why I've chosen the current implementation. Best Wishes, Jochen

Thanks. --nwf;

On Sun, Jan 8, 2012 at 6:07 AM, Jochen Keil wrote: Hi,

my last version of CycleRecentWS.hs had a small logical bug. I added the current ws to the end of the list but it should go to the head. This makes also the somewhat strange +/-2 on secondary modifier keypress superfluous. I also thought about getting rid of passive grab but the problem is that we stay in the recursive loop if we don't exit on the keyrelease event by the grabbed modifier. This shouldn't be a problem normally, because when you press another modifier + key combination we'll terminate the loop. It can however lead to unexpected behavior when releasing the modifier and then pressing it again so that the loop stays active thus cycling over the (old and possibly not desired) state again.

Best Regards,

Jochen

On 07.01.2012 23:32, Jochen Keil wrote:

...

...

...

Dear list,

after struggling for a while the XMonad.Actions.CycleRecentWS contrib module, mainly because it actively grabs the whole keyboard (and thus breaks various functionality, e.g. switching the layout on the fly), I took the time to rewrite this module. It now does not actively grab the whole keyboard anymore but relies only on one passive grab. I imagine this could be done even more generally, but I am pretty satisfied with how it works now. However, since theres always room for improvement new ideas are always welcome. :)

I've included another module which helps to setup up a passive grab on a certain key. Configuration is a bit (tr)icky, but I hope not too troublesome.

Best regards,

Jochen

_______________________________________________ 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

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk8KxMcACgkQtVwvsA+W4CB1MACeNA0iLHCxdoDoIBxpwez0JyXr ZgsAoJ002iSKjJRsJ1vVMexrVqbxYned =BBmJ -----END PGP SIGNATURE-----