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