RES style keyboard shortcuts
Not having the res keyboard shortcuts is making this website unusable for me, honestly.
I use j and k (to be clear, I use dvorak so that's actually v and c, which is extremely easy to press with one hand.) to go up and down and it automatically selects and expands things in res, that feature alone makes it so that i only have to push one button to navigate the entire website.
I also have it set for shift J to collapse and uncollapse the expando, and when it scrolls down to comments, i can also collapse and shrink comments, this is also extremely convenient.
Furthermore, i can push the A key to instantly open the selected posts comments, and enter for the selected posts link
I find this setup extremely convenient, scrolling and using a mouse is vastly more annoying.
Maybe this would better be relegated to an extension, but, I find this setup far too wonderful to think it isn't deserving of being native, and I think the shortcuts should be configurable per-session with the option to make it account-wide.
I'd definitely be open to someone wanting to add these. I don't have time to work on it, but anyone else is free to do so.
Is there a bountysource or something similar where I could donate to such an issue being resolved?
A tiny amount of money isn't going to solve the problem, either for me, or anyone else who wants this. Someone who wants the feature just needs to work on it.
How much money would make it happen?
@Kommynct I made a Lemmy keyboard navigation userscript here https://github.com/vmavromatis/Lemmy-keyboard-navigation
If someone wants to add this, I'll re-open and assign it to you.
Reopening as its a valid issue, and contributions are welcome.
I think this should be closed. No one's expressing any interest in working on it, and I also think its a bad idea to hijack browser keyboard shortcuts.
and I also think its a bad idea to hijack browser keyboard shortcuts
Factual correction on this note specifically - RES does not "hijack" browser shortcuts; most of its default (though configurable) keybinds are for keys which would otherwise do nothing.
Also is nobody working on something a good basis for closing an issue in the first place? Issue trackers are to track issues, they should be closed when they are solved or that it is rejected from the project, why bother closing a valid issue?
This is an issue tracker for the developers to track things they're going to work on. If you don't close unplanned issues, you'll end up with an issue tracker like qbittorrent: ~2000 issues that no one's working on, or that anyone plans to work on.
~~Anyways I'll re-open this if someone wants to work on it.~~
This is an issue tracker for the developers
Does this project not accept contributions from the community?
I think I understand what you mean, and that's certainly one way to approach categorizing issues - but from an optics perspective, you may find that tracking the above distinction another way results in less friction and fewer misunderstandings.
I.e., instead of:
- closing issues that the core development team is not interested in working on
- using labels or other mechanisms to distinguish other items which are in-actionable, have been actioned, or there is no interest in actioning from the core development team
Consider:
- closing inactionable issues as "not planned"
- closing actioned issues as "completed"
- keeping all actionable issues open
- using labels, assignees, and project boards to coordinate internal work within the core development team
While I see the aesthetic appeal of having a short list of open issues, it does result in recurrent discussions such as these, so it may not be worth it overall.
Does this project not accept contributions from the community?
Yes of course. Do you want to take on this issue? If so, I'll assign it to you.
keeping all actionable issues open
We used to do this, but in reality it meant hundreds of stale issues that no one had any interest in working on. Not easy to organize our work this way.
If people have pet issues that we don't see as important, that they have no interest in working on, then an issue tracker isn't the place for them to store them. This is for us to organize our work. Otherwise issues can be assigned to those who have an interest in actually doing them.
Do you want to take on this issue?
Fair ask (even though I don't presently use this software). I gave in an honest go. The code itself is straight-forward. However, I could not figure out a simple way to actually test it.
- As far as I understand, all Lemmy instances except voyager.lemmy.ml are CORS-restricted, so cannot be used for testing frontend development.
- Despite claims found online, voyager.lemmy.ml registration is not open - accounts must be approved, and it looks like there's no one is watching the approval queue.
- I also tried running a local backend. However, the backend requires a multi-container setup with non-trivial configuration. A simple
podman-compose updid not cut it - after a long wait to build the Rust binaries, I ran into permission errors. - Minor stumbling block: setup instructions in README are missing
git submodule update --init. While mostly obvious, without it the build fails with an obscure error.
I may have missed an obvious simpler way from going over the documentation, however the above was my experience.
That's all the time I can allocate for this at the moment. Perhaps consider what can be done to improve the developer experience as a core team priority!
If people have pet issues that we don't see as important, that they have no interest in working on, then an issue tracker isn't the place for them to store them. This is for us to organize our work. Otherwise issues can be assigned to those who have an interest in actually doing them.
Looking at this issue again, I am a little confused by the statements here:
- This issue is the second most upvoted open issue in this project
- The core dev team wants to use the list of open issues as a tool to prioritize work
- However, the second most upvoted open issue is not a priority?
I also think the issue should stay open, there is enough time to implement it after 2 or 3 years. Then maybe someone will come across it and implement it. Thats what the issue tracker is for.
@CyberShadow Just had a look at voyager.lemmy.ml and approved your registration, sorry about that. It seems the site settings are currently broken and so when I changed the registration mode it wasnt actually applied (https://github.com/LemmyNet/lemmy-ui/issues/3595). Changed the registration mode via SQL now and it should work without answering a question. Please give it a try and report if there are anymore problems. And when you see these problems with the documentation, it would be ideal if you could directly fix it and open a pull request. We will definitely merge that to make it easier for everyone.
For development you need to run LEMMY_UI_BACKEND_REMOTE=voyager.lemmy.ml pnpm dev like the readme says. Then your locally running Nodejs project connects to the backend api on voyager.lemmy.ml. So you see the same content, can login to your account, post and test everything else. You dont need to build Rust at all.