ScriptsBrowser — управление скриптами [экспериментально]

Здесь обсуждается всё, что касается макросов.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

ScriptsBrowser — управление скриптами [экспериментально]

Post by John Doe »

Каждый автор так или иначе снабжает свои скрипты метаинформацией, такой как название, описание, версия, автор, тема обсуждения на форуме, и т. п.
Сейчас эта информация может содержаться где угодно: в комментариях, или в каком-то диалоге, или в справке.
Естественно централизовано посмотреть её не получится.

Но раз каждый скрипт в любом случае содержит какую-то метаинформацию, то почему бы не заполнять её стандартизировано?
В результате мы получим возможность управлять скриптами централизованно, и реализовать разные интересные возможности, такие как изложенные ранее: http://forum.farmanager.com/viewtopic.p ... 66#p121966

Представляю экспериментальную реализацию некоторых идей:
Основные понятия:
  • Скрипт — это lua-файл. Он может содержать макросы или выполнять свои функции иным способом.
  • Скрипт может иметь вспомогательные файлы (cfg/lng/hlf).
  • Несколько скриптов могут формировать "пакет".
ScriptsBrowser.lua — утилита для работы со скриптами, запускается из меню плагинов.

regscript.lua — сам модуль, регистрирующий скрипты.
Все поля на данный момент опциональны, и их список открыт для обсуждения.
Пока предлагаю следующие:


cfgscript.lua — вспомогательный модуль, позволяющий переопределить начальные настройки скриптов не трогая их исходный код.

cfgscript_test.lua — демонстрационный скрипт для иллюстрации того, что регистрация может быть полезна и в произвольных скриптах

InsertInfo.lua — вспомогательный макрос для вставки в скрипт шаблона с метаинформацией.

P.S.
Интерфейс самого модуля может быть интересен для применения в макробраузерах.
Сейчас он позволяет получить таблицу скрипта по индексу, по id, или по полному имени файла.
Attachments
scriptbrowser02.7z
(10.12 KiB) Downloaded 299 times
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

ScriptsBrowser — управление скриптами [экспериментально]

Post by John Doe »

Latest post of the previous page:

IgorZ wrote: 1. А что, minfarversion нельзя задавать строкой? Почему?
Соответствующие функции работают с таблицей, отсюда и таблица. Синтаксически таблица не сложнее строки, но строку пришлось бы всё равно конвертировать в таблицу, для обеспечения возможности сравнения версий.
Впрочем, если подумать, не очень сильный аргумент..
Если у вас есть доводы в пользу строки, то почему бы и нет.

Но меня тут смущает один момент: исторически в версии фара не используется компонент Revision, что можно увидеть например в заголовке окна фара.
Поэтому не очень понятно, какой должна быть строка.
В текущей неопубликованной версии ScriptManager minfarversion в окне информации отображается так же без Revision, например

Code: Select all

minfarversion │ 3.0.4743
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

ScriptsBrowser — управление скриптами [экспериментально]

Post by John Doe »

IgorZ wrote: Что, пропускать часть позиций нельзя и надо обязательно указывать все пять чисел? Даже если так, всё равно некрасиво - надо перехватывать такие ситуации.
Согласен, падать не должно.
Насчёт 5 или 4 чисел даже не задумывался, не вручную заполняю а шаблоном.
Принимать и 4?

По факту в нашем случае достаточно и одной (билда), и врядли это когда-то изменится
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

ScriptsBrowser — управление скриптами [экспериментально]

Post by IgorZ »

John Doe wrote:
IgorZ wrote: 1. А что, minfarversion нельзя задавать строкой? Почему?
Соответствующии функции работают с таблицей, отсюда и таблица. Синтаксически таблица не сложнее строки, но строку пришлось бы всё равно конвертировать в таблицу, для обеспечения возможности сравнения версий.
Впрочем, если подумать, не очень сильный аргумент..
Если у вас есть доводы в пользу строки, то почему бы и нет.
Соображение одно: версию скрипта можно задавать строкой, а требуемую версию Far - нет. Разные подходы вызывают недоумение. Однообразие было бы эстетически приятнее (кстати, я, вроде бы, ранее предлагал версию скрипта задавать таблицей - тоже вариант единообразия). Собственно, тоже, если подумать, не очень сильный аргумент..
John Doe wrote:Но меня тут смущает один момент: исторически в версии фара не используется компонент Revision, что можно увидеть например в заголовке окна фара.
Поэтому не очень понятно, какой должна быть строка.
В текущей неопубликованной версии ScriptManager minfarversion в окне информации отображается так же без Revision, например

Code: Select all

