LINUX.ORG.RU

Какую widget-библиотеку по вашему мнению нужно использовать при разработке новых приложений?

 , , , ,


0

0

  1. qt 427 (36%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. gtk+ 422 (35%)

    ****************************************************************************************************************************************************************************************************************************************************************************************************************************

  3. только xlib 66 (6%)

    *************************************************

  4. motif 63 (5%)

    ***********************************************

  5. fltk 39 (3%)

    *****************************

  6. tk и др 30 (3%)

    **********************

  7. wmaker/gnustep 29 (2%)

    *********************

  8. не устраивает ни одна из существующих 26 (2%)

    *******************

  9. другую 21 (2%)

    ***************

  10. wxWindows 20 (2%)

    **************

  11. xview 15 (1%)

    ***********

  12. gtk-- 15 (1%)

    ***********

  13. xforms 13 (1%)

    *********

  14. athena/athena3d 5 (0%)

    ***

Всего голосов: 1191

★★★★★

Последнее исправление: CYB3R (всего исправлений: 1)

gtk+ уверенно лидирует. И это правильно. Она 1) портабельная, 2) красивая, 3) удобная для программиста, 4) враппится из почти всех распространенных скриптовых языков. Ну а Qt и прочая сиплюсовая фигня должна отойти в сторонку, и там тихонько помереть ;)

vsl
()

Ну вы и задали вопрос!

anonymous
()

Я предпочтаю портабельную (но пока глючащую) wxWindows (wxGTK)

eugeneai
()

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

anonymous
()

Naschet uverenno lidiruet , eto ti silno skazal ;)
A esli serjozno, to QT gorazdo stabilnee i prijatnee

regards

anonymous
()

Самое смешное, что дать Единственно Правильный Ответ в этом опросе МОЖНО. Но это будет НЕ ОДИН набор виджетов, т.к. есть как FSF, так и "Close Software Foundation" ;-} Из чего и следует сидение на двух стульях motif/gtk+ и смотрение на сцену, где имеет место быть Mozilla-style, из коего надо выкинуть изрядно излишеств. Вообще же, чтобы не устареть при программировании "кнопок" (приложений без 3d и графов), надо держать курс на builderы, генерирующие xml, а из него всю остальную труху html-c-java-gif-ps-... Программировать КНОПКИ слитно с алгорифмом на НЕдекларативном языке - анахронизм.

anonymous
()

Вот именно, XML, или списки, или еще что подобное (лучше, конечно, просто скрипт), но не ся с плюсами, как того хотят некоторые мяньяки, уважающие угребищную Qt...

vsl
()

GTK+? Но он все время мелькает(blinking) да и
медленный. C vs C++? -

Мама, ты проказница,
Я ж не мальчик, я же дочь
Все равно, какая разница,
Спи, мой мальчик, скоро ночь.

.....

А OpenGL в GTK+/gdk? Не геморрой?
А double_buffered windows? Вы герой!

На win32 работали-говно редкое-глупое, медленное,
но как же курсовые писать?

GTK+/win32 ? Но на 256-colors похо, не-dithered!

Исходники GTK+? Читайте, кайфуйте, материтесь!

Потоки в GLib? GPK? Быстро, современно ;-)

Вы пробовали в GTK+, Qt (etc) петлю раскидывания сообщений
_вне_ start_message_loop(etc) крутить ? Не нужно ?

Qt ? Но это-ж >=1000$ - дешево ;-) .....

Motiff? На P100/p200 ? Быстро ? По-пивку/водочке ?

C++-wrapper(wxWindows,etc)? Криво, неуверенно!

Вы помните старый, добрый DOS? Забыли?
Вы тогда думали о drawable/GDC?

Нафига думать и хранить/помнить о drawable/GDC ?
fl_color(0,255,0); fl_line(0,0,100,100);

P.S. С параздником(7-9 ноября)!
P.P.S. Patched FLTK1.0.6(parallel applications) http://www.chat.ru/~yaroslav_v 

yaroslav_v
()

?????

Вообще беда NeWS/NeXTSTEP - сложное программирование,
в первом случае toom much PostScript, во-втором-
"TOLKO Objective-C" - как сказал B.Spitzak
"even Microsoft does not force everybody to use MFC!"
Основная мука с unix-X/win32-gdi(mac-QuickDraw,etc)
состоит в ОТСУТСТВИИ хорошей(большой) библиотеки
_РИСОВАНИЯ_ - Я до сих пор ругаюсь, когда надо всего
лишь вывести RGB(24bit)-image в X/win32 !
OpenGL? Но вы сами понимаете проблему-
простую графику на нем писать еще труднее, чем на
PostScript(тут даже NeWS была лучше )

