Total Commander

Переделаем ТК в Миранду

VadiMGP писал(а):А если без шуток, то такая проблема может возникнуть (по крайней мере, при сегодняшнем API), только если плагин явно сообщит ТС, что он (плагин) поддерживает переименование своих собственных элементов.

То есть, ты предлагаешь пользователю играть в загадки-отгадки: а что же сейчас выкинет этот конкретный плагин при попытке переименовать ссылку на файл - переименует ссылку или, никого не спрося, сразу полезет в файловую систему, грохать имена оригинальных файлов, так что ли? Извини, но это идёт вразрез со всеми моими привычками и ожиданиями. Я в самую первую очередь ожидаю, что переименуется то, что я вижу на экране. И уж только потом, возможно, выполнятся дополнительные действия, вытекающие из специфики плагина. Просмотр и редактирование, на которые ты так упирал чуть ранее, этому совершенно не противоречат, т.к. ссылки на файлы при этих операциях идентичны самим файлам. С переименованием (и копированием) всё совсем не так. Грубо говоря: ты пытаешься в винде переименовать ярлык (LNK-файл), а вместо этого винда тебе берёт и переименовывает файл, на который этот ярлык ссылается. Причём не предупредив.

VadiMGP писал(а):Да, господи, у самого ТС те же проблемы например на ФТП панели. Файл, вроде бы, тут в панели есть, а на самом деле этого суслика уже может и не быть.

Речь совершенно не об этом. Пользователь переименовывает только что найденный файл, буквально тем же самым инструментом, которым этот файл нашёл - и всё, файл более для него невидим. Представь, что ты в обычном режиме в Тотале переименовал файл, а панель не обновляется, причём для её обновления надо запустить мега-переиндексацию часика на полтора. Долго бы ты оставался на таком файл-менеджере? Я к тому, что раз уж пользователь явно вызывает переименование, и плагин знает, что пользователь его вызывает, пусть плагин это дело корректно отработает, всё учтёт и пересчитает. А для этого необходимо, чтобы соответствующая функция плагина была вызвана Тоталом. А именно это сейчас и происходит, и именно это ты хочешь убрать. Как-то нелогично...

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

Именно это я говорил с самого начала.

VadiMGP писал(а):Почему? Я не понял.
А сегодня, при копировании из панели результатов поиска сохраняется структура? тогда в чем разница? Панель поиска - тоже в определенном смысле виртуальная панель.

При чём тут копирование из панели результатов поиска? Не все плагины типа "временная панель" поисковые. То есть я вообще просто пример привёл, какие трудности МОГУТ поджидать.
Да и копируются сейчас файлы как при режиме Ctrl+B, а не как при распаковке с учётом путей (т.е. оставляя реализацию функции копирования на вас, Гислер даёт вам больше свободы - сейчас ведь нет возможности копировать со структурой). Да и если вдруг найдены по поисковому запросу папка Folder и файл Folder\file, то если ты сначала удалишь Folder из панели результатов поиска, а потом (или если Folder и File будут в удаляемом выделении) попытаешься удалить File, вылезет ошибка.

VadiMGP писал(а):А вот тут совсем не понял. Объясни, пожалуйста. И опять-таки в чем принципиальная разница работы с виртуальной панелью и с сегодняшней панелью результатов поиска? Я и без плагина сегодня могу сделать такой поиск, чтобы нашлись и файлы и папки.

Разница в том, что в панели с результатом поиска файлы отображаются с полным путём в подробном режиме, и в том, что панель с результатами поиска не обновляется так, как обычная, а панели с wfx плагинами обычно обновляются (ну плюс ещё копировать пути плохо выходит в одном случае). Т.е. выхода два: либо Гислер дорабатывает до приемлемого состояния панель поиска результатов и делает так, чтобы панель плагинов типа "временная панель" отличалась отпанели поиска результатов только именами файлов (в одном случае их генерирует плагин, в другом - тотал), либо панель для обоих типов wfx-плагинов остаётся общей, но Гислер изменяет API так, чтобы плагины могли делать только часть действий, оставляя остальное на тотал.

