I'm working on a GUI for InputActions

[Glampi42]

Hey,
I've been using your tool for quite a while now, and it has increased my productivity by a lot. I thought that more people should have access to this wonderful tool, so I began working on a prototype for a GUI (made with Kirigami/QtQuick and C++ backend) for InputActions which I called "Input Ease GUI".

So far I have established the barebones frontend, and am now looking into the actual YAML config parsing. To this end, I wanted to ask you for some directions for how I should proceed with structuring the data. What I came up with are three categories:

1. General Settings — this includes autoreload, emergency_combination etc. (basically all settings that are root's children)
2. Device settings — Speed, and per-device DeviceRules. In the GUI, there is a tree view where all the child-gestures (or triggers) are displayed below each corresponding device.
3. Gesture(/Trigger) settings — Here's the main part: gesture type, fingers count, direction (for swipe gestures) etc. etc.
   Depending on which device/gesture will be selected from the aforementioned tree view, the corresponding settings will be displayed in a pane next to the tree view.

Since you are the creator of this project, I'd like to know how you think the data should be structured to visually aid the user, for configuration simplicity's sake. Naturally, I want to preserve all the vast functionality of the tool, but I will try to present the central options first, to make configuration intuitive, while not hiding all the great niche-features.

I am also just a hobby programmer, so if you have some advice regarding the coding-aspect, I would gladly hear it. Maybe you could direct me at InputActions' source code I should take a look at to help me with the config parsing.

I will be publishing the project to GitHub shortly, maybe after I reach a point where it has some basic functionality. Let me know if you'd like to see the source code. Here's a screenshot of the GUI.

Best regards,
Glampi

[taj-ny]

am now looking into the actual YAML config parsing

Don't bother with that right now, the current config parser is like 1.5k lines of code, can't be reused for the GUI (so you'd have to copy all of it), erases some information (e.g. trigger groups) and doesn't even support writing. I'll write a library that solves all of that, it'll also expose information about properties, allowing for creation of some UI components at runtime instead of hard-coding them.

My suggestions (for now):

1. Change the sidebar to:

   - General settings
   - Device rules
   [Header] Triggers
   - [Keyboard icon] Keyboard
   - [Mouse icon] Mouse
   - [Cursor icon (or something similar)] Pointer
   - [Touchpad icon] Touchpad
   - [Touchscreen icon] Touchscreen
   

   By header I mean this thing like in System Settings:
   

2. Let's just omit speed, I'll try to move it to device properties before the GUI is done.

3. On the Device rules and device pages, add a second sidebar (like in System Settings) containing device rules on the Device rules page, and triggers as well as trigger groups on device pages. Put an Add button in the header if possible:
   

   The second sidebar should be a tree view so that triggers in groups can be easily accessed.

4. Upon selecting a trigger, properties should be displayed in the remaining space like this:
   

If you publish the source code (under GPL3) I could start working on this too.

[Glampi42]

• General settings
• Device rules
  [Header] Triggers
• [Keyboard icon] Keyboard
• [Mouse icon] Mouse
• [Cursor icon (or something similar)] Pointer
• [Touchpad icon] Touchpad
• [Touchscreen icon] Touchscreen

Yes, a double sidebar makes sense given all these selections will open an extra pane with sub-items (like triggers for devices) or the options. Making it collapsible will make it less space-wasteful also. I do think there should be a main toolbar with "Add", "Move Up/Down", "Delete" options, since those can adapt to the selected item ("Add" can add a new trigger when the triggers pane is selected, or a new condition if the trigger's condition TreeView is selected) — this way one doesn't need to duplicate those buttons all across the UI.

[Glampi42]

I published the project on GitHub: InputEaseGUI

[taj-ny]

More suggestions:

• Sidebar items are way too large, change it to the default size (like in System Settings). Same with the button for collapsing the sidebar.
• Remove the border for the sidebar collapse button.
• Remove the sidebar search field, there's nothing to search for there.
• Replace the global action tool bar with a menu bar, use tool bars only for page-specific actions (such as Add for trigger lists and device rules)
• Move Up, Move Down and Delete actions are not necessary. Instead, make the list view items draggable and add a delete buttons for every item (like in window rules).

[Glampi42]

1. This is the smallest icon size that makes them colored (at least in breeze theme); if they are smaller, they become black'n'white. In System Settings they actually don't use a standard Kirigami icon size preset, but a custom size.
2. Agree
3. I was thinking about adding a "name" and "description" property to each trigger, because my config is already pretty large and the only way I can keep track of what trigger does what is by adding comments in the config. In-app, I think adding a name (which would be smth like "Swipe Gesture #1", "Tap Gesture #3" etc. per default) and a description to each trigger would solve this issue. The search bar would then let one find a particular trigger.
4. How would you imagine adding/removing trigger conditions, for example? Since it is a tree view (because of the "all", "any", "none" groups, which can also be nested within each other), one would either need a toolbar to add/move/remove conditions, or add the "new, delete" buttons at each nesting level. For example, if the conditions are:

conditions:
  - any:
    - all:
      - $finger_1_initial_position_percentage between 0,0;1,0.3
      - $finger_2_initial_position_percentage between 0,0.7;1,1
    - all:
      - $finger_2_initial_position_percentage between 0,0;1,0.3
      - $finger_1_initial_position_percentage between 0,0.7;1,1

, then one needs to have the "add" button at "any", level, as well as at both "all" level, making a total of 3 buttons. Also, a delete button next to each tree entry. I think a toolbar is more suitable here. I took the style for the global toolbar from "KDE Menu Editor", since it also has a tree view. Let me know what you think.

[Glampi42]

DrawNote_InputEaseGUI Concept Art.pdf

I made a concept drawing board for the UI. Here's some explanation:

On the right is the actual UI window, on the left are extra windows/menus/tooltips and such. The main window would consist of at most three columns (from left to right): MainDrawer, SubDrawer and InfoPane. You've seen MainDrawer already; SubDrawer will get displayed for a selected device, or for Device Rules, and InfoPane contains all the actual info.

The global toolbar could maybe be replaced by a menu bar, if you have ideas of how to nicely deal with adding/moving/removing items in tree views. For now, I envision a global toolbar that adapts itself to the selected item: for instance, when a condition is selected, the sub-actions in the "New..." button will contain "New condition...", "All of group" etc..

More specific stuff:

For gesture direction setup, there could be a set of presets (up, left-right, diagonal etc.), as well as a "custom" option, which would open an external window that lets one set up the custom angles.

To create conditions, there would be another extra window with two tabs: "Preset" and "Custom". A preset could be a collection of some standard conditions, like "active application is <...>", "all fingers in the <...> half of the screen" (presets could also contain multiple conditions) etc. And custom is something more similar to how a condition looks like in config, with <variable2/value>.

[Glampi42]

No, right, Device Rules also needs the SubDrawer, because they have conditions, ignore and other properties. Never had to use them so far, so I don't have a full picture for what they should look like in my head.

[taj-ny]

This is the smallest icon size that makes them colored (at least in breeze theme); if they are smaller, they become black'n'white. In System Settings they actually don't use a standard Kirigami icon size preset, but a custom size.

I don't mind symbolic icons, it'll actually more consistent with all the other icons in actions and context menus.

I was thinking about adding a "name" and "description" property to each trigger

Sure. We could also use some properties (fingers, mouse buttons, actions etc.) for better auto-generated names and descriptions, for example Swipe 3 fingers to the right, Run command 'dolphin'. Perhaps the description could be shown in the trigger list below the name.

The search bar would then let one find a particular trigger.

Would the matching triggers appear in MainDrawer or SubDrawer?

if you have ideas of how to nicely deal with adding/moving/removing items in tree views.

For moving items just implement drag-and-drop and for deleting add a delete button for each item. For triggers the delete button could be put in a context menu if there's no space.

For now, I envision a global toolbar that adapts itself to the selected item: for instance, when a condition is selected, the sub-actions in the "New..." button will contain "New condition...", "All of group" etc..

I don't like how many things the New button is for, plus having to select something before adding requires too many clicks and will be confusing for users. Make dedicated New buttons for trigger, action and condition lists. For the last two, put it to the right of the header in the same row.

For gesture direction setup, there could be a set of presets (up, left-right, diagonal etc.), as well as a "custom" option, which would open an external window that lets one set up the custom angles.

Sure.

To create conditions, there would be another extra window with two tabs: "Preset" and "Custom". A preset could be a collection of some standard conditions, like "active application is <...>", "all fingers in the <...> half of the screen" (presets could also contain multiple conditions) etc. And custom is something more similar to how a condition looks like in config, with <variable2/value>.

Conditions have so few options that it's not necessary to have a separate window for them, they can be made configurable directly in the condition list:

- [All/Any/None (combo box)] of the following are true:
  - [Variable name (combo box)] [Operator (combo box)] [Value (depends on variable type)]

Similar to BetterTouchTool: https://docs.folivora.ai/assets/images/cag_setup2-1e2a6e19bc7a327074a67d72143828cc.png

Presets and condition types can be displayed in the New menu.

No, right, Device Rules also needs the SubDrawer, because they have conditions, ignore and other properties.

That's right.

---

For the trigger page, perhaps it would be a good idea to split properties, conditions and actions into separate tabs to reduce the need for scrolling? There are quite a few trigger properties, I doubt all of that will fit on one page.

---

Actions groups are a thing, so I guess display actions in a tree view like triggers.

[Glampi42]

Would the matching triggers appear in MainDrawer or SubDrawer?

In the SubDrawer, and the MainDrawer would only display the devices that contain triggers that meet the criteria. One could also search for a specific general setting there.

Similar to BetterTouchTool

That's actually a very helpful reference, I will try to replicate the structure. Okay, I guess a global toolbar isn't necessary after all. I want the interface to work both with a pointer as well as with keyboard, so I'll try to come up with a design that works for both.

For the trigger page, perhaps it would be a good idea to split properties, conditions and actions into separate tabs to reduce the need for scrolling

Yeah, sounds good

[taj-ny]

Regarding the config library - what type should object list properties be? I'd like to use smart pointers, so I'm thinking about a generic QAbstractListModel implementation that exposes pointers to QObjects.

[Glampi42]

Isn't the config more of a tree structure? To my knowledge, QAbstractListModel is for flat lists; if one intends to implement a tree model, one needs the QAbstractItemModel, the ancestor.

[taj-ny]

My current plan for the config library is to deserialize the config into QObjects with properties to make it easy to manipulate. QAbstractItemModel would be used for properties with multiple levels of nesting such as actions, conditions and gestures, while QAbstractListModel would be used for flat ones like mouse_buttons, strokes etc. Will that be good?

[Glampi42]

Yes, I think so 😅 I haven't done something like this before, so can't know for sure. But having an API to interact with rather than having to make entries in the config sounds much better;)

[Glampi42]

Also, the changes to the config should not be written to the config file on the disk directly, but first stored in an intermediate config. Then, by pressing "Save" in the GUI, one would override the config file on disk with the intermediate config. I think ideally I should implement a global undo/redo functionality, but at the very least I will add a "Undo All" button, that will reset the intermediate config to the state that is saved on disk.