Dilma, с перепугу подумал что будет среда с пакетами на основе компилятора GCC, теперь прояснилось .

[offtop]...одной ОС на...[/offtop]

MAV, пакет для GCC (GTK) может и будет.

Если возможно, и пока ещё не поздно, хотелось бы видеть большую "гибкость" Конструктора, т.е. возможность создания или изменения компонентов без знания языков программирования.[flood]Как это реализовать не представляю, но вижу два пути: или создание более продвинутого редактора эелементов, или создание более мелких элементов (компоненты-микросхемы есть, нужны резисторы, диоды, транзисторы...) из которых можно будет собрать нужный компонент (медленный, замороченный, запутанный, но рабочий) и если он будет востребован, то переделывать его в полноценный и добавлять в палитру.[/flood]

это есть и в текущих версиях

[flood]Кухонный комбайн работает у меня раз в году, когда шинкую капусту, хотя когда покупал думал им и то делать, и это, и пятое, и десятое. Оказалось что он одно делает не так как думал, другое вообще портит, да его ещё и вымыть надумаешся. Вобщем не окупает он трудозатрат, и времени на это уходит гораздо больше чем всё тоже самое сделать по старинке, вручную.[/flood]

iarspider, возможно стоит за основу стоит взять Bloodshed Dev-C++, с которым сейчас знакомлюсь, про быстродействие и крошечный размер получаемого файла я уже и не говорю, а вот чем я был сильно удивлён это с присутствием русского языка в оболочке постовляемой с этим набором библиотек. Все библиотеки и исполняемые файлы компилятора занимают сравнительно малый размер не более 10 мб.
olDjeka, более продвинутый редактор элементов хотелось видеть не только тебе . Соответственно общей концепции такой редактор должен быть визуальным. Мне к примеру видится в виде шаблонных блоков, наподобие тех по которым в школах учат информатике.
К примеру алгоритм, соответствующий инструкции if-tnen-else

Кстати мне попадался проект с подобным принципом, но по всей видимости автор так и не развил идею до конца.

MAV, одна из насущных проблем всех пакетов на базе языка С++ это время сборки. Если средний проект пакета Windows собирается за 1-2 секунды(3-4 компилятором FPC), то проект на базе С++ собирается от 10 секунд и больше(зависит от числа используемых контейнеров). Поэтому еще не факт, что брать его в качестве основы имеет смысл. Вероятно связка Python + GTK (он же PyGTK) оказалась бы гораздо удачнее. Но пока об этом говорить преждевременно и задачи таковой не ставится. Порт существующих пакетов под новую среду это гораздо менее трудоемкая задача и выполнимая в приемлемые сроки.

Помойму в не той дорогой идете товарищи. Лучше разрабатывать более интеллектуальный кодогенератор да бы добиться хорошей читабельности кода и более легкого создания новых пакетов.
Также именно кодогенератор нужно делать мультиплатформиным и превратить его в компилятор, схемы в код, а средой или так скажем IDE это уже дело пользователя какой IDE использовать

автор поста желает внести 1500$ в фонд проекта на покупку Delphi?

только дело в этом? Не такая и большая сумма... если каждый пожертвует немного..

[offtop]Ravilr, будем реалистами[/offtop]

Пользовательские компоненты на основе контейнеров существуют уже ХЗ с какой версии (вкладка User). Только вот справка эту фичу не описывает - было только поснение от Dilmы на одном из старых форумов по созданию таких компонентов. Может, стоит добавить команду "преобразовать в User-элемент"?


А чем существующих плох?


А сейчас что, плохо читаем? Вполне себе читаем, если целевой язык знаешь


Изучить ещё один мини-язык (hws) очень сложно, ага


Среда позволяет приписать компилятор Copy любому пакету. Плюс все имеющиеся пакеты либо сразу используют Copy, либо (как Python) используют свой аналог (в случае с Python - конвертирует сгенерированный код в кодировку UTF-8)

сейчас это полностью заменяет команда Правка->Создание элемента, выполненная на контейнере.

Плохо справляется, так как отладка такого компонента в пакете Windows невозможна (из-за отсутствия хэндела подсвечиваемой связи для среды), не знаю, что можно сделать для решения этой проблемы, но она есть
------------ Дoбавленo в 12.34:
И вопрос, public репозиторий - это новый будет, или будет использоваться текущий репозиторий исходников среды (только с его открытием всех желающих, конечно)