«Прочту потом»: трудная судьба оффлайновой коллекции интернет-страничек

Есть виды софта, без которого одни люди жить не могут, а другие даже не представляют, что такое существует и кому-то вообще нужно. Для меня долгие годы такой программой был Macropool WebResearch, позволявший сохранять, читать и организовывать интернет-страницы в некое подобие оффлайновой библиотеки. Уверен, многие из читателей прекрасно обходятся коллекцией ссылок или комбинацией браузера и папки с набором сохранённых документов. Мне же хотелось бы иметь возможность хотя бы отмечать документы как "прочитанные" или "избранные", быстро переходить от одного текста к другому и не зависеть от доступности интернета или конкретного сайта. Бывает, что читать есть время ровно тогда, когда интернета нет (в дороге, например), да и ссылки, к сожалению, нередко оказываются недолговечными.

Видимо, примерно на таких людей и рассчитывали авторы WebResearch. Эта программа была нашпигована самыми разнообразными функциями: каталогизация по разделам и по тегам, редактирование заметок, всевозможные виды экспорта/импорта и так далее. Однако примерно к 2013 году проект перестал обновляться, а затем прекратил существование и сайт разработчика. Ещё несколько лет мне удавалось кататься на этой лошадке, но сначала отвалились браузерные плагины (доступные только для тогдашних версий IE и FireFox), а затем и современные сайты перестали нормально отображаться в просмотрщике на основе старого IE-движка.

Главное окно WebResearch, PC Week/RE №17 (575)

Дорога разочарований

Как только стало ясно, что замены не избежать, я в фоновом режиме взялся за поиск приличного аналога. Мне казалось, особых сложностей здесь не будет, поскольку желания мои крайне скромны. Я был готов обойтись лишь малым подмножеством средств WebResearch, включающим в себя:

• сохранение HTML страницы из браузера с помощью расширения;
• хотя бы минимальные средства каталогизации (переименование, организация каталогов, метки);
• (желательно) поддержка PDF документов;
• любой сносный способ синхронизации коллекции с другими устройствами.

К моему удивлению, ничего похожего мне найти так и не удалось, хотя я честно излазил интернет вдоль и поперёк и внимательно изучил с десяток подходящих по аннотации программ (за исключением Evernote, где похожая по описанию функциональность доступна только по подписке). На сегодняшний день хоть как-то удовлетворяют моим пожеланиям разве что проекты TagSpaces и myBase. Их изучение, вообще говоря, представляет определённый культурологический интерес.

TagSpaces — это такой вот "стильный-модный-молодёжный" органайзер на Electron с красивым сайтом, адаптивной вёрсткой и, конечно, тёмной темой, куда ж без неё. При этом злосчастное оглавление коллекции c модными закруглёнными значками занимает половину экрана, вмещая при этом штук двадцать элементов максимум, а базовые штуки вроде поддержки горячих клавиш или рендеринга просматриваемого документа пишутся по остаточному принципу. В итоге документы отображаются криво, а работа с коллекцией превращается в скучный и трудоёмкий комплекс упражнений с мышью.

Его антипод myBase родом из конца девяностых: здесь помимо чисто функционального интерфейса мы имеем крайне богатый набор настроек и функций. Однако в качестве окна просмотра здесь выступает всё тот же браузер на основе старого IE (что уже делает чтение затруднительным), а все документы хранятся в монолитной базе данных. Если её положить в папку Dropbox, например (других способов синхронизации с другими устройствами всё равно нет), то при малейшем изменении коллекции приходится дожидаться закачивания на сервер сотен мегабайт информации.

Поворотный момент

Вероятно, дальнейшее содержание заметки читателю представляется очевидным: сейчас нам предложат собственный велосипед, который, конечно, окажется на голову выше любого существующего аналога. Как бы да, но не совсем. Я действительно не выдержал мытарств с myBase и TagSpaces и набросал собственный менеджер документов, ссылку на который приведу ближе к концу. Однако этот мелкий проект для личных нужд сам по себе не заслуживал бы отдельной статьи; я пишу в большей степени потому, что мне показалось интересным поделиться опытом, полученным в процессе работы, и целым рядом неприятных сюрпризов, на которые я никак не рассчитывал.

Цели и задачи

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

Формат данных и сохранение страниц

