Скажем вот люди пишут систему для прикроватных мониторов в больнице. Для них загружаемый и легко конфигурируемый UI — самое оно.
Или когда весь UI собирается из фрагментов писанных скажем в Норвегии, Индии и Японии, стиль разрабатывают в штатах, а потом на это дело садятся переводчики-локализаторы из Ирландии, то тут уж поневоле задумешься про то как это все делать малой кровью.
И про desktop приложения…
Если скажем пишешь что-то типа опросника для больницы или «морду лица» какой АСУ ТП то весь UI это набор правил типа «клик-здесь-там-раскрыть-по-дороге-подгузить-инфу-с-сервера». Собственно благородным програмированием такой UI automation назвать сложно.
и вообще, JS/jQuery как язык для UI automation это way to go. Можно и на C++ писать UI automation конечно но не сильно комфортно в определенных облястях.
У меня т.н. customer driven разработка. Т.е. заказчики оплачивают. Пока никто не просил под другие платформы. Правда круг моих заказчиков несколько специфический: собственно все главные антивирусы (кроме KAV) и игровые фирмы.
Кому нужен движок для специфической платформы — свистите, сделаем.
Лучше/хуже вопрос относительный и зело субъективный.
Из объективных фактов:
1. Про размер уже сказали выше.
2. Desktop приложения используют другую security model чем browsers для которых safe browsing это главное. Соответсвенно ограничения в их движках. В качестве примера: в <richtext> редакторе (встроенный WYSIWYG HTML редактор) можно вставить картинку из clipboard. В том же webkit такой операции нет как класса.
3. sciter2 использует GPU для рисования, webkit рисует «руками».
4. webkit по рукам и ногам связан стандартами. Я же могу делать то что реально нужно в настоящий момент. В качестве примера фича по имени , print и print-preview в теле документа:
На пока:
You may utilize Sciter Engine Software Product free of charge in any manner you see fit to build commercial or non-commercial applications and components.
Из проблем которые были в то время:
1. D1 менялся радикально с каждым билдом, т.е. каждую неделю. Очень тяжело было shooting moving target.
2. Не ясен был принцип D.dll — т.е. создания компонент на D коде в DLL для non-D consumers. Единственынный способ «компонентизации» в D это компоненты в исходных текстах (т.е. статическая компиляция).
Вообще D хорош для «лохматых» проектов когда разумную политику владения (кто что создает а кто освобождает) трудно описать. Но приходится все хозяйство писать на D. С код (и DLL с plain C интерфейсами) можно ипользовать, но завимодействие с С++ и его new/delete уже известная проблема.
Есть две версии Sciter на настоящий момент Sciter1 — GDI backend (все версии Windows включая Windows CE)
и Sciter2 с Direct2D backend (Vista W7 W8), ссылка например в этой статье www.terrainformatica.com/2012/08/sciter-2-0-1-0-new-inspector-dll/ Обе версии имеют общий API поэтому взаимозаменямые.
Мой Sciter (sciter-x.dll ) делает то же самое только в размере 1.2 Mb.
Т.к. он создавался как встраиваемый движок то нативный код приложения имеет простой и эффективный способ управлять таким UI. HTML/CSS/script в UI desktop приложений имеет смысл особенно когда приложения пишутся для разных locale и и большими командами.
Вот пример приложения в котором весь UI это Sciter, т.е. HTML/CSS/script. Сама функциональность приложения естесвенно нативная:
Да, железо не главное. В девайсе главное софт. Точнее сбалансированность оного и возможностей железа. Старый Palm например выполнял все те же функции что и современные телефоны. Написание письма с него занимало ровно столько же времени что и сейчас. А в нем камень был 16 мгц.
Еще про сбалансирванность насущный пример. Делаем web application для мобилок, т.е. под WebKit и IE.
Для всех OS кроме iOS пришлость отключать CSS анимацию. Ибо FPS ниже плинтуса. Даже на топовых девайсах под Android и на все том же WebKit. Зато по паспорту те девайсы рвут например iPhone4 как Тузик грелку. Но софт в них то железо не тянет как я понимаю.
Больше интересует это moving или non-moving этот GC.
non-moving (например ref-counting) GC удобен при встраивании в C++ но имеет известные проблемы в плане cyclic references и частых аллокаций типа var s = ""; for(...) s = s + "something"
Чем-то похоже на мой tiscript. У меня правда class, namespace и property «настоящие».
И VM с moving garbage collector. Что хорошо например в контексте code inside web page но несколько неудобно во встраиваемом языке. А как в OS сделано, какой принцип memory management используется?
Мне кажется или Yate это некая концептуальная вариация JSONT? Понятно что и то и то делает JSON->template->HTML трансформацию. У вас правда некий нетривиальный входной язык наличествует.
Если задумываться про client side template compilation то интересует объем кода самого компилятора.
И кстати что есть откомпилированная template? В моем KiTE например откомполированная template это array со строковыми литералами и ссылками на функции — эдакий bytecode. А как у вас?
Использование float для целей layout это в общем-то грязный хак и весьма не рекомендуется. Собственно как и других штук типа zoom:1.
Некоторые проблемы Дэйвид Барон описал в своей статье. Со своей стороны хочу отметить что floats очень тяжелы для динамических изменений. При изменении float элемента пересчитывается layout всего BFC (block formatting context), в общем случае это весь документ.
Если уж надо горизонтальное размещение то на выбор: display:inline-block, display:table-cell или display: flexbox со товарищи (если религия проекта позволяет)
Автор в статье привел следющий посыл «200x300 пикселей — 400x600 пикселей — плотность в 4 раза больше».
Т.е. по всей видимости он имел ввиду «плотность на единицу площади». Поэтому и квадрат.
Не знаю откуда вот это «закрепляет за браузером право как привязывать логический пиксель...» и далее взялось.
Про физику с геометрией забывать не надо. Фрагмент экрана в 1/96in (1 пиксель у тебя) с расстояния метр имеет такой же угловой размер как и пиксель 1/192in на расстоянии пол-метра. Т.е. чем ближе экран устройства тем больше плотность пикселей на нем должна быть.
Вот это:
«CSS-пиксели… для точного отображения контента на страницах, вне зависимости от экрана… 200x300 пикселей, а на Retina-экранах тот же блок получит 400x600 пикселей… на Retina-экранах плотность пикселей в 4 раза больше, чем на обычных:», по меньшей мере, безграмотно.
CSS pixel это логический length unit равный 1/96 дюйма. Т.е. по своим свойствам тождественен 1pt (1/72 in), 1cm и пр.
И «в 4 раза больше» есть зело оптимистичная оценка. Retina она разная бывает.
«Обычный» экран имеет пиксели размерами 1/96 дюйма (96 DPI).
Ретина на iPhone и ~ 320 DPI т.е. примерно 11 раз больше пикселей на дюйм;
MacPro 220 DPI — в 5 раз больше;
iPad — 264 DPI — в 7 раз.
Кстати про KiTE. У меня используется базовый mustache синтаксис расширенный if секциями.
Template компилируется в своеобразный bytecode — массив из строк и функций. Получается в 25 раз быстрее чем mustache. Ну и это все в 180 LOC поместилось. Надо бы глянуть во что их движок вылился в результате.
Если уже говорить про JS то как бы в нем это все и так достаточно тривиально делается:
var person = { address: { postalCode:12345 } };
var postalCode = person
&& person.address
&& person.address.postalCode;
var spouse = person
&& person.spouse
&& person.spouse.firstName
|| "<not married>";
alert(postalCode);
alert(spouse);
Во первых width:auto для разных блоков означает разные вещи.
width:auto для таблицы это нечто близкое к min(100%, max-content).
Для floats это shrink-to-fit. Для простых блоков это нечто третье.
А во вторых смысл ситуации «юзер выставил шрифт поболее и content width стала больше чем 150px.» очевиден и ситуация вельми часто наблюдается.
Особенно когда этот grid будут пытаться втиснуть в трех-пиксельный экран мобильного браузера.
Т.к. grid layout допускает overflow:
«If the ‘min-content’ size of the Grid item’s box is greater than the size of its Cell, it will overflow the bounds of its Cell in a direction determined by its alignment»
то в общем и целом разницы между система гвоздями прибитых position:absolute элементов и те же элементы но в grid нет.
max-content это ширина самой колонки, но никак не элементов в ней. Ширина элементов определяется в CSS свойствами min/max-width, width и box-sizing. Соответсвенно высота min/max-height и height.
Еще раз: Grid Layout разрешает разместить несколько элементов внутри одного placeholder. Скажем мы поместили три таких элемента.
Как сказать «все три этих элемента должны иметь ширину равную ширине этого placholder, и быть расположенными один за одним вертикально занимая всю высоту этого placeholder»?
Скажем вот люди пишут систему для прикроватных мониторов в больнице. Для них загружаемый и легко конфигурируемый UI — самое оно.
Или когда весь UI собирается из фрагментов писанных скажем в Норвегии, Индии и Японии, стиль разрабатывают в штатах, а потом на это дело садятся переводчики-локализаторы из Ирландии, то тут уж поневоле задумешься про то как это все делать малой кровью.
И про desktop приложения…
Если скажем пишешь что-то типа опросника для больницы или «морду лица» какой АСУ ТП то весь UI это набор правил типа «клик-здесь-там-раскрыть-по-дороге-подгузить-инфу-с-сервера». Собственно благородным програмированием такой UI automation назвать сложно.
и вообще, JS/jQuery как язык для UI automation это way to go. Можно и на C++ писать UI automation конечно но не сильно комфортно в определенных облястях.
Кому нужен движок для специфической платформы — свистите, сделаем.
Из объективных фактов:
1. Про размер уже сказали выше.
2. Desktop приложения используют другую security model чем browsers для которых safe browsing это главное. Соответсвенно ограничения в их движках. В качестве примера: в
<richtext>редакторе (встроенный WYSIWYG HTML редактор) можно вставить картинку из clipboard. В том же webkit такой операции нет как класса.3. sciter2 использует GPU для рисования, webkit рисует «руками».
4. webkit по рукам и ногам связан стандартами. Я же могу делать то что реально нужно в настоящий момент. В качестве примера фича по имени , print и print-preview в теле документа:
На пока:
You may utilize Sciter Engine Software Product free of charge in any manner you see fit to build commercial or non-commercial applications and components.
Из проблем которые были в то время:
1. D1 менялся радикально с каждым билдом, т.е. каждую неделю. Очень тяжело было shooting moving target.
2. Не ясен был принцип D.dll — т.е. создания компонент на D коде в DLL для non-D consumers. Единственынный способ «компонентизации» в D это компоненты в исходных текстах (т.е. статическая компиляция).
Вообще D хорош для «лохматых» проектов когда разумную политику владения (кто что создает а кто освобождает) трудно описать. Но приходится все хозяйство писать на D. С код (и DLL с plain C интерфейсами) можно ипользовать, но завимодействие с С++ и его new/delete уже известная проблема.
На пока:
Sciter home: terrainformatica.com/sciter/
Русскоязычный форум про Sciter и HTMLayout: rsdn.ru/forum/htmlayout/
Есть две версии Sciter на настоящий момент Sciter1 — GDI backend (все версии Windows включая Windows CE)
и Sciter2 с Direct2D backend (Vista W7 W8), ссылка например в этой статье www.terrainformatica.com/2012/08/sciter-2-0-1-0-new-inspector-dll/ Обе версии имеют общий API поэтому взаимозаменямые.
Т.к. он создавался как встраиваемый движок то нативный код приложения имеет простой и эффективный способ управлять таким UI. HTML/CSS/script в UI desktop приложений имеет смысл особенно когда приложения пишутся для разных locale и и большими командами.
Вот пример приложения в котором весь UI это Sciter, т.е. HTML/CSS/script. Сама функциональность приложения естесвенно нативная:
www.softpedia.com/progScreenshots/Norton-Internet-Security-Screenshot-8667.html
Еще про сбалансирванность насущный пример. Делаем web application для мобилок, т.е. под WebKit и IE.
Для всех OS кроме iOS пришлость отключать CSS анимацию. Ибо FPS ниже плинтуса. Даже на топовых девайсах под Android и на все том же WebKit. Зато по паспорту те девайсы рвут например iPhone4 как Тузик грелку. Но софт в них то железо не тянет как я понимаю.
non-moving (например ref-counting) GC удобен при встраивании в C++ но имеет известные проблемы в плане cyclic references и частых аллокаций типа
var s = ""; for(...) s = s + "something"И VM с moving garbage collector. Что хорошо например в контексте code inside web page но несколько неудобно во встраиваемом языке. А как в OS сделано, какой принцип memory management используется?
Если задумываться про client side template compilation то интересует объем кода самого компилятора.
И кстати что есть откомпилированная template? В моем KiTE например откомполированная template это array со строковыми литералами и ссылками на функции — эдакий bytecode. А как у вас?
Некоторые проблемы Дэйвид Барон описал в своей статье. Со своей стороны хочу отметить что floats очень тяжелы для динамических изменений. При изменении float элемента пересчитывается layout всего BFC (block formatting context), в общем случае это весь документ.
Если уж надо горизонтальное размещение то на выбор: display:inline-block, display:table-cell или display: flexbox со товарищи (если религия проекта позволяет)
Т.е. по всей видимости он имел ввиду «плотность на единицу площади». Поэтому и квадрат.
Не знаю откуда вот это «закрепляет за браузером право как привязывать логический пиксель...» и далее взялось.
Вот все что есть:
… it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel.
Note that if the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
«CSS-пиксели… для точного отображения контента на страницах, вне зависимости от экрана… 200x300 пикселей, а на Retina-экранах тот же блок получит 400x600 пикселей… на Retina-экранах плотность пикселей в 4 раза больше, чем на обычных:», по меньшей мере, безграмотно.
CSS pixel это логический length unit равный 1/96 дюйма. Т.е. по своим свойствам тождественен 1pt (1/72 in), 1cm и пр.
И «в 4 раза больше» есть зело оптимистичная оценка. Retina она разная бывает.
«Обычный» экран имеет пиксели размерами 1/96 дюйма (96 DPI).
Ретина на iPhone и ~ 320 DPI т.е. примерно 11 раз больше пикселей на дюйм;
MacPro 220 DPI — в 5 раз больше;
iPad — 264 DPI — в 7 раз.
При переводе цифры надо проверять.
Вот я когда-то сравнивал свой KiTE с другими:
jsperf.com/dom-vs-innerhtml-based-templating/99
Кстати про KiTE. У меня используется базовый mustache синтаксис расширенный if секциями.
Template компилируется в своеобразный bytecode — массив из строк и функций. Получается в 25 раз быстрее чем mustache. Ну и это все в 180 LOC поместилось. Надо бы глянуть во что их движок вылился в результате.
width:auto для таблицы это нечто близкое к min(100%, max-content).
Для floats это shrink-to-fit. Для простых блоков это нечто третье.
А во вторых смысл ситуации «юзер выставил шрифт поболее и content width стала больше чем 150px.» очевиден и ситуация вельми часто наблюдается.
Особенно когда этот grid будут пытаться втиснуть в трех-пиксельный экран мобильного браузера.
Т.к. grid layout допускает overflow:
«If the ‘min-content’ size of the Grid item’s box is greater than the size of its Cell, it will overflow the bounds of its Cell in a direction determined by its alignment»
то в общем и целом разницы между система гвоздями прибитых position:absolute элементов и те же элементы но в grid нет.
Еще раз: Grid Layout разрешает разместить несколько элементов внутри одного placeholder. Скажем мы поместили три таких элемента.
Как сказать «все три этих элемента должны иметь ширину равную ширине этого placholder, и быть расположенными один за одним вертикально занимая всю высоту этого placeholder»?