Как поссорились TDF и Collabora и почему это печально

Давняя подковерная грызня между советом директоров TDF и главой Collabora Productivities Майклом Миксом вчера вылилась (как говно на голову всем в сообществе) в исключение всех работников Collabora из членов TDF и последовавший за этим пост от Майкла, в котором говорится о том, что Collabora перестает вносить вклад в LibreOffice, делает свой форк, из которого исключат Java и Base, напялят на него "красивую" ленточную морду и будут отдельно его развивать на пару со своим главным продуктом Collabora Online (это облачный офис а-ля Гугле Докс).

Учитывая, что более 50% кода в проект писали именно сотрудники Collabora - это политическое и техническое фиаско со стороны TDF. Нанимаемые напрямую фондом разработчики не заменят десятки программистов из Collabora, во всяком случае их надо нанимать больше намного и входить в курс им тоже надо будет время.

Между прочим, появились уже теории заговора вокруг этой воню чей темы - типа Европейский союз будет давать денег на посконный офис без закладок от МайкроСофт в силу политической обстановки в мире и поэтому TDF и Collabora захотели сожрать соло этот вкусный пирог. Посмотрим.

Вангую, что разработка LibreOffice и так не быстрая, замедлится, что починка багов, которых море морское - тоже быстрее не станет. 

TDF наняли двух из трёх ранее планировавшихся программистов

Как я ранее писал, TDF озаботились наконец-то наймом программистов на получаемые донаты.

Итак, кого же нанял TDF:

Dan Williams - будет заниматься UI и macOS специфичным кодом

Neil Roberts - будет заниматься поддержкой макросов. Я очень надеюсь, что он начнёт с допиливания поддержки работы с Python макросами, это прям мечта и маст хэв.

Остался ещё один кодер, на поддержку модуля Base, которого пока нет на горизонте. Но я так понял TDF и не спешит никуда в этом вопросе, к сожалению.

Balazs Varga реализует фичу "Форматировать как Таблицу" в Calc

Видимо Маркус не до конца осилил в одиночку фичу "Форматировать как Таблицу" в одно лицо, поэтому Balazs Varga из Collabora ему помогает. Вчера он выкатил почти пятьдесят патчей на эту тему, надеюсь через недельку другую мы сможем потестировать эту штуку в LibreOffice Calc.

Напомню, что это фича из MS Excel, которую очень много народу ждёт. 

Используем git для отправки патчей в LibreOffice

Это больше для себя памятка. Ни для кого с минимальным опытом программирования всё ниженаписанное не новость =)

Итак в терминале, убедившись, что мы в каталоге с исходным кодом проекта:

git pull - синхронизируем локальный исходный код с сервером

git checkout -b <branch_name> origin/master - создаем ветку

Делаем наш патч

make check - гоняем тесты для патча

git commit - записываем правки в историю

./logerrit submit master - коммитим патч в геррит на ревью

Если надо патч поправить после ревью или по любой иной причине:

git checkout <branch_name> - переходим в нашу ветку с патчем

Правим патч, чтобы стало как надо

git commit --amend -a - обновляем (!!! это важно !!!) правки в истории

./logerrit submit master - коммитим обновлённый патч в геррит на ревью

Маркус Морхард вернулся и сообщил о своей работе над фичей в Calc, аналогом "форматировать как таблицу" из Excel

Markus Mohrhard - это один из старых разработчиков LibreOffice, со срача с которым я начинал свое вхождение в проект. Последние много лет он был неактивен, но вот недавно он объявился, сделал пару патчей, а сегодня написал письмо в список рассылки о том, что делает фичу для Calc, аналог функции "форматировать как таблицу" из Excel.

Вот кривой перевод его сообщения (я читаю архив рассылки, а там нет скриншотов, о которых он говорит в письме):

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

Код находится в ветке feature/calc-table-styles.

Прилагаю два скриншота, показывающих сравнение рендеринга моего тестового документа в MS Excel и текущего рендеринга в Calc.

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

И там в письме дальше длинный список того, что надо бы ещё сделать в этом направлении, вы не думайте, что он выкатил готовую фичу прям =) Но всё равно это очень хорошее начинание, в свое время Маркус делал механизм автообновления для LibreOffice, который в итоге всё же допилили и в 25.2 он уже работает, так что и с этой фичей случится тоже самое, рано или поздно.

Управление макросами в LibreOffice - мы хотим перемен

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

Мало разделения по языкам, так ещё и управление диалогами (которые можно создавать для макросов внутри LibreOffice) - это отдельная команда и свой диалог, выполнение макроса - это свой диалог.