То есть, ты предлагаешь пользователю играть в загадки-отгадки:

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

Просмотр и редактирование, на которые ты так упирал чуть ранее, этому совершенно не противоречат, т.к. ссылки на файлы при этих операциях идентичны самим файлам.

По второму кругу... Не идентичны - я показывал в чем именно. Могу снова привести эти строки, можем побайтно сравнить. А насчет "не противоречат" я не понял, что ты имеешь в виду. Что чему не противоречит?

Грубо говоря: ты пытаешься в винде переименовать ярлык (LNK-файл), а вместо этого...

Я так и знал, что возникнет такая аналогия. На мой взгляд, она неприменима в данном случае. Дело в том, что .LNK файл в винде явно декларирован как объект отличный от файла. Он живет своей жизнью. В случае же виртуальных панелей юзер ни сном ни духом не знает о существовании каких-то там ссылок. Эти ссылки являются лишь техническим приемом, внутренним соглашением между ТС и плагином, для показа юзеру настоящих файлов. Разумеется, ты можешь написать, например, плагин-менеджер шорткатов на файлы (хотя мне кажется что при существующем API такой полноценный плагин невозможен, но допустим). Юзер будет их создавать, удалять, редактировать, просматривать. Но тогда это уже будет твоя забота, какие средства дать юзеру, чтобы он смог недвусмысленно указать над каким объектом он хочет выполнить операцию. А за что всем остальным отдуваться?

А что касается того, долго ли я бы сидел на таком менеджере - так и гадать не надо. Я на нем и сижу. По-моему, с версии 2.11. И наблюдал несуразности неоднократно. И прощаю ему и это и кучу других недостатков. И пока их совокупный объем не превысит критическую массу, так и буду сидеть. А что, ты в ТС не видишь недостатков? Он идеален?

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

Ты изящно пропустил один этап - юзер вызывает ТС, а уже ТС вызывает для переименования плагин. Мне страшно интересно, почему это плагин должен выполнять работу ТС? Можно получить простое объяснение? А сейчас юзер просит ТС переименовать файл, а ТС перепихивает файловую работу на плагин.

Не, ну правда, без подковырок, я хочу понять - зачем каждому плагинописателю надо сидеть и писать заново все те функции, которые в ТС уже готовы. В конце концов, почему бы не дать тем же плагинам интерфейс для вызова файловых функций ТС? Хотя бы в самом простом виде, вроде того, как сделан запуск файлов на исполнение? Если ТС вызывает плагин для запуска exe файла, плагин может вернуть ТС спец. код возврата, чтобы ТС сам его запустил (EXEC_YOUSELF). Почему бы не вернуть (RENAME_YOURSELF) для переименования или COPY_YOURSELF для копирования? Гибкость будет несусветная А все остальное (пересчет, корректировку, в общем все что надо) плагин с удовольствием сделает сам. Кому будет плохо от такого подхода? А еще лучше - дать возможность вызова этих функций, чтобы плагин тут же не отходя от кассы и узнал, чем операция закончилась и юзеру результат в лучшем виде отобразил? И тогда каждый при своем деле и все довольны. Чем плохо, кроме того, что хорошо?

Именно это я говорил с самого начала.

Ну так и я говорил, пока язык не отсох. А что толку? Это был так, глас вопиющего...

Да и копируются сейчас файлы как при режиме Ctrl+B,

Да я про панель поиска спросил не потому что она от "поиска" а именно потому что на режим Ctrl+B похожа. Вот ты и ответил. Спасибо.

оставляя реализацию функции копирования на вас, Гислер даёт вам больше свободы - сейчас ведь нет возможности копировать со структурой)

Ты ошибаешься, никакой свободы нету. Все что касается структуры решает единолично ТС. Он только вызывает плагин для копирования одиночного файла.

