На чем теперь GUI писать положено? - C/C++. Прикладные вопросы

Здравствуйте, cencio, Вы писали:

C>Здравствуйте, pepsicoca, Вы писали:

P>>Добрый день.

P>>Долгое время довольно успешно для разработки под Win использовал BCB60 и его VCL. Из-за разных причин возникла необходимость перейти на MSVC. Подскажите, какую С++ библиотеку для MSVC сейчас принято использовать для программирования GUI? Или же народ пишет GUI на C# и VB, а логику прикручивает на С++? Не хотелось бы изучать новый язык для написания GUI, хотелось бы обойтись С++.

P>>Спасибо.

C>MFC, фичепак интесный для него выщел, есть куча наработок и либ

MFC это же древний инструмент на макросах? Или я ужа отстал от жизни? Неужели Микрософт за столько лет не написал библиотеки оконных шаблонов типа VCL?

C>Qt хорошая либа, активно развивается и продвигается.

Qt Микрософт продвигает или она сама по себе? Это я к тому, что в мире винды если Микрософт что-то не продвигает, то этому бывает кирдык.

Здравствуйте, Nik_1, Вы писали:

N_>Здравствуйте, pepsicoca, Вы писали:
N_>Подскажите, какую С++ библиотеку для MSVC сейчас принято использовать для программирования GUI? Или же народ пишет GUI на C# и VB, а логику прикручивает на С++? Не хотелось бы изучать новый язык для написания GUI, хотелось бы обойтись С++.

N_>По моим наблюдением гуи чаще всего пишут на велосипедах

А в чем юмор?

Здравствуйте, pepsicoca, Вы писали:

P>Здравствуйте, cencio, Вы писали:

C>>Здравствуйте, pepsicoca, Вы писали:

P>>>Добрый день.

P>>>Долгое время довольно успешно для разработки под Win использовал BCB60 и его VCL. Из-за разных причин возникла необходимость перейти на MSVC. Подскажите, какую С++ библиотеку для MSVC сейчас принято использовать для программирования GUI? Или же народ пишет GUI на C# и VB, а логику прикручивает на С++? Не хотелось бы изучать новый язык для написания GUI, хотелось бы обойтись С++.

P>>>Спасибо.

C>>MFC, фичепак интесный для него выщел, есть куча наработок и либ
P>MFC это же древний инструмент на макросах? Или я ужа отстал от жизни? Неужели Микрософт за столько лет не написал библиотеки оконных шаблонов типа VCL?

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

C>>Qt хорошая либа, активно развивается и продвигается.

P>Qt Микрософт продвигает или она сама по себе? Это я к тому, что в мире винды если Микрософт что-то не продвигает, то этому бывает кирдык.

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

Здравствуйте, pepsicoca, Вы писали:
P>Или я ужа отстал от жизни? Неужели Микрософт за столько лет не написал библиотеки оконных шаблонов типа VCL?
Есть больменее удобная новая оконная либа, но тока под дотнет

Уменя складывается впечатления, что они умышленно не развивают чистый с++, чтобы пересодить всех на дотнет.

Здравствуйте, pepsicoca, Вы писали:
N_>>Здравствуйте, pepsicoca, Вы писали:
N_>>Подскажите, какую С++ библиотеку для MSVC сейчас принято использовать для программирования GUI? Или же народ пишет GUI на C# и VB, а логику прикручивает на С++? Не хотелось бы изучать новый язык для написания GUI, хотелось бы обойтись С++.

N_>>По моим наблюдением гуи чаще всего пишут на велосипедах

P>А в чем юмор?

Втом что со стандартными "С++ библиотеку для MSVC для программирования GUI" все настока плохо, что большая часть продуктовых приложений пишется на своих велосипедах. Недавно куте стал активно проникать в эту нишу и возможно скоро закрепиться как больменее стандартное решение.

Здравствуйте, Nik_1, Вы писали:

N_>Здравствуйте, pepsicoca, Вы писали:
P>>Или я ужа отстал от жизни? Неужели Микрософт за столько лет не написал библиотеки оконных шаблонов типа VCL?
N_>Есть больменее удобная новая оконная либа, но тока под дотнет

Уменя складывается впечатления, что они умышленно не развивают чистый с++, чтобы пересодить всех на дотнет.

У меня тоже складывается такое впечатление.

Здравствуйте, pepsicoca, Вы писали:

P>Долгое время довольно успешно для разработки под Win использовал BCB60 и его VCL. Из-за разных причин возникла необходимость перейти на MSVC. Подскажите, какую С++ библиотеку для MSVC сейчас принято использовать для программирования GUI? Или же народ пишет GUI на C# и VB, а логику прикручивает на С++? Не хотелось бы изучать новый язык для написания GUI, хотелось бы обойтись С++.

Если приложение windows-only, то Windows Forms — это то, что доктор прописал. Если есть опыт на VCL, то окажешься в очень знакомом окружении. Собственно в языке разобраться — две недели максимум (по крайней мере на 1.1 так было). Если раньше не писал ненативного кода, то добавь ещё неделю, в течение которой будешь больше втуплять в особенности управления памятью и ссылками, чем писать код. Плюс сколько-то времени понадобится на налаживание интеропа с нативным кодом, если понадобится и в зависимости от того, на сколько он будет сложным. Всё.
Писать на нативном языке интерфейс сейчас имеет смысл только при каких-то особых условиях вроде супер-кроссплатформенности (круче Явы) или требований к отзывчивости. Ну а при таких условиях ГУИ будет не самой большой проблемой. ИМХО.

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, pepsicoca, Вы писали:

P>>Долгое время довольно успешно для разработки под Win использовал BCB60 и его VCL. Из-за разных причин возникла необходимость перейти на MSVC. Подскажите, какую С++ библиотеку для MSVC сейчас принято использовать для программирования GUI? Или же народ пишет GUI на C# и VB, а логику прикручивает на С++? Не хотелось бы изучать новый язык для написания GUI, хотелось бы обойтись С++.

M>Если приложение windows-only, то Windows Forms — это то, что доктор прописал. Если есть опыт на VCL, то окажешься в очень знакомом окружении. Собственно в языке разобраться — две недели максимум (по крайней мере на 1.1 так было). Если раньше не писал ненативного кода, то добавь ещё неделю, в течение которой будешь больше втуплять в особенности управления памятью и ссылками, чем писать код. Плюс сколько-то времени понадобится на налаживание интеропа с нативным кодом, если понадобится и в зависимости от того, на сколько он будет сложным. Всё.
M>Писать на нативном языке интерфейс сейчас имеет смысл только при каких-то особых условиях вроде супер-кроссплатформенности (круче Явы) или требований к отзывчивости. Ну а при таких условиях ГУИ будет не самой большой проблемой. ИМХО.

Что такое Windows Forms? Это оконная библиотека только для С#? Или из С++ тоже можно ее вызвать?

Здравствуйте, pepsicoca, Вы писали:

P>Что такое Windows Forms? Это оконная библиотека только для С#? Или из С++ тоже можно ее вызвать?

Кхм. http://en.wikipedia.org/wiki/Windows_Forms
Библиотека имеет .NET интерфейс. Со всеми вытекающими возможностями "вызова из C++". За подробностми — в туториалы по дотнету. Сильно похожа на VCL, во многом благодаря тому, что году в 2000 её создали люди перешедшие в МС из Борланда (грубо говоря, за подробностями опять же — в гугл).

Уменя складывается впечатления, что они умышленно не развивают чистый с++, чтобы пересодить всех на дотнет.

Этому несколько противоречит тот факт. что вышла новая версия MFC с возможностями, которых вроде в дотнете нет (Office Style и т.д.)

pepsicoca wrote:

Ты знаешь, для VC столько есть вариантов для написания GUI,
что даже все не запомнить.

MFC, ATL, WTL -- тебе уже говорили.

Из GNU-тых: GTK+, TK, QT, WxWidgets и ещё дофига всяких.

С GNU конечно иногда не всё так хорошо, но первые три --
общепризнанно промышленно готовые библиотеки.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, cencio, Вы писали:
C>как раз "новая либа оконных шаблонов" (WTL) как раз офицально и не развивается, а в мфс уже даже рибон контрол есть и всегда можно за приемлемую цену докупить недостающие контролы. и в мфсишных макросах тоже ничего страшного нету, эти либа еще не скоро умрет.
угу. вот на это: Блуждания по лабиринту маршрутизации сообщений и команд в MFC
после Qt и смотреть не хочется.
Может на винде MFC и нормально использовать, но я уже воспринимаю виндовс-онли либы как не кошерные.

trdm wrote:

> угу. вот на это: Блуждания по лабиринту маршрутизации сообщений и команд
> в MFC <http://rsdn.ru/article/mfc/maze.xml>

А что, в QT нет Doc/View структруры и Doc не может обрабатывать события ?
Вроде есть, и может. А что, в QT не реализована Chain of responsibility ?
Должна, если есть Doc/View.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, pepsicoca, Вы писали:

P>Добрый день.

P>Долгое время довольно успешно для разработки под Win использовал BCB60 и его VCL. Из-за разных причин возникла необходимость перейти на MSVC. Подскажите, какую С++ библиотеку для MSVC сейчас принято использовать для программирования GUI? Или же народ пишет GUI на C# и VB, а логику прикручивает на С++? Не хотелось бы изучать новый язык для написания GUI, хотелось бы обойтись С++.

P>Спасибо.

лично мне очень нравится связка логики на C++ с HTML-driven UI на Qt Web Kit.

Здравствуйте, pepsicoca, Вы писали:

P>Здравствуйте, cencio, Вы писали:

C>>Qt хорошая либа, активно развивается и продвигается.

P>Qt Микрософт продвигает или она сама по себе? Это я к тому, что в мире винды если Микрософт что-то не продвигает, то этому бывает кирдык.

А при чем тут мир винды? В общем ответ на твой вопрос: Qt.

Здравствуйте, MasterZiv, Вы писали:

MZ>trdm wrote:

>> угу. вот на это: Блуждания по лабиринту маршрутизации сообщений и команд
>> в MFC <http://rsdn.ru/article/mfc/maze.xml>

MZ>А что, в QT нет Doc/View структруры и Doc не может обрабатывать события ?
MZ>Вроде есть, и может. А что, в QT не реализована Chain of responsibility ?
MZ>Должна, если есть Doc/View.
да вроде нету "Doc/View". есть модель/представление/делегат.
я к тому что в мфц геморно делать многие вещи. В Qt любой сигнал(читай сообщение) от любого объекта можно передать любому объекту,
не тратя много времени. можно внедрить свой перехватчик сообщений в нужный объект без изменения его кода.
карты сообщений на макросах не особо мне нравятся.

trdm пишет:

> MZ>А что, в QT нет Doc/View структруры и Doc не может обрабатывать события ?
> MZ>Вроде есть, и может. А что, в QT не реализована Chain of responsibility ?
> MZ>Должна, если есть Doc/View.
> да вроде нету "Doc/View". есть модель/представление/делегат

Это одно и то же.

Posted via RSDN NNTP Server 2.1 beta

Прекрасные впечатления от wxWidgets. С++, стабильная, много пользователей, полная и понятная документация, оччччень много фич и классов-утилит.

Здравствуйте, yaroslavp, Вы писали:
Y>Прекрасные впечатления от wxWidgets. С++, стабильная, много пользователей, полная и понятная документация, оччччень много фич и классов-утилит.
покажи мне эту понятную и полную документацию, плз.

Здравствуйте, trdm, Вы писали:

