更新后将设置与库名称集合到左下角，并且设置中无法关闭该功能，好难受，强迫症好难受……怎么会有这种更新啊！让我回到了被iphone资源库恶心的日子，只能使用系统的强制分类……强迫症不能没有自定义啊！
1 个赞
谢谢您的链接！我处于“简化期”，不想再为外观增加插件，选择了退版本……为什么更新要动这种根本设计！关键在于不给用户选择的权力，无法理解这个更新！他令我难受到一瞬间想放弃Obsidian，跟iphone资源库一样，更新后当天我就放弃了近四年的苹果生态……不能自己做选择，必须使用别人的审美，这一点令我难受得想死。
确实，很多人都感觉难受，如果不想用插件还可以用css隐藏掉，然后设置，帮助，仓库切换都可以通过命令打开，或用cmdr插件放到Ribbon处。
吓死我了，我以为1.6.5界面又改了，官方这个改动确实是个臭棋，建议改回去，或者可以自由选择
事实上，Obsidian的默认界面一直都是Obsidian团队的审美，也就是说一直都是别人的审美。而插件和CSS系统的存在就是为了让你可以选择自己的审美。
我这么说只是试着减小你为外观而增加插件的心理负担。
当然，退回旧版本，关闭自动更新，也不错。
我看到国外也在热议 
Please restore the location of the Settings and Help buttons - Feature requests - Obsidian Forum
确实，还有砍掉半透明也不可理喻
1 个赞
嗯，我理解您的意思，并且在论坛得到了很多想实现的效果上的帮助，我对所有“伟大的”（令我满意，觉得：牛比）的开发团队一向尊敬，没有开发者，就没有产品，我当然不会否定ob团队的审美，因为当我决定”以后就它了“的时候，我一定是认可的，并且现在我依然觉得满意。
产品能不断更新对我来讲是很棒的事情，我所困扰的是：上了一盘我们都认为可口的美食，在吃的过程中，你加了我忌口的佐料，这本来有更好的方法，分餐，给我一个选项，我可以不加。
香菜很微小，影响不了菜的整体，但不吃香菜的人会因为这一点点东西变得难受至极。
刚才回家前吃了一碗冰粉，这不正是Obsidian嘛，更新是添加山楂、折耳根、辣椒、芋圆、芝麻，花生，所有佐料我都要，独不要花生。在加佐料(更新)的时候，我可以选择不加花生，而不是只能加满全部佐料，再去想方法剔除花生，甚至像iphone资源库这种东西，完全无法去除，众口难调，关键在于能选择吃什么，不吃什么。
我觉得这么改还不错啊，感觉比之前好了，之前是库名是文件列表里面，看着还挺乱的，现在改到下面更清爽了 
楼主的这句话我还挺有感触的。其实就是顺序反了。
Obsidian 本体应该尽可能体积小、实现基础功能。任何优化性质的快捷输入、界面布局美化等，都应该留给插件和 CSS。
楼主提到“简化期”的概念，即减少安装插件，是一种很棒但很理想的状况。这表示开发团队需要的功能恰好和我们需要的功能重合，且没有我们觉得雷点的功能，这是非常难以做到的。
哪怕是 Obsidian 本体，这篇话题吐槽的文件列表，以及搜索、出链等软件核心功能，都依赖于软件的核心插件实现。
对于需求重合的人，这些核心插件在下载时默认打包到软件本体，可能是一丝便利，就像喜欢文件列表改动的人所感受到的一样。
但对于不喜欢其中一些功能的人来说，这些功能占用软件空间、不能像第三方插件一样卸载，导致 Obsidian 愈发臃肿。
Obsidian 只是一个很小的团队。具有优化性质的这些需要反复调试且个性化的功能，如果由开发团队承担，以目前效果来看，不够理想。
Obsidian 官方原则 (About - Obsidian) 也提到，他们希望这个软件是高度可定制和可扩展的，能够适应独特的需求。
所以我认为，合适的方向是，Obsidian 软件本体只作为运行插件的容器，优化结构、提供接口。如果官方有什么想自己实现的新功能，也可以写成插件，用户按需下载。
“软件本体只作为运行插件的容器”，这个观点并非我独创，而是我曾看到其他软件遵循类似理念，如 uTools。
诚然，uTools 是付费商业软件，而 Obsidian 要实现类似的功能，存在技术难点和源码泄露的安全隐患。因此，我依然理解 Obsidian 团队目前为止的很多选择。
作为用户，我们不负责理念的争端，只需要趁手的工具。我们不会也不可能对个别软件投入过多的热情。
站在解决问题的角度，如果目前的改动切实影响到了使用效率，且已切实有解决方案，我的建议是积极使用现有的解决方案。
当然，如同我希望官方的功能也是可卸载的，如果目前的改动虽有影响但还能接受，而现有的解决方案又不符合自身需求，保持现状、等待变化亦是一种选择。
1 个赞
Obsidian并不是开源的
Here the problem is also what you mean by “being open source”.
Is obsidian code released with an open source license (MIT, GPL, etc) ? No.Is a (minified/obfuscated/packed) version of the code available within electron? Yes.
用户可以看到Obsidian的一些代码，但是不能使用它们。如果在 github 上发布源代码并打算将其作为开源产品使用，Obisidian 团队有权提起诉讼。
原来如此，是一个法律意义上的定义问题，感谢提醒！我这么说确实会误导他人，造成法律风险。我修改一下。
认可，没有“雷点，即只有同，没有异，这是不可能也不合客观规律的，就像现在这个改动一样，千人千面，无论喜欢与讨厌的理由是什么，总归是两种状态：我用，我不用。
正如您所说，将尽可能多的改动留给插件与CSS，我也是这个观点：用插件与CSS做添加，而不是用它们做（功能上的）减少，
1.6这个改动是不可选的，如果它是一个类似”显示页面标题“，或者说使用暗模式or光模式的功能，我相信大家都会夸赞这个改动，因为喜欢它的人多了新功能，不喜欢的人可以不用。
谢谢回复。总体来说，我们都希望软件本体简化、通过插件（官方的或第三方的）和 CSS 自定义功能。
我的想法稍有不同。我不希望优化性质的功能默认打包到软件本体，即使可以关掉，它也要占内存空间。
如果 Obsidian 软件本体只作为运行插件的容器，核心插件和第三方插件一样能卸载，开发者可以更轻松地按照自己的喜好开发新插件，用户也不用总是下载大号安装包。
按照这个思路，旧版的文件列表可以是官方原先开发的插件，1.6 的改动是官方的新插件或补充包，想要旧版的就用旧插件，新版的就用新插件或安装补充包，皆大欢喜。
当然，目前这样的方法没有例子参考，所以很多人可能会用第三方插件现在的情况来想象核心插件也可以卸载的情况。由于 Obsidian 是本地存储，现在的第三方插件在某些情形下存在同步和迁移上的麻烦。但核心插件有官方优化，不一定要和第三方插件采取同样的方式，所以具体实施方法还有商议的空间。
我同意 @PlayerMiller 的观点，插件话开发思想，保持核心功能最小化。
但这个核心应尽可能的稳定，减少不必要的修改和向下兼容性。
我想吐槽的是，obsidian从1.5到1.6的升级确实导致一些插件失效或出现问题，至少这次向下兼容性不太好，我接触时是1.58，之前的升级不太清楚，但1.6升级确实带来了一些问题，包括主要样式等，与之前不同，导致某些插件样式出现了问题，用之前的样式覆盖就行了。但不可能用老版本样式覆盖，只能对比样式，找出差异，因为不是一处问题，且是别人的插件，不太熟，所以感觉很头疼。
我相信很多插件开发者都是业余开发的，如果频繁升级会导致问题，一方面开发者没有那么多精力修改，二是会使开发者失去信心和动力，对生态发展不利。
我也是这个看法啦，仅针对本次更新作假设：它若是一个跟显示标题栏一样的开关型改动，就不会有这么多的”讨厌“。
如果技术能实现的话，我也希望是Obsidian保持为最轻量的基础本体，一切变动以插件css形式实现，类似？BRAT
假设现有一个官方插件Wing——或者由它替代【核心插件】，在这里可以得到所有官方的功能与变动（官方团队是最核心并且专业的插件制作者，为什么不采用与第三方插件类似的嵌入形式呢，如果技术能实现的话），以与【第三方插件】作区分，我想使用某个功能，就在【wing】中下载并开启。
ob优秀的地方，就在于它可以做加减法，每个用户的ob都可以尽量符合的自己需求，如果官方的变更是固定不可选择的，或者为了取消某个功能，需要用户添加另外的功能，这会变得越来越臃肿，夸张的来讲，这不会成为一个半开放的印象笔记吗？它有多臃肿想必许多转战ob的朋友都了解。
固，我的看法同样是：
1. 保持ob的简洁本体——ob团队是创作者
2. 以一个类似【第三方插件】与【BRAT】界面的形式进行官方变动，让用户自己做加减法——ob团队是可靠的插件制作者