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