February 2008 - xmonad

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

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 #8 by andrea.rossato: sorry for my previous attachment. This is the correct implementation of my fix. Attachments: fix_issue111_Corrected.dpatch 8.5 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

darcs patch: Fix issue #111
by Andrea Rossato 21 Feb '08

21 Feb '08

Sorry for my previous noise, but I got a bit excited by the fact that my approach seemed to be working and I recorded and sent just a bit too quickly. This is the correct implementation of my idea: a 'sendMessage' for visible layouts: 'sendMessageToVisible'. And for the button events we use 'sendMessageToVisibles', which will call the above functions. I checked and this actually fixes the problems reported in #111. Let me know, please. Cheers, Andrea Thu Feb 21 11:08:53 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * Fix issue #111 The use of broacastMessage for sending button events to visible layouts conflicts with the possibility for those layouts of changing the windowset. This is possible with sendMessage, if the layout modifying the windowset doesn't return a new layout. This is how we handle mouse focus changes in decorated layouts. By generalizing sendMessage, we can use it to broadcast button events and let layouts in visible workspaces change the windowset as long as they do not update the layout. This should fix the problems reported in issues #111.

1 0

darcs patch: Fix issue #111
by Andrea Rossato 21 Feb '08

21 Feb '08

Hi, issue #111 is a real problem now that we have decorated layouts that require a correct button event handling. This patch addresses the issue. I don't know if you are going to like it but at least it fixes the problems. If the core developers do not like this solution, still I believe they should provide their own as quickly as possible. Hope this helps in getting this problem fixed as soon as possible. Cheers, Andrea Thu Feb 21 10:02:20 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * Fix issue #111 The use of broacastMessage for sending button events to visible layouts conflicts with the possibility for those layouts of changing the windowset. This is possible with sendMessage, if the layout modifying the windowset doesn't return a new layout. This is how we handle mouse focus changes in decorated layouts. By generalizing sendMessage, we can use it to broadcast button events and let layouts in visible workspaces change the windowset as long as they do not update the layout. This fixes the problems reported in issues #111.

1 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 #7 by andrea.rossato: I'm attaching my patch to fix the problem here to. I really hope we can come to a solutions as quickly as possible. cheers Attachments: fix_issue111.dpatch 8.0 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

New xmonad development tutorial
by Brent Yorgey 21 Feb '08

21 Feb '08

Hi all, I've written a short meta-tutorial on the xmonad wiki, on how to develop new extension modules for xmonad. It's not a haskell tutorial, it doesn't cover anything about the xmonad code itself (that's the other tutorial I'm still working on =), just all the little bits + pieces you need to know in order to develop xmonad stuff that weren't really documented anywhere central before (e.g. basics of using darcs, how to create a new module and add it to the .cabal file, coding standards, Haddock basics, how to test Haddock-generated documentation, submitting patches, etc.). I hope some people will find it useful, and feel free to point it out to new people interested in getting involved. Comments, suggestions, and improvements (it is a wiki of course! =) welcome. http://haskell.org/haskellwiki/Xmonad/xmonad_development_tutorial -Brent

2 1

Issue 79 in xmonad: unreliable fullscreen mode for gmplayer
by codesite-noreply＠google.com 20 Feb '08

20 Feb '08

Issue 79: unreliable fullscreen mode for gmplayer http://code.google.com/p/xmonad/issues/detail?id=79 Comment #2 by taupan: Vlc behaves similar: - press f to go to fullscreen mode - I see briefly a fullscreen window which immediately disappears an is replaced by the normal layout - I can then press f again to get the video window back However I can do the following to get a real vlc fullscreen display: 1.) switch to fullscreen layout, 2.) press alt-b to switch off all struts/borders 3.) press f in vlc to get fullscreen Strangely the vlc fullscreen display will not "disappear" in that case. -- 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