GUI

Xaw ещё никто не отменял.

Рюшечки, OpenGL, анимация, полупрозрачность в обычном GUI и множество других относительно ненужных вещей. А ещё более быстрое и безопасное написание кода.

/me разделяет твоё негодование, да только что поделать...

Взять и запилить свою либу.

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

Кроссплатформенной может быть и библиотека на C. GTK тому пример.

И, кстати, GTK так же пример того, как нагруженные сущностями библиотеки для GUI выглядят на C. Qt существенно стройней и понятнее.

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

Да тольк qt почему-то медленнее на слабых системах

Рюшечки, анимация, полупрозрачность в обычном GUI

Что характерно, все это превращает DE в бесвкусное, вульгарное, кривое, тормозное говно. Зачем они это делают? Ну ладно там всякие макоси, у которых ресурсов вагоны, лучшие дизайнеры и т.п., но у оупенсорсных нищебродов без элементарного чувства стиля.. ЗАЧЕМ?

openmotif

Позвольте, а почему перфокартами никто не интересуется? Век ЭВМ уже давно прошел. Как и Pentium 2.

freebsd + fluxbox/icewm чувствует себя превосходно на PI/II с 32/64 RAM. Инфа 100%.

Век ЭВМ уже давно прошел.

Для планктонин с планшетами он и не начинался.

А так я надеюсь полноценные мощные десктопы будут радовать нас ещё не одно десятилетие.

век то прошел, а тормоза - остались =(

Вопрос: какого %%%%, сейчас для отображения элемента требуется или залезть с корнями в С++ (или ещё более «универсальную прослойку») или аналогично залезать во множество функций с разными именами для получения той же функциональности и ох%%%%ной «„производительностью“»

Не ври. GTK — да, жирный, собака. Зато есть motif, к примеру.

man XCreateWindow

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

срочно на libaa! Только там есть хардкор.

XLib, Xaw, Xt чем не библиотеки ???

Кроссплатформенной может быть и библиотека на C. GTK тому пример.

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

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

Как надоело уже ваше нытьё. Найди себе какой-нибудь Red Hat 6.2, накати на свой третьепенёк и сиди весь радостный.

FLTK же:

www.linux.org.ru/gallery/screenshots/8757867

миниатюрность + отличная настраиваемость + написано на «С с классами»

Суть: Во времена когда linux как ядро ходило под столом^W отладчиком, уже существовали некоторые GUI OS (без имен).

Суть в том, что Linux команда не изобретала никакого GUI. Они взяли готовые наработки X-Window и иже с ними. Другие концепции графического интерфейса не прижились. Осознали это остаточно поздно - состряпали вяленого (wayland).

Идея Sun построить GUI на основе PostScript не прижилась (NeWS) , а вот идея построить то же самое на PDF вылилась в Aqua.

Хорошие примеры реализации GUI в Plan9, Inferno, Oberon, SmallTalk.

Но опять таки GUI понятие многослойное, тут и L&F, DE и конечно же приложения.

В общем писать можно долго :)

P.S.: А все эти новомодные Qt, GTK, wxWidgets и иже с ними, imho не нужны.

А все эти новомодные Qt (1992), wxWidgets (1992)

новее некуда

Qt, QML, система из 2000 частиц, 60 кадров в секунду на rasberry Pi. Потому что rasberry Pi популярен и под ним профилируют саму библиотеку и приложения.

Под Pentium 2 никто не будет затачивать ни библиотеки, ни софт, пользуйтесь софтом 5-6 летней давности и всё будет хорошо.

Да тольк qt почему-то медленнее на слабых системах

На глазок что ли определяли?

По сравнению с тем что уже было да, новомодные :)

Вырвиглазность ГТК - отдельная тема. Я говорил только о собираемости кода на разных системах.

все эти новомодные Qt, GTK, wxWidgets и иже с ними, imho не нужны.

И под каждую ось морда к приложению будет писаться своя? Нет уж, спасибо.

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

И под каждую ось морда к приложению будет писаться своя?

На кой? Пишешь под линукс, а на остальных насрать. Если захотят — сами морду напишут.

Потому что у каждой системы (оси) свои особенности GUI

