Hi, I'm now trying to clean up a bit after this long and stressful class ride (I even started dreaming about type classes, such is the addictive power of this stuff). Now I'm going to take a break and enter in a maintainer mode: just debugging and docs. Spencer: I'm still waiting your decisions about tabbed. Should it return all windows and thus use the decoration framework, of should it be e separated layout (the previous one) returning just the focused window? Please, take a decision, because at the present time tabbed is plainly broken (my fault since I gave you wrong information... but I was a bit confused when you asked). Anyway you can just: 1. push a simple patch to make it use Simplest, or 2. get a version of the old tabbed and copy it over the new one: it should be working out of the box (maybe users will have to import it qualified). The reason why it should not return all windows is still a bit mysterious to me... what you said, I don't remember exactly, seemed to me more a bug in the X server then a feature. But I came to be a bit confused on the distinction between the two, lately...;) Bugs may come to me! Andrea
On Thu, Jan 31, 2008 at 11:35:38AM +0100, Andrea Rossato wrote:
Hi,
I'm now trying to clean up a bit after this long and stressful class ride (I even started dreaming about type classes, such is the addictive power of this stuff).
Now I'm going to take a break and enter in a maintainer mode: just debugging and docs.
Spencer: I'm still waiting your decisions about tabbed. Should it return all windows and thus use the decoration framework, of should it be e separated layout (the previous one) returning just the focused window? Please, take a decision, because at the present time tabbed is plainly broken (my fault since I gave you wrong information... but I was a bit confused when you asked).
Anyway you can just: 1. push a simple patch to make it use Simplest, or 2. get a version of the old tabbed and copy it over the new one: it should be working out of the box (maybe users will have to import it qualified).
The reason why it should not return all windows is still a bit mysterious to me... what you said, I don't remember exactly, seemed to me more a bug in the X server then a feature. But I came to be a bit confused on the distinction between the two, lately...;)
Bugs may come to me!
Andrea
The tabbed layout should only return the focused window -- there are performance implications (much fewer expose events and repaints generated), it gives better information to layout modifiers that count the number of returned windows (like smartBorders), and it's just the right thing to do (non-visible windows should be in the unmapped state is standard WM convention). However, I don't think there's any reason we can't use Decorations. Of course, we'll need to generalize Decorations a bit. There are a few options: - Run 'decorate' even on windows that aren't returned by doLayout (perhaps use Maybe Rectangle as an argument, where Nothing signifies the window isn't visible) - Allow 'decorate' to return a list of decorations, rather than a single decoration. I haven't been able to divine the logic behind the code to make either modification myself, but I might be able to with a bit of documentation tossed in there :) I'm inclined to leave the base layout as Full, even though that is slightly broken at the moment. Thus are the perils of running software-in-development. Cheers, Spencer Janssen
Spencer Janssen
The tabbed layout should only return the focused window -- there are performance implications (much fewer expose events and repaints generated), it gives better information to layout modifiers that count the number of returned windows (like smartBorders), and it's just the right thing to do (non-visible windows should be in the unmapped state is standard WM convention).
What about when running a composite manager? I run xcompmgr (at least occasionally) and noticed that now the inactive tabs can be seen in a translucent term, previously only the desktop background would shine through.
Cheers, Spencer Janssen
Tom
On Fri, Feb 01, 2008 at 10:16:31AM +0100, Tom Rauchenwald wrote:
What about when running a composite manager? I run xcompmgr (at least occasionally) and noticed that now the inactive tabs can be seen in a translucent term, previously only the desktop background would shine through.
Sorry if I ask, but I don't use this stuff (I don't have to hardware for): do you think that the effects you are noticing are an improvement, or a bug? Thanks, Andrea
At Fri, 1 Feb 2008 13:04:01 +0100, Andrea Rossato wrote:
On Fri, Feb 01, 2008 at 10:16:31AM +0100, Tom Rauchenwald wrote:
What about when running a composite manager? I run xcompmgr (at least occasionally) and noticed that now the inactive tabs can be seen in a translucent term, previously only the desktop background would shine through.
Sorry if I ask, but I don't use this stuff (I don't have to hardware for): do you think that the effects you are noticing are an improvement, or a bug?
IMHO this would be a bug. Since the other windows are on their tabs and not in the background. greetings Tim -- The opposite of a correct statement is a false statement. But the opposite of a profound truth may well be another profound truth. -- Nils Bohr
On Fri, Feb 01, 2008 at 12:20:46PM +0000, Tim Schumacher wrote:
At Fri, 1 Feb 2008 13:04:01 +0100, Andrea Rossato wrote:
Sorry if I ask, but I don't use this stuff (I don't have to hardware for): do you think that the effects you are noticing are an improvement, or a bug?
IMHO this would be a bug. Since the other windows are on their tabs and not in the background.
just a terminology clarification: a tab, for you, is just the representation of a window ("windows are on their tabs"), and so you think they should not be visible through the transparent, focused, window, right? if that is right, I think that the last patch I've sent here: http://code.google.com/p/xmonad/issues/detail?id=125 should fix your problem. I'm writing that, because, in my vision, a tabbed layout is just a stack of full screen windows *plus* their tabs. I would expect that, if I resize the window at the top, I should be able to see the second window, and if I resize this second, I can see the third. This way I can user the WindowArranger with tabbed too. The patch that I sent, though, should make the both of us happy, since we can have both a tabbed layout with just the focused window, and a tabbed layout as I conceive it. As you may understand what I did was just implementing *my* idea of a tabbed layout. Cheers, Andrea
Andrea Rossato
On Fri, Feb 01, 2008 at 10:16:31AM +0100, Tom Rauchenwald wrote:
What about when running a composite manager? I run xcompmgr (at least occasionally) and noticed that now the inactive tabs can be seen in a translucent term, previously only the desktop background would shine through.
Sorry if I ask, but I don't use this stuff (I don't have to hardware for): do you think that the effects you are noticing are an improvement, or a bug?
Well it depends.. If you have the mental picture that an inactive tab is "behind" the active one, it is an improvement. At least it seems more logical to me. I don't really care much about this to be honest, it was just something i noticed.
Thanks, Andrea
Tom -- Then I drew in a breath, and my renewed will with it, lifted the rod in my right hand, murmured a phrase in a language I didn't know, and blew the tires off his fucking truck. -- Harry Dresden
On Fri, Feb 01, 2008 at 02:51:33AM -0600, Spencer Janssen wrote:
I haven't been able to divine the logic behind the code to make either modification myself, but I might be able to with a bit of documentation tossed in there :)
I'm inclined to leave the base layout as Full, even though that is slightly broken at the moment. Thus are the perils of running software-in-development.
this could be a clean solution, but I didn't test it. Basically it is a layout modifier that will take the first decoration and the first window, and then would just select decorations. That is, if placed on top of tabbed, it should be removing all unfocused windows, without touching decorations. -- | Removes windows for the tabbed layout windowRemove :: l a -> ModifiedLayout WindowRemover l a windowRemove = ModifiedLayout WindowRemover data WindowRemover a = WindowRemover deriving (Show, Read) instance LayoutModifier WindowRemover Window where redoLayout _ _ _ wrs = do nws <- end return (start ++ nws, Nothing) where start = take 2 wrs end = filterM (isNotDeco) (drop 2 wrs) isNotDeco (w,_) = do b <- isDecoration w return (not b) This way tabbed will be using Simplest, but xmonad would receive just the first window and all the correctly placed decorations. I'll test it and will let you know.[1] Docs: actually I though it could be fun to have the help of someone else to design the class, and improve its expressiveness. I didn't documented it because this was intended as a proposal to being discussed. I'd really beg you to read my previous messages and ask me whatever question you feel like (if I start telling the whole story every time, everything gets just more confused). I'm off the IRC channel also because I don't want to make the same mistake I did with you last time. This is quite difficult stuff for me, and I need to think a bit before answering (I'm also a bit tired... that has been one of the most rapid learning experiences I've had the last few years). I'd really appreciate any available help. Cheers, Andrea [1] At the present time, when I was trying to test it, I started experiencing strange problems with the linker: /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o): In function `s1e0s_info': ghc3557_0.hc:(.text+0x3ada): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_info' /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o):(.rodata+0xa8): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_closure' collect2: ld returned 1 exit status I've never touched neither WindowNavigator nor Combo... strange. I'll clean and retry.
On Fri, Feb 01, 2008 at 11:00:58AM +0100, Andrea Rossato wrote:
[1] At the present time, when I was trying to test it, I started experiencing strange problems with the linker:
/usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o): In function `s1e0s_info': ghc3557_0.hc:(.text+0x3ada): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_info' /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o):(.rodata+0xa8): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_closure' collect2: ld returned 1 exit status
It seems like I found a bug in ghc-6.6.1 and I need to upgrade to 6.8.2. Now that is going to be a bit of a pain... Anyhow, the code I'm sending in a separate patch seems to work fine with ghc-6.8.2. Cheers, Andrea
mailing_list:
On Fri, Feb 01, 2008 at 11:00:58AM +0100, Andrea Rossato wrote:
[1] At the present time, when I was trying to test it, I started experiencing strange problems with the linker:
/usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o): In function `s1e0s_info': ghc3557_0.hc:(.text+0x3ada): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_info' /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o):(.rodata+0xa8): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_closure' collect2: ld returned 1 exit status
It seems like I found a bug in ghc-6.6.1 and I need to upgrade to 6.8.2.
Now that is going to be a bit of a pain...
Anyhow, the code I'm sending in a separate patch seems to work fine with ghc-6.8.2.
Missing module in the cabal file?
On Fri, Feb 01, 2008 at 02:51:33AM -0600, Spencer Janssen wrote:
- Run 'decorate' even on windows that aren't returned by doLayout (perhaps use Maybe Rectangle as an argument, where Nothing signifies the window isn't visible)
why should I decorate those windows and then mark them as non visible? How can I know which window is visible in, say, a decorated circle layout, or in a floating layout? All windows maybe decorated, and it is only by inspecting its geometry (can be done) and comparing it with the geometry of the list of all windows (decorate can do that too), that you can have an idea of what could be visible. Instead, it is decorate that may want or not to want decorate a window, and indeed it returns a Maybe rectangle (the pure version). Think about the DwmStyle... When a layout produces a list of windows, decorations will look the stack and will not decorate that window returning a Nothing.
- Allow 'decorate' to return a list of decorations, rather than a single decoration.
I don't get this. decorate is run to each member of the (window, rectangle) list produced by a layout (resync in the instance, - resync is not pure to let to let decorate return X (Mayb Rectangle), and operate in the X monad.
I haven't been able to divine the logic behind the code to make either modification myself, but I might be able to with a bit of documentation tossed in there :)
I'm inclined to leave the base layout as Full, even though that is slightly broken at the moment. Thus are the perils of running software-in-development.
this is the pipe line. Every layout may (should be possible for it to) through;: 1. doLayout is called to some layout and a list [(w,r)] is produced; 2. arranger (pure layout modifier) which keeps track of geometries: data ArrangedWindow a = WR (a, Rectangle) -- original geometries produced by the underlying layout | AWR (a, Rectangle) -- geometry modified by a sendMessage The modifier (instance of LayoutModifier), with only a pure implementation: type ArrangeAll = Bool data WindowArranger a = WA Bool ArrangeAll [ArrangedWindow a] deriving (Read, Show) The Bool to toggle it off and on with a sendmessage. ArrangeAll for the floating layout. 3. Decorator: process the list and according to the DecorationStyle decide if and how decorate each window of the list. Choice is almost pure but in the X for more expressiveness of the types. 3a: decorate, the main method of the DecorationStyle is: decorate :: ds a -> Dimension -- user defaults, may be overwritten (decoration too small) -> Dimension -- user defaults, may be overwritten (decoration too small) -> Rectangle -> W.Stack a -> [(a,Rectangle)] -> (a,Rectangle) -> X (Maybe Rectangle) takes everything and, specifically the window and the rectangle to decorate (and run in resync, which could be pure, but I did it impure for increasing the power of decorate in terms of windows choice - windowAttributes?). The task of resync is to keep synchronized the (w,r) list with the decoration list (and geometry) - its State component. 3b: finally insert_dwr will fold the list of windows and (Maybe) decorations and will place them in front of the window they were created for. 4: then you start applying post decoration modifier, like WindowRemover (if you want remove window). 5. everything gets to restackWindos d list 6. Decoration keeps track of every decoration and will remove them when requested, or by an empty layout. My working proposal, as I reported in the abused tracker, the *really* ugly one, is to return the first window of the list produced by decoration, and then remove all windows that are not decorations, which means I remove the unfocused windows. But leaving the possibility of the other approach too. Obviously, over the windowRemover every modifier may be thinking that the layout was produced by Full, but it will receive the decorations too, but can just skip them when processing the list (what I say decoration awareness of a modifier) Andrea
participants (5)
-
Andrea Rossato -
Don Stewart -
Spencer Janssen -
Tim Schumacher -
Tom Rauchenwald