Ubuntu's X.Org Session Support Now Split Into Separate Package

[anda_skoa]

No I mean I want to double click something, press enter or press a hotkey to load/execute the freaking script

A good scripting API will even allow you invoke based on triggers, e.g. an application window appearing.

But if I can do that, then another app should also (assuming what I double click is just a bash script or whatever).

Only if the app can inject user events at a low enough level to essentially fake being the user and "navigate" the compositor's script loading UI that way.

Of course a compositor could theoretically have non-UI script loading options or even provide out-of-process scripting API.

[billyswong]

No I mean I want to double click something, press enter or press a hotkey to load/execute the freaking script. If I can't do that, this solution is garbage. The whole point is simplification, automation and making it fast as hell.

But if I can do that, then another app should also (assuming what I double click is just a bash script or whatever).

According to KDE documentation, the hotkey will be registered by your KWin script and your KWin script will be installed by a designated procedure. I don't know if another application can perform that designated procedure silently without user knowing, as I am not a KDE user myself.

[Weasel]

How would the these apps remote control the compositor to load their script?
Mind control of the user?

No I mean I want to double click something, press enter or press a hotkey to load/execute the freaking script. If I can't do that, this solution is garbage. The whole point is simplification, automation and making it fast as hell.

But if I can do that, then another app should also (assuming what I double click is just a bash script or whatever).

[anda_skoa]

So what prevents any app from doing it and nullifying the entire point of this useless privacy fiasco?

How would the these apps remote control the compositor to load their script?
Mind control of the user?

[Weasel]

Read the rest of the thread... Compositor scripting.

So what prevents any app from doing it and nullifying the entire point of this useless privacy fiasco?

[Serafean]

Scripts written by the user are also an "application" and now the user can't access his own system properly with them.

Read the rest of the thread... Compositor scripting.

[Weasel]

The user, on the other hand, gains more control over his/her system, because individual apps cannot enforce a non configurable window position, and the user is free to enforce the positioning he wants through the compositor of his choice. Imagine using an app that tries to enforce its window position under a tiling window manager/compositor...

Scripts written by the user are also an "application" and now the user can't access his own system properly with them.

[anda_skoa]

Through window rules, I forced kwin to draw its regular titlebar even for the Steam main window, and now the cross really does quit the app.

I sometimes do this for apps with similar broken CSD implementations.
In my case mostly for CSDs that fail to apply my config for the Maximize action (right click only maximizes vertically).

I did the same for Chromium so I could access kwin's "move to desktop" menu, and to have close/maximize/minimize in the order I set them up to be, and on the side I chose.

I think for Chromium/Chrome you can also right click the CSD and tell the application to switch to SSD.

[Serafean]

But everything you said impacts the user, and you are not his mom. He can decide if he wants his apps sandboxed or not.

it doesn't impact the user, it impacts the individual app developer.*
The user, on the other hand, gains more control over his/her system, because individual apps cannot enforce a non configurable window position, and the user is free to enforce the positioning he wants through the compositor of his choice. Imagine using an app that tries to enforce its window position under a tiling window manager/compositor...
The fact that yakuake works proves that there is a way to discuss and implement non-standard behaviour, in a sane way.
*The user is currently impacted because there is currently no defined mechanism to remember window positioning between app instances.

Personal example: Steam uses CSD, and the cross only minimizes it. Through window rules, I forced kwin to draw its regular titlebar even for the Steam main window, and now the cross really does quit the app. This is user control, not the fact that idiots at Valve decided the quit cross minimizes.
I did the same for Chromium so I could access kwin's "move to desktop" menu, and to have close/maximize/minimize in the order I set them up to be, and on the side I chose.

Another example: years ago, under windows, at one point the desktop/explorer icons kept refreshing/redrawing themselves every 15 or so seconds. It turned out to be 2 apps that had timers to check and set themselves as the default app for opening files of a certain type. The refresh was a result of the default app being changed every 15s. There was no way for me, the user, to stop this behaviour short of uninstalling one of the apps.

[skeevy420]

Yeah, Xorg has no privacy/sandboxing whatsoever (except the extension nobody uses because it's broken). But functionality trumps security.

You can have it both ways, but Wayland decided to have it only one way, the other way. Which makes it unusable.

Let's just agree to disagree on that one. I prefer the security first approach, as inconvenient as it is, but at the same time I understand not wanting to update to something that breaks what you're doing and how you want to do it. Doing what we do, how we do it is why most of us use Linux or some other FOSS OS.

It really does suck that they can't all agree on some sort of permissions system like Android offers.