关于属性视图创建文档和关联块属性的讨论

[zxhd863943427]

In what scenarios do you need this feature?

目前版本的属性视图新建文档后会生成一个不可见的子文档，但是这个子文档不会随属性视图的移动而移动。

这会在以下的常见操作中出现错误：

1. 移动属性视图，并删除属性视图原先所在的文档
2. 移动属性视图到另一个笔记本，并并关闭原所在笔记本
3. 移动属性视图到另一个笔记本，删除原所在笔记本

Describe the optimal solution

如果将建立位置改为笔记本下一个不可见的文档中，可以解决第一个问题，但无法解决2、3问题。

因此，可能更好的方法是建立一个单独的、不可见的、不可关闭的笔记本，并把属性视图新建的文档放在同名或任意其他特定标识的文档下。

并且可以配置一个设置选项，设置这个笔记本是否可见，允许需要看见真实文档位置和需要隐藏的用户都能满足需求。

Describe the candidate solution

No response

Other information

No response

[Temacc0531]

是不是可以在保持不可见的情况下，如果表格视图移动位置，底下的不可见文档跟随移动

[88250]

是不是可以在保持不可见的情况下，如果表格视图移动位置，底下的不可见文档跟随移动

不行的，一个块可以属于多个数据库。

[88250]

我个人更倾向于不要隐藏文档，这样用户可以根据自己的文档树管理方式来手动管理文档，虽然会稍显麻烦，但是从可控性上来说更好一些。

引入一种特殊的笔记本来存储这些文档可能会引入更多问题，比如这个笔记本是否允许手动管理文档，即创建、删除、移动、组织父子文档等。所以我觉得还是“如无必要，勿增实体”吧，数据库中进行创建行时创建非隐藏子文档更为实用可靠。

[zxhd863943427]

我个人更倾向于不要隐藏文档，这样用户可以根据自己的文档树管理方式来手动管理文档，虽然会稍显麻烦，但是从可控性上来说更好一些。

引入一种特殊的笔记本来存储这些文档可能会引入更多问题，比如这个笔记本是否允许手动管理文档，即创建、删除、移动、组织父子文档等。所以我觉得还是“如无必要，勿增实体”吧，数据库中进行创建行时创建非隐藏子文档更为实用可靠。

我觉得完全是可以的，引入一个特殊笔记也没有特殊到哪里去，实际上只是允许跨笔记本新建文档和增加一个模板变量而已，如果不需要隐藏，其他与普通的笔记本无异，不用考虑更多。

[88250]

不考虑不行的，就比如移动文档这个操作，如果允许移动的话那这个特殊笔记本就没有必要了啊，用户手动管理即可。

[royc01]

不隐藏文档的话，把属性表用作多维表的用户又有意见了，用文档作为属性存放载体还是有点“重”。

[zxhd863943427]

不考虑不行的，就比如移动文档这个操作，如果允许移动的话那这个特殊笔记本就没有必要了啊，用户手动管理即可。

自动化操作与手动操作是不一样的。从管理的角度来说，最后用户肯定会达成我希望官方自动化进行的效果：把数据库的文档放置到一个单独的笔记本中进行管理。
官方提供自动化是免去了用户的手工操作，而非剥离了用户的操作空间。

退一步来说，官方可以直接增加属性视图允许自定义新建路径，同时增加跨笔记本新建和增加当前属性视图名称作为模板变量，并把官方推荐的填为默认，我想用户自会做出决定了。

[leolee9086]

我觉得如果要隐藏文档就没必要专门针对属性视图，直接允许任何文档在文档树隐藏或显示，要么就干脆连属性视图的文档都不要隐藏，特例越多负担越重。

[88250]

@leolee9086 可以通过自定义属性 custom-hidden 控制的

[QMike0]

上面都是社区插件大佬们，我从普通用户角度也来插两句：

• 假如在数据库中新建一个新的块时，都会默认创建一个文档，这就会导致笔记库中的文档数目不断增大。从做笔记的角度来说，我希望自己笔记库中的文档都是有特定意义的，也就是根据特定的目的/主题进行创建，而不是为了数据库而随随便便弄出一堆新建文档，心理层面上压力较大，也不利于后期的笔记整理。另外，我 个人在使用数据库时，并不是所有新建的块都希望有对应的文档，有些是希望放在已有的文档里面的。思源本身就有内容块的概念，而且向数据库中添加块的时候，可以选择任意内容块，那为何不在新建块的时候，也体现出思源中块的优势呢？

