crazy-macs/obsidianar.git

迭代需求描述-26.0505-1

（26年5月5日提的优化需求第1批的意思）

设置-增加3项功能
左侧Tag 字体可以调整大小（有滑轨调整，可实时预览效果）
右侧APP列表显示的列数可调整——但无论怎么调都是必须对齐的
重新index，一旦用户修改了系统APP的标签，点击重新生成目录即可保证界面上的标签是最新的

迭代需求描述-26.0505-2

（26年5月5日提的优化需求第2批）


假死	bug修复	目前有假死现象，使用时系统cpu占用高达100% 假死前发生的动作：用户在设置中修改了字体大小为最大
设置项调整	优化	字体最小16，最大26

迭代需求描述-26.0505-3

（26年5月5日提的优化需求第3批）


加一个默认分类 “”Mac自带“”	优化	把Mac电脑初装时由苹果公司默认安装的所有应用都打上这个标签，这个分类显示在整个列表的最下边。
增加上一条分隔线，每个Tag位置都横向的都增加一个横线，以加强视觉的清晰性。同时把tag显示在横线的居中位置。注意视觉的优美性。线条不能太粗也不能太细，颜色不能太深也不能太淡。	UI优化	字体最小16，最大26

迭代需求描述-26.0505-4

（26年5月5日提的优化需求第4批）


假死	bug修复	打开即假死
强制退出应用程序找不到APPtag这个应用	bug修复	因为找不到APPtag这个应用。导致当用户在使用第一个屏幕时，连强制退出都无法退出。因为在出现死机时，APP tag的假死界面占据了整个屏幕的所有位置，而且显示在最顶上。

迭代需求描述-26.0505-5

（26年5月5日提的优化需求第5批）

需求简述：优化顶部显示，隐藏掉刘海屏
性质：视觉优化
需求描述：目前在有刘海屏的电脑上会明显地看到刘海屏很丑。所以把刘海屏的位置向下推，用一个纯黑的色块完全遮住---宁可完全浪费掉这块区域，什么都不显示。

迭代需求描述-26.0505-6

（26年5月5日提的优化需求第6批）

需求1：修复全屏状态下不能显示的问题。
性质：bug
需求描述：目前在全屏界面下，不能显示APP tag的全屏界面。必须去滑动到没有全屏窗口的界面才能看到---这个问题很要命。因为这样的话，用户有可能找不到界面，从而不会使用。
需求2：修复设置界面被遮挡的问题
性质：bug
需求描述：目前当APPtag显示APP列表的时候，如果用户想对APPTAG进行设置。设置界面被apptag自己的界面完全遮挡住了，从而无法操作。

迭代需求描述-26.0505-7

（26年5月5日提的优化需求第7批）

需求1：设置中去掉第一项
性质：优化
需求描述：把other重命名这个设置项去掉
需求2：设置界面改字体出现无法左边菜单显示不完全的情况
性质：优化
需求描述：设置界面方框太小。导致字体设置、名字显示不完整（如图1）
需求2：是第三项也改成滑轨
性质：优化
需求描述：columns设置成和字体设置一样的滑轨样式

迭代需求描述-26.0505-8

（26年5月5日提的优化需求第8批）

需求1：在界面的顶部显示标签，通过点击即可实现快速跳转
性质：优化
需求详述
1. 标签显示在顶部，以悬停的方式。
2. 标签背景带有颜色--和系统本身标签的颜色完全一致。
3. 用户点击可实现快速跳转
4. Mac自带这个标签，作为最后一个标签存在
需求2：在界面上优化搜索栏的位置和使用方式
性质：优化
需求详述
1. 目前搜索不可用（鼠标点击没有反应）
2. 搜索的显示位置可以放在顶部居中（位置在黑色刘海的下面，在标签行的前面）

迭代需求描述-26.0505-9

（26年5月5日提的优化需求第9批）

需求1：支持顶部标签显示到左边
性质：优化
需求详述
1. 支持标签显示在侧边，以悬停的方式
- 侧边可以是左边也可以是右边
- 设置中有三个选项：顶部，左边，右边——软件初次安装后默认是左边
1. 当在侧边显示时
- 标签区域不得显示APP图标
- 整个APP图标显示区域和侧边标签区有一条看不见的线相区隔
需求2：修复快速搜索无法使用的问题
性质：优化
需求详述：
- 现在的快速搜索，鼠标点击没有反应
- 正确的交互应该是点击点击就可以输入
- 一边输入一边实时筛选
- 匹配规则
  - 支持模糊匹配
  - 支持字段的任意部分（不要求必须是从首字母开始匹配）
  - 支持英文，也支持亚洲字符

