Allow new default gestures via package update

[m-roberts]

Current behaviour is to copy from /usr/share to user's home directory.

If the logic were to change to always load the system's default config, and then apply additional changes (including unsetting any undesired defaults) in the home dir, it were possible for distros to provide an updated default configuration, without changing the behaviour for users of the core software.

[JoseExposito]

I believe we need to figure something smart for this use case.
We need to find a good balance between sane defaults and the ability to update them.

What do you think is most likely going to need updates in your distro? Global gestures? Or app specific gestures?

Just thinking out loud... If the answer is app specific gestures -for example, Chromium changes a shortcut and you want to update it- then ignoring global gestures in /usr/share and reading app specified gestures could work. However, what happens if an user doesn't want to use that gesture? There is not an easy way to disable it at the moment.

[m-roberts]

I agree, it is not obvious exactly how to approach this.

I would anticipate that both are likely to be desirable. In our case, most of our users will be happy to accept updates to default behaviour. However, I of course appreciate that others will want to ensure that only what they have configured works.

Perhaps the user's config could also define the behaviour? e.g. "override" vs "extend"
That way a user who wants strict control can view the default config file and take what they like, whereas a less concerned user would simply receive updates.

An easy way to ensure that people get what they want, of course, would be to provide a GUI that allows them to choose what behaviour they want, and/or offer the ability to enable/disable gestures. It could even be a neat way of offering examples/templates for different use-cases.

[JoseExposito]

Perhaps the user's config could also define the behaviour? e.g. "override" vs "extend"

That will work, but I find it really difficult to understand for most of the users.

An easy way to ensure that people get what they want, of course, would be to provide a GUI that allows them to choose what behaviour they want, and/or offer the ability to enable/disable gestures. It could even be a neat way of offering examples/templates for different use-cases.

Yes, I also think this is the best idea. One of the features I'd like to add to the GUI is creating gestures from templates/examples.I could put those examples in a JSON file so you can patch it in your distro. Does this work for you?

[m-roberts]

I think that having a "user inherits from system and can extend, modify or disable in their own space" paradigm is still worth implementing. It allows distros and system admins to manage their own config files. Given that most will opt to preserve the default provided at source anyway, there would be no functional regression for most users.

One example that I can think of is how XDG handles .desktop files. /usr/share/applications is used if a matching name is not found in ~/.local/share/applications. If a new application is installed on the system, then the user gets it. If a system admin doesn't want an application appearing in the menu for for all users, then the file can be removed from /usr/share/applications. If a user wants to change a particular application's behaviour, they can copy it to their space and modify it there.

Another example would be systemd - /usr/lib/systemd/system is used by the package, /etc/systemd/system is used by system admins, and ~/.config/systemd/user/ is used by the user.

If each gesture is thought of as a sort of "application" (a bit of a stretch, I know), then it would make sense if the user inherits from the system and can either extend, modify or disable in their own space.

The GUI will help to ensure that users can easily see what functionality they will get as a user. They don't need to know what comes from the system - they can just see what their current configuration is and change it to their preference. If they have already defined a behaviour, then it will continue to work. If not, then it is unlikely that they will ever even know a new gesture was added.

[cassidyjames]

I think I agree with @m-roberts that the system-owned /usr/share config should be used by default, and there doesn't really need to be anything in the user's ~/.config unless a user wants to override things; in that case, they can copy the config and modify it for themselves.

[JoseExposito]

Does @cassidyjames approach also work for you @m-roberts ?

Just a quick summary to make sure we are on the same page:

• By default only the configuration in /usr/share will be used
• If a user wants to update their configuration, they will have to copy and paste it to their ~/.config directory

Pros:

• This allows me to distribute Ubuntu + Gnome support by default (as it seems to be the most popular distro/DE) and allows you to patch it for pi-top OS/elementary OS.
• It allows us to push updates to the default configuration.
• Easy and fast to implement.

Cons:

• If a user configures their gestures, he/she will not receive updates anymore.

[m-roberts]

• By default only the configuration in /usr/share will be used

Yes

• If a user wants to update their configuration, they will have to copy and paste it to their ~/.config directory

Not exactly. The default behaviour would be to extend/override the defaults. This is obviously more complicated to implement, but removes the drawback you mention.

The challenge here comes in adding support for loading multiple configuration files and determining which gestures should be used. Empty user config for a specific gesture should override the system defaults, resulting in no gesture. A defined user config for a specific gesture should override the system defaults, resulting in a different gesture to the default.

[JoseExposito]

I still think this is confusing. Also, I believe you will have the same issue:

Empty user config for a specific gesture should override the system defaults, resulting in no gesture

Let's illustrate it with an example: You ship a configuration file without an action for 5 fingers pinch.
The user overrides some gestures but doesn't include any action for 5 fingers pinch.
You upgrade the package config to include 5 fingers pinch to, for example, open the applications menu.
In this case the user does not get the new gesture.

---

The more I think about it, the more I like Cassidy's solution.
The reason is: I'm forced to distribute an unopinionated tool because there are too many DEs/WMs out there. This is bad, because my users need to edit their configuration to match their system, and no one wants to spend time configuring tools.
However, you target 1 platform and you are going to be able to provide good defaults. This allows your users to focus in using your product instead of configuring gestures.
In your case Mike, you also are in control of the hardware, so you know better than anyone what gestures are comfortable to perform.

Unless there is a very important use case I'm missing I think I'm going to stick with Cassidy's approach. What do you think guys?

[m-roberts]

Cassidy's solution at least gets us most of the way to where we want to get to, and it's easy. I would suggest implementing that while we continue to discuss possible solutions to the other suggestions I am making.

I still feel that what I am suggesting is worth doing, but - as I have made clear from the start of this Issue - it's not self-evident what the implementation should look like.