Sorry for the delay! Was out for a bit. Checking hyprctl clients -j, there is only one window with the Spotify class, both with the scratchpad is present and hidden.

I am currently on arch linux and my config remains unchanged, would be happy to try out an earlier version of pyprland though would require some guidance on how to go about setting that up! I could also try an earlier version of spotify if it is a spotify update that caused the error.

You can start with yay -G pyprland-git and add some "git checkout [version]" somewhere to force the version...

Can you dump the result of the command you tried to see what is the difference (when it's visible or not) ?

Reverting to pyprland version 2.0.4, spotify works as intended on startup again. There is an odd error with qalculate not working when started via terminal, causing a large degree of lag before pyprland works as normal - but that is only present when pyprland is killed, and then started again manually via the terminal for debugging purposes. Pyprland for spotify works correctly and as intended. The log looks as follows:

[086 16:11:22.113634] Ignoring invalid config line: 'url_excluded_characters'
[086 16:11:22.114107] Ignoring unknown config key: resize_draw_strategy
[086 16:11:22.170149] [glfw error 65544]: process_desktop_settings: failed with error: [org.freedesktop.DBus.Error.UnknownMethod] No such interface “org.freedesktop.portal.Settings” on object at path /org/freedesktop/portal/desktop
⚠ Failed spawning calc as proc 13821
"qalculate-gtk": The command didn't open a window
Failure starting calc
[2024-03-26T08:11:36Z INFO  spotify_launcher::config] Loading configuration file at "/etc/spotify-launcher.conf"
[2024-03-26T08:11:36Z INFO  spotify_launcher] No update needed
spotify: /usr/lib/libcurl-gnutls.so.4: no version information available (required by spotify)
/home/adi/.local/share/spotify-launcher/install/usr/share/spotify/spotify: /usr/lib/libcurl-gnutls.so.4: no version information available (required by /home/adi/.local/share/spotify-launcher/install/usr/share/spotify/spotify)
/home/adi/.local/share/spotify-launcher/install/usr/share/spotify/spotify: /usr/lib/libcurl-gnutls.so.4: no version information available (required by /home/adi/.local/share/spotify-launcher/install/usr/share/spotify/spotify)
/proc/self/exe: /usr/lib/libcurl-gnutls.so.4: no version information available (required by /proc/self/exe)

The failed spawning calc part is in red and is what causes the lag, but this is not present when pyprland is started on execution and only when it is started via terminal, so I think it's just some issue with the program itself. Key point is that reverting to 2.0.4 fixes the issue with spotify.

Okay, weirdly enough - after a system update, everything works normally even with pyprland 2.0.9 - however a different bug is present T-T, not sure if I should make a new thread or issue regarding this, but the margins and sizings no longer work. The config is the exact same, but the scratchpads display wonky on only half the screen, partially cropped. Everything works fine if no margin/size is provided and the windows are sized manually, however if a size is provided, they look like this:

Note that the window itself should look like this:

And it is cropped in the scratchpad, and funnily enough the result of calculations are invisible. This issue persists regardless of the type of scratchpad (term, spotify, calculator, etc.)

My config looks as follows:

[scratchpads.spotify]
command = "spotify-launcher"
animation = "fromBottom"
class = "Spotify"
class_match = true
process_tracking = false
size = "1920px 800px"
max_size = "1920px 100%"
position = "100% 10%"

[scratchpads.term]
animation = "fromTop"
command = "kitty --class kitty-dropterm"
class = "kitty-dropterm"
size = "75% 75%"
max_size = "1920px 100%"
margin = 100


[scratchpads.calc]
animation = "fromTop"
command = "qalculate-gtk"
class = "qalculate-gtk"
size = "60% 60%"
max_size = "1920px 100%"
margin = 100

I am unsure if a recent update in hyprland or some other graphics dependency messed up the margins and window sizes. The issue I noticed was that the first set of numbers in size, max_size, and position, had no effect whatsoever on the final result.

i.e.
size = "100% 10%" / position = "100% 10%"
gave the exact same result as
size = "20% 10%" / position = "20% 10%"

The second value would have an effect as expected.

Good news, I reworked related things in 2.0.9:

• sliding effect offset is now based on window size & margin

but that shouldn't break the size or the position or the margin, it should only affect "offset" auto-computation.

In your comment, I understand that only "size" is broken/ not working as expected.
Do you confirm / do you have something to add to this statement?

Also it would be helpful to:

• provide pypr logs
• tell if lazy=true changes something in the behavior

Edit: when you are testing, try "pkill" the app which causes problems before starting pypr again (eg: calc app)

Weirdly enough, on update it fixed itself again. T-T, so I guess everything works as intended now!
Though fwiw, every positioning and sizing tag was broken - size, position, margin, etc.

Though everything works now! Thank you for your help and patience so far :)