T>Здравствуйте, yaroslavp, Вы писали:
Y>>Прекрасные впечатления от wxWidgets. С++, стабильная, много пользователей, полная и понятная документация, оччччень много фич и классов-утилит.
T>покажи мне эту понятную и полную документацию, плз.
Идёт в комплекте. Проблем с пониманием не возникало, тем более, что у wxWidgets большое наследие от MFC, что смущает поначалу, но потом привыкаешь.

byleas пишет:

> T>покажи мне эту понятную и полную документацию, плз.
> Идёт в комплекте. Проблем с пониманием не возникало, тем более, что у
> wxWidgets большое наследие от MFC, что смущает поначалу, но потом
> привыкаешь.

В каком смысле "наследие" ? Ты поясни, а то будут думать, что они
код из MFC взяли.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, MasterZiv, Вы писали:

>> T>покажи мне эту понятную и полную документацию, плз.
>> Идёт в комплекте. Проблем с пониманием не возникало, тем более, что у
>> wxWidgets большое наследие от MFC, что смущает поначалу, но потом
>> привыкаешь.

MZ>В каком смысле "наследие" ? Ты поясни, а то будут думать, что они
MZ>код из MFC взяли.

Макросы похоже называются. Этим сходство и ограничивается, IMHO

Здравствуйте, trdm, Вы писали:

T>Здравствуйте, yaroslavp, Вы писали:
Y>>Прекрасные впечатления от wxWidgets. С++, стабильная, много пользователей, полная и понятная документация, оччччень много фич и классов-утилит.
T>покажи мне эту понятную и полную документацию, плз.

C:\Program Files\wxWidgets-2.8.8\docs\htmlhelp\wx.chm, 3.1 MB

Здравствуйте, 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 просто отсутствуют. Так что нельзя так тупо по килобайтам полноту документации сравнивать.

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>Здравствуйте, 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

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 все с примерами, пояснениями и т.п.

trdm, вот документация по wxWidgets:
http://docs.wxwidgets.org/trunk/page_topics.html
Вот документация по классу wxApp:
http://docs.wxwidgets.org/trunk/classwx_app.html
В wxWidgets в документации по классу описаны только те методы, которые относятся к этому классу. Но и полный список методов можно получить, если надо (List of all members):
http://docs.wxwidgets.org/trunk/classwx_app-members.html

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

Вопросы неоправданной перегруженности Qt и реализацией в ней велосипедных технологий, которые являются жалким подобием boost, CSS, HTML/XAML и OpenGL уже обсуждалось в этом форуме.
Если хочется пофлеймить — велкам в КСВ.

Здравствуйте, astral_marine, Вы писали:

_>Вопросы неоправданной перегруженности Qt и реализацией в ней велосипедных технологий,
_>которые являются жалким подобием boost, CSS, HTML/XAML и OpenGL уже обсуждалось в этом форуме.
_>Если хочется пофлеймить — велкам в КСВ.
"неоправданной перегруженности"? Это ты pimpl имеешь ввиду? А с чего это стало неоправданным?
тяжелая технология, не спорю, но насчет неоправданости это ты погоречилсё.
"жалкие велосипедные технологии"? А мне лично нравится, что простенький аналог HTML — как
раз то что нужно для имплементации простенькой хелп-системы, мне теперь побарабану, что за
система и какой в ней браузер, тем более есть под нее готовый редактор редактор и не надо голову ломать.
И насчет прочего есть что сказать, так что твое псевдо-донкихотство тут на меня лично впечатление не производит.

Здравствуйте, _DAle_, Вы писали:

_DA>Подожди, так ты и не сравнивай по килобайтам, попробуй по качеству документации сравнить.

По качеству — одинакова фигня.

_DA>Хотя, честно говоря, Qt в этом плане тоже есть еще куда расти.

Во-во

Здравствуйте, pepsicoca, Вы писали:

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> HTMLayout. Лучше нет ничего.

Кроме куте конечно

avalon 1.0rc2 rev 300, zlib 1.2.3
build date: 19.08.2009 14:13:36 MSD +04:00
Qt 4.5.2

Здравствуйте, Sheridan, Вы писали:

C>> HTMLayout. Лучше нет ничего.
S>Кроме куте конечно

Не, QT тоже не лучше.

Здравствуйте, 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) Хорошая интеграция с С++:
Есть.

Помимо всего прочего — куте не только гуевая либа. Не стоит этого забывать.

avalon 1.0rc2 rev 300, zlib 1.2.3
build date: 19.08.2009 14:13:36 MSD +04:00
Qt 4.5.2

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, A13x, Вы писали:

C>>>HTMLayout. Лучше нет ничего.
A>>на самом деле есть. Qt.
C>Нет, я пробовал.

A>>Объясню почему он мне нравиться больше HTML layout.
A>>Плюсы:
A>>1) Для описания UI можно использовать стандартную связку HTML+JavaScript+CSS (+jQuery), нестандартные расширения (css 3) будут работать минимум в 5 браузерах (Chrome, Safari, Maxthon, Konqueror, Arora). UI можно тестировать с помощью любого из перечисленных браузеров.
C>В HTMLayout лучше, там css реально работает. И есть удобнейшие flex units.

A>>2) Движок активно развивается, баги фиксятся Apple, Google и Nokia и opensource коммюнити.
C>Ну да, тут плюс.
Еще плюс — у webkit-а открыты исходники. Мне это реально помогало отлаживаться, выбирать оптимальный сценарий в скриптах по генерации UI (отображение произвольно большого списка) и решить нетривиальный баг с отрисовкой плагинов на "старой" версии Qt (4.5.2).

A>>3) Кроссплатформенность — Mac OS X, Linux, Windows.
C>В HTMLayout будет к концу года. И он уже есть на WinCE, на который пока QT портировать проблематично.
А на Mac OS X будет?

A>>4) Хорошая интеграция с С++:
C>Есть.
Такая же хорошая как в Qt?
То есть описал метод-слот и забыл?
Или нужен еще дополнительный код с биндингом?

Здравствуйте, Cyberax, Вы писали:

C>...

И еще — можно ли использовать jQuery c HTMLayout?
Сам я, правда, jQuery пока не использую, ибо не целесообразно пока, но давно присматриваюсь.

Здравствуйте, A13x, Вы писали:

C>>...
A>И еще — можно ли использовать jQuery c HTMLayout?
A>Сам я, правда, jQuery пока не использую, ибо не целесообразно пока, но давно присматриваюсь.
Что именно? CSS-селекторы можно использовать, а сам JQuery в чистом С/C++ невозможен из-за отсутствия контекста.

В Java-обёртке мы сделали JQuery-подобный API:

        $(".navigate [action]", element).listen(new BehaviorEventListener()
        {
            @Override
            public boolean onBehaviorEvent(final BehaviorEventEvent event, final HElement button)
            {
            ...
            }
        }

Для С++ никто не мешает сделать такое же, если не хватает стандартных декораторов.

Если использовать HTMLayout в связке с JavaScript'ом, то можно и полный JQuery сделать.

Здравствуйте, A13x, Вы писали:

A>>>2) Движок активно развивается, баги фиксятся Apple, Google и Nokia и opensource коммюнити.
C>>Ну да, тут плюс.
A>Еще плюс — у webkit-а открыты исходники. Мне это реально помогало отлаживаться, выбирать оптимальный сценарий в скриптах по генерации UI (отображение произвольно большого списка) и решить нетривиальный баг с отрисовкой плагинов на "старой" версии Qt (4.5.2).
Стоп-стоп-стоп. Мы говорим о WebKit'е или QT? На самом WebKit'е писать не особо приятно (я пробовал), не хватает многих необходимых вещей. Скажем, резиновый UI без таблиц никак не сделать, свои behavior'ы тоже нормально не прикручиваются. Тут WebKit сливает HTMLayout'у по полной.

Если мы говорим о самой QT как interface framework, то ситуация другая — там нет нормального CSS, скажем.

Ну и исходники HTMLayout можно получить при желании.

A>>>3) Кроссплатформенность — Mac OS X, Linux, Windows.
C>>В HTMLayout будет к концу года. И он уже есть на WinCE, на который пока QT портировать проблематично.
A>А на Mac OS X будет?
Как только я куплю Мак.

A>>>4) Хорошая интеграция с С++:
C>>Есть.
A>Такая же хорошая как в Qt?
Она просто другая.

A>То есть описал метод-слот и забыл?
A>Или нужен еще дополнительный код с биндингом?
Я когда писал на С++ — делал байндинги с помощью boost::bind+boost::function. Оно получается более правильно, чем система слотов. Ну и в HTMLayout оно немного меньше нужно, особенно если взять Sciter.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, A13x, Вы писали:

A>>>>2) Движок активно развивается, баги фиксятся Apple, Google и Nokia и opensource коммюнити.
C>>>Ну да, тут плюс.
A>>Еще плюс — у webkit-а открыты исходники. Мне это реально помогало отлаживаться, выбирать оптимальный сценарий в скриптах по генерации UI (отображение произвольно большого списка) и решить нетривиальный баг с отрисовкой плагинов на "старой" версии Qt (4.5.2).
C>Стоп-стоп-стоп. Мы говорим о WebKit'е или QT? На самом WebKit'е писать не особо приятно (я пробовал), не хватает многих необходимых вещей. Скажем, резиновый UI без таблиц никак не сделать, свои behavior'ы тоже нормально не прикручиваются. Тут WebKit сливает HTMLayout'у по полной.

Я говорю только о QtWebKit.
По поводу "сливает" — это голословно.
Допустим behaviors в WebKit нет. Потому что они не стандартизированы w3c.
И не факт, что жить без них нельзя никак.
Примеры интерфейсов о которых я говорю —
http://jqueryui.com/demos/tabs/
http://jqueryui.com/demos/datepicker/
и т.п.

На WebKit+JS доступен, например Wolfenstein 3D — http://www.nihilogic.dk/labs/wolf/
Не уверен что будет работать в мозилле, но в хроме и сафари работает довольно шустро.

C>Если мы говорим о самой QT как interface framework, то ситуация другая — там нет нормального CSS, скажем.
согласен, qss пока бедноват для rich-interface приложения.

C>Ну и исходники HTMLayout можно получить при желании.

Хорошо. Вот к примеру мне было бы интересно взглянуть на исходники HTMLayot (на самом деле), просто для образовательных целей. Как мне получить исходники?

A>>>>3) Кроссплатформенность — Mac OS X, Linux, Windows.
C>>>В HTMLayout будет к концу года. И он уже есть на WinCE, на который пока QT портировать проблематично.
A>>А на Mac OS X будет?
C>Как только я куплю Мак.

A>>>>4) Хорошая интеграция с С++:
C>>>Есть.
A>>Такая же хорошая как в Qt?
C>Она просто другая.

Насколько другая?
Пример разработки с QtWebKit:
1) описываем тестовый источник данных (на js) и html, тестируем-отлаживаем все в браузере с удобнейшим FireBug, редактируем в любимом редакторе.
2) перенос на С++ заключается только в описании источника данных с такими же именами слотов.

пример:
моделируемый источник данных и его заполнение тестовыми данными описан в test_data.js:

function TestData(foo, bar, baz) {
...
}
...
TestData.prototype.getFoo = function() {
    return this.foo;
}

TestData.prototype.getBar = function() {
    return this.bar;
}

TestData.prototype.getBaz = function() {
    return this.baz;
}
...
function getTestData() { return new TestData(...); }

нужно написать его аналог на С++ и заменить исходный тестовый на новый, нативный:
достаточно описать test_data.cpp

class TestData : public QObject
{
...
public slots:
 QString getFoo() {..}
 QString getBar() {..}
 QString getBaz() {..}
};

и все!

Замена на новый источник данных может быть сделана тривиально в коде загрузки источника данных:

