OutWiker 2.1.0.844 unstable с измененным форматом заметок

OutWiker 2.1.0.844 unstable с измененным форматом заметок

Снова привет. Сегодня выложил следующую нестабильную версию OutWiker под номером 2.1.0.844 с большим количеством изменений, которые уже заметны пользователям, а не только тем, кто копается в исходниках программы. С момента прошлой версии я взялся за исправление ошибок, чтобы постепенно доводить программу до стабильной версии, и сделал одну штуку, которую должны оценить те, кто хранит свои заметки в какой-нибудь системе контроля версий типа git, svn и т.п. Давайте про неё сначала и расскажу.

До сих пор все свойства заметок хранились в файлах __page.opt, который каждой заметки свой. В OutWiker до сих пор не было единого файла, в котором хранилась бы какая-то общая информация о всем дереве заметок. Это сделано для того, чтобы вы могли открывать любую заметку дерева как отдельное полноценное дерево заметок, в котором каждая заметка хранит всю информацию о себе.

На первый взгляд это выглядит логично, но, как говорится, есть нюансы, которые начинают проявляться, если пытаться спаривать OutWiker с другой программой (например, тем же git). Дело в том, что эти файлы __page.opt очень часто менялись из-за того, что туда постоянно записывались такие данные как контрольная сумма заметки (она используется, чтобы не надо было каждый раз парсить викинотацию, если текст заметки не изменился), состояние заметки в дереве заметок (свёрнута / развёрнута), положение курсора в редакторе, а также какая вкладка использовалась последней (Вики / Просмотр / HTML).

Перечисленные данные с одной стороны меняются часто, а с другой — они не так важны, и если их потерять, то ничего страшного не произойдёт. Поэтому в новой версии OutWiker данные по всем заметкам были перенесены в единый файл с именем __cache.tmp, который создаётся в корневой папке дерева заметок, и только там. И все не критичные данные по страницам теперь хранятся в нём. Его смело можно добавлять в файл настроек .gitignore или его налог для других систем управления версиями, чтобы он не попадал в репозиторий. Максимум, что вы заметите, если этот файл будет потерян — это все заметки при первом запуске программы будут свёрнуты в дереве заметок, а викинотацию для каждой заметки придётся разбирать заново, и то это будет заметно только для очень больших заметок.

При этом все важные данные, такие как тип страниц, даты создания и последней правки страницы, метки по-прежнему хранятся в файлах __page.opt для каждой заметке. Перенос некоторых свойств заметок в __cache.tmp открыл путь для ещё одной оптимизации. Теперь не надо для каждой заметки читать эти данные из файла настроек, а при их изменении писать обратно, поскольку файл __cache.tmp обновляется только при закрытии дерева заметок или программы, потому что если программа упадёт в процессе работы, то там хранятся не такие критичные данные, чтобы о них переживать. Благодаря этому может возрасти производительность в тех случаях, когда обращение к файлам заметок сильно замедлено (например по сети или через программу шифрования), да и вообще обращение к диску при работе с OutWiker должно снизиться. Насколько это будет заметно, надо пробовать. Будет интересно, если вы напишете, заметна ли разница.

А теперь перейдём к исправлению ошибок. Те из вас, кто следит за OutWiker в соц. сетях (ссылки в конце поста), уже знают, что, наконец-то была исправлена одна старая ошибка, которая проявлялась только под Linux, и была связана с перемещением по тексту с помощью клавиш Ctrl+Влево / Ctrl+Вправо. Если коротко, то под Linux вместо того, чтобы перескакивать к соседнему слову, эта комбинация клавиш приводила к тому, что фокус в программе перемещался от редактора текста к другим панелям, например, дереву заметок. На поиск виновника этого бага ушло два дня, это был настоящий детектив с неожиданной развязкой, в которой убийцей оказался тот персонаж, на которого совершенно не было подозрений. А учитывая, что интерфейс программы построен так, что от редактора текста до главного окна сообщения от клавиш проходят несколько слоёв абстракции, виновник хорошо скрывался. В итоге оказалось, что во всем виноват стандартный в wxPython компонент, который отвечает за вкладки внизу страницы (Вики / Просмотр / HTML). Оказывается, он перехватывал некоторые сочетания клавиш, и не давал им распространяться дальше, чтобы их можно было обработать в основном окне, где обрабатываются все сочетания клавиш. Почему-то именно эти сочетания клавиш ему очень понадобились, и он самовольно переключал фокус программы. Как только поменял компонент на аналогичный, но с немного другим внешним видом (по задумке разработчиков wxPython более современным, хотя это дело вкуса), баг исчез. Ура, това’ищи!

Также была исправлена одна ошибка, появившаяся в прошлой версии, из-за которой не работали ссылки на страницы, которые показываются при клике на метку. Проблема возникла из-за того, что в процессе подчистки кода я удалил одну строку, которая мне показалась лишней. 🙂 Спасибо пользователю Wave_Blessed, который заметил эту ошибку.

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

