as a followup to bug 89178, it seems sensible to have "else" branches in conditions ... however, this puts everything upside down. one would have a list of conditions and a list of actions, and they would be combined with a simple language (something basic-alike would be easiest to grok, i think). i would prefer that very much over the clumsy condition tree anyway, and i guess most power users would, too - and who else would use generic actions?
Very nice idea! An improvement, for the people who like a GUI more than a scripting language, would be to merge the triggers/actions/conditions tree into one and have some buttons to modify it. I would like a system like KRegExpEditor, where I can drag&drop my regexp. (They don't need to handle trees there, but that should not be the greatest difficulty I hope.)
The widget would look like this: -------------------------------------------------------- | Bar with: | Triggeritem | Conditionitem | Resultitem | -------------------------------------------------------- | | | Trigger:Mouseclk | | | | | Condition:DCOP | Condition:Windowfocus | | | | | | | |----->------>+<-----<----| | | | | | |<-----<------<+>----->---->| | | | | | | Result:Windowclose Result:Sound | | | --------------------------------------------------------
I suddenly got a better idea, completely different from the KRegExpEditor approach and much simpler: KHotKeyActionMenu: +->Group1 (like currently) | +->Action1 (like currently) | | +->Triggers (NEW) | | | |->Mouseclick | | +->Conditons (NEW) | | | |->DCOP | | | |->Windowfocus | | +->Results (NEW) | | |->Windowclose | | |->Sound | +->Action2 +->Group2 (Plus(+) means this subtree can be closed (like in a filebrowser)) Things like comment, Name or which mousebutton to click would be defined in RightClick->Settings. Enabling/Disabling an action/group would go by RightClick->Enable/Disable. Disabled things would become grey or something. So the right part of the KControlModule (with the tabs) would not be needed anymore.
it seems you missed the primary point of this report: else branches. bug #89193 might interest you.
You are right... I missed my initial idea with the third post(filebrowser-like). :( But I think the second one(KRegExpEdit-like) is valid.
As announced in https://pointieststick.com/2023/07/26/what-we-plan-to-remove-in-plasma-6/ and https://community.kde.org/Plasma/Plasma_6#Removals, I'm afraid KHotKeys has reached end-of-life in Plasma 6. Accordingly, all bug reports and feature requests for it must be closed now. Most of what KHotKeys could do can already be done with the newer KGlobalAccel system in Plasma 6. A few features such as mouse gestures and triggering conditions based on changes to window states are not yet implemented in the new system. These will be added in the future if and when resources materialize for them, and/or when a kind soul submits patches to implement them! :) Meanwhile, the 3rd-party "Mouse Actions" app (https://github.com/jersou/mouse-actions) may be usable for implementing your own mouse gestures again. Thanks for your understanding, everyone.