minfarversion │ 3.0.4743
Думаю, в случае версии Far строка должна соответствовать принятому нумерованию версии Far. Оно уже давно устоялось и вряд ли когда изменится.
John Doe wrote:
IgorZ wrote: Что, пропускать часть позиций нельзя и надо обязательно указывать все пять чисел? Даже если так, всё равно некрасиво - надо перехватывать такие ситуации.
Согласен, падать не должно.
Насчёт 5 или 4 чисел даже не задумывался, не вручную заполняю а шаблоном.
Принимать и 4?
А зачем там пятая, если по факту в Far она не используется в принципе? Оставить для совместимости, если надо, только вставить, где нужно, что-то вроде ver[5] = ver[5] or 0.
John Doe wrote:По факту в нашем случае достаточно и одной (билда), и врядли это когда-то изменится
При переходе с Far1 на Far2 счётчик билдов сбросился, а по макросам совместимость осталась. Так что, думаю, на всякий случай, все четыре лучше бы оставить, и, заодно, сверять по всем позициям. Да и смотрится красивее и понятнее, когда есть все четыре числа.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

ScriptsBrowser — управление скриптами [экспериментально]

Post by John Doe »

IgorZ wrote: версию скрипта можно задавать строкой, а требуемую версию Far - нет. Разные подходы вызывают недоумение.
Разные подходы тут неизбежны, поскольку semver невозможно в точности сопоставить VersionInfo, хотя бы по причине структурных отличий (куда накладываются ещё и исторические особенности использования в фаре).
IgorZ wrote: и, заодно, сверять по всем позициям.
Думал об этом, но счёл непринципиальным, ведь элементарно изменить в любой момент.
IgorZ wrote: Думаю, в случае версии Far строка должна соответствовать принятому нумерованию версии Far. Оно уже давно устоялось и вряд ли когда изменится.
Я как раз обратил внимание, что в фаре "принято" использовать 3 компонента, а не 4.
Но только для отображения, а в апи у нас да, честный VersionInfo.

Хотите указывать VersionInfo строкой? Если для вас это принципиально, то я не буду возражать.
И насчёт того чтобы компонент Stage принимать по умолчанию за 0 тоже.
Хотя и не вижу от всего этого никакой особой выгоды, ведь всё это вставляется шаблоном.
Делать?
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

ScriptsBrowser — управление скриптами [экспериментально]

Post by IgorZ »

John Doe wrote:
IgorZ wrote: версию скрипта можно задавать строкой, а требуемую версию Far - нет. Разные подходы вызывают недоумение.
Разные подходы тут неизбежны, поскольку semver невозможно в точности сопоставить VersionInfo, хотя бы по причине структурных отличий (куда накладываются ещё и исторические особенности использования в фаре).
Ну, не знаю. Мне глаз царапнуло, я и задал вопрос.
John Doe wrote:
IgorZ wrote: и, заодно, сверять по всем позициям.
Думал об этом, но счёл непринципиальным, ведь элементарно изменить в любой момент.
Так текущий момент ничем не отличается в этом смысле от любого другого.
Возможно, это просто разные привычки. Я когда-то довольно много писал на ассемблере (в том числе игры), так что привычка заранее предусматривать и закрывать возможные дыры осталась с тех времён.
John Doe wrote:
IgorZ wrote: Думаю, в случае версии Far строка должна соответствовать принятому нумерованию версии Far. Оно уже давно устоялось и вряд ли когда изменится.
Я как раз обратил внимание, что в фаре "принято" использовать 3 компонента, а не 4.
Но только для отображения, а в апи у нас да, честный VersionInfo.

Хотите указывать VersionInfo строкой? Если для вас это принципиально, то я не буду возражать.
И насчёт того чтобы компонент Stage принимать по умолчанию за 0 тоже.
Хотя и не вижу от всего этого никакой особой выгоды, ведь всё это вставляется шаблоном.
Делать?
Непринципиально. Более того, версия скрипта, на мой субъективный взгляд, тоже красивее смотрелась бы в виде таблицы. А вот отсутствующие элементы таблицы принимать за 0 было бы, на мой взгляд, разумно.
P. S. Лично я шаблоном при вставке не пользовался. Возможно, из-за того, что вставка nfo для меня пока ещё больше эксперимент, а не вошла в привычку.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

ScriptsBrowser — управление скриптами [экспериментально]

Post by John Doe »

IgorZ wrote: Вот. Адрес можно задавать и таблицей, и строкой.
В спецификации пакета достаточно будет строки, имхо.

Но есть другой вопрос: как лучше поступить с LOCAL/GLOBAL?
В моей практике настройки лежат либо только в GLOBAL, либо в обоих базах (в ключе с тем же путём).

