February 2008 - xmonad

mouse resize now available
by Andrea Rossato 12 Feb '08

12 Feb '08

Hi, I've just pushed a few patches that introduce the new XMonad.Actions.MouseResize module, which is a layout modifier to be used together with WindowArrager to resize windows by grabbing the window's lower right corner. With this feature, which can be obviously extended (mouse resize by grabbing the borders?) I think that the new decoration framework is complete. I added the mouse resize modifier to SimpleFloat and to the resizable layouts you can find in DecorationMadness. What remains to be done is solving the problematic interactions between decorations and WindowNavigation. No other major bug has been reported so far (but I'm waiting...;). Hope you'll enjoy. Andrea

1 0

I need help with mouse resize
by Andrea Rossato 12 Feb '08

12 Feb '08

Hi, I need some help with mouse resize (maybe Brandon is around?). Basically, I'm going to use what Brandon suggested: check for a button event on the lower right corner of the window (I'm thinking about a 4 pixels wide square). The problem is that the window's mask doesn't include button press events. Now I'm puzzled (due to my ignorance): should I change that? should I add some other decorations in the window's corners and set their event mask? I do not really know what happens in other WM and, since this is not like our mouseResizeWindow (which is basically a key binding and is not related to button events), I don't know what I should do. Any direction is appreciated. Andrea ps: I must confess I do not think this is an indispensable feature... it would be nice though. But now that I'm going to push a patch that unifies mouse focus and mouse drag (which means that you can start grabbing an unfocused window) I think that what is really needed is there...;)

2 2

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

12 Feb '08

Issue 138: Invisible mouse cursor (slim+xmonad) http://code.google.com/p/xmonad/issues/detail?id=138 Comment #3 by SpencerJanssen: Agreed: not an xmonad bug. Though if we don't have a FAQ about setting the mouse pointer, we ought to add one. Issue attribute updates: Status: Invalid -- 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

dynamiclog broken with Decoration..
by David Chanters 11 Feb '08

11 Feb '08

hi, is it meant to be the case when using all the Decoration stuff from darcs that it vreaks the dynamiclog? i now don't get the window name updates if windows have decoration. David

2 8

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