Статья Qt vs Gtk... + вопросы...

>Tk - разве не пример? libglade - не пример?

Ты хотя бы их использовал малыш?

А Delphi ты только как другие использовали видел?

Чем же libglade протеворечит ООП? Он его просто дополняет. Похожий подход используется кстати и в Delphi.

А tk, tk никто не использует, просто интерфейс очень убогий.

>Чем же libglade протеворечит ООП?

например скрывает механизм наследования/иерархию обьектов Гтк вместо которой строит свою собственную иерархию неимеющую ничего общего с ООП

Соплячонок завонял, что Tk никто якобы не использует, по причине отсутствия свистелок и перделок. Соплячонку пора бы повзрослеть и узнать, что свистелки и перделки - не самое главное в интерфейсе.

Можно. Вот где читай, там про всякое:

http://www.opennet.ru/base/dev/linux_dialog.txt.html

http://directory.fsf.org/Xdialog.html

http://freshmeat.net/projects/xdialog/

http://xdialog.dyns.net/

тут про змяю:

http://www.chrisarndt.de/en/software/python/

тут про кеды

http://developer.kde.org/documentation/tutorials/kdialog/t1.html

ну и вот в довесок

http://rubyforge.org/projects/kdialog/

а ваще - man google

ty hot' odno komercheskoe graphicheskoe prilozhenie razrabotal malysh?

Буковки русские настрой, дитятко.

Я делал GUI ещё во времена Motif, юзеры не жаловались. Я видел очень большие и навороченные корпоративные системы с тонкими клиентами на Tcl/Tk - юзеры были весьма довольны, они же не дети, чтоб на свистелки и перделки внимание обращать, им важно юзабилити, хоткеи удобные, возможность настройки шрифтов и контрастности.

И, кстати, какое отношение внешний вид Tk имеет к его ни разу не ООПному API? Можешь объяснить, фигли ты завоняло, жывотное?

Лучше использовать FLTK :-) Правда.

P.S.: Нервный фанат Tcl/Tk, ты жуткое хамло. Если хочешь доказать свою правоту, не начинай с оскорблений.

Не может быть большего хамства, чем проявление глупости и упёртости в споре.

Сам посуди, можно ли относиться как к человеку к тому, кто в ответ на пример объективно очень компактного не-ОО API для GUI начинает обсуждать внешний вид этого тулкита? Разве такое безмозглое жывотное можно причислить к роду человеческому, и говорить с ним, как с человеком?

2bugmaker

большое тебе спасибо багописатель! :))) шутка, и вправду сенкс!

>Я делал GUI ещё во времена Motif, юзеры не жаловались. Я видел очень большие и навороченные корпоративные системы с тонкими клиентами на Tcl/Tk - юзеры были весьма довольны, они же не дети, чтоб на свистелки и перделки внимание обращать, им важно юзабилити, хоткеи удобные, возможность настройки шрифтов и контрастности.

Да прибудет с тобою сила... кхе... :)

Кстати, а почему "во времена Мотиф..." многие и сейчас на нем пишут и говорят, что лучше нет...

жаль по ГТК нет на русском доки хорошей. По КуТе на опеннет, лежит хороший учебник, и еще один нашел в магазине даже в печатном виде...

В те времена ему альтернативы не было.

Зато есть хорошие примеры на нерусском. Примеры всегда лучше любой документации.

>Зато есть хорошие примеры на нерусском. Примеры всегда лучше любой документации.

даш ссылку? или ты про туториал, что на сайте гтк.орг лежит?

Книжка по библиотеке для создания интерфейса - это уже слишком :) давайте ещё по молоткам и плоскогубцам книжки продавать. Любуюсь томиком по MFC на 900с на полке соседа - о чём там столько писать?..

erdizz

Да наздоровье. В гугль заглядывай, там ещё мнооозе всево.

>Книжка по библиотеке для создания интерфейса - это уже слишком :) давайте ещё по молоткам и плоскогубцам книжки продавать.

Хотел я было поинтересоваться, не жмёт ли череп, потом вспомнил, ах да - как же, ведь Открытый Код Позволяет Девелоперу Разбираться В Деталях... И по мотифу, и по гтк, и тем более по кутэ очень даже необходимы книжки для разработки чего-то большего, чем хелло, ай эм пушбатон, клик ми. Нормальным людям необходимы, я имею в виду. В любом виде - текстовом ли, электронном, одними манами не обойдёшься.

