Говоря в общем, моя философия по данному вопросу такова. Уважая свободу других, я также  свободен. Поэтому на гипотетической площадке высказывается идея, затем желающий её реализовать программист обозначает цену, затем автор идеи сам, если ему это позволяют финансы, проплачивет. Здесь есть нюанс: если модифицируемая программа не поддерживает плагинов, то автор идеи вынужден пользоваться текущей модифицированной версией до тех пор пока она либо перестанет работать в новых версиях ОС, либо вновь обращаться к программисту за написанием обновления. В случае большого объема работ (высокой цены),  автор идеи ждёт, найдутся ли те кому нужно то же самое и готовых платить. Никаких согласований, ибо так проще.    

> За написание не бьют, более того, если какой-то фич нужен - пишите.
>> Автоматизация не помешала бы.
> Именно показа бандвиза? Не видел готового решения. А вообще народ довольно много
> всякой автоматизации понагородил через командлайновые морды и RPC - потенциально оно
> довольно дружественно к автоматизации.
>>> чего такого полезного дает рассматривание этого bitfield'а глазами?
> По крайней мере, я не только качаю что мне надо но и
> сам несколько раздач успешно с нуля провел. Даже в случаях отказов
> трекеров и прочая.

Вот здесь Вас не понял. Речь шла только о визуализации загружаемых частей в виде графика.

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

У меня одновременно в загрузке не более 2-х раздач разрешено (канал слабый), и если маленький или просто заинтересовавший  файл 3-ий в очереди, ждать долго - ставлю его 1-ым.

Надо будет глянуть последнюю версию, а то устанавливал из оф. репозитория не самую новую — спасибо, что подсказали.

> чувствительно если врубить полную преаллокацию файлов - UI или вебморда подмерзают
> на время операции.

Это, конечно, желательно исправлять.

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

Включил эту опцию, выключил монитор, продолжил собираться и ушёл, выключив уже только акустику. :) нечасто используется, некритично, но приятно, что есть такая возможность.

>> Адресная строка Bread Crumb Mode
> предпочитаю эдитабельную строку.

Согласен в случае файлового менеджера, но в диалогах открытия файлов Bread Crumb Mode более эргономичное решение —  программы ведь запоминают последний путь, а каким он будет в следующий раз неизвестно, при том, что навигация быстрей в этом режиме.

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

Приятно встретить единомышленника.

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

Ответ в начале этого поста

> 4) Фичи имеют свойство кушать ресурсы и тормозить работу программы.

Эх, если б всё писали на Ассемблере, то на современном железе это всё летало бы как разведчик МиГ-25Р на трёх махах. Мечты, мечты.

> 5) Чем больше в программе кода - тем больше в программе багов,
> глюков и просто уязвимостей. Тем сложнее ее отладить до стабильного юзабельного
> состояния.

Согласен, но не Dragon Playerом же теперь пользоваться.

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

По этому пункту мы с Вами солидарны

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

Как насчёт полноэкранного режима + всплывающая панель с элементами управления?