trdm пишет:
> MZ>А что, в QT нет Doc/View структруры и Doc не может обрабатывать события ? > MZ>Вроде есть, и может. А что, в QT не реализована Chain of responsibility ? > MZ>Должна, если есть Doc/View. > да вроде нету "Doc/View". есть модель/представление/делегат
Здравствуйте, yaroslavp, Вы писали: Y>Прекрасные впечатления от wxWidgets. С++, стабильная, много пользователей, полная и понятная документация, оччччень много фич и классов-утилит.
покажи мне эту понятную и полную документацию, плз.
Здравствуйте, pepsicoca, Вы писали:
P>Долгое время довольно успешно для разработки под Win использовал BCB60 и его VCL. Из-за разных причин возникла необходимость перейти на MSVC. Подскажите, какую С++ библиотеку для MSVC сейчас принято использовать для программирования GUI? Или же народ пишет GUI на C# и VB, а логику прикручивает на С++? Не хотелось бы изучать новый язык для написания GUI, хотелось бы обойтись С++.
HTMLayout. Лучше нет ничего.
Здравствуйте, trdm, Вы писали:
T>Здравствуйте, yaroslavp, Вы писали: Y>>Прекрасные впечатления от wxWidgets. С++, стабильная, много пользователей, полная и понятная документация, оччччень много фич и классов-утилит. T>покажи мне эту понятную и полную документацию, плз.
Идёт в комплекте. Проблем с пониманием не возникало, тем более, что у wxWidgets большое наследие от MFC, что смущает поначалу, но потом привыкаешь.
byleas пишет:
> T>покажи мне эту понятную и полную документацию, плз. > Идёт в комплекте. Проблем с пониманием не возникало, тем более, что у > wxWidgets большое наследие от MFC, что смущает поначалу, но потом > привыкаешь.
В каком смысле "наследие" ? Ты поясни, а то будут думать, что они
код из MFC взяли.
Здравствуйте, MasterZiv, Вы писали:
>> T>покажи мне эту понятную и полную документацию, плз. >> Идёт в комплекте. Проблем с пониманием не возникало, тем более, что у >> wxWidgets большое наследие от MFC, что смущает поначалу, но потом >> привыкаешь.
MZ>В каком смысле "наследие" ? Ты поясни, а то будут думать, что они MZ>код из MFC взяли.
Макросы похоже называются. Этим сходство и ограничивается, IMHO
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, trdm, Вы писали:
T>Здравствуйте, yaroslavp, Вы писали: Y>>Прекрасные впечатления от wxWidgets. С++, стабильная, много пользователей, полная и понятная документация, оччччень много фич и классов-утилит. T>покажи мне эту понятную и полную документацию, плз.
Здравствуйте, yaroslavp, Вы писали:
Y>Здравствуйте, trdm, Вы писали:
T>>Здравствуйте, yaroslavp, Вы писали: Y>>>Прекрасные впечатления от wxWidgets. С++, стабильная, много пользователей, полная и понятная документация, оччччень много фич и классов-утилит. T>>покажи мне эту понятную и полную документацию, плз.
Y>C:\Program Files\wxWidgets-2.8.8\docs\htmlhelp\wx.chm, 3.1 MB
Сравни: http://docs.wxwidgets.org/stable/wx_wxapp.html 28,4 КБ (29 083 байт)
и http://doc.trolltech.com/4.4/qapplication.html 96,46 КБ (98 775 байт)
у Qt все с примерами, пояснениями и т.п.
Здравствуйте, trdm, Вы писали:
T>>>Здравствуйте, yaroslavp, Вы писали: Y>>>>Прекрасные впечатления от wxWidgets. С++, стабильная, много пользователей, полная и понятная документация, оччччень много фич и классов-утилит. T>>>покажи мне эту понятную и полную документацию, плз.
Y>>C:\Program Files\wxWidgets-2.8.8\docs\htmlhelp\wx.chm, 3.1 MB T>Сравни: T>http://docs.wxwidgets.org/stable/wx_wxapp.html 28,4 КБ (29 083 байт) T>и T>http://doc.trolltech.com/4.4/qapplication.html 96,46 КБ (98 775 байт) T>у Qt все с примерами, пояснениями и т.п.
У QTшного QApplication просто методов-свойств-сигналов в три раза больше, чем у wxApp У wx например кой-чего в wxSystemSettings и wxSystemOptions вынесено, из того что у QT в QApplication живет. Будем их объем прибавлять? Или например есть отдельный глобальный wxTheClipboard вместо QApplication::clipboard() — соответственно, минус 3 строки в доке на wxApp. Или например аналоги QApplication::setOverrideCursor и QApplication::setKeypadNavigationEnabled в wx просто отсутствуют. Так что нельзя так тупо по килобайтам полноту документации сравнивать.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>Здравствуйте, trdm, Вы писали:
T>>>>Здравствуйте, yaroslavp, Вы писали: Y>>>>>Прекрасные впечатления от wxWidgets. С++, стабильная, много пользователей, полная и понятная документация, оччччень много фич и классов-утилит. T>>>>покажи мне эту понятную и полную документацию, плз.
Y>>>C:\Program Files\wxWidgets-2.8.8\docs\htmlhelp\wx.chm, 3.1 MB T>>Сравни: T>>http://docs.wxwidgets.org/stable/wx_wxapp.html 28,4 КБ (29 083 байт) T>>и T>>http://doc.trolltech.com/4.4/qapplication.html 96,46 КБ (98 775 байт) T>>у Qt все с примерами, пояснениями и т.п.
ТКС>У QTшного QApplication просто методов-свойств-сигналов в три раза больше, чем у wxApp У wx например кой-чего в wxSystemSettings и wxSystemOptions вынесено, из того что у QT в QApplication живет. Будем их объем прибавлять? Или например есть отдельный глобальный wxTheClipboard вместо QApplication::clipboard() — соответственно, минус 3 строки в доке на wxApp. Или например аналоги QApplication::setOverrideCursor и QApplication::setKeypadNavigationEnabled в wx просто отсутствуют. Так что нельзя так тупо по килобайтам полноту документации сравнивать.
Подожди, так ты и не сравнивай по килобайтам, попробуй по качеству документации сравнить. Хотя, честно говоря, Qt в этом плане тоже есть еще куда расти.
По моему сравнивать документацию по размеру в байтах HTML файла неразумно, более того, чем проще документация — тем лучше.
Вопросы неоправданной перегруженности Qt и реализацией в ней велосипедных технологий, которые являются жалким подобием boost, CSS, HTML/XAML и OpenGL уже обсуждалось в этом форуме.
Если хочется пофлеймить — велкам в КСВ.
Здравствуйте, astral_marine, Вы писали:
_>Вопросы неоправданной перегруженности Qt и реализацией в ней велосипедных технологий, _>которые являются жалким подобием boost, CSS, HTML/XAML и OpenGL уже обсуждалось в этом форуме. _>Если хочется пофлеймить — велкам в КСВ.
"неоправданной перегруженности"? Это ты pimpl имеешь ввиду? А с чего это стало неоправданным?
тяжелая технология, не спорю, но насчет неоправданости это ты погоречилсё.
"жалкие велосипедные технологии"? А мне лично нравится, что простенький аналог HTML — как
раз то что нужно для имплементации простенькой хелп-системы, мне теперь побарабану, что за
система и какой в ней браузер, тем более есть под нее готовый редактор редактор и не надо голову ломать.
И насчет прочего есть что сказать, так что твое псевдо-донкихотство тут на меня лично впечатление не производит.
GUI их много разных. Писать положено на том что больше всего подходит для данной конкретной задачи.
Я в свое время работал со множеством всякого рода GUI frameworks и toolkits. От голого API до скажем VB6.
Попробую описать базовые идеи заложенные в дизайн htmlayout и sciter как UI engines с точки зрения C++ программинга.
Неинтрузивность: Я считаю что GUI должен быть наименее интрузивным что-ли к остальному коду, С++ (и не только).
Т.е. скажем GUI engine не должен требовать обязательного использования CArray или CMap вместо vector<> или map<>.
Логика приложения пишется на том что удобно, актуально, эффективно. Я считаю неэтичным (т.е. технически неоправданным)
требовать от логики приложения например использовать обязательно .NET или скажем быть MOC совместимым.
Простота и унфицированность: GUI как абстракция это достаточно простая вещь — набор неких визуальных элементов из
которых как из кубиков складывается то что надо. Представляется удобным/удачным представление GUI системой
unisex(т.е. универсальных) DOM элементов. Т.е. вместо толпы всяко разных CLabel, CButton, CEdit используется один
единственный dom::element. Который кстати документируется просто одним .h файлом.
Кстати скажем CLabel не всегда в чистом виде label иногда оно например должно уметь генерировать clicks. По идее
это не должно требовать создания новых сущностей типа CClickableLabel.
Универсальность представления GUI как дерева dom::elements имеет еще один и очень большой плюс — на дереве
можно строить запросы например в форме CSS selectors. Т.е. каждый компонент GUI становится адресуемым без
лишних организационных вопросов. Скажем вот это:
element el = root.select(".stock-list > option[value=microsoft]");
el.set_attribute("class", "highlight");
в любом GUI toolkit вызовет как правило какие-то нетривально содрогательные телодвижения.
В качестве упражнения предлагается реализовать "во всех списках в этом view у которых один из классов есть stock-list установить
highlight класс у option имеющих атрибут value == microsoft". и рендеринг option.highlight должен определяться неким конфигурационным файлом
а не быть прошитым в коде. Или скажем с точки зрения логики программы некая form это просто набор значений: map<id,value> — на
селекторах такое делается элементарно. (behavior:form в h-smile core обрабатывает get/set_value() именно как map<name,value>, т.е. out of the box).
htmlayout API снаружи это три сущности view (т.е. окно), element и behavior/event_handler ( custom micro window ). Всё.
Там и документировать-то особо не чего. Единственно что требует документации это набор встроенных behaviors
которые цепляются на DOM элементы превращая тот или иной DOM элемент в скажем кнопку или combobox.
Здесь они все: http://www.terrainformatica.com/wiki/h-smile/built-in-behaviors/start
Изолированность:
GUI как система элементов живет своей жизнью. Логика приложения живет своей. Чем меньше эти две сущности связаны
между собой тем лучше. Скажем в Нортон продуктах вся работа (логика приложения) делается в worker threads. Вся работа с GUI делается механизмом
котрый имплементирован в htmlayout::queue (у них своя версия оного но принцип тот же). Т.е. никто никому не мешает.
Декларативность:
Практика показала что mostly declarative GUI это хорошо и правильно. Под декларативностью имеется ввиду в основном не описание структуры DOM,
а описание системы стилей этого DOM и нюансов связанных с поведением GUI в той или иной locale.
Чтобы не растекаться мыслью по древу вот пара скриншотов одного и того же дерева DOM элементов но при разных OS themes:
стандартной:
и high-contrast-white:
переключение осуществляется сменой таблицы стилей или отдельных правил. И не требует никаких бешенных телодвижений
размазанных по всему коду. Кстати прошу обратить внимание на серьёзность проблемы accessibility. Для программ продаваемых в "приличных" странах это the must.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, pepsicoca, Вы писали:
P>>Долгое время довольно успешно для разработки под Win использовал BCB60 и его VCL. Из-за разных причин возникла необходимость перейти на MSVC. Подскажите, какую С++ библиотеку для MSVC сейчас принято использовать для программирования GUI? Или же народ пишет GUI на C# и VB, а логику прикручивает на С++? Не хотелось бы изучать новый язык для написания GUI, хотелось бы обойтись С++. C>HTMLayout. Лучше нет ничего.
на самом деле есть. Qt.
Объясню почему он мне нравиться больше HTML layout.
Плюсы:
1) Для описания UI можно использовать стандартную связку HTML+JavaScript+CSS (+jQuery), нестандартные расширения (css 3) будут работать минимум в 5 браузерах (Chrome, Safari, Maxthon, Konqueror, Arora). UI можно тестировать с помощью любого из перечисленных браузеров.
2) Движок активно развивается, баги фиксятся Apple, Google и Nokia и opensource коммюнити.
3) Кроссплатформенность — Mac OS X, Linux, Windows.
4) Хорошая интеграция с С++:
экземпляр класса
class MyDataSource : public QObject
{
Q_OBJECT
Q_PROPERTY(QString foo read foo write setFoo)
Q_PROPERTY(int bar read bar write setBar)
public:
... skipped
public slots:
int doSomething(const QString& a1, int a2);
};
можно сделать видимым в яваскрипт-коде вызовом одной функции, причем яваскрипту будут "видны" свойства объекта foo и bar и метод doSomething (достигается путем прозрачного введения информации о типе Qt moc-ом).
5) Достойное быстродействие.
6) Легкость использования с другими хорошими вещами из Qt — сетевой библиотекой, плагинами и прочим.
Минусы:
1) Большой размер библиотек (в сумме — QtCore + QtGui + QtWebKit + plugins могут набежать до >20 Мб, в зависимости от конфигурации).
Впрочем сейчас это не очень большая проблема.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, pepsicoca, Вы писали:
.. CS>размазанных по всему коду. Кстати прошу обратить внимание на серьёзность проблемы accessibility. Для программ продаваемых в "приличных" странах это the must.
а можно поподробнее про accessibility (я так понял подразумеваются "facilities or amenities to assist people with disabilities") и почему это must have?
Кстати, было бы интересно узнать какие есть подходы в HTMLayout к решению проблемы локализации — или это решается стандартно введением отдельных html для нового языка?
Здравствуйте, A13x, Вы писали:
C>>HTMLayout. Лучше нет ничего. A>на самом деле есть. Qt.
Нет, я пробовал.
A>Объясню почему он мне нравиться больше HTML layout. A>Плюсы: A>1) Для описания UI можно использовать стандартную связку HTML+JavaScript+CSS (+jQuery), нестандартные расширения (css 3) будут работать минимум в 5 браузерах (Chrome, Safari, Maxthon, Konqueror, Arora). UI можно тестировать с помощью любого из перечисленных браузеров.
В HTMLayout лучше, там css реально работает. И есть удобнейшие flex units.
A>2) Движок активно развивается, баги фиксятся Apple, Google и Nokia и opensource коммюнити.
Ну да, тут плюс.
A>3) Кроссплатформенность — Mac OS X, Linux, Windows.
В HTMLayout будет к концу года. И он уже есть на WinCE, на который пока QT портировать проблематично.
A>4) Хорошая интеграция с С++:
Есть.
