ShellIconOverlayIdentifiers - почему их так мало?

На данный момент все знают, что существует ограничение на количество ShellIconOverlayIdentifiers(из MSDN):

Количество различных обработчиков наложения значков, которые может поддерживать система, ограничено объемом пространства, доступным для наложений значков в списке системных образов. В настоящее время для наложения значков выделено пятнадцать слотов, некоторые из которых зарезервированы системой. По этой причине обработчики наложения значков следует внедрять только в том случае, если нет удовлетворительных альтернатив.

Я могу понять ограничение на 15 оверлеев в Windows 95. Но в среде, где есть гигабайты ОЗУ, многочисленные ядра и графические процессоры, есть ли какая-то техническая причина для такого низкого числа в современной операционной системе?

И почему это значение нельзя настроить?

Прежде чем дать ответ «производительность», подумайте: Windows позволяет такую ​​конфигурацию, что вы можете убить производительность ... зачем выбирать именно эту проблему?

Если кто-то здесь не работает в команде Windows Shell, я сомневаюсь, что вы получите ответ, который действительно касается технических ограничений и того, как они влияют на выбор дизайна. Но я попытаюсь...

Я предполагаю, что никаких технических ограничений нет или, по крайней мере, сейчас нет. Настоящая причина, по-видимому, в том, что никто никогда не удосужился обновить код, дизайн и спецификацию, чтобы снять это ограничение. Функции не реализованы по умолчанию, и то, что вычислительная среда изменилась за последние несколько лет, не означает, что кто-то сел и переписал Windows, чтобы в полной мере воспользоваться всеми этими изменениями.

Вы также должны учитывать, что это более чем сознательный выбор дизайна, а не навязанное ограничение. Рэймонд Чен (который на самом деле делает работу в команде оболочки) опубликовал запись в блоге отвечая на шум о Windows-извлекая на «совместное использование руки» накладку. Он приводит убедительный аргумент в пользу того, что наложение значков на самом деле не является желательным способом отображения информации (помимо того факта, что система ограничена 15) [курсив добавлен]:

Вообще говоря, наложения - не лучший способ представления информации, потому что для каждого значка может быть только одно наложение , и существует ограничение в 15 наложений на ImageList. Если к элементу применяются два или более оверлея, то одно будет выигрывать, а другие проигрывают, и в этот момент значение наложения как способа определения того, какие свойства применимы к элементу, уменьшается, поскольку единственный способ убедиться что свойство отсутствует - это когда вы вообще не видите оверлей. (Если вы видите какое-то другое наложение, вы не можете сказать, потому ли это, что ваше свойство отсутствует или потому, что другое наложение отображается вместо вашего.)

Мне кажется разумным, что лишний беспорядок, добавленный в оболочку, просто не стоит того в большинстве реальных случаев. Команда Windows Shell, очевидно, пришла к такому же выводу и отказалась от наложения «руки общего доступа». Прямое объяснение Раймонда:

Учитывая изменения в том, как люди используют компьютеры, обмен информацией становится все более и более нормальным. Когда вы настраиваете домашнюю группу, почти все будет доступно для общего доступа. Чтобы убрать визуальный беспорядок, информация была перемещена в область «Подробности».

И, я знаю, вы специально просили не упоминать о производительности, но Windows действительно пытается удержать вас от ранения себе в ногу. Пользователям требуется отзывчивость оболочки, и накладываемые значки могут этому помешать. В качестве дополнительного доказательства того, что они не являются приоритетом , другой пост в блоге того же Раймонда Чена наказывает:

Другой пример приложений, которые корыстно смотрят на производительность, был получен в компании, разрабатывающей обработчик наложения значков. Оболочка рассматривает вычисление наложения как элемент с низким приоритетом, поскольку важнее выводить значки на экран, чтобы пользователь мог начать делать все, что он хотел. Украшения могут появиться позже. Эта компания хотела знать, есть ли способ улучшить свою производительность и отобразить наложение на экране еще до появления значка, демонстрируя феноменально эгоистичное толкование понятия «производительность».

Отличный ответ Коди по практическим вопросам. Что касается того, почему 15, а не какое-то другое число, лимит встроен в сам элемент управления ImageList .

Все это очень хорошо, как объяснил Коди Грей, но, честно говоря, это довольно невообразимо и, как сообщалось за кулисами, звучит немного разочарованно.

В 2015 году и с Windows 10, безусловно, может и должна быть улучшенная возможность, поскольку я заметил около тридцати наложений и должен был расставить приоритеты, которые я хотел бы видеть больше всего, а это совсем не то, о чем вы хотите, чтобы большинство людей вообще беспокоились. Также я вижу, как агрессивные производители, такие как Box, чрезмерно конкурируют, пытаясь расставить приоритеты, и это никогда не пойдет ни к чему хорошему.

Вот возможность: что, если бы у нескольких наложенных значков был общий индикатор наложения; небольшая прямоугольная матрица из нескольких цветов, такая как кнопка Google Chrome Apps? При одинарном наложении просто отображается наложение из длинного списка.

Затем, когда указатель мыши встречается со значком, небольшое всплывающее окно собирает все варианты значков для просмотра (с маленьким размером значка или немного большим). Каждый наложенный значок, в свою очередь, объявляет всплывающей подсказкой при наведении курсора мыши.

Теперь у вас могут быть все необходимые наложения значков для состояния в различных облаках, для индикации репозитория, инструментов Tortoise и так далее.