[BUG] scratchpads: excludes = "*" not working correctly

[punk-dev-robot]

Pyprland version 2.4.0

Describe the bug See the steps below and attached video

To Reproduce I have multiple scratchpads that have excludes = "*" set. For simplicity i picked 2 of them to show unexpected behaviour: dropterm and top

Steps to reproduce the behavior:

1. Everything works fine if I just toggle term and top (show and hide)
2. Than i show term again, and next, without hiding term i toggle show top - this seems to be working fine, term is hidden and only top visible
3. Now when I use toggle to hide top and term surprisingly shows up, and in the wrong place too

Expected behavior

after hiding top in step 3 no scratchpads should be visible

Configuration (provide following files/samples when relevant):

[scratchpads.dropterm]
animation = "fromTop"
# command = "kitty --class term-drop --config /home/kuba/.config/kitty/qterm.conf tmux new -A -s dropterm"
command = "kitty --class term-drop --config /home/kuba/.config/kitty/qterm.conf tmux attach -d -t dropterm"
class = "term-drop"
size = "90% 90%"
max_size = "1920px 90%"
excludes = "*"

[scratchpads.top]
animation = "fromBottom"
command = "kitty --class kitty_btm --config ~/.config/kitty/qterm.conf btm"
class = "kitty_btm"
size = "90% 90%"
max_size = "1920px 90%"
excludes = "*"

Additional context Add any other context about the problem here.

https://github.com/hyprland-community/pyprland/assets/3915056/2a9327cd-ed07-4b7e-b275-679fb104b3b5

[axelKeizoStahl]

