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

Вам не хватает чего-то в Far? Вы считаете, что вашу идею стоит услышать? Пишите сюда.
Post Reply
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 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.
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 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. но все изменения локальны и временны для конкретной копии. но даже тут не обошлось без приключений, хотя гораздо меньшего масштаба. а по ссылке пример человека, который пишет скрипт, который влияет буквально на всё в фаре, и при этом не утруждает себя чтением документации. давать в руки таких людей возможность перманентно менять состояние фара — не выглядит разумным.
мой вывод, что тогда нужны не-перманентные настройки для АПИ
User avatar
buniak_a_h
Posts: 4234
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 642 times
Contact:

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

Post by buniak_a_h »

citRiks, извините, не выдержал - вмешался.
Как выяснилось на практике, "перманентные" изменения в настройках делаются элементарно через SQLite UPDATE . Проблема в том, чо такие изменения не идны в текущей сессии ФАРа. Т.е. как раз то, против чего выступал zg ("невидимое" для юзера, но остающееся в настройках изменения) - как раз легко реализуется. И даже хуже. Изменения не видны, но при следующем старте ФАРа станут актуальны. Поэтому потуги к затруднению изменения настроек - это абсолютно бесполезные. К тому же меня умилила фраза на мантисе:
https://bugs.farmanager.com/view.php?id=2481#c11405 wrote:а давайте не будем решать за пользователя, какие настройки у него должны быть.
Макросы часто пишет сам пользователь. Т.е. в прямом противоречии со своим же высказыванием авторы решают за пользователя, какие настройки он может менять, а какие - нет.
Много вообще ненужных ограничений…
User avatar
citRiks
Posts: 1733
Joined: Fri 25 Oct, 2019 18:18
Has thanked: 610 times
Been thanked: 102 times

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

Post by citRiks »

buniak_a_h wrote: Wed 22 Apr, 2020 22:23 "перманентные" изменения в настройках делаются элементарно через SQLite UPDATE .
Не, ну это же типа хак извне, тут "редакция никакой ответственности не несет как раз"
что ЗГ и хотел, т. е. не нести ответственности за такое и связанные осложения.
buniak_a_h wrote: Wed 22 Apr, 2020 22:23 Макросы часто пишет сам пользователь. Т.е. в прямом противоречии со своим же высказыванием авторы решают за пользователя, какие настройки он может менять, а какие - нет.
Много вообще ненужных ограничений…
Да, есть ограничения которые лучше бы чтобы их не было.
И есть вопрос как лучше угодить всем, и разрабам, и юзерам и крутым хакерам.
На этот вопрос есть много ответов, которые хужее или лучшее для любой из упомянутых сторон.

Приведу свежий, и как мне кажется, хороший пример, как лучшее всем.
Вот недавно совсем, при улучшении FarColorer АПИ и overall user experience,
сделано разделение на типа на сессионные настройки и глобальные настройки.
На примере креста, это значит что крест можно включить или отключит через АПИ в сессии редактора,
но это не повлият на глобальную настройку креста (вкл/выкл).
Т.е. статус креста имеет два уровня:
1.) Глобальный или схемный, хранимый, нет АПИ изменений (или есть? но не суть, допустим нет)
2.) Сессионный, НЕ хранимый, т.е. при выходе-заходе обнулится ЕСТь АПИ для изменений
Допустим скрипт не может менять глобальную настройку, так оно ему и не надо, когда есть пункт (2.)

То же самое хорошо бы было иметь и для ФАР конфигов,
на мой взгляд это полная аналогия с настройками креста.

И я вот эту мысль и хотел донести и в этом предложении.
А так-то понятно что работа с конфигами не совершенна,
вопрос как лучше сделать.
Мне например действительно не улыбается разгребать последствия измений скриптами настроек,
помнить как было, и восстанавливать как было,
хотя я согласен и с тем, что достаточно часто может быть удобным менять настройки через АПИ
Post Reply

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