Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Variables #165

Open
TTWNO opened this issue Oct 18, 2022 · 2 comments
Open

[Feature] Variables #165

TTWNO opened this issue Oct 18, 2022 · 2 comments
Labels
Enhancement New feature or request

Comments

@TTWNO
Copy link
Contributor

TTWNO commented Oct 18, 2022

During the development of the Odilia screen reader we have run into a fairly specific use-case.
A screen reader usually works using the capslock key as the "screen reader modifier"; this is fairly standard, but doesn't work very well in the accessibility and general Linux space due to custom keyboards, bindings, etc. not to mention that some people just prefer using a different key as their SR modifier.
It is important to remember that the SR modifier needs to be bound for every screen reader function; this can be upwards of 100 keybindings.

If it would be at all possible, could there be a way to set a variable key like so:

$odilia_key = capslock
...
$odilia_key + k
    @odilia {JSON OBJECT HERE}

Then changing the key would be fairly straightforward; as of now, the user would need to do a find+replace on the entire file and hope that the string "capslock" doesn't show up anywhere.

Is this something you would consider supporting or should this be done in our fork?

@ajanon
Copy link
Collaborator

ajanon commented Oct 19, 2022

Thanks for the idea!

This seems similar to #117 to me (with a slightly different use case). What do you think?

I am personally not too hyped by the prospect of supporting variables in the config, as I believe this would create many edge cases and weird (mis)uses. As is, I do not think I have strong technical arguments against this feature.
In addition, supporting this use case could also help in solving #103 by allowing users to choose any key as a modifier (but this may create other issues, as you mention in #166 for instance).

I believe we should try to have a proper grammar and improve the config parser (as mentioned in #164) before implementing something like this.

@Shinyzenith @EdenQwQ @angelofallars what do you think?

@ajanon ajanon added the Enhancement New feature or request label Oct 19, 2022
@Shinyzenith
Copy link
Member

I think I agree with @ajanon in the sense that we should improve our lexical parsing before attempting this to make sure we cover most of the edge cases. Apart from that I think this would be a fine feature to add but annoying to code in 🤣. Sorry for the late reply, I've been super busy with university lately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or request
Development

No branches or pull requests

3 participants