Да , это не просто демагогия, а очень серьезная проблема!

Сглаженные TrueType шрифты в X ? Только в
XFree-4.0 ?

Использовать freetype(создатели кстати говорят - это незаконно)?

"HOLED" - окна? В X ? Да , в win32 после часа мучений можно
добиться, но в X ? QuickDraw?

Проблема X в window_manager'e - надоели Motiff_WM HINTS !

Нужны
ЧЕТКИЕ спецификации!

Звон/прогон?
Орите сами!

А GTK+? Да , для ADA95 он очень даже подходит, но все это суета.....

Qt ? Хорош только QString'ом (поддержка UNICODE)

Но разве UNICODE все решает? А если надо иероглифы
писать сверху_вниз?

Объясните ВЫ мне зачем нужен UNICODE? ( на 0x86)

Будующее за GTK+ / Qt , наконец Java?

Будующее, друзья мои, за Quantum Computers(http://xxx.lanl.gov)

P.S. С паздником всех вас вторично, легкого утра!  

yaroslav_v
()

Поток сознания - это хорошо, но некоторые вещи легко проверить каждому. Например Motif (f только одно), точнее Lesstif на P100/24MB работает быстро. И уже долго. После таких деталей какая вера всем другим высказываниям...

anonymous
()

Коллеги, а Вы не задумывались что самое приятное писать используя только Xlib? Это чем-то сродни программированию на ассемблере. Вот где поле для деятельности. Типа: "Создай себе среду сам". Исходя из этого Вам будет некого винить в том что: 1) Программа _медленно_ работает. 2) Пожирает _слишком много_ опреативной памяти. 3) Требует для работы _кучи мегабайтных библиотек_. 4) Имеет _несовременный вид_. 5) _Странно реагирует на события_. 6) Жизнь проходит мимо. ;) конечно это шутка, но в каждой шутке есть доля...

mav
()

Писать на Xlib - изврат. Это же на C писать придется, или на C++, а это просто глупо, так же глупо, как писать что-то отличное от ядра ОС на ассемблере. Для ГУЙни скриптовые языки есть.

vsl
()

О Lesstif: давайте сравним (с FLTK)
я очень люблю его layout inteface, но придумайте задачу и проверим - кто быстрее.
 

yaroslav_v
()

SwingSet has one of the best designs I have ever seen! I heard that oroginal concept was taken from Smalltalk and NextStep.

anonymous
()

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

surfer
()

Re Какую widget-библиотеку по вашему мнению нужно использовать при разработке новых приложений?

Я возможно фанат и разбираюсь в основном только в FLTK,
но с FLTK такое сделать на OpenGL можно за 100 минут. ;-)
У меня на странице есть фото программы
Charges - физич модель взаим двух зарядов
с вымороженными по одной степени свободы
курсовая на ФизФаке МГУ, ее писали 2 часа мы вдвоем
да еще из-под NT (по сети) на интерфейс потратили
около 15(!) минут. Потом параллельное приложение
(win32/POSIX) на FLTK с моим пакетом "мозги" FLTK-Brain
сделать легко .

Ярослав. (http://www.chat.ru/~yaroslav_v)

P.S. Кстати с FLTK- программировать напрямую X/win32 тривиально-
прямо вызываете и все работает. ;-) 

yaroslav_v
()