>Книжка по библиотеке для создания интерфейса - это уже слишком :) давайте ещё по молоткам и плоскогубцам книжки продавать. Любуюсь томиком по MFC на 900с на полке соседа - о чём там столько писать?..

почему собственно? пусть не книжка, пусть буклет, ховту, инструкция по эксплуатации :)

в продолжение если кому интересно, пара обзоров Qt и GTK (1) соответственно...

http://www.computerra.ru/print/softerra/freeos/22309/

а знаеш почему сейчас никто не защищал Гтк. Ибо народ знающий ГТК делом занят а народ знающий Qt без дела по нету шарится по причине невостребованности онного .... ;-)

ЗЫ: программы написанные на gtk имеют более предсказуемое поведение, а также гтк позволяет программеру более сильно/глубоко контролировать поведение приложения. А сотворить для Qt аналог libGlade для Гтк задача весьма нетривиальная если вообще решаемая.

Ответ в стиле "когда все программеры на Qt уже все написали и шарятся по инету, программисты на гтк прододжают писать, писать и писать..."
Не аргумент, одним словом...

кстати а gtk ещё умеет "риалтайм рендеринг" а с Qt говорят траблы

Не надо про риалтайм. Было уже здесь неоднократно про риалтайм обсуждение. Ни к чему хорошему это не приведет, в особенности
когда про конкретную задачу ничего не известно. Туда же и аргументы
про Glade - нафига Qt что-то повторять? Мне не нравится спор не по-существу. Кто-то выучил Gtk - молодец. Кто-то выучил Qt- тоже молодец. Кто-то пишет на Tcl/Tk - возьми с полки пирожок.
Человек, однако писал:
> - я ни разу не программист. (Qt - легче и быстрее изучить)
> - работе с железом (разные приборы) (по барабану)
> - математическим рассчетам (научные рассчеты) (по барабану)
> - базам данных (в Qt - есть API для этого)
> - гуи (Qt - очень качественно сделан)
> - сетям (в Qt - есть удобный и простой API для сокетов)

Человек ни разу не писал про Glade или realtime rendering? Хренли тогда?

>Человек, однако писал:
>> - я ни разу не программист. (Qt - легче и быстрее изучить)
не для меня
>> - работе с железом (разные приборы) (по барабану)
я бы не пытался работать с железом на С++
>> - математическим рассчетам (научные рассчеты) (по барабану)
На С математика быстрее если не использовать левых либ
>> - базам данных (в Qt - есть API для этого)
К гтк тоже что-то приклеено, что именно забыл.
>> - гуи (Qt - очень качественно сделан)
не знаю. давно не юзал
>> - сетям (в Qt - есть удобный и простой API для сокетов)

Ну опять ты подменяешь вопрос.
>не для меня
Речь-то не про тебя. Средне статистическому программеру легче
изучить Qt. Не конкретно тебе, а сферическому программеру, живущему в
в Линухе, к коей категории с большей вероятностью относится автор топика.
>я бы не пытался работать с железом на С++
Если речь не идет о модулях ядра (похоже, что не идет или будешь спорить?) - то особой разницы нет. Хотя, конечно,любую идею можно довести до абсурда.
>На С математика быстрее если не использовать левых либ
Однако обоснуй! (с) На сколько быстрее и почему.
>К гтк тоже что-то приклеено, что именно забыл.
Вот именно - где-то чего-то с боку приклеено или привязано как консервная банка к хвосту. В Qt - это часть концепции переносимого API
и поддержано документацией, кому угодно доступной.
>не знаю. давно не юзал
Вот зачем эта фраза - хоть убей не пойму... Очень, очень убедительно...

>>я бы не пытался работать с железом на С++

>Если речь не идет о модулях ядра (похоже, что не идет или будешь спорить?) - то особой разницы нет. Хотя, конечно,любую идею можно довести до абсурда.

а помоему есть. первое при том же обьёме кода будет намного медленее компилится С++ версия.

>>На С математика быстрее если не использовать левых либ >Однако обоснуй! (с) На сколько быстрее и почему.

ибо так проще оптимизировать код по скорости выполнения. Код С++ слишком абстрактный чтобы говорить о оптимизации.