если ты сначала удалишь Folder из панели результатов поиска, а потом попытаешься удалить File, вылезет ошибка.

Почему обязательно ошибка? Я же написал - ситуация совершенно штатная, прекрасно обрабатывается уже сегодня. ТС в такой ситуации не дает никакой ошибки. Не вижу в чем проблема.

Такое впечатление, что мы говорим о разных вещах... На всякий случай ещё раз уточню: я не против внесения дополнений в существующий API, позволяющего добавить новые классы FS-плагинов. Я против лишь изменения существующего API временных панелей, из-за которого бы произошло полное отождествление файлов со ссылками на эти файлы.

Теперь по пунктам.

VadiMGP писал(а):Я хочу, чтобы в ситуации, когда юзер выразил желание переименовать файл, ТС переименовал его. Чего проще-то?

Проще-то некуда. Осталось всего лишь отличить две ситуации: когда юзер выразил желание переименовать файл и когда он выразил желание переименовать ссылку на него.

VadiMGP писал(а):Что чему не противоречит?

Не противоречат моим словам. Иначе говоря, просмотр - это неудачный пример. Если я на файле-ссылке жму F3, то вряд ли это означает, что я хочу просмотреть какие-то внутренние структуры плагина, обеспечивающие привязку ссылки к файлу. Просмотр всегда должен выполняться только с оригинальным файлом. Но если я жму Shift+F6, то тут ещё бабка надвое сказала, чего мне хочется - переименовать ссылку или оригинальный файл.

VadiMGP писал(а):В случае же виртуальных панелей юзер ни сном ни духом не знает о существовании каких-то там ссылок.

Здрасьте! Как же тогда юзер может, скажем, удалять файлы-ссылки, если они у него на 100% отождествлены с оригинальными файлами? В том-то и дело, что полного отождествления нет и быть не может!
И ещё один момент: если у тебя всё полностью отождествлено, то как же бедному пользователю создать две ссылки, лежащие друг с другом, на одноимённые файлы (лежащие, понятное дело, в разных каталогах)? С одним именем создать нельзя, попробуешь переименовать - переименуется оригинальный файл, а оно мне надо?

VadiMGP писал(а):Но тогда это уже будет твоя забота, какие средства дать юзеру, чтобы он смог недвусмысленно указать над каким объектом он хочет выполнить операцию.

Понимаешь, в том варианте, который ты предлагаешь, у меня попросту не будет возможности такую заботу проявить! Вот в чём дело-то. Если Тотал сам будет просматривать, редактировать, переименовывать, удалять файлы, то плагин тут уже и не нужен.

VadiMGP писал(а):А что, ты в ТС не видишь недостатков? Он идеален?

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

VadiMGP писал(а):Мне страшно интересно, почему это плагин должен выполнять работу ТС? Можно получить простое объяснение? А сейчас юзер просит ТС переименовать файл, а ТС перепихивает файловую работу на плагин.

Временная панель - это не отождествление с реальным диском, иначе и плагин-то был бы не нужен. Интерфейс временной панели лишь облегчает некоторые задачи FS-плагину по сравнению со стандартным API, не больше и не меньше. В эти "некоторые задачи" переименование не входит и входить не может по вышеописанным причинам. Опять же, напомню, я говорю о существующем API, а не о гипотетическом, который хорошо было бы создать - об этом гипотетическом я не спорю и спорить не буду. Существующий интерфейс временной панели обязан предоставлять пользователю возможность переименования файлов-ссылок.

VadiMGP писал(а):Не, ну правда, без подковырок, я хочу понять - зачем каждому плагинописателю надо сидеть и писать заново все те функции, которые в ТС уже готовы.

Ни малейших возражений не имею, но только в случае расширения существующего API и добавлении новых классов плагинов.

VadiMGP писал(а):В конце концов, почему бы не дать тем же плагинам интерфейс для вызова файловых функций ТС?

На 100% поддерживаю: это и есть по сути расширение API.

