Как стать автором
Обновить

Комментарии 27

Кстати, не такое уж и «ненормальное программирование». В Visual Studio примерно таким же образом сделана авторизация через веб-страницу, замаскированную под диалоговое окно.
Есть настройка для реестра, что бы в конкретном приложении использовать определенную версию движка. Т. е. например, что бы рендерить через edge. Поройтесь, проблемы совместимости снимутся.
насколько мне помнится это когда то работа, но у меня не получилось… поигрался с мета тегами и получил интересную ситуацию — UA возвращал версию IE 7.0, но работали все фишки IE 10/11. В принципе этом меня устроило.

Правда у меня ситуация была другая — мне надо было перенести Cordova приложение на Windows Desktop. Поэтому в приложение был добавлен еще и вебсервер и прилеплен механизм обмена данными. Под виндой работало, а вот под МакОС (использоваля PureBasic) то работало, то нет, то снова работало. Подозреваю, что необходимо было разность приложение, WebView и вебсервер по разным потокам…
> еще и вебсервер и прилеплен механизм обмена данными

а просто адаптировать для HTA на js нельзя было?
Наверное можно было, но это разрушило бы идеологию — один код (Purebasic, html5/js) для всех платформ.

Кстати да! Вспомнил «прилеплен механизм обмена данными» это как раз для встроенного WebControl. Для версии с вебсервером внутри приложения — обмен обычный через http get/post/put
Да, я читал об этом. Но считаю что по возможности лучше обходиться без записей в чужие/системные ключи реестра когда это возможно. Раз тег тоже решает проблему, то реестр можно не трогать. Но ключ реестра поможет при отображении не собственного текста из памяти а какой-то реальной веб-страницы из интернета, на содержимое которой повлиять невозможно.
Пишется воббще-то во вполне предназаченные именно для этого юзерские ветки
https://msdn.microsoft.com/en-us/library/ee330720(v=VS.85).aspx

Более того, безболезненно можно писать права на старте приложения и стирать при выходе. Права выше юзерских не нужны. Никаких системных и тем более чужих ключей при этом не затрагивается.

Настройка есть, не всегда приложению туда дают лазить. Собственно и правильно делают. Одна настройка для всех.

Это не так. Совсем не так.
Под Android куча приложений, использующих веб фреймфорки, странно, что для Windows этот подход совсем не используется
Про кроссплатформенный Atom/Electron где только не писали, на котором сделан Visual Studio Code.
НЛО прилетело и опубликовало эту надпись здесь

WebBrowser компонент — это всегда IE причем зачастую неожиданной версии на машине у пользователя. IE сам по себе боль, а когда нужно под него писать не зная конкретную версию (а зачастую зная что лучшее на что можно надеяться это IE6 — enterprise для медицины или банков напр.) — то боль становится невыносимой.


Даже если мы решаем, что наше приложение это .NET framework 4.0, то разброс версий IE которые будут представлены в системах клиента — это IE8 — IE11 причем на системах с разными способами рендера шрифтов (Win XP — Win 10), разными способами масштабирования.


Когда нам надо было кусок нашего web приложения встроить в rich client на winforms, то повоевав с недельку с WebBrowser компонентом и поняв что доставшийся от контракторов backbone код под него не был заточен и фиг перезаточишь — решили пересесть на движок на базе чего-то другого firefox или chrome. Перепробовав многие из них остановились на CEFSharp. Да возни с его настройкой побольше, чем с WebBrowser control, сборка сложнее, но оно того стоило. Во-первых фиксированая версия браузера, которая не зависит от левой пятки админа в сети клиента. Во-вторых это chromium с родным V8 а значит JavaScript быстрый. В-третьих это WebKit/blink а значит и возможности по рендеренгу HTML повыше. Ну и все радости кастомизатора вроде получения событий и самостоятельная обработка сетевых запросов — в наличии.


Мое мнение на основе горького опыта. WebBrowser Control — если рендерим что-то очень простое или строго для себя (для внутренних нужд компании), если что-то пойдет вовне — лучше использовать другие средства.

На сколько увеличился размер вашего приложения из-за встраивания CEFSharp?

Точных чисел не дам сейчас, но порядок — 100мб.

Много. Я понимаю, что у нас сейчас не принято заботиться о размере дистрибутива, но когда приложение весит 20 мб, страшно не хочется встраивать в него браузер в 100. И мне не очень понятно, почему нету легких браузеров для встраивания.

Сразу несколько тем в одной
1) 100Мб может быть как много так и не много в зависимости от ситуации. Если у вас что-то вроде условнобесплатной утилитки, то пожалуй 100мб это серьезный барьер для пользователей. В нашей ситуации размер приложения был далеко не самым важным фактором.


