freepascal.ru

Есть очень интересная на мой взгляд идея : Альтернативная графическая среда быстрой разработки программ MidelAsm на подобие HiAsm ( смотри Hiasm.com) но более отрытая с полной ДВУНАПРАВЛЕННОЙ конверсий
Алгоритмическая схема -> исходный текст на ЯВУ и
исходный текст на ЯВУ -> Алгоритмическая схема

Так чтобы любая конструкция языка имела графическое представление и любой элемент схемы имел отражение в исходном тексте ...

В ХайАсме слишком много механизмов недоступных для изучения или устроенных непрозрачно с заточкой именно под использование в виде части графической схемы..
Генерируемые ХайАсмом коды в ЯВУ практически не читаемы.

Но если все будет прозрачно "сверху донизу" то можно будет использовать как достоинства крупно блочной наглядности ХайАсма и возможность корректировать любой участок исходного кода не теряя доступа к редактированию в форме схемы ...

Эдакий "корпускулярно-волновой" дуализм в приложении к программированию
Сейчас проект на стадии детальной проработки концепта.
Но уже скоро примусь за программирование редактора алгоритмов...

Если кого-то идеи заинтересуют пишите приму советы и буду рад обсуждению !

ЗЫ
В дальнейшем можно использовать конверсию одних и тех же схем-алгоритмов в разные языки программирования (и их диалекты ) и легко переводить исходники с одних ЯВУ на другие (Любые конструкции в разных языках можно представить как алгоритмическую схему и наоборот А если выразительных средств конкретного языка окажется недостаточно то ИМХО его почти всегда можно дополнить "библиотекой совместимости" )

Зы Зы
Писать основу буду разумеется в Лазарусе...

------------------------------------------------------------------------------------
21.03.2016
Текущий статус "ПОЛУКОНСЕРВАЦИЯ "
Первый модуль в "исследовательском исполнении "
"Редактор графических примитивов" доведен до версии 9.4.2.7 ...
11 действующих инструментов 22 скирпта + дополняемый "клипарт" + дополнительный "командно административный" интерфейс




Подробности и загрузки в конце темы ...

Планы конечно интересные и серьезные. Я надеюсь вы осознаете, какой обьем работ на себя берете?
Желаю успехов в этом начинании и буду с интересом следить за проектом.

На самом деле объем не настолько большой как это может показаться

Всего в простейшем случае там будет всего три основных блока :
1 Простейший векторный редактор с возможностью создавать свою клип-арт библиотеку
2 Модуль Pas2Alg
3 Модуль Alg2Pas

Разумеется для развития проекта понадобится еще несколько модулей, но поскольку я
намерен прямо переносить в алгоритмические схемы все конструкции языка НАПРЯМУЮ и без специальных классов посредников ( как это сделано в Хайасме ), а макро уровень готовых макросов-элементов вводить на уровне открытых контейнеров
("Микро-схем" ) без "водораздела" (тут схема, тут исходный текст элемента, а тут скрытые внутренние механизмы кодо-генерации) то все будет значительно проще...

Без классов понадобиться всего с десяток базовых конструкций .

