darcs patch: Added LayoutMessages
Hi,
as we said yestarday this is my proposal for a more sophisticated
layour message system.
Basically: UnDoLayouts is used for refreshes, LayoutSwitch wfor
notifying a layout change, and NonVisible when a layout is a workspace
not visible anymore.
This way we can have a non flickering tabbed, with proper handling of
fontStruct and windows, but without having to recreate/destroy these
resources at every refresh.
There is a new function sendMessage', for sending messages to a list
of layouts.
This is just a proposal. If you don't like the code style please let
me know (better if with directions): I'm always happy to improve!
The accompanying Tabbed code is finished: I just need to clean it up a
bit.
Andrea
Mon Sep 24 16:09:06 CEST 2007 Andrea Rossato
On Mon, Sep 24, 2007 at 04:20:32PM +0200, Andrea Rossato wrote:
Hi,
as we said yestarday this is my proposal for a more sophisticated layour message system.
Basically: UnDoLayouts is used for refreshes, LayoutSwitch wfor notifying a layout change, and NonVisible when a layout is a workspace not visible anymore.
I don't see why we need so many messages. It seems like UnDoLayouts should now be unused, and NonVisible should be treated the same as LayoutSwitch. Do you have a use case where these should be treated differently? However, it might be nice to have a Focus/NonFocus message. This would allow WorkspaceDir to work properly with multiple screens. A related (and perhaps better) possibility would be to create a different method in Layout for drawing focussed stacks versus unfocussed stacks. The default, of course, would be for both to be drawn the same. class (Show (layout a), Read (layout a)) => Layout layout a where doLayout :: layout a -> Rectangle -> Stack a -> X ([(a, Rectangle)], Maybe (layout a)) doFocusLayout :: layout a -> Rectangle -> Stack a -> X ([(a, Rectangle)], Maybe (layout a)) doFocusLayout = doLayout modifyLayout :: layout a -> SomeMessage -> X (Maybe (layout a)) modifyLayout _ _ = return Nothing Actually, I think this is exactly how I'd like to handle focus. But I really don't see a use case for NonVisible vs UnDoLayouts vs LayoutSwitch, and am not keen on sending and defining messages without an envisioned use case. If some day someone comes up with an idea that depends on distinct NonVisible and LayoutSwitch messages, we could easily split them apart, but until then, I'd prefer to have a single message sent. At a minimum, I'd vote for eliminating UnDoLayouts.
This way we can have a non flickering tabbed, with proper handling of fontStruct and windows, but without having to recreate/destroy these resources at every refresh.
That'll definitely be good.
There is a new function sendMessage', for sending messages to a list of layouts.
Sounds good. Maybe rename this to sendMessageToWorkspaces? I know I'm as guilty as anyone with regard to foo' naming, but I think sendMessageToWorkspaces would a bit better describe what this function does. -- David Roundy Department of Physics Oregon State University
On Mon, Sep 24, 2007 at 07:46:29AM -0700, David Roundy wrote:
On Mon, Sep 24, 2007 at 04:20:32PM +0200, Andrea Rossato wrote:
Hi,
as we said yestarday this is my proposal for a more sophisticated layour message system.
Basically: UnDoLayouts is used for refreshes, LayoutSwitch wfor notifying a layout change, and NonVisible when a layout is a workspace not visible anymore.
I don't see why we need so many messages. It seems like UnDoLayouts should now be unused, and NonVisible should be treated the same as LayoutSwitch. Do you have a use case where these should be treated differently?
Two messages would actually be fine for me. The problem is that I would like to know when I must hide and when I must free the resources. When we change layout we now send a "UnDoLayout", and we send the same in Operations.windows before updating the state. I also have the Read instance problem, which I did not study carefully yet. If I want to cache the fontStruct/Set together with the window ids, I would like to know when XMonad is going to be restarted. The cache is done in a Maybe type and I would like to free all the resources and return a Tabbed Nothing TConf, which could be read (am I guessing right here?).
However, it might be nice to have a Focus/NonFocus message. This would allow WorkspaceDir to work properly with multiple screens. A related (and perhaps better) possibility would be to create a different method in Layout for drawing focussed stacks versus unfocussed stacks. The default, of course, would be for both to be drawn the same.
Neither solves the release/hide resources issue, btw.
class (Show (layout a), Read (layout a)) => Layout layout a where doLayout :: layout a -> Rectangle -> Stack a -> X ([(a, Rectangle)], Maybe (layout a)) doFocusLayout :: layout a -> Rectangle -> Stack a -> X ([(a, Rectangle)], Maybe (layout a)) doFocusLayout = doLayout modifyLayout :: layout a -> SomeMessage -> X (Maybe (layout a)) modifyLayout _ _ = return Nothing
Actually, I think this is exactly how I'd like to handle focus.
But I really don't see a use case for NonVisible vs UnDoLayouts vs LayoutSwitch, and am not keen on sending and defining messages without an envisioned use case. If some day someone comes up with an idea that depends on distinct NonVisible and LayoutSwitch messages, we could easily split them apart, but until then, I'd prefer to have a single message sent. At a minimum, I'd vote for eliminating UnDoLayouts.
In which case how would you suggest to handle the specific problem of Tabbed?
There is a new function sendMessage', for sending messages to a list of layouts.
Sounds good. Maybe rename this to sendMessageToWorkspaces? I know I'm as guilty as anyone with regard to foo' naming, but I think sendMessageToWorkspaces would a bit better describe what this function does.
Perfect! Andrea
NOTE: I changed my opinion as I wrote this response, but haven't gone back to rewrite the whole response, so understand that it's more of a story than a coherent exposition of a well-thought-out opinion. On Mon, Sep 24, 2007 at 05:05:26PM +0200, Andrea Rossato wrote:
On Mon, Sep 24, 2007 at 07:46:29AM -0700, David Roundy wrote:
On Mon, Sep 24, 2007 at 04:20:32PM +0200, Andrea Rossato wrote:
Hi,
as we said yestarday this is my proposal for a more sophisticated layour message system.
Basically: UnDoLayouts is used for refreshes, LayoutSwitch wfor notifying a layout change, and NonVisible when a layout is a workspace not visible anymore.
I don't see why we need so many messages. It seems like UnDoLayouts should now be unused, and NonVisible should be treated the same as LayoutSwitch. Do you have a use case where these should be treated differently?
Two messages would actually be fine for me. The problem is that I would like to know when I must hide and when I must free the resources.
And I presume you want to free the resources when the layout is changed? To me, it seems that you'd want to treat the two the same way. When a workspace is hidden, there's no guarantee it'll ever be shown again, and I'd rather free resources at that time. Alternatively, perhaps you'd rather have a DestroyLayout message? Then we'd only free resources when we really need to, and temporarily switching to fullscreen mode wouldn't involve allocation/deallocation of resources.
I also have the Read instance problem, which I did not study carefully yet. If I want to cache the fontStruct/Set together with the window ids, I would like to know when XMonad is going to be restarted. The cache is done in a Maybe type and I would like to free all the resources and return a Tabbed Nothing TConf, which could be read (am I guessing right here?).
It seems like this would be trivially solvable by broadcasting a DestroyLayout message prior to calling show on the StackSet.
However, it might be nice to have a Focus/NonFocus message. This would allow WorkspaceDir to work properly with multiple screens. A related (and perhaps better) possibility would be to create a different method in Layout for drawing focussed stacks versus unfocussed stacks. The default, of course, would be for both to be drawn the same.
Neither solves the release/hide resources issue, btw.
Right.
class (Show (layout a), Read (layout a)) => Layout layout a where doLayout :: layout a -> Rectangle -> Stack a -> X ([(a, Rectangle)], Maybe (layout a)) doFocusLayout :: layout a -> Rectangle -> Stack a -> X ([(a, Rectangle)], Maybe (layout a)) doFocusLayout = doLayout modifyLayout :: layout a -> SomeMessage -> X (Maybe (layout a)) modifyLayout _ _ = return Nothing
Actually, I think this is exactly how I'd like to handle focus.
But I really don't see a use case for NonVisible vs UnDoLayouts vs LayoutSwitch, and am not keen on sending and defining messages without an envisioned use case. If some day someone comes up with an idea that depends on distinct NonVisible and LayoutSwitch messages, we could easily split them apart, but until then, I'd prefer to have a single message sent. At a minimum, I'd vote for eliminating UnDoLayouts.
In which case how would you suggest to handle the specific problem of Tabbed?
Personally, I'd vote for always releasing resources when the workspace is either NonVisible or when it's only the Layout that is hidden. This seems simplest, and I'm not convinced that simply hiding the tab windows would give us much of a performance gain. But if you want the performance gain of hiding tab windows, then it seems like you may as well have that performance gain when switching to Full and back again, in which case you'd always hide except we might want a DestroyLayout, or maybe we should call it a CleanupLayout or FreeResources message that really would ask for any resources to actually be freed. But the FreeResources message would be sent either if the layout is being destroyed, or if the Workspace is being destroyed, or if xmonad is about to quit. So calling FreeResources LayoutSwitch seems a bit of a misnomer (or calling FreeResources NonVisible would also be a misnomer, if you were thinking to release the windows when the workspace became nonvisible). So you've convinced me that two messages would be a Good Thing, but I'd vote for a Hide and a ReleaseResources message, with the latter being sent if we're going to discard a Layout (possibly because we're going to discard a Workspace) or before we exit (in which case it should always be called before we show the Layout). Note that in any case NonVisible must be treated as a superset of LayoutSwitch, since once a LayoutSwitch is received, NonVisible messages will *not* be received. i.e. anything that must be done in response to NonVisible must also be done in response to LayoutSwitch. -- David Roundy Department of Physics Oregon State University
On Mon, Sep 24, 2007 at 08:27:56AM -0700, David Roundy wrote:
So you've convinced me that two messages would be a Good Thing, but I'd vote for a Hide and a ReleaseResources message, with the latter being sent if we're going to discard a Layout (possibly because we're going to discard a Workspace) or before we exit (in which case it should always be called before we show the Layout).
Note that in any case NonVisible must be treated as a superset of LayoutSwitch, since once a LayoutSwitch is received, NonVisible messages will *not* be received. i.e. anything that must be done in response to NonVisible must also be done in response to LayoutSwitch.
Well, let me summarize, since I'm quite loosing myself. A layout must respond at least to 3 events: 1. a change in the stack -> UnDoLayout 2. a change in visibility: A. workspace got hidden B. LayoutSwitch -> the layout is not reachable anymore 3. xmonad is going to be restarted. We need 3 messages: Refresh, Hide, ReleaseResourcses (the third one for LayoutSwitch/restart). Or we could do it with 2 messages (Refresh/Hide) and a method for a mod-q restart. Which brings me to another consideration: should we add methods or messages? They seem to me equal in result. Andrea
On Mon, Sep 24, 2007 at 06:19:06PM +0200, Andrea Rossato wrote:
A layout must respond at least to 3 events: 1. a change in the stack -> UnDoLayout
UnDoLayout, which is actually useless, since we call doLayout within Operations.windows, right?
2. a change in visibility: A. workspace got hidden B. LayoutSwitch -> the layout is not reachable anymore
Still, if we cannot use Hide for both, so we free the resources in case of a layout switch. Right? I'm a bit slow... Andrea
On Mon, Sep 24, 2007 at 06:32:40PM +0200, Andrea Rossato wrote:
On Mon, Sep 24, 2007 at 06:19:06PM +0200, Andrea Rossato wrote:
A layout must respond at least to 3 events: 1. a change in the stack -> UnDoLayout
UnDoLayout, which is actually useless, since we call doLayout within Operations.windows, right?
Right, which brings us down to 2.
2. a change in visibility: A. workspace got hidden B. LayoutSwitch -> the layout is not reachable anymore
Still, if we cannot use Hide for both, so we free the resources in case of a layout switch. Right?
I don't see why "workspace got hidden" and LayoutSwitch differ. In both cases, the layout may later be reachable, and may not later be reachable. As long as we have a separate ReleaseResources message, I don't see why 2.A and 2.B shouldn't use the same message. Or more to the point, I don't see why we'd ever do anything differently, depending on which of these two events we received. I think we definitely need the ReleaseResources message for restarting or exiting xmonad, and for in cases where we end up discarding a Layout (due to either not wanting the layout any longer, or perhaps not wanting a Workspace any longer). If we wanted, we could combine "workspace/layout got hidden/deselected" with ReleaseResources, which would give layouts less flexibility to cache interesting resources, but I don't think I'd vote for this (although it was previously my preference). I agree that there can be cached data that is worth keeping around, so two messages seems optimal to me. -- David Roundy Department of Physics Oregon State University
participants (2)
-
Andrea Rossato -
David Roundy