This bug is not exclusively if you have 2 scratchpads that exclude, since it comes when only one does. If you have 2 scratchpads, excludes and normal, this is the problem (Here I use discord as excludes, and term as normal:

1. open excludes
![screenshot_2024-07-07-100735](https://github.com/hyprland-community/pyprland/assets/116924011/5e629965-ded6-49ea-88d4-e98877e38969)

2. open normal (excludes is  beneath)
![screenshot_2024-07-07-100745](https://github.com/hyprland-community/pyprland/assets/116924011/225ddee3-8220-44a5-ac9c-6eee94d0e8e6)

3. close excludes
![screenshot_2024-07-07-100756](https://github.com/hyprland-community/pyprland/assets/116924011/981cf799-7ddc-4bf9-9621-eeea84f4b2be)

4. open excludes (normal disappears)
![screenshot_2024-07-07-100803](https://github.com/hyprland-community/pyprland/assets/116924011/f6cd7239-aed9-48b1-a398-6b7fb9a3af33)

5. close excludes (see next step)
![screenshot_2024-07-07-100811](https://github.com/hyprland-community/pyprland/assets/116924011/659086be-6268-4c10-8e32-a2a1b168dc08)

6. normal shows itself in the wrong  place, but it's state seems to be off because if you toggle it  again it goes to the right   place

If you look at step 5's screenshot, it runs dispatch focuswindow address:0x55717cea5180 (focusing to the normal window). However, it does not run the commands that should be run to show/focus a scratchpad:

scratchpads - dispatch ['moveworkspacetomonitor special:scratch_term HDMI-A-1', 'movetoworkspacesilent 4,address:0x55717cea5180', 'alterzorder top,address:0x55717cea5180'] // ipc.py:144

scratchpads - dispatch ['movewindowpixel exact 2160 50,address:0x55717cea5180'] // ipc.py:144

When this mentions open/close it uses the toggle command.

[axelKeizoStahl]

I can/will fix this issue very soon. There are 2 options though:

1. Keep the window closed that was closed by an excludes scratchpad
2. Open the scratchpad back up after the excludes scratchpad is open.

I think option 1 is best, but both have merit.

[fdev31]

Thank you for looking at it! I'm a little more busy than usual those days and really appreciate!

Le dim. 7 juil. 2024, 16:19, Axel Stahl @.***> a écrit :

I can/will fix this issue very soon. There are 2 options though:

1. Keep the window closed that was closed by an excludes scratchpad
2. Open the scratchpad back up after the excludes scratchpad is open.

I think option 1 is best, but both have merit.

— Reply to this email directly, view it on GitHub https://github.com/hyprland-community/pyprland/issues/118#issuecomment-2212466751, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB2IHV2QAJFSRNKDIWCEK3ZLFE7PAVCNFSM6AAAAABKM6CIA2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJSGQ3DMNZVGE . You are receiving this because you were assigned.Message ID: @.***>

[axelKeizoStahl]

121 addresses this.

@kuba-gaj Until #121 gets merged, just set smart_focus to false under whatever scratchpad.

[fdev31]

I'm not really a user of this feature and didn't try the PR yet, but you implement some kind of memory of the excluded scratchpads to recover them ? Or is it really a bug which is fixed ? I'll look at it more in details later, it's not a small change and adds extra "heavy" show calls but thank you pals it looks interesting, I'll take time to test that later this week.

[axelKeizoStahl]

Ah you're right, I think I will change the PR to solely fix the bug. I think this may be an interesting feature, but there might be a better implementation. I will raise a feature request for this.

[fdev31]

I'm fine with the feature too... but should be conditional then... ideally in two different PR but it's OK if you don't split....

[punk-dev-robot]

Thank you both @axelKeizoStahl @fdev31 .

For now I disabled smart_focus on all my scratchpads and it works fine. It's not even clear to me what it was doing, maybe because i always have just single scratchpad it wasn't useful to me :)

[fdev31]

It's not even clear to me what it was doing, maybe because i always have just single scratchpad it wasn't useful to me :)

It's only useful when you have more than one monitor and use animations overlapping on another monitor... maybe I should only enable it in such case.

[fdev31]

Latest git commit should do the job as far as I understand...

[fdev31]

My point on smart focus:

• it's not sane, it should either become very complex over time or be killed
• I didn't find a better solution for it at the moment
• Workarounds include not using animations, or having default animations not leave the screen when hidden...

I will appreciate any idea about that. The poor workaround would be to limit its usage as much as possible, but ideally I would like to find a more generic solution to this problem, focusing the workspace back didn't work for me the last time I tested it...

The issue it fixes is:

• Given hiding a scratchpad which will float over another monitor when hidden
• then the focus of the current workspace can be lost (at least last time I tested without it)
• then it tries to recover this focus by remembering the last focused window

[punk-dev-robot]

Thank you both again, I will try and test later today.

Slightly out of topic but @axelKeizoStahl you mentioned that you use discord - but it is the only app I failed to configure, tried different match_by, disabling process_tracking and whatever else but it also fails and makes all scratchpads unusable (with window error even though processes are still running). I suspect it has something to do with this update popup they have on start. Would you mind sharing your config for discord?

@fdev31 Given all the above, what are the reasons that even with process_tracking disabled it looks like there is some kind of tracking going on and it crashes? Why not just make process_tracking = false dumb like:

1. Is there at least 1 match? 2a. YES - toggle all/first matches 2b. NO - execute the command

[punk-dev-robot]

Thinking about it I would appreciate this simplified option that would only match and leave process / window management to me, only toggling as it is by selector, no command, no starting, window tracking etc

[axelKeizoStahl]

I just use a pwa for discord, because you can't use discord with how scratchpads are now, since the update manager is already running. I suggest you open a bug report issue, I'll take a look into this. :+1:

[axelKeizoStahl]

Thinking about it I would appreciate this simplified option that would only match and leave process / window management to me, only toggling as it is by selector, no command, no starting, window tracking etc

And perhaps a feature request for this?

[fdev31]

Thinking about it I would appreciate this simplified option that would only match and leave process / window management to me, only toggling as it is by selector, no command, no starting, window tracking etc

Something like a dummy mode sounds like a good idea... Now I really don't have much time but if nobody picks it up I may... you can open a feature request for that.

[fdev31]

I pulled up a couple of different ideas, it could either be something like externally_managed = true

or mode="dummy" and I would also add "pwa" which would match_by="class" + process_tracking=false

Lastly, and this is my preferred option, it could be the default behavior if no command is provided instead of requiring it...

But first of all: why would you want that / what is the use case?

[punk-dev-robot]

Hey, sorry for the late response, been very busy.

I can think of couple of ways how that could be useful:

• one is for problematic apps like discord mentioned above - I could not make it work with any combination of existing options
• sometimes an app that I have in scratchpad crashes (or I close it by mistake) - at the moment pyprland will start throwing errors and I don't know how to recover, what is worse it will often stop working for other scratchpads and I have to reboot the system as I depend on them a lot
• I think it may be very useful for people wanting simple scratchpads, we are used to windowrules, it would be great to easily say "if there is a window matching toggle it, otherwise if there is an exec run it, else do nothing"

Sorry for keeping it here, let me know if I should start future request

[fdev31]

Got it. I'm still not very available so opening a ticket would be great.

Le ven. 12 juil. 2024, 20:48, Kuba Gaj @.***> a écrit :

Hey, sorry for the late response, been very busy.

I can think of couple of ways how that could be useful:

• one is for problematic apps like discord mentioned above - I could not make it work with any combination of existing options
• sometimes an app that I have in scratchpad crashes (or I close it by mistake) - at the moment pyprland will start throwing errors and I don't know how to recover, what is worse it will often stop working for other scratchpads and I have to reboot the system as I depend on them a lot
• I think it may be very useful for people wanting simple scratchpads, we are used to windowrules, it would be great to easily say "if there is a window matching toggle it, otherwise if there is an exec run it, else do nothing"

Sorry for keeping it here, let me know if I should start future request

— Reply to this email directly, view it on GitHub https://github.com/hyprland-community/pyprland/issues/118#issuecomment-2226177237, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB2IHQTNP4THR4BWSSLZYLZMAQGRAVCNFSM6AAAAABKM6CIA2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRWGE3TOMRTG4 . You are receiving this because you were mentioned.Message ID: @.***>

[fdev31]

About the discord issue: if someone can share a config I'll have a look. Is it discord "native" ? Those are really crap, why not using a browser window? it's more or less handled well in scratchpads when well configured...

[punk-dev-robot]

Yes it's the official discord app: https://archlinux.org/packages/extra/x86_64/discord/ It's running some other updater window first that it kills after a couple of seconds, I think that is the issue. For now I switched to pwa (with --app=<url> instead of --app-id to remove window decorations) and it works good enough.

I'm thinking about moving most of my apps to be managed by systemd for:

• easy / automatic restarts
• easy access to logs
• managing dependencies on other apps (like kitty window with tmux session on tmux)

Having a mode where I can just specify window rule for pyprland and get scratchpad functionality for them without any tracking would be useful

[fdev31]

I'll open a new FEAT ticket and refer to this one, which I'll close. We can continue the discussions there.