var data;
try {
data  = cppData;
}
catch (err) {
// используем тестовый источник данных, если не привязан С++ объект cppData
data = getTestData();
}

соответственно привязка cppDataSource делается тривиально из кода:

frame->addToJavaScriptWindowObject("cppData", new TestData(...));

A>>То есть описал метод-слот и забыл?
A>>Или нужен еще дополнительный код с биндингом?
C>Я когда писал на С++ — делал байндинги с помощью boost::bind+boost::function. Оно получается более правильно, чем система слотов. Ну и в HTMLayout оно немного меньше нужно, особенно если взять Sciter.

Насчет правильности — в принципе не согласен. Это слишком субъективное понятие

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, A13x, Вы писали:

C>>>...
A>>И еще — можно ли использовать jQuery c HTMLayout?
A>>Сам я, правда, jQuery пока не использую, ибо не целесообразно пока, но давно присматриваюсь.
C>Что именно? CSS-селекторы можно использовать, а сам JQuery в чистом С/C++ невозможен из-за отсутствия контекста.
C>Если использовать HTMLayout в связке с JavaScript'ом, то можно и полный JQuery сделать.

я имею в виду возможность переиспользовать jQuery контролы, например описанный здесь
В вебкит эта возможность доступна out-of-the-box.

Здравствуйте, A13x, Вы писали:

C>>Что именно? CSS-селекторы можно использовать, а сам JQuery в чистом С/C++ невозможен из-за отсутствия контекста.
C>>Если использовать HTMLayout в связке с JavaScript'ом, то можно и полный JQuery сделать.
A>я имею в виду возможность переиспользовать jQuery контролы, например описанный здесь
A>В вебкит эта возможность доступна out-of-the-box.
Большинство анимаций в HTMLayout вообще декларативно задаются в CSS. Поведение контролов делется с помощью behavior'ов. Т.е. как таковой надобности в JQuery-контролах нет.

При желании можно сделать, конечно.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, A13x, Вы писали:

C>>>Что именно? CSS-селекторы можно использовать, а сам JQuery в чистом С/C++ невозможен из-за отсутствия контекста.
C>>>Если использовать HTMLayout в связке с JavaScript'ом, то можно и полный JQuery сделать.
A>>я имею в виду возможность переиспользовать jQuery контролы, например описанный здесь
A>>В вебкит эта возможность доступна out-of-the-box.
C>Большинство анимаций в HTMLayout вообще декларативно задаются в CSS. Поведение контролов делется с помощью behavior'ов. Т.е. как таковой надобности в JQuery-контролах нет.

Это к вопросу о повторной используемости. jQuery предлагает много поддерживаемых и нетривиальных решений для достаточно сложных аспектов разработки UI — themes, item views, drag'n'drop, tab widgets, и т.п.
Не сомневаюсь, что подобное можно повторить на HTMLayout, однако, по всей видимости, не настолько же просто как с jQuery — путем простого подключения соответствующего модуля и создания объекта (взять любой из приведенных выше примеров с jQuery UI).

C>При желании можно сделать, конечно.

то есть HTMLayout + Sciter полностью поддерживают jQuery out-of-the-box? Или все таки надо что-то допиливать?

Здравствуйте, A13x, Вы писали:

C>>Стоп-стоп-стоп. Мы говорим о WebKit'е или QT? На самом WebKit'е писать не особо приятно (я пробовал), не хватает многих необходимых вещей. Скажем, резиновый UI без таблиц никак не сделать, свои behavior'ы тоже нормально не прикручиваются. Тут WebKit сливает HTMLayout'у по полной.
A>Я говорю только о QtWebKit.
A>По поводу "сливает" — это голословно.
Ничуть. Нормальный резиновый UI на чистом CSS не делается.

A>Допустим behaviors в WebKit нет. Потому что они не стандартизированы w3c.
Behavior в HTMLayout'е — это просто аналог контрола. Причём все контролы самого HTMLayout'а реализованы как обычные behavior'ы.

A>И не факт, что жить без них нельзя никак.
Нельзя.

A>Примеры интерфейсов о которых я говорю -
A>http://jqueryui.com/demos/tabs/
A>http://jqueryui.com/demos/datepicker/
A>и т.п.
Аналогичное всё делается, но другими механизмами.

Для табов в HTML будет вот это:

<div class="tabs">
    <div class="strip"> <!-- заголовки табов -->
        <div panel="tab1" selected="true" accesskey="t"><u>T</u>ab One</div>
        <div panel="tab2" accesskey="w">Tab t<u>w</u>o</div>
    </div>
    <div id="tab1"> Первый таб </div>
    <div id="tab2"> Второй таб </div>
</div>

И с помощью CSS подвязывается нужный behavior:

.tabs {
    behavior: tabs;
}

Код behavior'а сюда cut&paste'ить не буду.

A>На WebKit+JS доступен, например Wolfenstein 3D — http://www.nihilogic.dk/labs/wolf/
A>Не уверен что будет работать в мозилле, но в хроме и сафари работает довольно шустро.
Причём тут это — вообще непонятно. В HTMLayout'е берёшь графическую поверхность нужного элемента, и хоть FarCry на ней рисуй. С помощью нормального нативного кода, а не на JS.

C>>Ну и исходники HTMLayout можно получить при желании.
A>Хорошо. Вот к примеру мне было бы интересно взглянуть на исходники HTMLayot (на самом деле), просто для образовательных целей. Как мне получить исходники?
Пишешь csmile'у и объясняешь зачем они тебе нужны

A>>>Такая же хорошая как в Qt?
C>>Она просто другая.
A>Насколько другая?
Сильно.

A>Пример разработки с QtWebKit:
A>1) описываем тестовый источник данных (на js) и html, тестируем-отлаживаем все в браузере с удобнейшим FireBug, редактируем в любимом редакторе.
A>2) перенос на С++ заключается только в описании источника данных с такими же именами слотов.
На HTMLayout можно так делать, но не нужно. Проблема в том, что тебе придётся большую часть логики UI делать на JS, что лично мне неудобно. Использование (по сути) RPC для связи с С++ тоже мне не очень приятно.

С HTMLayout мне больше нравится более другая схема — HTMLayout занимается отображением и всякой там анимацией, а код на С++ — всем остальным. Т.е. можно прямо вешать обработчики событий на элементы управления и напрямую привязывать контролы к источникам данных.

Здравствуйте, A13x, Вы писали:

C>>Большинство анимаций в HTMLayout вообще декларативно задаются в CSS. Поведение контролов делется с помощью behavior'ов. Т.е. как таковой надобности в JQuery-контролах нет.
A>Это к вопросу о повторной используемости.
А кто ей мешает? Behavior'ы замечательно переиспользуются.

A>jQuery предлагает много поддерживаемых и нетривиальных решений для достаточно сложных аспектов разработки UI — themes, item views, drag'n'drop, tab widgets, и т.п.
Ряд этого не очень нужен, так как темы лучше и удобнее делать своими средствами HTMLayout'а. Табы — обычный behavior, идущий в стандартном SDK как пример.

D&D в HTMLayout'е сделан удобнее, чем в обычном HTML. В Sciter'е с ним вообще улётные демы есть.

A>Не сомневаюсь, что подобное можно повторить на HTMLayout, однако, по всей видимости, не настолько же просто как с jQuery — путем простого подключения соответствующего модуля и создания объекта (взять любой из приведенных выше примеров с jQuery UI).
Подключение табов, к примеру, делается включением в проект файла behavior_tabs.cpp и его CSS-ки. Всё, ничего больше делать не надо.

C>>При желании можно сделать, конечно.
A>то есть HTMLayout + Sciter полностью поддерживают jQuery out-of-the-box? Или все таки надо что-то допиливать?
Sciter — это не JS. Там свой язык со своими фичами, частично болеее удобными, чем есть в JS.

Я его не использую

Хватает HTMLayout + Java.

Здравствуйте, Cyberax, Вы писали:

C>...

OK, соглашусь со всеми доводами. Однако для меня однозначный deal breaker в том, что:
1) htmlayout не кроссплатформенный (как минимум Linux и Mac OS X не поддерживаются).
2) htmlayout не opensource (imho, лучше б он был платный но с альтернативой использования GPL-лицензированного варианта, как раньше распространялась Qt).

Здравствуйте, A13x, Вы писали:

C>>...
A>OK, соглашусь со всеми доводами. Однако для меня однозначный deal breaker в том, что:
A>1) htmlayout не кроссплатформенный (как минимум Linux и Mac OS X не поддерживаются).
Я занимаюсь портированием. К Новому Году надеюсь сделать версию для Линукса, а там дальше и Mac подтянется.

A>2) htmlayout не opensource (imho, лучше б он был платный но с альтернативой использования GPL-лицензированного варианта, как раньше распространялась Qt).
Так не получится, так как бинарная версия — бесплатна для коммерческого использования.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, A13x, Вы писали:

C>>>...
A>>OK, соглашусь со всеми доводами. Однако для меня однозначный deal breaker в том, что:
A>>1) htmlayout не кроссплатформенный (как минимум Linux и Mac OS X не поддерживаются).
C>Я занимаюсь портированием. К Новому Году надеюсь сделать версию для Линукса, а там дальше и Mac подтянется.

И что, вы сделаете либу для всех популярных архитектур и дистрибутивов? ppc, mips, x86-64, arm? Yellow Dog, Ubuntu, Red Hat, MCBC?

A>>2) htmlayout не opensource (imho, лучше б он был платный но с альтернативой использования GPL-лицензированного варианта, как раньше распространялась Qt).
C>Так не получится, так как бинарная версия — бесплатна для коммерческого использования.

Получится. Если автор захочет (и очень жаль, что он не хочет).

Здравствуйте, A13x, Вы писали:

A>>>OK, соглашусь со всеми доводами. Однако для меня однозначный deal breaker в том, что:
A>>>1) htmlayout не кроссплатформенный (как минимум Linux и Mac OS X не поддерживаются).
C>>Я занимаюсь портированием. К Новому Году надеюсь сделать версию для Линукса, а там дальше и Mac подтянется.
A>И что, вы сделаете либу для всех популярных архитектур и дистрибутивов? ppc, mips, x86-64, arm? Yellow Dog, Ubuntu, Red Hat, MCBC?
А какие проблемы? На ARM и MIPS оно уже работает (под WinCE). Кросс-компиляцию на PPC я точно сделаю, остальные архитктуры особой проблемы тем более не составят.

A>>>2) htmlayout не opensource (imho, лучше б он был платный но с альтернативой использования GPL-лицензированного варианта, как раньше распространялась Qt).
C>>Так не получится, так как бинарная версия — бесплатна для коммерческого использования.
A>Получится. Если автор захочет (и очень жаль, что он не хочет).
У него на это вполне нормальные причины.

Здравствуйте, A13x, Вы писали:

A>я имею в виду возможность переиспользовать jQuery контролы, например описанный здесь
A>В вебкит эта возможность доступна out-of-the-box.
Кстати, посмотрел внимательнее на JQuery tabs.

Ну и маздай.

Клавиатурной навигации нет, горячих клавиш нет, табы не фокусабельные.

Стоит ли говорить, что в HTMLayout оно всё есть?

Здравствуйте, pepsicoca, Вы писали:
P>Добрый день.

P>Долгое время довольно успешно для разработки под Win использовал BCB60 и его VCL. Из-за разных причин возникла необходимость перейти на MSVC. Подскажите, какую С++ библиотеку для MSVC сейчас принято использовать для программирования GUI? Или же народ пишет GUI на C# и VB, а логику прикручивает на С++? Не хотелось бы изучать новый язык для написания GUI, хотелось бы обойтись С++.

P>Спасибо.

попробуй http://ultimatepp.org

