Как думаете, если задаться целью написать эдакий конвертер sciter<->WorldWide, который бы перегибал "общепринятый" html/css/js в формат Sciter и обратно, как можно было бы для него формализовать техтребования?
Например, список замены тегов для html/css и методов и синтаксиса для js?
Здравствуйте, slay93, Вы писали:
S>Доброго дня, Андрей
S>Как думаете, если задаться целью написать эдакий конвертер sciter<->WorldWide, который бы перегибал "общепринятый" html/css/js в формат Sciter и обратно, как можно было бы для него формализовать техтребования? S>Например, список замены тегов для html/css и методов и синтаксиса для js?
Давай начнем с того что определимся кому это нужно? Т.е. target auditorium — кто это всё будет использовать?
Re[2]: Повернуть Sciter к world передом и vice versa
Здравствуйте, c-smile, Вы писали:
CS>Давай начнем с того что определимся кому это нужно? Т.е. target auditorium — кто это всё будет использовать?
Не думаю, что это действительно критически важный вопрос, но, допустим, это нужно для того, чтобы привлечь "стандартных" web-developers на сторону света Sciter.
На самом деле тут движет скорее интерес, насколько такая задача может сложной и, быть может, увидеть передовые наработки в дизайне html/css/js в окошке sciter'а без ручного допиливания их напильником
Re[3]: Повернуть Sciter к world передом и vice versa
, Андрею это не интересно. На этом, думаю, тему можно закрывать.
Всё верно, по теме именно того топика и возникла идея написать конвертер.
И, признаться, не могу представить ситуации, чтобы автор был не заинтересован в привлечении новых сторонников. Это тем более, что сам авторский продукт не потребует изменений. Только лишь собрать и систематизировать отличия и набросать правила преобразования
Re[3]: Повернуть Sciter к world передом и vice versa
Здравствуйте, slay93, Вы писали:
S>Здравствуйте, c-smile, Вы писали:
CS>>Давай начнем с того что определимся кому это нужно? Т.е. target auditorium — кто это всё будет использовать?
S>Не думаю, что это действительно критически важный вопрос, но, допустим, это нужно для того, чтобы привлечь "стандартных" web-developers на сторону света Sciter.
Это вопрос с которого начинается каждый дизайн. Представляется что он важен, хотя бы для того чтобы определить scope.
В зависимости от ответа задача может иметь принципиально разные решения.
Диапазон может быть от
Добавить в Sciter поддержку <script type="text/javascript"> с полной имплементацией browser DOM.
до
Определить список востребованных JS библиотек и добавить их порты в Sciter SDK.
И то и то возможно.
S>На самом деле тут движет скорее интерес, насколько такая задача может сложной и, быть может, увидеть передовые наработки в дизайне html/css/js в окошке sciter'а без ручного допиливания их напильником
"ручное допиливание их напильником" есть всегда. Даже для разных browser.
Ты не можешь например взять electron приложение и запустить его в browser. Нет в browser нужного runtime.
Обратное тоже верно — типовое web приложение (некий single page application скажем) не будет работать в electron, как минимум в offline mode.
Re[5]: Повернуть Sciter к world передом и vice versa
, Андрею это не интересно. На этом, думаю, тему можно закрывать.
S>Всё верно, по теме именно того топика и возникла идея написать конвертер.
Конвертор JavaScript в SciterScript... Это задача уровня разработки Babel.js т.е. ES6 -> ES5 transpiler.
Проще приделать возможность вызова JS напрямую. Скажем node.js как DLL, а в нем standard browser DOM emulation layer — т.е. все 140 классов стандартного DOM.
Что-то мне говорит что это и будет по размеру electron дистрибуция. А тогда зачем?
S>И, признаться, не могу представить ситуации, чтобы автор был не заинтересован в привлечении новых сторонников.
Новых — да, интересно.
Делать еще один browser просто чтобы был — категорически нет.
Делать browser интересно только в случае очень серьезного заказчика с четким осознанием для чего это надо.
Re[6]: Повернуть Sciter к world передом и vice versa
Здравствуйте, c-smile, Вы писали:
CS>Проще приделать возможность вызова JS напрямую. Скажем node.js как DLL, а в нем standard browser DOM emulation layer — т.е. все 140 классов стандартного DOM.
CS>Что-то мне говорит что это и будет по размеру electron дистрибуция. А тогда зачем?
Нет, далеко нет. Да и не нужны наверняка все 140. Добрая половина может быть действительно эмуляцией. То есть заглушками или заглушками с минимальным функционалом, чтобы не ломались библиотеки.
S>>И, признаться, не могу представить ситуации, чтобы автор был не заинтересован в привлечении новых сторонников.
CS>Делать еще один browser просто чтобы был — категорически нет.
Еще один браузер, пожалуй, не нужен. Разве что какой специализированный, например, встраиваемый.
А вот облегченный Electron — то есть платформа для десктоп приложений, построенных на веб технологиях — нужен.
Re[4]: Повернуть Sciter к world передом и vice versa
Здравствуйте, c-smile, Вы писали:
CS>Ты не можешь например взять electron приложение и запустить его в browser. Нет в browser нужного runtime. CS>Обратное тоже верно — типовое web приложение (некий single page application скажем) не будет работать в electron, как минимум в offline mode.
Что им мешает? В CEF — такое работает без проблем. Electron насколько я понимаю наследуется от того же самого chromium content layer. Чего-то не реализовали? В CEF в скором времени/уже есть даже chrome extensions (но не все API будут доступны, т.к. цели повторить chrome как он есть — нет).
Re[5]: Повернуть Sciter к world передом и vice versa
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, c-smile, Вы писали:
CS>>Ты не можешь например взять electron приложение и запустить его в browser. Нет в browser нужного runtime. CS>>Обратное тоже верно — типовое web приложение (некий single page application скажем) не будет работать в electron, как минимум в offline mode. F> Что им мешает? В CEF — такое работает без проблем. Electron насколько я понимаю наследуется от того же самого chromium content layer. Чего-то не реализовали? В CEF в скором времени/уже есть даже chrome extensions (но не все API будут доступны, т.к. цели повторить chrome как он есть — нет).
Это если application permanently web connected. Что в случае electron смысла не имеет особо — нужно приделывать FileSystem или еше какой storage.
Вообще Web App это именно что-то работающее в browser. Electron это другая модель.
Все что можно переиспользовать в electron для desktop это библиотеки типа d3.js и что-то еще.
Вот список таких библиотек и интересен на самом деле.
Как насчет такого списка? Т.е. о чем речь на самом деле?
Re[7]: Повернуть Sciter к world передом и vice versa
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, c-smile, Вы писали:
CS>>Проще приделать возможность вызова JS напрямую. Скажем node.js как DLL, а в нем standard browser DOM emulation layer — т.е. все 140 классов стандартного DOM.
CS>>Что-то мне говорит что это и будет по размеру electron дистрибуция. А тогда зачем?
W>Нет, далеко нет. Да и не нужны наверняка все 140. Добрая половина может быть действительно эмуляцией. То есть заглушками или заглушками с минимальным функционалом, чтобы не ломались библиотеки.
Что значит не нужны? Ну скажем HTMLDivElement нужен или нет? https://developer.mozilla.org/en/docs/Web/API/HTMLDivElement ?
Там каждый tag это свой класс.
S>>>И, признаться, не могу представить ситуации, чтобы автор был не заинтересован в привлечении новых сторонников.
CS>>Делать еще один browser просто чтобы был — категорически нет.
W>Еще один браузер, пожалуй, не нужен. Разве что какой специализированный, например, встраиваемый. W>А вот облегченный Electron — то есть платформа для десктоп приложений, построенных на веб технологиях — нужен.
Что можно выкинуть из electron чтобы его облегчить?
Re[6]: Повернуть Sciter к world передом и vice versa
Здравствуйте, c-smile, Вы писали:
CS>Это если application permanently web connected. Что в случае electron смысла не имеет особо — нужно приделывать FileSystem или еше какой storage.
Вот я и спрашиваю — как они умудрились открутить вещи которые в CC расположены более-менее штатно.
CS>Все что можно переиспользовать в electron для desktop это библиотеки типа d3.js и что-то еще.
Я всё таки х.з. В CEF я легко запущу SPA которые мспользую appcache и оно будет работать как в браузере. Понятно, что необходимость отличного от браузера клиента должна быть чем-то мотивирована.
CS>Как насчет такого списка? Т.е. о чем речь на самом деле?
Это не ко мне. Я за электрон спросил. А CEF-ом я прежде всего потребляю настоящий вэб в промышленных количествах. В скайтере на мой взгляд отсутствие классического JS возможно отпугивает, ограничивая в инструментах. Но если бы я делал GUI с нормальным размером бинарника — скайтер более чем хорош для меня. С другрй стороны для JS инструментов тоже нет. Все упоролись в тайпскрипт, но модульную систему не завезли.
Re[8]: Повернуть Sciter к world передом и vice versa
Здравствуйте, c-smile, Вы писали:
W>>Нет, далеко нет. Да и не нужны наверняка все 140. Добрая половина может быть действительно эмуляцией. То есть заглушками или заглушками с минимальным функционалом, чтобы не ломались библиотеки. CS>Что значит не нужны? Ну скажем HTMLDivElement нужен или нет? https://developer.mozilla.org/en/docs/Web/API/HTMLDivElement ? CS>Там каждый tag это свой класс.
Куча всего элементарно, или просто душит объемом (HTML*). А вот если взять основу: setTimeout и setInterval и их ответники clearTimeout и clearInterval — и из спецификации не следует, что они должны использовать одно пространство ID таймеров (следует только что могут), однако во всех современных браузерах clearTimeout и clearInterval это одна и таже функция. Более того — мне встречались реальные сайты которые не используют соответствующие "ответники". Это я к чему... нихрена это не простая работа, сгенерил-сгенерил и готово — так не получится.
Или вот ещё такая шутка — что должен возвращать getBoundingClientRect — в текущих хромах как минимум (вроде и в других) — данные лежат в прототипе, таким образом вернувшийся объект в JSON.stringify подсовывать бесполезно. Имхо, это тоже нигде не обговорено. Важно ли это? Ну в данном случае наверное не очень.
Но чем сложнее API — тем более нюансов есть.
Я вот реализовывал Geolocation API — опять таки поведение из браузеров соответствует спецификации, но совершенно не следует явно что оно должно быть именно таким.
В общем мрак. Но если методично — расковырять можно.
Re[7]: Повернуть Sciter к world передом и vice versa
Здравствуйте, fddima, Вы писали:
CS>>Все что можно переиспользовать в electron для desktop это библиотеки типа d3.js и что-то еще. F> Я всё таки х.з. В CEF я легко запущу SPA которые мспользую appcache и оно будет работать как в браузере. Понятно, что необходимость отличного от браузера клиента должна быть чем-то мотивирована.
То что ты запустишь SPA или любую другую Web страницу в CEF вопросов не вызывает. CEF это полномасштабный web browser минус UI crome code вокруг address bar input element.
Я же утверждаю следующее: для desktop приложения (electron case) тебе нужно "допиливать" свой код. А иначе в чем смысл использовать electorn а не запускать твой код в browser?
F>А CEF-ом я прежде всего потребляю настоящий вэб в промышленных количествах.
А смысл? Почему не потреблять настоящий вэб в его естественной среде обитания (browser). Там, где есть tabs и всё остальное ?
Re[9]: Повернуть Sciter к world передом и vice versa
Здравствуйте, c-smile, Вы писали:
F>> В общем мрак. Но если методично — расковырять можно. CS>Можно, но "Где деньги, Зин?"
Я лишь выражаю с тобой согласие. Убьешь время лично ты в пустую. Другое дело был бы заказчик или очевидный спрос.
Re[8]: Повернуть Sciter к world передом и vice versa
Здравствуйте, c-smile, Вы писали:
CS>То что ты запустишь SPA или любую другую Web страницу в CEF вопросов не вызывает. CEF это полномасштабный web browser минус UI crome code вокруг address bar input element.
Нет-нет. С CEF3 — это обвязка вокруг chromium content layer / он же embedders layer вокруг которого сделаны яндекс/опера браузеры. Этот слой ещё не достаточен доя нормального функционирования всего и вся — но очень близок.
CS>Я же утверждаю следующее: для desktop приложения (electron case) тебе нужно "допиливать" свой код. А иначе в чем смысл использовать electorn а не запускать твой код в browser?
Нативные приплюшки вроде трея, system-wide hotkeys ну и на что фантазии хватит. Например кастомный сетевой слой с шифровкой по ГОСТ.
CS>А смысл? Почему не потреблять настоящий вэб в его естественной среде обитания (browser). Там, где есть tabs и всё остальное ?
CEF обслуживает "табы". Я лично — изменяю JS world до своих нужд. Ранее — кастомный нетворкинг. Короче — не тривиальные вещи. А ну и ещё это же батч процессинг в "безголовом" режиме, но с каптурингом скриншотом и! даже видео. Да. Так что стандартный браузер ничегошеньки не может тут предложить. Более того chrome devtools protocol — тоже — у него всё есть но некоторые события происходят сильно позде чем должны. Короче — смысл есть.
ADD: Более того, я не стесняюсь кастомизировать хром под свои нужды, да и выхода нет. По разному бывает, сейчас упростилось до апа некоторых констант — а до того и вмешательство в код. Я к тому что "private" билды это норма.