迭代需求描述-26.0505-10

（26年5月5日提的优化需求第10批）

需求1：优化设置-字体的方式
性质：优化
需求详述
- 现在字体设置从16到26-可调整项过多
- 简化成16,18,20,22,24,26共6档即可
需求2：优化设置-纵向栏目（columns）的方式
性质：优化
需求详述
- 现在的设置方式从3到10选项太多了
- 简化成5,6,7,8,9,10共5档即可
需求3：快速搜索仍然不可用
性质：bug
需求详述
- 需求不变，现在的问题是不可用，需要能用

迭代需求描述-26.0505-11

（26年5月5日提的优化需求第11批）

需求1：优化设置-增加图标大小控制
性质：优化
需求详述
- 先帮忙查一下当前默认的图标大小是多少
- 以当前默认的图标大小为起点，给多5种尺寸选择
- 注意，图标显示的行列要随着图标的大小自动伸缩
- 不能出现图标和文字重叠的现象
需求2：优化光标选择和点击图标的显示
性质：新特性
需求详述：
- 类似docker上的交互体验
- 当光标移上图标
  - 图标就会自动放大
  - 还可以加上阴影（以给用户造成图标浮动凸起的感觉）
- 当光标从图标上移开
  - 则图标回归原状

迭代需求描述-26.0505-12

（26年5月5日提的优化需求第12批）

需求：移除APP搜索功能
性质：优化
需求详述
- 把搜索功能去掉

本次需求做完，告诉我当前APP的版本号是多少。

迭代需求描述-26.0505-13

（26年5月5日提的优化需求第12批）

需求：增加版本号的显示
性质：优化
需求详述
- 在顶部菜单栏-增加版本号显示。
- 在设置新增一个tab作为最后一个tab
- 上面显示版本号

迭代需求描述-26.0505-15

需求：增加一个编辑模式
性质：new feature
需求描述
- 编辑模式进入（触发）方式
- 屏幕右上角有一个编辑图标（一只笔）
- 键盘快捷方式是 CTRL+E
- 当用户触发了编辑模式时
- 画面上所有标签和APP全部消失，只留下原模糊背景和一下选择提示
- 选择（二选一）
- 您即将进入编辑模式
- 请问您是要编辑标签还是要编辑APP的分类（Tag）
- 当用户选择【我要编辑标签】
- 页面上所有的APP图标消失，只剩下左侧的APP列表
- 左侧标签列表可以增加标签
  - 除了增加还可以做改名和删除
  - 还可以对指定标签颜色
- 这里对标签的增改删以及指定颜色
  - 其发挥作用都是和finder全局同步且一致的
- 当用户选择【我要编辑APP分类（Tag）】
- 所有的APP上都浮现出勾选框
- 用户可以多选
- 然后用户把多选后的APP拖动到左边的标签上
- 画面出现提示-分类成功
  - 同时右边APP的分类立刻刷新，更新到最新分类方式
本次更新完之后，版本号改为 V1.1.0

迭代需求描述-26.0505-16

（26年5月5日提的优化需求第16批）

需求：修改【我要编辑APP分类（Tag）】的交互方式
当用户选择【我要编辑APP分类（Tag）】
- 所有的APP上都浮现出勾选框，同时所有的标签上面也出现勾选框
- 用户可以多选APP，也可以多选APP
- 当用户点击
- 【确定】，出现提示-分类成功
- 【取消】，则回到尚未做任何选择的状态
本次更新完之后，版本号改为 V1.1.1

迭代需求描述-26.0505-17

（26年5月5日提的优化需求第17批）

本版需要修复两个bug

Bug1：页面会闪退或消失不见
问题描述：当用户选择【我要编辑APP分类（Tag）】
这时候页面会消失不见
除非用户再去菜单找到show APPtag——时候看到界面出现了，也确实是在编辑状态。
请修复这个”会消失不见“”的问题。
Bug2：没有退出
问题描述：
- 当用户在编辑APP分类（Tag）时
- 整个页面没有退出编辑状态的按钮
建议的修复方案
1. 把确认（confirm）改为鲜艳的蓝色
2. 同时在左手边放一个灰色按钮，上面有一个Exit的图标和文字“退出编辑状态”
- 当用户点击退出编辑状态后
- 页面恢复到正常状态（正常状态是相对于编辑状态而言的）
本次更新完之后，版本号改为 V1.1.2

迭代需求描述-26.0505-18

（26年5月5日提的优化需求第18批）

本版需要修复1个bug

Bug1：标签无法编辑
问题描述：当用户试图编辑标签时（无论是新增标签还是修改标签），光标移上之后无法输入。
本次更新完之后，版本号改为 V1.1.3

