1 Oct 2009 21:18
1 Oct 2009 21:51
1 Oct 2009 22:03
1 Oct 2009 22:24
Issue 177 in xmonad: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol
Comment #13 on issue 177 by f.luithle: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol http://code.google.com/p/xmonad/issues/detail?id=177 Why is this not accepted over a year later? This defect renders Netbeans, for example, rather unusuable under XMonad, especially if you want to use the jVi plugin with it. This should have high priority to get into the next release. -- 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
1 Oct 2009 22:26
Re: [patch] WorkspaceByPos
I've applied the original patch., and my translation to use ErrorT. It seems to work as the original. Thanks, Adam * On Wednesday, September 30 2009, Adam Vogt wrote: >* On Wednesday, September 30 2009, Jan Vornberger wrote: > >>Hi there! >> >>I would like to ask for some comments/tips for improvements on the >>attached patch. >> >>It probably could use the Maybe monad to avoid all those if/thens, but >>I'm still a little bit unsure when it comes to using two monads at the >>same time (here the X monad and the Maybe monad). So how would this work >>here? >> >>Also, someone mentioned that it might be better to look at the gravity >>of the window to figure out if it requested a specifiy geometry, instead >>of checking for non-zero position. Does anyone have more details on how >>exactly I would do this? >> >>Thx in advance! >> >>Jan >(Continue reading)
2 Oct 2009 00:06
Re: Only floating windows with window decoration
On Thu, Oct 01, 2009 at 09:51:36PM +0200, Nathan Huesken wrote: > Can I somehow configure xmonad, so that only floating windows have > window decoaration? By this I mean a titlebar, which can be used to drag > them around ... I'd take a look at XMonadContrib/XMonad/Layout/SimpleFloat.hs -- -- Andrew Antle <andrew.antle@...> <http://antlechrist.org> ############################################## ## <TMR> : Can't we just agree to disagree? ## ## <TBM> : I disagree! ## ## <Aq> : And you're wrong! ## ##############################################
2 Oct 2009 01:02
Re: darcs patch: Extended GridSelect
* On Wednesday, September 30 2009, Jan Vornberger wrote: >Wed Sep 30 17:27:41 CEST 2009 Jan Vornberger <jan.vornberger@...> > * Extended GridSelect > 1) Added another convenience wrapper that allows to select an X() action > from a given list. > 2) Implemented the option to change the position of the selection diamond. > (Re-recorded from Bluetile repo, rebased to current darcs) Applied, Thanks.
2 Oct 2009 01:32
Re: darcs patch: WindowMenu based on GridSelect that displays actions f...
* On Wednesday, September 30 2009, Jan Vornberger wrote: >Wed Sep 30 17:53:43 CEST 2009 Jan Vornberger <jan.vornberger@...> > * WindowMenu based on GridSelect that displays actions for the focused window (re-recorded from Bluetile repo). Applied, Thanks!
2 Oct 2009 01:39
Re: darcs patch: A ResizableTile-like layout that can be resized using ...
On Wed, Sep 30, 2009 at 01:10:46PM -0400, Adam Vogt wrote: > * On Wednesday, September 30 2009, Spencer Janssen wrote: > > >On Wed, Sep 30, 2009 at 02:15:46PM +0200, Jan Vornberger wrote: > >> Wed Sep 30 14:11:05 CEST 2009 Jan Vornberger <jan.vornberger <at> informatik.uni-oldenburg.de> > >> * A ResizableTile-like layout that can be resized using the mouse. > >> All separations between windows can be dragged to modify the layout. > >> Keyboard commands can also be used to achieve the same effect. > > > >How else does this differ from ResizableTile? Can we merge the two? Less code > >is always better. > > I think the ResizableTile module should just be replaced by this one, > since it provides a superset of the ResizableTile functionality. > > Listening for mouse clicks might have some kind of performance issues, > but we could make those things optional? It probably has some kind of performance impact, as input windows have to be created, I agree. There is another subtle difference in the way 'slave' windows are handled: When you have one master window and three slave windows open in ResizableTile, the slave windows will get about 1/3 of the height each. The way those sizes are calculated is somewhat tricky though, because you can resize all those slave windows individually. Modifying one slave window will usually also affect all the others. I found that to be to hard to work with when I wanted to implement the option to change the boundaries with the mouse. So in MouseResizableTile(Continue reading)
2 Oct 2009 01:40
Cheers,
Jan
RSS Feed