Общие пожелания к FAR 2.x API

Хотите говорить о Far и не знаете, куда обратиться?
Post Reply
User avatar
NightRoman
Posts: 5920
Joined: Fri 18 Aug, 2006 13:52
Location: Cambridge, UK
Has thanked: 12 times
Been thanked: 14 times
Contact:

Общие пожелания к FAR 2.x API

Post by NightRoman »

Начну с одного пожелания общего характера. Может и еще у кого будут, тема может пригодится.

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

Этот пачечный ввод-вывод не всегда хорош даже для обычных плагинов в некоторых случаях. Но он особенно нехорош для плагинов типа FarNet и их потребителей (в плане производительности). У Far АПИ в стиле «С». У FarNet ООП – методы, свойства (и по другому не надо, в этом и цель была, чтобы так было). Но свойства, суть, внутри тоже методы, получение каждого свойсва – это запрос у Фара структуры данных, из которой берется одно. Пользователю надо 5 свойств – 5 раз будет запрошена эта структура, 5 раз Фар будет заполнять ее целиком.

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

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

Max Rusov
Posts: 3632
Joined: Wed 23 Nov, 2005 11:11
Location: Москва-Питер
Has thanked: 1 time
Been thanked: 11 times

Re: Общие пожелания к FAR 2.x API

Post by Max Rusov »

Еще одно пожелание - сделать быстрый Idle. Сейчас в API есть событие Idle, но вызывается оно
крайне редко (раз в несколько секунд), что делает его почти бесполезным. Хотелось бы, чтобы
событие Idle вызывалось без задержек (либо с задержкой типа Sleep(1), чтобы не греть процессор).
Чтобы в старых плагинах от этого что-нибудь не отвалилось, можно ввести какой-нибудь флаг
OPIF_FastIdle / FDLG_FastIdle. Имеет смысл как для панельных плагинов, так и для диалогов.

Еще, неплохо бы ввести экспортируемую плагином функцию Idle, с теми же правилами вызова.

User avatar
NightRoman
Posts: 5920
Joined: Fri 18 Aug, 2006 13:52
Location: Cambridge, UK
Has thanked: 12 times
Been thanked: 14 times
Contact:

Re: Общие пожелания к FAR 2.x API

Post by NightRoman »

ECTL_GETINFO стала слишком дорогой, мало того, что Фар возвращает, то, что плагину часто не нужно, это еще освобождать надо. Жить с этим можно, но введите, пожалуйста, ECTL_GETINFOSHORT или не требуйте освобождать строки (требуйте немедленно использовать), либо, как предлагалось в первом посте, вообще эту структуру данных редактора развалите на отдельные свойства.

User avatar
NightRoman
Posts: 5920
Joined: Fri 18 Aug, 2006 13:52
Location: Cambridge, UK
Has thanked: 12 times
Been thanked: 14 times
Contact:

Re: Общие пожелания к FAR 2.x API

Post by NightRoman »

Far2 не копирует FarDialogItem.History (может и Far1, но это "в прошлом").

Это неудобная опасная штука и ее затруднительно эффективно использовать для некоторых задач.

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

Опасная. Можно не знать документацию, можно ее не читать, и ее может не быть, как сейчас, например. Одним словом, поди догадайся, что History, переданную в элемент диалога, нельзя освобождать ни после Info.DialogInit, ни после Info.DialogRun (а ведь некоторые другие данные можно, например после DialogRun), а можно только после Info.DialogFree. Если так сделать, то Фар все еще будет использовать этот указатель в Info.DialogFree, чтобы обновить данные истории в реестре, а имя истории уже указывает на освобожденную память. Может упасть, а может в реестр писать мусор, молча и долго, пока случайно не заметишь, что в реестре в истории диалогов много элементов с интересными именами.

Затруднительно эффективно использовать, по крайней мере для некоторых задач. Хочу в диалоге динамически поменять историю, чтобы ее строки из другого места взять. Разовая операция извне и вообще, например, из плагина, который этот диалог и не создавал (FarNet, например, может работать с любым диалогом, даже не со своим, даже с родным Фаровским). Но негде эту строку с именем истории держать. Операция отработала и все, может и плагин, который ее выполнял, выгрузили после этого, а диалогу с этим указателем на мусор еще жить и работать. Таким образом, удобная в принципе фича, и примитивная по сути, становится сложной задачей.

Есть конечно мысль, что так было сделано сознательно по каким-то хитрым причинам. Ну что ж, селяви. Но если нет особых причин, в новом Фаре очень хотелось бы доработки в этом вопросе, история элементов ввода - штука полезная и может быть еще полезнее, если доработать.

P.S. Немного о другом, но в принципе связанные вещи. Было бы интуитивно и удобно, если бы все свои данные я мог освободить после Info.DialogInit - я же их Фару уже передал, он мог бы их скопировать, не для того ли Init? Сейчас это не так. Мало того, что это неудобно с точки зрения продумывания обеспечения жизненного цикла этих данных (удалить мы можем только после DialogRun, а это не всегда в том же месте кода, что Info.DialogInit), так еще и дублирование входных и рабочих данных происходит - это не только расход ресурсов, но и источник тонких подвохов. Диалог запустили и вот тут данные существуют в двух экземплярах - наши входные и скопированные Фаром. Если это диаложек с полями ввода и кнопкой ОК - это ничего, но ведь может быть и большой список строк, размеры которых теперь к тому же неограничены.

Игорь Юдинцев
Posts: 725
Joined: Sun 03 Apr, 2005 22:00
Location: Казань
Been thanked: 1 time

Re: Общие пожелания к FAR 2.x API

Post by Игорь Юдинцев »

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

Post Reply

Return to “Обсуждение Far Manager”