Replies: 91 comments
-
For sure. I was thinking of building it with React in TypeScript and compile it to JavaScript. There is a lot of things I need to know to set this up but later on it will help and make it easier for other people to contribute. I don't know how you guys are building and packing qBittorrent binaries. This is how I would suggest to do the web parts:
|
Beta Was this translation helpful? Give feedback.
-
|
The reasons I suggest to build it with React:
|
Beta Was this translation helpful? Give feedback.
-
Don't worry about this part yet, we aren't going to replace the current webui if the next one isn't on par with functionality. For now, you might want to start a project (on your side) and see how it goes, I'm sure it will catch our eyes if it gets popular enough :) |
Beta Was this translation helpful? Give feedback.
-
|
I looked at the Wiki, is this project official? Is there a REST API, where is the wiki of that API? |
Beta Was this translation helpful? Give feedback.
-
|
@Chocobo1 let it begin I'll try to figure the best way to avoid re-implementing the WebAPI and use that project... let's see |
Beta Was this translation helpful? Give feedback.
-
|
Found this |
Beta Was this translation helpful? Give feedback.
-
|
I was looking for more details on the API that I came across this project. Is there any reason that you wouldn't want this to be part of the core by default? @glassez it seems we would want to update some parts of the Web API again. In modern web apps we wanna redirect all the requests to an entry point lets say This is quiet important to not have two separate folders (private, public) serving the same app. Any thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
@drsepanta FYI, many people believe that web UI should mimic the desktop UI. I am not a supporter of this idea. To be honest, I don't even consider qBittorrent desktop UI the best thing. |
Beta Was this translation helpful? Give feedback.
-
|
@drsepanta |
Beta Was this translation helpful? Give feedback.
-
|
@glassez I'm gonna share some of the technical requirements of the code to be able to run modern web app UI from QBT. On the topic of if these efforts are even gonna be accepted, I still believe the discussion will help the core to have a better API to support Web UI. Bottom line is more people might willing to build Web UI for QBT. Though I would like to know what are the requirements coming from the Core team that they would wanna accept the project to be included by default. About the UI design I'm not an expert in designing UI (I've done some in the past but long time ago.) that said for better user experience I would strongly suggest to build the core Web UI as similar as possible to the desktop version. Though I wouldn't recommend to follow the look of the desktop version. It should look like a web application following user experience of desktop version and feel like it. This way user learn once and work with both without extra efforts. |
Beta Was this translation helpful? Give feedback.
-
Of course. This is what I would recommend for building the next generation of Web UI for QBT:
REST APIThis allows QBT to separate concerns. QBT doesn't have to serve any files if there is a standalone REST API. Users can configure this option and communicate with their QBT instance over network via http from any web apps on internet. Web-serverThis part is pretty clear, we would need to have a web-server to serve static files of Web UI application. This option gives the user the possibility to use QBT over network just by enabling the Web UI settings. The default built-in Web UI will work with the REST API so the configuration depends on REST API to be Enabled. |
Beta Was this translation helpful? Give feedback.
-
|
@drsepanta |
Beta Was this translation helpful? Give feedback.
-
|
I have additional, random points:
|
Beta Was this translation helpful? Give feedback.
-
|
That's fine. I'm gonna rephrase what I suggested. Right now we have an option to turn on the web-server. This option requires a path to be selected to serve the content. Once this is done automatically it starts serving On top of this if user doesn't have an alternative Web UI then QBT can offer them the built-it one that will communicate with the REST API. This can be pretty much what QBT is offering right now, both under the same host:port but different paths and web-server checks for Something else to consider, We can use the same Web UI and build an Electron app and completely deprecate QBT desktop UI. PS: I looked at the web API under |
Beta Was this translation helpful? Give feedback.
-
I don't know this tech but I would suggest against it. REST API would probably be a better option and to some degree it's already implemented in QBT.
That's not an issue, there are solutions for this on WEB. One can be virtual scroll. We render only part of the list that user sees and the rest only exists in the memory. If at some point we wanna optimize more we can add pagination to the REST API.
That sounds interesting though honestly you can build a Web application in Electron and run it on every single platform that it supports. VSCode is a good example. |
Beta Was this translation helpful? Give feedback.
-
|
2nd minor release supporting sorting and search. https://github.com/aminpaks/qbittorrent-web-ui/releases/tag/v0.2.0 |
Beta Was this translation helpful? Give feedback.
-
|
Very cool! I have started my own web ui, but my progress is severely lacking :D Also, I fully support being able to authenticate with a JWT instead of cookies, it would make developing a new interface way smoother then the current solution! For reference: https://github.com/richard87/qbtui A very basic implementation, basically just a MUI-Datatables :) |
Beta Was this translation helpful? Give feedback.
-
|
Also, there is no difference between sending an Authorization key, versus a Cookie ID, same amount of data over the wire, same security over the wire. The difference lay in the complexity on the server, and the vulnerability for injected javascript in the client to steal the access code (whether it being a JWT or a authentication key / session id). For security all communication should go via https no matter what, either self-signed or with a signed certificate from for example LetsEncrypt or any of the new ACME providers. On the backend implementation, I'm sure there are plugins for whatever http server that is in use now that already support cookie authentication. I would also argue that following modern best practices for web-security is way better than the unusual approach of private/public folders. ~~Also, I would love to give it a shot if any of the maintainers agree :D ~~ |
Beta Was this translation helpful? Give feedback.
-
|
I've been working on building categories and I'm not sure if the Web UI should follow the Native UI for adding items to a category. Also I'm not sure what the new behavior should be. I was thinking of simplifying the category set somehow. What I don't like about adding the categories in the context menu is I don't believe thats the best spot to display all the categories as if some of categories are too long or there is too many. I was thinking of building how categories can be assign to selected items in the list within sidebar itself. Any thoughts? |
Beta Was this translation helpful? Give feedback.
-
I have already expressed my opinion about this. I don't think Web UI should follow Desktop UI. But my opinion has opponents.
Maybe just add "Assign category" item in the menu to display some dialog? |
Beta Was this translation helpful? Give feedback.
-
What about seedbox, NAS, media server and other headless servers, for use cases such as this. |
Beta Was this translation helpful? Give feedback.
-
Ideally, Web UI should provide all the same features as the Desktop UI, but it is not necessary to imitate its appearance, etc. That's what I mean. |
Beta Was this translation helpful? Give feedback.
-
|
Released a new minor version implementing categories. https://github.com/aminpaks/qbittorrent-web-ui/releases/tag/v0.3.0 |
Beta Was this translation helpful? Give feedback.
-
|
@aminpaks |
Beta Was this translation helpful? Give feedback.
-
|
"better web ui user experience." This is typical web UI thinking. There is no better UX an app can have than NATIVE looking GUI. Every damn web developer should repeat this sentence at least 10 times a day. Using react/angular/js/electron base UIs for standard desktop applications is CANCER-like behavior, sorry for being honest. Web UI should be really provided as an alternative for people who really really want it on some obscure platforms/use-cases. |
Beta Was this translation helpful? Give feedback.
-
|
@martinrotter |
Beta Was this translation helpful? Give feedback.
-
|
It depends on the goal, should the WebUI be a complete alternative than the desktop GUI? Any user on the WebUI is way more likely to use a touch input, with limited screen size than a desktop computer , and a more imprecise input (touch). All my access to qBitTorrent is via the browser, half of the time on a laptop, half the time via the phone, even with the challenging UX. With a better UX, I think probably 90% would be via my phone :) I would love a simplified UX for uploading torrents and looking at their progress on the phone :)
I would love a tailored user experience to the user device, and am ready to contribute! |
Beta Was this translation helpful? Give feedback.
-
|
Recently converted to qbittorrent from Transmission. I hope this effort to rewrite the API and WebUI continues. I have been running my BACK END on my NAS for years and used remote native frontends over API with Transmission. I think to keep all camps happy it would make a lot of sense as mentioned previously to make a COMPLETE API, then take the current native front end and switch it to use the API. You could then use OS native front ends OR the web frontend with a common API, the code for the core app could END at the API and the front ends could all be spun off as separate projects. I believe this is also how deluge works or at the very least the desktop app has the option to switch from a local to remote backend. For desktop users you just by default install the native front end already pointed to the backend API they never see a difference, but for NAS users or those that want to run a remote backend hosted separately this becomes very flexible. For very advanced users as long as your API is easy to authenticate to they can also automate ANY task just by writing scripts that call the API via something like CURL which can be very powerful for large seeding boxes. |
Beta Was this translation helpful? Give feedback.
-
|
Greetings, is a dark mode option going to be available in future builds? I use qbit via web ui from a headless raspberry pi |
Beta Was this translation helpful? Give feedback.
-
|
@drsepanta Has there been any movement on this? If so, I'd love to contribute |
Beta Was this translation helpful? Give feedback.
-
I have done lots of web development, and I believe qBittorrent deserves a better web ui user experience.
I opened this issue to get some feedback from the maintainers.
How do you feel we rewrite the whole Web UI in React?
Beta Was this translation helpful? Give feedback.
All reactions