Romul81
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Abs62
Цитата:| Но как подумаешь, сколько всего переписывать придётся... |
 А в перспективе придётся переписывать ещё больше.
Важно, также, понимать, для чего это нужно. Определиться с приоритетами, т.ск.
Если посмотреть на ситуацию концептуально, с точки зрения основных задач, возлагаемых на программу, то она их выполняет. Относительно неплохо. Пока.
Всеядность GD является его же проблемой. Форматы ведь очень разные, и заточены на разные цели. Взять, к примеру, логические форматы DSL, XDXF. Да, GD их поддерживает, но это не та поддержка, которая задумывалась их авторами (или существует в Lingvo для первого). Простой поиск по зонам индексирования заставляет пользователей (тех, кто привык к этой фиче) сделать выбор в пользу родной оболочки. Для профессионалов это жизненно необходимый функционал. Из-за него они готовы мириться со всеми остальными причудами этой коммерческой программы.
На другом краю - HTML-ориентированные форматы. Специфика совершенно другая. Здесь уже чувствуется потолок оболочки. Это пока не заметно(?) пользователям, но уже ясно составителям-словаределам. Забегая вперёд скажу, что основная проблема - производительность при большом кол-ве подключенных словарей и необходимость их "допиливания" при создании.
Мы уже несколько лет живём в эпоху бурного развития веб-технологий и HTML5. Вопрос заключается не столько в том, что есть необходимость составлять словари согласно этим стандартам, а в том, что основным источником HTML-словарей является WEB. Который уже далеко впереди, и за которым оболочка не поспевает. Т.е., HTML-код необходимо очень сильно адаптировать (что, к примеру, для современного android уже не нужно делать). И если создатели словарей в формате Mdict ещё чего-то "пилят" (и то не всегда), то в ZIM, к примеру - неадаптированная WEB-разметка/CSS/скрипты. А что у нас с ней происходит в процессе предобработки? Конкретнее с CSS? Изоляция, причём двойная. И по итогу у нас сотни подобных правил:
Код: #gdfrom-87daa39e0aac5a64d01f2c8fca11ecd7 .zimdict .mw-body p {
line-height: inherit;
margin: 0.5em 0;
} |
А при подключенной сотне словарей сколько у нас может быть тегов <p>?... Теперь помножьте это на все правила во всех CSS во всех подключенных словарях. Получается, браузеру нужно отследить миллионы цепочек вплоть до корня DOM для каждого из селекторов. Какие бы там ни были хитрые оптимизации, это всё равно крайне неэффективно.
Да, здесь решается основная задача - изоляция стилей. Но при этом убивается производительность (это не считая предобработки, когда CSS надо распарсить регулярками и экранировать). А ведь надо ещё распарсить и обработать HTML...
Как Вы правильно сказали, это всё, в принципе, преодолимо. Тем более, современные веб-стандарты предлагают целый набор инструментов, которые позволяют изящно решать подобные проблемы. Именно поэтому я и спросил о QtWebEngine, который, как известно, построен на движке Blink.
В принципе, можно и без него, по старинке работая с iframe-ми. Но это палка о двух концах. Во-первых сложно (наверное, поэтому и не прижилось). Я не представляю страницу с сотней-другой iframe-ов. Во вторых в каждый из этих iframe-ов нужно инкапсулировать свой полный DOM, включая дефолтные стили, скрипты и т.д., что выглядит несколько странно, если мы говорим об эффективности.
Возвращаясь к QtWebEngine, а точнее к Blink. Именно в нём реализована такая штука, как web components. Конкретные компоненты Shadow DOM плюс, факультативно HTML imports и HTML Template - это как раз то, что нам нужно. Поддержка именно нативная, тогда как в других браузерах частичная или через полифилл.
В интересующем нас QtWebEngine она тоже, очевидно, имеется (см. секцию Web Components), и именно что в нативном варианте. Что это всё даёт? Вкратце и по-русски можно почитать здесь. Коротко на вики (со ссылками на ресурсы).
В общем, если развиваться в этом направлении, то весь вывод надо кардинально перекраивать.
|
либо с морфом либо без?