Такое впечатление, что мы говорим о разных вещах...

Видимо, да, это частично был спор о разных вещах. Теперь, кажется, стало проясняться.

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

Мамочки мои, держите меня семеро! ТАК ВЕДЬ И Я ЗА ТО ЖЕ! Я тоже за расширение API и тоже не требую изменеия существующего. Где я предлагал поменять API? Существующего API вполне достаточно, чтобы каждый занимался своим делом, плагин - хранит ссылки, ТС - выполняет файловые операции.

Кстати, размышление в сторону... А для каких таких целей Гислером было потребовано thread-safety для FsGetLocalName? Я могу придумать толко одно применеие - он, таки, да собирался делать переименование и копирование, причем в фоне. Для чего еще в отдельном потоке может потребоваться реальный файл. Контентные плагины не катят, потому что это FS. Есть другие идеи?

Но вернемся к нашим баранам. Поскольку я не предлагаю ничего изменять в существующием API, то, получается, что мы зря спорили. Тогда можно вернуться к тому с чего все началось и я хочу спросить - почему ты "категорически возражал" против того, чтобы ТС переименовал файл? Потому что, возможно, ты хочешь переименовать ссылку? Тогда почему ты не возражаеншь против того что на F4 ТС запускает редактор файла а не ссылки. А может я хочу ссылку отредактировать? И утверждение, что "вряд ли я хочу по F3 посмотреть ссылку" тоже сомнительно - плагин LinkInfo тому яркий пример.

А вообще, пришла мне в голову такая мыслЯ - сделать в следующей версии FSE возможность подключать функции CopyFile и MoveOrRenameFile из внешней DLL. Кому надо - пусть пишет для себя. А может быть появятся желающие написать это для всех. Пусть без всех наворотов ТС, но хотя бы, джентльменский минимум - нормальный диалог в случае если такой файл уже есть, да еще рид-онли, поддержка descript.ion... О комментах, скорее всего, мечтать не приходится. Какова вероятность, что такое будет написано?

А может кто-то знает что-то подобное, но уже готовое?

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

Когда он сказал мне копировать файлы самому, то я подумал, что, как временная мера - почему бы и нет? Гислер сейчас жутко занят, чего попусту ему на мозги капать? Потом, когда-нибудь он доделает API, а я пока поставлю, что-то простенькое. И в две минуты сбацал функцию копирования.

Но тут меня поджидал хищный зверь облом. Я наткнулся на следующий эффект - я попытался скопировать файл из панели FSE в панель CD-Burner. У меня глаза на лоб вылезли, когда я увидел, что ТС потребовал от FSE скопировать в о временную директорию полтора гига. Вместо того, чтобы запихнуть в бурнер ссылку на существующий файл. Аналогично с упаковкой. На хрена ТС потребовал от меня перед упаковкой файлов скопировать кучу мег в темп и на хрена он стал подсовывать архиватору файлы из темпа??? И на хрена мне в архиве файлы с путями из темпа??? К тому же, ясно, что время архивирования подпрыгнуло до Луны.

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

Все, выплеснул. Ежели, кого забрызгал, извините, не со зла.

VadiMGP писал(а):Тогда почему ты не возражаеншь против того что на F4 ТС запускает редактор файла а не ссылки. А может я хочу ссылку отредактировать?

Alt+Enter - наиболее разумный для этого путь.

VadiMGP писал(а):И утверждение, что "вряд ли я хочу по F3 посмотреть ссылку" тоже сомнительно - плагин LinkInfo тому яркий пример.

LinkInfo служит для реальных LNK-файлов, формат которых задан системой, и которые спокойно могут существовать и без Тотала. В плагине же, который отображает какие-то свои личные, сугубо плагиновские псевдо-файлы, просмотр и редактирование самой ссылки не имеет большого смысла. Если нужно - как указано выше, Alt+Enter, потому как это не есть типичная операция. Если же неимоверно хочется, чтобы F3 и F4 работали именно со ссылкой (например, логика плагина этого требует), то тогда попросту нет смысла реализовывать интерфейс временной панели.