Если же делать совсем универсально, то надо указывать полный перечень ключей, с указанием LOCAL/GLOBAL, и этих ключей может быть не 2, а сколько угодно.
Как по мне, то это будет перебор.

Проще всего LOCAL/GLOBAL в спецификации не указывать, что я и предлагаю.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

ScriptsBrowser — управление скриптами [экспериментально]

Post by IgorZ »

John Doe wrote:
IgorZ wrote: Вот. Адрес можно задавать и таблицей, и строкой.
В спецификации пакета достаточно будет строки, имхо.
Ну не выкидывать же теперь возможность! ;) Вы, коллега, сами же преложили в виде таблицы задавать, а теперь на попятную? :) :) :)
John Doe wrote:Но есть другой вопрос: как лучше поступить с LOCAL/GLOBAL?

Проще всего LOCAL/GLOBAL в спецификации не указывать, что я и предлагаю.
Неясно, как тогда действовать? Ладно, если данные только в одной базе, можно проверять обе и показывать ту, что есть, а если в обеих? Разве что предусмотреть клавишу "перейти на этот ключ в другой базе"? Кстати, неплохая идея независимо от всего.
Кстати, BookmarkManager хранит данные аж в трёх местах: локальные закладки, глобальные закладки и настройки. И как тут быть? Явно, надо предусмотреть возможность указывать несколько ключей. Как вариант, можно условиться, что несколько адресов задаются таблицей, а один можно и не таблицей с одним элементом, а просто строкой. Самую малость сложнее в обработке, но в тривиальных случаях упрощает заполнение nfo.
Да, для таблицы адреса можно задавать в виде описание=адрес. Думаю, будет наглядно и удобно.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

ScriptsBrowser — управление скриптами [экспериментально]

Post by John Doe »

IgorZ wrote: Ну не выкидывать же теперь возможность! ;)
Из dbedit да, конечно не выкидывать.
Но это не значит, что обязательно надо сразу применять именно тут.
IgorZ wrote: Разве что предусмотреть клавишу "перейти на этот ключ в другой базе"?
Именно
IgorZ wrote: Кстати, BookmarkManager хранит данные аж в трёх местах: локальные закладки, глобальные закладки и настройки. И как тут быть?
Зависит от целей.
Если рассматривать эту функцию как возможность менять параметры для простых скриптов, избавляющую их от реализации в каждом случае собственного интерфейса, то для BookmarkManager это вообще не очень актуально.

Но данную функцию можно рассматривать и более широко, как возможность экспорта/импорта/бэкапа.
В этом случае нужен полный перечень ключей.

И раз уж мы о BookmarkManager, то не могли бы вы на его примере проиллюстрировать ваши предложения.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Менеджер закладок для папок

Post by John Doe »

IgorZ wrote: Nfo
В макросах используется поле uid

Функция описания определена не тем способом, что рекомендован в актуальной версии ScriptsBrowser:

Code: Select all

local Info = Info or package.loaded.regscript or function(...) return ... end --luacheck: ignore 113/Info
Напомню, что идея в том, чтобы браузер мог получить описание (например из дистрибутива), передав в окружение собственную функцию Info.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

ScriptsBrowser — управление скриптами [экспериментально]

Post by IgorZ »

John Doe wrote:И раз уж мы о BookmarkManager, то не могли бы вы на его примере проиллюстрировать ваши предложения.
  1. --...
  2.  
  3.   dbkey = {
  4.  
  5.     "Локальные закладки" = "LOCAL//IgorZ//BookmarkManagerData";
  6.  
  7.     "Общие закладки" = "GLOBAL//IgorZ//BookmarkManagerData";
  8.  
  9.     "Настройки скрипта" = "GLOBAL//IgorZ//BookmarkManagerConfig"
  10.  
  11.   };
  12.  
  13. --...
Примерно так. А для, к примеру, LuaManager
  1. --...
  2.  
  3.   dbkey = "IgorZ//LuaManager";
  4.  
  5. --...
что внутри буквально одной строкой превратится в (разумеется, я о результате)
  1. --...
  2.  
  3.   dbkey = { "Настройки скрипта" = "IgorZ//LuaManager"; };
  4.  
  5. --...
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

Менеджер закладок для папок

Post by IgorZ »

John Doe wrote:В макросах используется поле uid
Это о чём???

P. S. А, понял! Да, косяк...
John Doe wrote:Функция описания определена не тем способом, что рекомендован в актуальной версии ScriptsBrowser:

Code: Select all

local Info = Info or package.loaded.regscript or function(...) return ... end --luacheck: ignore 113/Info
Напомню, что идея в том, чтобы браузер мог получить описание (например из дистрибутива), передав в окружение собственную функцию Info.
*ворчливо* Как в шапке ScriptBrowser написано, так и пишу.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