У меня в свое время появилась идея, что все эти дела, связанные с управлением макросами должны быть в одном месте, в одном диалоге главном, который бы мог отображать макросы на всех ЯП, диалоги, и позволял бы выполнять действия над ними всеми в зависимости от языка и типа объекта. И я написал баг репорт - https://bugs.documentfoundation.org/show_bug.cgi?id=120658.

Идея единого диалога выглядела вот так, всё в одном диалоге:

Он был воспринят не очень однозначно и долго висел без какой-либо реакции (как и большинство наших баг репортов, кстати). Я сам-то не могу код на плюсах писать, а вот приставать к людям, которые код писать могут - это я могу. И вот мне повезло, я дважды просил Jim Raykowski глянуть, может ли он это реализовать и во второй раз он согласился и таки написал патч на почти четыре тысячи строк, который реализует мою идею. Вот ссылка на патч - https://gerrit.libreoffice.org/c/core/+/176254.

А вот видео - результат реализации:

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

А самое забавное, что у нас нет под капотом механизма, который бы позволял управлять макросами на Python также, как идёт управление макросами на Basic. И в новом диалоге при выбранном макросе Python - выводится ошибка.

И дальнейшим планом видится именно допиливание нашего фреймворка для управления макросами так, чтобы можно было работать с Python макросами без лишних движений в виде установки расширения APSO и прочего. Но это тема для отдельного поста =)

Для тех, кто захочет контрибьютить в LibreOffice

Этот пост - просто информация для желающих, с чего начинать контрибьютить в проект LibreOffice.

Вся актуальная информация на английском языке, но для программиста это не должно стать препятствием. Также вы уже должны знать С++, учить вас программировать с нуля здесь никто не будет.

Итак, для тех, кто захотел написать пару строк кода для LibreOffice:

Начать следует с прочтения вот этой ссылки - https://wiki.documentfoundation.org/Development/GetInvolved. Это ровно информация для новичков в проекте, как скачать исходники, как собрать свой билд, какие зависимости, для каких IDE есть предварительные настройки и как их включить, какой код стайл мы используем, как пишем патчи и как их засылаем. Обратите внимание, вам нужно достаточно современное железо с многоядреным процессором (4 и более ядер) и большое количество ОЗУ (8 или более Гб), потому что первоначальная сборка на 4-х ядерном Core i5 2,5 ГГц сборка занимала ровно два часа времени. Также необходимо около 30Гб сводобного места на диске (который уже должен быть SSD).

После того, как вы настроите окружение, встанет вопрос, а с чего же можно начать знакомиться с проектом. У нас есть список так называемых изи хаков именно для этой цели. Обычно это баг репорт, в котором достаточно подробно расписано что надо сделать и указана ссылка на конкретный файл или даже строку в исходниках. Вот этот список - https://wiki.documentfoundation.org/Development/EasyHacks/by_Required_Skill/Skill_C%2B%2B. Обратите внимание, список разбит на три группы по сложности, выбирайте себе любую цель и пробуйте написать патч.

Если вы достаточно опытный разработчик и вам сразу все понятно и возможно просто интересна какая-то конкретная тема, например производительность, утечки памяти, проблемы в поддержке каких-то форматов, UI, новые фичи - у нас есть багзилла с бесконечно длинным списком проблем. Также у нас есть некая сортировка проблем по темам, мы называем это МЕТА багами, найти их можно вот здесь -  https://wiki.documentfoundation.org/QA/Tracking_Bugs. Там есть фильтры, можно отсортировать то, что вам надо и покопаться в конкретных баг репортах по выбранной теме.

После написания патча, он должен попасть к нам в геррит - https://gerrit.libreoffice.org/q/status:open+-is:wip+branch:master. Конечно мы используем Git, однако у нас имеется возможность поправить пару строк, используя веб-интерфейс. До пуша в геррит вы обязаны прогнать свой патч, используя команду make check - это позволит вам локально прогнать все юнит-тесты. В геррите патч проверит бот Дженкинс, который также гоняет юнит-тесты для каждой из популярных десктопных ОС, а затем ваш патч должен пройти код-ревью и кто-то из опытных разработчиков с правами должен вам поставить +2 и замержить ваш патч.

Найти разработчиков всегда можно в рабочие часы по средне-европейскому времени в IRC канале - https://web.libera.chat/?chan=#libreoffice-dev. Общение на английском языке.

