Latest post of the previous page:
IgorZДело вот в чём: скрипт может определять 20 макросов. А может не определять ни одного.
Т.е. регистрировать скрипт целесообразнее независимо.
Latest post of the previous page:
IgorZНо регистрируются в Far-е макросы, а не скрипты. В общем, неоднозначный вопрос, согласен. Идея моего предложения заключалась в том, чтобы ещё больше приблизить макросы к плагинам. Поскольку по возможностям они уже почти сравнялись.John Doe wrote:IgorZ
Дело вот в чём: скрипт может определять 20 макросов. А может не определять ни одного.
Т.е. регистрировать скрипт целесообразнее независимо.
Регистрируются клавиатурные сочетания, вызывающие скрипт.IgorZ wrote:Но регистрируются в Far-е макросы, а не скрипты.
Как и моего.IgorZ wrote:Идея моего предложения заключалась в том, чтобы ещё больше приблизить макросы к плагинам.
Предлагаю так:John Doe wrote:Регистрируются клавиатурные сочетания, вызывающие скрипт.IgorZ wrote:Но регистрируются в Far-е макросы, а не скрипты.
Регистрируются пункты меню плагинов, вызывающие скрипт.
Регистрируются обработчики событий.
Что из этого сейчас называть макросами?
Думает, что это либо не нужно, либо преждевременно.IgorZ wrote:Действительно, обсуждаемое описание более всего подходит скрипту. С другой стороны, тогда потребуется разработка системы регистрации скриптов. Возьмётся ли Shmuel за такое? Объём работы, на первый взгляд, не маленький, если делать капитально, ведь тогда стоит в описание скрипта внести поля и, возможно, ещё что-нибудь, к примеру, список всех файлов, входящих в скрипт. В общем, хотелось бы выслушать начальника транспортного цеха Shmuel-я, что он думает по этому поводу.
Это излишне.IgorZ wrote:[...]если делать капитально, ведь тогда стоит в описание скрипта внести поля
Что-то подобное может в перспективе пригодиться, например для деинсталляции. Лучше не список файлов, а функция, получится универсальнее.и, возможно, ещё что-нибудь, к примеру, список всех файлов, входящих в скрипт.
Зачем изобретать велосипед?! Уже давным-давно есть возможность делать на базе Windows Installer полноценные де-/инсталляторы скриптов и даже плагинов — в формате MSI или завёрнутые в EXE.John Doe wrote:Что-то подобное может в перспективе пригодиться, например для деинсталляции. Лучше не список файлов, а функция, получится универсальнее.
http://www.rsdn.ru/forum/flame.comp/5245011.1HaRT wrote:Зачем изобретать велосипед?! Уже давным-давно есть возможность делать на базе Windows Installer полноценные де-/инсталляторы скриптов и даже плагинов — в формате MSI или завёрнутые в EXE.
Windows Installer — стандарт де-факто. Чтобы скрыть его недостатки, есть соответствующие инструменты. Для скриптов или плагинов в большинстве случаев хватит банального ZipInstaller.DrKnS wrote:http://www.rsdn.ru/forum/flame.comp/5245011.1HaRT wrote:Зачем изобретать велосипед?! Уже давным-давно есть возможность делать на базе Windows Installer полноценные де-/инсталляторы скриптов и даже плагинов — в формате MSI или завёрнутые в EXE.
Представить можно, но функция отображения "соседних" макросов/событий, находящихся в одном файле, имеет смысл в любом случае:IgorZ wrote:Легко могу представить ситуацию, когда сложный скрипт состоит из нескольких файлов.
Опять же, надо отталкиваться от того, зачем мы собрали скрипты в один файл, и для чего нам их регистрировать отдельно (а не как единый скрипт).IgorZ wrote: Ещё легче представить ситуацию, когда в одном файле собрана куча независимых мелких скриптов.
Полагаю, такой ситуации возникнуть не может никогда.IgorZ wrote:Кстати, возможна ли ситуация, когда один и тот же макрос/эвент относится к нескольким независимым скриптам? Поскольку тогда нужна возможность задания для одного макроса/эвента нескольких suid.
Собственно, я и не возражал, просто заметил, что этот способ - не панацея, а суррогат. А что не обязан регистрироваться - это да. Но, надеюсь, выгода и удобство победят, и наличие suid станет нормой. Кстати, если макрос не принадлежит скрипту - это значит, что сам макрос и является скриптом, который состоит из единственного макроса - данного. Уф, ну и сформулировал.John Doe wrote:Представить можно, но функция отображения "соседних" макросов/событий, находящихся в одном файле, имеет смысл в любом случае:IgorZ wrote:Легко могу представить ситуацию, когда сложный скрипт состоит из нескольких файлов.
— Не каждый макрос обязан принадлежать какому-то скрипту.
— И не каждый скрипт обязан регистрироваться (в первую очередь давайте подумаем что даёт нам эта регистрация).
Например, куча мелких макросов, по сложности на уровне клавиатурных или чуть выше, не имеющих практически ничего общего и собранных вместе только для того, чтобы не плодить десятки файлов, каждый из пары строк.John Doe wrote:Опять же, надо отталкиваться от того, зачем мы собрали скрипты в один файл, и для чего нам их регистрировать отдельно (а не как единый скрипт).IgorZ wrote: Ещё легче представить ситуацию, когда в одном файле собрана куча независимых мелких скриптов.
Да, наверное, это я расфантазировался. Но есть схожая, вполне реальная ситуация - с модулями. Возможно, неплохо было бы ввести поле для указания внешних ссылок.John Doe wrote:Полагаю, такой ситуации возникнуть не может никогда.IgorZ wrote:Кстати, возможна ли ситуация, когда один и тот же макрос/эвент относится к нескольким независимым скриптам? Поскольку тогда нужна возможность задания для одного макроса/эвента нескольких suid.
В чём заключаются выгода и удобство?IgorZ wrote:Но, надеюсь, выгода и удобство победят, и наличие suid станет нормой.
Допустим. Как и для чего вы собираетесь их регистрировать?IgorZ wrote:Например, куча мелких макросов, по сложности на уровне клавиатурных или чуть выше, не имеющих практически ничего общего и собранных вместе только для того, чтобы не плодить десятки файлов, каждый из пары строк.
Что с этим полем предполагается потом делать?IgorZ wrote:Возможно, неплохо было бы ввести поле для указания внешних ссылок.
Однозначный и универсальный способ указать все компоненты, входящие в составной скрипт. Этого мало? Хочу напомнить, что uid тоже поначалу не казался нужной и очевидной вещью.John Doe wrote:В чём заключаются выгода и удобство?IgorZ wrote:Но, надеюсь, выгода и удобство победят, и наличие suid станет нормой.
О регистрации в данном случае речь не шла. Я говорил о том, что в одном файле могут оказаться несколько независимых друг от друга макросов, и привёл пример.John Doe wrote:Допустим. Как вы и для чего их регистрировать?IgorZ wrote:Например, куча мелких макросов, по сложности на уровне клавиатурных или чуть выше, не имеющих практически ничего общего и собранных вместе только для того, чтобы не плодить десятки файлов, каждый из пары строк.
Примеры возможных действий:John Doe wrote:Что с этим полем предполагается потом делать?IgorZ wrote:Возможно, неплохо было бы ввести поле для указания внешних ссылок.
Раз вы подразумеваете множество применений, значит стоит попытаться их перечислить, ведь от этого зависит решение задачи.IgorZ wrote:Однозначный и универсальный способ указать все компоненты, входящие в составной скрипт. Этого мало?
Но пока что пользуются им ровно 2 человека )IgorZ wrote:Хочу напомнить, что uid тоже поначалу не казался нужной и очевидной вещью.
Могут оказаться. Но даже если макросы технически независимы, их объединяют в одном файле по какому-то общему признаку, поэтому функция "показать все макросы из файла" вполне осмыслена.IgorZ wrote:О регистрации в данном случае речь не шла. Я говорил о том, что в одном файле могут оказаться несколько независимых друг от друга макросов, и привёл пример.
Это чтобы совсем не читать и не думать?IgorZ wrote:Возможно, неплохо было бы ввести поле для указания внешних ссылок.
Понятно. Задача весьма специфическая.IgorZ wrote:[*]Автоматизация сборки файлов, содержащих скрипт и все компоненты, от которых он зависит. К примеру, выбираешь в списке нужный макрос, сборщик проходится по ссылкам, составляет список всех файлов и экспортирует их в виде архива.
Согласен. Но уже сейчас есть какие-то идеи - высказывайтесь.IgorZ wrote:А вообще, как показывает практика, спустя некоторое время после введения новых возможностей число способов их использования может стать куда больше изначально предполагаемого.