Document support for custom web UI
Closed this issue · 10 comments
We all know transmission web-ui is pretty terribad. This is a really nice Web-UI:
https://github.com/ronggang/transmission-web-control
Here's how I added it:
- Add environment variable
TRANSMISSION_WEB_HOMEand set it to/transmission-web-control - Git clone that repo somewhere on the host where transmission container is running
- Add a volume mapping to the container, e.g.
/apps/docker/transmission/transmission-web-control/src:/transmission-web-control - Start container
- ?
- Much success, enjoy a better transmission web experience.
I personally build my own image to get the above webui included, but it would be appreciated if done in lsio-transmission. https://github.com/wiserain/docker-transmission/blob/e166429f850c019c8759da13858366f053296984/Dockerfile#L3-L7
Why build your own image? It's easy enough to add it following my instructions. A huge benefit is you can auto update the UI by running git pull from within the transmission-web-control directory (given you cloned the repo). This makes more sense then being baked directly into your Docker image.
I am just asking them to update the README.md to include my steps :)
Why build your own image? It's easy enough to add it following my instructions. A huge benefit is you can auto update the UI by running
git pullfrom within thetransmission-web-controldirectory (given you cloned the repo). This makes more sense then being baked directly into your Docker image.I am just asking them to update the README.md to include my steps :)
@onedr0p Your instructions sound a bit daft to me to be honest. Half the functionality in the container and half of it mounted from the host. That's not really how docker works. The idea of docker is to have a stable, automated and reproducible build rather than having to follow your step-wise 'recipe' . @wiserain 's suggestion of baking the UI into the docker image is actually much more sensible in my opinion. if you want to update the UI, simply rebuild and re-version the image.
Half the functionality in the container and half of it mounted from the host. That's not really how docker works. The idea of docker is to have a stable, automated and reproducible build rather than having to follow your step-wise 'recipe' .
That is exactly how docker works. There's no anti pattern here -- unless you want to talk k8s, swarm etc.. and HA, which in that point you're smart enough to build your own docker images.
We're simply taking a directory from the host and putting in the container. This way is best IMO because you don't need to build a new image and you can switch between web-ui variations easily which a config change and container restart. Having it baked into the image would be great! but the maintainers of this project are ghosting all issues and PRs, do you think they want to maintain updating the src of a web client in the image? Hell no.
All my documentation states is a way to use a custom web UI with the existing image. Not everyone is smart enough to build their docker image, but may want a nicer web UI.
Baking your desired web ui into the container would be like baking your personalized config file into container. IMO if there's a problem with these instructions it's that they're focused on one particular web ui (which gets muddled by throwing in git) without giving a more generalized explanation.
For the record, I found onedr0p's instructions very helpful and useful -- I would not have known about the environment variable otherwise.
I think we can appease all parties here with the following changes to the README:
- add a row to the PARAMETERS section for TRANSMISSION_WEB_HOME
- add a section for changing the UI based on onedr0p's instructions. Below, I've re-written them to be more clear and general
Custom Web UI
Transmission supports alternative web UIs such as Combustion and Transmission Web Control.
Here's how to change your Web UI:
- Download a new Web UI for Transmission and extract it to a folder on your Docker host
- Add environment variable
TRANSMISSION_WEB_HOMEand set it to/webui - Add a volume mapping to the container:
<path to custom web ui folder>:/webui - Start the container
@onedr0p and everyone else on this thread.
Normally I am against any large modifications and especially pulling in third party deps unless specifically needed.
But all of you are correct, the Default UI is terrible and tends to push people to other clients despite their lack of active development and support.
Though I have to say I do not like the documentation method, it is very unobtrusive and was more in line with our old way of thinking , but I think we can do better with an optional env flag and config logic for making the changes. We wan't everyday users to have these options.
I am going to put this on my TODO list , I cannot promise a time-frame but I tend to get stuff put together within a week when it is on this list.
I had to wait for a bunch of long compiles tonight so decided to cleanup the issues and PRs in this repo:
That is exactly how docker works. There's no anti pattern here -- unless you want to talk k8s, swarm etc.. and HA, which in that point you're smart enough to build your own docker images.
@onedr0p We'll have to agree to disagree on the wisdom of mounting functional code from the host machine. Just remember that a Dockerfile is a way to template your provided multistep recipe for people to build an image from without having to be 'smart enough' for anything other than running the docker build command. Bonus that built container is fully reproducible and portable by simply running the build command again. Bonus too that both the back-end and front-end code are locked in step with each other.
Fork the repo, publish the image... docker build onedrop/purty-transmission