Schweber
commented
3 weeks ago hdrop just gives the appropriate commands to hyprland to move windows between the present workspace and a special workspace named hdrop (to "hide" them until they're called back).
The relevant commands that hdrop uses are these (removed unessential parts for clarity):
hyprctl dispatch -- movetoworkspacesilent "$ACTIVE_WORKSPACE","^$CLASS$"
hyprctl dispatch -- focuswindow "^$CLASS$"
hyprctl dispatch -- movetoworkspacesilent special:hdrop,"^$CLASS$" In my opinion, hdrop doesn't cause the behaviour that you describe. Rather, it exposes a shortcoming in hyprland that usually goes unnoticed because most people don't use hyprland the way hdrop does. In my opinion, hyprland shouldn't allow windows to have a bigger size than the monitor they're presently on.
To be clear, you're talking about floating windows that behave this way?
Program
hdrop
Maintainers of the program
@Schweber
Bug or Regression?
Bug
Description
I'm using hdrop in a multimonitor setup. My lower and higher monitor have different size and ratios expressed on the config, this way: monitor eDP-1, highres@60, 0x1080, 2.5 monitor HDMI-A-2,highres,0x0, 2
the eDP monitor has (so to speak) less pixels than the HDMI-A-2, because the scaling between both monitors is different.
When using hdrop, my terminal doesn't change size between monitors so it becomes higher than the available size if the window was started on the bigger one, or smaller (which is sort of an OK workaround for now) if started on the smaller one.
How to reproduce
Use two monitors or more. Give them different scaling. Open a program with hdrop and then bring it to the background, later bring it to the foreground in a different monitor.
Hyprland crash reports, program logs, images, videos
No response