Подумалось тут... Давно стало классикой примерно такое:
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 с неким эталоном...
Что возвращать в GetMinFarVersion()
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Re: Что возвращать в GetMinFarVersion()
И не будет.API для 1.75 уже давно не менялось
1. В последней версии FAR меньше багов, чем в предпоследней.привязка к последней версии FAR, кроме стимуляции пользователей новых версий плагинов к обновлению FAR фактически ничего не даёт.
2. Чем новее у пользователя FAR - тем лучше для самого пользователя.
3. Стимулировать пользователей обновлять FAR - исключительно богоугодное дело.
Не стоит. Изменений в 1.x нет и не будет, а в 2.х это временное явление, связанное с его "переходным возрастом".Может быть стоит ввести кроме FARMANAGERVERSION ещё и FARMANAGERCOMPATIBLEVERSION, которое будет возвращать последнюю версию FAR, в которой произошли изменения в API?
Расставлять костыли ради временных явлений - нецелесообразно.
Посему авторам рекомендуется возвращать FARMANAGERVERSION и не париться.
Re: Что возвращать в GetMinFarVersion()
Понял, не дурак. Будем стимулироватьDrKnS wrote:3. Стимулировать пользователей обновлять FAR - исключительно богоугодное дело.
...
Посему авторам рекомендуется возвращать FARMANAGERVERSION и не париться.
Но более красивой стимуляцией было бы не тупо не стартовать плагин, а дать ему возможность обругать юзера желтым земляным червяком за древний FAR и только после этого гордо выйти или предложить запустить плагин на свой страх и риск. А вот тут уже хочется быть уверенным, что плагин под этой "древностью" всё же будет работоспособен, для чего FARMANAGERCOMPATIBLEVERSION очень бы не помешала... Но я не настаиваю. Тем более, что это можно сделать и самому, только придётся где-то в сторонке держать тестовую "древность" для тестов.
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Re: Что возвращать в GetMinFarVersion()
"тупо не стартовать" - это в каком продукте?Но более красивой стимуляцией было бы не тупо не стартовать плагин
У нас, вообще-то, в подобной ситуации возникает красивая красная табличка, где указан плагин, указана желаемая им версия far, указана текущая.
Если хочется именно "желтым земляным червяком" и возможности "запустить на свой страх и риск" - не экспортируй сабж, а сам спрашивай у фара версию где-нибудь в SetStartupInfo. А дальше ругай пользователя как угодно, работай дальше или не работай - всё в твоих руках :)дать ему возможность обругать юзера желтым земляным червяком за древний FAR и только после этого гордо выйти или предложить запустить плагин на свой страх и риск.
Я не совсем понимаю, как ты себе представляешь эту константу.хочется быть уверенным, что плагин под этой "древностью" всё же будет работоспособен, для чего FARMANAGERCOMPATIBLEVERSION очень бы не помешала
Как тут можно быть в чём-то увереным?
Вот, к примеру, менялось недавно панельное api. Естественно, поломалась куча плагинов.
А, допустим, колорер на это чихать хотел, как работал так и работает.
Где критерий compatible'ности?
-
- Posts: 3651
- Joined: Wed 23 Nov, 2005 11:11
- Location: Москва-Питер
- Has thanked: 2 times
- Been thanked: 19 times
Re: Что возвращать в GetMinFarVersion()
Проблема в том, что в FAR 2 довольно часто API меняется без оглядки на совместимость с предыдущими версиями. При этом проверка на версию FAR бессмысленна - у юзера самый распоследний FAR, а именно в нем плагин уже не работает. Может лучше вместо этого ввести некий API Revision и менять его только когда что-то меняется в Plugins.hpp. И сравнивать на равенство, а не на больше/меньше...
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Re: Что возвращать в GetMinFarVersion()
API, в принципе, уже почти утряслось.Проблема в том, что в FAR 2 довольно часто API меняется без оглядки на совместимость с предыдущими версиями.
Планируется ещё пара масштабных изменений и, наверное, всё.
Re: Что возвращать в GetMinFarVersion()
Мне, к сожалению, приходится "продвигать FAR" среди народа, для которого сообщение "Этот модуль требует FAR более высокой версии" это именно "тупо не стартовать". Бухгалтера, чтоб они здоровы были...DrKnS wrote:"тупо не стартовать" - это в каком продукте?
Для этого нужна по крайней мере уверенность в том, что поддерживается, например FMSG_ALLINONE и FMSG_MB_OK, чтобы не писать всё с оглядкой на 1.60... Константа нужна именно для хоть какой-то гарантии, что мы "взлетим" на этой версии.DrKnS wrote:не экспортируй сабж, а сам спрашивай у фара версию где-нибудь в SetStartupInfo. А дальше ругай пользователя как угодно, работай дальше или не работай - всё в твоих руках
Да я и сам понимаю, что по уму тут сделать всё нереально. Чтобы полностью быть в чём-то уверенным, то разве что некой утилитой, которая проанализирует исходники на предмет всех FCTL_*, ACTL_*, PanelInfo::CurDir и так далее. Это не столько нереально, сколько нецелесообразно. Тут я ни разу не спорю. Скажем, многим ли плагинам критично наличие MIF_DISABLE и MIF_GRAYED? Но по крайней мере один такой есть...DrKnS wrote:Я не совсем понимаю, как ты себе представляешь эту константу.
Как тут можно быть в чём-то увереным?
Вот, к примеру, менялось недавно панельное api. Естественно, поломалась куча плагинов.
А, допустим, колорер на это чихать хотел, как работал так и работает.
Где критерий compatible'ности?
Но, с восьмой стороны, если "API, в принципе, уже почти утряслось", а для 1.7x утряслось давно и навсегда, то можно ведь зафиксировать версию, после которой были только багфиксы?
Или сделать это не константой, а макросом или несколькими константами на случай "поломалась куча плагинов, а колорер на это чихать хотел". Скажем FAREDITORCOMPATIBLEVERSION, FARPANELCOMPATIBLEVERSION...
Но дополнения-то точно будут. Добавится что-то в FSF, FCTL_*, ECTL_*... Никуда FARу от этого не деться.DrKnS wrote:Планируется ещё пара масштабных изменений и, наверное, всё
Если константой нереально, но хотя бы в чейнджлоге стоило бы выделять изменения в API так, чтобы не приходилось вдумчиво перечитывать его от начала до конца в поисках билда, на котором ещё стоит тестировать плагин, а под каким уже точно не взлетим.
- John Doe
- Бюрократ
- Posts: 13855
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 73 times
- Been thanked: 428 times
- Contact:
Минимально необходимая версия Far Manager
В дистрибутив фара включены заголовочные файлы, очевидно для использования плагинописателями при сборке плагинов.
Но необходимо учитывать, что если использовать plugin.hpp (например) из актуальной ночной сборки, то собранный плагин не запустится на более старых билдах фара.
Вопрос: насколько это правильно? Ведь реально плагин мог бы работать и с более ранними версиями фара.
Никаких рекомендаций на этот счёт в Энциклопедии я не нашёл, но учитывая что от апи фара обладает обратной совместимостью, кажется логичным в качестве минимального указывать "реальный" требуемый билд фара, исходя из API whatsnew.
Да? Нет?
Что посоветуете?
Но необходимо учитывать, что если использовать plugin.hpp (например) из актуальной ночной сборки, то собранный плагин не запустится на более старых билдах фара.
Вопрос: насколько это правильно? Ведь реально плагин мог бы работать и с более ранними версиями фара.
Никаких рекомендаций на этот счёт в Энциклопедии я не нашёл, но учитывая что от апи фара обладает обратной совместимостью, кажется логичным в качестве минимального указывать "реальный" требуемый билд фара, исходя из API whatsnew.
Да? Нет?
Что посоветуете?
-
- Posts: 6836
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
Минимально необходимая версия Far Manager
Почему? Плагинописатель указывает минимально необходимую версию Фара в функции GetGlobalInfoW.
- John Doe
- Бюрократ
- Posts: 13855
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 73 times
- Been thanked: 428 times
- Contact:
Минимально необходимая версия Far Manager
Действительно.
Но в примере из Энциклопедии используют такой макрос:
Выходит это неправильная практика?
Хотя... Вот нашёл ответ из прошлого http://forum.farmanager.com/viewtopic.p ... 794#p57794
Надо бы осветить этот момент в Энциклопедии, чтобы вопросов не возникало.
Но в примере из Энциклопедии используют такой макрос:
Info->MinFarVersion=FARMANAGERVERSION;
Выходит это неправильная практика?
Хотя... Вот нашёл ответ из прошлого http://forum.farmanager.com/viewtopic.p ... 794#p57794
P.S.
Надо бы осветить этот момент в Энциклопедии, чтобы вопросов не возникало.