个人推测，部分人要求数据库新建文档默认隐藏的理由之一，可能就是防止新建的文档污染笔记库吧

• 现在通过数据库新建的文档在文档树是默认隐藏的，我测试了一下，当从数据库删除新建文档所在行时，这个文档仍然处于思源的data文件夹中。这就导致用户对笔记的不可控，虽然明面上进行了删除，但笔记库中累积的这种新建但无用的文档越来越多，用户却意识不到，对自己笔记失去了掌控。这或许是个bug，但只要文档是隐藏的，我不免有这方面的担心，包括其他大佬提到的数据库转移后误删文档的问题
• 虽然用户确实可以通过定期/批量整理的方式，对新建的文档进行整理，但这种操作还是太繁琐了，不太符合正常用户的习惯，而且随着通过数据库新建的文档越来越多，这种整理的压力只会越来越大。另外，也应该考虑新用户的体验，他们是否有“创建块，然后再拖拽到表中，或者考虑定期整理子文档，将其移动到某个文档中”的意识呢，这样的操作逻辑其实也在增加思源上手的难度
  说了这么多，个人也就下面的观点：
  个人不建议数据库新建块时只能自动新建文档，不管这个新建的文档看得见（在文档树中看得见），还是看不见（自动隐藏）
  如下设想：

1. 数据库新建块时，不应默认创建新文档，至少提供给用户选择：新建文档or新建块。后者需要进一步构思，是将新建的块放在某个已有的笔记文档中，还是统一放在某一特定文档
2. 新建的文档应该在文档树中进行显示，或者在设置中提供给用户选项，选择默认显示/隐藏

思源的其他功能在设置中都有对应的设置区域，例如AI、闪卡之类的，个人感觉数据库也值得拥有自己的特定区域

3. 数据库新建文档时，应考虑给用户提供选项，要将新建的文档放在文档树的哪个位置，或者是已设定的默认位置。这个思路就和电脑上安装软件一样，是默认安装在C盘，还是自己选个位置安装
4. 在删除数据库的某一行后，应有相应提示，即是否删除对应的文档/块的本体。不过，这一条想法也可以不考虑

[88250]

@fenshen000 感谢建议，有几点说明一下：

• 文档块是所有块的基础载体，所以数据库中创建时只能创建文档块，创建其他类型的话没有地方存放
• 上一条决定了文档块的必要，不隐藏文档块可能更好
• 假设支持创建非文档块，那么这些块依然需要 append 到某个已有文档中，或者这个 issue 提议的一个笔记本中，这个粒度无法把握，无论如何取舍都会有问题，所以更通用的做法还是直接创建不隐藏的子文档吧

另外，如果数据库行不绑定块，类似 Notion 那样点击 Open 才创建可能是最优解，一方面解决了无故创建子文档的问题，一方面又能支持“轻量化表格”需求，看似很不错，是否可行我们还需要分析看看。

[LoneFireBlossom]

假如在数据库中新建一个新的块时，都会默认创建一个文档，这就会导致笔记库中的文档数目不断增大。从做笔记的角度来说，我希望自己笔记库中的文档都是有特定意义的，也就是根据特定的目的/主题进行创建，而不是为了数据库而随随便便弄出一堆新建文档，心理层面上压力较大，也不利于后期的笔记整理。

1. 做daily notes的话不需要管新建了多少文件，尤其是思源不像Obsidian那样允许双链指向一个未创建的页面，所以用传递型双链就必然产生一大堆空页面。
2. 整理应该用MOC，而不是文档树，也不需要管新建了多少文件（MOC - 管理链接而非本体）

[QMike0]

假如在数据库中新建一个新的块时，都会默认创建一个文档，这就会导致笔记库中的文档数目不断增大。从做笔记的角度来说，我希望自己笔记库中的文档都是有特定意义的，也就是根据特定的目的/主题进行创建，而不是为了数据库而随随便便弄出一堆新建文档，心理层面上压力较大，也不利于后期的笔记整理。

1. 做daily notes的话不需要管新建了多少文件，尤其是思源不像Obsidian那样允许双链指向一个未创建的页面，所以用传递型双链就必然产生一大堆空页面。
2. 整理应该用MOC，而不是文档树，也不需要管新建了多少文件（MOC - 管理链接而非本体）

