On Sun, Feb 03, 2008 at 08:25:55PM -0500, David Roundy wrote:
I also added support for mouse clicking into Decoration, so that (modulo the need to avoid the broadcastMessage patch that breaks mouse support for tabbed anyhow) we now have fully functional tabs.
this part of the patch rises, I think, quite an interesting issue. I think that we should keep ordering information unique throughout the system, and *only* in the stack. I think Don will agree with me on this point. There is just one exception in the windowArranger. But from a practical perspective this only means that the arranged window (a window whose geometry has been modified by a user message sent to the arranger) will not change its position on the screen if you swap it in the stack. But it got swapped. Anyway, any modifier can trust the fact the focused window in the stack *is* the focused window, the first in the [(w,r)] (or the second if the first is a decoration). Your patch breaks this design and after Decoration the stack we pass to modifiers (redoLayout, etc) cannot be trusted anymore, which, I think, is bad. We could remove the stack from the type signature of those methods and just change our perspective, as you probably did. maybe this way is better. I don't know, but we should be consistent somehow, is which case this patch would be not enough. Just my 2 cents. Andrea ps: as you may observe, here I'm proposing to set aside the idea that a layout is a monolithic object, defined in a specific place in our source code. I think this is not scalable anymore, not when we start adding decorations and all that. Instead, we should create smaller components and put them together to create layouts. But we must hide everything to our users.