1 Программа (С секциями констант типов переменных )
2 Модуль (-//-)
3 функции-процедуры (-//-)
4 Операторы ветвлений и циклов
6 контейнеры "Begin/end"
7 Оператор ":=" ( А формулы мат действий не разбирать "на запчасти" - считаю "разборку формул" одним из самых больших просчетов ХайАсма...)


Ну и главное везде где разработчику покажется удобным можно вставить include вставку кода прямо в схему алгоритма .... (Что кстати решает вопрос с неполным описанием языка при прямой и обратной трансляции )

Само собой понадобится отдельный модуль визуального дизайна форм но я и тут не вижу особых проблем (еще в мохнатые 90-е делал дизайнеры для турбовижин )

Дополнительная информация о расположении элементов на схеме-алгоритме вводится
виде комментариев или в виде отдельного опционального ини-файла

Да и классы водятся без особых проблем

Дело пошло !
Концепция более или мнение утрясается начал "пилить редактор"

В хай-асме связи "хода операций" являются одновременно потоками данных
я же пока решил разделить потоки данных и ход выполнения алгоритма
(фишка ХайАсма достаточно оригинальная но есть постоянная угроза "паразитических рекурсивных связей" - кратко не объяснишь разве что послать разбирать код генерируемый ХайАсмом ( глядя на вроде бы предельно ясные схемы легко забыть
о методах их реализации в коде на ЯВУ сложность которого нарастет чуть ли не по экспоненте при усложнении схемы )

Возможно в дальнейшем будет что-то похожее на "вертикали" хайасма
( Для наглядности при передачи данных )
Но скорее всего пока будут просто секции в описании "контейнеров" процедур модулей и т.п.


LCL или КОL - приложения будут сдаваться в отдельной суб-среде ...
Думаю для простоты не использовать ресурсы лазаруса(описание форм и тд ) генерируя динамический код . Пока не представляю как можно получить ясную схему-алгоритм из готовой LCL-программы Но обратная трансляции ALG2PAS все-же скорее в основном для кода сгенерированного самим МидАсмом...


Зы
На днях подготовлю более подробную доку и возможно выложу первые наработки
чтоб обсуждение было более конкретным

Alex2013 писал(а):Пока не представляю как можно получить ясную схему-алгоритм из готовой LCL-программы

Все гениальное просто. Три блока: начало, конец, в середине один большой инклуд

Ну что-то да будет не применено! Уже сейчас начал клепать редактор схем
(Но есть несколько заказных проектов так, что МидАсм пока делаю в "идлэ моде" то есть при наличии вдохновения и времени - хотя есть надежда что его помощью получу свободу для первого и экономию для второго )

И так лед тронулся !
Векторный редактор MA_Red уже что-то рисует ....
Хотя "нулевые" версии годятся обычно разве что на воспоминания "как это было"
Однако, появилось хоть, что-то что можно выложить тут ...

Что может быть интересно уже сейчас?
1 Возможность поиграется со скриптами и ини файлом
2 Дополнить набор инструментов всем что можно нарисовать прямыми черными линиями ....
(Записи и чтения пока нет но приладить дело10-15 минут) ..
Формат скриптов меняется скорее всего не будет...
А вот вид "междуморды" редактора вне всяких сомнении будет!

Исходники пока не выкладываю потому что нужно хотя-бы немного их "причесать"
Да и вообще есть сомнения в целесообразности (У семи нянек...)
Другое дело скрипты плагины и тд ....

Рисует так левой кнопкой мыши выбрать инструмент потом ей же ткнуть два раза в поле редактора и закрепить нажатием правой кнопки ...

Приму любой конструктив !(Советы вопросы замечания )

Скачать

Добавлено спустя 22 часа 37 минут 20 секунд:
Как обещал отправляю новую версию
Работает запись и чтение картинки
пример DRV.Lst

Качать тут
Зы
Если кому-то действительно интересно могу выложить полный исходник
включая дельфийскую DLL (там фриварная библиотека поддержки скриптов которую мне пока не удалось портировать в лазарус )

Сразу пару мыслей подкину, так как недавно делал визуальный редактор.
1) Сразу продумайте интерфейс компонентов, как они взаимодействуют и какая от них требуется логика.
2) Property Editor - рекомендую Virtual Treeview заюзать.. наиболее беспроблемно.
3) Отрисовку фона делать не единожды, а в онпаинте. При перерисовке сетка исчезает.
4) Линия - первый тык получили координаты начала, по таймеру отрисовываем от координат начала до координат мыши, второй тык - таймер сдох, линия отрисована и сохранена во внутренних данных.

А так - смотреть пока особо нечего.

Добавлено спустя 3 минуты 59 секунд:
ЗЫ. и сериализуйте вы данные массово.. В тот же json например. Юниты fpjson,fpjsonrtti,jsonparser. Замечательно можно сериализовать и десериализовать обьекты в текст (если дописать функционал обьектов). Хотя проперти простых типов и так здорово обрабатывает.

Видимо действительно нужно выложить исходник или хотя бы его часть ...
1 Перерисовка идет и по таймеру (для прорисовке при запуске) и по OnPaint
Правда еще действительно не все отлажено ...
В рабочей версии скорее всего будет буферизация для "мгновенной" перерисовки векторной графики

2 Все интересное что пока есть в проекте сводится к возможности описывать новые инструменты
не меняя исходного кода и без компиляции через скрипт (смотри файлы с расширением *,PS )- причем что интересно, скрипт пишется на диалекте паскаля близкого к лазарусу или дельфи ...
(Такая возможность есть далеко не у всех профессиональных редакторов )