какие особенности у линукса?

Я говорил только о собираемости кода на разных системах.

mingw/cygwin тоже не вполне нативны для той же винды, так что гтк для винды можно считать потерянным. Требование превратить target arch/platform в posix для компиляции не есть кроссплатформенность.

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

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

А они будут делать обновление раз в год. И не париться.

GUI как обёртка на скриптовом

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

А еще можно сделать веб-морду. Все равно апач или nginx у каждого установлен. А если даже не установлен — запилить мини-вебсервер внутри самого приложения.

Юзай KolibriOS

какие особенности у линукса?

Вы настолько ограничены ? Мне, на вскидку, приходят на ум несколько операционных систем с различными меделями построения GUI - Haiku, Mac OS X, Windows, OS/2 (eComStation)

У Linux уже три графических подсистемы - X-Window, Wayland и framebuffer. Все они требуют отдельной работы и возможности у них совершенно разные.

Все они требуют отдельной работы и возможности у них совершенно разные

Вот для скрытия от разработчика особенностей и нужны инструментарии типа Qt.

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

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

У Linux уже три графических подсистемы - X-Window, Wayland и framebuffer.

Вот мне как прикладнику должно быть АБСОЛЮТНО наплевать, кто мне обеспечивает рисование моих окошек на экране. Я ж заколебусь учитывать в коде особенности графических серверов.

Зато есть motif, к примеру.

Эх, молодежь. И не подозревает, что когда-то, до того, когда этот ваш Мотив стали пропихивать, был прекраснейший OpenLook. Для программирования использовалась 2 фукнции. Ну, 4. xv_get, xv_set, xv_create, xv_destroy. Вcе. Мотив - мегатормоз по сравнению с openlook, от Мотифа все плевались в своё время, потому что он тормлзил. Такие дела.

какие особенности у линукса?

Мне, на вскидку, приходят на ум несколько операционных систем с различными меделями построения GUI - Haiku, Mac OS X, Windows, OS/2 (eComStation)

вы не понимаете простых вопросов?

У Linux уже три графических подсистемы - X-Window, Wayland и framebuffer. Все они требуют отдельной работы и возможности у них совершенно разные.

и не знаете, что такое GUI - марш в википедию

Всё таки GUI на компилируемом языке я считаю минусом. Потому как ежели вдруг мне захочется, то для ковыряния интерфейса скриптовый язык проще.

Времена и библиотеки меняются - реакция всё та же.

вы не понимаете простых вопросов?

По моему ответ был ниже.

и не знаете, что такое GUI - марш в википедию

Прочитайте ВНИМАТЕЛЬНО. Я писал о подсистемах, а не GUI

И идите Вы сами в вашу википедию или спать :)

Потому что у каждой системы (оси) свои особенности GUI

какие особенности у линукса?

«Прочитайте ВНИМАТЕЛЬНО. Я писал о подсистемах, а не GUI» - может я что-то не понимаю в русском языке, но когда пишут «особенности GUI», то обычно подразумевают «особенности GUI», а не «особенности подсистем»

для ковыряния интерфейса скриптовый язык проще

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

Кстати, да: а как ты взаимодействовать-то собираешься? Пилить свой велосипед на IPC?

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

Tcl/Tk что первое приходит в голову.

Кстати, да: а как ты взаимодействовать-то собираешься? Пилить свой велосипед на IPC?

Большинство из того что я вижу, достаточно дёргать программу с параметрами. Насчёт IPC хз. В конце концов надо, и D-Bus не к ночи будет упомянут можно задействовать.

Дополнительный буфер обмена в X11. Сочетания клавиш, зарезервированные различными DE. Appmenu (глобальное меню + поиск по нему при нажатии Alt) в unity, а скоро и в KDE.

Есть ещё ряд утилитных задач, которые сопутствуют созданию GUI: хранение пользовательских настроек (изменённая пользоватеелм ширина колонок таблицы не должна возвращаться обратно при перезапуске, а у FDO свои требования к месту хранения), поиск иконок в дефолтной теме (это специфично для linux, в mac/windows доступных приложениям наборов иконок нету).

Это навскидку, ибо я имею лишь поверхностные знания в данном вопросе.