и внешний редактор интерфейсов к нему(например Glade)
Сам же кодогенератор будет на FPC(Lazarus) так к нему уже есть обвязки для GTK+ (Ну или на чем то другом не особо важно)

Да у GTK+2.0 есть еще одно приемущество в отличие от QT можно писать коммерчиские программы на нем без каких либо ограничений и какой либо оплаты.

И да мульмедия библиотеки может уже пара закопать bass.dll из-за того что портировать на нем приложения кроме windows больше не куда нельзя.

Лучше уж что типа GStreamer или Xine использовать

alexsx2008, флаг тебе в руки. Делай.

Был бы я програмистом.
Да и диплом еще мне писать сейчас как-то времени не очень свободного много.

alexsx2008, ты меня извини, но и у других может быть Помещай объявление в КупиПродай. Вдуг и договоритесь.

alexsx2008, скоро начну 2ю часть проекта hiPython - компоненты для PyGTK.
------------ Дoбавленo в 23.05:
alexsx2008, на самом деле связать Hiasm и Glade будет непросто - ведь надо как-то перенести в редактор схемы структуру компонентов и контейнеров. Т.е. после каждого редактирования придётся читать glade-файл и переводить его в sha, а перед редактированием проводить обратную процедуру.

я бы вообще весь HiAsm на GTK переписал. QT это конечно хорошо, но минусов там и без коммерческих ограничений хватает...

Ну да.Хотя в Glade руками интерфейс рисуется,а он же потом на выходе идет как чистая оболочка контейнер для какого нарисованного в нем приложения(вернее его интерфейса) написанного и использующего библиотеки GTK,а код уже цепляют к кнопкам на поддерживаемых языках(или используют генератор если такой есть,в старых ревизиях Си код генерировался).

Хотя может я чего не так понял из описания.


Я же не говорю давайте завтра или через неделю.Это так можно рассмотреть кому захочется как далекая перспектива.


По мне было вообще хорошо если была именно такая программа(но это больше похоже на тупик)
Сначала рисуем интерфейс во внешнем редакторе(именно дизайн программы,кнопочки меню и т.д),потом уже его загружаем и каждый динамический(в некоторых случаях статический(неизменяемый) пункт делаем функциональным(с помощью например генератора кода и кубиков hiasm) и потом уже объединяем и разделяем блоками статику от динамики.Так же объединяем по блочно зависимые друг от друга компоненты и потом объединяем это все(не продуманно) и компелим программу(Тут по всем пунктам надо очень много думать и продумывать как и что)

alexsx2008, подобный подход хорош для сапров и case-ов. Для простого пользователя, не искушенного в архитектурах софтостроения, подобные этапы разработки программного обеспечения совершенно ни к чему.

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

alexsx2008, Как непрограммист непрограммисту могу сказать что в моём случае интерфейс разрастается по мере увеличения кода программы. И если бы стояла задача создать GUI а потом код, процесс затянулся бы во много раз, и задача по написанию программы могла погибнуть вместе с недорисованным интерфейсом

MAV прав на 100% Как раз в hiasme все отлично продумано и удобный интерфейс рисования интерфейса.

ну не всегда нужно наращивание внешнего функционала.Иногда важен только дизайн и потом уже к нему логика монолитная внешняя+немонолитная внутреняя.

Если идти то два способа по своему хороши
1.Дизайн+Монолитная внешняя логика программы+Не монлитная внутреняя логика(для одних которым нужно программу быстро прямо сейчас и на решение только поставленной задачи,да развитие не очень такой программе нужно.
2.Логика пишится в начле программы+дизайн уже наварачиватеся на логику(Вот тут не надо hiasm относительно этого пункта не очень удобен,в нем все почти ограниченно программой)по этому и предлагал воспользоваться внешним редактором интерфейса и дизайна который уже будет снимать все ограничения hiasm.

Да и вообще мы от темы отошли

Так что там спаршиваль библиотека GTK+2.0(тут Dilma отписал что он бы с радостью переписал на него HIASM),поддержка GLADE (внешнего редактора интерфейсов(визуального),тут много чего надо решить).

А вот под подключяемые библиотеки и медиа фреймоворки GStreamer и прочие и убирание bass.dll не кто не ответил

------------ Дoбавленo в 17.34:
Да еще бы HIASM использование drakon-схем и реализацию dron было бы круто и UML для кодегенерации своих моудей

bass прекрасно заменяется на fmod (хотя я не уверен, что для коммерческих программ у него не теже самые условия). С GStreamer никогда не работал, ничего про него сказать не могу.

Ну ладно GTK+ будет или нет хотябы так в блиайшем будушем(к примеру к концу этого года или следующего)

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