P.S. В FLTK-bazar (http://fltk.easysw.com) есть класс
Fl_Plot (вроде) и еще несколько, но наверное
проще на OpenGL самому сделать.
В PostScript? Тоже есть Fl_Draw, но
опять обычно проще пользоваться прямыми
стандартными методами. 

yaroslav_v
()

Если gnome-canvas для рисования различных векторных рисунков, CAD и др.

maxcom ★★★★★
() автор топика

Не хотелось-бы связываться с Цепепе :(

surfer
()

Эээ... А чем вам всем так cpp неугодил??? gcc он же g++, на самом то деле... qt-он конечно рулезный, но я бы там, где можно, motif юзал... ПРосто он объекты и классы X-ов поддерживает: с editres никто не игрался?

anonymous
()

yaroslav_v wrote: > Сглаженные TrueType шрифты в X ? Только вXFree-4.0 ? Скажите, а зачем Вам в X сглаженные TrueType шрифты? > Нужны ЧЕТКИЕ спецификации! Четкие спецификации на что, простите? На интерфейс wm? А смысл?

anonymous
()

Да по большому счету это все фигня!! В место того чтобы сделать один виджет-сет более-менее подходящий всем, наплодили кучу. Ни один из ни не доведен хотябы до уровня масдайных элементов управления. Самый тупой пример - и строки ввода в общем случае ни в QT ни в GTK+ в clipboard скопировать нельзя, контекстных меню нет. Нет спецификации на QT или GTK+ приложение, т.е. к примеру горячие клавиши каждый делает как хочет. Интерфейс тоже во всех прогах сделан абсолютно по своему. Я не сторонник мастдая - сижу в Линухе, но пока не будет одного набора виджетов и общих положений на разработку интерфейса, писать коммерческий софт если и будут, то на Мотифе. А для того чтобы привыкнуть к десятку copyleft прог прийдется е###ться с неделю.

anonymous
()

Какую

>A ZAЧEM ВAM В X SGLAЖENNЫE TrueType ШRIFTЫ?

Возможно это и странно, но целочисленное сглаживание
всякой графики улучшает (НМСВ - на мой скромный взгляд ;-) )
восприятие ее .....
В X действительно НМСВ порядком недоделок, которые впрочем
вянут перед "design errors" лица win32 , но все же порядком
раздражают:
WM_HINTS (НМСВ) просто убоги, а жаль.
Вывести RGB-image опять проблемы (а жаль)
.........................................

О чем же здесь спор?

Просто программировать по-прежнему легко, дело за новыми подходами,
идеями; квантовая логика - вот единственно увлекательное, стоящее дело.
На ЯМР(ядерно-магнитный резонанс)? Но это старо,
а как насчет spin-spin взаимодействия,
spin-orbit????? 

yaroslav_v
()

Clipboard?

Clipboard? Возможно это не мое дело, но это и впрямь тривиально ..... ;-) 

yaroslav_v
()

Как это "чем c++" не угодил?

Да это же совершенно уродский язык, ни для чего не пригодный, кроме того, ваять интерфейс не на скриптовом языке - грубейшее нарушение Unix Way, ну а если кто настолько извращенец, что все же хочет ГУЙ жестко вкомпилить, то есть гораздо более удобные и правильные ООПные языки (это если забыть, что ООП - дерьмо собачье).

vsl
()

Кто там графики хотел?

Решение в духе Unix Way: вызывать gnuplot. Если же это надо в реальном времени (или просто достаточно быстро) отображать - то как угодно, без разницы на чем делать, все равно всю бодягу с нуля писать, готовых виджетов для этого нет (разве что gamma-curve в gtk+).

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

vsl
()

To vsl: прежде чем ругать C++ - изучите его. Я уверен, что вы его совсем не знаете. А писать софт на просто С - геморойно. Про динамическое отображение графика - GtkPlot тут может иметь некое отношение к делу. Про unix-way написания ГУЕв - и что, вы будете продавать своим заказчикам софт с исходным кодом ГУЙной части? Я думаю вы побоитесь пиратства, а также потенциальной фрагментации памяти если софт будет работать год без остановки. (Про free софт я не говорю). А если рисовать GUI на glade, то тебе практически нет разницы, что за язык для управления GUI ты используешь - по-любому все просто.

Остальным: кто-то говорил про нестандартность keybindings - на это и существуют (идеологически по крайней мере) десктопы. Я еще не смотрел libglade, но эта вещь как я понял позволяет пользователю отредактировать ГУЙ приложения (кнопочки, их выравнивание, порядок и размещение, акселераторы, и как я понял, даже надписи на них) посредством модификации файла на xml. ИМО это на порядок круче всех editres - пользователь сможет сделать все мышкой сам. Так что не катите бочку на gtk+. И даже без libglade пользователь может управлять внешним видом gtk-шных приложений, если программер дает всем виджетам имена и классы (скажем, модно изменить цвет и шрифт надписи ОК в одном определенном диалоге, назначить ей акселератор) - просто изменяя .gtkrc. Естественно, ничего подобного не доступно для QT.

И вообще, при опросе было бы умнее спросить - какие виджет-сеты вы знаете (а не ваш любимый виджет сет) - я боюсь много народу выбирают qt, даже не зная его, из-за того что им как пользователям нравится KDE (за редакторы проголосовало ~1600 человек, за виджет-сеты - 500 - ну слишком уж много пишут GUI для unix!).

