[Feature request]: 设为活动配置文件前检查，选择配置文件界面，以及复杂ProfileItem

[DHR60]

原因

• 设为活动配置文件前检查
  • 链式代理，节点分流，如果配置文件别名填错或不支持，应该显式通知用户
• 选择配置文件界面
  • 用户友好，选择切换更方便
  • 为 复杂 ProfileItem 做铺垫
• 复杂 ProfileItem
  • 多配置文件，最终配置随当前的路由等设置改变，而不是现在的生成为自定义配置
  • 可支持无限长链式代理
  • 可在节点分流中支持多节点

实现细节

前两个大概构思了下代码实现，应该是可以的

设为活动配置文件前检查

在调用 SetDefaultServer 前检查，新增一个 Helper 或者 ProfileItem 里新增一个函数，若检查不通过，则弹出提示并 return

选择配置文件界面

抽取出来 ProfilesListView UserControls，只负责显示配置文件列表和选择的配置文件，并提供若干“内容插槽”
新建一个 SelectProfilesDialog，包含 ProfilesListView，最后选择结果写到一个属性中，用法和 OpenFileDialog 类似
ProfilesView 包含 ProfilesListView，将右键菜单和“新增/编辑订阅”按钮放进插槽里
大概长这样

复杂 ProfileItem

ProfileItem 加入 List<string>? IndexId, EMultipleLoad? multipleLoad，代码上 CoreConfigService 应该需要部分重写，将现有的 List<ProfileItem> 传参替换为 ProfileItem，其他代码将其视为 custom ConfigType

[DHR60]

想问下可行性，方向没问题的话我写写试试

[2dust]

• 设为活动配置文件前检查
  • 链式代理，节点分流，如果配置文件别名填错或不支持，应该显式通知用户

这个功能应该可以做，用户手动操作时可以提示；但是还有很多自动触发的时候，这个不好处理。

• 选择配置文件界面
  • 用户友好，选择切换更方便
  • 为 复杂 ProfileItem 做铺垫

配置选择界面可以做一个简单的列表，界面也不需要显示这么多列。
万万不能用现有的 ProfilesView 重构复用；因为目前各个界面分离的代码已经很复杂了，加上各种线程回调，逻辑已经相当复杂。
是否考虑用正则查别名 替换掉现在的?

• 复杂 ProfileItem
  • 多配置文件，最终配置随当前的路由等设置改变，而不是现在的生成为自定义配置
  • 可支持无限长链式代理
  • 可在节点分流中支持多节点

初步考虑是不要大改 ProfileItem，可以加了一个自定义配置二，自定义配置三（或其他名称），然后再新建一个数据结构存储你后面想到的功能。
这样构造配置文件的时候，可以再写一个 自定义配置二 处理类，里面可以再调用需要的配置处理类。

[DHR60]

这个功能应该可以做，用户手动操作时可以提示；但是还有很多自动触发的时候，这个不好处理。

自动的就不管了，保证手动操作时能判断提示就行，比如 设为活动配置文件、开启TUN、生成配置 这些情况判断一下就好。

配置选择界面可以做一个简单的列表，界面也不需要显示这么多列。
万万不能用现有的 ProfilesView 重构复用；因为目前各个界面分离的代码已经很复杂了，加上各种线程回调，逻辑已经相当复杂。

也想过直接做一个简单的列表，但因为有订阅列表这个东西，如果在 SelectProfilesDialog 里纯 copy ProfilesView，重复代码就太多了。
所以我的想法是上面说的做一个 ProfilesListView UserControl，里面只放两个 ListView：一个订阅列表，一个配置列表。
至于这两个界面对控件的行为差异，可以用委托注入，或者搞一个 IProfilesListViewModel，走依赖注入。

是否考虑用正则查别名 替换掉现在的?

作为临时方案可行，但未来趋势肯定是要 UI 化的。

[DHR60]

初步考虑是不要大改 ProfileItem，可以加了一个自定义配置二，自定义配置三（或其他名称），然后再新建一个数据结构存储你后面想到的功能。
这样构造配置文件的时候，可以再写一个 自定义配置二 处理类，里面可以再调用需要的配置处理类。

也就是做一个 ProfileItem2 这种，也是储存在 SQL，然后界面和类间传参使用 ProfileItemBase 或者 IProfileItem 这样子？

[2dust]

1. 设为活动配置文件前检查 ，可行
2. 选择配置文件界面 ，做一个简单的独立界面吧。

[2dust]

复杂 ProfileItem
多配置文件，最终配置随当前的路由等设置改变，而不是现在的生成为自定义配置
可支持无限长链式代理
可在节点分流中支持多节点

建立一个 ProfileItem 子表，数据结构大概这样 ，应该能支持上面说的三种情况。
也可以直接在 ProfileItem 增加一个属性，里面存储 ProfileItem2 的 json，就是每次用的时候可能需要解析比较麻烦。

public Class ProfileItem2
{
    public int ParentIndexId; // 关联 ProfileItem.IndexIdId，是展示中的父级 id
    public int IndexId; // 关联 ProfileItem.IndexIdId，是参与的 id
    public int Sort; // 序号
} 

数据这样

[
  {
    "ParentIndexId": 1,
    "IndexId": 101,
    "Sort": 1
  },
  {
    "ParentIndexId": 1,
    "IndexId": 102,
    "Sort": 2
  }
]

[Diluka]

@DHR60 路由规则集能不能改为启用多个，或者独立一个用户规则集。我现在切规则的话，我的自定义内容全部都要重新创建一遍，又不支持复制粘贴规则。修改的话，也要每个常用规则集都打开改一遍，好麻烦。明明我的个人规则只有一份。

[2dust]

规则集中规则可以多选右键导出到剪贴板，到目标规则集中从剪贴板导入选追加

[Diluka]

规则集中规则可以多选右键导出到剪贴板，到目标规则集中从剪贴板导入选追加

这样更容易出错，还不如一条一条的改。

[DHR60]

@DHR60 路由规则集能不能改为启用多个，或者独立一个用户规则集。我现在切规则的话，我的自定义内容全部都要重新创建一遍，又不支持复制粘贴规则。修改的话，也要每个常用规则集都打开改一遍，好麻烦。明明我的个人规则只有一份。

没听懂
多开 v2rayN 吧

[DHR60]

功能请求建议新开 Feature Request Issue，并清楚说明想要的效果和目前的不足

[DHR60]

TODO：
- [ ] Group Profile 的测速
感觉是个大工程，但是做了比较好