Customizing the Activator of SystemCommands #88

New Issue

delvh · 2020-10-07T22:06:13+02:00

delvh commented

2020-10-07 22:06:13 +02:00

As suggested by @DieGurke here, it might be nice if the user could customize the activator used for SystemCommands.

This feature request is not highly prioritized.

As suggested by @DieGurke [here](https://git.kske.dev/zdm/envoy/pulls/84#issuecomment-1069), it might be nice if the user could customize the activator used for SystemCommands. This feature request is not highly prioritized.

delvh added the

client

M

labels 2020-10-07 22:06:13 +02:00

kske commented

2020-10-08 08:25:01 +02:00

Is that really necessary? Don't know of any software that allows this and see no benefit in it myself.

delvh commented

2020-10-08 22:18:44 +02:00

Ask @DieGurke.

delvh commented

2020-10-08 22:26:18 +02:00

Oh, and by the way, this is not the first time that I have noticed this, but could we please stop to use "I don't know any competitor doing something like that and hence we won't do it either" as an argument to shut down features?
You, @kske, are especially guilty of that.

Oh, and by the way, this is not the first time that I have noticed this, but could we **please** stop to use "I don't know any competitor doing something like that and hence we won't do it either" as an argument to shut down features? You, @kske, are especially guilty of that.

kske commented

2020-10-09 08:01:15 +02:00

I don't see why this wouldn't be a valid argument.

Our competitors have a lot of experience in their field, and in most cases a feature that is not part of any competitors product is one that has been deemed unnecessary, insecure etc. by all of them.

That does obviously not mean that there are no exceptions to this either. Some features just don't fit a competitors vision of their product. For example, WhatsApp won't introduce a web interface that isn't backed by a smartphone, as one of their goals is to make their service account free (hence they use the cell phone number instead).

This behavior can be observed in other messengers as well, however it's not a reason to not implement it in Envoy, as we have different vision of how our product works.

I don't see why this wouldn't be a valid argument. Our competitors have a lot of experience in their field, and in most cases a feature that is not part of any competitors product is one that has been deemed unnecessary, insecure etc. by all of them. That does obviously not mean that there are no exceptions to this either. Some features just don't fit a competitors vision of their product. For example, WhatsApp won't introduce a web interface that isn't backed by a smartphone, as one of their goals is to make their service account free (hence they use the cell phone number instead). This behavior can be observed in other messengers as well, however it's not a reason to not implement it in Envoy, as we have different vision of how our product works.

kske commented

2020-10-09 08:19:14 +02:00

In principle, I have no problem with a high degree of customization, like allowing the user to change shortcuts, themes, or in this case the system command activator.

It is in fact one of the ways in which we can make a huge difference to our competitor's products, as they are targeted towards the "casual user", whereas we can keep the more advanced users in mind as well.

However, we need an easily accessible and expandable interface which allows the user to manipulate arbitrary settings without us having to separately implement initialization / defaults, getters and setters, settings UI etc. for each of them.

At the moment, implementing a user-defined setting is a rather complicated process that doesn't scale well, therefore we either have to reduce the amount of settings, or implement a better way of handling and manipulating them.

If one of you deems this a useful feature, I have no problem with you or me implementing it, but please don't litter our codebase with subpar boilerplate code that introduces even more initialization dependencies to classes, that are already complicated.

In principle, I have no problem with a high degree of customization, like allowing the user to change shortcuts, themes, or in this case the system command activator. It is in fact one of the ways in which we can make a huge difference to our competitor's products, as they are targeted towards the "casual user", whereas we can keep the more advanced users in mind as well. However, we need an easily accessible and expandable interface which allows the user to manipulate arbitrary settings without us having to separately implement initialization / defaults, getters and setters, settings UI etc. for each of them. At the moment, implementing a user-defined setting is a rather complicated process that doesn't scale well, therefore we either have to reduce the amount of settings, or implement a better way of handling and manipulating them. If one of you deems this a useful feature, I have no problem with you or me implementing it, but please don't litter our codebase with subpar boilerplate code that introduces even more initialization dependencies to classes, that are already complicated.

This repo is archived. You cannot comment on issues.