Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, A13x, Вы писали:
A>>Т.е. те, кто сейчас бесплатно используют библиотеку смогут ее и дальше бесплатно использовать, но только ту версию, которая уже есть у них. A>>Для перехода на новую версию им нужно принять новую лицензию. C>Ага. Что отпугнёт огромное число разработчиков, так как у них не будет возможности бесплатно использовать HTMLayout, пусть даже в бинарном виде.
если честно — я не понимаю вас.
Ситуация: огромное число разработчиков использует HTMLayout. Очевидно их устраивает использование для коммерческих продуктов, то есть они (или их работодатели) удовлетворены качеством библиотеки для использования в своих проприетарных программах.
Почему они не могут заплатить за нее? Ну допустим 300 баксов? Думаю если если их наберется больше 1000 (и мне кажется наберется) это получиться уже 300000 revenue.
И так же они могут продолжать ее использовать как и раньше если их софт открыт?
и еще: 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 или вычислять селекторы.
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 — это скорее из их плана по захвату вселенной КПК-смартфонов.
Здравствуйте, MasterZiv, Вы писали:
MZ>В каком смысле "наследие" ? Ты поясни, а то будут думать, что они MZ>код из MFC взяли.
Архитектура фреймворка, RTTI, некоторые классы и функции довольно схожи. Да и вообще, если почитать историю wxWidgets, то можно узнать, что изначально это была кроссплатформенная надстройка над MFC и XView.
Здравствуйте, astral_marine, Вы писали:
ТКС>>Насколько я знаю, WebKit в wx встраивается исключительно под макосью. _>WebKit под Mac OS X встраиватся как родной, для остальных систем есть wxWebKit
Он вообще под виндой-то собирается, этот wxWebKit?
ТКС>>Ну а IE как бы и даром не надь, и за деньги не надь. _>Ну не надо говорить за всех. IE позволяет иметь доступ к веб системам, которые заточены под него.
Мы все еще написание GUI обсуждаем, или уже на легаси веб системы перешли?
_>К тому же его не надо устанавливать — а это большой плюс для создания легких приложений или приложений из одного файла.
Насколько я понимаю, уже надо. Хотя может и ошибаюсь, седьмую винду пока не ставил.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, 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 еще раз.
Вот такие вот индейские национальные лодки.
Re[5]: На чем теперь GUI писать положено?
От:
Аноним
Дата:
11.11.09 08:37
Оценка:
Здравствуйте, 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 из системы вычищается.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
>>(Qt эмулирует контролы, а не использует родные) T>Чего? Эмулируют? Да у них свои контролы, на своей системе сообщений и паинтере.
Согласен
T>Это отлично: возможностей больше. А куцые и неудобные виндовые контролы они уже в печенках сидят.
Но возможностей меньше, Qt развивается сейчас только в сторону мобилок, разных спецефэктов на них, а не конролов для десктоп приложений.
T>Как чего посложнее чем просто дерево нарисовать надо будет типа дерева с колонками, так танцы T>с бубном и начинаются, знаю, уже танцевали:
В wxWidgets для этого есть wxDataViewCtrl, который делает то же самое, но выглядит при этом как родной
Вообще, если говорить о возможностях, то в wxWidgets на порядок больше продвинутых контролов. wxAUI, wxGrid и wxPropertyGrid аналогов в Qt до сих пор нет. http://www.rsdn.ru/forum/cpp.applied/3497242.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.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, pepsicoca, Вы писали:
P>Долгое время довольно успешно для разработки под Win использовал BCB60 и его VCL. Из-за разных причин возникла необходимость перейти на MSVC. Подскажите, какую С++ библиотеку для MSVC сейчас принято использовать для программирования GUI? Или же народ пишет GUI на C# и VB, а логику прикручивает на С++? Не хотелось бы изучать новый язык для написания GUI, хотелось бы обойтись С++.
Когда мне нужно на C++ под Windows сделать оконное GUI, я беру WTL.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, 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 для скрипта это
очень интересный способ рвать зубы.
Меня лично удивило бы наличие гинекологического кресла в стоматологическом кабиненте...
Уменя складывается впечатления, что они умышленно не развивают чистый с++, чтобы пересодить всех на дотнет.
каким-то боком умудрились IE заюзать?