每个人用法习惯不太一样
我个人不用dailynote流程，平时的想法在记录时会尽量按照类型进行归类，减轻后期整理的压力
目前我的笔记整理方法是文档树+MOC+标签的形式，文档树对我来说是必要的，而MOC是根据我在需要对某一主题进行汇总时才进行整理
而且可能是平时整理window文件夹习惯了，不愿意看到笔记库里面一堆不知名的空文件，乱糟糟的...

[LoneFireBlossom]

假如在数据库中新建一个新的块时，都会默认创建一个文档，这就会导致笔记库中的文档数目不断增大。从做笔记的角度来说，我希望自己笔记库中的文档都是有特定意义的，也就是根据特定的目的/主题进行创建，而不是为了数据库而随随便便弄出一堆新建文档，心理层面上压力较大，也不利于后期的笔记整理。

1. 做daily notes的话不需要管新建了多少文件，尤其是思源不像Obsidian那样允许双链指向一个未创建的页面，所以用传递型双链就必然产生一大堆空页面。
2. 整理应该用MOC，而不是文档树，也不需要管新建了多少文件（MOC - 管理链接而非本体）

每个人用法习惯不太一样 我个人不用dailynote流程，平时的想法在记录时会尽量按照类型进行归类，减轻后期整理的压力 目前我的笔记整理方法是文档树+MOC+标签的形式，文档树对我来说是必要的，而MOC是根据我在需要对某一主题进行汇总时才进行整理 而且可能是平时整理window文件夹习惯了，不愿意看到笔记库里面一堆不知名的空文件，乱糟糟的...

只能说怎么把文档树模式和dailynotes模式的人都照顾好就是开发者需要考虑的了。
我支持新建页面。

[LoneFireBlossom]

#9292 (comment)

属性需要区别对待，至少要区别内置属性和自定义属性的，

开发者肯定要区分，但应该在一栏中展示而不是查看自定义属性还需要再点击一次。
例如，如果用户不需要「别名」，那别名显示出来就纯粹是占位置的。

关于属性面板的设计是要保持统一，因为思源中所有块都可以添加属性，不只是文档块。

开发者惜字如金，我确实没看懂，所以我就只是复制粘贴一下之前写的

把属性放在右键菜单里太难用了。添加、删除、浏览都不方便。

• 非浮窗

  • 如果是一个页面块，那么在顶部展示所有属性，支持直接编辑、添加、删除属性。
  • 如果是其它块，那么聚焦这个块时在顶部展示所有属性，支持直接编辑、添加、删除属性。

• 浮窗

  • 在浮窗中是否展示属性由用户自己决定，在设置中弄一个开关选项。

• 文档属性显示在顶部还需要考虑，近期暂时不会安排

想知道是什么原因导致还需要考虑？

[LoneFireBlossom]

既然在这个主题里讨论那我粘贴一下我单独发的的issue链接：

#9292

[88250]

自定义属性对应的是扩展功能，内置属性对应内置功能。所以属性面板上需要有所区分，数据库也是类似，主要是考虑用途区分。

属性面板的易用性后期考虑改进，我们期待的是插件来完成各种扩展，相关接口目前基本都是具备的。

[88250]

关联目前亟待解决的问题：

• Database values no longer correspond to block attributes #9293
• New a row in the database no longer require to create a relevant doc #9294

[LoneFireBlossom]

自定义属性对应的是扩展功能，内置属性对应内置功能。所以属性面板上需要有所区分，数据库也是类似，主要是考虑用途区分。

属性面板的易用性后期考虑改进，我们期待的是插件来完成各种扩展，相关接口目前基本都是具备的。

区分可以用heptabase这种方式，而不是分成两栏要切换就得点击

然后还是之前说的gif

这样区分不就好了么。用户只要用过一次就知道哪些是内置的（思源总共就4个）。
这是obsidian里的步骤，开发者也可以试一下：

1. 点击add property

2. 这就是用户第一次添加属性遇到的下拉菜单，从此之后用户就知道要添加软件能认识的别名就用「aliases」：

如果用户看不懂「别名」是什么就去查操作指南。

我觉得这样做很方便很美观，开发者觉得这样做有什么坏处么

[88250]

暂时还没有时间分析，后面有空再考虑改吧，现在先解决能用，后面逐步提升体验吧。

