Что возвращать в GetMinFarVersion()

Место, где разработчики плагинов могут поделиться своим опытом.
Post Reply
User avatar
corwinnt
Posts: 92
Joined: Wed 03 Feb, 2010 14:31
Location: Днепропетровск, Украина
Contact:

Что возвращать в GetMinFarVersion()

Post by corwinnt »

Подумалось тут... Давно стало классикой примерно такое:

int WINAPI EXP_NAME(GetMinFarVersion)(void) { return FARMANAGERVERSION; }

Но API для 1.75 уже давно не менялось и привязка к последней версии FAR, кроме стимуляции пользователей новых версий плагинов к обновлению FAR фактически ничего не даёт. То есть на самом деле плагин прекрасно заработает и под FAR 1.70, хотя требует 1.75 (build 2619)...

В результате автор плагина вместо FARMANAGERVERSION пишет примерно такое:

int WINAPI EXP_NAME(GetMinFarVersion)(void) { return MAKEFARVERSION(1,71,2232); }

...и при критичном изменении в API забывает изменить это значение. Ведь у него-то последняя версия FAR и plugin.hpp, он просто не наколется на этом... А "собиратели древностей" могут пострадать...

Может быть стоит ввести кроме FARMANAGERVERSION ещё и FARMANAGERCOMPATIBLEVERSION, которое будет возвращать последнюю версию FAR, в которой произошли изменения в API? Изменять её значение даже не нужно "врукопашную", достаточно интеллектуальным скриптом сравнить текущий plugin.hpp с неким эталоном...
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

Re: Что возвращать в GetMinFarVersion()

Post by DrKnS »

API для 1.75 уже давно не менялось
И не будет.
привязка к последней версии FAR, кроме стимуляции пользователей новых версий плагинов к обновлению FAR фактически ничего не даёт.
1. В последней версии FAR меньше багов, чем в предпоследней.
2. Чем новее у пользователя FAR - тем лучше для самого пользователя.
3. Стимулировать пользователей обновлять FAR - исключительно богоугодное дело.
Может быть стоит ввести кроме FARMANAGERVERSION ещё и FARMANAGERCOMPATIBLEVERSION, которое будет возвращать последнюю версию FAR, в которой произошли изменения в API?
Не стоит. Изменений в 1.x нет и не будет, а в 2.х это временное явление, связанное с его "переходным возрастом".
Расставлять костыли ради временных явлений - нецелесообразно.

Посему авторам рекомендуется возвращать FARMANAGERVERSION и не париться.
User avatar
corwinnt
Posts: 92
Joined: Wed 03 Feb, 2010 14:31
Location: Днепропетровск, Украина
Contact:

Re: Что возвращать в GetMinFarVersion()

Post by corwinnt »

DrKnS wrote:3. Стимулировать пользователей обновлять FAR - исключительно богоугодное дело.
...
Посему авторам рекомендуется возвращать FARMANAGERVERSION и не париться.
Понял, не дурак. Будем стимулировать :)

Но более красивой стимуляцией было бы не тупо не стартовать плагин, а дать ему возможность обругать юзера желтым земляным червяком за древний FAR и только после этого гордо выйти или предложить запустить плагин на свой страх и риск. А вот тут уже хочется быть уверенным, что плагин под этой "древностью" всё же будет работоспособен, для чего FARMANAGERCOMPATIBLEVERSION очень бы не помешала... Но я не настаиваю. Тем более, что это можно сделать и самому, только придётся где-то в сторонке держать тестовую "древность" для тестов.
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

Re: Что возвращать в GetMinFarVersion()

Post by DrKnS »

Но более красивой стимуляцией было бы не тупо не стартовать плагин
"тупо не стартовать" - это в каком продукте?
У нас, вообще-то, в подобной ситуации возникает красивая красная табличка, где указан плагин, указана желаемая им версия far, указана текущая.
дать ему возможность обругать юзера желтым земляным червяком за древний FAR и только после этого гордо выйти или предложить запустить плагин на свой страх и риск.
Если хочется именно "желтым земляным червяком" и возможности "запустить на свой страх и риск" - не экспортируй сабж, а сам спрашивай у фара версию где-нибудь в SetStartupInfo. А дальше ругай пользователя как угодно, работай дальше или не работай - всё в твоих руках :)
хочется быть уверенным, что плагин под этой "древностью" всё же будет работоспособен, для чего FARMANAGERCOMPATIBLEVERSION очень бы не помешала
Я не совсем понимаю, как ты себе представляешь эту константу.

Как тут можно быть в чём-то увереным?
Вот, к примеру, менялось недавно панельное api. Естественно, поломалась куча плагинов.
А, допустим, колорер на это чихать хотел, как работал так и работает.

Где критерий compatible'ности?
Max Rusov
Posts: 3651
Joined: Wed 23 Nov, 2005 11:11
Location: Москва-Питер
Has thanked: 2 times
Been thanked: 19 times

Re: Что возвращать в GetMinFarVersion()

Post by Max Rusov »