VadiMGP писал(а):когда я увидел, что ТС потребовал от FSE скопировать в о временную директорию полтора гига. Вместо того, чтобы запихнуть в бурнер ссылку на существующий файл.

Хм... Именно для того, чтобы избежать подобных ситуаций, и был создан интерфейс временной панели... Ты уверен, что всё реализовано именно так, как требуется по API?

Alt+Enter - наиболее разумный для этого путь.

Вообще-то, по Alt+Enter обычно вызывется диалог свойств файла (и в FSE, кстати, тоже). Но ты не понял, мой вопрос был не о том на какой хоткей это дело повесить. Вопрос был о распределении функций между плагином и Тоталом. Сегодня нет выбора и переименование обязан выполнять плагин. Вопрос был - почему ты возражаешь, чтобы ТС переименовал файл?

Хм... Именно для того, чтобы избежать подобных ситуаций, и был создан интерфейс временной панели...

Так и я на это же рассчитывал!

Ты уверен, что всё реализовано именно так, как требуется по API?

Конечно уверен. Сто раз все перепроверил, перед тем как к Гислеру обратился.

Но тут интересное кино получается. Все это происходило где-то в мае прошлого года. С тех пор я тщательно следил и в History.txt ничего на эту тему не видел. А сейчас ты заставил меня задуматься - а вдруг что-то все равно изменилось и я проверил. Что значит проверил? А просто запустил поиск через FSE и стал копировать в разные места. И что бы ты думал? О чудо!
Оказалось, что при копировании в Burner и на ФТП теперь ТС все делает сами без лишних телодвижений! Копирование в архив делается дважды - сначала TC просит плагин скопировать файл в темп, потом пытается сделать это сам, но иногда, почему-то, не может. Копирование на диск не изменилось.

То есть, теперь ситуация - полный улет. Кто именно выполняет копирование теперь зависит от того, куда копируем. Если у тебя стоит FSE можешь увидеть это своими глазами.
Я почти уверен, что с архивами имеет место баг и если Гислеру сказать, то он починит. А вот с дисками - это, видимо, его принципиальная позиция - нехай плагин сам копирует.
В общем, я не знаю, какая логика за этим скрывается, да и, честно говоря, уже не больно-то и хочется знать.

VadiMGP писал(а):Вопрос был - почему ты возражаешь, чтобы ТС переименовал файл?

Так я ж на него уже отвечал: потому что а) у пользователя нет возможности сказать, что именно он хочет переименовать - ссылку или файл, б) при переименовании файла нарушится работоспособность ссылки.

Что касается копирования - не знаю, надо будет проверить, как время найдётся. Всё же очень похоже на баг, возможно, Гислер что-то не так понял...

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

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

Если завтра ТС начнет переименовывать файлы, то:
а) у пользователя нет возможности сказать, что именно он хочет переименовать - ссылку или файл,
б) при переименовании файла нарушится работоспособность ссылки.

Это минусы. Эти проблемы действительно могут возникнуть в будущем, если 1) появятся плагины, в которых нужно будет независимое переименование ссылок и файлов, но 2) Гислер, невзирая на это, не пожелает улучшать API. Верно?
(Хочу напомнить - я считаю, что проблема б) при переименовании это частный случай более общей проблемы неработоспособных ссылок и плагину все равно надо ее решать.)

Теперь посмотрим на плюсы. Мы автоматически стазу получаем:
а) MRT
б) ТС-шный Overwrite dialog
в) Поддержка .ion, .bbs и комментов
г) Учитываются опции "выполнение операций через проводник" и режимы совместимости для различных дисков.

И это только первое, что приходит в голову. Если подумать, можно найти еще пару-тройку фич.