>>К гтк тоже что-то приклеено, что именно забыл.

>Вот именно - где-то чего-то с боку приклеено или привязано как консервная банка к хвосту.

;-)

>В Qt - это часть концепции переносимого API и поддержано документацией, кому угодно доступной.

если пишем для десктопа то оно гдето так а если нас интересуют встраиваемые системы и токо БД то попробуй отвязатся от "концепции переносимого API" ;-) особенно если у нас 32 МБ ОЗУ и такая же флешка в military исполнении.

>>не знаю. давно не юзал

>Вот зачем эта фраза - хоть убей не пойму... Очень, очень убедительно...

покрайней мере здесь надо было понять что по етому пункту я никого нивчём не убеждаю

>если пишем для десктопа то оно гдето так а если нас интересуют встраиваемые системы и токо БД то попробуй отвязатся от "концепции переносимого API" ;-) особенно если у нас 32 МБ ОЗУ и такая же флешка в military исполнении.

Qt-embedded нервно курят в сторонке. Familliar/qtopia повесились на шнурках от блоков питания своих айпаков. Дальше продолжать?

>ибо так проще оптимизировать код по скорости выполнения. Код С++ слишком абстрактный чтобы говорить о оптимизации.

Можно конечно закодировать формулу через дерево абстрактных функторов
с перегруженными виртуальными методами вычисления унарных и бинарных операций... Эхххх! Мощаа! Было ведь время студенческое! Только в жизни никто так не делает. Если что-то нужно считать, то формула будет закодирована жестко. И тут я не вижу препятствий для оптимизации.

Пойми меня правильно - я не наезжаю на гтк. Просто есть куча успешных проектов на Qt и народ вполне доволен. Особенно удобно, что там много полезных вещей именно в одном флаконе и обернуто в удобный API. Возможность автоматизированной (не автоматической, а именно автоматизированной) сборки мусора, локализация, переносимость (сам пробовал - между Linux и VS - работает).

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

ЗЫ: Я как-то работал в одной конторе. Там довольно долго была вакансия со списком требований:
- знание С/С++
- Линух
- опыт программирования под Хы
- ОпенГл
- Корба
- девушка до 25 лет

В общем, что хочу сказать, многим людям, и лично мне в том числе весьма сомнительны преимущества QT перед GTK именно по причине того, что QT написана на С++. Профилирование и отладка приложений на сях - например, в случае использования motif/Xt это не сахар, особенно в случае cпецифических асинхронно передающихся ошибок Xов, но тот лист функций, что каждый может увидеть запустив gprof для ЛЮБОЙ qt программы - является лучшей анти-рекламой c++ вообще и qt в частности.

Я как-то поэтому с опаской отношусь к qt, хотя что там говорить - смотрится красиво, и если верить мануалам, и уже даже русскоязычным переводным и родным авторам - вроде бы да, красиво. Но это мануалы - и известные примеры, у тебя будет красивый интерфейс со всеми финтифлюшками, а что если возникнут проблемы? Выполнение кода в спп начинается не с main() а с инициализации глобальных объектов и прочей вовсе не очевидной ерунды... Вызовы каждого "метода" обвязаны десятком обёрток... Между тем средства отладки, как правило, ориентированы на реальный язык - на с - тот же gdb для примера.

Так блин, закругляюсь, "что хотел сказать-то" - что выбор в пользу qt далеко не очевиден, как минимум. Если вы ребята знаете в тонкостях особенности компилирования g++ - то вперёд, к вершинам, а так, если получилось пару красивых диалогов за пару дней создать ("с 70ю формами" - sic!) - это ещё ни о чём не го во р и т.... :-)

19.9: Is C++ a superset of C? Can I use a C++ compiler to compile C code?

C++ is a superset of something, we're not sure what. You can use a C++ compiler to compile C code, but the results may surprise you. (c) IFAQ comp.lang.c

"Если это хорошо - что сомнительно, то чем же это хорошо, а если это плохо - что наиболее вероятно - то чем же это плохо" (с) классик.

:-)

>жалко нельзя писать ГУЙ на баше :)))
xdialog

Да, кажется уже написали - чем хорошо. 
- Красиво
- Легкий старт
- Наиболее полный комплект по запрошенным фичам (см первое сообщение)
- Поддержка документацией, в т.ч. и русской, печатной.