сравнение с Qt http://ultimatepp.org/www$uppweb$vsqt$en-us.html
сравнение с wxWidgets http://ultimatepp.org/www$uppweb$vswx$en-us.html
сравнение с Swing http://ultimatepp.org/www$uppweb$vsswing$en-us.html

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, A13x, Вы писали:

A>>я имею в виду возможность переиспользовать jQuery контролы, например описанный здесь
A>>В вебкит эта возможность доступна out-of-the-box.
C>Кстати, посмотрел внимательнее на JQuery tabs.

C>Ну и маздай.

C>Клавиатурной навигации нет, горячих клавиш нет, табы не фокусабельные.

C>Стоит ли говорить, что в HTMLayout оно всё есть?

В контексте моего сообщения это скорее proof-of-concept, или то, что можно сделать. Я не разбирал подробно пример — возможно, что можно очень легко прикрутить клавиатурную навигацию.
В своей работе jQuery я пока не использую, так что квалифицированно ответить по тонкостям использования jQuery увы не смогу.

Плюс к тому jQuery решения портируемы на практически любой браузер (читай портируемое веб-решение). Чего нельзя сказать о HTMLayout.

Наконец подход HTMLayout-а мне в целом не нравится — например описание поведений в С++ коде.
Я предпочитаю видеть описание всего UI отдельно от C++ кода, в котором (опять же с моей точке зрения) лучше описывать только источники данных и основные элементы биндинга.
Подход, в котором динамика(поведение) описывается в js файлах при котором мы получаем максимально реюзабельный код мне видится более "правильным" нежели принятый в HTMLayout, синтаксические расширения которого непортируемы на другой браузер и не могут быть переиспользованы при отходе от HTMLayout-а в сторону другого HTML-движка (Gecko, Presto, WebKit etc.).

Хочу повторить, что вопросы "правильности" здесь по большему счету субъективны, это просто мое мнение

Здравствуйте, A13x, Вы писали:

C>>Стоит ли говорить, что в HTMLayout оно всё есть?
A>В контексте моего сообщения это скорее proof-of-concept, или то, что можно сделать. Я не разбирал подробно пример — возможно, что можно очень легко прикрутить клавиатурную навигацию.
Можно, но не особо легко. С taborder'ом и фокусом в HTML всё плохо.

В этом и проблема HTML — не задумывался он для приложений.

A>В своей работе jQuery я пока не использую, так что квалифицированно ответить по тонкостям использования jQuery увы не смогу.
A>Плюс к тому jQuery решения портируемы на практически любой браузер (читай портируемое веб-решение). Чего нельзя сказать о HTMLayout.
А нафиг оно для десктопного приложения? Если мечта о том, чтобы можно было десктопное приложение засунуть сразу в браузер — то можно забыть, слишком разные подходы.

A>Наконец подход HTMLayout-а мне в целом не нравится — например описание поведений в С++ коде.
A>Я предпочитаю видеть описание всего UI отдельно от C++ кода, в котором (опять же с моей точке зрения) лучше описывать только источники данных и основные элементы биндинга.
Неудобно для сложных интерфейсов.

Здравствуйте, Cyberax, Вы писали:

C>...
C>У него на это вполне нормальные причины.

Кстати, а почему? Если не секрет.
По моему разумению возможны такие варианты:

1) Автор хочет заработать на библиотеке. В этом случае исходники не раскрываются, бинарь продается или предоставляется в бесплатное пользование, сорцы выдаются за отдельную плату по особой лицензии.
2) Автор хочет предоставить библиотеку в бесплатное пользование населению (а я так понимаю это наш случай

)
В этом случае почему бы не выложить исходники в общий доступ (code.google.com) и допустить вариант дальнейшего развития библиотеки по лицензии GPL, а тем кто хочет использовать ее в коммерческих целях предлагать коммерческую лицензию.
Либо (совсем хорошо) предоставить библиотеку в LGPL(BSD/Artistic).
IMHO HTMLayout от такого решения только выиграет...

Здравствуйте, Cyberax, Вы писали:

C>...
C>А нафиг оно для десктопного приложения? Если мечта о том, чтобы можно было десктопное приложение засунуть сразу в браузер — то можно забыть, слишком разные подходы.

Вообще все довольно давно идет к слиянию этих двух подходов.
Windows довольно широко использует HTML в большей части своих диалогов — полностью или частично сделанные на HTML.
Google делает приложения, которые уже довольно близко по функционалу подходят к десктопным.
Пока все конечно далеко от этого, но в будущем ситуация может поменяться.
Особенно учитывая слухи о Chrome OS — http://hexryde.com/2009/07/google-chrome-os-an-open-source-web-oriented-os/

T>"жалкие велосипедные технологии"?
Совмещая неполноценные десктопные и веб технологии получается библиотека, которая имеет недостатки как декстопа (Qt эмулирует контролы, а не использует родные), так и веба (все интернет технологии в Qt крайне убоги). И в результате получается гибридная мутантная библиотека, которую неоправдано усложнена, а возможностей меньше чем у полноценных оригинальных технологий.

T>А мне лично нравится, что простенький аналог HTML — как
T>раз то что нужно для имплементации простенькой хелп-системы, мне теперь побарабану, что за
T>система и какой в ней браузер, тем более есть под нее готовый редактор редактор и не надо голову ломать.

В wxWidgets есть тоже простенький HTML — wxHtml, а также нормальная хелп система — wxHelp

К тому же в Qt есть поддержка только движка WebKit, а в wxWidgets — WebKit, Gecko (Firefox), Trident (IE). IE вообще принципиально невозможно встроить в Qt из-за особенностей неродных для ОС технологий.

Здравствуйте, A13x, Вы писали:

C>>А нафиг оно для десктопного приложения? Если мечта о том, чтобы можно было десктопное приложение засунуть сразу в браузер — то можно забыть, слишком разные подходы.
A>Вообще все довольно давно идет к слиянию этих двух подходов.
Но ещё не подошло.

A>Windows довольно широко использует HTML в большей части своих диалогов — полностью или частично сделанные на HTML.
Как раз наоборот. HTML'ные диалоги в Windows — это вымирающий вид. Они никогда нормально не работали.

A>Google делает приложения, которые уже довольно близко по функционалу подходят к десктопным.
A>Пока все конечно далеко от этого, но в будущем ситуация может поменяться.
A>Особенно учитывая слухи о Chrome OS — http://hexryde.com/2009/07/google-chrome-os-an-open-source-web-oriented-os/
Тем не менее, подтягиваться оно будет со стороны браузеров. Не готов пока обычный HTML к desktop-like приложениям. Его нужно расширять, чем и занимается HTMLayout.

Здравствуйте, A13x, Вы писали:

C>>...
C>>У него на это вполне нормальные причины.
A>Кстати, а почему? Если не секрет.
Могу попробовать объяснить как я понимаю.

A>По моему разумению возможны такие варианты:
A>1) Автор хочет заработать на библиотеке. В этом случае исходники не раскрываются, бинарь продается или предоставляется в бесплатное пользование, сорцы выдаются за отдельную плату по особой лицензии.
Да. Сейчас именно так и делается — ты можешь получить за деньги лицензию на исходные коды. Бинарики можно использовать бесплатно в коммерческих системах.

A>2) Автор хочет предоставить библиотеку в бесплатное пользование населению (а я так понимаю это наш случай

)
Не совсем.

A>В этом случае почему бы не выложить исходники в общий доступ (code.google.com) и допустить вариант дальнейшего развития библиотеки по лицензии GPL, а тем кто хочет использовать ее в коммерческих целях предлагать коммерческую лицензию.
Тогда не получится раздавать бесплатный бинарик для коммерческого использования.

A>Либо (совсем хорошо) предоставить библиотеку в LGPL(BSD/Artistic).
A>IMHO HTMLayout от такого решения только выиграет...
Пинай c-smile'а.

Здравствуйте, astral_marine, Вы писали:

T>>А мне лично нравится, что простенький аналог HTML — как
T>>раз то что нужно для имплементации простенькой хелп-системы, мне теперь побарабану, что за
T>>система и какой в ней браузер, тем более есть под нее готовый редактор редактор и не надо голову ломать.

_>В wxWidgets есть тоже простенький HTML — wxHtml, а также нормальная хелп система — wxHelp

_>К тому же в Qt есть поддержка только движка WebKit, а в wxWidgets — WebKit, Gecko (Firefox), Trident (IE). IE вообще принципиально невозможно встроить в Qt из-за особенностей неродных для ОС технологий.

Насколько я знаю, WebKit в wx встраивается исключительно под макосью. А Firefox — только древний (XulRunner 1.8.1) через wxWebConnect. Ну а IE как бы и даром не надь, и за деньги не надь.
Так что Qt тут явно выигрывает.

Здравствуйте, A13x, Вы писали:

A>Здравствуйте, Cyberax, Вы писали:

C>>...
C>>А нафиг оно для десктопного приложения? Если мечта о том, чтобы можно было десктопное приложение засунуть сразу в браузер — то можно забыть, слишком разные подходы.

A>Вообще все довольно давно идет к слиянию этих двух подходов.
A>Windows довольно широко использует HTML в большей части своих диалогов — полностью или частично сделанные на HTML.

Действительно на заре всего народ был озарен идеей использовать html desktop UI.
В принципе идея-то здравая но вот возникло пара проблем:

1) browser engine общего назначения призван в первую очередь обеспечить safe browsing. Т.е. большой набор действ которые разрешены
desktop приложению просто не разрешены в web ui. Это на самом деле очень глубокий конфликт. Например очень много приложений
которые использовали IE движок просто слетели при переходе со скажем IE6 на IE7. Самое мерзотное что код-то самого приложения не менялся.
Т.е. использование html в UI возможно только если а) HTML движок поставляется с самим приложением и б) ты можешь гарантировать что
следующая версия будет иметь ту же security model.

2) Существующая модель html/css преполагает документ имещий известную ширину но не известную высоту.
Т.е. vertical alignment и то что у меня известно как flex units для desktop UI должны быть обязательно.
Без этого html engine можно серьезно рассматривать в UI только для вещей типа help.

A>Google делает приложения, которые уже довольно близко по функционалу подходят к десктопным.

По функционалу — да. По возможностям — нет. В качестве подпорки google сделал Gears (threading & client side DB).

Ну и в качестве демонстрации пункта №2 выше: открой gmail и посмотри на список писем. Во всех desktop mail клиентах
этот список scrollable. В связи с ограничениями которые я изложил в п.2 сделать такое в Gecko и WebKit невозможно в принципе.
Качество usability — ниже плинтуса.

A>Пока все конечно далеко от этого, но в будущем ситуация может поменяться.
A>Особенно учитывая слухи о Chrome OS — http://hexryde.com/2009/07/google-chrome-os-an-open-source-web-oriented-os/

А чего ждать-то? Вот оно http://en.wikipedia.org/wiki/WebOS уже и сейчас есть.
Я так понимаю что google что-то такое и делает.

Здравствуйте, A13x, Вы писали:

A>Здравствуйте, c-smile, Вы писали:

CS>>Здравствуйте, pepsicoca, Вы писали:
A>..
CS>>размазанных по всему коду. Кстати прошу обратить внимание на серьёзность проблемы accessibility. Для программ продаваемых в "приличных" странах это the must.

A>а можно поподробнее про accessibility (я так понял подразумеваются "facilities or amenities to assist people with disabilities") и почему это must have?

Как минимум поддержка IAccessible (под Windows) + структура самого markup должна быть narrator.exe friendly.

"почему это must have?" Ну во первых есть такая Section 508:

the Rehabilitation Act to require Federal agencies to make their electronic and information technology accessible to people with disabilities

