Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Marty, Вы писали:
M>> Для многих мелких утилит WebKit — это второй вариант. Для них Htmlayout — хорошо подходит, но он не кросплатформ, и как я понимаю, пока и не собирается, и это печалит. Думаю, что вариант, когда Htmlayout доступен помимо Виндов для Маков, iPhone'ов, Android'ов, был бы многим интересен. Но в это надо вложить деньги, и/или время, которых у автора Htmlayout нет ;(
I>Вебкит есть и для иос, и для киндла, и для андроида, и для линукса, и для мака и тд и тд и тд. Если нужна кроссплатформенность, то пока что лучше вебкита это никто не умеет делат.
А что вдруг про QT забыли? Есть вроде уже как под всеми ОС, интерфейс рисуется на css + QML опять же.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, c-smile, Вы писали:
CS>>Я знаю живые приложения использующие htmlayout или sciter. Очень вероятно что они есть и на твоей машине (если у тебя стоит какой-нибудь антивирус например). CS>>Но вот как-то не попадалось мне на глаза ничего что на webkit основано. Может кто видел? Мне на самом деле интересно. CS>>А так если кому-то нужно что-то графическое с парой кнопок то htmlayout как бы самое оно. WebKit же ... ну картина "Умерщьвление пернатыхъ посредством стрельбы главным калибром линкора "Императрица Мария"
I>Дадим слово TC : "... и обязательно кросплатформенное..."
I>htmlayout или sciter кроссплатформенные ? Нет. webkit ? Да. Вопрос закрыт
А вы собственно пробовали? Я писал года 3 назад приблуду qt + webkit — весь интерфейс в последнем.
WebGL, HTML5 & CSS3 это конечно очень здорово, но вот взаимодействие между JS и C++ там мягко скажем недружественное. Оно конечно может что и поменялось, да только node-webkit больше подходит для пуска js из exe, но никак для интерфейса приложения на С++.
Ну и если так сильно хочется кросплатформенности — то ведь наверное не только в интерфейсе то?
Здравствуйте, 11molniev, Вы писали:
I>>htmlayout или sciter кроссплатформенные ? Нет. webkit ? Да. Вопрос закрыт
1>А вы собственно пробовали? Я писал года 3 назад приблуду qt + webkit — весь интерфейс в последнем. 1>WebGL, HTML5 & CSS3 это конечно очень здорово, но вот взаимодействие между JS и C++ там мягко скажем недружественное. Оно конечно может что и поменялось, да только node-webkit больше подходит для пуска js из exe, но никак для интерфейса приложения на С++.
Прямо сейчас тем и занят Архитектура приложения естественно меняется, она становится похожей на архитектуру веб приложения.
1>Ну и если так сильно хочется кросплатформенности — то ведь наверное не только в интерфейсе то?
А что, разве я где то сказал что дело только в интерфейсе ?
1>WebGL, HTML5 & CSS3 это конечно очень здорово, но вот взаимодействие между JS и C++ там мягко скажем недружественное. Оно конечно может что и поменялось, да только node-webkit больше подходит для пуска js из exe, но никак для интерфейса приложения на С++.
А Хромиум собирали из исходников? Правда, что там получается 14 гиг файлов при компиляции?
I>Прямо сейчас тем и занят Архитектура приложения естественно меняется, она становится похожей на архитектуру веб приложения.
Как я понимаю в процессе этого увлекательного занятия ты столкнулся с некими проблемами которые
подвигли тебя на предмет специально зайти на http://rsdn.ru/forum/htmlayout/ и проверить данный топик.
Что конкретно тебе не понравилось в связке webkit/node? Действительно интересно.
Здравствуйте, c-smile, Вы писали:
CS>Как я понимаю в процессе этого увлекательного занятия ты столкнулся с некими проблемами которые CS>подвигли тебя на предмет специально зайти на http://rsdn.ru/forum/htmlayout/ и проверить данный топик.
CS>Что конкретно тебе не понравилось в связке webkit/node? Действительно интересно.
С nodewebkit нужно тащить node, хотя он уже есть в nodewebkit, из за того, что он кое чего не пока что не умеет. Как то так. Но это если всё писать на JS, то есть, вообще всё.
Здравствуйте, jed, Вы писали:
1>>WebGL, HTML5 & CSS3 это конечно очень здорово, но вот взаимодействие между JS и C++ там мягко скажем недружественное. Оно конечно может что и поменялось, да только node-webkit больше подходит для пуска js из exe, но никак для интерфейса приложения на С++. jed>А Хромиум собирали из исходников? Правда, что там получается 14 гиг файлов при компиляции?
Скорее ближе к 40 гигам, если Debug и Release.
Здравствуйте, jed, Вы писали:
F>> Скорее ближе к 40 гигам, если Debug и Release. jed>Но с другой стороны, чтобы пользоваться CEF, не обязательно ведь собирать Хромиум из исходников?
Из исходников CEF собирать конечно же необязательно, но тогда прийдётся довольствоваться существующими бинарными сборками. Некоторые делают свои сборки, потому что активно учавствуют в разработке, некоторые вполне довольны существующими сборками. Поэтому обязательно или нет — каждый себе решает сам.
Если собирать CEF самостоятельно — то это приблизительно тоже самое что и собирать хромиум. В принципе с этим разок разобраться (на виндах) — и это уже не проблема, нужно только железо адекватное, что бы это не происходило мучительно долго. На линуксе сборка в разы проще.
И вообще я не понял при чём тут CEF.
jed>>Но с другой стороны, чтобы пользоваться CEF, не обязательно ведь собирать Хромиум из исходников? F> Из исходников CEF собирать конечно же необязательно, но тогда прийдётся довольствоваться существующими бинарными сборками. Некоторые делают свои сборки, потому что активно учавствуют в разработке, некоторые вполне довольны существующими сборками. Поэтому обязательно или нет — каждый себе решает сам.
А нет ли у вас случаем примера/ссылки как под винду с минимальными усилиями собрать helloworld пример использования CEF, желательно CEF3?
В идеале, готовый проект для какой-нибудь вижуал студии, чтоб просто взять и собрать. В смысле, пример использования готовой сборки CEF. Не скачивая с разных мест разные куски, не собирая Хромиум из исходников.
F> И вообще я не понял при чём тут CEF.
Ну, я на подпись в сообщении посмотрел. Вижу вы занимаетесь .NET врапером для CEF.
Похоже CEF — лучшее, что есть, если не заботит размер бинарников и потребление памяти и нужен современные js+html+css для GUI.
Здравствуйте, jed, Вы писали:
jed>А нет ли у вас случаем примера/ссылки как под винду с минимальными усилиями собрать helloworld пример использования CEF, желательно CEF3? jed>В идеале, готовый проект для какой-нибудь вижуал студии, чтоб просто взять и собрать. В смысле, пример использования готовой сборки CEF. Не скачивая с разных мест разные куски, не собирая Хромиум из исходников.
Если речь о C++ — то скачиваешь оригинальный пакет бинарников под виндовс ( http://www.magpcss.net/cef_downloads/index.php?file=cef_binary_3.1453.1255_windows.7z ) — там есть солюшн для cefclient — он посложнее helloworld, но достаточно прост что бы разобраться. С дотнетом в общем-то тоже самое. Ещё вот есть неплохой туториал Chromium Embedded Framework 3 — Bare Bones. Стоит почитать (хоть там и про GTK+ — ну под виндой используются обычные окна, поэтому это не так важно). Собственно говоря стоит запустить cefclient и пощупать его поближе.
F>> И вообще я не понял при чём тут CEF. jed>Ну, я на подпись в сообщении посмотрел. Вижу вы занимаетесь .NET врапером для CEF. jed>Похоже CEF — лучшее, что есть, если не заботит размер бинарников и потребление памяти и нужен современные js+html+css для GUI.
It depends, как говорится. CEF хорош тем, что это минимальный браузер (в плане API), и он готов браузить паблик интернет — это основное его преимущество.
Недостатки тоже есть, — на мой взгляд высокий порог вхождения, — надо понять не только CEF API, надо ещё обязательно проштудировать коммандные ключи Chromium, и всякие документики с chromium.org тоже полезны. Ну и быть готовым хоть в пол глаза пробежаться дебаггером, если вдруг что. При чём не только по коду CEF, но и по коду Chromium. Поэтому — если есть серьёзные намерения на серьёзный продукт, и нет желания/возможности копаться в исходниках не только CEF но и Chromium — то в дальней перспективе, я бы от Chromium-based решения начисто бы отказался.
Почему? Потому что chromium разрабатывается в первую очередь с нацелом на Google Chrome. Всё что не мешает браузить социалки — идёт прямо в топку (ну конечно не так категорично, но суть приблизительно в этом). Поэтому даже если вдруг я например сделаю крутой патч к хрому — вполне может так стать, что он либо будет отвергнут, либо если он будет принят — прийдётся какое-то время мэйнтнить сборку с применением своих патчей самому.
Необходимости в этом обычно нет, тем не менее я знаю несколько пользователей CEF, которые с подобным столкнулись и успешно пропихнули (багфиксы) в хром.
Из ярких примеров, нерешенных проблем — это по сей день отсутсвие поддержки HiDPI из коробки, или старрый иссу по поводу фликания белого фона на черных сайтах, когда issue чуть ли не старше чем сам хром, а дотянут опять таки до наших дней (кстати может быть пофиксили... движ вроде был вокруг).
Третий, на мой взгляд, краеугольный недостаток chromium-based решений — это то что он навязывает вам свою архитектуру. Он спавнит процессы так, как хочет он, он сделан с замахом на сэндбоксинг. Механизм этот можно изменить, но только вместе с изменениями в модуле content (та часть хрома вокруг которой построен CEF, или вот новая опера), и если такое предложить — я думаю начнется такой баттхерт, что лучше не спрашивать.
С другой стороны — у меня очень даже положительные впечатления от CEF. Просто для приложения на 2 кнопки — оно себя никак не оправдает. Приложения навроде Adobe Brackets — это вообще ошибка природы. Хотя для spotify или rdio он вполне оправдан. У меня лично были свои причины его начать использовать. И даже в последствии сделать свой биндинг к нему. Хотя где эта грань между использовать или не использовать — я не знаю.
В принципе-то аналогичные проблемы присущи любым third party библиотекам, в той или иной степени, в зависимости от.
Архитектура приложения естественно меняется, она становится похожей на архитектуру веб приложения.