迭代需求描述-26.0506-1

（26年5月6日提的优化需求第1批）

本版在设置中增加一个feature

需求：设置中增加一个Tag-editor
需求描述：
- 在setting里面增加第二个tab,标题是tag
- 在这个页面维护标签
- 可以显示所有已有的标签
- 可以增加标签
  - 除了增加还可以做改名和删除
  - 还可以对指定标签颜色
  - 这里对标签的增改删以及指定颜色
  - 其发挥作用都是和finder全局同步且一致的
- 这个页面如果标签太多，显示不下,可以上下滚动，有滚动条。
本次更新完之后，版本号改为 V1.1.4

迭代需求描述-26.0506-2

（26年5月6日提的优化需求第2批）

需求1：去除编辑模式里面对tag的编辑
性质：优化
需求描述：
- 去除编辑模式里面对标签的编辑
- 所以在点击编辑模式时，不再出现编辑标签还是对tag进行分类的选择这个页面
- 保留setting中对标签的编辑
需求2：修复Setting中标签编辑的bug
性质：bug修复
需求描述：
- 现在发现修改标签会造成产生一个新的标签
- 澄清一下修改标签的内涵
- 修改当前这个标签的名字及颜色
- 把原来系统中打这个标签的应用，全部改成应用新标签
本次更新完之后，版本号改为 V1.1.5

迭代需求描述-26.0506-3

（26年5月6日提的优化需求第3批）

需求1：优化提示1
性质：优化
需求描述：
- 当我在founder里面给一个APP添加标签时，如果这个标签是通过AppStore下载的，往往会弹出窗口，要求我输入密码或验证指纹
- 但现在我用APP tag在修改标签时，它不弹出这个窗口（提示我输密码或验证指纹。），只会直接失败。
- 请解决这个问题，解决方案：
- 遇到这种情况，立刻弹出窗口，让用户输入密码或验证指纹。
本次更新完之后，版本号改为 V1.1.6

迭代需求描述-26.0506-4

（26年5月6日提的优化需求第4批）

需求1：优化提示1
系统应用在 /System/Applications/ ─受 SIP 保护，即使管理员权限也写不了。
凡是符合这种情况的APP。在编辑模式下，上面都有一个禁止操作的半透明符号，不提供勾选功能。当用户试图点击。出现提示“系统应用，无法编辑标签分类”

迭代需求描述-26.0506-5

（26年5月6日提的优化需求第5批）

需求：大幅优化标签逻辑
需求背景：
- 现在APP tag的逻辑，所有的标签和finder的标签是同步的。但finder的标签编辑受到很多限制--比如系统权限等等。
需求说明
- 把标签的管理和finder完全脱离。
- 从这个版本起
- APPtag编辑的所有标签都是独立存储独立维护的，只用来在APP tag里面对标签进行分类展示。和finder完全没关系。
- 系统已有标签，仅在初始化时作为第一批标签的来源使用。包括（Mac自带）这个标签。
- APP tag所维护的所有标签方案，自己保存在一个独立的数据库里面。支持导出和导入。

本次更新完之后，版本号改为 V2.0

迭代需求描述-26.0506-6

（26年5月6日提的优化需求第6批）

需求：导出功能优化
数据导出里面的导出不只是导出tag，而是导出每个tag下面都有什么APP，或者每个APP都归属于什么tag这个信息
这样方便在电脑重装后快速恢复分类信息
你检查一下你的代码是否这样实现的。如果没有，请把这部分逻辑修改一下。

本次更新完之后，版本号改为 V2.0.1

迭代需求描述-26.0506-7

（26年5月6日提的优化需求第7批）

需求：增加排序功能
性质：新需求，交互优化
需求描述：
- 用户可以在编辑页面拖动标签的显示位置。右侧该标签所归属的APP的排序位置会相应地发生变化。
本次更新完之后，版本号改为 V2.0.2

迭代需求描述-26.0506-8

需求：增加APP列表显示的**容器样式**
性质：新需求，交互优化
需求描述：
- 用户可以在设置中选择APP列表的显示样式是平铺还是容器？
- 该设置项在设置第一个页签的第一个行
- 样式是标准的Radio样式
- 如果是平铺，就是现在这种样式
- 用户选择容器，则显示为以下样式
- 容器样式的意思是
  - 当前分类（TAG）的APP在一个圆角矩形框里面
  - 圆角矩形框的大小取决于当前分类（TAG）中有几个APP（宽度一行最少要能显示3个APP）
  - 圆角矩形从左向右，从上到下依次排列——在整个画面中的排版完全灵活自适应