[LoneFireBlossom]

属性面板的易用性后期考虑改进，我们期待的是插件来完成各种扩展，相关接口目前基本都是具备的。

这句话也没看懂，「插件完成各种扩展」是指「扩展属性面板的易用性」吗？这个面板不好看也能用插件改么。

算了，我不想管那个难看的的属性面板了。
在块上面显示属性（就是之前说的），允许用户在这里编辑/添加/删除属性就好了，长得和notion那样就很漂亮

[88250]

理论上讲应该是可以通过插件构建出各种所需要的属性呈现和编辑界面的，属性面板可以理解为软件标配，插件可以理解为选装，只是现在还没有选装提供……

[88250]

前面说过，标配也是有改进空间的，但是时间紧任务重，我们只能先解决能不能用的问题，好不好用的问题还需要时间。

[LoneFireBlossom]

你认为的自定义块属性：date、number、text等等 实际上的自定义块属性：用来标志这个块属不属于卡包、塞了一串指示任务到期时间的json、储存图标的base64

没有看懂，你说的这些这不是系统内置的属性吗？不是自定义的属性啊

[zxhd863943427]

你认为的自定义块属性：date、number、text等等 实际上的自定义块属性：用来标志这个块属不属于卡包、塞了一串指示任务到期时间的json、储存图标的base64

没有看懂，你说的这些这不是系统内置的属性吗？不是自定义的属性啊

大概更新了一下，刚刚确实写的不是很清楚

[LoneFireBlossom]

还是没看懂，自定义属性是这里这个，你说的那些都是系统内置的属性，确实应该那样处理，但跟自定义属性无关啊

[zxhd863943427]

如果你想看看插件到底会拿块属性做什么，我可以给你举个例子：

你当然可以说你是不会使用插件的，但是使用插件的用户也是客观存在的。

[zxhd863943427]

还是没看懂，自定义属性是这里这个，你说的那些都是系统内置的属性，确实应该那样处理，但跟自定义属性无关啊

对了，这些就是插件拿自定义属性干的事，而不是什么内置属性。

[QMike0]

这里面给出了部分自定义属性：https://docs.siyuan-note.club/zh-Hans/reference/block/attribute.html
另外部分插件会在自定义属性里面插入特定的词条

大佬们继续继续

[LoneFireBlossom]

对了，这些就是插件拿自定义属性干的事，而不是什么内置属性。

你这么说我懂了，我之前没想过插件可以给块写属性。我以为块的属性都是要用户自己定义，属于我理解不深所以表达的东西就不准确了。

我这样表述我的意思吧：

「内置属性」、「数据库属性」、「用户手动定义的属性」应该放在一栏中展示，也建议在页面上展示。#9272 (comment)
「插件使用的属性」则单独放在另一栏展示，并且在页面上不展示。

[zxhd863943427]

对了，这些就是插件拿自定义属性干的事，而不是什么内置属性。

你这么说我懂了，我之前没想过插件可以给块写属性。我以为块的属性都是要用户自己定义，属于我理解不深所以表达的东西就不准确了。

我这样表述我的意思吧：

「内置属性」、「数据库属性」、「用户手动定义的属性」应该放在一栏中展示，也建议在页面上展示。#9272 (comment) 「插件使用的属性」则单独放在另一栏展示，并且在页面上不展示。

你说的很好，但是该怎么区分呢？思源内部没有这种区分机制，他最多只能过滤掉他自己使用的自定义属性。而且不要把简单的事情复杂化，用户自定义属性，就用数据库的属性就好，自定义块属性，在设计上就是提供给插件和拓展功能的接口。

[LoneFireBlossom]

你说的很好，但是该怎么区分呢？思源内部没有这种区分机制，他最多只能过滤掉他自己使用的自定义属性。而且不要把简单的事情复杂化，用户自定义属性，就用数据库的属性就好，自定义块属性，在设计上就是提供给插件和拓展功能的接口。

我觉得你说的那样就可以区分了：用户自定义属性，就用数据库的属性就好
还是这个图，我改一下。

在「内置+数据库」栏的属性都要展示出来。在「自定义栏」的属性不展示。
用户只应在「内置+数据库」栏添加自己想要的属性，这里的属性都应能被数据库的表格直接展示。

[zxhd863943427]

