NON-persistent FAR configurations, same as persistent, existing for FAR process instance runtime only

Вам не хватает чего-то в Far? Вы считаете, что вашу идею стоит услышать? Пишите сюда.
Post Reply
citRiks
Posts: 454
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 135 times
Been thanked: 40 times

NON-persistent FAR configurations, same as persistent, existing for FAR process instance runtime only

Post by citRiks »

Сорри фор май енглиш, начал писать на русском так:
НЕ персистентные конфиги ФАРА, существующие пер ФАР инстанс ран-тайм только лишь
.. но понял что так тоже не дело.
Другой вариант перевода:
"НЕ сохраняемые настройки ФАРа, существующие и задаваемые только на время исполнения только в исполняемом экземпляре ФАРа"


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

Мое понимание проблемы с этим:
1.) "временно" изменяемые настройки могут оказаться случайно, или так или иначе, сохраненными в базу настроек, причем без ведома пользователя, и доставить тому немало сюрпризов.
2.) Измененные настройки в одном экземпляре ФАРа становятся доступными и актуальными настойками в любом другом паралелльном экземпляре процесса ФАРа

Чтобы решить эту пробелму, я предлагаю создать вдобавок несохраняемые настройки,
актуальные только в этом конкретном исполняемом экземпляре процесса ФАРа.
Может быть лучше пусть будут вообще только в памяти, без сохранения на диск.
Они будут иметь наивысший приоритет над "персистентными" (сохраняемыми),
но не будут сохранятся между запусками.
и дать к ним програмный культурный удобный доступ НА ИЗМЕНЕНИЕ.

Мне кажется, что таким образом и волки будут сыты, и овцы будут целы
Last edited by citRiks on Fri 27 Mar, 2020 12:41, edited 1 time in total.

citRiks
Posts: 454
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 135 times
Been thanked: 40 times

NON-persistent FAR configurations, same as persistent, existing for FAR instance runtime only

Post by citRiks »

вот еще разумные доводы о вреде изменения перманентных настроек програмно:
zg wrote:
Thu 26 Mar, 2020 15:46
изменение настроек программы втайне от пользователя — зло. то же самое в программе с кучей деструктивных функций — очень большое зло. у фара был в прошлом пример, когда плагин случайно менял сочетание xlat на x и потом годами пользователи жаловались, что не работает кнопка x. при этом и версия исправленная давно вышла и написано про это везде было. поэтому реальный пример, почему это плохо — есть. иногда это бывает хорошо, пример editor.SetParam. но все изменения локальны и временны для конкретной копии. но даже тут не обошлось без приключений, хотя гораздо меньшего масштаба. а по ссылке пример человека, который пишет скрипт, который влияет буквально на всё в фаре, и при этом не утруждает себя чтением документации. давать в руки таких людей возможность перманентно менять состояние фара — не выглядит разумным.
мой вывод, что тогда нужны не-перманентные настройки для АПИ

Post Reply

Return to “Предложения и идеи”