По поводу профайлинга... Сама постановка вопроса подразумевает некий 
уровень владения темой - так? И в чем проблема? gprof нормально работает как с С++, так и с Qt. Пример:

bash-2.05b$ cat hello.cpp 
#include <qapplication.h>
#include <qpushbutton.h>
#include <iostream>
#include <fstream>

class MyButton : public QPushButton
{
   Q_OBJECT
   public:
      MyButton(QWidget* p = 0) : QPushButton(p)
      { 
         setText("Press me!"); 
         show();
         connect(this,SIGNAL(clicked()),this,SLOT(slotWriteLog()));
      }
   public slots:
      void slotWriteLog()
      {
         std::ofstream log("log",std::ios::app);
         log
            << "User pressed button!" 
            << std::endl;
      }
};

int main(int ac, char** av)
{
   QApplication a(ac,av);
   MyButton b;
   a.setMainWidget(&b);
   return a.exec();
}

#include "hello.moc"

bash-2.05b$ gprof hello     
Flat profile:

Each sample counts as 0.01 seconds.
 no time accumulated

  %   cumulative   self              self     total           
 time   seconds   seconds    calls  Ts/call  Ts/call  name    
  0.00      0.00     0.00      249     0.00     0.00  QShared::deref()
  0.00      0.00     0.00       11     0.00     0.00  MyButton::staticMetaObject()
  0.00      0.00     0.00        5     0.00     0.00  MyButton::slotWriteLog()
  0.00      0.00     0.00        5     0.00     0.00  QMetaObject::slotOffset() const
  0.00      0.00     0.00        1     0.00     0.00  _GLOBAL__I_main
  0.00      0.00     0.00        1     0.00     0.00  __static_initialization_and_destruction_0(int, int)
  0.00      0.00     0.00        1     0.00     0.00  QString::~QString [in-charge]()
  0.00      0.00     0.00        1     0.00     0.00  MyButton::MyButton[in-charge](QWidget*)
  0.00      0.00     0.00        1     0.00     0.00  MyButton::~MyButton [in-charge]()

По-моему все здесь читаемо...

Объектно-ориентированный C,
выглядит как огромный костыль,
стоит только взглянуть на код gtk+.

То что вы не смогли выучить C++ ни о чем не говорит.

>C++ is a superset of something, we're not sure what. You can use a C++ compiler to >compile C code, but the results may surprise you

вообще-то раньше ядро собирали g++.

Ты баран. Тебе тут не место.

Размер списка огласи, после намекай на "владение предметом".

баран это ты

> - я ни разу не программист. (Qt - легче и быстрее изучить) > - работе с железом (разные приборы) (по барабану) > - математическим рассчетам (научные рассчеты) (по барабану) > - базам данных (в Qt - есть API для этого) > - гуи (Qt - очень качественно сделан) > - сетям (в Qt - есть удобный и простой API для сокетов)

Я так понимаю, что с GTK решается только пункт про ГУЙ из этого списка?

>Человек ни разу не писал про Glade или realtime rendering?

я пока даже не знаю что это :(

2cvv

>На С математика быстрее если не использовать левых либ

А какие вообще в С есть математические библиотеки кроме math.h? Она бедновата... хочется чего-нибудь сопоставимого с фортраном, хотя бы 77 :)

Вопрос как знатоку ГТК. Есть ли там возможность выводить графики, и желательно бегущие... То-есть допустим число меняется от времени, и согласно этому времени на экране ползет график величины числа...

2Flogger_d

по поводу QT у меня есть одно сомнение на данный момент, не считая C++. У меня есть коллега, вобщем того же рода "программер" что и я, но он решил писать все на КуТе... Програмки и вправду пишутся быстро, но вот работают не очень. Собирается все через КуМэйк, после чего все работает и показывается, но когда возникают вопросы, непонятно куда копать. Вернее понятно, что нужно таки начинать скурпулезно читать доки :) Почитав учебник по ГТК я понял, что там скурпулезно надо читать с самого начала... Вот и пойми что лучше. Сразу или потом...

Всем баранам и прочим овнам, к коему огненному знаку и я отношусь, вот еще ссылочка: http://club.shelek.com/print.php?id=120

статья из трех частей по поводу ГТК2. Я так понимаю, что это попытка перевода туториала с gtk.org своими словами :)

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

Основные проблемы как правило бывают на стыке технологий. Например - гуи и сеть или гуи и долгая процедура или база данных и т.д. В случае зоопарка таких проблем будет очень много - как на уровне архитектуры проекта (как это все вместе будет работать) так и на уровне инструментов. В Qt эти проблемы в основном были решены в самом начале - кроме гуи там имеется апи для сетей, тредов, баз данных, т.е. все то, что тебе нужно и что ты перечислил в своем списке требований.

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

>> - я ни разу не программист. (Qt - легче и быстрее изучить) > - работе с железом (разные приборы) (по барабану) > - математическим рассчетам (научные рассчеты) (по барабану) > - базам данных (в Qt - есть API для этого) > - гуи (Qt - очень качественно сделан) > - сетям (в Qt - есть удобный и простой API для сокетов)

>Я так понимаю, что с GTK решается только пункт про ГУЙ из этого списка?

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

есть отдельная либа приклееная к ГТК предоставляющая единый интерфейс для работы с базами. имя забыл. собирал пол-года назад. я с базами работаю через фирменное/оригинальное АРИ.

>>Человек ни разу не писал про Glade или realtime rendering?

>я пока даже не знаю что это :(

1. Glade и libGlade - это разные вещи.

2. libGlade позволяет разделить программу(логику) и её интерфейс следующим образом: есть некий xml-файл описывающий интерфейс программы и действия которые должен выполнять каждый её елемент управления. при старте программы считывается етот xml - файл строится по нему интерфейс и программа работает. набор действий которые должна выполнять программа толи прошивается в программу толи подгружается ввиде модулей/либ. тоесть если нам надо изменить интерфейс программы или его поведение мы просто правим xml-файл и перестартовываем программу без всяких перекомпиляций пересборок и т.д. единственный недостаток - НЕМНОГО более медленный старт ибо надо считать с диска дополнительный конфиг.

реалтайм рендеринг ето когда надо чтобы рисунок на екране изменялся синхронно с какимто внутренним/внешним параметром а не тогда когда ядро подгрузит очередную страницу со свапа %-)

наглядный пример mplayer - в состоянии нормально проиграть любой фильм (mpeg4 divx5) на целероне 300 МГц /64 ОЗУ даже при полном отсутствии раздела подкачки без дёрганий, затыков, замираний, потери синхронизации и т.д. Написан на ГТК.

>>На С математика быстрее если не использовать левых либ

>А какие вообще в С есть математические библиотеки кроме math.h? Она бедновата... хочется чего-нибудь сопоставимого с фортраном, хотя бы 77 :)

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

>Вопрос как знатоку ГТК. Есть ли там возможность выводить графики, и желательно бегущие... То-есть допустим число меняется от времени, и согласно этому времени на экране ползет график величины числа...

вообщето можно и бежать будут шустро. Сколько на ето надо потратить времени и как ето делается не скажу ибо ни разу не делал. неудивлюсь если придётся рендерить вручную типа как под досом. возможно придётся написать свой виджет.

>Qt тебе даст более управляемый и предсказуемый код.

на етапе написания. На етапе выполнения здесь рулит ГТК так как получается полее управляемое и предсказуемое приложение иначе бы gtk_mm никогда не появился на свет по причине вероятной невостребованности.

>>На С математика быстрее если не использовать левых либ

>А какие вообще в С есть математические библиотеки кроме math.h? Она бедновата... хочется чего-нибудь сопоставимого с фортраном, хотя бы 77 :)

запусти гугль с ключевыми словами : free math lib linux

особенно обрати внимание на продукты intel

Либо по причине более свободной лицензии.

Про xml - тоже не нужно человеку мозги парить - он не собирается делать коммерческий продукт. И xml здесь - еще один слон в зоопарке технологий, причем явно не нужный. Так что рекомендация к использованию libGlade при разработке - в конкретном данном случае (именно в данном, а не вообще) -
скорее недостатов, а не достоинство.

Откуда такой фанатизм?

>Либо по причине более свободной лицензии.

здесь ты наверное более прав

>Так что рекомендация к использованию libGlade при разработке - в конкретном данном случае (именно в данном, а не вообще) - скорее недостатов, а не достоинство.

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

Но ты согласен, что к данному вопросу это никак не относится и в данном случае ее использование скорее вредно?