Насчет вырезания в клипбоард полей ввода в GTK - насколько я помню, Ctrl-Ins и Shift-Ins работают.

hvv
()

Уважаемый vsl. Не могли бы вы поконкретнее объяснить, в чем собственно уродство c++. Почему ООП дерьмо, и если так, то какую альтернативу ООП вы предлагаете ? Я уже раньше спрашивал на этом сайте, почему здесь все так ругают c++, но кроме невнятного "с эффективней" ничего не добился. Ни одного примера в пользу этого утверждения я так и не дождался. Если кому нибудь это интересно, могу привести примеры в пользу того, что c++ эффективней, чем c. Всем нелюбителям c++: Не поленитесь, и прочитайте Страуструпа. Если кто не знает - это аналог K&R для C++.

anonymous
()

Можно поругаться насчет MWM_HINTS? Точнее про их неадекватное восприятие E и KDE. Так вот, устанавливаю у окна свойства "показывать только заголовок окна" и "разрешить перетаскивать". Вывожу окно. Под icewm - все просо замечательно. Enlightment - проигнорировал эти свойства, т.е. как будто ничего и не задавал. KDE - спрятал кнопку минимизации и кнопку максимизации, остальное проигнорировал. А теперь вопрос - почему разработчики qt и E выдумывают свои WM_HINTS? В свойствах окна есть еще куча неиспользованных бит, зачем было выдумывать что-то совершенно несовместимое? Не исключаю вариант, что криво выставлял свойства, однако под icewm работает...

mav
()

Какую

Друзья мои, давайте не будем ругаться -
Великий шутник VSL опять шутит ;-)))))

Вопрос был какую библиотеку _нужно_ использовать,
поэтому если человеку нравится GNOME/Xfce он голосует за GTK+ ?! 

yaroslav_v
()

форум

Dear mav, давай обсудим такие вопросы в создатель-форуме..... ;-) 

yaroslav_v
()

yaroslav_v, конечно я не прочь обсудить эти вопросы. Создавайте форум. Думаю это пойдет только на пользу.

mav
()

Я не сравниваю C++ с C. C++ - это извращение, а C - это портабельный ассемблер. О применимости того и другого судите сами.

Про ООП: не стоит путать ООП с ООД. Если ООД просто необходим для крупных проектов, то это еще не повод автоматом считать необходимым применение ООП. Сейчас просто нет нормальных ООП языков.

Посмотрите на модульные языки, идеально ложащиеся на ООД: Ada, ML, Oberon. Попробуйте Inferno. И потом только говорите о крутости C++, если язык повернется.

vsl
()

Нет нормальных ОО языков? Smalltalk - rules!!!

anonymous
()

Смоллтолк не нормален по определению. Если нужна конкретика - пошли в мыло, а то тут уже все это оффтопик.

vsl
()

forum

Уважаемый yaroslav_v! Буду признателен за любую информацию о HINT'ах использующихся в различных виджетах. Попутно вопрос: Как отлаживать memory leak при помощи gdb? Пока лучше чем ps v PID в соседней консоли ничего не придумал.

mav
()

Пожалуй QT более менее нормальная, хоть и на с++ ,но там все давольно просто. Я не любитель с++, но здесь помоему он вполне уместен, а на gtk одни названия функций чего стоят, да и не понравился такой факт что уже имеющиеся проги откомпиленые ранее с предшествующей версией выдавали сегментейшн в gtk библиотеки. Версии например: 1.2.х и 1.2.у , мне такой подход не понравился. С другой стороны обилие библиотек вызывает уныние, т.к. они не стандартизированы что не хорошо. А по поводу скриптовых языков для gui, ну незнаю, пришишь на перле и на ц разница в скорости видна не вооруженным взглядом. А чем быстрей работает gui тем лучше для юзера :)

anonymous
()

рисунки

Привет всем!

Я думаю многим будут интересны
библиотеки:

FOX(http://cyberia.cfdrc.com/FOX/fox.html)
хорошая библиотека, написанная на C++,
работает на X и win32 .
Поддерживает OpenGL. Кстати имеет довольно удобный
class для работы с OpenGL, который чем-то
напоминает OpenGL-Optimizer от SGI (http://www.sgi.com)
Поддерживает MDI(multiple_documents) в стиле Windows,
я не уверен, что это правильное решение, но "много-не-мало" ;-)
На нем написано несколько хороших и быстрых
приложений:

Magic Light(http://home.bip.net/mikael_aronsson)-modeller,
хороший, быстрый, удобный использует OpenGL ( alike MAX_Studio )

XWinCommander(http://www.geocities.com/SiliconValley/Mouse/7912/xwc.html)
хороший- file manager (alike WindowsCommander)

EZWGL (http://www.ma.utexas.edu/users/mzou/EZWGL/)
полнофункциональная, быстрая, красивая, СТАБИЛЬНАЯ
библиотека, layout_manager напоминает motif (XmForm)
содержит в себе библиотеку проектирования
пространственных фигур (a'la OpenGL, но НЕ OpenGL,
ее интерфейс похож на OpenGL, software_rendering
быстрее MesaGL) очень рекомендую любителям
Motif (сделана целиком на C, programming_interface
напоминает GTK+, хотя похоже он проще)
Не требует дополнительных библиотек, не основана
на "C-classlib" (Glib) быстрее GTK+.
Backgroung_images,etc. в органах управления делаются легко.
Есть rich_text(image support!), редактор X_resources (a'la motif)
МАЛЕНЬКАЯ/БЫСТРАЯ!!!!!

JX (http://www.its.caltech.edu/~jafl/jx/)
Он неплох, быстр в чем-то лучше продуман, чем Qt
Но как и Qt не LGPL, и потому не интересен почти.
К тому же не перенесен на win32 (пока?)

TOAD(http://www.informatik.uni-rostock.de/~hopf/toad/)
пример довольно хорошо спроектированной библиотеки,
написанной на C++, отличный layout_manager (alike XmForm)
Имеется interface builder (dialog editor)
Поддержка ресурсов, хорошо работает с картинками,
реализована идея "файл_в_памяти" (URL memory://)
МАЛЕНЬКАЯ/БЫСТРАЯ!!!!!

FLTK: (http://fltk.easysw.com) FLTK-Brain (http://www.chat.ru/~yaroslav_v)
На мой взгляд самая интересная
библиотека.
Ее архитектура отличается от всех вышеперечисленных библиотек
сообщения в ней доставляютсяне в callback_functions
к
каждому сообщению свою, а в handle method ..... (read manual)
Отличная документация-целая книга, хорошо написана
(кратко/понятно)
изначально это был просто теоретический проект человека,
который работал в SUN(NeWS)-качество кода
(высокое) сразу бросается в глаза
Лично я освоил ее примерно за один день:
(распечатал документацию, вечером почитал, утром ..... )
В ней конечно есть некоторые недостатки,
но похоже, что их меньше чем в других пакетах.
Те , кто писал графику для _DOS_ (BGI,direct_vga) сразу
оценят ее, похоже, что это лучшая LGPL библиотека
и для программирования под windows.
И в заключение я бы хотел прорекламировать FLTK-brain
поправленную мной FLTK-latest_stable с поддержкой потоков.

P.S. Мои комментарии субъективны и я советую сходить по
гиппер ссылкам и взглянуть самим .....

Ярослав. 

yaroslav_v
()

v dogonky

P.P.S. Я имел ввиду, что EZWGL имеет более удобный
программный interface  в сравнении с GTK+.

P.P.S. Я уже говорил, что FLTK работает на
X, win32 и QuickDraw(Macintosh) ?
С
версии 2 (beta-январь/stable-май) будет иметь styles
( alike GTK+, но на даже на настоящий момент (unstable_cvs)
!
более быстрый, чем у GTK+1.2.x(stable) - за счет binery_plugins,
text/binary-файлов конфигурации-alike .gmo objects в gettext)
Я планирую к лету (январь-alpha) доделать html_(latest ;-) ) browser.
(Пока до networking руки не дошли , html кой как уже читается-
кстати hash_functuions,etc. делают его быстрее Mosaic/Mozilla)
На днях я выпущу обновления FLTK-brain - теперь
совсем отполированную
-----
Опасность: слишком много потоков могут свести преимущества FLTK к
ZERO! ;-) .....

По поводу "расплодившихся библиотек" я
думаю, что это просто отлично-
мы свободные люди, делаем то , что НАМ нравится, хотя это и МОЖЕТ
быть полезным кому-либо еще.....
Шлифовать GTK+?
Но там glib- недоделана(даже архитектура), да
и лично мне нравятся программы на GTK+, но писать не ней я не
люблю .
Лично мне было просто неприятно смотреть как на объявление
о новой библиотеке от mav'a (кстати хорошо пишущейся и небольшой,
т.е. легкой для освоения и понимания общих принципов работы X)
Однообразие ВРЕД! На мой взгляд надо(НЕОБХОДИМО!) дорабытавыть
и стандартизировать только низкоуровневые библиотеки
X, glibc (если речь идет о программировании UNIX/X Window)
На мой взгляд еще не пришло время говорить, что GUI-совсем
ничто , тривиально .....
На моем компьютере на отрисовку тратится около 90 % времени процессора. Я
и не использую компьютер для счета - гораздо проще
воспользоваться большой параллельной счетной машиной..... 

yaroslav_v
()

По-моему, вопрос был поставлен некорректно. Во-первых, отсутствует возможность множественного выбора тулкитов. Например, gtk+ и gtk-- по мнению создателя вопроса - совсем разные вещи, что ли, особенно с юзерской точки зрения? Во-вторых, не ясно, к кому обращается автор - к юзерам, или девелоперам? У меня, например только что было загружено два xlib - приложения (xosview, xterm (или он не на xlib непосредственно?)), одно qt (LICQ), одно Motif-приложение, скомпилированное статично (Netscape), один виндоу-менеджер и куча gtk-прог (Gimp, irc - клиент, info-browser, миноискатель :) и тому подобные "утилитки" ), которые мне, надо сказать нравятся... А про LICQ, Netscape и др. не гтк ут

allter
()

утилитки я могу сказать - просто не было _достойной_ (в смысле: стабильной, современной, утилитарной, лёгкой) альтернативы. Но ведь эта ситуация зависит на 60% от юзеров. Посмотрел я на скриншоты из галереи и понял, что такое разнообразие софта, тулкитов и т.п. вполне народ устраивает. Спрос рождает предложение. Будет спрос - будет и популярный тулкит. С точки же зрения девелоперов - тоже не всё ясно. Лопатят-перелопачивают коды обработчиков кнопок, например, в Mozilla, вместо того, что бы подучить матчасть. В результате, у ребят из команды разработчиков маленького шустрого модульного браузера Mnemonic (3е- 5ро человек собственно "код

allter
()

"кодеров" (в кавычках, т.к. прежде всего они этой самой матчастью и занимаются, а остальные члены группы - разные дизайнеры, вебмастеры, дебианизаторы и т.п.), из которых только один (или двое - забыл) PhD in CS, и то student(ы) на оного), который, думается, к следующему релизу Debian-a успеет стать достаточно юзабельным, разрекламированный "мозилловский" рендеринг контента до закрывающего тага моментально появился и не стеснил сетевой и другой код. И это при двух вариантах вывода - X/gtk и console/ncurses... (Уфф, сорри за слегка закомплексованное предложение). Причём они запоздали относительно выхода сорцев мозиллы примерно на год с началом разработки.

allter
()

(QT-дисплей или что там ещё подключить, при этом, будет совершенно не проблема). Allter. P.S. Блин, как же сюда сообщения постят??? Режутся в самом ненужном месте. :-F~~~O А в режиме "Preformatted HTML" скрипт ругается на /PRE/ таги... :-(

allter
()

allter: то ли в Интернет-Експлорере, то ли в данном .пхп3 ошибка, вот и режутся. А с Нетскейпом вроде нет проблем. Или это с Виндовс проблемы? :) Мораль - не используй Виндовс на Линукс сайте. :)

anonymous
()

motif - КЛАССИКА!!!

anonymous
()

Я полностью согласен со словами allter-а о том, что вместо написания конкретного прикладного софта, куча народа занимается одним и тем же. Одному не нравятся имена функций из GTK+, другому C++ - херня. По-моему одним из достоинств OpenSource мат. обеспечения является возможность развивать его всем кому не лень - расширять функциональность. А в случае с Widget тулкитами куча народу делает одну работу. Ни один тулкит концептуально не закончен, а смысла в таком кол-ве никакого: 1. юзеру необходим единый интерфейс (не надо подстраиваться под что-то новое) 2. юзеру надо БОЛЬШОЕ кол-во ПРИКЛАДНОГО софта, а не Widget Set-ов. Ну не просто так же винды так популярны(у юзеров). В свое время Билли Гейтс потратил кучу денег на обучение лопоухих юзеров по всему миру, содействовал открытию консультативных фирм - теперь обученого персонала куча, софта тоже, вот и получается глючный Мастдай самой распространенной ОС - ИЛИ МОЖЕТ ВСЕМ НРАВИТСЯ КАК ВИНДЫ ПАДАЮТ. 3. В том же Win32 писать проги сполошная морока. Уж не по этому-ли на MFC и VCL пишутся сколько-нибудь серьезные проги (а они-то объектно ориентированые). Кстати где-то в серьезной книге по программированию я читал, что при объеме кода свыше 100 тыс. строк процедурная разработка абсолютно не эффективна. Так что, если разрабатывается большой прог. продукт так писать свою библиотеку классов над GTK+, Motif и т.п. И там кто-то говорил, что можно использовать ООП без ОО языка - советую почитать книгу "Обьектно-ориентированый анализ и проектирование" Гради Буча, не очень давно в ПитерПресс вышла. В результате получается, что куча программеров просто в игры играется. И, хотя имеют на это полное право, но в результате или какая-нибудь фирма заплатит Линусу и тем кто разрабатывает ядро и будет на коммерческой основе развивать Линукс (это скорее из области фантастики) или Линукс так и останется серверной ОС и никто и не будет пытаться использовать ее в офисе - что-то я не верю, что скажем Corel нормально зарабатывает на WordPerfect-е. )

anonymous
()

Существует куча ОО разработок - Linux kernel, X etc. Причем на С++ эти вещи получились бы эффективнее. Просто половина народа его не знает, половина не пишет программы больше, чем на 1000 строк и/или обуяны романтикой типа "PURE C, asm !!!!!, ed is the best editor in the world !!! etc." Ну с ядром и с иксами то все понятно, в то время еще не было эффективных С++ компилеров, но зачем сейчас начинать разрабатывать/писать на заведомо устаревшем языке ?

anonymous
()

Если C - устаревший язык, то C++ - и вовсе мертворожденный. Ну а призывы писать на C++ ядро - и вовсе глупо смотрятся. Еще бы на Форте его писать стали... Вообще, ООП и С++ - совсем не синонимы, как многие считают.

vsl
()

Я полностью поддерживаю написание программ с размером исходного кода больше чем 5 Kb на С++. Использование С для больших проектов приводит к ненужным затратом времени/усилий программистов, и приводит к поялению негибкого/медленного софта, код которого трудно повторно использовать (а это червато для freesoftware). Использование С можно оправдать только требованиями очень большой портабельности. Но в любом случае ООП подход (даже с использованием С) наиболее предпочтителен. Например - gtk+ написан с использованием ООП подхода, но на С. Но все равно, даже старый С++ освобожает программиста от гемороя - например использование inline функций вместо макросов, параметры со значением по умолчнанию, статическая инициализация, перегрузка функций - освобожает программиста от необходимости выдумываяния и использования всяких префиксов к именам сущностей (как например gtk_clist_remove - gtk_clist_ здесь префикс, который не нужен при использовании возможностей C++. Новый С++ дает еще шаблоны (это прорыв для компилируемых языков, пространства имен и исключения, а также гарантирует наличие STL. К сожалению, FSF не поощеряет (не оплачивает разработку) использование программ на С++. Да и С++-компиляторы не входят в поставку unix - их надо покупать, к тому же они не все совместимы с последним стандартом. Выход есть - трансляторы с С++ в С. Хакание gcc чтобы он генерил C вместо ассемблера на выходе может изменить мир free software. Еще одна проблема - библиотеки, которые реализованы в виде шаблонов (как STL, MTL и др.) Чтобы их можно было использовать в коммерческих программах, их недостаточно выпустить под LGPL (так как шаблоны нельзя динамически слинковать) - вот еще проблема. Короче - использование С я бы сравнил с работой лопатой, а использование С++ с работой экскаватором. Да, изучение последнего в совершенстве требует напорядок больше времени, но и производительность (об[ем вынутого грунта в единицу времени) тоже различаются на порядок. Исользование же STL повышает к тому же и производительность кода за счет использования очень умных алгоритмов (например сортировки, сортировки на месте - шаблоны дают использовать функцию сортировки, которая будет inlined!) Чегой-то linux.org.ru так часто недоступен - какая СУБД у вас стоит? От чего он недоступен - падает БД или скрипт? Я тут уж добавлял комментарии, но после падений они исчезают...

hvv
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.