Это распространяется кстати не только на Federal agencies. Нортона например чуть было в суд не затащили со старой версией из-за этого.

A>Кстати, было бы интересно узнать какие есть подходы в HTMLayout к решению проблемы локализации — или это решается стандартно введением отдельных html для нового языка?

Да всяко разны подходы. От использования client side fragment includes: <include src="something-in-current-locale.htm" /> (HLN_LOAD_DATA handler отдает something-in-current-locale в зависимости от языка). До использования переключателя в CSS:

html[lang="ru"] button#on > text { content:"Вкл." }
html[lang="ru"] button#off > text { content:"Выкл." }

Такое использование CSS content является кстати нестандартным и было сделано в htmlayout/sciter специально для нужд localization.
Т.е. это все декларативно, никто не занимается этим в коде, это точно.

Плюс все input элементы, например <input type="date" /> и <input type="time" />, они что называется locale aware.

Здравствуйте, pepsicoca, Вы писали:

P>Добрый день.

P>Долгое время довольно успешно для разработки под Win использовал BCB60 и его VCL. Из-за разных причин возникла необходимость перейти на MSVC. Подскажите, какую С++ библиотеку для MSVC сейчас принято использовать для программирования GUI? Или же народ пишет GUI на C# и VB, а логику прикручивает на С++? Не хотелось бы изучать новый язык для написания GUI, хотелось бы обойтись С++.

P>Спасибо.

а что вы на этом GUI завернулись да напостили ишо скролл залип .. сейчас это не тема вообще, уже давно не 90-е на дворе, что вам так — окно создать ? грид на него налепить ? 5 кнопок и меню ? -создавайте на чем хотите, 99% нутряка современных приложений это негуевый

слой

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, A13x, Вы писали:

C>>>...
A>>В этом случае почему бы не выложить исходники в общий доступ (code.google.com) и допустить вариант дальнейшего развития библиотеки по лицензии GPL, а тем кто хочет использовать ее в коммерческих целях предлагать коммерческую лицензию.
C>Тогда не получится раздавать бесплатный бинарик для коммерческого использования.

ну как же не получится. Вот предположим — вышла новая версия, да вдобавок кроссплатформенная. Автор говорит: все робяты, переходим на новую модель использования, хотите пользоваться новой и последующей версией, будьте любезны переходить на новую лицензию.
Автор не сможет перелицензировать *старую* версию, новые версии — сколько душе угодно.

Несмотря на то что лично я с опаской отношусь к расширениям layout-а, я вижу, что много замечательных программистов, компаний используют успешно этот продукт. Да и само наличие новой ветки форума на RSDN-е посвященной HTMLayout-у говорит само за себя.

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

ТКС>Насколько я знаю, WebKit в wx встраивается исключительно под макосью.
WebKit под Mac OS X встраиватся как родной, для остальных систем есть wxWebKit

ТКС>Ну а IE как бы и даром не надь, и за деньги не надь.
Ну не надо говорить за всех. IE позволяет иметь доступ к веб системам, которые заточены под него. К тому же его не надо устанавливать — а это большой плюс для создания легких приложений или приложений из одного файла.

Здравствуйте, c-smile, Вы писали:

CS>...
Понятно, что существующие подходы с HTML4 + CSS2 не очень хорошо работают в ряде случаев.
Возможно в будущем ситуация измениться с повсеместным распространением HTML5 + CSS3(или 4), Flash или может даже Silverlight.

CS>А чего ждать-то? Вот оно http://en.wikipedia.org/wiki/WebOS уже и сейчас есть.
CS>Я так понимаю что google что-то такое и делает.

Похоже, что это еще на стадии прототипов и экспериментов. Посмотрим, что будет в production версии.

Здравствуйте, astral_marine, Вы писали:

T>>"жалкие велосипедные технологии"?
_>Совмещая неполноценные десктопные и веб технологии получается библиотека, которая имеет недостатки как декстопа (Qt эмулирует контролы, а не использует родные), так и веба (все интернет технологии в Qt крайне убоги). И в результате получается гибридная мутантная библиотека, которую неоправдано усложнена, а возможностей меньше чем у полноценных оригинальных технологий.

_>К тому же в Qt есть поддержка только движка WebKit, а в wxWidgets — WebKit, Gecko (Firefox), Trident (IE). IE вообще принципиально невозможно встроить в Qt из-за особенностей неродных для ОС технологий.
Специфика моих приложений — учетные системы. Это позволяет плевать с высокой телебашни
на те "якобы недостатки" которые вы описали, я с ними просто не имею дело.
Для моих целей Qt это то, что доктор прописал.
Мне не нужна поддержка кипы браузеров, OpenGL, анимации, CSS и т.п.
Для меня важна не "ширина" возможностей, а стабильность, безглючность и набор базовых инструментов.
Кроме того, фрайм-верк он на то и фраймверк, что-бы быть базой, а не охватить все.
Уж это то надо учитывать в рассуждениях. Требовать от базового фраймверка "широких" возможностей в
каждом инструменте немного неправильно. Вот от узконаправленных инструментов, таких как
HTMLayout ширины и ритчевости можно ожидать.
>(Qt эмулирует контролы, а не использует родные)
Чего? Эмулируют? Да у них свои контролы, на своей системе сообщений и паинтере.
Это отлично: возможностей больше. А куцые и неудобные виндовые контролы они уже в печенках сидят.
Как чего посложнее чем просто дерево нарисовать надо будет типа дерева с колонками, так танцы
с бубном и начинаются, знаю, уже танцевали:

Здравствуйте, A13x, Вы писали:

C>>Тогда не получится раздавать бесплатный бинарик для коммерческого использования.
A>ну как же не получится. Вот предположим — вышла новая версия, да вдобавок кроссплатформенная. Автор говорит: все робяты, переходим на новую модель использования, хотите пользоваться новой и последующей версией, будьте любезны переходить на новую лицензию.
A>Автор не сможет перелицензировать *старую* версию, новые версии — сколько душе угодно.
Ты не понял. Если будет GPL-версия, то бесплатный бинарик придётся убрать. Т.е. все программисты, которые сейчас _уже_ бесплатно используют HTMLayout должны будут либо перейти на GPL, либо заплатить за коммерческую лицензию.

A>Говорит все это о том, что это замечательная вещь, полезная многим людям. И было бы замечательно если бы эта библиотека могла развиваться дальше, став кроссплатформенной, опробованной и протестированной в самых разных ситуациях opensource сообществом.
Но ты учти, что c-smile надо на что-то жить

Насколько я понимаю, он сейчас продаёт source code license разным крупным компаниям за деньги.

Приветствую, Cyberax, вы писали:

C> Ты не понял. Если будет GPL-версия, то бесплатный бинарик придётся убрать. Т.е. все программисты, которые сейчас _уже_ бесплатно используют HTMLayout должны будут либо перейти на GPL, либо заплатить за коммерческую лицензию.
LGPL?
К томуже емнип и к GPL никто не запрещает динамически линковаться.

avalon 1.0rc2 rev 300, zlib 1.2.3
build date: 19.08.2009 14:13:36 MSD +04:00
Qt 4.5.2

Здравствуйте, Cyberax, Вы писали:
C>Я занимаюсь портированием. К Новому Году надеюсь сделать версию для Линукса, а там дальше и Mac подтянется.
1. Там будет жава (где-то вроде ты писал про жавскую версию) или нативная либа?
2. Если нативная — то у нее будет сишный интерфейс или только C++?

Здравствуйте, Cyberax, Вы писали:

C>... программисты, которые сейчас _уже_ бесплатно используют HTMLayout должны будут либо перейти на GPL, либо заплатить за коммерческую лицензию.

я имел в виду другое.
Пользователи библиотеки могут использовать бесплатно старые версии, новые выходят под другой лицензией. Автор имеет право поменять лицензию в новой версии продукта.
Т.е. те, кто сейчас бесплатно используют библиотеку смогут ее и дальше бесплатно использовать, но только ту версию, которая уже есть у них.
Для перехода на новую версию им нужно принять новую лицензию.
Новая версия обладает теми же правами, что и новый продукт. Плюс к тому, можно ребрендинг сделать, что это теперь не просто HTMLayout, а Ultimate HTML Toolkit for all the popular platforms that offers one true way to solve all your problems.

Здравствуйте, A13x, Вы писали:
A>Т.е. те, кто сейчас бесплатно используют библиотеку смогут ее и дальше бесплатно использовать, но только ту версию, которая уже есть у них.

Здравствуйте, A13x, Вы писали:

A>Т.е. те, кто сейчас бесплатно используют библиотеку смогут ее и дальше бесплатно использовать, но только ту версию, которая уже есть у них.
A>Для перехода на новую версию им нужно принять новую лицензию.
Ага. Что отпугнёт огромное число разработчиков, так как у них не будет возможности бесплатно использовать HTMLayout, пусть даже в бинарном виде.

A>Новая версия обладает теми же правами, что и новый продукт. Плюс к тому, можно ребрендинг сделать, что это теперь не просто HTMLayout, а Ultimate HTML Toolkit for all the popular platforms that offers one true way to solve all your problems.
HTMLayout — это уже известный бренд.

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Cyberax, Вы писали:
C>>Я занимаюсь портированием. К Новому Году надеюсь сделать версию для Линукса, а там дальше и Mac подтянется.
MC>1. Там будет жава (где-то вроде ты писал про жавскую версию) или нативная либа?
И то и другое.

MC>2. Если нативная — то у нее будет сишный интерфейс или только C++?
С-шный, понятное дело. Тот же самый, что и в обычном HTMLayout'е.

Здравствуйте, Sheridan, Вы писали:

C>> Ты не понял. Если будет GPL-версия, то бесплатный бинарик придётся убрать. Т.е. все программисты, которые сейчас _уже_ бесплатно используют HTMLayout должны будут либо перейти на GPL, либо заплатить за коммерческую лицензию.
S>LGPL?
А на что c-smile будет жить?

S>К томуже емнип и к GPL никто не запрещает динамически линковаться.
Запрещает, причём сама GPL.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, A13x, Вы писали:

A>>Т.е. те, кто сейчас бесплатно используют библиотеку смогут ее и дальше бесплатно использовать, но только ту версию, которая уже есть у них.
A>>Для перехода на новую версию им нужно принять новую лицензию.
C>Ага. Что отпугнёт огромное число разработчиков, так как у них не будет возможности бесплатно использовать HTMLayout, пусть даже в бинарном виде.

если честно — я не понимаю вас.
Ситуация: огромное число разработчиков использует HTMLayout. Очевидно их устраивает использование для коммерческих продуктов, то есть они (или их работодатели) удовлетворены качеством библиотеки для использования в своих проприетарных программах.
Почему они не могут заплатить за нее? Ну допустим 300 баксов? Думаю если если их наберется больше 1000 (и мне кажется наберется) это получиться уже 300000 revenue.
И так же они могут продолжать ее использовать как и раньше если их софт открыт?

Здравствуйте, A13x, Вы писали:

A>...

и еще: GPL = Unlimited Evaluation Period.
По-моему неплохо.

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

Здравствуйте, A13x, Вы писали:

A>Почему они не могут заплатить за нее? Ну допустим 300 баксов? Думаю если если их наберется больше 1000 (и мне кажется наберется) это получиться уже 300000 revenue.
Спроси у c-smile'а. HTMLayout изначально был небесплатным, так что мне самому интересно насколько количество пользователей возросло после того, как он стал бесплатным.

Я лично натыкался в 2004-м году (кажется) на HTMLayout ещё на CodeProject'е (кажется), но тогда не взял из-за того, что он платный был.

Здравствуйте, A13x, Вы писали:

A>Здравствуйте, c-smile, Вы писали:

CS>>...
A>Понятно, что существующие подходы с HTML4 + CSS2 не очень хорошо работают в ряде случаев.
A>Возможно в будущем ситуация измениться с повсеместным распространением HTML5 + CSS3(или 4), Flash или может даже Silverlight.

Заметь что в достаточно отдаленном будущем.
Дело в том что развитие того же WebKit или Mozilla связано по рукам и ногам с процедурой утверждения стандартов.
Скажем я знаю что люди из Mozilla заинтересованы в моих flex units. Но пока они не дойдут до уровня хотя бы обсуждения
никто и шевелиться там не будет. Desktop UI для них priority совсем никакая.

То же самое про размер и состав дистрибуции. Для них основным является распрстранение в виде готового приложения.
Сборка в единый самодостаточный модуль не есть для них необходимость.

Я к тому что ждать можно долго.

CS>>А чего ждать-то? Вот оно http://en.wikipedia.org/wiki/WebOS уже и сейчас есть.
CS>>Я так понимаю что google что-то такое и делает.

A>Похоже, что это еще на стадии прототипов и экспериментов. Посмотрим, что будет в production версии.

WebOS вполне себе рабочая лошадь. Или ты про google OS? А чем кстати Android не подходит? Тоже вполне себе ОС.

Здравствуйте, A13x, Вы писали:

A>то есть HTMLayout + Sciter полностью поддерживают jQuery out-of-the-box? Или все таки надо что-то допиливать?

Sciter содержит практически всю функциональность jQuery в native виде.

Скажем вот

var some = self.$( div.some ); // находим первый элемент

for( var el in self.$$( div.some ) ) // перебираем все элементы div.some
   ... // что-нить с ними делаем.

это то что касается jQuery как таковой. Если же говорить про jQuery UI то опять же много всякого оттуда реализовано нативно.
Например все те же <input type="date">, <input type="calendar">, <input type="time"> и пр.
Т.е. же диалоги например реализованы опять же по-взрослому нативно. view.dialog() создает реально modal dialog.

Про все остальное рекомендую глянуть в sciter/sdk/samples, особливо в sciter/sdk/samples/animations и sciter/sdk/samples/ideas

Здравствуйте, c-smile, Вы писали:

CS>...
CS>Заметь что в достаточно отдаленном будущем.
Да, к сожалению вряд ли мы этого дождемся в ближайший год-два. Или к счастью

CS>То же самое про размер и состав дистрибуции. Для них основным является распрстранение в виде готового приложения.
CS>Сборка в единый самодостаточный модуль не есть для них необходимость.

Под единым самодостаточным модулем понимается единая dll с HTML+JS-движком?
Насчет Gecko не знаю, но WebKit так собрать можно (проверял не так давно). Правда он не будет совсем уж самодостаточен, графическая часть все таки идет стороной (Skia или CoreGraphics или wxWidgets, GTK, Qt или что-то еще...).
Есть вариант собрать без зависимостей от Qt вообще, адаптировать под свои нужды, ввести по необходимости расширения css, я думал об этом, но не стал глубоко копать, т.к. не было необходимости и что самое главное времени, хотя и было бы довольно интересно

Сам по себе WebKit оставил впечатление очень грамотно написанного движка с разветвленной, но четко продуманной и вполне понимаемой структурой, несмотря на его возраст и то что над ним поработало столько людей.
И в перспективе можно было бы поковырять довольно вкусный вариант WebKit-а в исходниках Chrome — там он использует, imho, один из лучших, если не самый лучший js движок v8, плюс, кажется, нет невычищабельных зависимостей от тяжелых либ.

CS>WebOS вполне себе рабочая лошадь. Или ты про google OS? А чем кстати Android не подходит? Тоже вполне себе ОС.

Я про Google OS. Android — это скорее из их плана по захвату вселенной КПК-смартфонов.

Здравствуйте, A13x, Вы писали:

CS>>То же самое про размер и состав дистрибуции. Для них основным является распрстранение в виде готового приложения.
CS>>Сборка в единый самодостаточный модуль не есть для них необходимость.

A>Сам по себе WebKit оставил впечатление очень грамотно написанного движка с разветвленной, но четко продуманной и вполне понимаемой структурой, несмотря на его возраст и то что над ним поработало столько людей.

Да WebKit явно лучше чем Gecko (который просто вызывает тошноту на самом деле). Я бы на месте Mozilla просто перешел на WebKit.

A>И в перспективе можно было бы поковырять довольно вкусный вариант WebKit-а в исходниках Chrome — там он использует, imho, один из лучших, если не самый лучший js движок v8, плюс, кажется, нет невычищабельных зависимостей от тяжелых либ.

А JS это вообще отдельная песня. Начать с того что его спецификация просто содержит очевидные ляпы. (ECMA как standard body вызывает недоумение после принятия ECMAScript в таком виде).

С точки зрения серьёзного программинга JS в том виде что он есть тоже некие сомнения вызывает.
Вот тут http://www.codeproject.com/KB/recipes/TIScript.aspx я попытался описать то что не хватает JS для того чтобы быть мало мальски production level языком в котором есть что-нубдь to write home about.

По поводу V8: весь этот бешенный effort нужен в том случае если у тебя нет возможности перенести критические методы
в native code. Например если у тебя нет эффективного native метода getElementBySelector то да, для того чтобы jQuery реально
работала, нужен JIT и все мегабайты кода с этим связанные. Но скрипт он не для того чтобы на нем делать ray tracing или вычислять селекторы.

В качестве примера:

Here is something close to real:
http://terrainformatica.com/tests/std-table-fixed-10000-rows.htm
This table contains 10`000 rows. First button named Update runs loop
through all rows and does update of cell's text in first column.
Timings on my machine:

Sciter (TIScript + H-SMILE core) — 781ms
Firefox (3.5, Gecko + Spidermonkey?) — from 1450ms to 2200ms
Google Chrome(2.0, WebKit + V8) — 1210ms
Opera (9.64) — 2141ms

Т.е. JIT в общем случае может тебе 10-20% на реальных задачах дать.
Все остальное — это эффектвность DOM и layout методов. Тут как ты видишь в разы выигрыш получается.
А вот эффективность DOM это уже вопрос к комитету и процедурам утверждения стандартов.
Т.е. эти все мегабайты дистрибуции и excessive memory consumption (caching) в попытках хоть как-то заставить это все двигаться и есть та цена которая платится за процедуру развития данных технологий.

Вот и считай что тебе дешевле. Какие-то фичи из jQuery или размеры дистрибуции.

CS>>WebOS вполне себе рабочая лошадь. Или ты про google OS? А чем кстати Android не подходит? Тоже вполне себе ОС.

A>Я про Google OS. Android — это скорее из их плана по захвату вселенной КПК-смартфонов.

Ну вот netbook dual W7/Android

http://www.engadget.com/2009/10/14/acer-aspire-one-d250-android-netbook-gets-fondled-and-photograph/
http://www.blogcdn.com/www.engadget.com/media/2009/10/091014-d250withandroid-03.jpg

Т.е. как бы считается что Android это как бы нечто типа W7. Google OS и есть Android как я понимаю.

Здравствуйте, MasterZiv, Вы писали:

MZ>В каком смысле "наследие" ? Ты поясни, а то будут думать, что они
MZ>код из MFC взяли.
Архитектура фреймворка, RTTI, некоторые классы и функции довольно схожи. Да и вообще, если почитать историю wxWidgets, то можно узнать, что изначально это была кроссплатформенная надстройка над MFC и XView.

Здравствуйте, astral_marine, Вы писали:

ТКС>>Насколько я знаю, WebKit в wx встраивается исключительно под макосью.
_>WebKit под Mac OS X встраиватся как родной, для остальных систем есть wxWebKit

Он вообще под виндой-то собирается, этот wxWebKit?

ТКС>>Ну а IE как бы и даром не надь, и за деньги не надь.
_>Ну не надо говорить за всех. IE позволяет иметь доступ к веб системам, которые заточены под него.

Мы все еще написание GUI обсуждаем, или уже на легаси веб системы перешли?

_>К тому же его не надо устанавливать — а это большой плюс для создания легких приложений или приложений из одного файла.

Насколько я понимаю, уже надо. Хотя может и ошибаюсь, седьмую винду пока не ставил.

Здравствуйте, A13x, Вы писали:

A>Здравствуйте, Cyberax, Вы писали:

C>>Здравствуйте, A13x, Вы писали:

A>>>Т.е. те, кто сейчас бесплатно используют библиотеку смогут ее и дальше бесплатно использовать, но только ту версию, которая уже есть у них.
A>>>Для перехода на новую версию им нужно принять новую лицензию.
C>>Ага. Что отпугнёт огромное число разработчиков, так как у них не будет возможности бесплатно использовать HTMLayout, пусть даже в бинарном виде.

A>если честно — я не понимаю вас.
A>Ситуация: огромное число разработчиков использует HTMLayout. Очевидно их устраивает использование для коммерческих продуктов, то есть они (или их работодатели) удовлетворены качеством библиотеки для использования в своих проприетарных программах.
A>Почему они не могут заплатить за нее? Ну допустим 300 баксов? Думаю если если их наберется больше 1000 (и мне кажется наберется) это получиться уже 300000 revenue.
A>И так же они могут продолжать ее использовать как и раньше если их софт открыт?

А о чем речь-то, а то я что-то пропустил... Опять про open source? Или про деньги?
1) Open source деньги не приносит в принципе (WebKit например делают люди получающие З/П в Apple).
2) У меня: деньги дают в основном три клиента у которых слово "open source" вызывает какие-то нездоровые эмоции.
3) От этих же трех клиентов идут профессиональные баг репорты. Всем такие репорты желаю.
4) Open source стоит автору дорого. И по времени и по финансам. Open Source нужно кому-то обслуживать. Были переговоры одно время с Cisco — они хотели купить с потрохами и сделать Open Source. Не договорились.
5) См. п.1 еще раз.

Вот такие вот индейские национальные лодки.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Nik_1, Вы писали:

N_>>Здравствуйте, pepsicoca, Вы писали:
P>>>Или я ужа отстал от жизни? Неужели Микрософт за столько лет не написал библиотеки оконных шаблонов типа VCL?
N_>>Есть больменее удобная новая оконная либа, но тока под дотнет

Уменя складывается впечатления, что они умышленно не развивают чистый с++, чтобы пересодить всех на дотнет.

PD>Этому несколько противоречит тот факт. что вышла новая версия MFC с возможностями, которых вроде в дотнете нет (Office Style и т.д.)

А Вы WPF видели? Простите, но догги стайл, ой, то есть Offise Style — это ничто по сравнению с тем, что есть в WPF: поддержка themes, кастомизируемые шаблоны представления для любого контрола, развитой дата биндинг... Даже жаль, что всё это только дот-нетовское, прикрутить поддержку C++ тоже можно было б при желании, но...

Здравствуйте, c-smile, Вы писали:

CS>...
CS>А о чем речь-то, а то я что-то пропустил... Опять про open source? Или про деньги?

на самом деле и то и другое.
Я просто высказал мысль, что, возможно, переход на dual license схему мог бы принести больше денег и полезный feedback от opensource community, как в плане портирования, так и в плане использования и развития.
Под dual license я подразумевал двойное лицезирование — под GPL "для всех" и под Commercial License предполагающей продажу за деньги, тем кто хочет использовать либу в коммерческих целях.

Здравствуйте, c-smile, Вы писали:

CS>...
CS>С точки зрения серьёзного программинга JS в том виде что он есть тоже некие сомнения вызывает.
CS>Вот тут http://www.codeproject.com/KB/recipes/TIScript.aspx я попытался описать то что не хватает JS для того чтобы быть мало мальски production level языком в котором есть что-нубдь to write home about.

Ну с этим уже сложно что то поделать, отчасти еще из-за отвратительной совместимости браузеров в части касающейся реализации js (и не только), может быть следующий стандарт js привнесет качественно новые изменения.

CS>По поводу V8: весь этот бешенный effort нужен в том случае если у тебя нет возможности перенести критические методы
CS>в native code. Например если у тебя нет эффективного native метода getElementBySelector то да, для того чтобы jQuery реально
CS>работала, нужен JIT и все мегабайты кода с этим связанные. Но скрипт он не для того чтобы на нем делать ray tracing или вычислять селекторы.

CS>В качестве примера:

CS>

CS>Here is something close to real:
CS> http://terrainformatica.com/tests/std-table-fixed-10000-rows.htm
CS>This table contains 10`000 rows. First button named Update runs loop
CS>through all rows and does update of cell's text in first column.
CS>Timings on my machine:

