nclarius / KWin-window-positioning-scripts

KWin scripts controlling window placement on multi-monitor setups
GNU General Public License v3.0
59 stars 14 forks source link

[Always Open on Active Screen] "fits on screen" enhancement? #5

Closed joedefen closed 2 years ago

joedefen commented 2 years ago

I've been very frustrated with KDE's window placement after adding a huge monitor to go with several others. E.g., it always, regardless of window rules or history, KDE places new Chrome windows straddling the same two windows with the same size. Arrrgh!

The always-open-on-active-screen script almost gets me to Shangri-La. At least, it gets the window to the screen it is launched. But, the new windows are often oversized and/or partly off screen; so, there is often yet more manual manipulation to do.

Do you think forcing the new window to fit within the screen is a desirable feature to add to all your always-open scripts (or maybe just -active-screen)? If so, I'll make a contribution to your project if I get that enhancement working to my satisfaction. Or do you consider the current behavior sometimes more desirable? If so, then I'll try to create an alternative script (unless you desire multiplying your placement scripts).

nclarius commented 2 years ago

I think it's good to have a 'always open on x screen' script that does just that.

But maybe I can help you solve the other issue sepearately.

Did I understand it correctly that you tried both window rules and enabling/disabling the 'allow programs to remember their position' option in the window behavior setting? With window rules, note that the x and y coordinates are calculated not relative to each screen, but to the workspace with all screen combined, starting from the leftmost/topmost edge.

Can you describe more precisely what the expected and what the actual behavior is?

joedefen commented 2 years ago

Does "it's good" mean it is best to enhance always-open-active-screen or create another?


Re: "Can you describe more precisely what the expected and what the actual behavior is?". My duh. I had a misnamed, overly generic window rule that caused the poor Chrome placement. Still, using always-open-active-screen, some apps are not fully on screen. So the feature request is not fully negated by my carelessness ;-)

joedefen commented 2 years ago

BTW, this code for always-open-active-screen seems to do the trick for me.

/*
KWin Script Always Open on Active Screen
(C) 2021 Natalie Clarius <natalie_clarius@yahoo.de>
GNU General Public License v3.0
*/

workspace.clientAdded.connect(moveToActiveScreen);

function moveToActiveScreen(client) {
    if (client == null || !client.normalWindow) {
        return;
    }
    workspace.sendClientToScreen(client, workspace.activeScreen);
    if (client.moveable) {
        /* Force the window to fit in the screen */
        var maxArea = workspace.clientArea(KWin.MaximizeArea, client);
        width = Math.min(client.width, maxArea.width);
        height = Math.min(client.height, maxArea.height);
        x = client.x
        if (x < maxArea.x) {
            x = maxArea.x;
        } else if (x > maxArea.x + maxArea.width - width) {
            x = maxArea.x + maxArea.width - width;
        }
        y = client.y
        if (y < maxArea.y) {
            y = maxArea.y;
        } else if (y > maxArea.y + maxArea.height - height) {
            y = maxArea.y + maxArea.height - height;
        }
        client.geometry = {
            x: x,
            y: y,
            width: width,
            height: height
        };
    }
}
nclarius commented 2 years ago

I was thinking a separate script, but on second thought, that carries the risk of them not being applied in the right order, so I'll incorporate your suggested enhancement into the existing script.

Thanks a lot! I think if you make a pull request, you will be listed as an official contributor.

joedefen commented 2 years ago

Looking forward your update (so I can remove my custom version) ... no credit needed ... just happy to reach KDE Shangri-La with your help. I'll continue testing and report any failings, but the revision looks good so far to me.

nclarius commented 2 years ago

Updated, with a minor prettification in the code. I successfully tested it on my setup; let me know if anything is not the way you intended.

Re. the move one screen up/down/left/right:

In order to determine the screen layout with a KWin script, for lack of a given function in the API I think you'd have to compare the x and y coordinates of the client area for each screen: Initially and on each screen setup change, traverse the client list, which includes a desktop background window for each desktop and screen, and get the x and y properties of the respective client area with a note which screen the window was on. Then keep one left-to-right list and one top-to-bottom list of screen numbers sorted by their x and y values, and probably one also wants to filter the screen moving by which screens are on the same horizontal/vertical level so encode that as well. Then in the move to screen functions, determine the window's current screen's position in the grid and send the client to the screen at the previous/next index on the same column/row.

Doing that in a precise way probably gets a bit lengthy (unless there is a more elegant way I'm overlooking) and I don't have all that much use for it myself, so you may gladly take over turning that into an actual implementation if you feel up to it.

nclarius commented 2 years ago

Cont.: Or if you just want it for yourself and on always the same screen setup, you could test if the assignment of screen numbers to monitors is the same across reboots and then simply hardcode the screen numbers into the direction functions.

joedefen commented 2 years ago

Thanks for the suggestions. KDE has made improvement to its built in windows movements like fitting windows to the new screen. I do prefer ALT-H/J/K/L vi mnemonics for left/up/down/right to move windows rather than KDE's choices, but the benefit seems quite marginal for the effort. I'll likely just be remain content with the status quo, but if not, you've provided a head-start. Thanks.

nclarius commented 2 years ago

Not sure I understand; which benefit is still missing if you map the built-in window moving function your preferred shortcuts in the system settings?

Anyway, glad you achieved an improvement.

nclarius commented 2 years ago

(Yesterday's version contained an error; please update again if you're having issues.)

joedefen commented 2 years ago

The script is working great, btw, and I'm using it constantly. It has removed the need for most of my window rules as a huge benefit, too.

I hate to bother and I have (I hope) some very trite questions about kwin scripting and I must have something very wrong. Maybe you can spot it if you wish. I've read the tutorial and the little that I can find by googling to no avail.

Can you offer a hint how to get something working (i.e., am I clueless or is my system somehow broken)? Thanks.

nclarius commented 2 years ago

It's not you, it's a bug in the scripting console: https://bugs.kde.org/show_bug.cgi?id=445058

I always just put console.log statements in the script, reinstall the script, restart kwin and examine the output of that in the ordinary terminal.

joedefen commented 2 years ago

Thanks. You saved me from continuing to beat my head against the wall.