[Question] Compatibility between scratchpad and swallow

[explosion-mental]

tldl, scratchpad terminal windows don't swallow.

The scratchpad patch uses the instance 'property' of the window. Seems to be ignoring the class of isterminal or something I don't quite understand.

Just curious if you notice or happen to stumble across this behaviour.

[bakkeby]

This would probably depend a lot on what scratchpad patch you use and what swallow patch you use.

For sake of reference let's assume that you are using the patches from this repository:

• renamedscratchpads
• swallow

The two patches are, for all intensive purposes, adding two separate pieces of functionality and they should have no direct conflict.

The only thing to note here is that the swallow patch adds two new client rule flags of isterminal and noswallow while the scratchpad patch adds a new flag scratch key.

When the two patches are combined you should sanity check the order of the rule options by looking at the Rule struct in dwm.c.

I'd expect it to look like this:

typedef struct {
    const char *class;
    const char *instance;
    const char *title;
    unsigned int tags;
    int isfloating;
    int isterminal;
    int noswallow;
    int monitor;
    const char scratchkey;
} Rule;

The class, instance and title parts of the client rules are filters which are used to match rules to clients. All the other fields are properties that applies to clients that match said rule. Note that by default in dwm a client window can match more than one rule.

The client rule, using the example from the patch, should then look like:

/* class  instance    title       tags mask  isfloating  isterminal  noswallow  monitor  scratch key */
{ NULL,   NULL,   "scratchpad",   0,         1,          1,          0,         -1,      's' },

As long as the isterminal flag is set to 1 then the terminal should be allowed to be swallowed. If the terminal doesn't swallow then maybe there is something wrong with your client rules?

Swallowing depends on being able to determine that the process associated with a window is a descendant of the terminal process, but this should not be an issue if swallowing works fine in a normal (non-scratchpad) terminal.

In terms of compatibility issues between the two patches let's say that you open a scratchpad terminal, then you run xclock. The xclock window takes place of the terminal window. Now if you want to be able to toggle the xclock window using the same scratchpad key then you will have to make the xclock window inherit the scratch key from the terminal.

This can be achieved by adding these lines to the replaceclient function:

diff --git a/dwm.c b/dwm.c
index 8735093..d156e75 100644
--- a/dwm.c
+++ b/dwm.c
@@ -1331,6 +1331,9 @@ replaceclient(Client *old, Client *new)
        new->tags = old->tags;
        new->isfloating = old->isfloating;

+       new->scratchkey = old->scratchkey;
+       old->scratchkey = 0;
+
        new->next = old->next;
        new->snext = old->snext;

[explosion-mental]

Wow... And if I quit xclock, would I be able to toggle the terminal as a scratchpad again?

For sake of reference let's assume that you are using the patches from this repository:

I use the ones from suckless site. I might migrate to renamedscratchpads just because what you mention about..

[bakkeby]

Wow... And if I quit xclock, would I be able to toggle the terminal as a scratchpad again?

Yes with the above changes the scratch key would be returned to the terminal again when the x window (xclock) closes.

I use the ones from suckless site.

As for using the swallow patch from there I presume that this *might* work out of the box due to how the same "client" is used for both windows. I can't think of anything besides a mix-up in the rules that would cause a scratchpad terminal to not swallow when using those patches.

[explosion-mental]

Hmmm okay looks like appending .isterminal = 1 to the scratchpad instance rule werks. Also toggle'ing on/off seems to also trigger the swallowed window.

My apologies, I had two scratchpads with the same instance name and the rule wasn't applyied correctly, and thank you very much.