用户如果拿它来自定义其他内容，实际上在属性视图出现后，已经是属于不务正业了，官方不会给予支持是很正常的。
自定义的块属性并不只表面上只是对这个块添加了一个属性，然后你可以右键查看它，除此之外，没有任何影响。他实际上会直接出现在整个页面的结构中，对于插件等第三方开发者是直接可见，会直接影响整个页面的稳定性，所以你甚至没法自定义中文的属性。
因此，在数据库属性出现后，已经完全不建议用户使用这个来自定义属性了。
以前使用，那是属于没得选的选择。

[zxhd863943427]

你说的很好，但是该怎么区分呢？思源内部没有这种区分机制，他最多只能过滤掉他自己使用的自定义属性。而且不要把简单的事情复杂化，用户自定义属性，就用数据库的属性就好，自定义块属性，在设计上就是提供给插件和拓展功能的接口。

我觉得你说的那样就可以区分了：用户自定义属性，就用数据库的属性就好 还是这个图，我改一下。

在「内置+数据库」栏的属性都要展示出来。在「自定义栏」的属性不展示。 用户只应在「内置+数据库」栏添加属性，这里的属性都应能被数据库的表格直接展示。

这个倒是可以，我觉得这也是之后努力的目标，思源的四个内置属性和数据库属性虽然有挺大的差异，但还是可以共处的。
不过现阶段显然还是先增加可用性为主，这个可能就得后期再说了。

[LoneFireBlossom]

前面说过，标配也是有改进空间的，但是时间紧任务重，我们只能先解决能不能用的问题，好不好用的问题还需要时间。

我的感想是，虽说思源是开箱即用比Ob装很多插件还好用，但是这段时间用下来各种细节上的体验很折磨我（看看我提了多少细节上的issue），感觉我提issue的时间跟我用ob按需求找插件的时间都有得比了，而且这种折磨很心累，ob找插件没那么心累。

确实应该先解决能用的问题，在优化细节上的体验，但后者也很重要。

[QMike0]

前面说过，标配也是有改进空间的，但是时间紧任务重，我们只能先解决能不能用的问题，好不好用的问题还需要时间。

我的感想是，虽说思源是开箱即用比Ob装很多插件还好用，但是这段时间用下来各种细节上的体验很折磨我（看看我提了多少细节上的issue），感觉我提issue的时间跟我用ob按需求找插件的时间都有得比了，而且这种折磨很心累，ob找插件没那么心累。

确实应该先解决能用的问题，在优化细节上的体验，但后者也很重要。

那为啥不直接用obsidian呢

（不懂，只是好奇问问）

[LoneFireBlossom]

前面说过，标配也是有改进空间的，但是时间紧任务重，我们只能先解决能不能用的问题，好不好用的问题还需要时间。

我的感想是，虽说思源是开箱即用比Ob装很多插件还好用，但是这段时间用下来各种细节上的体验很折磨我（看看我提了多少细节上的issue），感觉我提issue的时间跟我用ob按需求找插件的时间都有得比了，而且这种折磨很心累，ob找插件没那么心累。
确实应该先解决能用的问题，在优化细节上的体验，但后者也很重要。

那为啥不直接用obsidian呢

（不懂，只是好奇问问）

我确实很纠结。本来就是从ob来的，高强度用了几天撑不住了。
我打算继续用Ob了，等到块引用成为我的高频需求再考虑思源。

1. 块引用、反链面板拖动有当然好但没有也基本不影响（简单来说：笔记原子化、传递型双链写在frontmatter里、每条笔记用模板自动添加dataview代码列出所有传递过来的且正文未引用的卡片、善用笔记拆分split和合并merge功能）。

2. 思源最吸引我的是闪卡功能，因为我觉得Obsidian不可能实现内置闪卡，这点可以成为决定性因素。但是思源不支持用多种条件筛选卡片出来复习，按文档树复习不适合daily notes笔记法，用卡包的话每次制完卡都要手动添加太麻烦，相当于我还是用不了闪卡功能。等思源全面增强反链/搜索/闪卡/块嵌入的筛选功能，我想最快也得一年以后才能开始做（ 搜索面板应做得像反链面板那样 #9218 ）

3. 把ob笔记迁移到思源难度比反过来肯定简单很多。

