Suggestion: kwinscript argument

[marvin1099]

Would it be possible to have like a argument to pass in a kwin script.
For custom kwin requests and returned values.

Like then something like windowlooking may be used with something like this:

var locked = false;

function toggleLock() {
    var client = workspace.activeClient;
    if (!client) return;

    locked = !locked;
    client.resizeable = !locked;
    client.moveable = !locked;

    workspace.showOnScreenDisplay(
        "Window " + (locked ? "Locked" : "Unlocked")
    );
}

This code may be wrong, have not checked it yet.
But this would not be your issue.
Just asking for a easy run return system for kwin scripts.

Edit:
resizeable and moveable are read only, sad.
Same with the layer property.
There still are limitations even with direct control.
But still some nice things to do with direct kwin control.

[jinliu]

I don't get it. Which part is the "argument to pass in" in the above example?

[marvin1099]

I meant sothing like:
kdotool kscript ~/Downloads/hello-world.js

A fitting script may output:
Hello World

I the cli

The argument(s) here is(are) just:
kscript ~/Downloads/hello-world.js
(technically thats 2 arguments passed to kdotool)

So i meant a new argument for kdotool (like "kscript", that is probably a as good as any argument string, but "kwinscript" would also work).
Another argument that exists (as example):
kdotool getmouselocation

Here getmouselocation is the first argument passed to kdotool.

[marvin1099]

Argument to pass in to the kwin script would be interesting but i dont even know if that could be suported, if that works as well, it would be nice to have.

Like:
kdotool kscript ~/Downloads/search-some-property.js searchterm

A fitting script for this may use the argument given to it as searchterm.
So kdotool has 3 arguments here and would pass every thing after "kscript ~/Downloads/search-some-property.js" as argument to search-some-property.js

If that would be suported props, but i really mostly just want to run kwin scripts with cli return.

[jinliu]

So IIRC, you want to run your own script (instead of the one created by kdotool from your command line), for one time, and get some output (probably using similar mechanisms that kdotool uses for its own scripts)?

That's an interesting idea. The simplest way to implement it seems to be that we treat "kscript ~/Downloads/search-some-property.js" as inserting a code snippet just as other commands does. E.g.,

kdotool getactivewindow kscript ~/Downloads/search-some-property.js windowmaximize would upload a js code like:

kdotool header code
getactivewindow code
~/Downloads/search-some-property.js code
windowmaximize code
kdotool footer code

And your code can access the window stack via the window_stack variable, and output via output_result, just like other kdotool commands internally do.

Would this solve your problem?

[marvin1099]

I think there may be a small misunderstanding, so let me try to clarify my idea a bit better.

kdotool already has many built-in commands that internally talk to KWin, for example:

kdotool getmouselocation

This retrieves the mouse position from KWin (similar to how xdotool would do it on X11).

What I’m proposing is not inserting snippets between existing internal commands, but rather adding a simple way to execute a custom KWin script directly via the CLI, for one-time execution, and optionally get a return value.

Something like:

kdotool kwinscript /path/to/script.js

The goal is simply:

• Run arbitrary KWin JavaScript code
• Let it interact with the workspace/clients
• Optionally print something back to stdout (similar to how internal kdotool commands return values)

For example, using the window lock logic I mentioned earlier:

Example 1 – Toggle lock of active window

kdotool kwinscript toggle-lock.js

Where toggle-lock.js might:

• Get workspace.activeClient
• Toggle moveable / resizeable
• Output "Locked" or "Unlocked"

The file toggle-lock.js would probably have code like i already mentioned.

Example 2 – Query lock state of a specific window

kdotool kwinscript get-lock-state.js <window-id>

The script could:

• Accept a window ID
• Find the matching client
• Return whether it is currently moveable/resizeable
• Print true / false (or similar) to stdout

If argument passing is possible (everything after the script path being forwarded to the custom js script given by the user), that would be great — but even without argument forwarding, just being able to execute custom scripts and retrieve output would already solve my main use case.

So in short:
I’m mainly looking for a clean CLI entry point to run custom, one-shot KWin scripts via kdotool, with stdout return support — similar in spirit to the existing internal commands, but user-defined.

Hope this explains it better.

[marvin1099]

If it helps move this forward, the implementation should fit pretty naturally into the existing structure, every subcommand already builds a JS string and hands it to the internal KWin script runner. A kwinscript subcommand would just skip the generation step and pass the user's script straight through.

Rough pseudocode sketch (all within the existing subcommand match in main.rs):

// new variant alongside the existing ones in the Commands enum
Kwinscript {
    --file  <path>    // read script from a .js file
    --inline <string> // or pass it directly as a string
    // (the two as a clap exclusive group)
}

// in the match block:
Kwinscript { file, inline } => {
    let script_body = match (file, inline) {
        (Some(path), _) => read_file_to_string(path),
        (_, Some(text)) => text,
        _               => error_out("supply --file or --inline"),
    };

    // no generation needed, just forward to the same runner:
    run_kwin_script(context, &script_body)
}

So usage would be something like:

kdotool kwinscript --file my_lock_toggle.js
kdotool kwinscript --inline "workspace.activeClient.minimized = true"

The existing --dry-run flag would also work for free, which is handy for debugging custom scripts.

One thing worth thinking about: if the script produces output (via print() or a DBus callback), should it be forwarded to stdout the same way getwindowname etc. do?
The existing output-capture path would handle it,
the user's script would just need to use the same callDBus(...) pattern the generated scripts use. Might be worth documenting if so.

Discamer as i have no rust or kde coding expertise this implementation idea was mostly generated by ai.
It seems plausible but of course feel free to ignore if to far off.
I made shure to only have pseudocode so no real AI code can then be used when making this feature if desired.

[jinliu]

I get it now. For output, I think we can prepend the current SCRIPT_HEADER snippet before your script, so output_debug and output_result is available. That shouldn't interfere with your script unless there are name conflicts.