Проблема в том, что в FAR 2 довольно часто API меняется без оглядки на совместимость с предыдущими версиями. При этом проверка на версию FAR бессмысленна - у юзера самый распоследний FAR, а именно в нем плагин уже не работает. Может лучше вместо этого ввести некий API Revision и менять его только когда что-то меняется в Plugins.hpp. И сравнивать на равенство, а не на больше/меньше...
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

Re: Что возвращать в GetMinFarVersion()

Post by DrKnS »

Проблема в том, что в FAR 2 довольно часто API меняется без оглядки на совместимость с предыдущими версиями.
API, в принципе, уже почти утряслось.
Планируется ещё пара масштабных изменений и, наверное, всё.
User avatar
corwinnt
Posts: 92
Joined: Wed 03 Feb, 2010 14:31
Location: Днепропетровск, Украина
Contact:

Re: Что возвращать в GetMinFarVersion()

Post by corwinnt »

DrKnS wrote:"тупо не стартовать" - это в каком продукте?
Мне, к сожалению, приходится "продвигать FAR" среди народа, для которого сообщение "Этот модуль требует FAR более высокой версии" это именно "тупо не стартовать". Бухгалтера, чтоб они здоровы были...
DrKnS wrote:не экспортируй сабж, а сам спрашивай у фара версию где-нибудь в SetStartupInfo. А дальше ругай пользователя как угодно, работай дальше или не работай - всё в твоих руках :)
Для этого нужна по крайней мере уверенность в том, что поддерживается, например FMSG_ALLINONE и FMSG_MB_OK, чтобы не писать всё с оглядкой на 1.60... Константа нужна именно для хоть какой-то гарантии, что мы "взлетим" на этой версии.
DrKnS wrote:Я не совсем понимаю, как ты себе представляешь эту константу.
Как тут можно быть в чём-то увереным?
Вот, к примеру, менялось недавно панельное api. Естественно, поломалась куча плагинов.
А, допустим, колорер на это чихать хотел, как работал так и работает.
Где критерий compatible'ности?
Да я и сам понимаю, что по уму тут сделать всё нереально. Чтобы полностью быть в чём-то уверенным, то разве что некой утилитой, которая проанализирует исходники на предмет всех FCTL_*, ACTL_*, PanelInfo::CurDir и так далее. Это не столько нереально, сколько нецелесообразно. Тут я ни разу не спорю. Скажем, многим ли плагинам критично наличие MIF_DISABLE и MIF_GRAYED? Но по крайней мере один такой есть...

Но, с восьмой стороны, если "API, в принципе, уже почти утряслось", а для 1.7x утряслось давно и навсегда, то можно ведь зафиксировать версию, после которой были только багфиксы?

Или сделать это не константой, а макросом или несколькими константами на случай "поломалась куча плагинов, а колорер на это чихать хотел". Скажем FAREDITORCOMPATIBLEVERSION, FARPANELCOMPATIBLEVERSION...
DrKnS wrote:Планируется ещё пара масштабных изменений и, наверное, всё
Но дополнения-то точно будут. Добавится что-то в FSF, FCTL_*, ECTL_*... Никуда FARу от этого не деться.

Если константой нереально, но хотя бы в чейнджлоге стоило бы выделять изменения в API так, чтобы не приходилось вдумчиво перечитывать его от начала до конца в поисках билда, на котором ещё стоит тестировать плагин, а под каким уже точно не взлетим.
User avatar
John Doe
Бюрократ
Posts: 13801
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 72 times
Been thanked: 425 times
Contact:

Минимально необходимая версия Far Manager

Post by John Doe »

В дистрибутив фара включены заголовочные файлы, очевидно для использования плагинописателями при сборке плагинов.
Но необходимо учитывать, что если использовать plugin.hpp (например) из актуальной ночной сборки, то собранный плагин не запустится на более старых билдах фара.
Вопрос: насколько это правильно? Ведь реально плагин мог бы работать и с более ранними версиями фара.

Никаких рекомендаций на этот счёт в Энциклопедии я не нашёл, но учитывая что от апи фара обладает обратной совместимостью, кажется логичным в качестве минимального указывать "реальный" требуемый билд фара, исходя из API whatsnew.
Да? Нет?

Что посоветуете?
Shmuel
Posts: 6815
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 41 times
Been thanked: 526 times

Минимально необходимая версия Far Manager

Post by Shmuel »

John Doe wrote: Но необходимо учитывать, что если использовать plugin.hpp (например) из актуальной ночной сборки, то собранный плагин не запустится на более старых билдах фара.
Почему? Плагинописатель указывает минимально необходимую версию Фара в функции GetGlobalInfoW.
User avatar
John Doe
Бюрократ
Posts: 13801
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 72 times
Been thanked: 425 times
Contact:

Минимально необходимая версия Far Manager

Post by John Doe »

Действительно.
Но в примере из Энциклопедии используют такой макрос: Info->MinFarVersion=FARMANAGERVERSION;
Выходит это неправильная практика?

Хотя... Вот нашёл ответ из прошлого http://forum.farmanager.com/viewtopic.p ... 794#p57794
DrKnS wrote: Стимулировать пользователей обновлять FAR - исключительно богоугодное дело.
P.S.
Надо бы осветить этот момент в Энциклопедии, чтобы вопросов не возникало.
Post Reply

Return to “Разработка плагинов”