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

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

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

Postby corwinnt » Thu 04 Feb, 2010 17:47

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

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: 4456
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 2 times
Been thanked: 105 times
Contact:

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

Postby DrKnS » Thu 04 Feb, 2010 18:05

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()

Postby corwinnt » Thu 04 Feb, 2010 18:23

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

Понял, не дурак. Будем стимулировать :)

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

User avatar
DrKnS
Posts: 4456
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 2 times
Been thanked: 105 times
Contact:

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

Postby DrKnS » Thu 04 Feb, 2010 18:50

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

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

Где критерий compatible'ности?

User avatar
Max Rusov
Posts: 3599
Joined: Wed 23 Nov, 2005 11:11
Location: Москва-Питер
Been thanked: 6 times
Contact:

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

Postby Max Rusov » Thu 04 Feb, 2010 19:04

Проблема в том, что в FAR 2 довольно часто API меняется без оглядки на совместимость с предыдущими версиями. При этом проверка на версию FAR бессмысленна - у юзера самый распоследний FAR, а именно в нем плагин уже не работает. Может лучше вместо этого ввести некий API Revision и менять его только когда что-то меняется в Plugins.hpp. И сравнивать на равенство, а не на больше/меньше...

User avatar
DrKnS
Posts: 4456
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 2 times
Been thanked: 105 times
Contact:

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

Postby DrKnS » Thu 04 Feb, 2010 19:11

Проблема в том, что в FAR 2 довольно часто API меняется без оглядки на совместимость с предыдущими версиями.

API, в принципе, уже почти утряслось.
Планируется ещё пара масштабных изменений и, наверное, всё.

User avatar
corwinnt
Posts: 92
Joined: Wed 03 Feb, 2010 14:31
Location: Днепропетровск, Украина
Contact:

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

Postby corwinnt » Thu 04 Feb, 2010 23:35

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: 11038
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 9 times
Been thanked: 62 times

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

Postby John Doe » Wed 09 Sep, 2015 20:27

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

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

Что посоветуете?

Shmuel
Posts: 4943
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 11 times
Been thanked: 123 times

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

Postby Shmuel » Wed 09 Sep, 2015 20:42

John Doe wrote:Source of the post Но необходимо учитывать, что если использовать plugin.hpp (например) из актуальной ночной сборки, то собранный плагин не запустится на более старых билдах фара.

Почему? Плагинописатель указывает минимально необходимую версию Фара в функции GetGlobalInfoW.

User avatar
John Doe
Бюрократ
Posts: 11038
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 9 times
Been thanked: 62 times

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

Postby John Doe » Wed 09 Sep, 2015 20:46

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

Хотя... Вот нашёл ответ из прошлого DrKnS @ Что возвращать в GetMinFarVersion()
DrKnS wrote:Source of the post Стимулировать пользователей обновлять FAR - исключительно богоугодное дело.


P.S.
Надо бы осветить этот момент в Энциклопедии, чтобы вопросов не возникало.


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

Who is online

Users browsing this forum: No registered users and 1 guest