между "боксом" и "контейнером" наверно нет. А вот понятия "FTCG контейнер" как такового нет, ибо среда ничего не знает про кодогенераторы и уж тем более их названия.


надо ли это понимать так, что от утверждения "FTCG не умеет работать с интерфейсными элементами" мы перешли к вопросу о том, где скачать полный аналог пакета Windows? Т.е. несостоятельность первого можно считать доказанной?


более менее приемлемая скорость компиляции только у продуктов от Microsoft, пакеты для которых врят ли кто-то когда-то будет делать.


полагаю очевидно, что собирать оптимальный проект из элементов не возможно без посредника в виде некоторого скриптового языка? Это значит, что альтернативой может быть только случай, когда целевой язык и язык скрипта совпадают. Уместность такого подхода в случае, к примеру, Assembler-a (или CSS, HTML, Prolog и т.д.) вызывает очень большие сомнения.

nesco, я уже не раз говорил о том, что FTCG не обязывает писать элементы ручками в своем собственном диалекте. Опять таки же не желание потратить пол часа на ознакомление с пакетом или хотя бы заполнить пробелы в знании четко поставленными вопросами приводит к формированию ложных представлений о технологии. В том же пакете QT есть примеры элементов (визуализаторы звукового потока скажем), которые выполнены в виде отдельных cpp юнитов (как в стандартном пакете hiasm4), и подключаются через относительно простой hws скрипт, который при желании можно генерировать автоматиматически по INI файлу.

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