DobrijZmej 16.07.2010 09:31
Есть вопрос! — Мультиплатформенный GUI - миф или реальность ? [вопрос снят]
Приветствую уважаемых ВиЛинуксоидов....Снова я к Вам с вопросами...
Решил я озадачиться и попрограммить в GUI. Почитал литературку, и пришел к таким выводам:
1) Можно использовать библиотеки GTK+, но тогда приложения будут оптимизированы под гном, и при установке в других "окнах" будут тянуть за собой гномовские библиотеки библиотеки GTK+, которых нет в системе.
2) Можно использовать QT, но тогда приложения будут оптимизированы под KDE, и соответвенно в других оконных менеджерах будут тянуть за собой KDE-шные библиотеки библиотеки QT, которых нет в системе...
3) можно использовать Xlib (к чему я, собственно и склоняюсь), но при подключении хидеров компилятор ругается, что у меня хидеров Xlib-а нету -> а соответственно если я буду распространять написанный мною код, то он опять-таки будет тянуть за собой библиотеки Xlib.
А теперь внимание, вопрос:
1) Есть ли возможность программить GUI, используя минимальный объем библиотек (желательно такие, которые установлены уже в любой системе, будь то GNOME/KDE/XFCE/etc), но не скатываясь ниже C++
2) Если вся графика (GTK+ и QT в том числе) так или иначе базируется на Xlib, то почему когда я начинаю подключать эти библиотеки - они отсутствуют в системе ?
Возможно (даже наверняка), я не до конца понимаю некоторые вопросы, и допустил некоторые технические неточности в тексте выше (или, другими словами, написал полный бред) - не могли бы Вы тогда поправить меня, или дать ссылку, куда мне пойти почитать о том, что я неверно понял (желательно на русском языке).
Заранее всем спасибо за потраченное на чтение этого поста время =)
Подводя итоги:
Username:
1) Есть ли возможность программить GUI, используя минимальный объем библиотек (желательно такие, которые установлены уже в любой системе, будь то GNOME/KDE/XFCE/etc), но не скатываясь ниже C++
Запихай библиотеки в собственную программу, в чем проблема-то?
digiwhite
2) Если вся графика (GTK+ и QT в том числе) так или иначе базируется на Xlib, то почему когда я начинаю подключать эти библиотеки - они отсутствуют в системе ?
По поводу библиотек. Заголовочные файлы идут в так называемых "development" пакетах. Для собранных приложений и библиотек они не требуются. Поэтому надо просто доставить нужные пакеты дофепчм разработки.
leonike
Почему тогда в линухе все построено на зависимостях ? ставишь пакет, а он за собой тянет кучу зависимостей....
Только для того чтоб библиотеки могли сами по себе развиваться и исправлять свои глюки, а программа как работала так и работает ?
Только для того чтоб библиотеки могли сами по себе развиваться и исправлять свои глюки, а программа как работала так и работает ?
если каждая программа будет распространяться со своими библиотеками, то представляете, сколько пространства будет занимать дистрибутив? насколько я понимаю, и в памяти тоже, так как разделяемые библиотеки используют все программы, а так каждое приложение будет загружать в память свою копию библиотеки.
Ну и глюки тоже, представим, в библиотеке нашли серьезную багу, профиксили, и будем заново собирать весь софт с новой библиотекой или качать апдейты гигабайтами?
muhas
В винде все закручено вокруг виндового API, в линухе вокруг Xlib ?
ну зачем сразу xlib, есть gtk-dfb (с directfb - без всяких иксов)
есть efl которые можно собирать без исков на голом fb(да и софта для fb не мало - тот же mplayer можно без зависимости от иксов собрать). есть libxcb конфликтующий с libx11... вобщем не всё так просто как кажется на первый взгляд...
так что что бы пока не заморачиваться (тем более к c++ у тебя насколько понял предрасположенность) - возьми qt и не парь себе мозг. винда, никсы, макось - тем более в qt не только qtgui но и куча всего(сетка, мультимедиа, etc) дабы не шибко зависеть от целевой ОС.
Пожалуй, на последней фразе остановлюсь. Всем спасибо за обсуждение.
Во-вторых, использование тулкитов GTK и Qt != использованию библиотек GNOME и KDE. Просто девелоперам под линукс проще работать с DEшными библиотеками, для пущей интеграции приложения в рабочий стол
вилинуксуюяркий пример это psi - он на qt но без кед.
в дельфах раньше 2.8 помнится qt был для гую (только qtgui)
да и интеграции можно добиться без использования дешных либ...
1) Есть ли возможность программить GUI, используя минимальный объем библиотек (желательно такие, которые установлены уже в любой системе, будь то GNOME/KDE/XFCE/etc), но не скатываясь ниже C++
есть... пиши хоть на питоне, у него tk в комплекте =)
Если вся графика (GTK+ и QT в том числе) так или иначе базируется на Xlib, то почему когда я начинаю подключать эти библиотеки - они отсутствуют в системе ?
всё-таки иначе. в винде и мобилках как бы xlib и нету, не?а нету у тебя хидеров а не самого xlib - на грубом приближении это как разбиение на dev пакеты в дебьяне.
в общем ТС учи матчасть
всё-таки иначе. в винде и мобилках как бы xlib и нету, не?
Да, признаю, неверно выразился. Имел ввиду множество различных дистрибутивов самого UNIX, без мобильных и виндовых платформ.
Запихай библиотеки в собственную программу, в чем проблема-то?
Т.е. есть возможность распространять только один файл приложения, без зависимости от библиотек ?
Почему тогда в линухе все построено на зависимостях ? ставишь пакет, а он за собой тянет кучу зависимостей....
Только для того чтоб библиотеки могли сами по себе развиваться и исправлять свои глюки, а программа как работала так и работает ?
Т.е. либо мы с начала мучаемся со сборкой, либо программа тянет за собой все глюки библиотеки на момент собрки ?
Почему тогда в линухе все построено на зависимостях ? ставишь пакет, а он за собой тянет кучу зависимостей....
Только для того чтоб библиотеки могли сами по себе развиваться и исправлять свои глюки, а программа как работала так и работает ?
Только для того чтоб библиотеки могли сами по себе развиваться и исправлять свои глюки, а программа как работала так и работает ?
если каждая программа будет распространяться со своими библиотеками, то представляете, сколько пространства будет занимать дистрибутив? насколько я понимаю, и в памяти тоже, так как разделяемые библиотеки используют все программы, а так каждое приложение будет загружать в память свою копию библиотеки.
Ну и глюки тоже, представим, в библиотеке нашли серьезную багу, профиксили, и будем заново собирать весь софт с новой библиотекой или качать апдейты гигабайтами?
Т.е. либо мы с начала мучаемся со сборкой, либо программа тянет за собой все глюки библиотеки на момент собрки ?
А чего мучаться со сборкой, либо использовать -static, либо просто кидать библиоеку в директорию с исполняемым файлом
Автор имеет в виду, что в GNU Linux Qt и Gtk для отрисовки окошек и прочей ерунды используют xlib. В win , по крайней мере Qt (думаю что и Gtk) ,используют нативные виндовые средства.
ну использует и бог с ним. хидеры-то для работы не нужны, только для компиляции, не?
ну и я к тому же(это ответ автору топика, я правда всё намеками да намеками)
Да, спасибо, это и имел ввиду:
В винде все закручено вокруг виндового API, в линухе вокруг GUI ?
В винде все закручено вокруг виндового API, в линухе вокруг GUI ?
Да, спасибо, это и имел ввиду:
В винде все закручено вокруг виндового API, в линухе вокруг Xlib ?
В винде все закручено вокруг виндового API, в линухе вокруг Xlib ?
ну зачем сразу xlib, есть gtk-dfb (с directfb - без всяких иксов)
есть efl которые можно собирать без исков на голом fb(да и софта для fb не мало - тот же mplayer можно без зависимости от иксов собрать). есть libxcb конфликтующий с libx11... вобщем не всё так просто как кажется на первый взгляд...
так что что бы пока не заморачиваться (тем более к c++ у тебя насколько понял предрасположенность) - возьми qt и не парь себе мозг. винда, никсы, макось - тем более в qt не только qtgui но и куча всего(сетка, мультимедиа, etc) дабы не шибко зависеть от целевой ОС.
есть efl которые можно собирать без исков на голом fb(да и софта для fb не мало - тот же mplayer можно без зависимости от иксов собрать). есть libxcb конфликтующий с libx11... вобщем не всё так просто как кажется на первый взгляд...
так что что бы пока не заморачиваться (тем более к c++ у тебя насколько понял предрасположенность) - возьми qt и не парь себе мозг. винда, никсы, макось - тем более в qt не только qtgui но и куча всего(сетка, мультимедиа, etc) дабы не шибко зависеть от целевой ОС.
Возможно (даже наверняка), я не до конца понимаю некоторые вопросы, и допустил некоторые технические неточности в тексте выше (или, другими словами, написал полный бред) - не могли бы Вы тогда поправить меня, или дать ссылку, куда мне пойти почитать о том, что я неверно понял (желательно на русском языке).
man man =)шучу...
учебники по программированию вестимо, гугул ища в нем кросплатформенные решения
а ты хотел что бы я посоветовал конкретную книгу где описаны все особенности кросплотформенной разработки? да такой ещё не написано :(
а вообще ява - вот где боле-менее кросплотформенность, правда гуй у явасофта страшненький (swing и прочее, да он у многих тулкитов по современным меркам страшненький
а вообще ява - вот где боле-менее кросплотформенность, правда гуй у явасофта страшненький (swing и прочее, да он у многих тулкитов по современным меркам страшненький
ну есть qtjambi, правда я не видел ни одного приложения на ней, а мб и видел, но не знаю, что то была java.
шут его знает, в ауре есть пакет qtjambi-community 4.6.3, мб поддерживается сообществом
хотя да, вспомнил, что была новость, что нокия больше не будет выпускать jambi
Ещё есть wxWidgets и FLTK, FLTK вообще очень компактная если склероз мне изменяет. Хотя для Qt гораздо лучше с документацией.
тысячи их.... FOX toolkit, tk,Swing и мульён своих прослоек таких как в опере используется....
вот-вот... куча всяких возможностей - выбирай что тебе лучше.
А откуда я знаю что лучше-то ?
Пробовать каждый по очереди ?
А откуда я знаю что лучше-то ?
Пробовать каждый по очереди ?
что лучше не знают даже сами разработчики (точнее каждый считает что у него лучше - отсюда и огромное их количество даже под один язык)
По поводу библиотек. Заголовочные файлы идут в так называемых "development" пакетах. Для собранных приложений и библиотек они не требуются. Поэтому надо просто доставить нужные пакеты дофепчм разработки.
а тогда еще вопрос... ну совсем ламерский... =)
в deb-пакетах распространяются бинарники или исходники ?
в deb-пакетах распространяются бинарники или исходники ?
И то и другое. Только это различные deb пакеты. В версиях "для разработки" обычно идут бинарники (статические библиотеки)+ заголовочные файлы. А есть пакеты именно с исходниками.
ну, емнип, всё-таки чистые исходники для сборки пакетов в debian идут в обычных архивах (tar.gz) + патч (просто gz) + PGP подпись
пардон, заглянул в репозиторий. Там не только подпись, а файл с описанием
Да, тут я наверное ошибся. Чисто исходники вряд ли идут в deb пакетах. Но смотреть щас влом :) Жара меня просто убивает :(
У нас дождей нет уже 2-ю неделю. Хотя сегодня надеюсь все же будет. Какие-то предпосылки имеются :)
Дело в том, что без северного ветра дожди всё портят - становится как в парилке и на улицу просто невозможно выйти
Да у нас другая проблема. У нас влажность высокая. Ладога, другие озера поменьше, болота вокруг города. От этой влажности вообще в осадок выпадаешь. Короче дождик был бы очень кстати. Хоть чуть чуть облегчение принесет.
Правила сборки? configure, Makefile e.t.c - это чтоли?
Вообще не помню. Как-то раз что-то пробовал ставить из исходников. Что там в нем припомнить уже не могу. Вроде как оно собирается, потом пакуется в deb и можно ставить. Но говорю - могу путать и ошибаться.
Вообще не помню. Как-то раз что-то пробовал ставить из исходников. Что там в нем припомнить уже не могу. Вроде как оно собирается, потом пакуется в deb и можно ставить. Но говорю - могу путать и ошибаться.
Правила сборки? configure, Makefile e.t.c - это чтоли?
аля ебилдовможешь распаковать какойнить deb src да посмотреть... в rpm src почти так же...
Для разработки, чтобы написанные тобою программы могли слинковаться с ними (ключик у gcc -l).
Кстати, если собираешься серьёзно девелоперствовать, особенно под C/C++, рекомендую фундаментальный труд Linkers and loaders - он про низкоуровневые неинтересные (сначала) штуки, но, прочитав его, будешь понимать, что "у ей там внутре" происходит при компиляции, линковке и при запуске.
Кстати, если собираешься серьёзно девелоперствовать, особенно под C/C++, рекомендую фундаментальный труд Linkers and loaders - он про низкоуровневые неинтересные (сначала) штуки, но, прочитав его, будешь понимать, что "у ей там внутре" происходит при компиляции, линковке и при запуске.
deb-пакет - это специальным образом сформированный, упакованный и сжатый архив и с бинарниками, и (deb-src) с исходным кодом.
Хочу немного поправить qt - не kde, а gtk - не gnome.
gnome базируется на gtk, а kde базируется на qt.
Имхо gtk будет в 99%, как бы не хотел все равно какая нить херь ее потянет
gnome базируется на gtk, а kde базируется на qt.
Имхо gtk будет в 99%, как бы не хотел все равно какая нить херь ее потянет
2) Можно использовать QT, но тогда приложения будут оптимизированы под KDE, и соответвенно в других оконных менеджерах будут тянуть за собой KDE-шные библиотеки...
никак нет, если писАть на чистом qt то никаких KDE не надо, только qt..
Причем qt-шная программа в GNOME будет иметь GTK-ный вид, а в KDE KDE-шный.
KDE:
GTK:
KDE:
GTK:
кстати ! напомнили мне еще про один вопрос...
Можно ли (ну допустим под qt) писать так, чтоб программа выглядела везде одинаково, независимо от оконного менеджера ?
Можно ли (ну допустим под qt) писать так, чтоб программа выглядела везде одинаково, независимо от оконного менеджера ?
можно. например, используя setStyleSheet, стили можно писать самому, man qss.
ещё скажи что бы независимо от исползуемой темы =)
она от оконного менеджера не зависит, если что... только от темы и прочих мелочей
она от оконного менеджера не зависит, если что... только от темы и прочих мелочей
Ну так предыдущий мой пост именно про это. У Qt мощная система стилей(визуальные темы), стиль это не набор картинок и конфигов, а классы которые рисуют виджеты. Есть Qt-шный стиль которыйтема есть с
Случайно отправил предыдущее незаконченное сообщение.
Ну так предыдущий мой пост именно про это. Посмотри скриншоты, это одна программа, и в ней нет никаких специальных операторов переключающих вид в зависимости от DE. Все делает тулкит.
У Qt мощная система стилей(визуальные темы), стиль это не набор картинок и конфигов, а классы которые рисуют виджеты. Есть Qt-шный стиль который для отрисовки дергает GTK-шные функции. Поэтому виджеты с этой темой в GNOME будут выглядят нативно.
Если надо нарисовать иконку, в Qt есть специальный метод передаешь ему имя иконки, и он возвращает иконку для текущей темы, как для гномовской, так и для кдешной.
Диалоги открытия/сохранения файла в Qt вообще автоматом выбираются, в GNOME показывается гномовский в KDE кдешный. За это тролям/нокии низкий поклон. Еще б GTK-шники сделали такое.
Ну так предыдущий мой пост именно про это. Посмотри скриншоты, это одна программа, и в ней нет никаких специальных операторов переключающих вид в зависимости от DE. Все делает тулкит.
У Qt мощная система стилей(визуальные темы), стиль это не набор картинок и конфигов, а классы которые рисуют виджеты. Есть Qt-шный стиль который для отрисовки дергает GTK-шные функции. Поэтому виджеты с этой темой в GNOME будут выглядят нативно.
Если надо нарисовать иконку, в Qt есть специальный метод передаешь ему имя иконки, и он возвращает иконку для текущей темы, как для гномовской, так и для кдешной.
Диалоги открытия/сохранения файла в Qt вообще автоматом выбираются, в GNOME показывается гномовский в KDE кдешный. За это тролям/нокии низкий поклон. Еще б GTK-шники сделали такое.
мне последняя опера нравиться - там ни qt ни gtk - а диалог выбора файлов можно и кдешный и ктшный и гткашный юзать =)
вообще давно пара стандартизировать как-то диалог выбора/сохранения файлов в иксах...
вообще давно пара стандартизировать как-то диалог выбора/сохранения файлов в иксах...
От рук разработчиков зависит. Некоторые софтины никакими стилями не заставить выглядеть нормально(пси, кутим), а на скринах ваших всё хорошо.
сколько кутимом под гномом пользовался(и не только под гномом, а даже в самомборке на открытой коробке), всегда он нормально выглядел, в стиль установленной теме(по крайней мере ветка 0.2)
ну в симбиане и wm qt немного другой - надо будет ещё кучку правил учитывать для лучшей портабельности. насчет всем как всегда не надо, не всем - у меня вот моторолка была со всем софтом на qt (версии 2.8 правда)
<зануда>имелось ввиду, что один и тот же бинарник может менять внешний вид в зависимости от используемого окружения и темы, под винду и мак ось нужно отдельно собиратьзануда>
А вообще, совет тс'у: не парься и пиши на qt :) Если пользователь захочет поставить твоё приложение, установить по зависимостям libqt - ерунда, она весит-то
- 5,1 Мб, в наше время это ерундовый размер. В отличии, например, от kdelibs.
$ apt-cache show libqtcore4 libqtgui4 | grep '^Size' | awk '{ print $2}'
1504974
3616502
- 5,1 Мб, в наше время это ерундовый размер. В отличии, например, от kdelibs.
да нет... меня библиотеки в плане чего бесят...
вот понравилась мне программка, я ее захотел домой отнести. приношу, а она мне и говорит человеческим голосом - пока не поставишь то-то и то-то запускаться не буду...
Ну хорошо, на следующий день я ей и приношу то-то и то-то, а этот то-то и то-то мне и говорит - а мне для работы нужно перетот и перетот...
Приходиться опять отлаживать установку программы и нести с работы библиотечку...
А дома интернетов у меня нету =(
вот понравилась мне программка, я ее захотел домой отнести. приношу, а она мне и говорит человеческим голосом - пока не поставишь то-то и то-то запускаться не буду...
Ну хорошо, на следующий день я ей и приношу то-то и то-то, а этот то-то и то-то мне и говорит - а мне для работы нужно перетот и перетот...
Приходиться опять отлаживать установку программы и нести с работы библиотечку...
А дома интернетов у меня нету =(
недавно на линуксе?
обычно это по началу раздражает а потом наоборот.
ну а домой с работы лучше срез репы носить =)
обычно это по началу раздражает а потом наоборот.
ну а домой с работы лучше срез репы носить =)
та да... недавно...
С одной стороны, конечно, когда есть куча вариантов это хорошо
Но с другой стороны... пока для себя выберешь... а особенно если не знаешь что можно достроить что-то руками в конфигах или (о ужас!) при компиляции....
Хорошо хоть ГугльХром под линухами есть =)
С одной стороны, конечно, когда есть куча вариантов это хорошо
Но с другой стороны... пока для себя выберешь... а особенно если не знаешь что можно достроить что-то руками в конфигах или (о ужас!) при компиляции....
Хорошо хоть ГугльХром под линухами есть =)
а для среза репы флешка нужна большая - опять-же покупать нужно =(
за неделю унесешь и на флехе в пару гиг. накрайняк из дома винт возьмешь =)
В век, когда исошники двд кочают браузером за 5 минут, 44 Мб кделибс выглядят смешно.
в век когда имеются нетбуки с ssd по 4Гб, 44Мб кделибс(в нераспаковонном виде?) немного напрягают - не надо всех под одну гребенку, плз. а ещё часть их кделибс будет в памяти висеть - а не всегда есть возможность планку памяти добавить
вот поэтому нам сейчас и приходиться покупать терабайтные hdd, гигабайты ram и многоядреные многогигагерцовые cpu...
:-)
:-)
когда говорят прогресс, всегда уточняйте прогресс чего (© Станислав Ежи Лец)
скорее регресс: сколько себя помню... в общем мой текущий комп раз в 16-20 мощнее того, о котором я мечтал всего лет 10 назад. причём сегодня мой комп немногим лучше бюджетного (по моему мнению) а мечтал я в то время о вполне топовом компе.
так вот, (к чему я всё это? ах, да...) а счастья всё равно нету :-( всё как тормозило -- так и тормозит. на современном железе реально быстро работает только софт возрастом лет 5 и старше...
короче: ныть можно долго, но факт остаётся фактом -- с тех пор, как за IT взялись торгаши (бизнесмены) реального развития нет. вся отрасль тупо топчется на месте. никакого качественного развития нет. только количественное...
всё ИМХО...
так вот, (к чему я всё это? ах, да...) а счастья всё равно нету :-( всё как тормозило -- так и тормозит. на современном железе реально быстро работает только софт возрастом лет 5 и старше...
короче: ныть можно долго, но факт остаётся фактом -- с тех пор, как за IT взялись торгаши (бизнесмены) реального развития нет. вся отрасль тупо топчется на месте. никакого качественного развития нет. только количественное...
всё ИМХО...
а давайте ещё ногу сравним со всем организмом.
qt - фреймворк с кучей всего
wxWidgets всего лишь гуевые выджеты, т.е. сравнивать тогда уж с qtgui но никак не со всем qt
qt - фреймворк с кучей всего
wxWidgets всего лишь гуевые выджеты, т.е. сравнивать тогда уж с qtgui но никак не со всем qt
Про Qt vs vs GTK vs wxWidgets vs ... полно информации в гуглнете.
Qt vs wxWidgets - Результатов: примерно 153 000
Qt vs GTK - Результатов: примерно 134 00
GTK vs wxWidgets - Результатов: примерно 27 300
Qt vs GTK - Результатов: примерно 134 00
GTK vs wxWidgets - Результатов: примерно 27 300
Можно было и без циферок обойтись. Я какбе понимаю что "в этих ваших интернетах" есть куча разных сравнений. Некоторые я уже даже прочитал. Интересно мнение кого-то поближе. кому можно задать вопрос.
Я боюсь вместо мнения, будет очередной флейм, тема уж больно опасная, особенно GTK vs Qt/KDE. С другой стороны уже 80 постов и все корректные, что очень приятно.
Еще не стои забывать, про look and feel у многих популярных проектов это больное место, особенно gtk программы в kde. Выглядит и работает просто ужасно. Иногда бывают глюки которые вообще не позволяют работать например в Eclipse была проблема с созданием проекта кнопку просто не возможно было нажать, не срабатывал обработчик, естесвенно подпорки были, но всеже ... когда надо ехать а тут такое. Вообще не понимаю тех кто использует gtk , для кроссплатформенности qt по лучше будет, ко всему имеет более продуманные, красивые и аккуратные виджеты, а не найденные на помойке истории в году 95(в этом gtk только motif обгоняет)). Взгляните на гномовский диалог открытия файлов без слез смотреть нельзя, им только текстовые файлы открывать.
Вообще, у GTK с кроссплатформенностью сильно хуже, а жаль. А вот с виджетами похоже работа сейчас пошла (не знаю, с чем это связано, но гном медленно, но довольно верно встает на нужный курс (юзабилити) )
Пока я прогресса не вижу, сам гном конечно совершенствуется и в нем есть приятные штуки но библиотека на которой он основан, по прежнему антиквариат. Вообще бы это уже давно умерло, если не исторический GPL фанатизм связанный c gtk. Еще такой выбор как раз таки тормозит создание качественных с точки зрения интерфейсов продуктов, особенно коммерческих, очень много усилий надо потратить... опера только сейчас подобралась к решению этой проблемы( и хочу заметить весьма успешно). Сколько лет им понадобилось. Возможно было бы решением использовать еще слой абстракции который бы сам выбирал библиотеку в зависимости от наличия в системе. Ни кто не в курсе про это если уже что-то такое? Правда я так понимаю Qt это уже умеет :).
Во-вторых, использование тулкитов GTK и Qt != использованию библиотек GNOME и KDE. Просто девелоперам под линукс проще работать с DEшными библиотеками, для пущей интеграции приложения в рабочий стол.
Запихай библиотеки в собственную программу, в чем проблема-то?
переведи.