CS> Sciter (TIScript + H-SMILE core) — 781ms
CS> Firefox (3.5, Gecko + Spidermonkey?) — from 1450ms to 2200ms
CS> Google Chrome(2.0, WebKit + V8) — 1210ms
CS> Opera (9.64) — 2141ms

CS>Т.е. JIT в общем случае может тебе 10-20% на реальных задачах дать.
CS>Все остальное — это эффектвность DOM и layout методов. Тут как ты видишь в разы выигрыш получается.
CS>А вот эффективность DOM это уже вопрос к комитету и процедурам утверждения стандартов.
CS>Т.е. эти все мегабайты дистрибуции и excessive memory consumption (caching) в попытках хоть как-то заставить это все двигаться и есть та цена которая платится за процедуру развития данных технологий.

CS>Вот и считай что тебе дешевле. Какие-то фичи из jQuery или размеры дистрибуции.

Все зависит от того, как именно писать код.
Мне приходилось реализовывать возможность просмотра очень большого списка из нескольких тысяч элементов.
В моем случае на странице в каждый момент времени было всего несколько десятков элементов, контент подгружался динамически по мере прокрутки/изменения размера/клавиатурной навигации, совершенно незаметно для пользователя.
Причем новые ноды для дерева не создавались, а переиспользывались, т.е. было реализовано что то вроде кэша нодов в коде.
Плюс к тому использовался прием ускоренного обновления нодов, путем кэширования информации о под-элементах, на которые необходимо установить новый контент.
Соответственно скорость работы яваскрипта играла большую роль, операции над DOMом были оптимизированы.
То есть было реализовано что то вроде этого:

// получаем новый нод с "привязанной" операцией обновления
function getNewNode(cache, nodeTemplate) {
    var node;
    if (cache.length > 0) {
        // нет необходимости конструировать новый нод и выполнять запросы к его DOM-у
        node = cache.pop();
    }
    else {
        // клонирование, дорогая операция, в которой единовременно
        // получаем "подэлементы" и функцию их обновляющую
        node = nodeTemplate.cloneNode(true);
        
        var uiSubElem1 = getByClass(trackNode, "class-1");
        var uiSubElem2 = getByClass(trackNode, "class-2");
        var uiSubElem3 = getByClass(trackNode, "class-3");
        //...

        // определяем функцию обновления именно этого нода
        node.updateUI = function(data) {
            uiSubElem1.textContent = data.getFoo1();
            // ..
        }
    }

    return trackNode;
}

соответственно по удалению нода мы его помещаем в cache для дальнейшего повторного использования.
Впоследствии по мере достаточного заполнения кеша имеем очень быструю прокрутку и позиционирование в любое место списка сравнимую с пролистыванием небольших html-only списков.

ТКС>Он вообще под виндой-то собирается, этот wxWebKit?
Конечено! И под Linux и Mac OS X.

ТКС>Мы все еще написание GUI обсуждаем, или уже на легаси веб системы перешли?
Это вы так называете ОС, которая занимает 90% рынка и браузер занимающий 60%? Или может быть веб приложения — это не GUI, а консольные приложения?

ТКС>Насколько я понимаю, уже надо. Хотя может и ошибаюсь, седьмую винду пока не ставил.
Приложение IE и встраиваемый контрол IE — это разные вещи.

Здравствуйте, astral_marine, Вы писали:

ТКС>>Он вообще под виндой-то собирается, этот wxWebKit?
_>Конечено! И под Linux и Mac OS X.

Это лично проверено или сведения из третьих рук?

ТКС>>Мы все еще написание GUI обсуждаем, или уже на легаси веб системы перешли?
_>Это вы так называете ОС, которая занимает 90% рынка и браузер занимающий 60%?

Так я называю веб-приложения, которые работают только в IE

_>Или может быть веб приложения — это не GUI, а консольные приложения?

Позвольте, мы обсуждали такую вполне прозаическую вещь, как GUI Toolkit для применения в C++ приложениях. В этой конкретной области я места для IE не вижу (ибо пробовал лет 10 назад так делать и конкретно затрахался). Ну разве что MS вдруг начнет поставлять с ним сорцы (можно некомпиляемые) и pdb.

ТКС>>Насколько я понимаю, уже надо. Хотя может и ошибаюсь, седьмую винду пока не ставил.
_>Приложение IE и встраиваемый контрол IE — это разные вещи.

Ежу понятно. Я видел в сети скриншоты, по которым было похоже, что сам движек IE из системы вычищается.

>>(Qt эмулирует контролы, а не использует родные)
T>Чего? Эмулируют? Да у них свои контролы, на своей системе сообщений и паинтере.
Согласен

T>Это отлично: возможностей больше. А куцые и неудобные виндовые контролы они уже в печенках сидят.
Но возможностей меньше, Qt развивается сейчас только в сторону мобилок, разных спецефэктов на них, а не конролов для десктоп приложений.

T>Как чего посложнее чем просто дерево нарисовать надо будет типа дерева с колонками, так танцы
T>с бубном и начинаются, знаю, уже танцевали:

В wxWidgets для этого есть wxDataViewCtrl, который делает то же самое, но выглядит при этом как родной

Вообще, если говорить о возможностях, то в wxWidgets на порядок больше продвинутых контролов. wxAUI, wxGrid и wxPropertyGrid аналогов в Qt до сих пор нет.
http://www.rsdn.ru/forum/cpp.applied/3497242.aspx
http://www.rsdn.ru/forum/cpp.applied/3494892.aspx
http://www.rsdn.ru/forum/cpp.applied/3494316.aspx

ТКС>>>Он вообще под виндой-то собирается, этот wxWebKit?
_>>Конечено! И под Linux и Mac OS X.
ТКС>Это лично проверено или сведения из третьих рук?
Да я сам собирал, wxWebKit — это кроспратформенный контрол.

ТКС>Так я называю веб-приложения, которые работают только в IE

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

ТКС>Позвольте, мы обсуждали такую вполне прозаическую вещь, как GUI Toolkit для применения в C++ приложениях. В этой конкретной области я места для IE не вижу (ибо пробовал лет 10 назад так делать и конкретно затрахался). Ну разве что MS вдруг начнет поставлять с ним сорцы (можно некомпиляемые) и pdb.
Я уже указывал варианты его использования в этой ветке.

ТКС>Ежу понятно. Я видел в сети скриншоты, по которым было похоже, что сам движек IE из системы вычищается.
В этих скриншотах выбор браузера делается в IE

Здравствуйте, astral_marine, Вы писали:

ТКС>>>>Он вообще под виндой-то собирается, этот wxWebKit?
_>>>Конечено! И под Linux и Mac OS X.
ТКС>>Это лично проверено или сведения из третьих рук?
_>Да я сам собирал, wxWebKit — это кроспратформенный контрол.

Это хорошо, надо попробовать, а то чето народ в форумах пугал что не собирается.

ТКС>>Так я называю веб-приложения, которые работают только в IE

_>Каким браузером пользоватся выбирает пользователь, сдесь же идет речь о встраиваемой версии браузера в приложение.

Ну и нафига IE встраивать, если есть варианты получше?

ТКС>>Позвольте, мы обсуждали такую вполне прозаическую вещь, как GUI Toolkit для применения в C++ приложениях. В этой конкретной области я места для IE не вижу (ибо пробовал лет 10 назад так делать и конкретно затрахался). Ну разве что MS вдруг начнет поставлять с ним сорцы (можно некомпиляемые) и pdb.
_>Я уже указывал варианты его использования в этой ветке.

Значит еще раз повторить не затруднит? А то я ничего разумного на эту тему не заметил.

ТКС>>Ежу понятно. Я видел в сети скриншоты, по которым было похоже, что сам движек IE из системы вычищается.
_>В этих скриншотах выбор браузера делается в IE

Хочешь сказать, тут

каким-то боком умудрились IE заюзать?
Ну и такой QA тоже не исключено что не просто так ляпнут:

Q: My Windows application (WPF, Win Forms, Java, etc.) uses the Web Browser control. Is there any compatibility issue?

A: Everything should work as expected. However, we’ve seen some issues when applications depend directly on a specific browser. In particular, if while using the Web Browser control, you allow the application to open new windows that do not respect the user’s default browser choice, you may see some issues.

Здравствуйте, A13x, Вы писали:

CS>>...
CS>>С точки зрения серьёзного программинга JS в том виде что он есть тоже некие сомнения вызывает.
CS>>Вот тут http://www.codeproject.com/KB/recipes/TIScript.aspx я попытался описать то что не хватает JS для того чтобы быть мало мальски production level языком в котором есть что-нубдь to write home about.

A>Ну с этим уже сложно что то поделать

Мне — не сложно как сам понимаешь. Любой feature request лишь требует анализа на предмет охвата группы потребностей а не какого-то частного случая.

A>... отчасти еще из-за отвратительной совместимости браузеров в части касающейся реализации js (и не только), может быть следующий стандарт js привнесет качественно новые изменения.

Как разработчика своего собственного приложения тебя эти проблемы не должны волновать вообще.

CS>>По поводу V8: весь этот бешенный effort нужен в том случае если у тебя нет возможности перенести критические методы
CS>>в native code. Например если у тебя нет эффективного native метода getElementBySelector то да, для того чтобы jQuery реально
CS>>работала, нужен JIT и все мегабайты кода с этим связанные. Но скрипт он не для того чтобы на нем делать ray tracing или вычислять селекторы.

CS>>В качестве примера:

CS>>

