Comments 33
А хром, например, нельзя использовать? Или он не запустится на калибри?
Замечу, что портирование Chromium теоретически возможно, но ресурсов для этого у проекта нет — в частности, человеческих.
Зато возможно практически портирование другого браузера, поменьше.
Зато возможно практически портирование другого браузера, поменьше.
Netsurf сейчас дорабатывается.

А когда (если) портируют/выйдет NetSurf для KolibriOS, разработка WebView будет приостановлена?
Вряд ли. Хотя в WebView много архитектурных проблем, NetSurf значительно массивней. Размер бинарника Netsurf раз в 70 больше, и он использует очень много чужеродных для Колибри библиотек — freetype, libjpeg и так далее.
И вообще, разве Chrome/Firefox «убили» разработку текстовых браузеров?
И вообще, разве Chrome/Firefox «убили» разработку текстовых браузеров?
разве Chrome/Firefox «убили» разработку текстовых браузеров?
Если честно, то похоже на то, ибо я не могу вот сейчас навскидку назвать более одного (теперь — двух) текстовых браузеров.
Это lynx/Links и теперь WebView. Да и Links тоже умеет картинки выводить на самом деле.
WebView тоже умеет выводить картинки, но пока не умеет загружать их из сети.
Добавьте к своему списку w3m, netrik, zen, debris, edbrowse. Кстати, lynx, links, elinks, links2 — разные браузеры.
Добавьте к своему списку w3m, netrik, zen, debris, edbrowse. Кстати, lynx, links, elinks, links2 — разные браузеры.
И вообще, разве Chrome/Firefox «убили» разработку текстовых браузеров?А разве нет? Вы тут перечислили целую кучку браузеров, но когда у них что-то новое выходило? w3m — три года назад, netrik — пять, debris — десять, zen прямо на своей старнице пишет «Please note that this project is no longer in development»… Разработка lynx'а/links'а вроде теплится — но тоже едва-едва: на то, чтобы вышла предыдущая минорная версия lynx'а ушло три года, на версию 2.8.8, похоже, лет 10 понадобится. Links, правда держится (последней версии всего полгода!), но он уже и не совсем текстовый.
Также замечу, что возможно создание имплементации Linux ABI и эмуляции окружения POSIX, портирование иксов и запуск хромиума ^_^
короче, возможно всё :)
Конечно, возможно. Я вот этими своими кривыми руками *смотрит на руки* добавлял обработчик int 0x80 в ядро, писал два десятка основных POSIX-функций, и запускал несложные elf-бинарники из Колибри. Аналогичный проект для PE/WinApi позволяет даже запускать TASM.
Кстати, вот тема PELoad, если кому-нибудь интересно.
А как-же JavaScript? Или только HTML разметка?
Можно попросить скриншот Хабра или Википедии для примера?
Wikipedia i.imgur.com/WEKgpGl.png
Habrahabr i.imgur.com/nfz0IZl.png
(извиняюсь, не на тот уровень ответил)
Habrahabr i.imgur.com/nfz0IZl.png
(извиняюсь, не на тот уровень ответил)
А, ведь, весьма неплохо! Даже хорошо, что нет ничего лишнего, только контент!
Заметил, что у вас выводятся машинописные кавычки, а не ёлочки. Это особенности шрифта или проблема с кодировками?
А войти и написать что-нибудь получится?
Интересное мнение.
К сожалению, в downloader можно передавать только адрес, но нельзя передавать заголовки. Плюс IPC было через файл /rd/1/.download (на рамдрайве, размер которого ограничен).
Одно из возможных решений: действительно расширить функционал downloader. Чтобы он понимал заголовки и тип запроса в качестве параметров; чтобы обмен данными вёлся через именнованную общую память.
Другое решение, которое и было использовано: программа downloader была разделена на библиотеку libhttp и интерфейс к ней. API библиотеки прост и понятен, а сам механизм взаимодействия проще, чем в случае с shared memory. Сам downloader стало проще расширять, улучшать и модфицировать.
О преимуществах разных подходов можно спорить вечность. Если бы Колибри была ОС с UNIX-корнями, то, я думаю, предпочтение отдавалось бы первому решению. Однако, Колибри действительно далека от *NIX; можно сказать, что какие-то несколько лет назад она была почти полной противоположностью. До появления в относительно недавнем прошлом shared memory и локальных сокетов взаимодействие между процессами было возможно только через файлы или очень-очень медленную функцию обмена сообщениями через ядро, которая носит гордое имя «IPC». Каналов в Колибри нет до сих пор (что очень мешает переносу консольных POSIX-совместимых приложений). Однако, Колибри интересна, на мой взгляд, именно своей самобытностью. Позволяет иначе взглянуть на «привычные» вещи.
К сожалению, в downloader можно передавать только адрес, но нельзя передавать заголовки. Плюс IPC было через файл /rd/1/.download (на рамдрайве, размер которого ограничен).
Одно из возможных решений: действительно расширить функционал downloader. Чтобы он понимал заголовки и тип запроса в качестве параметров; чтобы обмен данными вёлся через именнованную общую память.
Другое решение, которое и было использовано: программа downloader была разделена на библиотеку libhttp и интерфейс к ней. API библиотеки прост и понятен, а сам механизм взаимодействия проще, чем в случае с shared memory. Сам downloader стало проще расширять, улучшать и модфицировать.
О преимуществах разных подходов можно спорить вечность. Если бы Колибри была ОС с UNIX-корнями, то, я думаю, предпочтение отдавалось бы первому решению. Однако, Колибри действительно далека от *NIX; можно сказать, что какие-то несколько лет назад она была почти полной противоположностью. До появления в относительно недавнем прошлом shared memory и локальных сокетов взаимодействие между процессами было возможно только через файлы или очень-очень медленную функцию обмена сообщениями через ядро, которая носит гордое имя «IPC». Каналов в Колибри нет до сих пор (что очень мешает переносу консольных POSIX-совместимых приложений). Однако, Колибри интересна, на мой взгляд, именно своей самобытностью. Позволяет иначе взглянуть на «привычные» вещи.
Насколько мне известно, есть. Колибри может быть интересным суповым набором, если требуется очень быстрый доступ к «железу» и графика. Порты линуксовых драйверов ATI/AMD и Intel этому способствуют. Приятные «бонусы» — BSD-совместимые sockets, стек USB OHCI/EHCI/UHCI (мышки-клавы-флешки) и звуковая подсистема с поддержкой Intel HDA.
«New Downloader» использует libhttp практически с рождения. И вот почему.
В Колибри за последние два-три года изменилось очень многое. Так, была выброшена на обочину истории сетевая подсистема MenuetOS. Героическими усилиями разработчика hidnplayr в Колибри появилась новая сетевая подсистема, с BSD Sockets и поддержкой одновременной работы нескольких сетевых интерфейсов. Все сетевые приложения превратились в тыкву. Многие были написаны практически «с нуля», включая downloader/libhttp. И жить стало лучше, жить стало веселее.
В Колибри за последние два-три года изменилось очень многое. Так, была выброшена на обочину истории сетевая подсистема MenuetOS. Героическими усилиями разработчика hidnplayr в Колибри появилась новая сетевая подсистема, с BSD Sockets и поддержкой одновременной работы нескольких сетевых интерфейсов. Все сетевые приложения превратились в тыкву. Многие были написаны практически «с нуля», включая downloader/libhttp. И жить стало лучше, жить стало веселее.
Чувствую меня уже не раз поминали дурным словом, за то что проект начинался на C--. Да и честно говоря он не планировался как полноценный браузер. Чисто документацию к системе в html чтоб можно было смотреть.
Там же еще проблема в том, что не строится DOM-дерево, а сразу рисуется, из-за чего полноценный css и js невозможен.
Но надо отдать должное Leency (Кириллу) и всем кто дальше поддерживал этот проект, получилось весьма неплохо
Там же еще проблема в том, что не строится DOM-дерево, а сразу рисуется, из-за чего полноценный css и js невозможен.
Но надо отдать должное Leency (Кириллу) и всем кто дальше поддерживал этот проект, получилось весьма неплохо
Sign up to leave a comment.
WebView или история о том, как в KolibriOS браузер писался