LINUX.ORG.RU
ФорумTalks

Браузер встраиваемый в приложение. Шел 2015й год.

 ,


0

2

Сабж. И до сих пор нету стандартного способа встрить браузер по-умолчанию, установленный в системе, в мое приложение. И это при том, что систем без браузеров не существует, а стандарнтое API до сих пор не запилили в браузерах.

В то же время у микрософта своё «стандартное» (в том смысле, что на любой венде работает) API уже 20 лет как в венде, пусть только для IE, но оно работает и удобное. (И не надо тащить за собой 40-60 метров движка, как в случае с geckofx или webkit'ом (Зачем тащить вобще - не ясно, ведь уже есть браузер в системе, нужно только универсальное API).

upd: доходит даже до такого проприетарного маразма: http://www.awesomium.com/

★★★★★

Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от invy

html - определенный формат, который иногда надо показывать именно в своем приложении.

Окей, тогда я бы всё равно рекомендовал использовать родные возможности тулкита типа qt5-webkit. Просто потому что системный браузер может, например, содержать плагины или ещё что-то что не подконтрольно твоему приложению.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

webkit.

Это делает меня зависимым от конкретного движка, который надо таскать за собой. А завтра, допустим, webkit станет неактуальным (как сейчас trident(IE)), то ты автоматом получаешь кучу legacy софта, который надо переписывать с новыми библиотеками и новым движком. Это уже наступание на грабли какое-то получается (15 лет назад тоже все думали, что кроме IE ничего не надо...)

Просто потому что системный браузер может, например, содержать плагины или ещё что-то что не подконтрольно твоему приложению.

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

В идеале я должен попросить у системы дать мне браузер, который умеет требуемые мной фичи (например HTML5, canvas, webgl) и мне должно быть совершенно без разницы, что это будет за браузер...

invy ★★★★★
() автор топика
Последнее исправление: invy (всего исправлений: 3)
Ответ на: комментарий от invy

А завтра, допустим, webkit станет неактуальным

Тут помогла бы эмуляция API в новом движке...

ты автоматом получаешь кучу legacy софта, который надо переписывать с новыми библиотеками и новым движком.

Мне кажется, через 15 лет любой современный софт станет legacy если его постоянно не допиливать.

Вообще, мне кажется невозможно один раз написать софтину и чтобы через 15 лет с ней не было проблем. Так не бывает. За 15 лет индустрия может целиком поменяться. Не факт что там тот же qt выживет, а ты за браузер переживаешь :). Да и я не слышал чтобы столько жили програмные продукты (кроме прошивок в банкоматах).

Короче, вариант «написал и забыл» мне в любом случае кажется утопичным.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Короче, вариант «написал и забыл» мне в любом случае кажется утопичным.

Что, вызов open() на новом ядре не будет работать как на старом?
Всё, что нужно, чтобы не думать о реализациях на годы вперёд - продуманное API и более-менее стабильное ABI, что топикастер и просит
/thread

frame ★★★
()
Ответ на: комментарий от frame

Что, вызов open() на новом ядре не будет работать как на старом?

Если всё что твоя программа делает это дёргает пару простых системных вызовов из POSIX то да, ты можешь расчитывать что оно и дальше будет работать.

продуманное API и более-менее стабильное ABI, что топикастер и просит

Да что уж там, проси сразу продуманные и стабильные программы :)

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Работа с браузером (ивентами в нем и DOM) не намного комплекснее, чем с файловой системой и при том довольно станданртна, потому, не вижу проблем в создании API.

invy ★★★★★
() автор топика
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от true_admin

Мне кажется, через 15 лет любой современный софт станет legacy если его постоянно не допиливать.

Ты даже не представляешь, сколько софт может жить. И исходить из того, что через N лет он будет не нужен - очень плохой подход. Часто, особенно на предприятиях, используется софт, которому уже ОЧЕНЬ много лет, потому что он работает и всех устраивает и потому что «never touch a running system».

