LastLeader, доп. файлик?
Более логично продумать и реализовать API редактора схем, редактора форм, панели элементов.
Далее в коде элемента описываем необходимые действия, при определённых условиях и дёргаем API
------------ Дoбавленo в 19.41:
В идеале, лучше всего реализовать ядро среды с продуманным интерфейсом (API) и далее уже делать обвес GUI на чём душе угодно, хоть на том же Lua или QtScript.
------------ Дoбавленo в 19.53:

Довольно таки не плохая штука, кстати
Основан на ECMAScript + модификация для дружбы с сигналами и слотами.

Если думать о совместимости то с файлом вроде логичней, да и при сборке меньше мусора парсить (кодогену ведь не нужна граф информацыя да и в исходниках она вроде не к чему), а API нужно 100%, с этого начинать нужно.

LastLeader, для поддержки текущей элементной базы(RTCG, FTCG), проще реализовать функционал кодогенераторов с учётом новой архитектуры среды.
Благо там не так много функционала было реализовано, и думаю за неделю можно всё это дело перевести на новый лад
Вообще, нужно прекращать строить велосипеды и прикрутить нормальный скриптовой движок, с подсветкой синтаксиса, автодополнением, нормальным отладчиком и хотя-бы простым статическим анализатором (для стандартизированного ECMAScript в самый раз).
------------ Дoбавленo в 20.11:
И вообще, это всё должно работать в реальном времени, и все изменения в коде элемента подхватываться на лету в случае применения оных.
------------ Дoбавленo в 20.23:
Ещё, мне очень не нравится текущая ситуация с кодогенератором...
Из-за ошибки в скрипте элемента, может упасть вся среда! Как так.
Среда вообще должна быть не убиваемой и иметь механизм теневой копии параметров открытых проектов и не сохранённых изменений, дабы мы не потеряли свой наработки из-за какой-то там солнечной вспышки

Много чего упирается в время, плохая работающая система намного лучше хорошей не работающей. Нужно делать систему наращиваемую и что работает уже сейчас. Когда оно заработает

Предлагаю использовать ECMAS script 6 на v8.
+ js простой.
+ 6 версия не содержит необычных особенностей js, + новые фичи.
+ v8 очень быстрый, скорость не помешает.
+ Можно использовать asm.js и производить ещё более быстрые вычисления, и использовать готовые библиотеки использующие asm.js вроде pypy.js и без изменения когда позволять писать код на python.

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


Плохо это или хорошо, но, в кьютешке используют ECMAS script стандарта ECMA-262 Edition 5.1 (June 2011).
http://qt-project.org/doc/qt-5/qtscript-index.html

Так почему же тогда ты морочишь бэбики с языками
Правильно ведь сказал:

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

------------ Дoбавленo в 07.32:
Одно очень маленькое замечание - не получится.
А дальше начинается самое интересное, определяющее характер человека: либо модифицируется HiAsm (чтобы получилось), либо открывается холивар про то, у какого ЯП чего толще.

Galkov, абстракции - абстракциями, но нужно учитывать объём предполагаемой работы относительно человеческих возможностей
Мне не важен язык в большей степени, мне важна качественная реализация необходимых возможностей на низком и высоком уровне.
Есть конечно сверхвысокий уровень - HiAsm, но сам по себе, он ничего не может

В итоге, у нас 4 базовых уровня абстракции:
1) Реализация базового API на основе низкоуровневого взаимодействия с парком ОСей. Даёт нам Qt.
2) Реализация высокого уровня с учётом концепции тулкита и базового API. Даёт нам Qt.
3) Ядро проекта с реализацией базового функционала относительно задуманных возможностей. Сами делаем.
4) Реализация возможности взаимодействия пользователя с ядром проекта. Сами делаем.

В данном случае, у нас будет гибкий инструмент с огромными возможностями, способный адаптироваться к любой задаче, с учётом требований к проекту.

Блин, это не сверхвысокий уровень, это нормальный уровень.
Это первое...
А второе -- МОЖЕТ. Успокойте на 5 минут свой зуд про то, что Вам нужна завтра работающая программа, и Вы увидите -- МОЖЕТ.

Он может разбить одну большую задачу на десяток-другой более простых (во столько же раз), с абсолютно понятными интерфейсами, которые могут реализовываться разными программистами абсолютно независимо.
Даже если у Вас нет ни кодогенерации, ни API для него - это уже огромный результат. Хотя бы потому, что эта схема разработки рекурсивная, и не имеет ограничения сверху на уровень сложности.
И потому, что другие ЯП этого тупо не умеют. И не хотят уметь. И даже не знают, что надо уметь.

