Alternate WebUI development discussion

[FranciscoPombal]

Everyone is welcome to share ideas/code about the development of alternate WebUIs here.

Rules:

• This is not for feature requests about the main WebUI. However, if some good ideas come out of this discussion that have not yet been implemented or requested for the main WebUI, feel free to submit a separate feature request (or even better, a PR!).

• Please refrain from posting comments such as "+1" and "me too" to not clutter the thread too much, use reactions to express such feelings instead.

• Finally, I think this goes without saying, but do not whine about "why is this feature not in the main WebUI yet???".

Happy hacking everyone!

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/90905007-alternate-webui-development-discussion?utm_campaign=plugin&utm_content=tracker%2F298524&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F298524&utm_medium=issues&utm_source=github).

[WolfganP]

Excellent @FranciscoPombal . Just for easier reference to contributors of this topic, these are the original dev discussions on Alt WebUI https://github.com/qbittorrent/qBittorrent/issues/7217 and https://github.com/qbittorrent/qBittorrent/pull/7610

[bbogdanov]

I am happy to contribute to a new implementation of the WebUI.

Actually, I was looking lately at https://github.com/qbittorrent/qBittorrent/wiki/Web-API-Documentation in order to plan how to implement a new WebUI.

These are what my goals are so far:

1. WebUI as SPA (single page application)
2. Responsive design (currently I am struggling with opening the UI on my phone and search for torrents in the search tab to download)
3. Modern but lightweight design
4. i18n support
5. (Optional) 0Auth2.0 support - this one would require some back-end work.

Let me know what do you think.

[pozemka]

I hope responsive design if introduced wouldn't add unnecessary dependencies and don't slow web interface as it happens with Bootstrap.

[bacon-cheeseburger]

I would like to see all the options & settings exposed in the webui so headless/qbittorrent-nox can be fully controlled & configured in the webui. For example, to lock qbittorrent-nox to tun0, I had to install a Linux desktop and GUI version of qbittorent in a VM, lock it to tun0, then parse out the lock settings and paste them into my qbittorrent-nox config. That's hardly convenient.

Generally speaking, having full usability & configurability in the webui should be a goal. A lot of apps these days don't even bother with an app, they just opt for a backend with a webui frontend since there's no porting and works on most if not all devices people are already using (pc, laptop, tablet, phone, etc).

[bacon-cheeseburger]

I hope responsive design if introduced wouldn't add unnecessary dependencies and don't slow web interface as it happens with Bootstrap.

Yes, absolutely! The only thing worse than a crap ui is a slow ui. I'd take fast crap over slow anything.

[CzBiX]

I built a new WebUI with Vue + TypeScript. It has responsive design, and most of core functions works, except the settings UI. Who braves like a warrior may want to try it: https://github.com/CzBiX/qb-web

[WolfganP]

Something I brought up a while ago (https://github.com/qbittorrent/qBittorrent/issues/7217#issuecomment-328541796 :-) that may improve the ability to test altWebUI more safely (meaning, having the ability to always have control of the program if no crashing), is maintain the WebUI core always running (ie at http://qBwebUI:port/), and the altWebUI in a fixed subtree (ie http://qBwebUI:port/altWebUI/) if enabled via settings, instead of the current situation that's one (core) or the other (alt) running exclusively.

What do you guys think?

[FranciscoPombal]

I would like to see all the options & settings exposed in the webui so headless/qbittorrent-nox can be fully controlled & configured in the webui. For example, to lock qbittorrent-nox to tun0, I had to install a Linux desktop and GUI version of qbittorent in a VM, lock it to tun0, then parse out the lock settings and paste them into my qbittorrent-nox config. That's hardly convenient.

In 4.2.4 it will be possible to "lock" qbittorrent to a specific VPN interface, and there will be no leaks. This is due to recent fixes in the network interface setup code as well as fixes on the libtorrent side (1.2.6).

[bbogdanov]

Something I brought up a while ago (#7217 (comment) :-) that may improve the ability to test altWebUI more safely (meaning, having the ability to always have control of the program if no crashing), is maintain the WebUI core always running (ie at http://qBwebUI:port/), and the altWebUI in a fixed subtree (ie http://qBwebUI:port/altWebUI/) if enabled via settings, instead of the current situation that's one (core) or the other (alt) running exclusively.

What do you guys think?

I am totally up for this approach.

I did a brief look at the @CzBiX approach and it looks fine to me. Material design is something I suppose we are all familiar with. The implementation seems great as well.

@CzBiX I am open to join you with what you already have and start developing on top of your work.

I also think if we start a design prototype in e.g. Figma. I know it will make the process a little bit heavier but it is worth it.

[CzBiX]

@WolfganP There is a workaround to achieve your idea. And I suggest to use alt WebUI as main UI(in qb:port/), and use default/official WebUI as alt UI(in qb:port/alt/, when alt WebUI is enabled.

@bbogdanov I'm not good at design, so you may design it as what you wanted. I will follow your design works. The only thing I ask for, is the UI controls should be compacted, not over designed to take a lot of space.

[ngseer]

And I suggest to use alt WebUI as main UI(in qb:port/), and use default/official WebUI as alt UI(in qb:port/alt/, when alt WebUI is enabled.

Having an option to serve default UI with an /alt/ prefix looks a little confusing to me. I think it would be better to serve all available UIs (including default one) with corresponding prefixes and just have a possibility to re-route default (qb:port/ or whatever) path to one of these UIs.

[bacon-cheeseburger]

And I suggest to use alt WebUI as main UI(in qb:port/), and use default/official WebUI as alt UI(in qb:port/alt/, when alt WebUI is enabled.

It seems very awkward to flip how the default webif is accessed based on a flag. It makes sense that it should be consistent. The default webif always accessible at qb:port/ and the alt webif always at qb:port/alt/.

@bbogdanov I'm not good at design, so you may design it as what you wanted. I will follow your design works. The only thing I ask for, is the UI controls should be compacted, not over designed to take a lot of space.

I'm a huge fan of doing the most with the space you have as long as it's not overly cluttered. I HATE when you have to go menu diving or page flipping to do something that could have easily been available on the main page. I'd suggest avoiding navigating away (other pages, menus, popups, etc) whenever possible.

[bacon-cheeseburger]

I think it would be better to serve all available UIs (including default one) with corresponding prefixes and just have a possibility to re-route default (qb:port/ or whatever) path to one of these UIs.

I don't think the default should ever be re-routed, overridden, etc. I think it's best to always have the default webif available at a consistent url so you can always navigate to it without messing around with settings.

[ngseer]

I don't think the default should ever be re-routed, overridden, etc. I think it's best to always have the default webif available at a consistent url so you can always navigate to it without messing around with settings.

Default UI should always be accessible by some persistent route as a fallback, that goes without saying. The question is whether we should have a possibility to select which UI to serve without prefix or not.

[bacon-cheeseburger]

How about the default webif always at qb:port/ and any alternate webif's at qb:port/name/. If I have 3 webif's installed (CzBiX, ngseer, bacon) then I can easily select which one with qb:port/CzBiX/, qb:port/ngseer/, or qb:port/bacon/. That way you can have unlimited alternates available and an easy method of accessing them.

You can have a dir in the config path where they're stored. If my config path is /qb/config/, then store them in /qb/config/webui/CzBiX, /qb/config/webui/ngseer, /qb/config/webui/bacon, etc.

Also, the webui's could add functionality, say to the qb logo, where if you click it, you get a list of all the installed webui's + default that you can select from to make it very easy to flip between different ones.

[bacon-cheeseburger]

Hi guys,

It has been over a month since the last post on this subject. Was wondering if a final decision has been made?

[FranciscoPombal]

@bacon-cheeseburger

Unfortunately no one is really working on that, since there are higher priority issues and everyone's time is stretched thin. Besides, can't the WebUI be changed on the fly simply by changing the setting? Or does it require a restart?

[bbogdanov]

I am working on the design from time to time. I am using Figma for it so if someone is willing to jump in I could invite him to the workspace.

This is what I currently have. I am recreating the current layout for the desktop version and then I will think if there is a change needed in the layout.

The mobile view is a challenge and I think a lot of the information that exists in the desktop view has to be hidden in there but we will see I am still experimenting with it.

[WolfganP]

@bbogdanov nice work on material design :-) Yes, mobile views are challenging due all the info on screen that the desktop view offers. The most usable layouts I saw were a main list view (with just a few values displayed on it to quickly verify the overall status) and then jump to cards style for each one of the torrents listed with all info available on the item.

[jef]

2. Responsive design (currently I am struggling with opening the UI on my phone and search for torrents in the search tab to download)

I think this is key as loading anything about 100 torrents takes a long time to parse through.

[bbogdanov]

I have some progress on the views. Some of them are the same page but with different design.

I thought the settings can go in a different page but to be honest I think the modal is the best solution for this app. I think to go with the same approach I used for the torrent table. Collapse panels for each settings group.

Let me know what are your thoughts.

[jef]

I like it. Modals are nice for this reason. I think another good example of a mobile view is nzb360. Loads very quickly. It uses side panels instead of modals, but I think the modal approach is just as nice.

[WolfganP]

I like it as well, but for better usability I suggest to slightly differentiate the background in alternate rows when displaying lists (it helps to target clicks/touch more accurately on displayed items).

[pozemka]

@bbogdanov I like your design! And have a comment too: Too much empty space IMO. Top panel and torrents rows are little bit too tall. Same goes to mobile view of torrent details. You can fit much more information if thin empty space between information blocks.

[bacon-cheeseburger]

@bbogdanov I like your latest screenshots. Clean, uncluttered, and fast are what I value most and it looks like that's what you've created. I look forward to giving it a try and appreciate the work you (and others) have been doing in this area lately!

[bbogdanov]

I think these guidelines are enough at this point and I can start coding it.

@pozemka I will try to reduce the tallness while developing it.

@CzBiX Are you still on board after seeing the design prototype?

[FranciscoPombal]

@bbogdanov This looks pretty good. However, I think some elements are just to big, when they could be a little smaller for more space efficiency. For example, the row height on the main transfer list. I'm not saying it would be best to make everything denser, but a few things could be denser IMO, without making the overall design too cramped.

[jef]

I agree. Some compromise between comfortable and compact. Something like GMail has -- not sure if that DLS we want to follow, but at least an example.

[CzBiX]

My thoughts are the same as above, too many spaces to me. @bbogdanov Sorry, I am busy recently, I may only have time to contribute at month later.

[bbogdanov]

@CzBiX No worries. I will start and you can jump when you have time.

@FranciscoPombal Do you guys have some kind of chat platform that you are using for communication? I think the issue can get huge if we continue to communicate here.

[jef]

@bbogdanov I've been using #qbittorrent at chat.freenode.net:6697. Not sure if there is a Gitter, Discourse, or something else.

[bacon-cheeseburger]

@CzBiX Do you plan to continue working on your webui? I've been using it in dark mode and love it so far! Wondering if you intend to add settings and/or rss??

[bbogdanov]

@CzBiX Do you plan to continue working on your webui? I've been using it in dark mode and love it so far! Wondering if you intend to add settings and/or rss??

The plan is to use his project and build everything I've shared so far as designs on top of his work. Having that in mind I will work on the settings and the search and then we can adjust the main page to the design guidelines.

I hope that answers your question.

[bacon-cheeseburger]

@bbogdanov Thanks for the update. I was concerned that CzBiX webui was abandoned. Regarding settings, I'd like to request that you please include all the advanced settings as well. That's one huge disadvantage us non-gui users had -- the webui was missing the advanced settings that were only accessible thru the gui. Users shouldn't have to install a gui version (and desktop environment for it to run in) to properly configure it.

[jamiehowarth0]

@bbogdanov I'd love to help with mobile designs please - do you have a repo you're working on?

[bbogdanov]

@bbogdanov I'd love to help with mobile designs please - do you have a repo you're working on?

I am using Figma for the designs. I can add you to the project, but I will need an email to do that.

From code perspective, I didn't start developing the new designs. I am quite busy at the moment and I think I will be able to start coding for this project in two weeks.

[jamiehowarth0]

@bbogdanov I'd love to help with mobile designs please - do you have a repo you're working on?

I am using Figma for the designs. I can add you to the project, but I will need an email to do that.

From code perspective, I didn't start developing the new designs. I am quite busy at the moment and I think I will be able to start coding for this project in two weeks.

Fantastic - hello@jamiehowarth.me!

[Sparh4wk]

@bbogdanov UI looks rly good. just wondering, do you have any thoughts about rss support as well? btw keep doing great job, if you can make this real, it will be best webui for qbit.

[bbogdanov]

@FranciscoPombal Can you share what happened with the Web API documentation? Seems like it is deleted.

[c0re100]

@FranciscoPombal Can you share what happened with the Web API documentation? Seems like it is deleted.

https://github.com/qbittorrent/qBittorrent/wiki/WebUI-API-(qBittorrent-4.1) still exist...