Также можно задать технический вопрос в список рассылки для разработчиков (также на английском языке) - https://wiki.documentfoundation.org/Development/Mailing_List

По каким-то организационным вопросам можно спросить у меня в Телеграм (пока его не прибили), ник @Kompilainenn.

TDF приняли на работу разработчика в области RTL/CTL/CJK систем письменности

В свое время The Document Foundation много критиковали за то, что они не нанимают разработчиков на поступающие донаты. И в мае и июле 2023 года они наконец наняли двух разработчиков на полный день. Один из них, Khaled Hosny, очень активно проработал пару месяцев, а потом по каким-то разногласиям с руководством TDF (чуть ли не политическими), оставил свою работу. А занимался он как раз направлением развития и поддержки RTL/CTL/CJK систем письменности в LibreOffice.

Ну вот TDF не прошло и года озаботился его заменой. Сейчас в списке рассылки я случайно обратил на ремарку, что нанят новый разработчик Jonathan Clark для аналогичной работы.

Это безусловно положительная новость, вопрос в его компетентности. Khaled всё же и опыт имеет немалый именно в разработке LibreOffice, знает проект изнутри, и в шрифтах и рендерингах всяческиъ хорошо разбирается. Ну посмотрим...

TDF принял на работу уже второго программиста

Итак, свершилось чудо! Чуть ранее, я писал, что TDF хочет нанять программистов наконец-то. А недавно они таки приняли первого - Khaled Hosny.

Сегодня TDF опубликовал сообщение о приемке на работу и второго программиста. Это Michael Weghorn, человек тоже не просто так со стороны. Он давно уже контрибьютит в проект LibreOffice. До TDF работал в какой-то организации в Мюнхене, где также занимался LibreOffice.

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

Повторюсь, это очень хорошая тема, что TDF будет тратить деньги именно на найм программистов на полный рабочий день для работы над проектом LibreOffice.

TDF наконец принял на работу первого из двух запланированных кодеров

Помните, я радовался, что наконец-то донатные деньги TDF будет тратить и на разработку тоже, а не только на себя, конференции и инфраструктуру? Ну так они все же наняли первого программиста, который должен будет заниматься проблемами в поддержке RTL/CTL письменности. Это оказался Khaled Hosny, который и до найма в TDF занимался тем же самым в проекте LibreOffice, только, как волонтер или ему кто-то заказывал какую-то разовую работу. Он из Египта, проблемы RTL (справа налево) письменности ему близки, плюс он один из разработчиков библиотеки HarfBuzz и имеет большой опыт в понимании работы со шрифтами, с текстом и в плюсах. Это прям однозначно хорошая новость.

Замена старого генератора MSI установщика на новый скрипт на Pyhton

Внезапно оказалось, что для формирования MSI установщика (из которого LibreOffice можно установить на ОС Windows), у нас использовались скрипты на Perl! Да, оно работало, и вроде не плохо. Но вот решили ребята, что Perl нынче никто не знает, что-то править там  - это тухлый номер, и решили осовременить этот механизм, заменив скрипты на Perl на один скрипт написанный на Pyhton.

Вообще идея-то хорошая, мы реально избавляемся от гремучего Perl и должны заиметь намного более короткий и простой скрипт на Python.

Патч долго обсасывали, долго полировали, наконец сегодня его замержили. И тут же вылезла ошибка, которая не позволяет MSI формировать=)))

Единственно, я не понял, почему они Python скрипт добавили, а старый код не выкинули в одном патче.

А ещё мне очень не нравится, что такие вещи не освещаются никак. Не было никакой статьи, ни баг-репорта с предложением, ничего. Я случайно это увидел в нашем gerrit.

Разработчик, который перевел LibreOffice на Skia, ушел из проекта

Я абсолютно случайно сегодня узнал, что Luboš Luňák, разработчик LibreOffice из Collabora, ушел из этой самой Collabora и из проекта LibreOffice соответственно. А это был человек, который в одно лицо перевел LibreOffice на использование библиотеки рендеринга Skia. И соответственно все оставшиеся не решёнными баги, связанные со Skia в LibreOffice, так и останутся не решёнными.

Я, откровенно говоря, и не удивлен даже подобному. Это нормальная история, когда человек меняет работу. Не нормально только, что никто более в Skia внутренностях в проекте не разбирается. Даже обновить Skia на новую версию скорее всего никто не возьмется (у нас версия m103, текущая в апстриме - m111), а ведь там могли бы найтись возможно фиксы и для наших проблем.

