Qbittorrent: 替代 WebUI 开发讨论

优秀的@FranciscoPombal 。 只是为了更容易地参考本主题的贡献者，这些是 Alt WebUI https://github.com/qbittorrent/qBittorrent/issues/7217和https://github.com/qbittorrent/qBittorrent/pull/7610上的原始开发讨论

我很高兴为 WebUI 的新实现做出贡献。

实际上，我最近正在查看https://github.com/qbittorrent/qBittorrent/wiki/Web-API-Documentation以计划如何实现新的 WebUI。

这些是我目前的目标：

1. WebUI 作为 SPA（单页应用程序）
2. 响应式设计（目前我正在努力在手机上打开 UI 并在搜索选项卡中搜索种子下载）
3. 现代但轻巧的设计
4. i18n 支持
5. （可选）0Auth2.0 支持 - 这需要一些后端工作。

让我知道你的想法。

我希望如果引入响应式设计不会添加不必要的依赖项，并且不会像 Bootstrap 那样减慢 Web 界面的速度。

我想看到_all_webui 中公开的选项和设置，以便可以在 webui 中完全控制和配置 headless/qbittorrent-nox。 例如，要将 qbittorrent-nox 锁定到 tun0，我必须在 VM 中安装 Linux 桌面和 GUI 版本的 qbittorent，将其锁定到 tun0，然后解析锁定设置并将它们粘贴到我的 qbittorrent-nox 配置中。 那可不太方便。

一般来说，在 webui 中具有完全的可用性和可配置性应该是一个目标。 如今的许多应用程序甚至都不关心应用程序，他们只是选择带有 webui 前端的后端，因为没有移植，并且可以在人们已经使用的大多数设备（PC、笔记本电脑、平板电脑、手机、等等）。

我希望如果引入响应式设计不会添加不必要的依赖项，并且不会像 Bootstrap 那样减慢 Web 界面的速度。

是的，一点没错！ 唯一比垃圾用户界面更糟糕的是用户界面缓慢。 我会接受快速的废话而不是慢的任何东西。

我用 Vue + TypeScript 构建了一个新的 WebUI。 它具有响应式设计，除了设置 UI 外，大多数核心功能都可以工作。
像勇士一样勇敢的人可能想尝试一下：
https://github.com/CzBiX/qb-web