invy ★★★★★
() автор топика
Ответ на: комментарий от invy

Есть серьёзные организационные сложности. Тебе нужно убедить в нужности этого Mozilla, Google и Microsoft.

Имхо, значительно проще решить проблему своей прослойкой совместимой с нужными браузерами.

true_admin ★★★★★
()
Ответ на: комментарий от invy

И исходить из того, что через N лет он будет не нужен - очень плохой подход

Я нигде не писал что исхожу из этого. Я говорил что 15 лет без обновлений скорее всего не проживёт.

Часто, особенно на предприятиях, используется софт, которому уже ОЧЕНЬ много лет, потому что он работает и всех устраивает и потому что «never touch a running system».

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

true_admin ★★★★★
()
Ответ на: комментарий от invy

проще и надёжнее таскать с собой кусочек вебкита.

Thero ★★★★★
()
Ответ на: комментарий от invy

в кде всё это было, но линуксоиды плевались на комбайн и вштыки.

Thero ★★★★★
()
Ответ на: комментарий от invy

Так ты и тут не будешь таскать. Под юниксами поставишь пакет общий для всей системы, под виндой тоже есть варианты. Или может быть я проспал те времена, когда приложения под виндой перестали таскать за собой библиотеки рантайма VS?

buddhist ★★★★★
()
Ответ на: комментарий от true_admin

Если всё что твоя программа делает это дёргает пару простых системных вызовов из POSIX то да, ты можешь расчитывать что оно и дальше будет работать.

Что мешает стандартизировать какой-нибудь WebRender API для этих целей?

Да что уж там, проси сразу продуманные и стабильные программы :)

Нужен продуманный интерфейс, а не текущие внутренности, которые могут 100 раз поменяться

frame ★★★
()
Ответ на: комментарий от frame

Что мешает стандартизировать какой-нибудь WebRender API для этих целей?

Как минимум отсутствие человека который бы этим занимался.

Нужен продуманный интерфейс

Я не буду спорить на эту тему. Если тебе кажется что сделать продуманный интерфейс который будет хорошо ложиться на все текущие и будущие браузеры, на все распространённые языки программирования и проживёт эти самые N лет... то ради бога.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Как минимум отсутствие человека который бы этим занимался.

API не нужно постоянно заниматься, его нужно один раз грамотно продумать и забыть (как в случае с системными вызовами)

Если тебе кажется что сделать продуманный интерфейс который будет хорошо ложиться на все текущие и будущие браузеры, на все распространённые языки программирования и проживёт эти самые N лет... то ради бога.

Ну для примера: виндовый COM прекрасно работает 15+ лет - сколько за это время сменилось версий(реализаций) IE?

frame ★★★
()
Ответ на: комментарий от frame

его нужно один раз грамотно продумать и забыть

виндовый COM прекрасно работает 15+ лет

Отличный пример:

COM is the basis for several other Microsoft technologies and frameworks, including OLE, OLE Automation, ActiveX, COM+, DCOM, the Windows shell, DirectX, UMDF and Windows Runtime.

(c) Wikipedia

Как видно, один раз продумать и забыть не вышло, пришлось переизобретать кучу костылей и надстроек. В википедии эта тема относительно раскрыта. В итоге венда тянет всё своё барахло чуть ли не с win3.11 . Каждый раз как только возникают проблемы с предыдущей технологией они тупо делают новую потому что старую трогать нельзя — программы поломаются. По мне так этот подход привёл к тому что венда это адовое болото (моё имхо).

Я, собственно, не хочу это дальше обсуждать. Я хотел дать тебе пищу для ума что эволюция софта это сложный топик и «stable API is not a silver bullet». Больше мне добавить нечего.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Я хотел дать тебе пищу для ума что эволюция софта это сложный топик

Я тебе тоже дам пищу для уму: почему именно АТФ, а не куда более энергоёмкие молекулы? Вопрос, в принципе, риторический =)

frame ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.