View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001486 | Wishes | Plugins API | public | 2010-08-31 21:01 | 2014-01-26 09:51 |
Reporter | max rusov | Assigned To | zg | ||
Priority | normal | Severity | feature | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | 2.0 | ||||
Fixed in Version | 3.0 | ||||
Summary | 0001486: Программное добавление макроса (MCMD_AddMacro) | ||||
Description | Предлагаю добавить в ACTL_KEYMACRO новую подкоманду, для программного добавления макроса в библиотеку, минуя реестр. Это дало бы возможность написать плагин, считывающий макросы из текстовых файлов при запуске FAR (по мотивам топика http://forum.farmanager.com/viewtopic.php?f=15&t=27&start=75). Формат struct ActlKeyMacro, вроде как, достаточен для передачи всех данных - код клавиши можно поместить в Reserved[2]. | ||||
Tags | No tags attached. | ||||
Build | 0 | ||||
|
1. А куда поместить макрообласть, и всевозможные условия срабатывания? 2. MCMD_LOADALL и MCMD_SAVEALL недостаточно, хотелось бы избирательности 3. Добавить макрос в библиотеку хорошо, а наоборот? (получить текст и все параметры) (а текже удалить) |
|
Явно не написал, возможно неочевидно: речь идет не о считывании макросов из какого-то файла, я предлагаю передавать в MCMD_AddMacro саму макропоследовательность, в том же виде как и в MCMD_POSTMACROSTRING. Т.е. в принципе ничего нового - просто добавить API к уже имеющимся функциям. Вроде, должно быть несложно. |
|
Да, точно, про макрообласть забыл :(. В принципе - должно хватить битиков во Flags - надо посчитать. |
|
Ну, логически следует, что для получения и удаления можно будет добавить MCMD_GetMacro, MCMD_DeleteMacro - но это на будущее. Для плагина "библиотекаря" достаточно одного MCMD_AddMacro. Так как в реестр ничего не пишется, то все макросы добавленные таким образом сами удалятся при перезапуске FAR. |
|
1. Всевозможные условия срабатывания не забудьте, их больше дюжины. 2. Зачем держаться за совместимость если на носу неизбежный слом АПИ? 3. Поэтому надо продумать на будущее необходимые функции, а то опять битиков не хватит. |
|
Ну, можно, конечно, расширить структуру. В принципе, это даже совместимость не ломает. Так как MCMD_AddMacro новая команда - то она будет работать с расширеной структурой, а все старые MCMD_xxx - со старой структурой. Просто новые поля надо добавить в конец. |
|
Вообщем, для меня данный вишь больше не актуален, его можно закрыть |
|
Не надо торопиться, неужели нет желания избавиться от хаков |
|
Уже сейчас MacroLib имеет больше возможностей, чем если бы он работал через стандартный механизм запуска клавиатурных макросов FAR. Если Вы считаете хаком перехват ReadConsoleInput - то да, желание избавиться есть, но это предмет другого виша... |
|
Я считаю что опыт MacroLib может послужить стимулом к внедрению подобных возможностей в ядро фара. |
|
А я считаю, что в ядре должен остаться только исполнятор (+ те возможности записи/воспроизведения макросов, какие были в <= Far 1.65), а загрузчик и компилятор (в байткод) макросов - в плагине. В этом случае (при известной структуре байткода) макросы могут быть на любом языке (главное, чтобы "правильный" программер попался :-)) UPD: если кто-то сподобится на создание такого плагина - готов плотно поработать (как в плане описания внутренней кухни, так и уточнений исполнятора) |
|
В данном случае вопрос больше не в загрузчике и компиляторе, а скорее в запускаторе: у MacroLib уже сейчас больше возможностей, и запланировано ещё ого-го. |
|
Валентин, при всем уважении, Ваша идея мне кажется утопичной и никому не нужной. Ну кто и зачем будет писать компилятор с какого-нибудь известного языка в байткод FAR? Да и как Вы себе это представляете? Вот есть в языке классы. Какой байткод должен породить вызов метода класса? Или будет поддерживаться не весь язык - а только его какое-то подмножество? Уже есть FAR.NET, LUA FAR - кому это надо, те давно на них что-то скриптуют. Достоинство макросов FAR - то что они нативны (изкоропки) и позволяют покрыть 90% задач мелкой автоматизации. Imho лучше оставить все как есть. Ну при желании развивать макроязык. Макрофункции были бы очень полезны, интеграция с плагинами... |
|
Вот этого достаточно? MCTL_ADDMACRO typedef unsigned __int64 FARMACRORECORDFLAGS; static const FARMACRORECORDFLAGS MFLAGS_MODEMASK =0x00000000000000FF, MFLAGS_DISABLEOUTPUT=0x0000000000000100, ... MFLAGS_REG_MULTI_SZ =0x0000000010000000; struct MacroAddRecord { size_t StructSize; FARMACRORECORDFLAGS Flags; // Флаги макропоследовательности FarKey Key; // Назначенная клавиша wchar_t *Src; // "текст" макроса wchar_t *Description;// описание макроса (для хелпа, например) }; |
|
>MCTL_ADDMACRO Может ещё и MCTL_CHANGEMACRO, MCTL_DELETEMACRO и возможность "пройтись" по всем макросам ? Для MacroView точно пригодится. |
|
Может быть и можно и пригодится... Тут такое дело: 1) что ты видишь в качестве параметров для дэлита и ченжа и 2) кто-бы еще этот MacroView перевел под API 3.0 :-) |
|
>1) что ты видишь в качестве параметров для дэлита и ченжа Каждому макросу - свой id :) Как-то так: struct FarMacroRecord { size_t StructSize; int id; // Если == -1, то макросов больше нет FARMACRORECORDFLAGS Flags; // Флаги макропоследовательности FarKey Key; // Назначенная клавиша. Если задана для MCTL_GETFIRSTMACRO и MCTL_GETNEXTMACRO, то итерация производится только по этой клавише wchar_t *Area; // область макроса wchar_t *Src; // "текст" макроса wchar_t *Description;// описание макроса (для хелпа, например) }; Ну и MCTL_GETFIRSTMACRO, MCTL_GETNEXTMACRO >2) кто-бы еще этот MacroView перевел под API 3.0 :-) Сначала макросы в SQLite :) |
|
> int id; // Если == -1, то макросов больше нет А почему не GUID? Для функций я резервировал именно гуид. > FarKey Key; // Назначенная клавиша. Если задана для MCTL_GETFIRSTMACRO и MCTL_GETNEXTMACRO, то итерация производится только по этой клавише Разжуй. > wchar_t *Area; // область макроса Зачем? Стартовая область задана в Flags. > Сначала макросы в SQLite :) Да я только за... Алекса просите ;-) |
|
Вы уверены, что область нужна в виде wchar_t? Уже ж есть FARMACROAREA. |
|
>> int id; // Если == -1, то макросов больше нет >А почему не GUID? >Для функций я резервировал именно гуид. Может и GUIDы. Только они "на глазок" трудновоспринимаемы (в плагине SQLiteDB, например). >> FarKey Key; // Назначенная клавиша. Если задана для MCTL_GETFIRSTMACRO и MCTL_GETNEXTMACRO, то итерация производится только по этой клавише >Разжуй. Применений может быть масса. Контекстная помощь по макрокомандам, альтернативный редактор макросов :) и т.д. Да и SQL-запросы будут оптимальнее. >> wchar_t *Area; // область макроса >Зачем? Стартовая область задана в Flags. А если макро-плагин захочет завести свою область ? Ну и для наглядности, опять же. А может и так: struct FarMacroRecord { size_t StructSize; int id; // Если == -1, то макросов больше нет GUID Id; // GUID макро-плагина. Если != {00000000-0000-0000-0000-000000000000}, то итерация в MCTL_FIND* производится только по этому GUIDу FARMACRORECORDFLAGS Flags; // Флаги макропоследовательности wchar_t *Key; // Назначенная клавиша (или имя macro func). Если задана, то итерация в MCTL_FIND* производится только по этой клавише wchar_t *Area; // Назначенная область макроса. Если задана, то итерация в MCTL_FIND* производится только по этой области wchar_t *Sequence; // "текст" макроса wchar_t *Description;// описание макроса (для хелпа, например) }; И MCTL_FINDFIRSTMACRO, MCTL_FINDNEXTMACRO, соответственно. >Алекса просите ;-) Ну вот, а на форуме он на тебя всю ответственность перекладыает. :) |
|
Т.е. от идеи переноса макросов в текстовые файлы таки отказались? |
|
>Т.е. от идеи переноса макросов в текстовые файлы таки отказались? Это где? И даже если отказались, сабж вроде бы позволит плагину элементарно загрузить макросы откуда бы то ни было? |
|
>>Алекса просите ;-) >Ну вот, а на форуме он на тебя всю ответственность перекладыает. :) Тогда ждите. У меня сейчас напряги с "на подумать". > Т.е. от идеи переноса макросов в текстовые файлы таки отказались? Будет, но не сейчас. Поэтому предлагается промежуточный вариант - с SQLite. >>> wchar_t *Area; // область макроса >>Зачем? Стартовая область задана в Flags. >А если макро-плагин захочет завести свою область? И как двиг твою область поймет? >Ну и для наглядности, опять же. Для наглядности - это для юзеров, а для АПИ наглядность - это как раз младший байт во флагах. |
|
я наверное чего-то не понимаю... Для чего это добавление затевалось? для MacroLib-а? Но тогда, в предлагаемой реализации смысла оно особо не несет? MacroLib позволяет 1. привязывать макрос к спец.областям Dialog.{Guid}, Dialog.'Title', Editor.'*.fml', и т.д. 2. Назначать не просто "Key", а Down/Up/Release/Double/Hold/Single |
|
Да, Макролиб с тех пор сильно шагнул вперёд. Но никто не мешает и фару подтянуться. И второе: Тут хотят вынести макросы в файлы. Но как по мне, то фар идеологически должен хранить макросы там же, где и всё остальное, т.е. в базе. В противном случае как-то неконсистентно получается: например почему ассоциации не в текстовых файлах? Имхо текстовые файлы хорошо, я бы пользовался, но тогда уж плагином (и необязательно это будет макролиб). |
|
>Сначала макросы в SQLite :) В общем, почти сделал. :) Остались мелочи, типа MSave(), MLoad() День-два погоняю, и ... Куда ? Виш заводить ? |
|
>Виш заводить ? Конечно! |
|
2159 :) |
|
2159 |
|
Константы бы ещё... (вероятно это уже другой тикет) |
|
А кого этот тикет ждёт? |
|
закрываем? |
Date Modified | Username | Field | Change |
---|---|---|---|
2010-08-31 21:01 | max rusov | New Issue | |
2010-08-31 21:08 | JohnDoe | Note Added: 0005737 | |
2010-08-31 21:09 | JohnDoe | Note Edited: 0005737 | |
2010-08-31 21:12 | JohnDoe | Note Edited: 0005737 | |
2010-08-31 21:12 | max rusov | Note Added: 0005738 | |
2010-08-31 21:16 | max rusov | Note Added: 0005739 | |
2010-08-31 21:22 | max rusov | Note Added: 0005740 | |
2010-08-31 21:24 | JohnDoe | Note Added: 0005741 | |
2010-08-31 21:26 | JohnDoe | Note Edited: 0005741 | |
2010-08-31 21:36 | max rusov | Note Added: 0005742 | |
2011-01-12 13:43 | max rusov | Note Added: 0006092 | |
2011-01-12 20:27 | JohnDoe | Note Added: 0006094 | |
2011-01-12 21:08 | max rusov | Note Added: 0006095 | |
2011-01-12 21:38 | JohnDoe | Note Added: 0006097 | |
2011-01-13 09:30 | vskirdin | Note Added: 0006100 | |
2011-01-13 09:31 | vskirdin | Note Edited: 0006100 | |
2011-01-13 10:00 | JohnDoe | Note Added: 0006104 | |
2011-01-13 10:54 | max rusov | Note Added: 0006105 | |
2011-07-04 18:00 | vskirdin | Note Added: 0007235 | |
2011-07-04 22:25 | DAtaMan | Note Added: 0007237 | |
2011-07-05 05:30 | vskirdin | Note Added: 0007238 | |
2011-07-05 09:22 | DAtaMan | Note Added: 0007239 | |
2011-07-05 10:13 | vskirdin | Note Added: 0007240 | |
2011-07-05 11:19 | Yegor | Note Added: 0007241 | |
2011-07-05 11:33 | DAtaMan | Note Added: 0007242 | |
2011-07-05 13:11 | max rusov | Note Added: 0007243 | |
2011-07-05 14:38 | JohnDoe | Note Added: 0007244 | |
2011-07-05 20:49 | vskirdin | Note Added: 0007245 | |
2011-07-21 14:19 | Maximus | Note Added: 0007290 | |
2011-07-21 16:19 | JohnDoe | Note Added: 0007291 | |
2011-07-23 11:43 | DAtaMan | Note Added: 0007299 | |
2011-07-24 00:55 | JohnDoe | Note Added: 0007300 | |
2011-08-23 15:49 | zg | Note Added: 0007511 | |
2012-07-03 10:45 | vskirdin | Note Added: 0009390 | |
2012-07-03 10:45 | vskirdin | Assigned To | => zg |
2012-07-03 10:45 | vskirdin | Status | new => feedback |
2012-07-03 11:44 | JohnDoe | Note Added: 0009393 | |
2013-02-03 00:33 | alexy | Severity | minor => feature |
2013-04-20 13:08 | JohnDoe | Note Added: 0010865 | |
2013-04-20 13:17 | vskirdin | Note Added: 0010867 | |
2014-01-26 09:51 | zg | Build | => 0 |
2014-01-26 09:51 | zg | Status | feedback => closed |
2014-01-26 09:51 | zg | Resolution | open => fixed |
2014-01-26 09:51 | zg | Fixed in Version | => 3.0 |