ShellIconOverlayIdentifiers - 为什么这么少？答案

【问题标题】：ShellIconOverlayIdentifiers - why so few?ShellIconOverlayIdentifiers - 为什么这么少？
【发布时间】：2011-05-23 14:50:21
【问题描述】：

至此，大家都知道ShellIconOverlayIdentifiers的数量是有限制的（来自MSDN）：

系统可以支持的不同图标覆盖处理程序的数量受到系统图像列表中图标覆盖可用空间量的限制。当前为图标叠加分配了 15 个插槽，其中一些是系统保留的。因此，只有在没有令人满意的替代方案时才应实施图标覆盖处理程序

我可以理解 Windows 95 中的 15 覆盖限制。但是在有千兆内存、大量核心和 GPU 的环境中，在现代操作系统中这样低的数字是否存在某些技术原因？

为什么这个值不可配置？

在给出“性能”答案之前，请考虑： Windows 允许进行配置，这样您就可以破坏性能......为什么要专门选择这个问题？

【问题讨论】：

为什么这个标签是“tortoisesvn”？我错过了什么吗？
我认为我很聪明，因为在处理图标过度限制时，tortoisesvn 是最常被提及的应用程序 - 主要是因为它占用了您的 9 个可用插槽。删除了标签。
Windows 10 上的限制仍然相同。也不知道为什么。

标签： windows icons windows-explorer windows-shell

【解决方案1】：

除非这里有人碰巧在 Windows Shell 团队工作，否则我怀疑您会得到一个真正解决技术限制以及它们如何影响设计选择的答案。但我会尝试...

我的猜测是没有任何技术限制，或者至少现在没有。 真正的原因大概是没有人花时间坐下来更新代码、设计和规范来解除这个限制。默认情况下没有实现功能，只是因为过去几年计算环境发生了变化，但这并不意味着有人坐下来重写 Windows 以充分利用所有这些变化。

您还应该考虑到这很可能是一种有意识的设计选择，而不是强加的限制。 Raymond Chen（实际上确实在 shell 团队工作）发表blog entry 回应有关 Windows 7 移除“共享之手”覆盖层的骚动。他提出了一个令人信服的论点，即图标覆盖实际上不是显示信息的理想方式（除了系统限制为 15 个这一事实之外）[强调补充]：

一般来说，叠加不是呈现信息的好方法 因为只能有一个叠加层每个图标，限制为 15 个每个 ImageList 的叠加层。 如果有两个或多个覆盖，适用于项目，那么一个会赢，另一个会赢将失去，此时的价值覆盖作为确定的一种方式哪些属性适用于项目减少，因为唯一的方法是确定缺少属性是当您根本看不到叠加层时。（如果你看到一些其他的覆盖，你不能告诉你是不是因为你的财产丢失或因为显示其他叠加层而不是你的。）

在我看来，在大多数实际情况下，添加到 shell 中的额外杂乱是不值得的。 Windows Shell 团队显然得出了同样的结论，并切断了“共享之手”的覆盖。雷蒙德的直接解释：

鉴于人们使用方式的变化计算机，共享信息是越来越默认状态。设置家庭组时，几乎一切都会共享。为了消除视觉上的混乱，信息已移至详细信息窗格。

而且，我知道您特别要求不要提及性能，但 Windows 确实尝试不让您自爆。用户需要 shell 的响应能力，并且覆盖图标可能会干扰这一点。作为进一步证明它们不是优先事项，another blog post 由同一位 Raymond Chen 批评：

另一个应用程序示例一种自私的表现观来了来自一家开发图标的公司覆盖处理程序。贝壳对待覆盖计算作为低优先级项目，因为它更重要的是获取屏幕上的图标，以便用户他们可以开始做任何事情想做的事。装饰品可以晚点来。这家公司想知道他们是否有办法提高他们的表现并获得它们甚至覆盖在屏幕上在图标出现之前，表现出惊人的自私 “性能”的解释。

【讨论】：

反应很好。所以也许更好的问题是“什么是图标覆盖的替代方案，它在文件/文件夹的状态上呈现相同的即时视觉队列？”在我看来，使用图标来做的不仅仅是识别内容类型正变得越来越重要，这正是 Raymond Chen 提到的原因——文件位置边界的模糊，状态很重要。
我非常怀疑这既不是有意识的设计选择，也不是强加的限制，而是很久以前（大约 Win 95）做出的一个愚蠢的设计决定，并且由于已安装的用户群而从未修复。最愚蠢的决定是每个覆盖扩展只能支持一个图标覆盖，并且对于每个文件，shell 只询问“应用？”。应该每个叠加层都支持一组图标，并且对于每个文件，shell 都会询问“哪个图标叠加层？”，扩展程序可能会回答“我不适用”作为一个选项.
有趣的是，从 Win10 开始，MS 通过使用 OneDrive crud 混淆我的 ShellIconOverlayIdentifiers 注册表项来接受这一点。对于使用 TortoiseSVN/GIT 之类的开发人员来说，这些叠加层至关重要，而且只能显示一个这一事实是 WHY 的原因。
在 Windows 10 破坏的所有事情中，@Alex，我的清单远远低于这一点。决定将 OneDrive 强加给用户显然是营销部门的决定，而不是外壳团队。没有人会花时间和金钱来回去改进 shell 图像列表以使其对用户友好。
这不是一个可接受的答案。我知道其中一部分来自 Microsoft 本身，因此，不接受是针对 Microsoft 的方法。看我的例子：我已经同步了 DropBox、Google Drive、Mega、OneDrive 和 Tortoise SVN 的文件夹，我真诚地希望在所有文件夹上正确地看到所有覆盖，但我不能因为这个愚蠢的限制。

【解决方案2】：

科迪对实际问题的出色回应。至于为什么是 15 而不是其他数字，限制是在 ImageList 控件本身中进行的。

【讨论】：

【解决方案3】：

这一切都非常好，正如 Cody Gray 所解释的那样，但坦率地说，这非常缺乏想象力，而且正如幕后报道的那样，听起来有点沮丧。

在 2015 年和 Windows 10 中，肯定可以而且需要有更好的能力，因为我注意到存在大约 30 个叠加层，并且必须优先考虑我最想看到的那些，这不是你希望大多数人担心的一点也不。我还看到像 Box 这样激进的供应商过度竞争，试图优先考虑自己，这永远不会有任何好处。

这是一种可能性：如果多重叠加图标有一个通用的叠加指示符会怎样；像 Google Chrome Apps 按钮一样的多种颜色的小矩形矩阵？单独叠加只会显示长列表中的叠加层。

然后，当鼠标指针遇到图标时，一个小的弹出窗口会收集所有图标变体以供查看（图标尺寸小或稍大）。当您将鼠标悬停时，每个叠加的图标都会通过工具提示依次宣布它是什么。

现在您可以获得所需的所有图标叠加层，用于各种云中的状态、存储库指示以及 Tortoise 工具等等。

【讨论】：

叠加层背后的想法是，您应该能够“一目了然”地识别被观察对象的状态。您的计划虽然有创意，但需要“手握键盘或鼠标”才能显示信息。并不是说我有更好的解决方案...
如果它们必须在弹出窗口中，为什么不将信息放在信息栏或预览窗格或 UI 中的其他位置？叠加图标的全部意义在于它们实际上是叠加的并且一目了然。

【解决方案4】：

我在此引用来自Why is there a limit of 15 shell icon overlays? Raymond Chen 2019 帖子的明确答案的摘录

值 15 来自图像列表的相应限制。这 ImageList_SetOverlayImage 函数最多支持 15 个图像列表每个图像列表的叠加层。（嘿，它曾经更糟糕。过去的限制只有 3 个！）

好的，但为什么只有 15 个？为什么不多呢？

叠加图像是使用的信息之一从图像列表中绘制图像。选项编码在 fStyle 参数，以及当位被划分为各种目的，四个位可用于指定覆盖图片。（你得到 15 个叠加图像而不是 16 个，因为你失去了一个的值，以指定“无叠加”。）

好的，但是fStyle参数中的值只使用了后16位位。高 16 位呢？那里有足够的空间。

16 位限制是从 16 位版本的通用控件（在 Windows 95 中仍需要支持）。的当然，如今，没有人关心通用的 16 位版本控件，那么为什么不开始使用高位呢？

有一个不能令人满意的解释：内部管理的代码 fStyle 在某些地方仍然使用 WORD，所以所有的代码管理 fStyle 将不得不进行修改。这发生在多个跨 Windows 的模块，因此必须进行同步更改跨多个组件。这是二进制文件的重大更改级别，因为接口不再兼容。打破更改在程序上难以协调：受影响的代码 shell 团队可能看不到他们，因为他们坐在远处的枝条还没有被RI'd到树干上。有可能将 fStyle 从 WORD 扩展为 DWORD 意义深远某些组件的后果。

就像我说的，这令人不满意。基本上它归结为“它工作量很大，而且我们很懒惰。”

【讨论】：