Замена qt чем нибудь на c.

Gtk+.

Компилируем без изменения исходного кода на все платформы

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

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

Это замена QtGui только, кажется?

Это замена QtGui только, кажется?

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

Gtk+, не?

ничего, афаир.

В Glib много чего есть, и структуры данных, и потоки, и ввод-вывод. И всё кросс-платформенно, да.

для «окошек» и прочей ненужной чепухи

Чёрт, а ты ведь знаешь - ты прав

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

Вот именно, интересуюсь для встраивания в язык высокого уровня.

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

в линуксе никаких нормальных GUI библиотек нет, любая стоящая прога всегда использует какую-то свою библиотеку, а то что написано на gtk и qt выбросить жалко, и нести тяжело

Эквивалентной замены не получится, так как возможности С более скудны.

Я не имел ввиду эмуляцию Qt API

Набор библиотек на C который заменит Qt на принципе «Компилируем без изменения исходного кода на все платформы».

Ты только что произнес слова «FreePascal» и «LCL»

http://enlightenment.org/p.php?p=about&l=en

http://trac.enlightenment.org/e/wiki/EFLBindings

Qt и gtk уже ненормальные GUI библиотеки? Что-то новенькое.

А чем Qt не устроил? (чтобы не посоветовали чего-то, что обладает теми же самыми критическими недостатками)

Или проблема только в C++?

Я сначала подумал, что ты говоришь о ситуации на шindows, но потом перечитал еще раз и удивился.

Наркомцан?

xlib .. worker

Qt не заменишь. Он один такой хороший:)

Никак не заменить, но если убрать ограничение на С, тогда java наиболее кроссплатформерна.

И всё кросс-платформенно, да.

Ага, только если этим всем лично не пользоваться.

К сожалению, разработчики GTK игнорируют особенности винды, из-за чего в потоке нельзя просто так взять и получить/изменить что-то в виджетах. Обход проблемы есть, но он не нужен под линуксом. Вот и выходит, что оно кроссплатформенно да, но ни в коем случае НЕ всё.

Сам пользуюсь GTK&Glib. Если снять ограничение на C и остаться на С++, то есть FOX (fox-toolkit.org) и FLTK (лично не использовал). О FOX узнал, работая с SUMO.

Так Qt не работает с C

К сожалению, разработчики GTK игнорируют особенности винды, из-за чего в потоке нельзя просто так взять и получить/изменить что-то в виджетах.

Под Linux'ом лучше тоже этого не делать. Лично сталкивался с падением ПО при включенном режиме для инвалидов в Гноме (не помню как по научному называется это дело, значок еще такой синий в трее). Может это и бага Гнома, может и конкретной версии и сейчас уже починили, но требовалась стабильная работа ПО под любым дистром/DE, так что пришлось избавляться от GTK-вызовов из не-GTK-потоков.

И всё кросс-платформенно, да.

Ага, только если этим всем лично не пользоваться.

А в остальном как раз нормально все. Лично пользуюсь, ага.

Набор библиотек на C который заменит Qt на принципе «Компилируем без изменения исходного кода на все платформы».

GLib + Gtk. И точка. Остальные варианты — чисто пофлудить в треде, не более.

А glib зачем?

XLib, а вообще, само собой, лучше Gtk.

А glib зачем?

Так выше писали же:

В Glib много чего есть, и структуры данных, и потоки, и ввод-вывод. И всё кросс-платформенно, да.

Ладно, не буду вякать. За кроссплатформенность придется платить либо использованием велосипеда над велосипедом, либо изучением особенностей написания кода под каждую платформу.

интересуюсь для встраивания в язык высокого уровня.

Ну так как раз Gtk и GLib со своим GObject'ом (http://ru.wikipedia.org/wiki/GObject) под это дело заточены.

fltk же, давно извесно что это выход из замкнутого круга

fltk же

fltk на С++

По-моему ты лиспом увлекаешься. Чем CAPI не устраивает, кроме как своей ценой?

Набор библиотек на C который заменит Qt на принципе «Компилируем без изменения исходного кода на все платформы».

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

Glib + gtk?

Qt + extern «C» ?

да и использовать qt расточительно, т.к. приложение раздувается до неимоверных размеров.

ЩИТО?

Чем тебе Qt не устроил?

ЩИТО?

на лоре писали, что qt добавляет +10Mb к андроидному APK, что на подавляющем большинстве андроидных девайсов будет обозначать «поставить некуда, место на internal storage кончилось».

Я вот тоже думаю что кроссплатформенность далеко не всегда нужна.

Я думаю, что у ТСа просто ЧСВ зашкалило.

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

на лоре писали, что qt добавляет +10Mb к андроидному APK, что на подавляющем большинстве андроидных девайсов будет обозначать «поставить некуда, место на internal storage кончилось».

Я бы не сказал, что в современных телефонах такой маленький internal storage.

wxWidget

Я бы не сказал, что в современных телефонах такой маленький internal storage.

ну если делать софт только для тех кто апгрейдит телефон каждые полгода — да, наверное и qt подойдет. у меня самого телефон двухгодовалый htc desire, и internal storage категорически маленький.

Тут уже выше сказали: Gtk+ и GLib. Больше проверенных вариантов нету.
Хотя есть EFL, который вполне себе подходит под требования. Но сказать честно, на Windows я его не пробовал, но довелось использовать эти библиотеки на десктопном Linux и embedded Linux(без иксов, с фреймбуфером), показали себя вполне неплохо.
Возможность собрать под винду есть, и даже имеется слой совместимости (с говорящим названием Evil). Так что можно посмотреть в эту сторону.

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

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

К сожалению, разработчики GTK игнорируют особенности винды, из-за чего в потоке нельзя просто так взять и получить/изменить что-то в виджетах.

Ну в общем-то в любом графическом тулките многопоточная работа с виджетами - тонкий момент, и потому считается хорошим и правильным всё-таки разделять рабочие потоки и gui-поток.
Да и честно сказать, я и не помню такого, чтобы где-то была заявлена корректная обработка изменений в UI, сделанных из другого потока.

Кстати, насчет многопоточности. А считать-то как?

Допустим, понадобится ТСу запустить несколько параллельных потоков + с openMP распараллелить цикл какой… Что-то сомневаюсь, что в мастдае есть pthreads и openMP.

Мы используем Qt на девайсах с намного меньшими ресурсами, чем у современных планшетов и смартфонов

Зачем?

Мы используем Qt на девайсах с намного меньшими ресурсами, чем у современных планшетов и смартфонов

а на андроиде используете? с размером apk проблем не возникает? гуй адаптировать не приходится с десктопа?