我不久前提出的一些东西 (https://github.com/qbittorrent/qBittorrent/issues/7217#issuecomment-328541796 :-) 可以提高更安全地测试 altWebUI 的能力（意思是，能够始终控制如果没有崩溃），则保持 WebUI 核心始终运行（即在 http://qBwebUI:port/），如果启用，则 altWebUI 位于固定子树（即 http://qBwebUI:port/altWebUI/）中通过设置，而不是一个（核心）或另一个（替代）专门运行的当前情况。

你们有什么感想？

我想看到_all_webui 中公开的选项和设置，以便可以在 webui 中完全控制和配置 headless/qbittorrent-nox。 例如，要将 qbittorrent-nox 锁定到 tun0，我必须在 VM 中安装 Linux 桌面和 GUI 版本的 qbittorent，将其锁定到 tun0，然后解析锁定设置并将它们粘贴到我的 qbittorrent-nox 配置中。 那可不太方便。

在 4.2.4 中，可以将 qbittorrent“锁定”到特定的 VPN 接口，并且不会出现泄漏。 这是由于最近修复了网络接口设置代码以及 libtorrent 端 (1.2.6) 的修复。

我不久前提出的一些东西（ #7217（评论） :-) 可以提高更安全地测试 altWebUI 的能力（意思是，如果没有崩溃，可以始终控制程序），就是始终保持 WebUI 核心运行（即在 http://qBwebUI:port/），以及固定子树中的 altWebUI（即 http://qBwebUI:port/altWebUI/），如果通过设置启用，而不是当前情况（核心）或另一个（alt）专门运行。

你们有什么感想？

我完全支持这种方法。

我简要地看了一下@CzBiX方法，对我来说它看起来不错。 材料设计是我想我们都熟悉的东西。 实施似乎也很棒。

@CzBiX我愿意加入你已经拥有的东西，并开始在你的工作基础上进行开发。

我还认为，如果我们在 Figma 中开始设计原型。 我知道这会使过程变得更重，但这是值得的。

@WolfganP有一种解决方法可以实现您的想法。
我建议使用alt WebUI作为主 UI（在qb:port/ ），并使用默认/官方 WebUI作为 alt UI（在qb:port/alt/ ，当启用 alt WebUI 时。

@bbogdanov我不擅长设计，所以你可以按照你想要的方式设计它。 我会关注你的设计作品。
我唯一要求的是 UI 控件应该被压缩，而不是过度设计以占用大量空间。

我建议使用alt WebUI作为主 UI（在qb:port/ ），并使用默认/官方 WebUI作为 alt UI（在qb:port/alt/ ，当启用 alt WebUI 时。

有一个选项来提供带有/alt/前缀的默认 UI 对我来说有点混乱。
我认为最好为 _all_ 可用用户界面（包括默认用户界面）提供相应的前缀，并且有可能将默认（ qb:port/或其他）路径重新路由到这些用户界面之一。

我建议使用alt WebUI作为主 UI（在qb:port/ ），并使用默认/官方 WebUI作为 alt UI（在qb:port/alt/ ，当启用 alt WebUI 时。

根据标志来翻转默认 webif 的访问方式似乎很尴尬。 它应该是一致的，这是有道理的。 默认 webif _always_ 可在qb:port/ ，alt webif _always_ 可在qb:port/alt/ 。

@bbogdanov我不擅长设计，所以你可以按照你想要的方式设计它。 我会关注你的设计作品。
我唯一要求的是 UI 控件应该被压缩，而不是过度设计以占用大量空间。

我非常喜欢充分利用您拥有的空间，只要它不过分杂乱即可。 我讨厌当你不得不去菜单潜水或翻页来做一些很容易在主页上找到的东西时。 我建议尽可能避免导航（其他页面、菜单、弹出窗口等）。

我认为最好为 _all_ 可用用户界面（包括默认用户界面）提供相应的前缀，并且有可能将默认（ qb:port/或其他）路径重新路由到这些用户界面之一。

我认为不应该重新路由、覆盖默认值等。我认为最好始终在一致的 url 中使用默认 webif，这样您就可以始终导航到它而不会弄乱设置。

我认为不应该重新路由、覆盖默认值等。我认为最好始终在一致的 url 中使用默认 webif，这样您就可以始终导航到它而不会弄乱设置。

默认 UI 应该始终可以通过某些持久路由作为后备访问，这是不言而喻的。 问题是我们是否应该有可能在没有前缀的情况下选择要提供的 UI。

默认的 webif 总是在qb:port/和任何备用 webif 的qb:port/name/怎么样。 如果我安装了 3 个 webif（CzBiX、ngseer、bacon），那么我可以使用qb:port/CzBiX/ 、 qb:port/ngseer/或qb:port/bacon/轻松选择哪一个。 这样你就可以拥有无​​限的替代品和一种简单的方法来访问它们。

您可以在存储它们的配置路径中有一个目录。 如果我的配置路径是/qb/config/ ，则将它们存储在/qb/config/webui/CzBiX 、 /qb/config/webui/ngseer 、 /qb/config/webui/bacon等中。

此外，webui 可以添加功能，比如 qb 标志，如果你点击它，你会得到一个所有已安装的 webui 的列表+默认值，你可以从中进行选择，以便在不同的之间轻松切换。

嗨，大家好，

距离上一篇关于这个主题的帖子已经一个多月了。 想知道是否已经做出最终决定？

@培根芝士汉堡

不幸的是，没有人真正在做这件事，因为有更高优先级的问题，而且每个人的时间都很紧张。 此外，不能通过更改设置来动态更改 WebUI 吗？ 还是需要重启？

我不时进行设计。 我正在使用 Figma，所以如果有人愿意加入，我可以邀请他到工作区。

这就是我目前所拥有的。 我正在为桌面版本重新创建当前布局，然后我会考虑布局是否需要更改。

移动视图是一个挑战，我认为桌面视图中存在的很多信息必须隐藏在那里，但我们会看到我仍在试验它。

@bbogdanov在材料设计方面
是的，由于桌面视图提供了屏幕上的所有信息，因此移动视图具有挑战性。 我看到的最有用的布局是主列表视图（只显示几个值以快速验证整体状态），然后跳转到列出的每个种子的卡片样式，其中包含该项目的所有可用信息。

2.响应式设计（目前我正在努力在手机上打开用户界面并在搜索选项卡中搜索种子下载）

我认为这是关键，因为加载大约 100 个种子需要很长时间来解析。

我在意见上取得了一些进展。 其中一些是相同的页面，但设计不同。

我认为设置可以放在不同的页面中，但老实说，我认为模式是此应用程序的最佳解决方案。 我想采用与我用于 torrent 表相同的方法。 折叠每个设置组的面板。

让我知道你的想法。

我喜欢。 由于这个原因，模态很好。 我认为移动视图的另一个很好的例子是nzb360 。 加载非常快。 它使用侧面板而不是模态，但我认为模态方法同样好。

我也喜欢它，但为了更好的可用性，我建议在显示列表时稍微区分交替行中的背景（它有助于在显示的项目上更准确地定位点击/触摸）。

@bbogdanov我喜欢你的设计！ 也有评论：
太多的空白空间 IMO。 顶部面板和种子行有点太高了。 种子详细信息的移动视图也是如此。 如果信息块之间的空白空间变薄，则可以容纳更多信息。

@bbogdanov我喜欢你最新的截图。 干净、整洁、快速是我最看重的，看起来这就是你创造的。 我期待着尝试并感谢您（和其他人）最近在该领域所做的工作！

我认为这些指南在这一点上就足够了，我可以开始编码了。

@pozemka我会在开发它的同时尝试降低

@CzBiX看到设计原型后你还在吗？

@bbogdanov这看起来不错。 然而，我认为有些元素太大了，当它们可以更小一点以提高空间效率时。 例如，主传输列表上的行高。 我并不是说最好让_一切_更密集，但有些东西_可以_在 IMO 中变得更密集，而不会使整体设计过于局促。

我同意。 在舒适和紧凑之间做出一些妥协。 像 GMail 这样的东西——不确定我们是否想要遵循 DLS，但至少是一个例子。

我的想法和上面一样，对我来说空间太多了。
@bbogdanov对不起，我最近很忙，我可能只有在一个月后才有时间来贡献。

@CzBiX不用担心。 我会开始，你有时间可以跳。

@FranciscoPombal你们有用于交流的聊天平台吗？ 我认为如果我们继续在这里沟通，问题会变得很大。

@bbogdanov我一直在chat.freenode.net:6697使用#qbittorrent chat.freenode.net:6697 。 不确定是否有 Gitter、Discourse 或其他内容。

@CzBiX你打算继续在你的

@CzBiX你打算继续在你的

计划是使用他的项目，并在他的工作之上构建我迄今为止分享的所有设计。
考虑到这一点，我将进行设置和搜索，然后我们可以根据设计指南调整主页。

我希望这能回答你的问题。

@bbogdanov感谢您的更新。 我担心 CzBiX webui 被放弃了。 关于设置，我想请求您也包括所有高级设置。 这是我们非 gui 用户的一个巨大劣势——webui 缺少只能通过 gui 访问的高级设置。 用户不必安装 gui 版本（以及运行它的桌面环境）来正确配置它。

@bbogdanov我很乐意帮助您进行移动设计 - 您有正在处理的

@bbogdanov我很乐意帮助您进行移动设计 - 您有正在处理的

我正在使用 Figma 进行设计。 我可以将你添加到项目中，但我需要一封电子邮件才能做到这一点。

从代码的角度来看，我并没有开始开发新设计。 我现在很忙，我想我可以在两周内开始为这个项目编码。

@bbogdanov我很乐意帮助您进行移动设计 - 您有正在处理的

我正在使用 Figma 进行设计。 我可以将你添加到项目中，但我需要一封电子邮件才能做到这一点。

从代码的角度来看，我并没有开始开发新设计。 我现在很忙，我想我可以在两周内开始为这个项目编码。

太棒了 - [email protected]！

@bbogdanov UI 看起来不错。 只是想知道，您对 RSS 支持也有任何想法吗？ 顺便说一句，继续做得很好，如果你能做到这一点，这将是 qbit 的最佳 webui。

@FranciscoPombal你能分享一下 Web API 文档发生了什么吗？ 好像被删了

@FranciscoPombal你能分享一下 Web API 文档发生了什么吗？ 好像被删了

https://github.com/qbittorrent/qBittorrent/wiki/WebUI-API- (qBittorrent-4.1)
还存在……