Здравствуйте, rsn81, Вы писали:
R>В проекте Nebula реализовали новые "хрени" (widgets): календарь, диаграмму Ганта — красота! R> R> R>PS Досадно только, что в CalendarCombo пока явный архитектурный баг имеет место...
Год назад было время разобраться с программированием под Java/SWT/Swing.
все было хорошо, пока не пришлось решать конкретную задачу, и вот тут оказалось, что стандартного компонента типа "календарь" нету — надо ставить приблуду. Далее — генератор отчетов — оказалось либо платный либо бесплатный но платформенно зависимый и т.д. И таких вот приятных мелочей я насобирал под самую завязку плюс ко всему очень недружественные эклипс и нетбинс (это уже субъективно ИМХО, сравнивая с разработкой на VC#2005/2008 ).
Здравствуйте, igna, Вы писали:
I>Какие недостатки есть у Java/SWT по сравнению с другими комбинациями язык/библиотека для программирования под Windows? Хочу, чтоб поругали.
Список недостатков (ИМХО):
SWT базируется на Java, отсюда очевидный недостаток — SWT зависит от Java
SWT сравнительно молодая библиотека. Разработчик, который использует эту библиотеку "по крупному" обречен хоть раз запостить баг в багрепорт Eclipse комьюнити. Если посмотреть на баг-листы SWT можно заметить, что абсолютное большенство багов и рассуждений в новостных рассылках SWT от разрабочиков крупных продуктов на основе этой библиотеки (тот же Azureus проект или SWT Designer). Итак вторая проблема — это баги, из-за молодости библиотеки. Многие пофишены, но все-равно они есть еще. Вы не управляете развитием библиотеки. Формально библиотека открытая, фактически — есть сообщество, планы которого задокументированы на год вперед. Из-за этого ваши идеи, пусть и революционные — идут в мусорку. Ограниченая функциональность. Вы огранчены рамками SWT. Все что выходит за рамки библиотеки, придется писать самим. Иногда это обходится "дорого", так как приходится писать на JNI для множества предполагаемых систем. Вы привязаны к "платформе". Это значит, что если какого-либо native-компонета нет в системе — ваша программа будет работать без него (Например, Eclipst до сих пор не может подружить версии SWT с Motif).
Blazkowicz wrote: > M>Обратная сторона really-native-look-and-feel. > Java 1.6 Swing Windows Look&Feel ни на глаз ни на ощупь не отличим от > really-native-look-and-feel.
Вот только сказок не надо. Еще как отличимо, без
net.java.plaf.windows.WindowsLookAndFeel там вообще кууууча багов,
причем сложнообходимых.
0rc>Список недостатков (ИМХО):
0rc>SWT сравнительно молодая библиотека. Разработчик, который использует эту библиотеку "по крупному" обречен хоть раз запостить баг в багрепорт Eclipse комьюнити. Если посмотреть на баг-листы SWT можно заметить, что абсолютное большенство багов и рассуждений в новостных рассылках SWT от разрабочиков крупных продуктов на основе этой библиотеки (тот же Azureus проект или SWT Designer). Итак вторая проблема — это баги, из-за молодости библиотеки. Многие пофишены, но все-равно они есть еще.
Не все так страшно, библиотека не настолько молодая, и на ней написан не один крупный проект.
0rc>Вы не управляете развитием библиотеки. Формально библиотека открытая, фактически — есть сообщество, планы которого задокументированы на год вперед. Из-за этого ваши идеи, пусть и революционные — идут в мусорку.
Хм.. а ситуация с MFC, Winforms, QT или Swing лучше?
0rc>Ограниченая функциональность. Вы огранчены рамками SWT. Все что выходит за рамки библиотеки, придется писать самим. Иногда это обходится "дорого", так как приходится писать на JNI для множества предполагаемых систем.
Это цена кросплатформености. Если проект только под Windows — JNI кодa не намного больше чем расширяя MFC.
0rc>Вы привязаны к "платформе". Это значит, что если какого-либо native-компонета нет в системе — ваша программа будет работать без него (Например, Eclipst до сих пор не может подружить версии SWT с Motif).
Обратная сторона really-native-look-and-feel.
Если не заморачиваться на естественных ограничениях возникающих при выборе кросплатформенной библиотеки, остаются только возражения по дизайну.
Встречал мнение: требование SWT, чтоб все операции с виджетами проходили в одном потоке в, это плохо.
Можно поругать SWT за то что вместо асинхронных делегатов как в Winforms, многопоточность реализована через метод Display.[a]syncExec...
Но это все не мое IMHO. По мне так SWT+Jface рулят.
-- Главное про деструктор копирования не забыть --
cvetkov wrote: > 0rc>Сейчас я бы не назвал это большой проблемой, хотя до недавнего > времени (как сейчас не знаю) существовали платформы, для которых не было > JRE. > До недавнего времени SWT было только для Windows. Сейчас кажеться > ситуация изменилась, но я не уверен.
SWT с рождения поддерживала Linux.
Здравствуйте, lomeo, Вы писали:
L>Я к тому, что сколько инсталляторов не делай, а JRE пользователю нужно. Если его нет, то его надо качать и ставить. Как он это будет делать — качать отдельно или встроенный — неважно. Это дополнительные телодвижения. А дополнительные телодвижения достоинством назвать трудно.
Грамотно распространяемое ПО позволяет пользователю:Выбирать для скачивания один из инсталляторов: с включенной средой исполнения или без.
Во время установки инсталлятор определяет наличие среды исполнения (в случае .NET это кроме прочего и предшествующее определение наличия следующего ПО требуемой версии: IE, Windows Installer и прочее), и в случае ее отсутствия:
инсталлятор со встроенным сопутствующим ПО автоматически устанавливает его, пользователь, в принципе, может и не заметить этого;
"легкий" инсталлятор предлагает автоматически загрузить соответствуюшее ПО из Интернета;
Таким образом, пользователю достаточно жимкнуть OK в диалоге: ПО будет при необходимости загружено и установлено.
Телодвижения при грамотном распространении приложения минимальны — нажать OK в соответствующем диалоге. Проблема вовсе не в самом факте существования сопуствующего ПО, среда исполнения управляемых платформ в этом отношении ничем не отличается от используемой в программе конкретной библиотеки, БД и прочего. Проблема в том, как это сопутствующее ПО поставляется. Если программист не заботится о телодвижениях пользователей, то проблемы будут без вариантов.
Здравствуйте, igna, Вы писали:
I>Какие недостатки есть у Java/SWT по сравнению с другими комбинациями язык/библиотека для программирования под Windows? Хочу, чтоб поругали.
SWT — мощная библиотека, качество реализации которой не хуже чем у конкурентов, а функционально она, возможно, даже лучше (я имею в виду рюшечки Eclipse RCP). Соответственно, на мой взгляд единственный существенный недостаток — отсутствие нормальной реализации под Vista. Планы сообщества по развитию этого направления, мягко говоря, невнятные — первая нормальная версия ожидается в 2008 г. Сколько в ней будет глюков — одному богу известно. Насколько я понимаю, у Swing с этим сейчас дела обстоят существенно лучше (во всяком случае в Netbeans работать можно, а Eclipse нельзя ).
Здравствуйте, igna, Вы писали:
I>Какие недостатки есть у Java/SWT по сравнению с другими комбинациями язык/библиотека для программирования под Windows? Хочу, чтоб поругали.
Меня разражают ограничения, которые накладывает SWT на кодирование. Такие как, например, обязательная передача родительского виджета в конструктор. И ещё потрясающие взаимозаменяемые int константы.
В проекте Nebula реализовали новые "хрени" (widgets): календарь, диаграмму Ганта — красота!
PS Досадно только, что в CalendarCombo пока явный архитектурный баг имеет место...
Здравствуйте, igna, Вы писали:
I>Да, вот это интересно. Некоторые считают зависимость от JVM (или CLR) недостатком, некоторые нет. В чем конкретно ты видишь недостаток?
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, 0rc, Вы писали:
0rc>>SWT базируется на Java, отсюда очевидный недостаток — SWT зависит от Java R>Со всем согласен, но вот это философское утверждение не понял, можно разжевать?
Я имел ввиду JVM, так например есть тот же MFC, он не привязан к JVM, в этом смысле MFC "лучше" SWT так как не требует предустановленной JRE.
Здравствуйте, 0rc, Вы писали:
0rc>Сейчас я бы не назвал это большой проблемой, хотя до недавнего времени (как сейчас не знаю) существовали платформы, для которых не было JRE.
До недавнего времени SWT было только для Windows. Сейчас кажеться ситуация изменилась, но я не уверен.
Здравствуйте, igna, Вы писали:
I>Не прими за занудность, но почему это недостаток? Чем это хуже случая, когда программа использует некую библиотеку, dll которой нужно установить?
Ничем, если размеры и усилия при установке библиотеки и JRE сопоставимы.
Я же не говорю, что это огромный минус. Но это отнюдь не достоинство, и иногда это надо учитывать. Я скорее скачаю программку на 5 мегабайт, чем на 50, если функциональность у них схожая. И мне абсолютно по барабану насколько удобно было разработчикам её разрабатывать.
Кстати, SWT — это также и новый проект Nebula Project. Он, правда, пока на стадии так называемом eclipse incubation. Давно не смотрел, в каком он состоянии, сейчас глянул — понравилось, пожалуй, попробую сейчас эту красоту в работе.
Каково, а?
PS Там и другие есть.
Здравствуйте, 0rc, Вы писали:
0rc>SWT базируется на Java, отсюда очевидный недостаток — SWT зависит от Java
Со всем согласен, но вот это философское утверждение не понял, можно разжевать?
Здравствуйте, 0rc, Вы писали:
0rc>Я имел ввиду JVM, так например есть тот же MFC, он не привязан к JVM, в этом смысле MFC "лучше" SWT так как не требует предустановленной JRE.
Да, вот это интересно. Некоторые считают зависимость от JVM (или CLR) недостатком, некоторые нет. В чем конкретно ты видишь недостаток?
Здравствуйте, igna, Вы писали:
I>Здравствуйте, 0rc, Вы писали:
0rc>>Я имел ввиду JVM, так например есть тот же MFC, он не привязан к JVM, в этом смысле MFC "лучше" SWT так как не требует предустановленной JRE.
I>Да, вот это интересно. Некоторые считают зависимость от JVM (или CLR) недостатком, некоторые нет. В чем конкретно ты видишь недостаток?
Сейчас я бы не назвал это большой проблемой, хотя до недавнего времени (как сейчас не знаю) существовали платформы, для которых не было JRE.
Здравствуйте, cvetkov, Вы писали:
C>До недавнего времени SWT было только для Windows. Сейчас кажеться ситуация изменилась, но я не уверен.
Cyberax истину глаголет — с Linux-ом SWT дружил всегда. А теперь вот это многообразие:
SWT:
Windows.
Windows (x86/WPF).
Windows (x86_64).
Linux (x86/GTK 2).
Linux (x86/Motif).
Linux (x86_64/GTK 2).
Linux (PPC/GTK 2).
Linux (s390/GTK 2).
Linux (s390x/GTK 2).
Solaris 8 (SPARC/GTK 2).
AIX (PPC/Motif).
Mac OSX (Mac/Carbon)
eSWT:
Windows Desktop.
Windows Mobile 2003/5.
WinCE 5.0 Professional.
Nokia Series 80.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, cvetkov, Вы писали:
C>>До недавнего времени SWT было только для Windows. Сейчас кажеться ситуация изменилась, но я не уверен. R>Cyberax истину глаголет — с Linux-ом SWT дружил всегда. А теперь вот это многообразие:
R>[list=1]SWT:
Здравствуйте, 0rc, Вы писали:
0rc>>>SWT базируется на Java, отсюда очевидный недостаток — SWT зависит от Java R>>Со всем согласен, но вот это философское утверждение не понял, можно разжевать?
0rc>Я имел ввиду JVM, так например есть тот же MFC, он не привязан к JVM, в этом смысле MFC "лучше" SWT так как не требует предустановленной JRE.
С таким же успехом можно сказать, что "SWT не привязан к windows, в этом смысле SWT лучше MFC так как не требует предустановленной windows". В конце концов любой gui от чего-то зависит, так что имхо совсем не аргумент
Здравствуйте, lomeo, Вы писали:
L>Ещё мегабайты.
~9Mb, с размером встроенного .NET, кстати, несравнимо, как впрочем и по простоте установки.
L> Возможно, из-за размера потенциальный пользователь откажется это качать.
Так сделать два инсталлятора. Это проблема распространения приложения, а не проблема самого приложения.
Здравствуйте, rsn81, Вы писали:
L>> Возможно, из-за размера потенциальный пользователь откажется это качать. R>Так сделать два инсталлятора. Это проблема распространения приложения, а не проблема самого приложения.
Я к тому, что сколько инсталляторов не делай, а JRE пользователю нужно. Если его нет, то его надо качать и ставить. Как он это будет делать — качать отдельно или встроенный — неважно. Это дополнительные телодвижения. А дополнительные телодвижения достоинством назвать трудно.
Здравствуйте, mishaa, Вы писали:
0rc>>баги, из-за молодости библиотеки. M>Не все так страшно, библиотека не настолько молодая, и на ней написан не один крупный проект.
Тем не менее не приятно писать в багтреке что новая бага из-за SWT и нет нормальной возможности её исправить в кратчайшие сроки.
Даже если расковырять код и исправить самому, сразу же ребром станет вопрос апдейта версий.
0rc>>Вы не управляете развитием библиотеки. M>Хм.. а ситуация с MFC, Winforms, QT или Swing лучше?
Swing лучше. Во-первых, изменение версии Java гораздо более серьезный шаг для проекта чем изменение версии SWT. Во-вторых код Swing, гораздо более лаконичный, и уж досадных багов найти там очень не просто.
0rc>>Ограниченая функциональность. M>Это цена кросплатформености. Если проект только под Windows — JNI кодa не намного больше чем расширяя MFC.
Со Swing, цена кроссплатформености становится ещё меньше.
0rc>>Вы привязаны к "платформе". Это значит, что если какого-либо native-компонета нет в системе — ваша программа будет работать без него (Например, Eclipst до сих пор не может подружить версии SWT с Motif). M>Обратная сторона really-native-look-and-feel.
Java 1.6 Swing Windows Look&Feel ни на глаз ни на ощупь не отличим от really-native-look-and-feel.
M>Если не заморачиваться на естественных ограничениях возникающих при выборе кросплатформенной библиотеки, остаются только возражения по дизайну.
Да, дизайн SWT диктующий свои ограничения на порядок создания объектов никогда не радовал.
M>Встречал мнение: требование SWT, чтоб все операции с виджетами проходили в одном потоке в, это плохо.
Что в этом особо плохого — не ясно.
B>Меня разражают ограничения, которые накладывает SWT на кодирование. Такие как, например, обязательная передача родительского виджета в конструктор. И ещё потрясающие взаимозаменяемые int константы.
Та же фигня. Но писать гуй это в общем-то не мешает.