3 Мой принцип в программировании как можно меньше не стандартных библиотек ( особенно если они не мной написаны ) Иногда например при написании проекта с БД получается чуть грубовато но зато я полностью понимаю все механизмы ее работы ... Что тем более важно если дело касается не коммерческого проекта где нет сроков исполнения

4 Пока действительно занят только векторным редактором для создания графической библиотеки образов-элементов визуальной части схем-алгоритмов так что детальная разработка взаимодействия объектов-классов-элементов пока дело будущего

>>Alex2013
Тоже делаю векторный редактор. пара советов:
1) если планируется большой объем векторных данных лучше сразу озаботится о их хранении и обработке с пространственным разбиением
2) сразу продумать механизм ундо\редо
3) перерисовка по таймеру? почему не в mousemove?
4) перерисовывать всё "средствами векторной графики" довольно медленно. на туже резиновую линию можно запомнить картинку до начала рисования, выводить ее фоном и сверху рисовать резиновую линию. Запоминать картинку естественно не в TBitmap, а в чтонибудь побыстрее.

>>B4rr4cuda
>>по таймеру отрисовываем от координат начала до координат мыши
Зачем тут таймер? прекрасно делается в mousemove

zub писал(а):Зачем тут таймер? прекрасно делается в mousemove

Ибо мышь может выйти за границы формы - раз. Может быть завершена отрисовка кликом на другом компоненте - два.
У вас просто векторный редактор и все на одной канве отрисовывается. В случае подобного редактора - на основном поле могут валяться и другие компоненты. И mousemove тут уж не особо помогает.

Ибо мышь может выйти за границы формы - раз. Может быть завершена отрисовка кликом на другом компоненте - два.
У вас просто векторный редактор и все на одной канве отрисовывается. В случае подобного редактора - на основном поле могут валяться и другие компоненты. И mousemove тут уж не особо помогает.

ЛЦЛ компоненты на канвасе? Гораздо проще соорудить нужные компоненты в рамках своего векторного движка, чем вживить в него ЛЦЛ компоненты. Даже если так, сомневаюсь в необходимости рисовать чтото когда мышка ушла за пределы канваса или перешла на другой контрол.

Прямо притча "о трех спецах" получается ...
В общем во первых я завтра выложу исходник ...

Во вторых таймер для первой прорисовки поля редактора ..
(Почему то OnPaint не сработал в первый раз. )
Да разумеется я использую OnMouseDown (от куда бы я без WinApi положение курсора узнал )

В третьих я не думаю что стадии разработки концепта стоит особо заморачивается с оптимизаций скорости прорисовки По этому пока только канвас И опять же я не редактор ради редактора пишу ...
А как часть конструктора алгоритмов . От сюда сразу упор на скриты и столь "топорная" прорисовка
Зы
Я уже несколько новых инструментов в скрипты затолкал ..
Как то ожидал что именно это часть вызовет интерес
ведь уже даже у выложенных версий можно добавить в обойму
инструментов хоть полигон, хоть звезду, хоть куб

.

zub писал(а):Даже если так, сомневаюсь в необходимости рисовать чтото когда мышка ушла за пределы канваса или перешла на другой контрол.

У всех свои задачи)

Alex2013 писал(а):В общем во первых я завтра выложу исходник ...

Ждем)

Alex2013 писал(а):Как то ожидал что именно это часть вызовет интерес
ведь уже даже у выложенных версий можно добавить в обойму
инструментов хоть полигон, хоть звезду, хоть куб

Скажем так - концепция не нова. И думаю все применяют что-то подобное для своих проектов. Поэтому особого всплеска интереса ожидать не стоит. В данном случае, интересует не сам концепт, а дальнейшее его применение и возможности.
Т.е. как раз часть связанная с генерацией кода и обратным схемопостроением.

Пятая сборка в пятницу
На этот раз почти полный исходник (Искать исходник ДЛЛ ки было немого в лом) Хотя на днях найду и выложу ничего секретного там нет ...
Кстати не плохо бы ее перекомпилировать в лазарусе а то например возврат данных обработанных скриптом являет иногда довольно не тривиальную задачу-головоломку ...

Добавил полигон (Несколько точек соединяется в не замкнутый контур ) а та так же элипс и прямоугольник ...
А главное расширил библиотеку процедур которые можно использовать из скрипта .
Исходники так и не "причесал" комментариев не много и те возможно кривоватые но и кода пока с гулькин нос ..
С глюкавой перерисовкой пока просто не заморачивался