2) Легких браузеров (встраиваемых или нет) нет, потому что все движки довольно сложные. HTML/CSS сложный язык, а внутри еще и JavaScript, и flash, и воспроизведение кучи всяких медиа форматов, плюс шифрование, плюс ресурсы, плюс XML часто, плюс инструменты разработчика итд итп. Если попробуете все это сами запаковать в меньший объем — убедитесь что это не так-то просто.


Если вам нужен только HTML + CSS рендерер, то есть другие и более легкие варианты. Тот же blink/webkit отдельно бывает под разные языки. Опять же если HTML у вас простой — то WebBrowser control вполне подойдет, если нужен JS — то где-то здесь была ссылка на статью, где автор все отдельно запиливал.


Если же вам нужен просто интерфейс который можно динамически строить на каком-то декларативном языке, так тот же XAML, XUL, QML ну или миллион других опций в зависимости от языка и платформы. HTML/CSS — не лучший вариант (ибо слишком сложный формат и куча не нужного вам).


Ну а серебряной пули, которая при этом еще и маленькая увы нет.

Если же вам нужен просто интерфейс который можно динамически строить на каком-то декларативном языке, так тот же XAML, XUL, QML

Ну для .NET из коробки только XAML. Все остальное с костылями и следовательно заранее неизвестным количеством граблей на которые придется наступить. В этом плане на фоне прочих 'неродных' решений HTML пожалуй будет предсказуемее что ли. А так, теоретически, к примеру при наличии в проекте веб-частей, возможно использование суммарно на одну технологию меньше перекрыло бы 'не лучшесть' этого варианта.
Но в любом случае я согласен что что-либо серьезное пока только на сторонних движках можно делать, ибо всегда чем меньше приложение зависит от внешних факторов тем лучше.
Если попробуете все это сами запаковать в меньший объем — убедитесь что это не так-то просто.

В этом я и не сомневался. Но вот почему бы не позволить делать кастомные сборки только с нужными функциями? Например, я увернен, что флеш мне не нужен и никогда не понадобится. То же самое с инструментами разработчика, воспроизведением медиа и тд.

Так ведь вам никто и не запрещает делать кастомные сборки. Можете отдельно webkit взять, отдельно javascript, итд итп. Только собрать все это вместе и проинтегрировать — это примерно объем работы которым заняты разработчики современной opera или vivaldi. Ну это если вы хотите чтобы у вас в окошке крутились angluar или backbone приложения. А если вы хотите просто на html рисовать морду и всю логику на том же C# обрабатывать, то задача существенно проще.

Есть более удобное решения для подобный приложений — http://sciter.com/ Оно специально заточено под разработку UI + кросплатформенное. Не знаю, есть ли биндинги для C#, но их можно всегда сделать. Я делал HTML-based UI на IE и на Sciter. Последний явно удобнее и приятнее. Плюс он гораздо компактнее всего остального, что доступно на сегодняшний день, меньше того же электрона в десятки раз.
Еще для разработки десктопных приложений на C# с HTML интерфесйом можно использовать .Net Core + Electron. Получается что-то типа локального веб-сайта. В Asp.Net Core встроен хороший веб-сервер — Kestrel, с поддержкой шаблонного двжижка Razor, так что разработка UI идет довольно быстро.

Эта пара фреймворков, конечно, заметно увеличивает размер приложения, добавляя мегабайт 50 к инсталятору. Зато приложение получается кросс-платформенным. Вот один из примеров — CatLight catlght.io
VS2013->New Project->Windows Desktop->WPF Browser Applicaiton?
И какое это имеет отношение к использованию HTML для создания пользовательских интерфейсов?
Самое прямое. Десктоп приложение написаное на C# завoрачивается в html.
Вы либо абсолютно не знаете что такое WPF Browser Applicaiton либо не поняли идею статьи.
WPF Browser Applicaiton не заворачивается в html, такое приложение загружается браузером и запускается в отдельном процессе PresentationHost.exe, просто parent-окном является браузер. На такой «странице» с этим xbap-приложением HTML отсутствует в принципе.
То что вы советуете диаметрально противоположно сути статьи. Суть — рисовать UI десктопного приложения на HTML _вместо_ XAML или WinForms, и встраивать в приложение браузер для его отрисовки. Подчеркну — десктопное приложение, с полными возможностями десктопных приложений и без неободимости использовать к-л сервера. Вы же советуете взять «десктопное» приложение с десктопной технологией UI (xaml ни в какой html при выполнении не трансформируется) и запихнуть его тем самым в браузер, причем непонятно зачем, поскольку никаких преимуществ по сравнению с обычным wpf приложением при использовании в качестве standalone-приложения это не даст, зато на ровном месте получаем кучу ограничений песочницы в которой оно выполняется и которые еще руками отключать придется.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории