- xmonad - Haskell.org

Re: Emergency terminal
by Don Stewart 22 Feb '08

22 Feb '08

xmonad-bounces: > The attached message has been automatically discarded. > Date: Fri, 15 Feb 2008 08:45:01 +0200 > From: Salvatore Iovene <salvatore.iovene(a)googlemail.com> > To: xmonad(a)haskell.org > Subject: Emergency terminal > > Hi all, > sometimes I need to open a terminal window just for a quick task (i.e. > quickly view an image). Using Mod+p and opening a dmenu is not really > good for that (lack of good completation support) and I don't want to > open a new terminal that will change the existing layout (not good on > the eye). > > The ideal solution would be having a special key that'd fire up a > floating terminal on the bottom of the screen, only, say, 5 lines > high, so you could quickly give your command without interfering with > the existing layout. > > Is there anything like this already around? > Thanks! > There's been much talk about a 'scratchpad' terminal. This doesn't exist, but would be easy to implement as an extension -- just open up a terminal with a property set on it, then write a manageHook rule that looks for that property, and positions the window as floating, and with particular geometry. This would be a great extension to have, if someone would like to write it. -- Don

5 7

Issue 143 in xmonad: XEvent hook or similar needed
by codesite-noreply＠google.com 22 Feb '08

22 Feb '08

Issue 143: XEvent hook or similar needed http://code.google.com/p/xmonad/issues/detail?id=143 New issue report by nomeata: Hi, I've mentioned this a few times in the past, but I want this tracked here: For proper EWMH support, I need a way to get XEvents (ClientMessage events in particular) independent from the current workspace or layout, reliably, and exactly once. This is logically equivalent to what we do to key events, just that there is nothing the user needs to configure (besided enabling the EWMH module). I think the cleanest solution would be a new hook, similar to logHook, that passes any received XEvent to interested modules. Thanks, Joachim Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- 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 0

darcs patch: broadcastMessage now uses Operations.windows to update...
by Andrea Rossato 22 Feb '08

22 Feb '08

hi, this is a follow up of my previous "broadcastMessage should not call modify". This is a proposal of the new approach, in order to show that it fixes the issue #111. Cheers, Andrea (ps: sorry for the noise, but I think this is urgent, as issue #142 shows.) Thu Feb 21 15:18:50 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * broadcastMessage now uses Operations.windows to update the windowset This is a fix for issue #111: - broadcastMessage and restart moved to Operations; - added sendMessageToVisible and sendMessageToHidden - broadcastMessage will use sendMessage* functions now. TODO: remove Core.runOnWorkspaces and refactor sendMessageToWorkspaces accordingly.

3 3

darcs patch: Export XMonad.Layout.Grid.arrange (for u... (and 1 more)
by Roman Cheplyaka 22 Feb '08

22 Feb '08

Thu Feb 21 08:22:04 EET 2008 Roman Cheplyaka <roma(a)ro-che.info> * Export XMonad.Layout.Grid.arrange (for use in XMonad.Layout.IM) Thu Feb 21 10:57:52 EET 2008 Roman Cheplyaka <roma(a)ro-che.info> * Add XMonad.Layout.IM

2 1

How is this screenshot done?
by Dominik Bruhn 21 Feb '08

21 Feb '08

Hy, I found this screenshot: http://haskell.org/haskellwiki/Image:Screen-ohmega-tab-gnome-twopane.jpg How is the tabbing done in this screen? The upper right window seems to have multiple tabs. Is this possible using xmonad? Thanks for any help -- Dominik Bruhn mailto: dominik(a)dbruhn.de

3 2

xmobar with utf8 support
by Andrea Rossato 21 Feb '08

21 Feb '08

Hi, today I pushed a few patches to add utf8 support to xmobar. I don't think I'm going to add full locale support, since utf8 seems to be fine for a minimalistic status bar (moreover, locale support requires iconv). I just need to write a battery plugin with the possibility of setting the filepath where to retrieve battery information and then I'll make the 0.9 release. So, if you want to give it a try and find a bug, or have some other features you would like to see implemented before 0.9, speak now, or forever...whatever. Cheers, Andrea

2 2

Issue 142 in xmonad: Tab selection and highlighting doesn't work as expected
by codesite-noreply＠google.com 21 Feb '08

21 Feb '08

Issue 142: Tab selection and highlighting doesn't work as expected http://code.google.com/p/xmonad/issues/detail?id=142 New issue report by v.dijk.bas: (Possibly related to issue 125) When using the Tabbed layout the selection and highlighting of the tabs doesn't work as expected. What steps will reproduce the problem? 1. Switch to the Tabbed layout. 2. Open multiple windows. 3. Select a tab by clicking on that tab. 4. Move the mouse away from the tabs into the selected window. 5. Select another tab by clicking on that tab. 6. Notice that the selected window becomes active like you expect. However, the selected tab is not highlighted as you would expect. In fact, if you look closely, it is only highlighted for a fraction of a second after which the previously selected tab is highlighted. The real problem however is when you select tabs while your cursor doesn't move out of the tabs region. Then, when you select another tab and then try to select the previous tab (which is still highlighted) you won't be able to select it. (This is quite irritating) I'm using a recent version of xmonad and XMonadContrib from darcs: Thu Feb 21 2008 (I'm using a NoBorder LayoutModifier over my Tabbed layout. But also without this I have the same problem.) 'Component-Contrib' regards, Bas Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- 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

2 1

Issue 111 in xmonad: Clicking on tab doesn't work if that screen doesn't have focus
by codesite-noreply＠google.com 21 Feb '08

21 Feb '08

Issue 111: Clicking on tab doesn't work if that screen doesn't have focus http://code.google.com/p/xmonad/issues/detail?id=111 Comment #9 by andrea.rossato: this is a new patch: this way I propose to change broadcastMessage to use Operations.windows. Please see here for a discussion of the reasons: http://www.haskell.org/pipermail/xmonad/2008-February/004824.html Attachments: fix_refactor_boradcastMessage.dpatch 11.4 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

1 0

Issue 142 in xmonad: Tab selection and highlighting doesn't work as expected
by codesite-noreply＠google.com 21 Feb '08

21 Feb '08

Issue 142: Tab selection and highlighting doesn't work as expected http://code.google.com/p/xmonad/issues/detail?id=142 Comment #1 by andrea.rossato: Hi, this is probably a duplicate of issue #111 http://code.google.com/p/xmonad/issues/detail?id=111 You can try the patch that I attached there today. But I'm also working on a more general approach. Here I tried to explain the problem with some more details: http://www.haskell.org/pipermail/xmonad/2008-February/004824.html cheers -- 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 0

broadcastMessage should not call modify
by Andrea Rossato 21 Feb '08

21 Feb '08

Hi, I now have perfectly clear in my mind what happens when issue #111 shows up. I don't know if the solution I'm proposing is the right one, this is a different matter. Moreover I might even be wrong. But at least I can try to share my understanding of the problem. When boradcastMessage is called it will 'get' the windowset, call handleMessage with the (against would be a correct expression?) layout of each workspace, and then update the state with a list of workspaces made up of the stack retrieved by the previous 'get' call, and a (maybe modified) layout returned by the *successive* handleMessage. The problem is that handleMessage may change the windows' stack in a workspace, if a call of 'focus' is made within handleMessage. This is what happens when you click on a decoration: the stack is changed *after* 'gets windowset', but broadcastMessage updates the state with an *outdated* stack, the one retrieved by 'gets'. The decorations, instead, reflect the updated stack that has been discarded. This doesn't happen with 'sendMessage' because sendMessage calls handleMessage with (against?) the layout of the current workspace. If handleMessage returns a new layout, then 'sendMessage' will call Operations.windows to update the state. And 'windows' will operate on a state retrieved *after* handleMessage returned, that is to say, with an updated windowset (and so with an updated stack). This is why my patch fixes #111 (as long as I can try with my simulated Xinerama setup - but I'm able to reproduce the issue with that very setup): it uses 'windows' to update the (Maybe) modified layouts (when it is Just) of every visible workspace. Now, as far as I understand, the use of 'modify' in 'broadcastMessage' is done in order not to call the resource intensive Operations.windows (there is no other reason *I* am aware of). But I think this wrong, because it is the only reason why a layout cannot safely call 'focus' in handleMessage. This is my understanding. Cheers, Andrea

1 0