Менеджер закладок для папок

Post by John Doe »

IgorZ wrote: P. S. А, понял! Да, косяк...
С dbedit то же самое
IgorZ wrote: Как в шапке ScriptBrowser написано, так и пишу.
А это мой косяк. В шаблоне изменил, а в шапке нет.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

ScriptsBrowser — управление скриптами [экспериментально]

Post by John Doe »

В DBEdit (как впрочем и в других скриптах) заметил использование поля helptxt, которое показалось мне спорным.
Туда попала довольно специфическая информация, вряд ли интересная именно в Scripts Browser, учитывая что по ShiftF1 открывается полноценная справка (hlf).

Т.е. в данном случае это поле либо не стоит применять вообще, либо разместить там общее описание (то что в справке называется "О скрипте").

Также, предлагаю ещё раз взглянуть на поле history.По текущему содержанию вроде бы вопросов нет.
Но ведь лог изменений имеет свойство расти. Стоит ли пихать всё в nfo? (Помимо прочего это ещё и бессмысленный расход памяти).
Лично я бы предпочёл историю отдельным файлом, ссылка на который будет присутствовать в поле files.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

ScriptsBrowser — управление скриптами [экспериментально]

Post by IgorZ »

John Doe wrote:В DBEdit (как впрочем и в других скриптах) заметил использование поля helptxt, которое показалось мне спорным.
Туда попала довольно специфическая информация, вряд ли интересная именно в Scripts Browser, учитывая что по ShiftF1 открывается полноценная справка (hlf).

Т.е. в данном случае это поле либо не стоит применять вообще, либо разместить там общее описание (то что в справке называется "О скрипте").
Я планировал разместить в этом поле короткую информацию об использовании скрипта на тот гипотетический случай, если файлы справки будут отсутствовать. Но, судя по замечанию, перестарался.
John Doe wrote:Также, предлагаю ещё раз взглянуть на поле history.По текущему содержанию вроде бы вопросов нет.
Но ведь лог изменений имеет свойство расти. Стоит ли пихать всё в nfo? (Помимо прочего это ещё и бессмысленный расход памяти).
Лично я бы предпочёл историю отдельным файлом, ссылка на который будет присутствовать в поле files.
Есть определённые сложности. На файл с историей нет ни писанных, ни исторически сложившихся чётких стандартов имени и расширения. Какие только варианты не встречаются: и changelog, и whatsnew, и history; без расширения, .txt, .язык_истории, .hst,.new... Как разбираться с таким зоопарком - не знаю. Наиболее логичным представляется или вводить отдельное поле для файла истории, или добавить в поле files возможность указывать типы файлов, как я предлагал раньше. Можно было бы, конечно, проигнорировать определение данного типа файла (положившись на то, что пользователь сам догадается, что это, а стандартный просмотр, независимый от типа файла, есть), но мы когда-то говорили о разборе истории в программе и использовании её, в частности, при установке пакетов. Если эти планы ещё живы, правильно было бы реализовывать их поддержку сразу по мере введения соответствующих сущностей.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

ScriptsBrowser — управление скриптами [экспериментально]

Post by John Doe »

IgorZ wrote: мы когда-то говорили о разборе истории в программе и использовании её, в частности, при установке пакетов.
Для файлов со стандартизированной структурой определённо понадобится отдельное поле.
Все прочие будучи перечислены в files уже сейчас вроде бы успешно определяются по маске, весь зоопарк.
IgorZ wrote: Если эти планы ещё живы, правильно было бы реализовывать их поддержку сразу по мере введения соответствующих сущностей.
Планы в планах.
Сущности вводить считаю пока преждевременным.
User avatar
buniak_a_h
Posts: 4236
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 643 times
Contact:

ScriptsBrowser — управление скриптами [экспериментально]

Post by buniak_a_h »

Столкнулся с проблемкой.
В редакторе options есть возможность удалить параметр. Но нет возможности сбросить на "умолчательное" значение (или я не нашёл). Было бы правильным при удалении параметра на самом деле не удалять его (что может привести к неработоспособности скрипта), а вернуть умолчательное значение. Можно, конечно, его вести снова, но надо же помнить имя! Т.е., если случайно удалили и lua не знаю, то до свидания любимы скрипт...
На самом деле я не проверял, возможно, для скрипта значение для удалённого параметра будет браться из текста. Но это не исправляет того факта, что поменять его из ScriptsBrowser-а будет невозможно, пока не заведёшь снова. Надо бы сделать "сброс" (пусть для всех параметров)...
Post Reply

Return to “Обсуждение макросов”