- User Since
- Oct 28 2016, 11:08 AM (173 w, 5 d)
Jun 28 2019
Thanks for evaluating the script again.
We listen to our users. We told you, that the functionality you were requesting is currently impossible to implement.
Jun 14 2019
Yes, there was recently a discussion about exposing some API events on Wayland. There were some concerns about breaking Wayland security by doing so. It was, however, decided that the API does not expose any information not available by other means, so the changes got merged about two weeks ago.
My only dissatisfaction so far is with hotkeys: some of them doesn't work OOB
We have very recently decided to remove the non-essential default key bindings, because a) neither of us is an UX specialist, so the bindings were most probably sub-optimal and b) to prevent more future conflicts with Plasma defaults.
although there's "move focused window left/right", but I don't see "focus the left/right window"
It is a design decision to not duplicate KWin's functionality and KWin already has very flexible and polished task switcher. There indeed are "focus next/previous tile" actions, but they have somewhat special meaning in respect to the window "stacking" order and they are unbound by default.
Just to make it clear: is it possible with current API to override kwin hotkeys from the extension? E.g. to allow a user to apply default hotkeys?
I don't know what's the current state, sorry.
I'll probably configure and try to use it on the weekend
Thanks. If you are on Plasma 5.16, please use our master/HEAD. There are some not-yet-released improvements in handling of maximized clients.
Jun 13 2019
This is more a subtask of T11080
This does not apply exclusively to the KWin tiling functionality. There could be a list of "approved" and supported 3rd-party extensions which would be actively advertised to the user.
The script shortcuts in particular are handled and configured in the same way as the rest of global shortcuts. There's almost no difference except for the default binding.
Although, one thing that's definitely better when functional is integrated: you don't need to think about backward compatibility.
Yes, that's a valid argument. Currently it's up to the script maintainer/developer to consciously maintain backwards compatibility.
Wayland doesn't have concept of managed/unmanaged clients, so if your script checks managed property, you're screwed for the most part. I don't see any other option but introduce a client type enum.
That particular script I'm talking about does not really use managed property.
This would require some adjustments in scripts. :/
Yes, I expect some adjustments to be needed and some run-time X11/Wayland differentiation to be necessary. I'm OK with that - c'est la vie.
Jun 11 2019
May 23 2019
A rogue app could inject malicious code into the script or completely replace it with something else.
Assuming we have an encrypted config section, we can of course store script fingerprint there.
- Add a config option somewhere that enables this functionality (I'm happy editing a file rather than requiring a GUI option)
- A warning when adding a script that says something about not trusting random scripts from the internet
Neither of the above would solve the issue.
- The configuration options are stored in plaintext and are writable by any process.
- The scripting interface is exposed on D-Bus, so any process can download and run any arbitrary script.
The solution would be to store the plugins configuration encrypted (or in general to allow for encrypted config sections) and to remove potentially dangerous methods from the D-Bus interface.
Mar 26 2019
Mar 25 2019
Regardless of the XdgShell protocol, there's currently no way to maximize client from KWin script at all, which is somewhat limiting factor for certain use cases (e.g. Maximized layout in a tiling script such as https://github.com/faho/kwin-tiling).
- Use Q_INVOKABLE instead of slot
OK, will do. I did honestly think that this is a bug.
Mar 11 2017
Nov 4 2016
Works for me.
It's funny (is it?) that I'm just doing the same. I should have told you I guess :)
Your solution is simpler anyway. My solution involves inputdevice.kcfg.
I don't think the [vendor][product] key is sufficient. I have two DELL devices here with the same product code, but different name and different functionality. I suggest the key to be [vendor][product][name].
Nov 3 2016
Nov 2 2016
Incorporated Martin's suggestion to not translate the Linux button codes.
Created this one by accident. Sorry for the mess.
OK. Thanks again.
Thanks for the explanation.
And that also shows: please push to Plasma/5.8 branch :-)
Do you mean only to Plasma/5.8 and you're going to merge into master later?
Given the number of reviews you have: do you want to apply for a git account? See https://community.kde.org/Infrastructure/Get_a_Developer_Account
I did (https://identity.kde.org/index.php?r=developerApplication/view&id=637).
How to proceed once (if) the application is approved? Since I haven't used Arcanist to create the diff, will it be enough to use "Differential Revision:" keyword in the commit to pair it with the respective diff? Do I understand it right, that there's no mechanism ensuring that what I'm committing is what was under review?
Oct 31 2016
Thanks for the review. Can you please land the diff for me?