Если же ТС не переименовывает завтра файлы, то, с одной стороны, в будущем нам не грозят проблемы, о которых ты говорил.
Но с другой стороны, мы гарантировано лишены плюсов б) в) г), о которых писал я. В рамках существующего API автор плагина довольно легко может сделать поддержку MRT и это позволяет надеяться, что все или большинство авторов сделают это. Теоретически возможно, хотя я и не верю, что кто-то сам сделает поддержку .ion и .bbs, но только для своего плагина. Поэтому я смело говорю, что в целом мы лишены в).

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

К тому же, всегда есть надежда, что API будет улучшен и минусы исчезнут естественным образом.

И, напоследок, хочу спросить - не для спора, просто интереса ради. Ты действительно считаешь, что при таком раскладе минусы перевешивают плюсы?
Алаверды.

VadiMGP писал(а):И, напоследок, хочу спросить - не для спора, просто интереса ради. Ты действительно считаешь, что при таком раскладе минусы перевешивают плюсы?

Ты всё время преподносишь эти улучшения как некую замену существующему интерфейсу. Это вызвало непонимание с самого начала, это начнёт вызывать непонимание и теперь. Это не замена, это расширение! Иначе говоря, плагин сам, осознанно, в здравом уме и твёрдой памяти говорит Тоталу: да, я такой-сякой, хочу поиметь возможные проблемы с битыми ссылками и не давать пользователю возможности ссылки переименовывать, а ты, Тотал, давай-ка мне взамен все супер-фичи от а) до г). И Тотал даёт ему эти супер-фичи. А другой плагин, например, какой-нибудь TempPanel, который разработан вот прямо сейчас и о каких-то будущих интерфейсах, реализованных в TC версии 12.0, знать не знает, ничего такого Тоталу сказать не сможет (потому как не в курсе, что надо говорить), и будет работать в точности так же, как работает сейчас.

Иначе говоря, выбор интерфейса будет лежать на авторе плагина. Решит он, что лучше старое поведение - без удобного переименования файлов, но с удобной работой ссылок - реализует старое (и Тотал ему это позволит); решит, что лучше новое - реализует новое (и Тотал позволит ему и это).

И ещё что я хочу сказать: какой смысл спорить, какие плюсы какими минусами перевешиваются (или наоборот), если существует возможность (хотя бы теоретическая) реализовать так, чтобы были только плюсы, без минусов? И эта возможность уже высказывалась выше: либо позволить плагинам вызывать внутренние функции Тотала, либо возвращать спец-код возврата, который скажет Тоталу, что схалявить не получится, и функцию придётся выполнять самому Тоталу. В этом случае будут доступны и все плюсы от а) до г), и упомянутых минусов не будет, потому как Тотал вызывает функцию плагина, и плагин способен выполнить необходимую обработку (в частности, переименовать файл-ссылку вместе с переименованием оригинального файла; или подправить внутренние данные, без переименования самой ссылки).

И последний момент:

VadiMGP писал(а):(Хочу напомнить - я считаю, что проблема б) при переименовании это частный случай более общей проблемы неработоспособных ссылок и плагину все равно надо ее решать.)

С этим я не спорю. Но зачем ухудшать ситуацию, когда этого можно не делать? Одно дело - когда кто-то в совершенно левой программе, совершенно левыми операциями втихомолку переименовал файл, и теперь ссылка на него битая. Что ж, обидно, досадно, но ничего сделать здесь невозможно в принципе. И совершенно другая ситуация, когда ты сам, своими собственными руками, в своём собственном плагине вызываешь функцию переименования, и после этого ссылка перестаёт работать, хотя плагин мог бы запросто обработать это переименование и исправить ссылку на лету. Видишь разницу? В первом случае - неизбежное зло (сделать ничего нельзя), во втором - элементарное разгильдяйство (мог сделать, но не захотел).

Ты всё время преподносишь эти улучшения как некую замену существующему интерфейсу.