本次更新完之后，版本号改为 V3.0.1

迭代需求描述-26.0506-9

需求：增加APP列表显示的**容器样式**
性质：交互优化
需求描述：
- 在容器样式下
- 所有的圆角矩形容器从左到右依次铺开
- 所有的容器之间是物流流式排列，为了保证屏幕铺满
- 容器内部每一行有几个图标是自动动态调整的
- 最终效果是：同宽度的容器从左到右按次序占满屏幕
本次更新完之后，版本号改为 V3.0.2

迭代需求描述-26.0506-10—作废

需求：优化**容器样式的显示方案**
性质：交互优化
显示方式描述
- 和flat模式下一样，所有的APP都是在一个看不见的网格构图里面
- 所有的APP纵向横向都是在（对齐）方格里面的
- 所有小容器按行依次排列
- 小容器之间不允许纵向有参差不齐的现象
- 只允许小容器内部有空位
- 同一行的小容器高度必须一致
- 要么都是一列高
- 要么都是两列高
- 要么都是三列高
- 同一行的容器，不能出现你有1列，我有3列这种情况
- 所有的小容器布满了整个空间，同时小容器与小容器之间留出统一的间隔（16PT）
- 小容器内部允许空间浪费（因为APP数量不够，所以留空）
- 但小容器与小容器之间不允许空间浪费
- 所以最终
- 要么整行只有一个小容器。
- 要么整行有2到3个、4个、5个小容器
- 所有的小容器加起来总个的总共的空间在显示屏上是居中的
  - （从屏幕的最左到最右是居中的）
本次更新完之后，版本号改为 V3.0.3

迭代需求描述-26.0506-11

需求：增加设置项-隐藏APP名称
性质：交互优化
需求描述：
- 增加设置项-隐藏APP名称
- 样式：Radio开关
本次更新完之后，版本号改为 V3.0.4

迭代需求描述-26.0510-01

需求：优化鼠标hover的交互
性质：交互优化
需求描述：
- 鼠标移动上每个标签时
- 整个区域的背景都变成标签的颜色
- 以突出显示这个标签对应的container的区域
- 移除掉原来点击边框加粗并变色的交互逻辑

迭代需求描述-26.0510-02

需求：优化容器内填充颜色相关的交互
性质：交互优化
需求描述：
- 现在的交互是
- 鼠标移动上每个标签时
  - 整个区域的背景都变成标签的颜色，以突出显示这个标签对应的container的区域
  - 但鼠标从标签上移开时，整个区域的颜色又恢复原状
- 新的交互是
- 鼠标移动上每个标签时
  - 整个区域的背景都变成标签的颜色，以突出显示这个标签对应的container的区域
  - 但鼠标从标签上移开时，整个区域的颜色仍保持原颜色
  - 直至再次点击该标签，或者在容器内部的空白处再次点击时
  - 区域底部所填充的颜色又被移除，恢复成未填充颜色状态

迭代需求描述-26.0510-03

需求：增加一个APP列表的显示样式
性质：交互优化
需求描述
- 把现在的第2种样式（现名称：分组）改为“无色容器”
- 注意“无色容器”在其他语言版本下要有对应语言的名称
- 增加第3种视图样式，名称：彩色容器
- 和第2种样式的唯一区别是
- 所有容器加一个填充色（就是容器本身标签的颜色）
- 鼠标hover与移开
  - 鼠标hover到该容器区域时，增加一个凸起的效果（通过给整个容器增加阴影来实现这种视觉效果）
  - 鼠标离开该容器区域后，凸起效果消失，恢复正常
这个需求实现后，版本号更新为3.2.0

迭代需求描述-26.0510-04

需求讨论
关于一种新的APP列表样式可能性的讨论
- 现在第2种无色容器和第3种彩色容器的本质都是瀑布流
- 瀑布流实现的视觉效果有个缺点
  - 所有的APP从纵横来看是不对齐的
- 为了解决这个不对齐的问题：我提出以下一种思考方式，你帮忙分析下，是否可以实现
- 我假想中拟实现的效果有以下几个特点
- 1、纵横图标都是对齐的
  - 就是画面其实是存在隐形的网格状
  - 即使APP是装在大小不一的容器中