另外，我把思源里的笔记导出为markdown后标签的井号中间出现了神秘符号「​#」「#​​」（复制这一段，然后把光标在这里左右移动看一下需要移动几次才能移出「」），导致我在Obsidian里设置标签时很麻烦，在Obsidian里还得全文搜索替换这个神秘符号。

[zxhd863943427]

前面说过，标配也是有改进空间的，但是时间紧任务重，我们只能先解决能不能用的问题，好不好用的问题还需要时间。

我的感想是，虽说思源是开箱即用比Ob装很多插件还好用，但是这段时间用下来各种细节上的体验很折磨我（看看我提了多少细节上的issue），感觉我提issue的时间跟我用ob按需求找插件的时间都有得比了，而且这种折磨很心累，ob找插件没那么心累。

确实应该先解决能用的问题，在优化细节上的体验，但后者也很重要。

作为一个思源用户，我很欢迎其他用户能代替我提出可行确切的优化建议，但也希望你能明白，良好的建议可以让所有用户受益，而比较差的提议只能让少部分的用户体验提高，让更多数人的体验下降。
因此，在提建议的时候，我希望你能意识到以下两个事实：

思源是一个独立软件，不是其他软件及其插件的复刻版、整合包。
思源是一个跨平台软件，不是任何平台的独占软件。

落实到具体的提建议上，这提供了两个准则：

要尽可能地分辨，什么是平台、软件实现的特色，什么是普适的改进方向？
要尽可能地分辨，什么是操作习惯导致的不适应，什么是大部分用户都会面临的困境？

当然，无论你是否能分辨清楚一个建议这几个方面的区别，你都可以提交你的建议。但也希望，不要在别人提出不同的意见，直接将他人的观点、操作习惯定义为“错误的”、“不合常理的”，这并不是解决问题的正确途径。

[LoneFireBlossom]

当然，无论你是否能分辨清楚一个建议这几个方面的区别，你都可以提交你的建议。但也希望，不要在别人提出不同的意见，直接将他人的观点、操作习惯定义为“错误的”、“不合常理的”，这并不是解决问题的正确途径。

如果你觉得我哪个issue提交的不满足这些准则，你就直接说，然后咱们去那个issue下面讨论。

[88250]

来来来，一首黄小琥的《没那么简单》送给大家：

https://music.163.com/#/song?id=419827620

没那麽简单 就能找到 聊得来的伴

尤其是在 看过了那麽多的背叛

总是不安 只好强悍

谁谋杀了我的浪漫

没那麽简单 就能去爱 别的全不看

变得实际 也许好也许坏各一半

不爱孤单 一久也习惯

不用担心谁 也不用被谁管

感觉快乐就忙东忙西

感觉累了就放空自己

别人说的话 随便听一听 自己做决定

不想拥有太多情绪

一杯红酒配电影

在周末晚上 关上了手机 舒服窝在沙发里

相爱没有那麽容易 每个人有他的脾气

过了爱做梦的年纪 轰轰烈烈不如平静

幸福没有那麽容易 才会特别让人着迷

什麽都不懂的年纪

曾经最掏心 所以最开心 曾经

没那麽简单 就能去爱 别的全不看

变得实际 也许好也许坏各一半

不爱孤单 一久也习惯

不用担心谁 也不用被谁管

感觉快乐就忙东忙西

感觉累了就放空自己

别人说的话 随便听一听 自己做决定

不想拥有太多情绪

一杯红酒配电影

在周末晚上 关上了手机 舒服窝在沙发里

相爱没有那麽容易 每个人有他的脾气

过了爱做梦的年纪 轰轰烈烈不如平静

幸福没有那麽容易 才会特别让人着迷

什麽都不懂的年纪

曾经最掏心 所以最开心 曾经

相爱没有那麽容易 每个人有他的脾气

过了爱做梦的年纪 轰轰烈烈不如平静

幸福没有那麽容易 才会特别让人着迷

什麽都不懂的年纪

曾经最掏心 所以最开心 曾经

想念最伤心 但却最动心 的记忆

[zxhd863943427]

当然，无论你是否能分辨清楚一个建议这几个方面的区别，你都可以提交你的建议。但也希望，不要在别人提出不同的意见，直接将他人的观点、操作习惯定义为“错误的”、“不合常理的”，这并不是解决问题的正确途径。

如果你觉得我哪个issue提交的不满足这些准则，你就直接说，然后咱们去那个issue下面讨论。

具体来说，你的提议大部分在我看来确实是很不错的，只有两个出于我个人的使用习惯和平台原因使我不太能接受。
#9290 ，这个是出于操作系统培养的习惯问题，在我日常使用的window和linux平台中，使用右上角关闭都是一个被训练得自然习惯的方式。直到群里有人提醒我之前，我都不知道mac是左上角关闭的。我同意在开发者有精力的情况下，应该把这个设置为可选项，但我不能同意把这个设置为对所有人的默认项。
#9292 ，这个我上文已有充足描述，简略概况下就是思源的自定义属性确实不等同于其他软件的属性，两者确实是不能使用相同的展示逻辑的。

你所论述的其他关于：创建新笔记本后自动对笔记本进行排序、搜索面板应做得像反链面板那样、PDF文本高亮可以重叠，重叠后可以全部选中等等，我觉得都是相当不错的，特别是搜索面板的改进，我希望能把标签的搜索改一改老久了……

[LoneFireBlossom]

#9272 (comment)

这个我上文已有充足描述，简略概况下就是思源的自定义属性确实不等同于其他软件的属性，两者确实是不能使用相同的展示逻辑的。

这个你说得很对，但并不是因为违反了你说的那几条准则，而是因为我不了解这个「自定义属性」的功能所以没有表达清楚我的目的……

上手使用思源不用装什么插件，这个地方写着「自定义属性」，软件说明文档里写这里由用户自己设置（见下），没想过插件的问题很正常。

在你没说之前，如果有人问我“插件怎么给块添加属性”，我会认为就是藏在.sy文档里，在软件里根本看不到。

## 自定义属性

自定义属性由用户通过 `块标菜单` - `属性` 进行设置，属性名仅允许使用英文字母和阿拉伯数字（例如 `doing`、`​ 7days`）。

设置后，思源会自动在属性名前加上前缀 `custom-`，以区分内置属性和自定义属性。

[QMike0]

来来来，一首黄小琥的《没那么简单》送给大家：

https://music.163.com/#/song?id=419827620

没那麽简单 就能找到 聊得来的伴

尤其是在 看过了那麽多的背叛

总是不安 只好强悍

谁谋杀了我的浪漫

没那麽简单 就能去爱 别的全不看

变得实际 也许好也许坏各一半

不爱孤单 一久也习惯

不用担心谁 也不用被谁管

感觉快乐就忙东忙西

感觉累了就放空自己

别人说的话 随便听一听 自己做决定

不想拥有太多情绪

一杯红酒配电影

在周末晚上 关上了手机 舒服窝在沙发里

相爱没有那麽容易 每个人有他的脾气

过了爱做梦的年纪 轰轰烈烈不如平静

幸福没有那麽容易 才会特别让人着迷

什麽都不懂的年纪

曾经最掏心 所以最开心 曾经

没那麽简单 就能去爱 别的全不看

变得实际 也许好也许坏各一半

不爱孤单 一久也习惯

不用担心谁 也不用被谁管

感觉快乐就忙东忙西

感觉累了就放空自己

别人说的话 随便听一听 自己做决定

不想拥有太多情绪

一杯红酒配电影

在周末晚上 关上了手机 舒服窝在沙发里

相爱没有那麽容易 每个人有他的脾气

过了爱做梦的年纪 轰轰烈烈不如平静

幸福没有那麽容易 才会特别让人着迷

什麽都不懂的年纪

曾经最掏心 所以最开心 曾经

相爱没有那麽容易 每个人有他的脾气

过了爱做梦的年纪 轰轰烈烈不如平静

幸福没有那麽容易 才会特别让人着迷

什麽都不懂的年纪

曾经最掏心 所以最开心 曾经

想念最伤心 但却最动心 的记忆

想听D大的翻唱版⌓‿⌓

[88250]

目前最新 dev 版已经对创建文档和块属性做了调整，欢迎大家测试反馈。

[zxhd863943427]

经过测试，非常符合我的使用习惯，我认为这是一个了不起的改进。

[UltramarineSky]

@88250 D大，数据库属性面板现在好像是按照创建顺序排序的，是否应按照属性视图中的顺序排序展示好些？或者允许属性面板中自定义排序

[88250]

@UltramarineSky 感谢反馈，关联 #9319

[88250]

我关闭 issue 了，感谢各位参与讨论 🙏