- xmonad - Haskell.org

darcs patch: Decoration: add mouse resize support
by Andrea Rossato 11 Feb '08

11 Feb '08

Hi, this is a follow up of my previous message ("I need help with mouse resize"). In this patch I change the windows' event mask to add the buttonEventMask. I don't know if this is the right approach to the problem. I can say it works perfectly here, but I'm not going to push this patch unless someone can confirm my approach is not inappropriate. Thanks Andrea Mon Feb 11 15:38:46 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * Decoration: add mouse resize support

1 0

darcs patch: Refactor XMonad.Hooks.DynamicLog
by Roman Cheplyaka 10 Feb '08

10 Feb '08

Sun Feb 10 22:49:47 EET 2008 Roman Cheplyaka <roma(a)ro-che.info> * Refactor XMonad.Hooks.DynamicLog This allows using DynamicLog not only for statusbar.

1 0

The future of Decoartion
by Andrea Rossato 10 Feb '08

10 Feb '08

Some of you may be thinking I'm just rewriting Ion3 in Haskell... my screen shots could even lead you to think I'm *not* using xmonad at all...;) This is just because I've been using it for quite some time and I came to love some of its features. And so I wrote the prompt and I contributed in improving David's tabbed layout (well, I also contributed in breaking it, when I added an amazingly inefficient way of managing fonts). The last thing from Ion3 I was really missing was the floating layout. *That* floating layout (and *not* our floating layer). I wanted it because I need it in some places of my desktop. Since no one was going to write it in the near future I decided to do it myself. I thought it could also be an opportunity to refactor a bit Tabbed and clean up its code, which was quite ugly (I wrote it and so I know!): it was the first or the second layout ported to the new class system. There was a problem: the ugly part in tabbed is the decoration windows management stuff, which requires a state to keep tract of created windows, the font structure (loading fonts is very resource consuming, I was told), and so on. If I were to write the floating layout I should replicate all that code, debug both versions, maintain both versions, etc. I thought it wouldn't be manageable. Then I had the idea of applying the same design pattern we have been using somewhere: generalize a computation and fine tune it with a type: our event handler uses a type of the LayoutClass to ask him to perform some specific tasks needed for a specific layout (handleMessage); Operations.windows uses a type of the LayoutClass to perform some specific layout related tasks (doLayout); the ModifiedLayout instance is fine tuned (or controlled, or driven, I just don't know the word that should be the more appropriate here) by a type of the LayoutModifier class - even xmobar has been conceived this way (a plugin is just a type member of the Runnable class, if I remember the class's name right)... This is how I conceived Decoration and the DecorationStyle class. Now, it seems to me some are complaining because Decoration is broken. And the prove Decoration is broken is given by the fact that the tabbed layout they are using is not what they expect. And since that tabbed layout is not what they expect, they think that tabbed layout breaks other part of the system (smartBorders, for instance). I would like to point out that the working of Decoration and the tabbed layout *may* be unrelated. Decoration is similar to the old tabbed layout, but just because I used the old tabbed layout to design the abstract computation to be performed for decorating windows. But Decoration *doesn't" enforce *any* idea of a layout. It is just an abstract way of creating decoration windows, and that abstract way is made concrete by a type of the DecorationStyle class. Only after that, there is the problem of the specific behavior of a tabbed layout. I would like you to admit, as I do, that there *may* be different ideas of what a tabbed layout is. Many of you think that a tabbed layout is a focused window and a set of tabs representing non visible windows belonging to that workspace. While I think this is a legitimate vision of a tabbed layout, I would like to point out that it is totally inconsistent, since it would require the focused window *not* to have a tab. Instead, tabs represent both unfocused windows *and* the focused one, and you need to use colors to avoid confusion. Since I come from the humanities, I have a totally different perspective: a tabbed layout is like an index-book (if you get what I mean - I'm using an Itaian/English dictionary here...;) or an address book, if this is giving you a better idea. Now, I understand that your idea of a tabbed layout is more convenient, since it makes it easier to code other part of the system, such a smartBorders (I know that if I put it this way you may have the feeling that I'm thinking your idea of a tabbed layout is an ugly hack to quickly code smartBorders, and the rest. And you may even be right...;-). The problem is that you are enforcing it in the wrong place. By enforcing it in Decoration you are making it impossible for me, or for others, to have the tabbed layout we want. That is to say, you decided your tabbed layout is the *right* one and that no other kind of tabbed layout *should* ever exist. That could be fine, but by doing so your are making it impossible the existence of a floating layout too. Just the idea of enforcing a given idea in Decoration is going to break decoration. I really didn't need to read David's code to know he was breaking my floating layout. His comment was enough. And indeed, I didn't read it. I just grabbed a clean source, built it, fired up Xnest and took the screenshot: http://gorgias.mine.nu/xmonadShots/droundyPatch.png (well, I was hoping for some of David's miracles, but I knew that was highly improbable in that situation, and given that comment). Now, in order to have a tabbed layout that is working smoothly with other parts of the system - your idea of a tabbed layout - we need to use a layout modifier. And I understand you think this is wrong. And since you think this is wrong, you think I must fix my code. What I'm trying to say is that, the problem is not the code, but the idea behind it. We have two conflicting ideas that are mutually incompatible. I see 3 possible solutions: 1. I change my mind; 2. you change your mind; 3. everyone changes her mind and we find a 3rd idea the is better then mine and yours. 1. and 3. are feasible for me. But I need to be convinced. 2 is out of my reach. Obviously there may be other solutions too I'm not aware of. Andrea ps: at the present time the repository is enforcing your idea with my code. This is why the repository is currently broken and, as far as my knowledge goes, there's no way to fix it.

5 17

Issue 138 in xmonad: Invisible mouse cursor (slim+xmonad)
by codesite-noreply＠google.com 10 Feb '08

10 Feb '08

Issue 138: Invisible mouse cursor (slim+xmonad) http://code.google.com/p/xmonad/issues/detail?id=138 Comment #2 by luizribeiro: Got it to work by adding 'xsetroot -cursor_name left_ptr' to my .xinitrc. Actually this is not a bug, slim supposes the WM will take the cursor back (xmonad is the only one that doesn't). -- 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 138 in xmonad: Invisible mouse cursor (slim+xmonad)
by codesite-noreply＠google.com 10 Feb '08

10 Feb '08

Issue 138: Invisible mouse cursor (slim+xmonad) http://code.google.com/p/xmonad/issues/detail?id=138 Comment #1 by luizribeiro: I forgot to state that the mouse is invisible only over GTK applications and the root window. -- 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 138 in xmonad: Invisible mouse cursor (slim+xmonad)
by codesite-noreply＠google.com 10 Feb '08

10 Feb '08

Issue 138: Invisible mouse cursor (slim+xmonad) http://code.google.com/p/xmonad/issues/detail?id=138 New issue report by luizribeiro: What steps will reproduce the problem? 1. Run slim (http://slim.berlios.de/) as your login manager with hidecursor=true 2. Run xmonad What is the expected output? What do you see instead? xmonad was supposed to recover the mouse cursor visibility. Although, the cursor's still hidden. What version of the product are you using? On what operating system? xmonad 0.6 slim 1.3.0 archlinux Please provide any additional information below. If this error is due to a module from XMonadContrib, please tag this issue with 'Component-Contrib' below. 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: Run.hs: add an option to runinterms (and 1 more)
by gwern0＠gmail.com 09 Feb '08

09 Feb '08

Mon Feb 4 22:18:24 EST 2008 gwern0(a)gmail.com * Run.hs: add an option to runinterms It turns out that for urxvt, and most terminal, apparently, once you give a '-e' option, that's it. They will not interpret anything after that as anything but input for /bin/sh, so if you wanted to go 'runInTerm "'screen -r session' -title IRC"', you were SOL - the -title would not be seen by urxvt. This, needless to say, is bad, since then you can't do stuff like set the title which means various hooks and extensions are helpless. This patch adds an extra options argument which is inserted *before* the -e. If you want the old behaivour, you can just go 'runInTerm "" "executable"', but now if you need to do something extra, 'runInTerm "-title mutt" "mutt"' works fine. This patch also updates callers. Mon Feb 4 22:21:55 EST 2008 gwern0(a)gmail.com * +doc for WindowGo.hs: I've discovered a common usecase for me for raiseMaybe

2 1

decoration madness
by Andrea Rossato 09 Feb '08

09 Feb '08

Hi, I pushed a new module, and I called it DecorationMadness. There are some layouts (tall, mirror, accordion and circle) with decorations. Stuff I've used to test the decoration code I've been writing, mainly. But I also added a screen shot for each of the available layouts, and some documentation: http://gorgias.mine.nu/xmonad-docs/xmonad-contrib/XMonad-Layout-DecorationM… which is the main reason I collected those layouts in a single place. Each layout comes in two version: a simple one, with the default window's name shrinker and the default theme, and a version with the possibility to add custom options. Could it be a way to present to end users our code? Andrea

1 0

darcs patch: Decoration: fix mouse dragging jump ...
by Andrea Rossato 09 Feb '08

09 Feb '08

I'm not so sure if I should push this patch. It works, but I don't understand why. If you do, please let me know. Andrea Fri Feb 8 21:41:20 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * Decoration: fix mouse dragging jump ... ... I don't have a better description... when starting to grab the window by clicking on the decoration, you could see the window's origin jumping to the pointer position. This should be fixed now (but I'm not so sure... please report any window's strange movement you may see).

2 3

screen redraw > 2s -> urxvt -tr in "noBorders Full" window
by ac007＠bluewin.ch 09 Feb '08

09 Feb '08

Hello, When switching to/from a "noBorders Full" window containing urxvt with transparency, it takes almost 2 seconds for the screen to redraw. The screen redraw is almost instantanous with urxvt plain background and/or normal (with borders) "Full" window. Can't remember when i first noticed this... some weeks ago (maybe when i started using noBorders ? :) Sorry if this has allready been mentionned. Bests and long live Xmonad ! Alexandre * xmonad-0.6 darcs (last pull/compile X11/Xmonad/XMonadContrib 2 days ago) * rxvt-unicode-8.9 * xorg-server-1.4.0.90 -- xorg-x11-7.3

2 1