Можете (и это будет справедливо) назвать это системной архитектурой (особенно, если хочется потешить свое самолюбие)...
А по нашему - это просто схема

---

Наконец, самое главное: ВОПРОС, ответ на который мне было бы очень интересно услышать.
Что же мы собираемся делать
Как я мимоходом отмечал - "на HiAsm не получится". А вот типа у нас, "очень умных программистов" - получится. Так что ли
Так мы опять делаем игрушку для "НЕ очень умных программистов"
Мы сохраняем разделение на "гуру" и "пользователей"
Или надеемся, что потом сможем произвести нужные модификации
((мое категорическое мнение - НЕ СМОЖЕМ. Плавали, знаем...))

Это очень важный вопрос, определяющий потенциальный успех проекта. И ответ на который надо давать "на берегу".

В чем заключается моя мысль: на самом первом шаге надо создать системную архитектуру проекта, и изобразить ее в виде СХЕМЫ (не более двух десятков элементов).
Только в виде схемы. Ничего кроме схемы.
Если для нас эта конечная задача является непосильной -- тогда позвольте мне не поверить в успех проекта
А если получится, тогда на очереди появится еще с десяток конечных же задач...
Хотя и не будет еще конечной программы, но сомнений в успехе проекта уже не останется.

Galkov, вы меня (или всех) явно переоценивайте
У вас имеется опыт управления сложными проектами. Да?
Также, видимо, вы хорошо знакомы с системной архитектурой. Возможно, да?
И философией проектированиямоделирования увлекаетесь. Возможно, да?

Ну так вот, к чему это я
Задача у меня простая - сделать прототип.
Посмотреть, покрутить, оценить возможные дополнительные концепции, способы упрощенияулучшения, уровень сложности реализации существующих и будущих решений.
Я не Автор, и не участвовал в создании HiAsm.
У меня нет того опыта, который Автор накапливал долгие годы, основываясь на практических соображениях относительно всего существования проекта...
Всё что я могу, потихонечку повторить весь опыт Автора относительно проекта, исходя из того что у меня есть, и, только потом приступить к захвату мира

От простого к сложному, так сказать

Да ладно Вам...

Предлагаю же я, всего лишь ПОДУМАТЬ, перед тем как начать работу.
"Чтобы не было мучительно больно за бесцельно прожитые годы"
Разве я предыдущим постом недостаточно обрисовал, почему такое может приключиться

Кого я переоцениваю... Надо лишь схемку НЕБОЛЬШУЮ нарисовать.
И очень серьезно задуматься - почему не очень (мягко говоря) получается.
И главное - что надо сделать, чтобы получилось. Схемку небольшую нарисовать
Повторюсь - НЕБОЛЬШУЮ (чтобы меня не обвиняли в чьей-то переоценке)
((вообще-то, я этот путь уже прошел, чего и Вам желаю))


Тут же нет никакой сверхгениальности (чтобы кого то переоценивать): сначала надо понять, чего делать, а уже потом -- делать.

Вот еще, CriDos -- давайте не будем пугать друг друга умными словами про "управление проектами". ((хотя сейчас это и есть моя основная работа, в которой я испытываю огромные трудности))
Системная архитектура -- должна стать не более, чем схемой на HiAsm.
Не смотря на гиги философских рассуждений на этот предмет в инете. От тех, кто в этом не очень разбирается (это уже не более, чем мой личный диагноз)

Ровно также, как очень сложное понятия ПРОГРАММА было превращено в схему на HiAsm
Теперь следующий этап.
Это, конечно же, если есть желание совершить революцию в ИТ-технологиях

Пофантазирую
PS: я не курю

Мы помним

Я бы по Вашим идеям сказал, что Вы ведёте ЗОЖ. Я те же функции/возможности хочу ввести в HiAsm Mobile

[offtop]И вспомнил же [/offtop]

Netspirit, доплнение .
Для кодогенератора иконка и конфигурацыя компонета не нужна
Там где сейчас находится конфигурацыя можно включить предлагаемый скриптовый язык.
Скриптовый язык нужен для:
1. Описания структуры элемента;
2. Для всего того что написано в Netspirit
3. Описания дополнительных графически форм связанных с элементом;