Была исправлена экзотическая ошибка, которая вешала OutWiker, если при использовании плагина TableOfContents для создание оглавления на странице вставить команду (:toc:) в заголовок. Честно говоря я очень удивился, когда об этой ошибке мне написали, я бы даже не догадался вставлять эту команду в заголовок.

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

Что касается внутренних изменений, то теперь при запуске тестов измеряется покрытие кода тестами. Оказалось, что в данный момент тестами покрыто 84.6% кода. Строго говоря, сама по себе эта цифра мало о чем говорит, но я ожидал увидеть меньшую степень покрытия. Теперь надо стараться придерживаться такого стиля программирования, при котором эта цифра не должна уменьшаться.

Пожалуй, это все изменения в новой версии. И я все больше задумываюсь о том, чтобы к релизу переименовать версию 2.1 в версию 3.0, поскольку изменений уже накопилось много, в том числе и ломающие обратную совместимость плагинов. Скорее всего переименую версию, когда реализую ещё несколько заметных нововведений.

На этом пока все. До встречи!

OutWiker в социальных сетях:

PS. Вы можете подписаться на новости сайта через RSS, Группу Вконтакте или Канал в Telegram.

Пожалуйста, оцените запись

УжасноПлохоТак себеХорошоОтлично (Количество голосов: 6, средняя оценка: 5,00)
Загрузка...

комментариев 7

  1. unreal666:

    по поводу __cache.tmp.
    Обратно поведение вернуть нельзя? А то мне, к примеру, все, что там будет храниться, критично. У меня 2 базы довольно большие (одна из них 17 гигов вместе с аттачами) и не хочется из-за сбоя проги терять эту инфу + у многие заметки довольно большие – их генерация может длиться секунд по 10-20.

  2. Aleksei:

    в актуальных файлах OutWiker под Linux (бинарная сборка): outwiker_linux_amd64.zip или outwiker_linux_amd64.7z доступных на странице по ссылке https://jenyay.net/Outwiker/Unstable
    лежит версия 842, по крайней мере в файле version.xml указана именно 842, а не 844. Когда планируется обновить до 844?

  3. Aleksei:

    по поводу __cache.tmp. Решение Евгения вынести в отдельный файл некритичную но часто обновляемую вспомогательную информацию очень верное и назревшее. Поддерживаю.
    По поводу желания unreal666 вернуть всё взад, не очень понятна мотивация. Новый формат как раз заточен на использование систем надежного хранения версий, теперь их можно использовать более рационально и экономно. Апелляция к случаю сбоя программы так же не понятна, так как вероятность катастрофичного сбоя как раз выше при постоянной записи вспомогательной и не критичной информации в кучу файлов (и чем больше база тем вероятность сбоя выше, так как количество файлов больше). Запись в один единственный файл резко снижает время записи и соответственно вероятность критичного сбоя.
    в общем не вижу существенных обоснований и повода возвращать прежний формат.
    Спасибо Евгений за правильно продуманное решение.

  4. Jenyay:

    > по поводу __cache.tmp

    Совсем вернуть не удастся, но можно сделать, чтобы этот файл почаще сохранялся.

    > в актуальных файлах OutWiker под Linux (бинарная сборка): outwiker_linux_amd64.zip или outwiker_linux_amd64.7z доступных на странице по ссылке https://jenyay.net/Outwiker/Unstable
    лежит версия 842

    Спасибо, поправил ссылки на скачивание.

  5. unreal666:

    2 Aleksei.
    1. Мое предложение — это сделать 2 варианта работы, а не полностью вернуть назад. Кому что нравится и важнее.
    2. По поводу сбоя. Если будет сбой в __cache.tmp, то навернется вся инфа в нем, а если без него — то только у текущей заметки.
    3. При отсутствии __cache.tmp вероятность сбоя никак не зависит от размера базы, т.к. сохраняется только текущая заметка. А при юзании __cache.tmp и сбое при закрытии базы/проги, как раз будет выше вероятность, т.к. время сохранения __cache.tmp выше, чем одиночной заметки, т.к. надо будет сохранять инфу по всей базе.

  6. Aleksei:

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

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

    А предложение Евгения по установке частоты или интервала времени автоматического сохранения файла __cache.tmp в сочетании с дополнением одной строчки в крон (шедуллер в win) процесса периодического копирования этого единственного файла __cache.tmp в бэкап, на мой взгляд полностью решает вашу проблему сохранения параметров страниц и делает надежность спасения параметров даже сто крат лучше чем при старом алгоритме!

  7. unreal666:

    2 Aleksei
    Еще раз. Вероятность сбоя от размера базы не зависит, т.к. изменения записываются только для текущей страницы, т.е. максимум летит файл __page.opt текущей страницы (да и «базу» я могу открыть вообще на любой внутренней заметке, а не полностью базу).
    А при юзании __cache.tmp, накроется вся инфа для всей базы (для кого-то не очень важная, но для меня важная).

    > периодического копирования этого единственного файла __cache.tmp

    Он единственный, если база единственная. У меня на данный момент 8 баз.

Leave a comment

Subscribe without commenting