CS>>Here is something close to real:
CS>> http://terrainformatica.com/tests/std-table-fixed-10000-rows.htm
CS>>This table contains 10`000 rows. First button named Update runs loop
CS>>through all rows and does update of cell's text in first column.
CS>>Timings on my machine:

CS>> Sciter (TIScript + H-SMILE core) — 781ms
CS>> Firefox (3.5, Gecko + Spidermonkey?) — from 1450ms to 2200ms
CS>> Google Chrome(2.0, WebKit + V8) — 1210ms
CS>> Opera (9.64) — 2141ms

A>Все зависит от того, как именно писать код.
A>Мне приходилось реализовывать возможность просмотра очень большого списка из нескольких тысяч элементов.

Да, есть два способа просмотра длинных списков. 1) Загнать весь список в ДОМ и 2) сделать его виртуальным.
У обоих решений есть очевидные достоинства и недостатки.

Хорошо когда у тебя есть обе опции и твой выбор основнан на твоих потребностях.

A>В моем случае на странице в каждый момент времени было всего несколько десятков элементов, контент подгружался динамически по мере прокрутки/изменения размера/клавиатурной навигации, совершенно незаметно для пользователя.
A>Причем новые ноды для дерева не создавались, а переиспользывались, т.е. было реализовано что то вроде кэша нодов в коде.
A>Плюс к тому использовался прием ускоренного обновления нодов, путем кэширования информации о под-элементах, на которые необходимо установить новый контент.

Тут мы с тобой смотрим на проблему с разных позиций. Я борюсь с причинами — ты со следствиями.
Все эти пляски с бубном вокруг cloneNode() выглядят как тривиальный хак и/или попытка обойти чей-то другой баг. Что всегда чревато.
Если cloneNode() *в WebKit* дорогая операция то *WebKit* должен имплементировать кэш у себя внутри.

И я не понимаю что такого термоядерного в этом cloneNode() ...
В Sciter например Element.clone(), new Element() и Element.detach() это просто вызовы dom::element::copy(), new dom::element() и dom::element::release().
Что в них такого волшебного я не понимаю. Да, dom::element::copy() вызывает аллокацию копии дерева ну и что?

Я тут в качестве упражнения сделал в Sciter пример virtual list + kinetic scrolling.
См. в версии 1.0.8.48 (сегодня выложил) вот этот пример:
sciter/sdk/samples/ideas/virtual-list/
и сравни с тем что есть у тебя.

A>Соответственно скорость работы яваскрипта играла большую роль, операции над DOMом были оптимизированы.

Ну я же и говорю: попытка фиксить баги DOM имплементации путем создания JIT для скрипта это
очень интересный способ рвать зубы.
Меня лично удивило бы наличие гинекологического кресла в стоматологическом кабиненте...

Здравствуйте, astral_marine, Вы писали:

>>>(Qt эмулирует контролы, а не использует родные)
T>>Чего? Эмулируют? Да у них свои контролы, на своей системе сообщений и паинтере.
_>Согласен

T>>Это отлично: возможностей больше. А куцые и неудобные виндовые контролы они уже в печенках сидят.
_>Но возможностей меньше, Qt развивается сейчас только в сторону мобилок, разных спецефэктов на них, а не конролов для десктоп приложений.
С чего ты так решил?

T>>Как чего посложнее чем просто дерево нарисовать надо будет типа дерева с колонками, так танцы
T>>с бубном и начинаются, знаю, уже танцевали:
_>В wxWidgets для этого есть wxDataViewCtrl, который делает то же самое, но выглядит при этом как родной
Да уж, фраза "как родной" слезу еще не вышибает?
Какая-то мерялка получается... В Qt 300 лет уже есть нечто подобное wxDataViewCtrl:
QTreeView

_>Вообще, если говорить о возможностях, то в wxWidgets на порядок больше продвинутых контролов. wxAUI, wxGrid и wxPropertyGrid аналогов в Qt до сих пор нет.
ага... это данные из какого века? гридов там хоть попой ешь, хоть с пропертями хоть без.
а о широких возможностях кастомизации и говорить не буду — незачем.

_>>Но возможностей меньше, Qt развивается сейчас только в сторону мобилок, разных спецефэктов на них, а не конролов для десктоп приложений.
T>С чего ты так решил?
Практически все, что делает последнее время Nokia внутри Qt, относится к мобилкам — браузерная поддержка, Touch, движение мобилки в пространстве, 3D.
Кончно, это может быть использовано и в десктопных приложениях, но это лишь говорит о том, что мобильная платформа теперь в Qt первична, десктопная — вторична.

T>Да уж, фраза "как родной" слезу еще не вышибает?
Конструктивная критика уже закончилась?

T>>>Как чего посложнее чем просто дерево нарисовать надо будет типа дерева с колонками, так танцы
T>>>с бубном и начинаются, знаю, уже танцевали:
_>>В wxWidgets для этого есть wxDataViewCtrl, который делает то же самое, но выглядит при этом как родной
T>Какая-то мерялка получается... В Qt 300 лет уже есть нечто подобное wxDataViewCtrl:
Это был мой ответ на то, что в аналог QTreeView — wxDataViewCtrl, я не отрицал наличие QTreeView, просьба повнимательней читать форум.
Неужели 300 лет?

_>>Вообще, если говорить о возможностях, то в wxWidgets на порядок больше продвинутых контролов. wxAUI, wxGrid и wxPropertyGrid аналогов в Qt до сих пор нет.
T>ага... это данные из какого века? гридов там хоть попой ешь, хоть с пропертями хоть без.
T>а о широких возможностях кастомизации и говорить не буду — незачем.
Неужели? А можно получить пруфлинк? Какой контрол является аналогом wxAUI?

_>>Да я сам собирал, wxWebKit — это кроспратформенный контрол.
ТКС>Это хорошо, надо попробовать, а то чето народ в форумах пугал что не собирается.
WebKit собирается под wxWidgets, Qt и GTK+ с использованием GNU окружения (bash, bisin, flex etc), настроить которое не очень просто. Так же очень много зависимостей от внешних библиотек. Видимо были проблемы с настройкой, а не со сборкой самого WebKit.
ТКС>Ну и нафига IE встраивать, если есть варианты получше?

Согласен, wxWebKit и wxWebConnect (Gecko) получше будут, но бывают ситуации, когда нужен именно IE. И только wxWidgets позволяет это сделать, в Qt — это невозможно.

ТКС>Значит еще раз повторить не затруднит? А то я ничего разумного на эту тему не заметил.

Вот, пожалуйста: http://www.rsdn.ru/forum/cpp.applied/3597045.aspx

ТКС>Хочешь сказать, тут [...] каким-то боком умудрились IE заюзать?
ТКС>Ну и такой QA тоже не исключено что не просто так ляпнут:
ТКС>

ТКС>Q: My Windows application (WPF, Win Forms, Java, etc.) uses the Web Browser control. Is there any compatibility issue?
ТКС>A: Everything should work as expected. However, we’ve seen some issues when applications depend directly on a specific browser. In particular, if while using the Web Browser control, you allow the application to open new windows that do not respect the user’s default browser choice, you may see some issues.

Не знал об этом. Но какой именно движок (WebKit, Trident, Gecko, Presto) используется внутри Web Browser control не имеет значения в данном случае. API из Windows позволяет вставлять веб контрол в wxWidgets приложения, а в Qt приложения — нет.

Здравствуйте, astral_marine, Вы писали:

_>>>Да я сам собирал, wxWebKit — это кроспратформенный контрол.
ТКС>>Это хорошо, надо попробовать, а то чето народ в форумах пугал что не собирается.
_>WebKit собирается под wxWidgets, Qt и GTK+ с использованием GNU окружения (bash, bisin, flex etc), настроить которое не очень просто. Так же очень много зависимостей от внешних библиотек. Видимо были проблемы с настройкой, а не со сборкой самого WebKit.
ТКС>>Ну и нафига IE встраивать, если есть варианты получше?

_>Согласен, wxWebKit и wxWebConnect (Gecko) получше будут, но бывают ситуации, когда нужен именно IE. И только wxWidgets позволяет это сделать, в Qt — это невозможно.

Да вроде тоже без проблем: http://doc.trolltech.com/4.2/activeqt-webbrowser.html

ТКС>>Значит еще раз повторить не затруднит? А то я ничего разумного на эту тему не заметил.

_>Вот, пожалуйста: http://www.rsdn.ru/forum/cpp.applied/3597045.aspx

Ну то есть легаси. Когда пара-тройка древних ActiveX завалялась.

ТКС>>Хочешь сказать, тут [...] каким-то боком умудрились IE заюзать?
ТКС>>Ну и такой QA тоже не исключено что не просто так ляпнут:
ТКС>>

ТКС>>Q: My Windows application (WPF, Win Forms, Java, etc.) uses the Web Browser control. Is there any compatibility issue?
ТКС>>A: Everything should work as expected. However, we’ve seen some issues when applications depend directly on a specific browser. In particular, if while using the Web Browser control, you allow the application to open new windows that do not respect the user’s default browser choice, you may see some issues.

_>Не знал об этом. Но какой именно движок (WebKit, Trident, Gecko, Presto) используется внутри Web Browser control не имеет значения в данном случае. API из Windows позволяет вставлять веб контрол в wxWidgets приложения, а в Qt приложения — нет.

Вот все-таки странное это желание — вставлять ActiveX в ситуации, когда можно обойтись чистыми плюсами...

Здравствуйте, astral_marine, Вы писали:

T>>Да уж, фраза "как родной" слезу еще не вышибает?
_>Конструктивная критика уже закончилась?
Не вижу смысла доказывать чета человеку,
который уверен, что wxWidget пуп мироздания.
я выбрал Qt и слава богу что не wx. тчк

Здравствуйте, c-smile, Вы писали:

CS>...Тут мы с тобой смотрим на проблему с разных позиций. Я борюсь с причинами — ты со следствиями.
CS>Все эти пляски с бубном вокруг cloneNode() выглядят как тривиальный хак и/или попытка обойти чей-то другой баг. Что всегда чревато.
CS>Если cloneNode() *в WebKit* дорогая операция то *WebKit* должен имплементировать кэш у себя внутри.

я, наверное, не совсем корректно выразил свою мысль.
В общем идея была в том, чтобы избежать явной пессимизации.
Иными словами подразумевается примерно такой алгоритм — если нужно получить новый нод и в кэше нет похожего,
клонируем шаблонный нод такого же класса (в смысле такого же типа, не css) и после клонирования назначаем метод обновления содержимого этого нода.
В противном случае, если в кэше есть подобный нод, просто извлекаем его оттуда.
Нет смысла просто "забывать" о ноде когда он извлекается из DOM дерева, т.к.:
1) операция сохранения в кэше очевидна и очень проста.
2) операция клонирования и поиска в поддереве явно занимают какое-то время, пусть небольшое но все же. В случае поиска элемента по классу aka getElementsByClassName налицо еще использование дополнительных ресурсов — создание и возвращение массива из элементов.
3) за нодами и результатами выборки необходимо следить сборщику мусора. В схеме с кэшем сборщик мусора просто не может никуда "потерять" экземпляры неиспользованных нодов, расход памяти — даже при очень интенсивном использовании — не будет расти.
4) В случае отказа от виртуализации налицо явное дублирование не отображаемых данных, т.к. в дереве будут присутствовать элементы сопоставленные всем элементам источника данных невзирая на то, что они не видимы и не операбельны пользователем. Уверен, что даже HTMLayout вряд ли быстро отобразит миллион элементов, хотя это явно редкий use case. В случае с виртуализацией это будет работать настолько же быстро как со списком из нескольких дестяков элементов.
5) Источник данных с lazy initialization, идеально подходит к списку с виртуализацией, в противном случае мы сводим преимущества отложенной инициализации на нет.

	От:	pepsicoca
	Дата:	05.11.09 10:37
	Оценка:	-1

От:	cencio	http://ua-coder.blogspot.com
Дата:	05.11.09 11:02
Оценка:

	От:	Nik_1
	Дата:	05.11.09 11:17
	Оценка:

	От:	pepsicoca
	Дата:	05.11.09 13:05
	Оценка:

	От:	pepsicoca
	Дата:	05.11.09 13:06
	Оценка:

	От:	Mazay
	Дата:	05.11.09 15:40
	Оценка:	8 (1) +2 -1

	От:	Cyberax
	Дата:	07.11.09 15:53
	Оценка:	58 (2) +2

	От:	Тот кто сидит в пруду
	Дата:	07.11.09 21:38
	Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	08.11.09 22:54
Оценка:

	От:	MasterZiv
	Дата:	06.11.09 10:15
	Оценка:

	От:	MasterZiv
	Дата:	06.11.09 17:53
	Оценка:

	От:	A13x
	Дата:	06.11.09 18:30
	Оценка:

	От:	Sharpeye
	Дата:	06.11.09 20:11
	Оценка: