Что будет в QT4

И, к тому же, уважаемый alphex, не в обиду будет сказано, но с Вашими перлами типа sprintf в однобайтовый массив я бы даже на C++ не рисковал бы писать, Java/C#, пожалуй, тут будет самое то что надо :-))

покопавшись в доках к gtk и qt я понял что с gtk прийдется возится больше а выгода не очевидна. смысл? а подход как в tv мне был всегда ближе =)

chl

Господин RON если б вы читали внимательней то поняли почему это не только религия.

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

ДА и к вопросу - кому что удобно , вопрос что в gtk есть альтернатива в qt ее нету - следовательно не только для меня qt идет лесом - как тут выражаються.

> qt API для C есть ? нету, по сему как вы выражаетесь лично для меня идет лесом. А вот gtk и C и C++ и еще много чего, так что о возможностях не надо.

А в C классы есть? А шаблончики? нету, так что лично для меня идет лесом =)

А вообще кстати есть Qt-биндинги для C. Вот вам ссылка: http://prdownloads.sourceforge.net/qtcsharp/qtc-qtsharp-0.7a.tar.bz2?download

> Потом кто сказал что KDE работает ,быстрее Gnome ? наоборот - а почему - потому как на C обычном написано.

Я сказал. А почему? А потому, что написано грамотно. И вообще, BeOS видел? Тоже вот на C++ написано. Но работает быстрей и Gnome, и KDE.

gtk - да согласен не просто, но окгда разберешся не сложнее чем qt. Но кроме как в плюсах писать с qt нельзя - следовательно - читаем выше=)

2int19h ООП это метод программирования прежде всего, кстати вами не любимый gtk это показатель как на C можно использовать этот метод.

BeOS? видел мельком - и что? Что там есть ? Подробней тут.

> gtk - да согласен не просто, но окгда разберешся не сложнее чем qt.

Однако! Писать гуй в сях теперь легче чем в плюсах? Интересная точка... эээ ... зрения =)

> Но кроме как в плюсах писать с qt нельзя - следовательно - читаем выше=)

Во первых сами читайте выше, во вторых есть еще как минимум PyQT - тоже кстати замечательная вещь.

А ты вот лучше покажи достойную IDE под (и, желательно, на) Gtk. Для Qt есть KDevelop. Для PyQT - Eric3. А Gtk'шные проги вы мне предложите в виме писать?

> 2int19h ООП это метод программирования прежде всего, кстати вами не любимый gtk это показатель как на C можно использовать этот метод.

Можно. Его и на ассемблере можно использовать. Так же, как плац мести можно метлой, но некоторые предпочитают ломом...

> BeOS? видел мельком - и что? Что там есть ? Подробней тут.

Все там есть. И написано оно на C++, и весь системный API там тоже на C++. И работает так шустро, что всяким там линухам и не снилось.

Да, сразу оговорюсь. То, что я люблю Qt, вовсе не значит, что я не люблю Gtk (а точнее, Gtkmm). Просто Qt (и вообще C++ по сравнению C для написания GUI-приложений) мне по ряду причин нравится больше.

2int19h - а как же anjuta+glade ?

хотя сам пишу как неоднократно писал в jed - нравиться мне так - это дело привычки и дело каждого, посколько ide всякие не люблю - кому то да удобней ide - а кому то нет - привыкать надо к новому.

У меня анюта пока не заработала ни разу. Запускаю, создаю новый проект, пытаюсь собрать - выдает кучу ошибок. Что-то там с automake/autoconf...

А Glade после QtDesigner'а как-то не радует =)

>а qt API для C есть ? нету, по сему как вы выражаетесь лично для меня идет лесом. А вот gtk и C и C++ и еще много чего, так что о возможностях не надо.

я в десятый раз говорю уже: есть. Называется QTC. Живёт или в kdebindings или в kdesdk.

Вы хоть посмотрели бы сначала, прежде чем ругаться!

> посколько ide всякие не люблю - кому то да удобней ide - а кому то нет - привыкать надо к новому.

Ну извините =) Тяжелое MFC- и WinForms-наследие дает о себе знать. KDevelop/QtDesigner конечно не замена Visual Studio, но уж всяко ближе к ней, чем всякие "programmer's text editors".

> я в десятый раз говорю уже: есть. Называется QTC. Живёт или в kdebindings или в kdesdk.

Отдельно оно тоже живет, точнее, его вариант, не завязанный на KDE (т.е. в депах только Qt). Я выше ссылку давал.

>хотя сам пишу как неоднократно писал в jed - нравиться мне так - это дело привычки и дело каждого, посколько ide всякие не люблю - кому то да удобней ide - а кому то нет - привыкать надо к новому.

И скрин одгого из этих творений здесь пробегал... :-)

нету у меня такого наследия, не писал Я под винды.

При чем тут наследие - jed - очень хорошо - настроил хоткеи - открыл нужные буферы - make умеет - запустить бинарник тоже - так и что?

а уж что к emacs прикрутить можно вообще молчу =)

QTC - есть - все извиняюсь;

скрин? а что в нем ужастного то ?

http://www.linux.org.ru/profile/alphex_kaanoken/view-message.jsp?msgid=476479

ты про этот чтоли? так удобно - то что надо одновременно видеть то вижу: плюс там еще в буферах то что надо валяеться.

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

chl

>А ты вот лучше покажи достойную IDE под (и, желательно, на) Gtk. Для Qt есть KDevelop. Для PyQT - Eric3. А Gtk'шные проги вы мне предложите в виме писать? <

QIDE - commercial Glade+Anjuta - free

читай повнимательней прежние пость?

ну я уже написал. вот был tv борландовский. а до него еще пакет был, запамятовал, я им не пользовался но подход был как в gtk. для меня непонятно зачем пытаться вытягивать необъектный язык через такую жопу что удивляешься. ради биндингов? нах биндинги если я оригинальный язык знаю? не катит. ради кроссплатформенности - это я принимаю. но когда мне сверхкроссплатформенность не нужна (а на скольких платформах qt идет?), то отсутвие документации имеет большое значение. а например вспомогательные классы типа QString? ну и т. д. а разбираться в гтк... зачем? =)

chl

>> скрин? а что в нем ужастного то ?
>>
>> http://www.linux.org.ru/profile/alphex_kaanoken/view-message.jsp?msgid=476479
>>

Ужасно писать функции с 12-ю параметрами.
По магазинам уже больше года лежит известная книжка Фаулера/Бека про рефакторинг - прочитайте её как-нибудь вместо манов, может окажется полезно.

win 95 поставь - он у тебя тоже будет шустро работать.

xlib-ские видел? они видимо тоже не читали=)

можно было два параметра - урезанная структура и указатель на список - мне так неудобно : сначала ее заполнить замаллочить и тд и тп - вообщем тут то не надо.

>> мне так неудобно
>>
>> entr[0] = malloc(4);
>> sprintf(entr[0], "%d", pointer->cid);

А подстраховаться от переполнения через snprintf вместо sprintf Вам тоже неудобно?

Я это уже давно поправил

>нах биндинги если я оригинальный язык знаю?

Биндинги нужны не только для портабельности.

1) Скрипты не надо перекомпилировать => быстрее идет работа. Плюс к этому скрипты можно менять прямо на лету.

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

Кроме того, биндинги легко пишутся и для C++ API, так что использовать для этого C-only не обязательно.

1) да это так

2) ну такие любители иногда излишни

далее скрипты есть скрипты - скорость и прочее - можно и не продолжать даже дальше.

>2) ну такие любители иногда излишни

Ну, я говорю о биндингах вообще :-) В game development, например, скрипты пишут обычно дизайнеры, которые не обязаны знать C, C++ и т. п..

>далее скрипты есть скрипты - скорость и прочее - можно и не продолжать даже дальше.

Иногда приходится немного уступить в скорости для получения большей гибкости. Ну а для небольших GUI приложений потери в скорости вообще не будут заметны на современном железе.

>В game development, например, скрипты пишут обычно дизайнеры, которые не обязаны знать C, C++ и т. п..

не могу не согласиться

>Иногда приходится немного уступить в скорости для получения большей гибкости. Ну а для небольших GUI приложений потери в скорости вообще не будут заметны на современном железе.

там да, Я про крупный проекты говорил.

> нету у меня такого наследия, не писал Я под винды.

Я про себя говорил.

> При чем тут наследие - jed - очень хорошо - настроил хоткеи - открыл нужные буферы - make умеет - запустить бинарник тоже - так и что?

Как насчет project management?

> win 95 поставь - он у тебя тоже будет шустро работать.

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

> xlib-ские видел? они видимо тоже не читали=)

Не читали. Давно кстати известный факт =)

>Как насчет project management?

autoconf/automake?

... ах да, забыл, и чтоб все это мышкой =)

> А Glade после QtDesigner'а как-то не радует =)

Подскажи как в designer'е сделать растягивающиеся диалоги, чтобы ручками не добавлять layot'ы и stretch'и?

> А вообще кстати есть Qt-биндинги для C.

Нужен плюсовый линкер?

> Подскажи как в designer'е сделать растягивающиеся диалоги, чтобы ручками не добавлять layot'ы и stretch'и?

Эээ... а зачем? Они ж вроде для того и нужны.

> Нужен плюсовый линкер?

Да, нужен. Впрочем, если ты пользуешь GCC - он там все равно один на всех. Но тут требовали возможность писать Qt-приложения на C - так вот она имеется. То, что в депах идут плюсовые библиотеки, не оговаривалось =)

Например, надо, чтобы кнопки ok и cancel были всегда внизу справа независимо от размера окна. То есть в общем как из дизайнера достучаться до какого-нибудь geometry manager'а (есть ли плагин или в стандартной поставке что-нибудь надо включить)?

Да, еще. Чем отличаются QHBox и QHBoxLayout? Зачем надо было вводить новое понятие (layout), когда можно было обойтись одними виджетами?

Есть у меня знакомый фанатик beos... Как она работает на новых процах...
Об amd x86-64 там даже не заикаются.

Она интересная, но не более того и быстро работает именно по старости.

Беось и новые много чем уделывала.

Одна 64-битная ФС чего стоила...

>> "Зачем надо было вводить новое понятие (layout), когда можно было обойтись одними виджетами?"

А вот когда ты станешь большим и будешь читать умные книжки по ООД, то тогда ты это узнаешь :-))

Сорри за подъ@@ку, я это не со зла :-))

> А вот когда ты станешь большим и будешь читать умные книжки по ООД, то тогда ты это узнаешь :-))

Читаем умную книжку "Паттерны проектирования". В первой или второй главе узнаем про глифы, далее смотрим на qt, и задаем себе тот же вопрос, зачем нам две ручки, когда все нормально крутится одной.

> Сорри за подъ@@ку, я это не со зла :-))

Я понимаю, это ты по незнанию. :)

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


Ну так найдите время и прочитайте эту книжку дальше второй главы - возможно узнаете ответ :-))

Ну ты меня заинтриговал. Во второй главе описаны все основные концепции, а далее уже детали идут. Ну, давай, говори. Я же знаю, что там ответа все-равно нет. :) Интерфейс QWidget процентов на 99 покрывает интерфейс QLayout, и я не вижу причин как-то их разделять.

> Она интересная, но не более того и быстро работает именно по старости.

Ну что ты хочешь от операционки, которая уже несколько лет как скончалась? Но если сравнить беось с тем, что было в ее время - выигрывала по всем параметрам. Тогдашний линух рядом не стоял. 64-битная журналирующая ФС с атрибутами, юникод, продвинутые (и удобные!) объектно-ориентированные API для работы со всем, о чем можно подумать. Очень удобный, красивый, и при этом быстрый GUI - и в то же время вся мощь консоли в POSIX-совместимой системе. И все - на С++...

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

>> "Интерфейс QWidget процентов на 99 покрывает интерфейс QLayout, и я не вижу причин как-то их разделять."

Ну так никто же лично тебя и не заставляет. Пиши так, как тебе удобно. Just-for-fan всё-таки. :-)))

>> "Во второй главе описаны все основные концепции, а далее уже детали идут."

Если ты так со всем с чем работаешь разбираешься, то искренне желаю тебе творческих успехов :-))

>> "если все так зашибись, почему оно не стоит у меня на рабочем месте?"

Я сильно подозреваю, что это больше связанно с твоим рабочим местом, а не с качеством той или иной железки :-)))

> Ну так никто же лично тебя и не заставляет. Пиши так, как тебе удобно. Just-for-fan всё-таки. :-)))

А мыслишки-то куда девать? :)

> если все так зашибись, почему оно не стоит у меня на рабочем месте?

Если это вопрос по поводу беоси - то у ребят маркетинг просто хреновый был. Ну и поддержка железа подкачала. А так, если б его довести до ума - был бы у нас MacOS X для PC =)

2int19h - autoconf/automake - ка ктебе выше сказали - совместная работа над проектом CVS+свои писанные скрипты для удобства.

А чтобы все мышкой - ??? зачем??? ты программист или кто? код ты тоже мышкой писать будешь ? блин изврат мышкой это все ...