I guess yes, it's a bit out of my competence here but it seems like this is the most probable origen of the problem... could be worth trying with older hyprland versions to see if it was working before making the bug report ?
(in case it's a regression starting from a specific version it will be easier to identify & fix...)

Hyprland issue hyprwm/Hyprland#5101

Btw, are the latest versions fixing (or rather avoiding) this issue?
It nows uses hyprland itself to set the layout...

No it doesn't. I'm giving up on making the monitors plugin work. It is too buggy on my system, hard-coded monitor rules have been working much smoother for me.

Hm, this is very strange... how it currently works is supposed to achieve the same as a static configuration (it's using the same API). If you can give it a try later and show some logs I'll have a look (or maybe with https://github.com/fdev31/wlr-layout-ui which I also updated to avoid usage of an external tool...).

Any package available on the python instance running pypr (using virtual env or not) can be used.
I'm not familiar with NixOS but this should be possible.
You can also manually do it, by adding your "extra package" somewhere, then add it to your PYTHONPATH environment.

PS: Immutable or not, you probably have a "home" and can write to it... either adding a virtualenv or some plain python packages folder.

Thank you for the fast reply, but I'm not sure if I understand what you mean. NixOS containerises packages and their dependencies so the python instance that pyprland uses is separate from everything else. Customisations like extra packages are usually done trough overrides that would look something like this:

home.packages = [
(pyprland.override { extraPackages = [ pkgs.nerdfonts ]; })
];

This means that I don't even have a PYTHONPATH variable and if I try to define it it is ignored.

Do you mean a program installed on nix can't access your files at all ?
Then I guess you need to make a nix package for your python extension and add it as a dependency, or something similar... maybe you'll find more help on the hyprland-community discord since I know more or less nothing about nix but I know some others do ^^

Edit: maybe a silly idea: make your own fork, your extensions will never conflict so rebase should be trivial... then use your git url instead of the upstream one for your package...

I was thinking about doing that or even adding an option to specify the PYTHONPATH and making a pull request. I guess I will be doing the latter.

Edit: A program on nix can access my files but I can't interact with its environment so I can't change the PYTHONPATH variable. I am pretty inexperienced with nix myself which is why I'm running into this issue in the first place.

A PR to pass a extra path for plugins will be welcome :)

I'm not a nix user but a few are, including @NotAShelf. Hope someone will be able to answer.
From the little I know from nix or any packaging system, it should be doable without any problem, but I don't think that's the correct way of configuring it. Why not just using the config files in the expected way?

pyprland currently doesn't have a module that handles managing configuration files, so you would have to find a way to write files to their respective locations

nixpkgs has writers for a variety of formats, which you can use in tandem with home-manager's xdg.configFile

or you can write the filed manually and link them using home-manager

Hi - I want to use Pyprland in NixOS. What is the proper way of configuring it? I would like my configs to stay in the .nix file, if that's possible.

I hope someone will help me. Thank you.

Just a couple of hints that allow some flexibility regarding the configuration file location, you can point at a custom file path (or folder that will contain .toml files):

[pyprland]
include = ["~/.config/hypr/pyprland.d"]

You can also change the "main" config file path by using the --config argument when starting pyprland.

my bad scratchpads are special workspaces. just run hyprctl clients.
I am on hyprland 0.41.0 btw.

And good morning! ;)
Indeed that is a "known problem" which I never solved because nobody ever asked (and it's "good enough" for my use case).

In short today each plugin is fully autonomous-independent by design.

Hyprland 0.41.0 brings some new feature which would allow tagging windows to better handle them in such scenarios.

Anyway, the code wasn't even trying to manage that a little, I pushed a commit in git that should improve the situation without relying on anything new.

I believe the main (or only?) problem remaining for your use case is that the scratchpad will not be "raised" on top.... actually it's relatively hard to predict if the user wants the scratchpad on top or the main window, what is your view about it?
Are you able to test the git version to comment it?

goodmorning,

i will try the git version this evening or tomorrow and let you know. Actually i have two different use cases that are effected. the first one is the most normal one , use neovide in a scratch pad to do all the my code editing in a centralized view iso using multiple terminals all with different instances of nvim.

The second one is more debatable from a scratchpad perspective and a temp workaround. i am running tclock in a foot terminal to display a clock above the centralized window. basically as a kind of clock widget that i turn of when the layout is not centralized. This actually would be better handled by a clock widget in the overlay layer but did not find a suitable one. At least not until the bar i am using ( ironbar) releases its next version which would allow to do exactly that.

I was already thinking about the new tags in hyprland but then actions like movefocus or cyclenext should be tag based

Summary will let you know later :-)

goodmorning,

unfortunately your changes did not fix much , it did swallow a layout-center next when a scratchpad is active but for the rest the same symptoms. but dont worry to much will spend some time adapting the plugin to my own needs.

Regards
Bert

Good day :)
I'm not fully understanding "the same symptoms", the problem you described about having the scratchpad considered in the layout is gone isn't it?
I highlighted the Z order will probably not be as expected but which other unexpected/undesired behavior are you facing?