> Их философия понятна, поэтому писать им не буду

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

>> Но это вариант для неленивых :)
> Автоматизация не помешала бы.

Именно показа бандвиза? Не видел готового решения. А вообще народ довольно много всякой автоматизации понагородил через командлайновые морды и RPC - потенциально оно довольно дружественно к автоматизации.

>> чего такого полезного дает рассматривание этого bitfield'а глазами?
> Согласен, что опция некритичная, но… и об этом тоже чуть позже.

По крайней мере, я не только качаю что мне надо но и сам несколько раздач успешно с нуля провел. Даже в случаях отказов трекеров и прочая.

>> Очереди Правда я не совсем понимаю зачем они нужны …
> Нужны, если добавляется что-то небольшого размера, а выше в очереди огромные по
> размеру файлы или, например, что-то сильно заинтересовавшее.

Если нечто небольшого размера - оно и так скачается быстро. Хотя лично я в этом случае могу ему помочь поставив приоритет в high. Единственный разумный юзеж очередей видится разве что для тех кто качает 50 больших файлов за раз и боится что диск зафрагментируется окончательно или хочет первые несколько файлов в ущерб остальным. В какой-то из последних версий очереди сделали - гляньте, это то чего вы хотели? Я в очередях не очень разбираюсь, мои сценарии использования их не требуют а в кторенте у меня от них только гемор по снятию с паузы был :)

>> На самом деле у трансмиссии есть более противный недостаток :P.
> Какой?

Некоторое тяжелое I/O не делается в данный момент асинхронно/отдельным тредом. Наиболее чувствительно если врубить полную преаллокацию файлов - UI или вебморда подмерзают на время операции. Там у них есть баги на этот счет, но починка этого требует довольно много изменений как я понимаю. Пока никто не сподвигся.

> а индикация задействования этого режима присутствует в Clementine (может, есть и в
> некоторых других) и это удачное решение.

Честно говоря, лично этой опцией не пользуюсь. С точки зрения [моих] юзкейсов я не понимаю зачем это надо. Если мне надо стопнуть плеер, он должен немедленно заткнуться ASAP. А если не надо - так пусть себе играет. Можете мне объяснить какой практический смысл существования такой опции и как это применяется на практике?

> Адресная строка Bread Crumb Mode — ещё один пример удачного решения.

Оно удачное только если позволяет вводить адрес методом копипасты. Иначе это может доставить уйму неприятных моментов. По этой причине я обычно предпочитаю эдитабельную строку. Откусить кусок от строки и нажать энтер - не особая проблема, хоть и чуть дольше чем ткнуть в середину. Зато копипаст пути заведомо работает. И на copy и на paste, сильно ускоряя некоторые операции.

> Режим перехода по документу в Okular (полоса прокрутки доступная по щелчку по
> номеру страницы на нижней панели). Таких примеров можно привести множество.

Okular вообще симпатичная программа, имхо - эталонный образец вьюшки документов и как ее надо делать. Одна из немногих программ KDE которые мне откровенно нравятся. К сожалению, в данный момент я довольствуюсь более простым evince у которого есть пара бестолковостей, т.к. переть все и вся из кедов в XFCEшную систему ради пары программ явно оверкилл (у кедов все как-то довольно плохо с модуляризацией).

> А насколько превосходными бы были программы, воплощающие все доступные для данного типа
> программ удачные решения?!

В этом плане у меня есть некоторые мысли:
1) Не все обязаны считать фичу супернужной. Ну вот например для меня остановка после ... в плеере - всего лишь кусок dead code. Зачем он мне? А прога утяжелится.
2) Не все обязаны считать фичу однозначно удачной. Иногда получается откровенное деление на остроконечников и тупоконечников в соотнощении 50/50 и начинается войнушка.
3) Если в программе много фич, интерфейс может получиться перегруженным и сложным в освоении. Аналогично и насчет настроек. Все хорошо в меру.
4) Фичи имеют свойство кушать ресурсы и тормозить работу программы. Тормозные ресурсожоркие программы мало кому по вкусу.
5) Чем больше в программе кода - тем больше в программе багов, глюков и просто уязвимостей. Тем сложнее ее отладить до стабильного юзабельного состояния.

[...]
> программистов, которые бы взялись дополнить один из уже существующих в данном
> классе (под классом подразумеваю, например, музыкальные проигрыватели) проектов такими
> решениями.
> Где-то это будут дополнения, где-то изменения будут вноситься в код самой программы.

Идея сама по себе довольно здравая, имхо. Но во первых см. выше. Во вторых, создать фичу еще недостаточно. Надо или в апстрим ее пропихать (а они там могут быть иного мнения), или ... или вам придется майнтайнить это своими силами (а это затратно по ресурсам а значит и деньгам).

> Как уважаемый читатель воспринимает такое предложение?
> Если положительно, то нужно выбрать площадку для публикации и обсуждения.

Читатель думает что в принципе могла бы существовать площадка, где пользователи предлагают фичи и выставляют вознаграждение за реализацию (с возможностью для каждого посетителя добавить свои эн тугриков), а желающие реализовать "срубают банк" реализовав фичу. При этом оно бы самобалансировалось - если фича злободневная и нужна куче народа, то накидают много денег и будет стимул учесть пожелания юзеров. А иначе ее если и реализуют то разве что для души. Но о существовании таких площадок мне ничего не известно. Потенциально какой-нибудь талантливый вебпрограммер мог бы наверное тут увидеть интересную идею. Правда геморную в реализации, как все что свзязано с деньгами (арбитраж и прочее-сплошная попаболь).

> P.S. Как считаете, если в Okular эта полоса отрисовывалась бы сразу (без
> необходимости её вызова) на нижней панели, было б удобнее?

Я считаю что в общем случае мне не хочется чтобы место на экране которое мне нужно под документ тратилось бы на что-то еще. Скажем технические даташиты зачастую подразумевают просмотр весьма немелкой сущности (например крупной схемы). И при масштабе 100% оно на монитор влезает со скрипом. Поэтому зачастую под область просмотра должна быть отдана максимально возможная площадь экрана, IMHO.