Ну Skia - это одна сторона вопроса, прямо конкретная. А вторая сторона, более общая, что Luboš очень грамотный разработчик и его уход конечно скажется в принципе на проекте.

The Document Foundation наконец-то хочет нанять программистов для работы над LibreOffice на полный день

TDF после стольких лет вопросов "почему фонд с полученных через пожертвования денег не нанимает разработчиков" наконец-то решили нанять двух программистов на полный день.

Первый должен заниматься поддержкой в LibreOffice CTL/RTL языков письменности. А это все языки мира, которые не латиница и не кириллица. Арабский, иврит, китайский, корейский, японский, хинди, тайский, вьетнамский и так далее, во всем разнообразии языков народов азии.

Второй должен сосредоточиться на вопросах accessibility в LibreOffice. Это возможности работы в программе для людей с различными ограничениями, поддержка контрастных тем, поддержка систем для озвучки элементов интерфейса и так далее. 

То, что TDF нанимает программистов напрямую и ставит им конкретные задачи - это огромный плюс проекту.

Использование нового линковщика mold вместо стандартного при сборке LibreOffice

Один знаменитый в узких кругах программист взял и написал новый линковщик mold, который (по слухам) здорово ускоряет сборку нашего не маленького проекта LibreOffice.

Илмари пишет, что при использовании mold сборка LibreOffice у него стала занимать 30 минут вместо 50 минут со стадартным lld. Почти в ДВА раза! Учитывая, что у меня старое железо, и сборка вообще занимает два часа, применение mold явно имеет смысл.

Чтобы использовать mold при сборке LibreOffice (о том, как собирать свою сборку я писал ранее вот в этой статье), вам нужен установленный в вашей ОС mold и на шестом шаге "даём команду ./autogen.sh" нужно добавить к команде опцию --enable-ld=mold, либо добавить эту опцию в ваш файл autogen.input.

Вот результат тестов от самого автора mold :

 

Добавлю после натурного эксперимента: 

mold в Ubuntu 20.04 собирается после прочтения инструкции по ссылке выше. Всё оказалось просто:

Команда sudo apt-get install -y build-essential git clang cmake libstdc++-10-dev libssl-dev libxxhash-dev zlib1g-dev pkg-config установит необходимые зависимости.

Далее команды:

git clone https://github.com/rui314/mold.git
cd mold
git checkout v1.2.0
make -j$(nproc) CXX=clang++
sudo make install

скачают репозиторий mold к вам локально, соберут бинарник версии 1.2.0 и поместят его в системный каталог.

Так как штатный компилятор GCC в Ubuntu 20.04 имеет версию 9.4, а поддержка mold появится только в GCC 12, то собирать LibreOffice, используя mold можно только юзая Clang (это тоже компилятор). Для этого в файл autogen.input в каталоге с исходниками LibreOffice надо добавить следующие строки:

CC=clang
CXX=clang++
--enable-ld=mold

Именно так, две первые строки без двух дефисов, а последняя с ними.

Далее даем команды

make clean

make

И процесс побежит.

Кто же разрабатывает LibreOffice

Я периодически слышу вопросы, типа "Кто же разрабатывает LibreOffice? Студенты? Компании? А какие?". Ну так вот, ответ на вопрос представлен на диаграмме ниже, это данные за 2021 год:

Данные в процентах, так нагляднее. Общее количество коммитов в проект за 2021 год составляет 14400. 

Итак, компании Collabora и Red Hat вносят каждая по четверти от общего количества коммитов. Причём это патчи, которые добавляют серьезный новый функционал, улучшают производительность, совместимость с MS Office, и прочие достаточно сложные вещи.

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

TDF - это коммиты от сотрудников самого фонда The Document Foundation. В основном там патчи с юнит тестами от Xisco Fauli (он QA инженер) и патчи в справку и документацию от Olivier Hallot (он лидер команды документации).

Others - это все остальные компании, вклад которых варьируется от 0,1% до 4 %. Список таких компаний приведён в правой части диаграммы. Не смотря на вроде бы незначительный вклад в процентном отношении, большинство этих коммитов важные и нужные.

Используем perf и FlameGraph для поиска и визуализации проблем производительности в LibreOffice

В LibreOffice бывают иногда странные случаи, когда он зависает и жрет ресурсы компьютера, как не в себя. Например, загрузка процессора достигает 100% при каких-то банальных операциях. Это ненормально, как вы понимаете. Для того, чтобы программист понял, в каком собственно месте исходного кода ошибка, есть куча инструментов.

