OutWiker 2.1.0.840 unstable с новыми панелями инструментов

OutWiker 2.1.0.840 unstable с новыми панелями инструментов

Всем привет. Пока Роскомнадзор в очередном безумном угаре не заблокировал весь интернет, а чиновники не ввели лицензии на владение сайтов, спешу поделиться с вами новостями об очередной нестабильной версии OutWiker. Этот месяц получился очень продуктивным.

Программисты в последнее время все чащи стали использовать термин «технический долг» применительно к разработке программ. Мне очень нравится этот термин своей точностью. Технический долг — это то, что когда-нибудь в любом случае надо будет исправить в программе, и часто, чем дольше откладываешь «момент расплаты» по такому долгу, тем сложнее становится его закрыть. В последнее время при разработке OutWiker-а большая часть времени уходила на покрытие таких долгов. Сюда можно отнести переход на wxPython 4 (поскольку возникли проблемы с wxPython 3.0.2 в новых версиях Ubuntu) и Python 3.x (поскольку все идет к тому, что дистрибутивы Linux скоро перестанут включать в себя Python 2). За прошедший месяц удалось избавиться от еще двух крупных технических долгов, о чем я сейчас и расскажу.

Начнем с исправления, о котором часто писали пользователи, и я тоже об этом неоднократно писал. Речь идет о панелях инструментов. Как я и обещал, в новой версии OutWiker они полностью переделаны. Я долго думал, как их лучше оформить, чтобы с одной стороны кнопки были как-то сгруппированы по темам (шрифты, плагины, таблицы и т.п.), а с другой стороны экономно расходовалось место. После нескольких экспериментов и прикидок решил, что не стоит создавать какие-то экзотические элементы интерфейса, а нужно просто сделать так, чтобы панели не разъезжались. До сих пор панели выглядели неаккуратно, потому что они были слишком умные и пытались сохранять свое положение в окне, но при этом все панели могли менять размер при переключении между разными типами страниц. Это оказались противоречивые требования. Поэтому новые панели инструментов стоят бок о бок соседними панелями. Их больше нельзя перемещать, но зато они аккуратно пристыковываются друг к другу, а если надо, переходят на следующую строку.

Вот как выглядят новые панели под Linux:

А вот как они выглядят под Windows:

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

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

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

С самого начала проекта для OutWiker писались тесты с использованием стандартной для Python библиотеки unittest. Это были не только простые маленькие тесты, но и тесты, проверяющие работу интерфейса программы. По историческим причинам для тестирования GUI создавался единственный экземпляр приложения (класса, производного от wx.App), в котором создавались окна программы для каждого такого теста. Через некоторое время оказалось, что хотя окна вроде бы закрываются, но происходит утечка ресурсов GDI (в памяти оставались какие-то картинки, кисти, перья и т.п.) Когда тестов было мало, это было не страшно — при обычном использовании программы таких утечек не было, поскольку главное окно создавалось один раз и уничтожалось только перед закрытием приложения. А в тестах ресурсы GDI накапливались и не уничтожались. Когда тестов стало много (сейчас их уже больше 3500), я столкнулся с проблемой — под Windows одно приложение не может иметь больше 10000 ресурсов GDI, а если тесты превышали этот порог, то все последующие тесты падали из-за того, что не могло создаться очередное окно.

В свое время мне почему-то не удалось сделать так, чтобы на каждый тест создавалось отдельное приложение wx.App, и я сделал обходной маневр, который, правда, имел свои преимущества. Я разбил тесты на группы: ядро, GUI, викинотация, плагины. Тесты в этих группах запускались независимо друг от друга, и каждая группа не создавала больше 10000 ресурсов GDI. Заодно я мог легко запускать тесты определенной группы. Например, если я что-то менял в парсере викинотации, то мне не надо было запускать еще тесты интерфейса или плагинов. Так тесты работали на протяжении последних нескольких лет, хотя я помнил о проблеме и она мне если и не портила сон, но по крайней мере мозолила глаза своим существованием.

И вот недавно эта проблема опять дала о себе знать, когда группа тестов интерфейса снова стала создавать слишком много ресурсов GDI. Можно было бы просто разбить эту группу еще на две группы, но захотелось решить проблему на корню. К тому же, недавно я пролистывал перед сном исходники wxPython и увидел, что там тесты без проблем создают экземпляры wx.App для каждого теста. Дальше началась алхимия, о которой я не буду рассказывать, чтобы вас не усыпить. Результатом многодневного рефакторинга стало то, что теперь тесты избавились от утечки GDI и их теперь снова можно запускать одним махом. В качестве приятного побочного эффекта оказалось, что теперь при уничтожении главного окна можно не выполнять некоторые шаги по уничтожению интерфейса (все, что нужно, уничтожится само), а это ускорило закрытие программы.

Но мне не хотелось терять возможность запускать тесты по группам, поэтому теперь в дополнение к unittest для запуска тестов используется pytest, который позволяет запускать тесты из указанной папки (тесты и так были упорядочены по папкам). Заодно в конце выполнения тестов добавил вывод статистики по оставшимся в памяти объектам, которые могут занимать GDI, чтобы следить, вдруг опять появится тест, который будет создавать утечку ресурсов, чтобы устранять проблемы сразу при ее появлении.

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

И в завершение хочется сказать спасибо Владимиру Тубольцеву, который активно подключился к разработке OutWiker и в данной версии улучшил систему загрузки плагинов. Для пользователей это пока не заметно, но это пригодится для другой крутой вещи, которую сделал Влидимир. Но эту крутую вещь я еще сам не успел попробовать, поэтому она пока не включена в сборку, о ней я напишу в другой раз. Надеюсь, мне удалось вас заинтриговать?

Также сегодня обновил плагины Sessions и Statistics. В них были исправлены некоторые небольшие ошибки.

На сегодня это всё, жду отзывов на новую версию.

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

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

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

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

комментария 4

  1. Михаил:

    Евгений, а насколько реально портировать Outwiker под мак? При наличии свободного времени я бы даже мог этим заняться. Пока я вижу проблему в самом wx — поставить нормально (ну как нормально — через Homebrew) можно только wx 3.0, а вы уже вроде как везде переходите на 4 версию.

  2. Jenyay:

    На мой взгляд портировать Мак приложение вполне реально. Сам я этим не занялся, потому что под рукой нет Мака, а в виртуалке когда-то удалось установить только очень древнюю версию Mac OSX. В коде не так много мест, зависящих от операционки. wxPython можно установить через pip, а потом пытаться сделать приложение с помощью pyInstaller (как это сейчас делается для Windows и Linux). В версии wxPython 3.0 был какой-то компонент, который был не реализован в Маке (кажется, это было всплывающее окно, которое используется при клике на тег в списке тегов), надо посмотреть, реализовали ли его в wxPython 4. Но даже если нет, готов попытаться его чем-нибудь заменить.

  3. Verano:

    Переформулирую вопрос Михаила:
    Евгений, а насколько реально портировать Outwiker под _Андроид_?

    Неоднократно пробовал запускать PmWiki на телефоне, но всё как-то криво получается: до сих пор не нашел компактный и неглючный сервер с PHP под Андроид, имеются проблемы записи на SD карточку, проблемы с синхронизацией вики с настольной версией и т.д.

    И вроде все решаемо, но количество затраченного времени на поиски решения и на настройки отбивает всякое желание с этим иметь дело.

  4. Jenyay:

    А вот под Андроид придется по сути писать приложение с нуля. На самом деле я очень хочу этим заняться, но пока времени на это не хватает.

Leave a comment

Subscribe without commenting