В каком виде хранить веб-страницы на диске? С учётом ранее сформулированных требований мне казалось, что выбор невелик: либо формат сохранения "веб-страница полностью", то есть основной HTML файл и папка со связанными ресурсами, либо формат MHTML. Первый вариант мне сразу показался менее предпочтительным: невелика радость иметь на диске помойку из кучи файлов, из которых понадобится извлекать значимые документы, фильтровать лишнее при поиске и следить за целостностью при копировании. Когда я пытался работать с TagSpaces, мне пришлось пересохранить все свои документы так, чтобы имя папки с ресурсами начиналось с точки: тогда система распознавала их как "скрытые" и не отображала.

Эта проблема скрыта из виду в myBase, поскольку всё хранится в базе данных, но в моём случае принцип простоты взял верх: очень хотелось хранить всё в виде обычных файлов на диске, чтобы не пришлось заниматься реализацией рутинных операций вроде копирования, переименования, удаления и синхронизации.

Формат MHTML переживает не лучшие свои времена. Простой способ сохранять MHTML был выброшен из Chrome этим летом, и я вот даже не знаю, в чём теперь предполагается хранить страницы? Понятно, что возможность пока что никуда не делась, есть сторонние расширения, но в целом это какой-то нехороший признак. Кроме того, сохранение в формате MHTML не поддерживается в Chromium Embedded Framework, что тоже не прибавляет оптимизма.

Параллельно я стал искать простой способ сохранения страниц из браузера в указанную папку. В итоге обе проблемы удалось разрешить малой кровью: я наткнулся на замечательный проект SingleFile, умеющий сохранять содержимое веб-страницы в отдельном независимом HTML-файле. Делается это путём преобразования всех связанных ресурсов в формат base64 и внедрения непосредственно в HTML. Конечно, при этом размер файла растёт, да и содержимое выглядит несколько замусоренным, но в целом подход мне показался надёжным и простым, и я остановился на нём.

SingleFile поставляется как в виде браузерного расширения, так и в виде приложения командной строки. Сейчас я просто пользуюсь расширением: это достаточно удобно, если не считать того, что надо вручную выбирать целевую папку для сохранения. В будущем, вероятно, постараюсь доработать приложение, чтобы упростить этот процесс. Для вызова стороннего приложения из Chrome можно использовать расширение External Application Button — это ещё одно моё полезное открытие. Кстати, приложение уже принесло пользу: с его помощью я сконвертировал коллекцию папок и файлов из TagSpaces в набор самостоятельных HTML-документов.

Хлопоты с GUI и браузером

Мне показалось, что для всевозможных простых операций с файлами и строками хорошо подходит Python, а поскольку в одном из моих рабочих проектов используется wxWidgets, выбор wxPython в качестве основного фреймворка выглядел логичным.

Далее, насмотревшись на косяки с отображением страниц в других программах, я сделал для себя вывод, что единственный надёжный способ справиться с ними — это внедрить в программу визуализатор на основе современного браузера, то есть Chrome или Firefox.

Должен признаться, что в последний раз мне приходилось заниматься чем-либо подобным лет 15 назад, и я не ожидал никаких подвохов. Оказалось, что "просто шлёпнуть браузер на форму" нельзя: как-то вот человечество не сумело надёжно и универсально справиться с этой задачей. Какой-нибудь listbox или кнопку на форму можно поместить в любом GUI-фреймворке, да ещё и сгенерировать кроссплатформенный код, и мне казалось, что в 2019 году отображение HTML тоже должно было быть повсеместно решённой проблемой.

Оказалось, что в wxWidgets, например, стандартный компонент "браузер" является кроссплатформенной обёрткой над системно-зависимым "браузером", который в случае Windows, например, означает Internet Explorer 7, причём ситуация в Windows Forms ничуть не лучше, и версии свежее IE9 доступны только при помощи нетривиальных манипуляций с реестром. Как видите, не я один занимался последние 15 лет другими делами — здесь тоже с места ничего не сдвинулось.

Дальше передо мной стоял выбор: менять фреймворк или искать альтернативный компонент для браузера. Поколебавшись, я решил попробовать сначала второй путь и достаточно быстро наткнулся на проект CEF Python: Python bindings for Chromium Embedded Framework, предназначенный ровно для задачи встраивания Chromium в приложения на Python.

Оцените ситуацию: Python является одним из самых популярных языков программирования в мире, Chrome — по сути монополист на рынке браузеров. При этом CEF Python фактически поддерживается энергией одного парня, сил и здоровья ему. Неужели это больше никому не нужно?..

