View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001840 | Wishes | Macro | public | 2011-07-25 05:51 | 2013-02-03 00:33 |
Reporter | DAtaMan | Assigned To | vskirdin | ||
Priority | high | Severity | feature | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | 3.0 | ||||
Fixed in Version | 3.0 | ||||
Summary | 0001840: Macro && DB | ||||
Description | Сохранение(считывание) макросов в(из) DB | ||||
Tags | No tags attached. | ||||
Build | 2291 | ||||
|
|
|
Примечания: 1. Заодно вынес все *func(...) в отдельный файл (если не ошибаюсь, где-то видел эту идею). 2. Экспорт в XML есть, но импорта пока нет, т.к. структура DB может поменяться. 3. Всё, что связано с pluginfunctions, не тестировалось, т.к. многое может поменяться :) 4. Может KMFLAGS_REG_MULTI_SZ уже не нужен ? Хоть один плагин его использует ? 5. По поводу MacroView: может заменить его встроенным редактором макросов (а заодно, и переменных и констант) ? IMHO, это будет проще. |
|
area и key как integer - как-то не фонтан, ибо без искаробочного редактора править нереально. KMFLAGS_REG_MULTI_SZ для бд не нужен, да macro.db => macros.db |
|
>area и key как integer - как-то не фонтан, ибо без искаробочного редактора править нереально. Ну, если они точно не станут знаковыми... А почему нереально править, кстати ? >macro.db => macros.db Назвал так потому, что там всё же не только макросы. Может тогда 'macroconfig' ? |
|
> А почему нереально править, кстати ? Ну вот хочу вручную добавить макрос на F4 в область диалогов. Как догадаться, что F4 - это "65651", а диалоги - это "4"? |
|
Когда будет импорт, будет проще. :) Ещё можно добавить строковое поле для названия клавиши, и если поле с кодом пусто, то автоматом преобразовывать в код и записывать. |
|
При наличии полноценного экспорта/импорта "читабельность" самой бд не существенна, да. Но в xml записям вида area="4" и key="0000000000010073" думаю, не место. Пусть будут всегда нормальные human-readable строки. Флаги тоже, наверное, лучше разворачивать. |
|
Наверное, всё-таки надо каждому макросу назначать Id. Тогда Area можно убрать, а флаги писать целиком, как есть. Может и переменным/константам Id тоже нужен. Может их и в одну таблицу писать ? Мдя, стрижка только началась. |
|
"Area" по любаси нужна, т.к. ОНО обозначает "откуда стартовать". |
|
>"Area" по любаси нужна... Не понял. Я про поле "Area" в БД. То есть будет примерно так: id │ key │ flags │ sequence │ description Ну и в MacroRecord тоже Id добавить. Ещё подумал, может сделать возможность задавать макросу несколько областей, в виде флагов ? Тогда из многих макросов изчезнут If(Editor || ...) Не ? |
|
>задавать макросу несколько областей, в виде флагов Несколько областей можно задать точно так же строкой, а не флагами. |
|
>Несколько областей можно задать точно так же строкой Я о внутреннем представлении. А визуально это могут быть галочки в листбоксе или чекбоксы (но их будет много). |
|
Если уж думаете в эту сторону, то не забудьте о возможности привязки макросов к конкретным диалогам, по GUID. |
|
>Если уж думаете в эту сторону Я-то думаю, но... :) Но это, наверняка, тема для отдельного виша (а то и для темы-голосовалки на форуме) |
|
Такой формат для экспорта/импорта годится ? <keymacros> <area name="Shell"> <key name="Up"> <field name="sequence" value="Up Up"/> <field name="description" value="2 раза вверх"/> <flags> <flag name="DisableOutput" value="1"/> <flag name="Selection" value="1"/> <flag name="NoSendKeysToPlugins" value="1"/> </flags> </key> ... </area> ... </keymacros> |
|
> name="sequence" как мультилайн и всякие \n & < > будут выглядеть? |
|
\n без изменений " & < > как принято в XML. tinyxml сама конвертит. А вот с мультилайн непонятно. Как его вводить ? Upd: Движок Мантиса слишком умный. :) |
|
> А вот с мультилайн непонятно. Как его вводить ? CDATA? (у меня дежавю :) ) |
|
>> А вот с мультилайн непонятно. Как его вводить ? > CDATA? Да нет, в диалоге по CtrlShift. (пока "допиленного" DialogTools нет) >у меня дежавю :) По поводу чего ? UPD: В общем, экспортируется в виде амперсанд#x0A |
|
А может покомпактнее? <flags DisableOutput="1" Selection="1" NoSendKeysToPlugins="1"/> <sequence>Up Up</sequence> P.S. sequence в CDATA наверно P.P.S. И может не стоит макросы группировать по областям/клавишам? Пусть все будут равны, но в каждом указана область (потенциально не одна) Впрочем, тут возникает проблема уникальности имён... Но она рано или поздно всё равно возникнет. |
|
Чем тебя старый DialogTools не устраивает? |
|
>И может не стоит макросы группировать по областям/клавишам? Да, пожалуй. Будет достаточно сортировки по области. >Чем тебя старый DialogTools не устраивает? Тем, что пока не работает под враппером, а новый не компилируется. |
|
Все бы собралось, если чуть проект допилить |
|
>Да, пожалуй. Будет достаточно сортировки по области. В идеале бы убрать группировку по области. |
|
А еще бы снять ограничение имя=сочетанию_клавиш. |
|
разжуй |
|
сейчас макрос может иметь название равное сочетанию клавиш его вызывающее (например AltBS) или искуственное (например Alt10000), при наличии макрокоманды eval("кнопкосочетание", 2) иногда трудно вспомнить что-же висело на этом "кнопкосочетании" приходится закрывать редактор(а он модальный :( ) и лезть смотреть что там за макрос... есть конечно vars которым можно дать осмысленные названия, но к ним из макровью не долезешь и, как я понимаю, они компилятся каждый раз при вызове в отличии от обычного макроса компилируемого при старте. Если бы имя макроса могло быть произвольным то например макрос смены диска с сохранением пометок: eval("AltM",2) AltF1 превратился в eval("SaveSelectionFiles",2) AltF1, имхо, удобнее... |
|
>В идеале бы убрать группировку по области. Пока так: <keymacros> <macro> <area name="Shell" /> <key name="Up" /> <sequence> <![CDATA[Up Up]]> </sequence> <description> <![CDATA[Вверх]]> </description> </macro> ..... </keymacros> Годится? P.S. С флагами отдельная грустная песня. |
|
2SUSim В текущей реализации коды клавиш пишутся в базу как коды :) Плюс - быстрая загрузка макросов из DB. |
|
А напомните, зачем там CDATA, из-за мултилайна? Его нельзя через \n как-то передавать? |
|
Ага, из-за мултилайна. А если в тексте макроса используется \n? Или \r\n? Парсить в configdb? |
|
Если в строковых литералах макроса используются управляющие последовательности, то при экспорте их надо экранировать обратным слешем (в *.reg всегда так и было). Неэкранированные в этом случае будут относиться к самому строковому представлению макроса. |
|
Хотя не факт, что это лучше, да. |
|
>А напомните, зачем там CDATA, из-за мултилайна? Не только: & (&), < (<), > (>), ' (') и " (") — последние две полезны для записи разделителей внутри значений атрибутов. P.S. CDATA ведь можно сделать не обязательным? |
|
> eval("SaveSelectionFiles",2) AltF1, имхо, удобнее... "– Помыслил, может, им знаком Просперо?" (Дэн Симмонс, Илион) Имхо удобнее будет вот когда: 1. Клавишам - клавишное, т.е. оставляем как сейчас 2. "SaveSelectionFiles" - это будет функция в разделе Func 3. Вместо eval("SaveSelectionFiles",2) AltF1 пишем SaveSelectionFiles() AltF1 4. Юзеровские функции (не в плагинах) допилю, пока будут без параметров и без возвратов (хотя и здесь можно придумать, скажем ввести оператор return) |
|
Если макросы все-таки планируется развивать - то очень советую сделать как в MacroLib - возможность привязки макроса к произвольному количеству обастей/клавиш. Т.е. сделать Area и Key строковыми атрибутами макроса. Потом менять форматы будет сложнее. |
|
> Т.е. сделать Area и Key строковыми атрибутами макроса Именно так и предлагается автором тикета чуть выше: http://bugs.farmanager.com/view.php?id=1840#c7358 |
|
Да, не заметил, извините. Только как то очень громоздко. Почему бы не упростить? <keymacros> <macro area="Shell" key="Up" description="Вверх"> <![CDATA[Up Up]]> </macro> ... </keymacros> |
|
Потенциально и area, и key могут иметь более одного значения, а description может быть многострочным. Не думаю, что запись "в кучу" что-то упрощает. Разве что сделать оба варианта записи равнозначными. |
|
Много значений - никаких проблем, разделять пробелами. Упрощает - если редактировать вручную. |
|
В таком случае идеально было бы сделать оба варианта равнозначными для импорта. А экспортировать можно и развёрнуто. |
|
Зачем два, когда можно - один? |
|
Все мои аргументы уже изложены выше, могу только разжевать. Когда параметры расположены в строчку - их сложнее найти, потому что приходится визуально сканировать каждую строку полностью. Не говоря о том что строка получается длинной и может не умещаться на экране. Если XML предназначен не только для машины, то строчки весьма желательны короткие. |
|
Спорно. Рассмотрим XML запись простого fml макроса, например этого: http://far-macro-library.googlecode.com/svn/trunk/Common/AltScreens.fml "Сокращенная" форма: <macro area="Shell Editor Viewer" key="Alt1 Alt2 Alt3 Alt4 Alt5 Alt6 Alt7 Alt8 Alt9 Alt0" description="Use Alt-Digit to switch between screens"> <![CDATA[ %s = Key(#AKey); %c = substr(%s, len(%s) - 1, 1); F12 $If ( CheckHotkey (%c) ) eval(%c) $Else Esc eval(%s) $End ]]> </macro> "Полная" форма: <macro> <area name="Shell" /> <area name="Editor" /> <area name="Viewer" /> <key name="Alt1" /> <key name="Alt2" /> <key name="Alt3" /> <key name="Alt4" /> <key name="Alt5" /> <key name="Alt6" /> <key name="Alt7" /> <key name="Alt8" /> <key name="Alt9" /> <key name="Alt0" /> <description> <![CDATA[Use Alt-Digit to switch between screens]]> </description> <sequence> <![CDATA[ %s = Key(#AKey); %c = substr(%s, len(%s) - 1, 1); F12 $If ( CheckHotkey (%c) ) eval(%c) $Else Esc eval(%s) $End ]]> </sequence> </macro> Как раз для человека, мне кажется, первый вариант предпочтительней. |
|
Не надо утрировать до такой степени. Для Area - одна строка Для Key - одна строка <macro> <area>Shell Editor Viewer</area> <key>Alt1 Alt2 Alt3 Alt4 Alt5 Alt6 Alt7 Alt8 Alt9 Alt0</key> <description>Use Alt-Digit to switch between screens</description> <sequence> <![CDATA[ %s = Key(#AKey); %c = substr(%s, len(%s) - 1, 1); F12 $If ( CheckHotkey (%c) ) eval(%c) $Else Esc eval(%s) $End ]]> </sequence> </macro> P.S. Это в общем мало чем отличается от вашего сокращённого. Если при экспорте фар отформатирует как у вас - этого для человека будет достаточно. При условии что работать с этим мы будем только средствами фара. |
|
По моему нет никакого смысла записывать что-то тэгом, если это прекрасно записывается атрибутом. Впрочем - более спорить не буду, делайте как хотите. |
|
В значениях атрибутов нельзя использовать неэкранированные сущности, даже кавычки/апострофы (актуально для key). CDATA нельзя использовать внутри атрибутов (актуально для description). И чтобы атрибуты отформатировать так человекоориентированно как в вашем "сокращённом" - вероятно нужна дополнительная обработка (врядли стандартные библиотеки это делают, но пусть специалисты меня поправят) |
|
> В значениях атрибутов нельзя использовать неэкранированные кавычки/апострофы (актуально для key). Но при этом придется экранировать другие символы - шило на мыло. >CDATA нельзя использовать внутри атрибутов (актуально для description). Я бы не сказал, что это очень актуально. Вероятность, что в описании макроса встретятся символы требующие экранирования очень мала, от конструкции "<![CDATA[...]]>" - читаемость страдает гораздо больше. |
|
>Но при этом придется экранировать другие символы - шило на мыло. О каких других символах речь? >Вероятность, что в описании макроса встретятся символы требующие экранирования очень мала Разве?? У меня в 99% макросов содержится что-либо из набора <>&'" P.S. Возможно конструкцию <![CDATA[...]]> можно сделать опциональной, т.е. использовать только там где необходимо. |
|
> О каких других символах речь? "<", ">", "&" - их придется экранировать: Alt> Или использовать CDATA. >Разве?? У меня в 99% макросов содержится что-либо из набора <>&'" В _описании_ ? Про текст макропоследовательности - я не спорю. |
|
> "<", ">", "&" - их придется экранировать: Alt> Или использовать CDATA. - в атрибутах необходимо экранировать <>&'" - в тегах необходимо экранировать <>& Очевидно, что в тегах экранировать придётся немного меньше, а при использовании CDATA - не придётся практически ничего. (в атрибутах же использование CDATA не допускается) Впрочем, можно конечно рассмотреть возможность создания собственного XSD, где будет разрешено CDATA для атрибутов... >В _описании_ ? В описании вероятность встретить "сущности" конечно меньше. Но те что всё-же встретяться - приятнее в CDATA. И не забываем о потенциальной возможности многострочных описаний. |
|
Подчеркну, что CDATA это не особый тип данных, а по сути всего лишь директива для парсера "не искать в этом разделе разметку". При редактировании XML руками никто не навязывает использовать CDATA. Тем не менее, может оказаться хорошим тоном использовать его всегда (именно в sequence): это защитит от случайных ошибок. |
|
> - в атрибутах необходимо экранировать <>&'" Вроде бы экранировать < > ' - не обязательно. |
|
>Вроде бы экранировать < > ' - не обязательно. Это не совсем так, но в любом случае: как ни крути, а в значениях атрибутов ограничений больше. --- А вот ещё вопрос ко всем: все эти пляски вокруг сущностей... Может сделать импорт/экспорт в формат Macrolib? Плюсы: проще в редактировании, не множатся форматы Минусы: вместо использования стандартных библиотек придётся изобретать свой велосипед ? |
|
Я то вообще не понимаю зачем пихать макросы в БД. Кроме геморроя это ничего не дает... |
|
Парсер типа macrolib - это по сути велосипед. Использовать велосипед в одном месте, и полнофункциональные базы данных во всех других местах как-то непоследовательно. Я вот хочу ассоциации в файле, кто-то ещё - другие настройки в файле. Возникает вопрос нафига нам тогда база данных? ... И в чём вы видите геморрой? Всё будет в базе данных, как по сути и сейчас. Т.е. со стороны фара минимальные изменения, т.е. минимальный геморрой. |
|
С моей точки зрения есть принципиальная разница между макросами и всеми остальными настройками. Макросы - это программы, скрипты. Программы пишутся в текстовом редакторе и хранятся в файлах, иного я не признаю. > И в чём вы видите геморрой? Всё будет в базе данных, как по сути и сейчас. Вот сейчас - и есть геморрой. А будет еще больше. > Возникает вопрос нафига нам тогда база данных? Это хороший вопрос, но здесь - offtopic. |
|
Тогда требуется доп. апи для доставания макросов из плагина. |
|
>Вот сейчас - и есть геморрой. Переделывать всё заново - ещё больший геморрой. Переделывать надо, только как по мне, то начать надо с другой стороны. Я вот за то чтобы работа макросов максимально приблизилась к тому что умеет Macrolib. А как оно при этом там хранится - вопрос десятый. Не проблема ведь загружать плагином из файла, да? |
|
Э, народ, а кто мешает импорт/экспорт делать не в xml, а, скажем в том же формате, с каким работает плагин? > Тогда требуется доп. апи для доставания макросов из плагина. что есть "доставания макросов из плагина"? Что на счет моего предложения http://bugs.farmanager.com/view.php?id=1840#c7365 (правда это наверное не в этом тикете, но все же) |
|
> А как оно при этом там хранится - вопрос десятый. Вот с этим я принципиально не согласен. Вопрос формата хранения - самый важный, потому что от неудачного выбранного формата все оставшееся время будут страдать все. Возможности можно наращивать от версии к версии, а вот формат уже так просто не поменяешь... |
|
>(правда это наверное не в этом тикете, но все же) Давайте не здесь, потому что потеряется ведь: и так уже понаписали всякого. >от неудачного выбранного формата все оставшееся время будут страдать все В том-то и дело, сейчас не происходит никакой смены формата: как было, так и остаётся. Другой вопрос, если вы призываете его прямо сейчас революционно сменить. Предлагаю для начала принять формат экспорта/импорта устраивающий всех (Macrolib). После чего уже обсуждать чем нас не устраивает фактический формат хранения в базе. Полагаю, в этом тикете это уже офтопик, а на форуме будет самый раз, и намного удобнее. |
|
Здесь обсуждаем необходимость смены представления макросов в базе, и возможный отказ от хранения в базе (в пользу файлов): http://forum.farmanager.com/viewtopic.php?f=15&t=6561 |
|
> Макросы - это программы, скрипты. Программы пишутся в текстовом редакторе и хранятся в файлах, иного я не признаю. А вот "Esc = CtrlO" - это программа или скрипт? > Предлагаю для начала принять формат экспорта/импорта устраивающий всех (Macrolib). Основная проблема с форматом Macrolib - необходимость писать парсер, что, насколько мне известно, никого не вдохновляет. |
|
> необходимость писать парсер, что, насколько мне известно, никого не вдохновляет. ну, если автор Macrolib сподобится на патч - тут можно подумать... ;-) |
|
Что-то все заглохло... Предлагаю актуализировать патч на последние сорцы и применить его (с предварительным анализом) Допиливать импорт/экспорт будем потом - на крайний случае есть куча г-на по управлению sqlite-баз (минималистичный вариант - sqlite.exe). |
|
>Предлагаю актуализировать патч на последние сорцы и применить его (с предварительным анализом) Ok, но я надеялся на развитие макродвига (начало же уже положено, небольшое). Или это потом? :) 1. Макрофункции в отдельные файлы выносить? 2. Экспорт/импорт вообще (даже пустышки) не интегрировать? 3. Что решили с редактором макросов? |
|
1), 2) и 3) это отдельные задачи, которые можно решить и после. Или нет? |
|
Давайте сделаем первый шаг - повторим в sqlite структуру реестра для макросов. А потом уже будем думать/обсуждать/строить планы/etc что будет вторым/третьим/etc шагом. Это к тому, что так движение получится быстрее (когда что-то будет сломано ;-))) |
|
Угу, главное - двигаться :) А что по 1 и 2? И есть предложение заменить "void* Id" в MacroRecord на "__int64 Id" |
|
up |
|
а чем void не устраивает? |
|
2274. |
|
имеет смысл имена назначенных клавиш и имена областей не числами в базе держать, а именами |
|
смысл "имена вместо чисел": 1. проще программно контролировать значения 2. удобство работы с базой :-) К тому же Флаги уже именами сделаны! |
|
3. Потенциально увеличивает шанс портируемости. |
|
в xml уже и так всё именами. надо ли хранить в базе в строковом представлении - я хз, потенциально это медленнее, т.к. больше преобразований при каждом старте, но возможно, это сущие копейки. Вот бы померял кто. |
|
Надо! Кто сказал, что завтра AltF10 == 0x02000000+0x00010000+VK_F10? А если я области перетусую? На счет медленно - в реестре все было символьно :-) В Базе area, key & flags должны быть строками. без кодов. CREATE TABLE IF NOT EXISTS key_macros(area TEXT NOT NULL, key TEXT NOT NULL, flags TEXT, sequence TEXT, description TEXT, PRIMARY KEY (area, key)); CREATE TABLE IF NOT EXISTS plugin_functions(plugin_guid TEXT NOT NULL, function_name TEXT NOT NULL, nparam INTEGER NOT NULL, oparam INTEGER NOT NULL, flags TEXT, sequence TEXT, syntax TEXT NOT NULL, description TEXT, PRIMARY KEY (plugin_guid, function_name)); Здесь у flags убран NOT NULL, т.к. флагов может и не быть. |
|
переделал. коммитить? (пред.базу macros.db нужно удалить) |
|
Так... я так думаю этот тикет можно переводить в решенные. Основное (идея) отработано. Прочие глюки - отдельными Инцами. Иные мнения есть? |
Date Modified | Username | Field | Change |
---|---|---|---|
2011-07-25 05:51 | DAtaMan | New Issue | |
2011-07-25 05:51 | DAtaMan | File Added: Macro&&DB.7z | |
2011-07-25 05:51 | DAtaMan | Note Added: 0007309 | |
2011-07-25 07:00 | DrKnS | Note Added: 0007310 | |
2011-07-25 10:51 | DAtaMan | Note Added: 0007311 | |
2011-07-25 10:58 | DrKnS | Note Added: 0007312 | |
2011-07-25 11:58 | DAtaMan | Note Added: 0007313 | |
2011-07-25 12:12 | DrKnS | Note Added: 0007314 | |
2011-07-25 13:17 | DAtaMan | Note Added: 0007316 | |
2011-07-25 20:32 | vskirdin | Note Added: 0007322 | |
2011-07-25 21:09 | DAtaMan | Note Added: 0007323 | |
2011-07-27 08:53 | JohnDoe | Note Added: 0007325 | |
2011-07-27 12:30 | DAtaMan | Note Added: 0007326 | |
2011-07-27 14:00 | max rusov | Note Added: 0007327 | |
2011-07-28 18:05 | DAtaMan | Note Added: 0007330 | |
2011-07-28 18:06 | DAtaMan | Note Added: 0007331 | |
2011-07-28 18:56 | vskirdin | Note Added: 0007332 | |
2011-07-28 19:20 | DAtaMan | Note Added: 0007333 | |
2011-07-28 19:34 | DAtaMan | Note Edited: 0007333 | |
2011-07-28 21:12 | max rusov | Note Added: 0007334 | |
2011-07-28 22:12 | DAtaMan | Note Added: 0007335 | |
2011-07-28 22:46 | DAtaMan | Note Edited: 0007335 | |
2011-07-29 11:32 | JohnDoe | Note Added: 0007336 | |
2011-07-29 11:32 | Maximus | Note Added: 0007337 | |
2011-07-29 11:33 | JohnDoe | Note Edited: 0007336 | |
2011-07-29 11:36 | JohnDoe | Note Edited: 0007336 | |
2011-07-29 11:37 | JohnDoe | Note Edited: 0007336 | |
2011-07-29 13:13 | DAtaMan | Note Added: 0007338 | |
2011-07-29 22:39 | Maximus | Note Added: 0007339 | |
2011-07-30 17:19 | JohnDoe | Note Added: 0007340 | |
2011-08-03 05:14 | SUSim | Note Added: 0007355 | |
2011-08-03 06:03 | vskirdin | Note Added: 0007356 | |
2011-08-03 06:35 | SUSim | Note Added: 0007357 | |
2011-08-03 06:43 | DAtaMan | Note Added: 0007358 | |
2011-08-03 06:46 | DAtaMan | Note Added: 0007359 | |
2011-08-03 06:48 | DrKnS | Note Added: 0007360 | |
2011-08-03 07:39 | DAtaMan | Note Added: 0007361 | |
2011-08-03 07:59 | DrKnS | Note Added: 0007362 | |
2011-08-03 08:01 | DrKnS | Note View State: 0007360: private | |
2011-08-03 08:01 | DrKnS | Note View State: 0007360: public | |
2011-08-03 08:06 | DrKnS | Note Added: 0007363 | |
2011-08-03 09:04 | JohnDoe | Note Added: 0007364 | |
2011-08-03 09:22 | JohnDoe | Note Edited: 0007364 | |
2011-08-03 09:35 | JohnDoe | Note Edited: 0007364 | |
2011-08-03 09:52 | vskirdin | Note Added: 0007365 | |
2011-08-03 10:19 | max rusov | Note Added: 0007366 | |
2011-08-03 10:26 | JohnDoe | Note Added: 0007367 | |
2011-08-03 10:35 | max rusov | Note Added: 0007368 | |
2011-08-03 10:51 | JohnDoe | Note Added: 0007369 | |
2011-08-03 11:00 | max rusov | Note Added: 0007370 | |
2011-08-03 11:10 | JohnDoe | Note Added: 0007371 | |
2011-08-03 11:11 | max rusov | Note Added: 0007372 | |
2011-08-03 11:35 | JohnDoe | Note Added: 0007373 | |
2011-08-03 11:36 | JohnDoe | Note Edited: 0007364 | |
2011-08-03 12:13 | max rusov | Note Added: 0007374 | |
2011-08-03 12:31 | JohnDoe | Note Added: 0007375 | |
2011-08-03 12:35 | JohnDoe | Note Edited: 0007375 | |
2011-08-03 12:36 | max rusov | Note Added: 0007376 | |
2011-08-03 12:52 | JohnDoe | Note Added: 0007377 | |
2011-08-03 13:03 | JohnDoe | Note Edited: 0007377 | |
2011-08-03 13:08 | JohnDoe | Note Edited: 0007375 | |
2011-08-03 13:08 | JohnDoe | Note Edited: 0007375 | |
2011-08-03 13:11 | max rusov | Note Added: 0007378 | |
2011-08-03 13:13 | max rusov | Note Edited: 0007378 | |
2011-08-03 13:15 | max rusov | Note Edited: 0007378 | |
2011-08-03 13:18 | JohnDoe | Note Added: 0007379 | |
2011-08-03 13:20 | JohnDoe | Note Edited: 0007379 | |
2011-08-03 13:29 | max rusov | Note Added: 0007380 | |
2011-08-03 13:30 | max rusov | Note Edited: 0007380 | |
2011-08-03 13:37 | JohnDoe | Note Added: 0007381 | |
2011-08-03 13:39 | JohnDoe | Note Edited: 0007381 | |
2011-08-03 13:42 | JohnDoe | Note Edited: 0007381 | |
2011-08-03 13:45 | JohnDoe | Note Edited: 0007381 | |
2011-08-03 13:47 | JohnDoe | Note Added: 0007382 | |
2011-08-03 13:49 | JohnDoe | Note Edited: 0007381 | |
2011-08-03 13:51 | max rusov | Note Added: 0007383 | |
2011-08-03 13:54 | JohnDoe | Note Added: 0007384 | |
2011-08-03 13:58 | max rusov | Note Added: 0007385 | |
2011-08-03 14:00 | JohnDoe | Note Edited: 0007381 | |
2011-08-03 14:06 | JohnDoe | Note Added: 0007386 | |
2011-08-03 14:16 | max rusov | Note Added: 0007387 | |
2011-08-03 14:33 | Denis | Note Added: 0007388 | |
2011-08-03 14:39 | JohnDoe | Note Added: 0007389 | |
2011-08-03 14:42 | JohnDoe | Note Edited: 0007389 | |
2011-08-03 14:44 | JohnDoe | Note Edited: 0007389 | |
2011-08-03 14:48 | JohnDoe | Note Edited: 0007384 | |
2011-08-03 14:54 | vskirdin | Note Added: 0007390 | |
2011-08-03 14:55 | max rusov | Note Added: 0007391 | |
2011-08-03 15:14 | JohnDoe | Note Added: 0007393 | |
2011-08-03 15:19 | JohnDoe | Note Added: 0007394 | |
2011-08-03 16:49 | DrKnS | Note Added: 0007395 | |
2011-08-03 21:30 | vskirdin | Note Added: 0007398 | |
2011-09-01 11:17 | vskirdin | Note Added: 0007587 | |
2011-09-01 12:33 | DAtaMan | Note Added: 0007589 | |
2011-09-01 12:45 | JohnDoe | Note Added: 0007590 | |
2011-09-01 13:56 | vskirdin | Note Added: 0007593 | |
2011-09-01 15:15 | DAtaMan | Note Added: 0007595 | |
2011-10-21 06:16 | DrKnS | Note Added: 0007941 | |
2011-10-21 06:58 | vskirdin | Note Added: 0007942 | |
2011-12-02 20:13 | DrKnS | Note Added: 0008038 | |
2011-12-02 20:13 | DrKnS | Status | new => feedback |
2011-12-04 12:27 | vskirdin | Note Added: 0008051 | |
2011-12-06 08:05 | vskirdin | Note Added: 0008060 | |
2011-12-06 10:13 | max rusov | Note Added: 0008061 | |
2011-12-06 10:50 | DrKnS | Note Added: 0008062 | |
2011-12-06 11:27 | vskirdin | Note Added: 0008063 | |
2011-12-06 11:30 | vskirdin | Note Edited: 0008063 | |
2011-12-06 12:12 | vskirdin | Note Added: 0008064 | |
2011-12-08 13:24 | vskirdin | Note Added: 0008099 | |
2011-12-23 08:26 | alexy | Build | => 2291 |
2011-12-23 08:26 | alexy | Status | feedback => closed |
2011-12-23 08:26 | alexy | Assigned To | => vskirdin |
2011-12-23 08:26 | alexy | Resolution | open => fixed |
2011-12-23 08:26 | alexy | Fixed in Version | => 3.0 |
2013-02-03 00:33 | alexy | Severity | major => feature |