how to contribute

as rovr is currently in its early stages, prs are greatly appreciated. these can be from feature implementations, like a plugin system, to theme additions.

theme additions

textual’s default assortment of themes is quite small, so any theme that you made for yourself can be contributed here!

ensure that your theme follows the schema for a custom theme

[[custom_theme]]
name       = "<name>"
primary    = "<color>"
secondary  = "<color>"
warning    = "<color>"
error      = "<color>"
success    = "<color>"
accent     = "<color>"
foreground = "<color>"
background = "<color>"
surface    = "<color>"
panel      = "<color>"
is_dark    = true
variables  = { "<var>" = "<key>" }

for more information, please refer to theming

once you are done, make a pull request with screenshots made by textual

to make screenshots via textual, simply launch rovr, use the command palette keybind ctrl+p then press on Save Screenshot

in this screenshot, ensure that

1. a completed process, an in-progress process and errored process are all shown
2. the main file list is in select mode with a selected option, and a highlighted option
3. the clipboard contains a selected and non-selected option

afterwards, for the extra screenshots, take screenshots of

• modal screens, preferably DeleteFiles and GiveMePermission modals
• text preview without bat

after that, simply attach your screenshots to your pr and send it!

feature additions

feature additions are allowed as long as it helps the point of having a file explorer. I’m currently looking for contributors that are willing to add support for pdf previews, perhaps by extracting each page as an image, and using the image protocol to render it.

for feature requests, ensure that you have these at minimum

• uv - uv manages the dependencies of the entire project, and does the building + publishing
• git - git is necessary as it is how you get to suggest your changes in pull requests

pr checklist

<!--describe your pull request-->

---

by sumbitting this pull request, i agree that

- [ ] i have run `poe check` to check for any style issues
- [ ] i have tested both the dev version (in venv) and the built version (uv build then install) of rovr
- [ ] cache, logs and others were not accidentally added to git's tracking history
- [ ] my commits follow the conventional commits format as much as possible
- [ ] the documentation has been updated wherever necessary

after making your necessary changes, you can run

$ uv run poe check

so that your code follows the defined style guide and is typed properly.

if you need help with conventional commits, commitizen should be available as a dev dependency in the virtual environment, so you can run cz c to commit with commitizen.

else, you can also run

$ uvx --from commitizen cz c

bugs

bugs can tend to be common, especially with a relatively new application.

if you want to create a new bug report, ensure that one doesn’t already exist in the list of issues
if it doesn’t exist, follow the format below

### issue descripton
{describe what happened that resulted in the crash}

### how do you reproduce it?
{a step by step instruction on recreating the error, or a video with what keys you are pressing visualized}

### what is the expected result of the steps?
{what should have been the expected results?}

### what actually happened after doing the steps?
{show what actually happened after doing the steps. preferrably, paste the exception if the app had crashed.}

### how can this be fixed?
{how do you think this bug can be fixed?}

want to fix an issue?

yeah sure go ahead, the pr format is roughly similar to that of feature additions, except that the pr must link to the issue it is resolving.
the issue linking must follow github’s issue linking syntax.
if there aren’t any existing issues to the problem you are resolving, you are required to create a new issue for it.

feature request

feature requests can be done in the discussions tab. a new request can be opened with the Ideas template.
you may also choose to mention it in the discord server. we might take a look at it either ways.