Чокнуться можно! Ведь я говорил (как я думал - явно и недвусмысленно), что я не предлагаю никакой замены API. Все эти улучшения доступны без всяких изменеий/расширений нынешнего API. Так почему же ты упорно возвращаешься к "замене" API? Что именно так снова и снова наводит тебя на эту мысль? Ну покажи мне, пожалуйста, какой(ие) конкретно элемент(ы) API изменяются? И как именно?

какой смысл спорить, какие плюсы какими минусами перевешиваются (

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

А что касается теоретической возможности иметь одни плюсы без минусов (кто бы спорил, что лучше быть богатым и здоровым, чем бедным и больным), то это возможно только после расширения API. Я боюсь, что это слишком розовое далёко. Я до него не доживу.

во втором - элементарное разгильдяйство (мог сделать, но не захотел).

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

VadiMGP писал(а):Все эти улучшения доступны без всяких изменеий/расширений нынешнего API. Так почему же ты упорно возвращаешься к "замене" API? Что именно так снова и снова наводит тебя на эту мысль?

Как что? Да элементарные соображения совместимости! Если Гислер сейчас возьмёт и поменяет поведение Тотала при некоторых операциях с плагинами, не меняя API этих плагинов, то существующие плагины попросту перестанут корректно работать. Поэтому о таком изменении даже вопрос не ставится. Не будет такого изменения, и быть не может! Единственные возможные варианты:
а) оставить всё в точности так, как есть сейчас;
б) добавить новые функции/константы/параметры в существующий API вместе с добавлением нового описанного тобой поведения только при условии, что плагин использует эти самые новые функции/константы/параметры. Номер версии API, естественно, тоже должен будет увеличиться.

VadiMGP писал(а):Вот, есть API - такой, какой есть. Так какой из этих двух вариантов является более привлекательным до тех пор пока API не расширится?

Вот API, такой какой он есть, менять категорически недопустимо. И неважно, что мне кажется лучше, а что хуже. И неважно, что тебе или даже Гислеру кажется лучше, а что хуже. Существующее поведение в принципе нельзя менять без расширения API. Просто по определению.

VadiMGP писал(а):то это возможно только после расширения API.

Точно так же, как и предлагаемое тобой изменение. А раз и то, и другое требует расширения API, то почему бы его не расширить сразу так, как удобнее?

VadiMGP писал(а):Эк ты сразу все под одну гребенку...

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

Как что? Да элементарные соображения совместимости! Если Гислер сейчас возьмёт и поменяет поведение Тотала при некоторых операциях с плагинами, не меняя API этих плагинов, то существующие плагины попросту перестанут корректно работать.

Интересно. Я в упор не вижу ни единой проблемы совместимости. И мне кажется, что ты невнимательно прочитал мое предложение. Оно касалось исключительно плагинов виртуальных панелей. На все остальные плагины это в принципе не может оказать никакого влияния. А теперь проиллюстрируй свою мысль на конкретном примере, пожалуйста. Какой именно плагин виртуальной панели написанный в соответствии с нынешним API станет работать некорректно? И в чем именно эта некорректность будет заключаться?

И неважно, что мне кажется лучше, а что хуже.

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

Существующее поведение в принципе нельзя менять без расширения API. Просто по определению.

Тебя не сильно удивит, что я не знаком с таким определением? Более того, беру на себя смелость утверждать, что такого определения не существует. Более того, я продолжаю утверждать, что не только можно менять поведение ТС (что, кстати, многократно уже происходило без всяких изменений API), но и нужно. Так, для справки - последний известный мне раз, когда Гислер менял поведение ТС в части виртуальных панелей, был в январе.

Вот API, такой какой он есть, менять категорически недопустимо.

Извини, я не понял какой смысл ты вкладывал в это предложение. Выражение "такой, какой есть" синоним слова "неизмененный". То есть, я вижу фразу "Неизмененный API менять категорически недопустимо."

(как противопоставление ситуации, когда сделать это самое что-либо даже возможности ни малейшей не существует).

Высшие силы vs. человеческая натура?