Repository navigation
Allow customizing shortcuts #1611
Description
Activity
https://developer.mozilla.org/en-US/docs/Web/API/Invoker_Commands_API#creating_custom_commands might be helpful for that.
Thinking purely out loud here (as this wouldn’t work for everything) but is it an option to have the shortcuts that click a specified by ID element be defined as such?
E.g. aside from things that have to be hardcoded strings like “refresh entries page”, we could have [ “click”, “QUERYSELECTOR”]. This wouldnt be as customisable as custom coding, but it would allow for some light behaviour customisation without source code changing
For more practical: would the configuration be done through the JSON file from #1610? Or preferably be consistent with INI?
- While ini file is already implemented it is not really well suited for nested structures like
list<object{shortcut: string, action: string}>. - We could support
config.jsoninstead ofconfig.ini(reading the latter if the former does not exist for backwards compatibility). but JSON is not very human friendly. - We could use some better language like TOML but that requires adding a third-party parser dependency, which increases stuff that can break at app initialisation.
- Also parsing config in PHP might possibly make each PHP request slightly slower.
- All for a feature that is not even used by the backend.
- Though it we might need it for other features like configuring SSRF filter.
- Neither of these probably a huge concern but we should still be careful.
- We also expect that everything that can be configured in config can be configured using environment variables and those are even less dimensional than INI files.
- We could introduce a separate JSON config for frontend since the JS client can be considered a different app anyway.
- We could avoid supporting changing this in config and provide JS API for use in
user.jsinstead.
- While ini file is already implemented it is not really well suited for nested structures like
- While ini file is already implemented it is not really well suited for nested structures like
list<object{shortcut: string, action: string}>. - We could support
config.jsoninstead ofconfig.ini(reading the latter if the former does not exist for backwards compatibility). but JSON is not very human friendly. - We could use some better language like TOML but that requires adding a third-party parser dependency, which increases stuff that can break at app initialisation.
How about yaml? It is rather easy to write by hand and seems to be somewhat internally supported by PHP. Although, it doesn’t natively support JS, which would add a layer of dependency again if the config is to be client-only
- We also expect that everything that can be configured in config can be configured using environment variables and those are even less dimensional than INI files.
We could abstract it slightly with a delimiter? Its a little messy, but would work within INI & env
[commands] view_unread=& 1
The tinykeys notation doesn’t seem to use spaces, so it works fine as a delimiter. Otherwise
,can be used or whatever- We could introduce a separate JSON config for frontend since the JS client can be considered a different app anyway.
- We could avoid supporting changing this in config and provide JS API for use in
user.jsinstead.
True! Although (selfishly), the NixOS module isn’t quite equipped for it yet (especially not with immutable root). That can be patched into the module however, so its not a big issue
- While ini file is already implemented it is not really well suited for nested structures like
How about yaml?
It needs to be installed from PECL, which is not an option for some of our users (e.g. on shared web hosts). Plus yaml is just not very friendly, thankfully we switched the language code for Norwegian Bokmål from
notonb.We could abstract it slightly with a delimiter? Its a little messy, but would work within INI & env
Right, though we would not want to be bound to tinykeys syntax. Maybe we will want to introduce support for chording. Also https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html is relevant to DSL design.
True! Although (selfishly), the NixOS module isn’t quite equipped for it yet (especially not with immutable root). That can be patched into the module however, so its not a big issue
I introduced
SELFOSS_CONFIG_DIRsupport for that purpose. And then forgot to actually apply it for theuser.*🤦♀️
Currently, I am leaning towards the
user.jssolution. That is already explicitly declared unstable so we can change it in the future and we can skip having to think about this for now.Reacted by CatIt needs to be installed from PECL, which is not an option for some of our users (e.g. on shared web hosts)
Ah, my bad! Reasonable thing to want to avoid
Plus yaml is just not very friendly, thankfully we switched the language code for Norwegian Bokmål from
notonb.Thanks for the link, had no idea yaml had an oversight like that! Noted
Right, though we would not want to be bound to tinykeys syntax. Maybe we will want to introduce support for chording. Also https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html is relevant to DSL design.
Great writeup as well as reasoning!
I introduced
SELFOSS_CONFIG_DIRsupport for that purpose. And then forgot to actually apply it for theuser.*🤦♀️Happens to the best of us ❤️
Currently, I am leaning towards the
user.jssolution. That is already explicitly declared unstable so we can change it in the future and we can skip having to think about this for now.That’s fair! What type of syntax are you imagining in user.js? I don’t know how easy it is to hand over stuff inbetween the client typescript and the user.js as of right now
Would be nice to allow changing keybindings like e.g. text editors allow, for example, Sublime Text keymaps.
Though it would require abstracting selfoss operation to string names, something like commands and in Sublime Text or actions in GTK.