Здравствуйте, rsn81, Вы писали:
R>Поменял бы местами % первых двух пунктов. Причины две: менеджеры компоновки, а также б'ольшая популярность визуального программирования в .NET.
Там % с потолка, только для примера. И потом, мы правильно понимаем друг друга, если трудоемкость изучения и использования первого — 100%, а второго — 130%, то первое легче?
Re[3]: Трудоемкость изучения и использования GUI-библиотек
Здравствуйте, igna, Вы писали:
I>Там % с потолка, только для примера.
Данный вопрос слишком субъективен, потому цифры с потолка его уже не испортят.
I>И потом, мы правильно понимаем друг друга, если трудоемкость изучения и использования первого — 100%, а второго — 130%, то первое легче?
Ага, так у вас. Я же сказал, что считаю: все наоборот.
Re[4]: Трудоемкость изучения и использования GUI-библиотек
Здравствуйте, rsn81, Вы писали:
I>>И потом, мы правильно понимаем друг друга, если трудоемкость изучения и использования первого — 100%, а второго — 130%, то первое легче? R>Ага, так у вас. Я же сказал, что считаю: все наоборот.
Не путай, если трудоемкость первого — 100 часов, а второго — 130, то первое безусловно легче.
Re[5]: Трудоемкость изучения и использования GUI-библиотек
Здравствуйте, igna, Вы писали:
I>Не путай, если трудоемкость первого — 100 часов, а второго — 130, то первое безусловно легче.
Вы сами с собой спорите?
Попробуйте читать повнимательнее.
Re: Трудоемкость изучения и использования GUI-библиотек
Все ИМХО (по стобальной шкале, чем выше бал — тем сложнее) и со следующими предположениями:
1. Сравнение ведется с Win(16/32) API. Т.е. моя оценка была выставлена с одной стороны схожесть с Win32 API (общие подходы, сходные методы итд), а с другой — упрощение интерфейса по сравнению с WinAPI.
2. Все библиотеки идут в комплексе с RAD компонентами (указаны в колонке RAD). Т.к. я давно не писал без RAD
3. Все субъктивно
Название
RAD
Сложность (max=100)
Комментарии (все ИМХО)
C#/Windows Forms
Окно Form Visual Studio
50
Почти такая же как SWT. Но немного сложнее, и ИМХО некоторые вещи сделаны откровенно туповато. Хотя и на SWT и на Win Forms писал 3+ года, особых проблем, ради которых надо уходить от первой ко второй или на оборот я не выявил. Все примеры можно найти и на сайте MS, и на codeproject, и на GDN.
Java/SWT
SWT Designer
40
Самая простая из рассмотреных. В большенстве своем из-за того, что имеет множество примеров здесь + очень приличное средство RAD.
Delphi/VCL
не работал с этим
C++/Qt
не работал с этим
C++/MFC
Окно редактора диалога Visual C++
60
Большинство примеров/библиотек всегда бралось с двух ресурсов codeguru, а позже codeproject. ИМХО совсем не сложная, поэтому поставил 60, а не 70. Основной плюс, что после WIN API, почти ничего ненадо изучать. Основной минус — сейчас очень мало книг(раньше книг было на порядок больше) по этой библиотеке (поэтому поставил 60, а не 40), но это из-за того, что многие считают эту библиотеку устаревшей.
Только попробуйте поставить минус, я четыре раза написал ИМХО
... << RSDN@Home 1.2.0 alpha rev. 725>>
Re[6]: Трудоемкость изучения и использования GUI-библиотек
Здравствуйте, rsn81, Вы писали:
R>Попробуйте читать повнимательнее.
Читаю:
I>>И потом, мы правильно понимаем друг друга, если трудоемкость изучения и использования первого — 100%, а второго — 130%, то первое легче? R>Ага, так у вас. Я же сказал, что считаю: все наоборот.
Как именно наоборот, если трудоемкость изучения и использования первого — 100%, а второго — 130%, то второе легче?
Давай разберемся с этим недоразумением.
Re[7]: Трудоемкость изучения и использования GUI-библиотек
Здравствуйте, igna, Вы писали:
I>Как именно наоборот, если трудоемкость изучения и использования первого — 100%, а второго — 130%, то второе легче?
Нет, конечно — первое, ну боже ж ты мой...
I>Давай разберемся с этим недоразумением.
Ага, или не будем их себе придумывать.
Re[2]: Трудоемкость изучения и использования GUI-библиотек
Название : HTA (HTML Application).
RAD : ЛЮБОЙ HTML-редактор. (Visual Studio имеет очень неплохой встроенный)
Сложность (max=100) : 60 — на глаз (реально оценить трудно. С одной стороны — есть несколько подводных камней при хостинге MSHTML. С другой — создание интерфейса сильно упрощается поскольку книг по HTML-завались).
Комментарии (все ИМХО) : Для формошлёпок или программ где интерфейс должен быть красивым — очень даже неплохой вариант. Изначально дорог из-за вышеупомянутых подводных камней, но если проект большой и интерфейс в нём занимает большУю часть времени — окупает себе с лихвой. Дополнительный плюс — все интерфейсные задачи можно писАть на JavaScript (для любителей тонких извращений — на VBScript), что очень здОрово дополнительно ускоряет разработку. Из недостатков — принципиальная некросплатформенность, необходимость поддержки нескольких браузеров (обычно в требования ставят как минимум IE 5.01, с более предыдущими стараются не связываться).
PS. Это как бы не совсем библиотека, просто один из вариантов создания GUI.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[2]: Трудоемкость изучения и использования GUI-библиотек
Здравствуйте, rsn81, Вы писали:
R>Поменял бы местами % первых двух пунктов. Причины две: менеджеры компоновки, а также б'ольшая популярность визуального программирования в .NET.
"Большая популярность визуального программирования в .NET" является одной из причин того, что изучение и использование C#/Windows Forms более трудоемко по сравнению с изучением и использованием Java/SWT?
Re: Трудоемкость изучения и использования GUI-библиотек
Здравствуйте, igna, Вы писали:
I>Какова сравнительная трудоемкость изучения и использования комбинаций языка программирования и GUI-библиотеки?
I>Пример ответа:
I>C#/Windows Forms — 100% I>Java/SWT — 130% I>Delphi/VCL — 90% I>C++/Qt — 200% I>C++/MFC — 900%
I>Или укажите трудоемкость изучения и использования отдельно.
Здравствуйте, igna, Вы писали:
I>"Большая популярность визуального программирования в .NET" является одной из причин того, что изучение и использование C#/Windows Forms более трудоемко по сравнению с изучением и использованием Java/SWT?
Да. А что, нашли противоречие? Визуальное программирование — это зло, порождающее одноразовый ГИП, который очень неуклюж при условии относительно непростого ГИПа и частого изменения требований к нему. Нет, ну если речь про 2-3 формы, то конечно...
Под трудоемкостью стоит понимать трудозатраты на реализацию эквивалентного по сложности ГИПа, а не сравнение скорости и удобства накидывания 2-3 формочек в визуальном построителе.Кстати, SWT напрямую используется редко, в основном популярны классы надстройки над SWT — JFace.
Здравствуйте, igna, Вы писали:
I>Какова сравнительная трудоемкость изучения и использования комбинаций языка программирования и GUI-библиотеки?
I>Пример ответа:
I>C#/Windows Forms — 100% I>Java/SWT — 130% I>Delphi/VCL — 90% I>C++/Qt — 200% I>C++/MFC — 900%
I>Или укажите трудоемкость изучения и использования отдельно. I>Также интересны просто рассуждения на тему.
wxWidgets — 40% от MFC (100%)
вообще, после MFC, все остальное изучается влет, или сразу становится понятным, т.е. можно сразу работать и по ходу дела вникать глубже
Re[2]: Трудоемкость изучения и использования GUI-библиотек
Здравствуйте, igna, Вы писали:
I>Спасибо. Кто-нибудь может добавить информацию про JFace?
Снова ИМХО:
Название
RAD
Сложность (max=100)
Комментарии (все ИМХО)
JFace
SWT Designer/VE
55
JFace однозначно сложнее SWT, приблизительно как Windows Forms поэтому поставил выше 50. Из проблем: слишком абстрагированы компоненты для ежедневных практических задач, малое количество литературы (только на eclipse.org), обусловлено тем, что интерфейс JFace частенько меняется или значительно дополняется. Тем не менее использование JFace в крупных проектах считаю оправданым и выгодным.
Как вообще можно сравнивать ядро (SWT) и надстройку над ним (JFace)? SWT — просто набор "хреней" (не знаю, как правильнее переводить widgets — контролы вроде как тоже не по-русски звучит), а JFace — набор MVC-ориентированных компонентов, которые построены на SWT-widgets. И как можно говорить, что JFace сложнее SWT? Разумеется, сложнее... потому как использовать JFace без знания SWT сложно.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, 0rc, Вы писали:
R>Как вообще можно сравнивать ядро (SWT) и надстройку над ним (JFace)?
Можно, первое и воторое является (G)UI инструментарием.
R>SWT — просто набор "хреней" (не знаю, как правильнее переводить widgets — контролы вроде как тоже не по-русски звучит), а JFace — набор MVC-ориентированных компонентов, которые построены на SWT-widgets.
На самом деле, ни то не другое не является тем, чем вы назвали: ни SWT не является "просто набором хреней (widgets)" (взгляните в swt.jar например, там widgets занимают ~40% от всей библиотеки. Тот же MFC имел примерно такие пропорции, но никто /по крайней мере я не слышал/ не говорил, что MFC состояло из классов порожденных от CWnd (аналог моднячего слова widgets), кроме них было и поддржка вывода на внешним устройстам, к их контекстам, таймеры, управление манипуляторами, итд итп — SWT, как и MFC все это имеет ) ни JFace не является набором MVC-ориентированых компонентов (http://en.wikipedia.org/wiki/JFace, http://wiki.eclipse.org/index.php/JFace).
ИМХО: Когда я писал на чистом SWT то хорошо почуствовал, что написать программу на чистом SWT будет долго, а когда использовал JFace у меня значительно ускорилась разработка, но само использование JFace добавило сложности в понимании, в изучении,...
R>И как можно говорить, что JFace сложнее SWT? Разумеется, сложнее... потому как использовать JFace без знания SWT сложно.
Здравствуйте, igna, Вы писали:
I>Нет, конечно же SWT и SWT+JFace. По теме: SWT + JFace > SWT — и ежу понятно, что до знака больше сложнее, чем после.
Что более-менее серьезное можно написать без JFace только на голом SWT лично мне непонятно (разве что snippet-ы с eclipse.org), потому рассматривать их отдельно не вижу смысла.
Здравствуйте, 0rc, Вы писали:
0rc>На самом деле, ни то не другое не является тем, чем вы назвали: ни SWT не является "просто набором хреней (widgets)" (взгляните в swt.jar например, там widgets занимают ~40% от всей библиотеки. Тот же MFC имел примерно такие пропорции, но никто /по крайней мере я не слышал/ не говорил, что MFC состояло из классов порожденных от CWnd (аналог моднячего слова widgets), кроме них было и поддржка вывода на внешним устройстам, к их контекстам, таймеры, управление манипуляторами, итд итп — SWT, как и MFC все это имеет ) ни JFace не является набором MVC-ориентированых компонентов (http://en.wikipedia.org/wiki/JFace, http://wiki.eclipse.org/index.php/JFace).
Все правильно, кроме основного, что назвал, в библиотеках много всего прочего, да-да, как к примеру работа с ActiveX в SWT. Но лицо SWT — это widgets, а лицо JFace — это MVC-ориентированные представления списков, таблиц, деревьев и т.п. Первый раз программист лезет в пакет (пространство имен) org.eclipse.jface именно для того, чтобы залезть в org.eclipse.jface.viewers — и найти классы, упрощающие работу со списками, таблицами, деревьями и прочим. По вашей же ссылке из вики:
Viewers are model based adapters for certain SWT widgets, simplifying the presentation of application data structured as lists, tables or trees.
Все остальное в JFace там же называют просто UI toolkit.
0rc>ИМХО: Когда я писал на чистом SWT то хорошо почуствовал, что написать программу на чистом SWT будет долго, а когда использовал JFace у меня значительно ускорилась разработка, но само использование JFace добавило сложности в понимании, в изучении,... Никогда не писал не чистом SWT, бог уберег...
0rc>Т.е. вы согласны?
Утверждение абсурдно... пусть верно.
Здравствуйте, rsn81, Вы писали:
R>Что более-менее серьезное можно написать без JFace только на голом SWT лично мне непонятно (разве что snippet-ы с eclipse.org), потому рассматривать их отдельно не вижу смысла.
Здравствуйте, igna, Вы писали:
I>Какова сравнительная трудоемкость изучения и использования комбинаций языка программирования и GUI-библиотеки?
А сопровождение не учитываем? А сложность "прыжков через голову", когда сложные вещи один фреймворк позволяет сделать, а на другом это почти невозможно?
Re[2]: Трудоемкость изучения и использования GUI-библиотек
Здравствуйте, Eugene Kilachkoff, Вы писали:
EK>А сопровождение не учитываем? А сложность "прыжков через голову", когда сложные вещи один фреймворк позволяет сделать, а на другом это почти невозможно?
Учитываем, давай.
Re[3]: Трудоемкость изучения и использования GUI-библиотек
Здравствуйте, igna, Вы писали:
EK>>А сопровождение не учитываем? А сложность "прыжков через голову", когда сложные вещи один фреймворк позволяет сделать, а на другом это почти невозможно?
I>Учитываем, давай.
Я к тому что изучение далеко не главная вещь.
Вообще GUI я давно не пишу, но по-моему MFC уверенно держит первое место по геморрою во всех четырех номинациях.
Здравствуйте, AndrewVK, Вы писали: AVK>ИМХО!!! AVK>
AVK>
Library
Изучение
Использование
AVK>
MFC
100%
100%
AVK>
VCL
110%
70%
AVK>
Swing
160%
50%
AVK>
WinForms
120%
60%
AVK>
WPF
200%
40%
AVK>
Я конечно пониаю, я что ИМХО, но.... Просто инересно....
Ты хочешь сказать, MFC проще чем VCL??? Ты чего?
Чтобы на Делфи формошлёпить, и учиться даже не надо. Я как только открыл Делфи (до этого знал Паскаль) моментально догнал, как делать интерфейс. Ваще самая простая библиотека!
MFC я так и не осилил. И не осилю наверное, если целенаправлено не возьмусь.
Re[3]: Трудоемкость изучения и использования GUI-библиотек
Здравствуйте, maggot, Вы писали:
M>Ты хочешь сказать, MFC проще чем VCL???
В плане изучения? Безусловно.
M>Чтобы на Делфи формошлёпить, и учиться даже не надо.
Я формошлепанье во внимание не принимал. Я оценивал стоимость обучения в плане качественного овладения. В плане скорости достижения формошлепского результата мне не интересно, да и не в состоянии я подобный параметр адекватно оценить.
M> Я как только открыл Делфи (до этого знал Паскаль) моментально догнал, как делать интерфейс. Ваще самая простая библиотека!MFC я так и не осилил. И не осилю наверное, если целенаправлено не возьмусь.
Значит ты и VCL не осилил, вот и все.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, Eugene Kilachkoff, Вы писали:
EK>Вообще GUI я давно не пишу, но по-моему MFC уверенно держит первое место по геморрою во всех четырех номинациях.
ИМХО прыжки через голову для MFC родная стихия, оне там проще чем в любой другой библиотеке, основанной на User/GDI.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
и считаешь, что SWT+JFace проще чем Windows Forms?
Нет, такого не говорил.
0rc>JFace однозначно сложнее SWT, приблизительно как Windows Forms поэтому поставил выше 50.
Про это уже говорил: работать с SWT без JFace, а тем паче сравнивать сложность, не стоит. А по WinForms vs SWT/JFace: оценка слишком субъективна, но здесь Re: Трудоемкость изучения и использования GUI-библиотек
согласен с Orc-ом — сложность примерно одного уровня.
0rc>Из проблем: слишком абстрагированы компоненты для ежедневных практических задач
Именно эта абстракция и делает JFace единственно пригодным путем использования SWT для построения серьезного ГИПа: самому реализовывать MVC на уровне контролов никогда в голову не приходило.
0rc>малое количество литературы (только на eclipse.org), обусловлено тем, что интерфейс JFace частенько меняется или значительно дополняется.
Советую посмотреть также http://wiki.eclipse.org
Единственное, что действительно досаждает: огромное количество bugs — их относительно оперативно изменяют, потому обычно нет особенного смысла перекрывать bug своей реализацией, проще дождаться исправления, но... таки приходится bug ставить на некоторое время отнюдь не в fixed.
0rc>Тем не менее использование JFace в крупных проектах считаю оправданым и выгодным.
Так без него вроде никак.
"Большая популярность визуального программирования в .NET" является одной из причин того, что изучение и использование C#/Windows Forms более трудоемко по сравнению с изучением и использованием Java/SWT?
Ага, все ж таки вывели на чистую воду.
Да, считаю Java GUI (Swing, SWT) несколько более концептуально красивым (а значит и простым при решении одинаковых по сложности задач) по указанным выше причинам (менеджеры компоновки, засилие визуального формошлепства).
Но допускаю, что сужу несколько субъективно.