Например, perf - это утилита для оценки производительности системы из состава ядра linux. Она на уровне ядра собирает кучу всякой информации и записывает её в файл. Этот файл можно проанализировать потом и понять, где проблемное место. Проблема в том, что вывод этой утилиты весьма слабо читаемый и нужно потратить кучу времени на то, чтобы понять, где там что. А время - деньги. 

Так что один хороший человек написал FlameGraph - это инструмент, который обрабатывает результат вывода утилиты perf и на выходе даёт график, показывающий, какой именно процесс внутри программы занимает больше всего процессорного времени.

График получается в формате SVG и выглядит так вот примерно:

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

Как получить такой график?

1. Нам нужен установленный linux дистрибутив, у меня это Kubuntu 19.04, в котором мы и будем работать далее.

2. Нам нужен установленный пакет linux-tools-$(uname -r), который и содержит утилиту perf. 

Примечание: Обратите внимание, пакет этот должен точно соответствовать текущей версии ядра, поэтому я и команду так написал! У меня было отдельное ядро, не из дистрибутива, к которому linux-tools я конечно не нашёл, пришлось перейти на дистрибутивное ядро. 

3. Также нужен пакет linux-tools-$(uname -r)-generic.

4. Нам нужен LibreOffice, собранный с опцией --enable-symbols (для этого вам потребуется большое количество оперативной памяти, больше 8Гб точно). Опция эта позволит программисту увидеть сразу проблемное место в коде достаточно точно.

5. Нам нужен FlameGraph. Его нужно просто скачать из git автора. Там есть зелёная кнопка "Clone or Download", жмите на неё и в выпадающем меню будет надпись "Download ZIP". Скачается архив, я распаковал его в каталог ~/soft/. Это важно, поскольку влияет на команды, которые мы будем запускать.

Примечание: FlameGraph из архива имеет имя своего каталога FlameGraph-master, я этот самый мастер удалил из имени для упрощения команды.

Для запуска perf без прав root нужно дать команду

sudo sysctl -w kernel.perf_event_paranoid=1
Предварительно запускаем LibreOffice (не системный, а свою сборку!). Я запускал из отдельной вкладки терминала. 

Для начала процесса сбора данных даём команду в каталоге FrameGraph: 

perf record -F200 --call-graph dwarf,65528 --pid=`pidof soffice.bin`

Команда соберет данные из запущенного LibreOffice.

Выполняете действия, которые приводят к проблеме. Закрываете LibreOffice (или убиваете процесс, если он завис).

В терминале будет написано нечто вроде:

[ perf record: Captured and wrote 292,351 MB perf.data (4667 samples) ]

Примечание: вообще-то объем файла perf.data здорово зависит от времени работы LibreOffice и количества действий, которые вы делаете. У меня почти 4Гб данные для графика выше заняли. Так что имейте ввиду, что в том месте, откуда вы даёте команды, есть достаточно свободного места.

Далее даём следующую команду:

perf script | ~/soft/FlameGraph/stackcollapse-perf.pl | ~/soft/FlameGraph/flamegraph.pl --width 1500 > perf.svg

Она и даст нам искомый график с именем perf.svg. Процесс создания SVG может занять достаточно длительное время. Этот SVG и надо прикрепить в багрепорт в багзилле. Вот в принципе и всё.

Вклад Астра Линукс в LibreOffice оказался равен нулю

Я в своё время очень порадовался, когда товарищи из Астра Линукс вроде начали активно писать код в проект LibreOffice. Они даже три патча запилили, из которых два уже заброшены и дропнуты, и только первый пробный патч был влит в кодовую базу проекта. По сравнению с ребятами из Альт - это мизер, не заслуживающий упоминания. Я уж не говорю про Collabora или даже NIZS.

На сегодня никакого движения от Астры нет и не предвидится, хотя планы у них были. 

Очень, очень жаль, конечно...

Почему я ненавижу редактировать Справку в LibreOffice

Вы когда-нибудь пробовали внести какие-нибудь изменения в Справку LibreOffice? Нет? Попробуйте (вот здесь я писал о том, как это можно сделать, используя веб-интерфейс). Это настолько не тривиальная задача из-за использования тэгов в формате XML, что просто противно даже пытаться. Вместо того, чтобы писать текст, вы занимаетесь почти программированием.

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

Вы вносите правки, сохраняете, а кто-то с правами принимает или отклоняет ваши правки. Собрать впоследствии все эти странички в единый архив, который и будет составлять Справку, я думаю проблем не составит.
Я хочу такую систему для редактирования Справки LibreOffice!