Впрочем, мне CEF Python в итоге не помог: хотя даже базовый пример интеграции с wxWidgets из репозитория проекта откровенно глючит, я попробовал повозиться с ним подольше, но так и не смог решить все возникающие проблемы. Даже не буду углубляться в тему, вряд ли она того заслуживает.

Я изучил подробнее компоненты на основе Chromium Embedded Framework и в итоге решил попробовать версию для C#. Поскольку работаю я почти всё время с Windows, перспектива отказаться от кроссплатформенности меня, в общем, не особенно смущала.

После некоторой неизбежной возни на старте дело пошло гораздо быстрее: связка CefSharp и Windows Forms оказалась выигрышной, и мне удалось без особых проблем решить большинство поставленных технических задач.

О неиспробованном

В приложение на C# можно попробовать внедрить и FireFox, используя компонент Geckofx, но я про него ничего сказать не могу. Стандартный браузерный компонент фреймворка Qt под названием QWebEngineView основан на Chromium, так что, вероятно, будет работать не хуже CefSharp.

У любителей Qt может возникнуть соблазн откомментировать: мол, брал бы Qt, не имел бы проблем. Возможно, что так оно и есть, но и wxWidgets можно считать если не первой, то второй опцией при выборе GUI фреймворка для приложений на Python или C++. И по моему скромному мнению уж такая вещь как браузер должна встраиваться в любой более-менее развитый GUI фреймворк без плясок с бубном.

WebLibrary

Вернёмся, однако, к моему приложению с рабочим названием WebLibrary. На сегодняшний день выглядит оно (барабанная дробь) вот так:

Помимо чистого и лаконичного интерфейса здесь реализованы лишь самые наибазовые функции:

• Отображение любого указанного каталога в системе как библиотеки документов.
• Просмотр документов в окне браузера. Навигация по списку обычным образом (клавиши курсора, PgUp, PgDn, Home, End), пролистывание в браузере клавишами Space и Shift+Space.
• Переименование документов.
• Пометка документов как прочитанных или избранных с помощью горячих клавиш.
• Сортировка документов по любому полю.
• Обновление окна приложения при любых изменениях в библиотечной папке.
• Сохранение настроек окна при выходе.

Это всё может показаться тривиальной функциональностью, но вот, скажем, сохранение размеров колонок в TagSpaces всё ещё не поддерживается — видимо, у авторов другие приоритеты.

Статус (прочитано/избранное) попросту хранится в имени файла (прочитанный файл doc.html переименовывается в doc{R,S}.html). Синхронизация как таковая не реализована, но я попросту держу библиотеку в Dropbox — в конце концов, это всего лишь папка с файлами.

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

Выводы

Самые разные. Как я сказал с самого начала, удивительно, насколько инструментарий одного человека может отличаться от инструментария другого. Для меня пользоваться средством вроде WebResearch естественно, и я ощущал почти физический дискомфорт от его отсутствия. При этом, судя по всему, единомышленников у меня немного, иначе бы проблем с поиском аналогов не возникло бы. С другой стороны, аналогичные случаи происходят и с куда более меинстримным софтом: например, Microsoft не собирается обновлять десктопную версию OneNote, так что я вынужден пользоваться версией 2016 года, и рано или поздно придётся с неё тоже куда-то переезжать.

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

Оказалось, что реальность куда менее благожелательна, и нарваться на проблему можно просто на ровном месте. Скажем, есть у меня два splitter-а, с помощью которых можно растянуть окно браузера. Так вот, восстановить их позиции после загрузки в wxWidgets крайне непросто, поскольку система выставляет их в позиции по умолчанию практически после всех доступных мне событий, и приходится заниматься всяческим хакерством, чтобы добиться нужного. Вот кто бы предполагал?

С другой стороны, видно, что в Windows Forms всё заточено под "бизнес-интерфейсы". Практически всё, что требовалось, оказалось доступно из коробки: и сохранение/восстановление настроек приложения, и удобный интерфейс компонентов (скажем, не ожидал, что у компонента TreeView можно запросить полный путь от корня до любого дочернего элемента в виде строки), и нетривиальные средства вроде отслеживателя изменений содержимого папки.

В любом случае время потрачено не зря, а результат можно признать удовлетворительным, так чего же ещё желать от жизни, верно?