12:20:34

http://pastebin.com/4KSJnA1D

Updated the patch, it adds handling of ACTION_GOTO_WORKSPACE. Through testing I realized that simply using "PWinObj::getFocusedPWinObj();" is not good enough, because many Actions that change focus only cause X-server requests to change the focus, while the Pekwm internals are not updated, thus invoking the method will not cause the new focused window to really be considered.

Strangely enough, the GoToWorkspace code DOES update the pekwm structure to consider the new focused window after swapping workspaces, so it works for that particular case.

I don't know if more actions need a context update, specially the others where the "newly focused" window cannot be easily known by the user (eg: closing a window).

11:06:50

Giving this to IOError, he noted that it is 0.1.13 in #pekwm.

10:33:32

Okay, I did some more reading of the code, and it appears I can also update the context by simply invoking "PWinObj::getFocusedPWinObj();"

Would a cleaner patch that simply sets "update_context = true" and then retrieves the focused window from the aforementioned method be preferred to the current proposal?

EG: case ACTION_GOTO_WORKSPACE:

   actionGotoWorkspace(it->getParamI(0), (ap.type == MotionNotify) || (ap.type == EnterNotify));
   update_context = true;
   break;

Then the loop update would read like: if (update_context) {

  update_context = false;
  if (wo != PWinObj::getFocusedPWinObj()) {
     ...
  }

}

Blah blah blah, rather than modifying the return values of some key functions? I do suppose a simpler patch would have a higher chance of making it into the tree.

13:54:03

Attached file from pastebin.

13:30:19

Hmm, I don't see the link for submitting a patch, so here goes a pastebin link: http://pastebin.com/NjznGisc

This patch (against current Git) applies the methodology I just proposed for the following cases:

ACTION_FOCUS_DIRECTIONAL ACTION_ACTIVATE_CLIENT_REL ACTION_ACTIVATE_CLIENT_NUM ACTION_DETACH ACTION_ATTACH_CLIENT_IN_NEXT_FRAME ACTION_ATTACH_CLIENT_IN_PREV_FRAME ACTION_ATTACH_FRAME_IN_NEXT_FRAME ACTION_ATTACH_FRAME_IN_PREV_FRAME ACTION_NEXT_FRAME ACTION_NEXT_FRAME_MRU ACTION_PREV_FRAME ACTION_PREV_FRAME_MRU ACTION_FIND_CLIENT ACTION_GOTO_CLIENT_ID

These were easy to spot. I am not sure we want to update the context in situations where the new focused window is "unpredictable" (eg: closing a window), but really, what kind of behaviour should a user expect if he specifies a chain like "close; toggle maximized"? Should the window be closed and the whoever gets the focus next be maximized?

In any case, I am running a patched Pekwm to test this, and it seems to work very well so far (and as expected).

11:21:48

Good observation there, that might actually do the trick. Might produce some funky focus behaviour, as I'm not sure if the actual focused object is updated (or used) in all actions.

10:10:31

Hmm.... a year old report. Anyway, I have some interest in getting this "fixed," so I was reviewing the current git code for ActionHandlers.

It appears that ActionHandler::handleAction already handles multiple actions in order, the problem is that the "context" is not updated during the chain.

The context is obtained from ap.wo, and is never changed while executing the chain. However, I am pretty sure most users would want the context to be updated after certain events that change the currently focused window.

Shouldn't ap.wo be updated (and client,frame,decor as well) after handling the following events?

(focus change) ACTION_FOCUS_DIRECTIONAL ACTION_CLOSE ACTION_CLOSE_FRAME ACTION_KILL ACTION_SEND_TO_WORKSPACE ACTION_GOTO_WORKSPACE

(client in-frame change) ACTION_ACTIVATE_CLIENT_REL ACTION_ACTIVATE_CLIENT_NUM

(Frame change) ACTION_DETACH ACTION_ATTACH_MARKED ACTION_ATTACH_CLIENT_IN_NEXT_FRAME ACTION_NEXT_FRAME ACTION_NEXT_FRAME_MRU ACTION_PREV_FRAME ACTION_PREV_FRAME_MRU ACTION_ATTACH_CLIENT_IN_PREV_FRAME ACTION_ATTACH_FRAME_IN_NEXT_FRAME ACTION_ATTACH_FRAME_IN_PREV_FRAME

Unfortunately I don't understand the underlying logic enough to understand what's the risk in simply updating the local variables on each iteration of the actionHandler list after the given actions (I wouldn't even know how to get the new Window Object for several of them!), but I guess I could try on my local copy of Pekwm for those I understand and see how it behaves.

19:35:04

Some sort of synchronization is required here indeed, but there's quite a few things to think about doing this:

• How do we avoid loops in actions?
• How many events should we process before continuing to process actions?

Making things a bit simpler might be that actions such as FocusDirectional actually updates pekwm's idea of what is focused even though the window has not yet been focused (a request has just been sent which would avoid leaving the action handler to achieve this.

Are there any other actions than focus related actions that require special handling?