- 2、关于容器我有以下要求
  - a.容器首先必须遵守一个限制：容器内部绝对不能出现左右或上下的滚动条
  - b.横向同一行的容器数量只能有三种情况：要么是1个容器，要么是2个容器，要么是3个容器
  - c.横向同一行的容器数量超过1时，同一行所有容器的宽度必须是一致的（就是同一行的要么被1个容器把屏幕宽度占满，要么被2个等宽的容器把屏幕宽度占满，要么被3个等宽的容器把屏幕占满）
  - d.横向同一行的容器的宽度可以不一致，但高度一定是一致的
  - 就是说同一行的容器，要么都是都只能容纳1行APP，要么都能容纳2行APP，要么都能容纳3行APP……以此类推
  - **为了同时保证以上abcd规则同时实现，允许单个容器内有空位置（无论有几个空位置都可以接受）

迭代需求描述-26.0510-05

视图2和视图4统一光标hover交互效果

需求描述
光标hover每个标签时
- 整个容器区域的背景都变成标签的颜色，同时增加一个凸起的效果（通过给整个容器增加阴影来实现这种视觉效果）
- 以突出显示这个标签对应的container的区域
- 移除掉原来点击边框加粗并变色的交互逻辑（如果代码种有这个逻辑，如果没就忽略此要求）
- 鼠标离开该容器区域后，颜色和凸起效果均消失，恢复正常
鼠标点击区域或标签
- 整个容器区域的背景都变成标签的颜色，同时增加一个凸起的效果（通过给整个容器增加阴影来实现这种视觉效果）
- 以突出显示这个标签对应的container的区域
- 移除掉原来点击边框加粗并变色的交互逻辑（如果代码种有这个逻辑，如果没就忽略此要求）
- 再次点击后，颜色和凸起效果均消失，恢复正常

迭代需求描述-26.0511-01

所有5个视图均增加拖动归类的交互

当光标在APP上按住足够久，所有光标开始晃动，意思是可以拖动改变位置了（参考原macos自带的lauchpad对应的移动APP位置的逻辑，和其逻辑以及交互效果保持一致），
拖动方式1-移动式拖动
从A标签容器拖动到B标签容器
- 等效于
- 对当前APP移除A标签，打上B标签
- 注意
- 只要B标签容器含有空位，就默认放在最后一个位置
- 如果B标签容器没有空位，就先把当前APP拖动指定的位置
  - 等松手后，再重新计算整体布局，调整容器的高宽
  - 注意写完这部分逻辑后要验证一下，不要有死循环或其他程序风险导致程序假死或崩溃。
拖动方式2-复制式拖动
按住 Option (⌥) 键，从A标签容器拖动到B标签容器
- 等效于
- 对当前APP保留原A标签，增加打上B标签
- 注意
- 只要B标签容器含有空位，就默认放在最后一个位置
- 如果B标签容器没有空位，就先把当前APP拖动指定的位置
  - 等松手后，再重新计算整体布局，调整容器的高宽
  - 注意写完这部分逻辑后要验证一下，不要有死循环或其他程序风险导致程序假死或崩溃。

迭代需求描述-26.0511-02

发现一个功能缺陷

编辑视图下无法移除已添加的标签
情况说明
- 用户给1个APP打了A标签和B标签
- 现在用户的意图是想去掉这个B标签
- 用户点击进入了编辑模式,并选定了APP
- 此时，用户预期的效果是
  - 该APP在左侧的标签列表那里出现了A标签和B标签都被勾选，且高亮的效果。
  - 用户去掉B标签的勾选
  - 再点击确认
  - 此时，APP就只剩下了归类为A标签
- 但现在的实际情况是
- 用户进入编辑模式选定了APP后
  - 左侧的标签列表没有任何变化
  - 所以导致用户无法移除掉B标签

迭代需求描述-26.0513-01

做一个优化

在列表查看视图下，增加标签的拖动排序
1-是**新增**一种操作逻辑
- 现在是支持标签拖动排序的
- 但是仅支持在编辑状态下进行标签的拖动排序
- 保留这个交互逻辑，不要改变
- 现在我要的是在保留这个交互逻辑的前提下，新增一种标签拖动排序的交互
2-新交互逻辑的说明
- 无论用户当前在应用列表样式的哪一种（就是说5种都可以）
- 也无论用户当前的应用列表视图中，标签位置在左侧还是在右侧还是在顶部（就是说在哪里都行）
- 标签都可以拖动排序
- 具体怎么拖动
- 触发条件：参考拖拽图标的触发条件
  - 只要用户的鼠标长按住标签到达一定时间（和拖拽图标的时长保持一致）
  - 就进入标签的轻微晃动状态——意思是可以拖动了
- 拖动交互
  - 标签拖动排序的交互和编辑状态下拖动效果基本一致
  - 拖动到位之后
  - 出一个动效-给出拖动发生效果的交互反馈
  - 就是标签从A位置挪到了B位置
  - 标签所对应的容器也会从A位置挪到B位置