QA в Libreoffice

Сокращение QA означает quality assurance, дословно - гарантия качества.

Команда QA - это часть сообщества LibreOffice, которая занимается тестированием LibreOffice. Обо всех ошибках пишутся отчеты на специальный ресурс проекта. 

Внимание! Если вы нашли ошибку в LibreOffice и не сообщили о ней в багзиллу проекта, то разработчики никогда не узнают о проблеме и никогда ошибку не исправят.

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

Примечание: также можно найти информацию об ошибках в статусе UNCONFIRMED (не подтвержденные). Таких ошибок ориентировочно около 500 штук всего, включая старинные отчеты, по которым либо нет единого мнения у людей, которые ошибки проверяли или имеются разные результаты, полученные в процессе проверки.

Вдумайтесь в цифру! 13 тысяч ошибок! Это действительно огромная цифра. Для обработки такого количества информации нужно такое же огромное количество человек.

И на сегодня перед командой QA в LibreOffice стоят такие первоочередные задачи, как:

1. Проверять ежедневно появляющиеся сообщения об ошибках на достоверность и повторяемость. Часто необходимо вытягивать информацию из пользователя, который прислал отчет об ошибке, задавая ему наводящие вопросы. Также желательно сразу сортировать ошибки, заполняя соответствующие поля. Ещё более желательно проверять новые воспроизводимые ошибки на предмет регрессии. Например, в LibreOffice 6.2 ошибка есть, а в 6.1 её не было. И тогда нужно выполнить операцию bibisect для того, чтобы определить коммит и разработчика, который регрессию в код внёс.

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

3. Перепроверять старые ошибки, по которым более одного года не было никаких сообщений. Это нужно для актуализации сведений об ошибке. Также бывает, что ошибка в последних версиях LibreOffice не воспроизводится и тогда её необходимо закрыть с соответствующим сообщением и указанием версии LibreOffice, в которой была проведена проверка. Список таких ошибок, кандидатов на перепроверку есть в вики проекта.

4. Каталогизировать ошибки по так называемым МЕТА. МЕТА - это по сути определенная категория ошибок, аналог каталога в файловой системе, куда складывают файлы по одной тематике. Все существующие МЕТА перечислены в вики проекта. Например, есть большое количество МЕТА для ошибок, связанных с форматом DOCX:

Разработчикам по таким МЕТА удобнее следить за ошибками по теме, в которой они разбираются.

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

Поэтому проекту LibreOffice нужны волонтёры, готовые потратить пару часов своего времени на тестирование ошибок в LibreOffice. Любая помощь приветствуется.

Команда QA всегда готова помочь вам. Есть IRC канал #libreoffice-qa в сети Freenode.net (нужна регистрация в связи со спам атаками в последнее время, ссылка для доступа через браузер https://webchat.freenode.net/?channels=#libreoffice-qa) и есть также Телеграм канал, связанный с IRC чатом в единое пространство, @libreoffice_qa (ссылка для доступа через браузер https://web.tlgrm.eu/#/im?p=@LibreOffice_QA). Каналы англоязычные. Если у вас проблемы с английским, то можете попросить помощи и на русском IRC канале https://webchat.freenode.net/?channels=#libreoffice-ru или Телеграм канале https://web.tlgrm.eu/#/im?p=@libreofficeru

Панель цветов в LibreOffice Draw

В LibreOffice Draw существует очень полезная панель, позволяющая быстро назначать цвет нарисованной фигуре. Называется Панель цветов. Доступна она из меню Вид->Панели инструментов->Панель цветов. Выглядит она вот так (открывается в нижней части экрана):

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

А теперь главная фишка этой Панели цветов. Если выделить фигуру на рисунке, то при нажатии левой кнопкой мыши на цвете будет изменен цвет заливки области фигуры, а если по цвету щелкнуть правой кнопкой мыши - цвет линии границы фигуры! Это очень удобно.

Опрос по поводу сохранения функционала библиографии в LibreOffice

Товарищи из дизайн-тимы запилили опрос по поводу сохранения функционала библиографии в LibreOffice.

Один единственный вопрос звучит так: "Что вы думаете по поводу удаления функционала библиографии из LibreOffice?"

Ответов два:

1. Да, удалить

2. Нет, погодите...

Ссылка на статью https://design.blog.documentfoundation.org/2018/12/19/save-the-bibliography/ , опрос конце статьи на сером поле. 

Голосуй или проиграешь! Или как там было в истории...

Очередные метания разработчиков LibreOffice. Мысли печальные

По умолчанию в новом документе типа электронная таблица Libreoffice Calc создавал верхний и нижний колонтитулы, содержащие некоторые данные. На мой взгляд (и не только на мой) такое поведение по умолчанию абсолютно не нужно, новая электронная таблица должна быть пустая абсолютно. Если мне нужны будут колонтитулы, я их сам добавлю. В новом текстовом документе Writer ведь нету по умолчанию включенных колонтитулов, почему же они есть в Calc?

Вот соответствующая ошибка в багзилле.

Наконец, в бета выпуске LibreOffice 6.2 колонтитулы были отключены для новой электронной таблицы. Победа, я считаю.

Однако оказалось не все так просто. В меню Calc есть такой пункт, как Вставка->Колонтитулы, который открывает одноимённый диалог (это ещё версия 6.1):

Обратите внимание, мы как бы! вставляем колонтитул, однако по сути колонтитул УЖЕ вставлен и УЖЕ содержит данные (в данном случае поле номера листа "Лист1"). В версии 6.1 этот пункт меню всегда активен по умолчанию, поскольку и колонтитулы включены по умолчанию.

Теперь, после отключения колонтитулов в 6.2, этот пункт меню по умолчанию не активен, что вызывает некий когнитивный диссонанс. Пользователь хочет ВСТАВИТЬ колонтитулы, а пункт меню, вполне логично расположенный в меню Вставка, не работает. Бага же! И у этой баги тоже есть свой номер в багзилле. Вторая бага явно вытекает из первой, её надо бы до релиза исправить.

По хорошему было и есть несколько способов решить данную "проблему" (на мой взгляд):

1. Просто удалить пункт меню Вставка->Колонтитулы и включать колонтитулы только в диалоге Формат->Страница, как это возможно и сейчас.

2. Сделать так, чтобы при выборе пункта меню Вставка->Колонтитулы открывался диалог Формат->Страница на нужной вкладке, где даже сейчас явно видно, КАК включить колонтитул.

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

Знаете, что разработчики сделали в итоге? Просто откатили патч, который отключал колонтитулы. Выбрали самый бредовый вариант, который оставил бОльшую проблему на мой взгляд не решённой.

Беда сообщества LibreOffice, что подобного рода вопросы не выносятся на какой-нибудь общедоступный ВСЕМ ресурс, где можно было бы собрать мнения и многих разработчиков LibreOffice и простых пользователей, и кого-то из команды документации. А сейчас данную "проблему" со второй багой обсудили между собой ДВА человека во внутреннем списке рассылки команды дизайна, один из которых, как мне показалось, просто плюнул и пошел по пути наименьшего сопротивления, просто всё вернул в то состояние, какое было до его правки.

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

Разработка LibreOffice. Создание панели инструментов (GtkToolbar) в Glade

Ранее я писал о процессе создания диалога с элементами управления в Glade. В той статье мы затронули создание и размещение кнопок, выпадающих списков, чекбоксов, меток.

Сейчас мне потребовалось внутри существующего диалога создать панель инструментов (GtkToolbar) с парой кнопок для форматирования текста. И я столкнулся с тем, что контейнер GtkToolbar не позволяет на себе размещать кнопки так, как мы делали это ранее с контейнером типа GtkGrid. Оказывается панель инструментов (GtkToolbar) - это отдельный тип контейнера, он позволяет себя редактировать (Edit). Итак, щелкаем правой кнопкой мыши по уже добавленному контейнеру прямо в центральной рабочей области, либо по имени нашей панели инструментов в древовидной структуре в левой части окна Glade, и выбираем пункт контекстного меню Edit.

Откроется вот такой крайне плохо реализованный диалог (его просто трудно заметить на фоне главного окна Glade, он рамок не имеет):

В левой части диалога редактирования панели инструментов есть специальная область, которая отображает доступные элементы управления на этой панели инструментов, аналогичная по назначению структуре в левой части основного окна Glade. В нижней части этой области есть две кнопки: "плюс" и "минус". По нажатию на кнопку "плюс" в список элементов управления добавляется новый элемент, по нажатию на "минус" - удаляется текущий выделенный элемент. Причем удалить существующую кнопку с панели инструментов можно так же, как и все иные виджеты: выделите и нажмите клавишу Delete на клавиатуре. Все оказалось просто (когда знаешь).

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

Выпуск LibreOffice 6.2 beta 1

The Document Foundation объявил о доступности для тестирования LibreOffice 6.2 beta 1. Скачать можно по ссылке https://dev-builds.libreoffice.org/pre-releases/ для операционных систем Windows, Linux, macOS в 32- и 64-битных версиях.

Обо всех найденных ошибках нужно сообщать разработчикам в багзиллу проекта .

Список исправленных ошибок и нового функционала доступен по ссылке https://dev-builds.libreoffice.org/pre-releases/src/bugs-changelog-libreoffice-6-2-release-6.2.0.0.beta1.log 

Обзор изменений в теме значков Elementary

Rizal Muttaqin, автор темы значков Karasa Jaga, описал в своем блоге изменения, которые произошли в другой теме значков, Elementary, с тех пор, как он стал активно данную тему дорабатывать.
Просто чтобы вы знали, различных значков в каждой отдельной теме LibreOffice более 2000 штук.
Пройдите по ссылке и посмотрите иллюстрации (там все очевидно до/после), вполне наглядно видно, что была проделана огромная работа.

Разработка LibreOffice. Копирование патча из gerrit в локальный репозиторий

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

Итак, консоль наш лучший друг. Переходим в каталог с локальным репозиторием LibreOffice и даём там команду git checkout -B some_name master.

Эта команда создаст у вас в репозитории локальную новую ветку с именем some_name (имя можно задать любое вообще).

Далее нужно открыть сайт https://gerrit.libreoffice.org/ перейти в ваш патч и в правом верхнем углу раскрыть выпадающее меню Download.

В строке Cherry Pick справа есть значок "Copy to clipboard", нажмите его. В буфер обмена будет скопирована определённая команда. Вставьте её в консоль через контекстное меню и выполните.

Далее нужно собрать обновленную сборку с вашим патчем, делается это командой make build-nocheck. В этом случае, сборка будет создана быстро, буквально пара минут. Далее мы запускаем LibreOffice с включённым вашим патчем все той же командой instdir/program/soffice.

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

Выйти из локальной новой ветки обратно в главную мастер ветку можно командой git checkout master.

Разработка LibreOffice. Правим код по мелочи, используя веб-интерфейс

18 мая 2020г. Я обновил этот пост, поскольку TDF обновил версию gerrit до более новой, молодёжной и прогрессивной.
Если вы знаете, что ваш патч в проект LibreOffice будет состоять из пары новых строк кода (или изменения пары строк существующего), то такой патч можно сделать на коленке с планшета, сидя в метро, используя веб-интерфейс по адресу https://gerrit.libreoffice.org/.

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

Перво наперво нужно авторизоваться на указанном сайте. В правом верхнем углу есть ссылка SIGN IT. Переходим по ссылке и видим такое:

Поддерживается авторизация исключительно по логину/паролю от вашего аккаунта в TDF!  Если у вас нет аккаунта, то создайте его, используя ту оранжевую кнопку. Авторизуйтесь на сайте.
Далее, чтобы создать патч, нужно выбрать соответствующие проект и ветку (в данной статье мы планируем создать патч в основной разрабатываемой ветке "master").

В верхней части сайта жмем на ссылку Browse и в выпадающем меню выбираем Repositories:

В поле Filter вбиваем core (или help, если вы хотите внести изменения в справку). Чуть ниже из огромного списка осталась одна строка с именем core (или соответственно help). Щёлкаем в этой строке по слову core (help):

Страница обновится. В левой части нажмите на слово Commands.

По центру появится кнопка CREATE CHANGE, жмём её.

Далее появляется вот такое окно (без всяких подсказок, что печально):

В первой строке Select branch for new change вбивайте master и в появившемся списке выбирайте вариант просто master. В поле Enter topic for new change ничего не вводите, в поле Description нужно ввести номер ошибки из багзиллы в формате tdf#номер_бага (это в случае, если вы исправляете ошибку, если нет, то конечно же номер не нужен) и краткое описание изменения. Общая длина описания здесь не должна быть более 75 символов в одной строке (в дальнейшем описание можно будет сделать более подробным и объемным). И жмём кнопку CREATE в правом нижнем углу окошка и видим такое:

В верхнем правом углу нажимаем кнопку EDIT и далее нам нужно выбрать тот файл в исходном коде, в который мы вносим правки. В нижней трети экрана справа есть строка со словами:

 

Нажмите кнопку ADD/OPEN/UPLOAD и в открывшемся окне введите путь до файла, который собираемся изменять, например startcenter.ui:

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

Далее нажмите кнопку OPEN и откроется окно редактора (к сожалению обновление gerrit принесло с собой задержки в работе интерфейса, так что если ничего не происходит на экране, просто подождите пару секунд):

После внесения изменений в исходный код, нажмите кнопку SAVE (дождитесь появления в нижнем левом углу сообщения All changes saved), а затем кнопку CLOSE. Вы вернетесь на предыдущий экран, который будет  содержать строку со ссылкой на ваш измененный файл:

Если нужно в рамках одного патча править несколько файлов, то опять жмём ADD/OPEN/UPLOAD, и так далее, как было чуть выше описано.

Далее жмём в правом верхнем углу PUBLISH EDIT.

Если у вас есть знакомый разработчик LibreOffice, который готов вам помочь, то лучше всего его добавить в ревьюеры вашего патча. В левой части страницы находим слово ADD REVIEWER и щёлкаем на него. В появившемся окне в верхней строке пишем либо ник, либо электронную почту разработчика и жмём кнопку START REVIEW в правом нижнем углу окна.

Если знакомого нет, то придется просто ждать, пока кто-то из разработчиков не посмотрит на патч в порядке живой очереди. Также можно попросить кого-нибудь из разработчиков сделать ревью на IRC канале #libreoffice-dev в сети freenode.net.

Если вы никого не знаете в проекте, тогда просто нажмите кнопку START REVIEW.

После этого сайт можно закрыть и ждать двух сообщений минимум: первое от тестирующего все патчи бота jenkins, второе от ревьюера-разработчика.
Только при условии получения +1 от jenkins'a и +2 от человека-ревьюера ваш патч может быть принят, его ревьюер и вольет в кодовую базу, сразу, как проставит +2.
Удачи!

Выпуск LibreOffice 6.0.7 и 6.1.3

The Document Foundation объявил о выпуске LibreOffice версий 6.0.7 и 6.1.3. Всем пользователям соответствующих веток рекомендуется обновиться.

Списки исправленных ошибок для 6.0.7:

https://wiki.documentfoundation.org/Releases/6.0.7/RC1

https://wiki.documentfoundation.org/Releases/6.0.7/RC2

https://wiki.documentfoundation.org/Releases/6.0.7/RC3

Списки исправленных ошибок для 6.1.3:

https://wiki.documentfoundation.org/Releases/6.1.3/RC1

https://wiki.documentfoundation.org/Releases/6.1.3/RC2

Скачать новые версии LibreOffice, как всегда, можно отсюда https://www.libreoffice.org/download/.

Новое расположение вкладок в диалогах LibreOffice 6.2

Случайно увидел в ежедневной сборке, что диалог "Формат ячейки" в Calc стал выглядеть оригинально, если используется бэкэнд gtk3. Скриншот сделан в среде Openbox, а не в Gnome, поэтому общий внешний вид странноватый и выглядит, как неродной, но не это важно:

Вкладки сбоку! Я не очень уловил и пока не интересовался у разработчиков - это для всех диалогов будет уже в 6.2 и только для gtk3, или это вообще пока эксперимент.
Update: я глянул в Glade, изменить расположение вкладок на положение "слева" - это очень просто, изменяется одно единственное свойство у контейнера. Вопрос в том, какова причина таких изменений.
Update 2: пообщался с разработчиком, который это пилит. Оказывается GTK 3 не умеет в многострочное расположение вкладок, он умеет вкладки только прокручивать по горизонтали, если они все не вмещаются целиком в размеры диалога. Поэтому, если вкладок много, то в некоторых диалогах они (может быть!) будут перемещаться сверху в левую часть диалога. Будет ли это полностью реализовано к выходу LibreOffice 6.2, пока не понятно.

Разработка LibreOffice. Собственная сборка LibreOffice в Ubuntu

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

Ниже ссылки на страницы вики проекта для сборки LibreOffice на разных операционных системах:

Сборка из ОС Linux

Сборка из ОС Windows

Сборка из macOS 

Мне нужна была своя сборка в Linux (Kubuntu 18.10), поэтому я ниже опишу те несколько команд, используя которые, я получил свою сборку LibreOffice:

Самое первое - нужно подключить репозитории с исходным кодом (которые по умолчанию в убунте отключены). Запускаем Пакетный менеджер Muon (в Ubuntu и Xubuntu это будет Synaptic), выбираем пункт меню "Настройка->Настроить источники программ", вводим пароль, в диалоге "Источники приложений" ставим галочку на опции "Исходный код". Закрываем диалог. Система должна обновить список пакетов с сервера обновлений. Если этого не случилось, то в консоли (которая всё равно далее потребуется) даем команду sudo apt-get update.

Второе - устанавливаем некоторые зависимости командой sudo apt-get build-dep libreoffice

Третье - устанавливаем ещё зависимости командой sudo apt-get install git gstreamer1.0-libav libkrb5-dev nasm graphviz ccache

Четвёртое - находим свободного места гигабайт около 30, создаём каталог, где будет лежать исходный код LibreOffice (у меня это был просто /home/roman) и даём следующие команды git config --global protocol.version 2 (эта команда включает новый протокол git, который в десяток раз уменьшает нагрузку на сервер) и затем git clone https://gerrit.libreoffice.org/core libreoffice (которая у меня в каталоге /home/roman создала подкаталог /home/roman/libreoffice и развернула там исходный код проекта). Есть и альтернативный способ получения исходного кода, я написал об этом отдельно.

Пятое - после завершения предыдущей команды, переходим в каталог libreoffice, дав команду cd libreoffice

Шестое - даём команду ./autogen.sh (заметьте, безо всякого sudo!). Тут возможно задать кучу различных опций, например отключить использование Java или использовать библиотеки из дистрбутива, чтобы их не собирать заново при компиляции.

Седьмое - если предыдущая команда завершилась без ошибок и предупреждений, то последняя команда - это make (также без sudo).

Далее придется ждать от 2-х до 8-9 часов. Это очень сильно зависит от вашего процессора и дисковой подсистемы (крайне желательно разворачивать дерево исходников на SSD). Чем более многоядерный и высокочастотный процессор и чем быстрее диск, тем быстрее пройдет сборка.

Восьмое - после успешного окончания работы команды make, LibreOffice можно запустить командой instdir/program/soffice.

Разработка LibreOffice. Создание графического интерфейса пользователя в Glade

В LibreOffice некоторые графические элементы интерфейса, такие как диалоги и элементы управления в них (кнопки, чекбоксы, выпадающие списки, радиокнопки и так далее) описаны в файлах с расширением .ui. Внутри это XML файлы, которые в принципе можно править и создавать в любом текстовом редакторе. Однако всегда удобнее видеть готовый результат сразу и управлять размещением графических элементов в специальном редакторе. Таким редактором для LibreOffice является Glade - редактор интерфейса из проекта Gnome.

Примечание: аналогичные файлы с расширением .ui создает ещё один аналогичный редактор графических интерфейсов Qt Designer из проекта KDE. Файлы .ui, созданные в Glade не совместимы с файлам .ui, созданными в Qt Designer, и, соответственно, для редактирования .ui файлов из LibreOffice программа Qt Designer не подходит (а жаль)!

К сожалению, современные версии Glade не доступны для ОС Windows, поэтому для работы нужно будет использовать любой удобный вам дистрибутив Linux (можно Linux установить в виртуальной машине типа VirtualBox). Будем считать, что с установкой Glade вы разобрались и он у вас запускается. Перейдём непосредственно к Glade.

Запускаем Glade и видим такое окно (версия Glade 3.22):

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

и добавляете в раздел "Дополнительные пути к каталогу" следующий путь <ваш_каталог_установки_LibreOffice>/share/glade. Сохраните настройку и перезапустите Glade.

В этой статье мы будем создавать новый диалог для пакетного конвертирования документов из формата в формат из LibreOffice.

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

Итак, используя Pencil, я создал вот такой прототип диалога (который по факту работы в Glade получилось немного упростить):

Для начала в Glade нужно создать новый проект, нажав на соответствующий значок в виде пустого листа в левом верхнем углу. Окно Glade примет вот такой вид с тремя рабочими областями:

Затем добавить в проект окно диалога (GtkDialog) из меню "Окна" в верхней части экрана (перевод интерфейса самого Glade 3.22 на русский язык выполнен как-то частично, но уж как есть):

Теперь нужно задать диалогу ID, по которому он будет вызываться в исходном коде программы. Это делается в правой части Glade, на боковой панели, на вкладке "Основные" в самой первой строке. У меня это будет Document_converter.
А вот дальше нужно сначала подумать, прежде, чем что-то делать. Дело в том, что Glade не позволяет просто размещать управляющие элементы (виджеты) в окне нашего диалога, как угодно. Вернее позволяет, но по-умолчанию это только один виджет размером во всё окно! Поэтому сначала нужно разбить внутреннюю область диалога на несколько частей, добавив на диалог один или несколько контейнеров.
Контейнер - это специальный элемент в GTK, который позволяет создавать разметку области. Каждый контейнер имеет свои параметры. На контейнерах можно размещать, как дополнительные контейнеры, так и виджеты. Этих контейнеров в Glade достаточно много разных видов, и, комбинируя их, а также их параметры и взаимное расположение, а ещё и варьируя параметры самих виджетов, можно будет настроить общий внешний вид диалога.
Небольшая ремарка: на мой взгляд - это более, чем странная концепция, которая достаточно не легко мной воспринимается. Однако, скорее всего, именно такой механизм размещения виджетов реализован не просто так, а имеет какие-то причины.

Итак, глядя на наш макет диалога, исходя из парадигмы, что каждый виджет требует под себя отдельное посадочное место, то нужно разделить наш диалог на сетку из тринадцати строк и трёх столбцов. Приступим.
С левой стороны в Glade есть древовидное иерархическое представление всех объектов в нашем диалоге. Каждый графический элемент верхнего уровня (окно, любой диалог) уже содержит в себе предварительно настроенный какой-либо контейнер.
В нашем диалоге также по-умолчанию уже имеется контейнер - графически выделенный, как тёмная область. Тип этого контейнера - GtkBox (внутренний). Для работы с ним нужно в левой части экрана, в дереве элементов, раскрыть строку с именем нашего диалога (самую верхнюю) и выделить строку GtkBox (внутренний)).
Примечание: для работы с любым элементом в Glade элемент сначала нужно выделить. Делать это можно либо прямо в центральной области, где показан результат работы, либо в дереве в левой части Glade.
Для создания той самой сетки 13х3 ячеек в нашем диалоге нужно использовать контейнер типа GtkGrid. Выбираем такой контейнер из одноимённого меню "Контейнеры" в верхней части окна Glade и щёлкаем мышью на темной области в нашем диалоге. Мы помним, что нам надо тринадцать строк с учётом кнопок управления диалогом (Help, Cancel, Convert), поэтому для контейнера GtkGrid (убедитесь, что в дереве слева выделен именно он) в правой части Glade на боковой панели увеличиваем значение параметра Count (количество) для "Строки" до двенадцати (под кнопки управления диалогом уже зарезервирована отдельная область). Количество столбцов оставляем равным трём.
Примечание: Все настройки контейнеров, включая размеры, можно изменять и после того, как на контейнере будут размещены виджеты. Однако это приведёт к дополнительной работе по перемещению уже существующих виджетов в новое положение. Лучше продумывать размещение виджетов и разметку заранее.
Вот, что мы получили в итоге:

Теперь следующий этап - это размещение виджетов в контейнере.
Выбираем виджеты из меню "Control" и "Display", и щёлкаем мышью на соответствующих им местах в нашей разметке. Нам будут нужны (указаны меню - тип виджета - мой комментарий):
Display - GtkLabel - текстовая надпись-метка, подсказка
Control - GtkFileChooserButton - кнопка для выбора файла/каталога
Control - GtkEntry - поле для ввода текста
Control - GtkButton - кнопка
Control - GtkChekButton - чекбокс (галочка)
Control - GtkRadioButton - радиокнопка
Control - GtkComboBoxText - выпадающий список
Display - GtkProgressBar - прогресс бар
Не пугайтесь, что при размещении виджетов на диалоге он будет сжиматься и виджеты будут жаться друг к другу. Дистанцию между виджетами и прочий лоск мы будем наводить позднее.
Обратите внимание, что при размещении виджетов в ячейках сетки их можно растягивать по-горизонтали и по-вертикали на соседние ячейки сетки. Делается это для любого выделенного виджета на правой боковой панели на вкладке "Упаковка", параметры "Ширина" и "Высота" соответственно, значение которых означает количество занимаемых ячеек в контейнере. Отсчёт занимаемых ячеек начинается с верхней левой ячейки. Это нужно учитывать, если вы виджет хотите сделать большой.
Каждому виджету обязательно нужно присвоить ID на правой боковой панели в соответствующем поле на вкладке "Основные". Это идентификатор виджета, по которому с ним будет работать код программы. ID должен быть уникальным для данного диалога/окна и крайне желательно, чтобы из ID было понятно, что это за тип виджета и что он делает.
Примечание (важное!): ID нужно прописывать не только самим виджетам типа кнопок, чекбоксов, меток и выпадающих списков, но и вложенным в виджеты элементам (если такие есть конечно)! Например каждый элемент в выпадающем списке может иметь свой ID. И они должны каждый иметь свой уникальный ID. Хоть это и не обязательно, но в дальнейшем, в коде, это обязательно пригодится!
Если вы ошибочно установили виджет не на то место, какое планировали изначально, то виджет можно либо удалить, нажав на клавишу Delete на клавиатуре, либо переместить на нужное место в контейнере используя параметры виджета "Прибавление слева" и "Прибавление сверху" на вкладке "Упаковка" на правой боковой панели. Номера строк и столбцов в контейнерах начинаются с нуля. То есть левая верхняя ячейка нашего контейнера будет иметь адрес 0,0.
Вот итоговый вид нашего диалога (пока итоговый) в Glade:

 А вот, как диалог будет выглядеть в KDE:

Переработка диалогов управления макросами в LibreOffice

По состоянию на сейчас в LibreOffice управление макросами реализовано в интерфейсе через одно место.

Проблемы, как я их вижу, такие:

Из меню Сервис->Макросы->Управление макросами доступны ЧЕТЫРЕ разных диалога управления макросами, для каждого доступного языка отдельно. Basic, JavaScript, BeanShell и Python. Причем все они разные.

Причём диалог для Basic не позволяет управлять макросами. Для собственно управления макросами Basic нужно открыть отдельный дополнительный диалог.

Кнопка Правка во всех диалогах позволяет редактировать сам макрос, а вовсе не имя/положение библиотеки/модуля/диалога.

Я предлагаю всё это безобразие упразднить и сделать ОДИН диалог для управления макросами и запуска макросов.

Вот такого примерно вида (я на английском делал, потому что в багзилле так ВСЕ поймут, о чем речь и зачем):

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

Никакого разделения по языкам программирования не нужно, в силу того, что LibreOffice сам различает на каком языке программирования написаны макросы в библиотеках и, я так понимаю, не допустит, чтобы из библиотеки Basic запустился модуль на Python. А значит и в моем варианте диалога нужно заставить LibreOffice значками выделять библиотеки/модули на разных ЯП и они все просто будут иерархически в одном дереве.

Есть ещё один момент: в текущей версии LibreOffice для работы с макросами на Python нужно внешнее расширение APSO. Без него не получится даже создать соответствующую библиотеку. Почему так сделано, я не очень понимаю, как и то, почему это расширение не включено в базовую поставку LibreOffice, раз базовый функционал просто нерабочий.

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

Охота на ошибки LibreOffice 6.2 alpha 1

The Document Foundation объявил «Охоту на ошибки» в LibreOffice 6.2 alpha 1.

Для удачной охоты вам необходимо 22 октября 2018 года скачать дистрибутив под вашу архитектуру и операционную систему с сайта http://dev-builds.libreoffice.org/pre-releases/, установить LibreOffice и заняться поиском ошибок (или подтверждением корректной работы).

Особое внимание при тестировании первой альфа версии LibreOffice 6.2 необходимо уделить новому модулю интеграции LibreOffice в KDE 5.

Нужно проверить:

• корректное определение наличия среды KDE 5 и установку соответствующего модуля vcl
• корректный внешний вид приложения в KDE 5
• наличие/отсутствие значков в меню LibreOffice в среде KDE 5
• выравнивание элементов меню LibreOffice при включенном/отключенном отображении значков в меню
• какой диалог открытия/сохранения файлов используется в LibreOffice в KDE 5
• что угодно ещё, что вам придет в голову проверить для LibreOffice в KDE 5

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

Популяризация LibreOffice и поиск начинающих разработчиков на С++

Поглядел я на количество открытых багов в багзилле проекта, оценил количество активных разработчиков в gerrit, плюсом внимательно поглядел на общую фотографию с конференции в Тиране. И сделал печальный вывод: разработчиков, которые непосредственно пишут код в проект крайне мало и они все достаточно возрастные. И задумался я о преемственности поколений девелоперов, и пришла мне в голову мысль попробовать привлечь в проект студентов или начинающих программистов, которые возможно захотят поучаствовать в большом проекте с открытым исходным кодом, повысить свои навыки программирования, а также иметь несколько патчей в проекте, чтобы было что показать работодателю в не таком и далёком будущем.

Написал я объявление, нацеленное на развешивание в профильных ВУЗах (вот ссылка на ПДФ), которое попросил распространить среди студентов там, где мог (не так кстати и много мест, где я попробовал, надо расширять ареал распространения информации). В объявлении ищутся именно начинающие кодеры на С++ (это важно).

На сегодня прошло не так много времени с момента просьбы о размещении объявления, однако есть уже некоторые результаты:

1. Появилась пара человек, которые захотели поддерживать инфраструктуру проекта, пока в виде русскоязычного сайта ru.libreoffice.org, и будут разрабатывать/поддерживать новую версию сайта в дальнейшем.

2. Из этой пары человек один также будет пробовать писать код, начав с Easy hacks

3. Ещё один человек заинтересовался проектом LibreOffice, как ещё одним проектом, куда он может слать патчи на С++. Не факт, что он будет это делать, но хотя бы он теперь знает, что можно.

4. И ещё один товарищ написал мне отдельное письмо, что также желает писать код в проект, и как только настроит необходимое окружение, так появится на нашем IRC канале #libreoffice-ru в сети freenode.net (вот вэб-интерфейс для простоты вхождения в IRC, если кто-то заинтересовался).

И это собственно вовсе не те люди, на которых было ориентировано само объявление. Это люди, которые узнали о теме из просьбы разместить объявление. Это как в теоретической науке: исследуют нейтронные звезды, а в качестве практического применения люди получают технологию wi-fi. 

В общем и целом, я не уверен, что само объявление появится хоть в одном ВУЗе и что хоть один человек заинтересуется проектом, однако то, что хоть какой-то результат есть уже сейчас - это хорошо.

Если кто-то заинтересуется кодингом на С++ в проект LibreOffice - милости просим.

Если кто-то может распространить объявление среди студентов ИТ специальностей - буду благодарен.

Использование кода, написанного в рамках GSoC, в LibreOffice

Я уже писал про то, что в этом году студенты со всего мира писали код в рамках спонсируемого гуглом мероприятия GSoC. В том числе код писали и для LibreOffice. Одним из заявленных проектов была переработка диалога Печать. Студент (Daniel Silva) с заданием справился, диалог переделал, код соответствующий написал (об этом я тоже писал ранее). Однако, по какой-то причине, код он писал не в основной мастер-ветке, где ведется разработка следующей версии LibreOffice 6.2, а в отдельной. И теперь сложилась достаточно неприятная ситуация: студент код написал, а в основную ветку его не влил. Бог знает по каким причинам. Самое плохое, что и наставник его из сообщества LibreOffice, который курировал именно этот проект, не спешит делать это сам и не спешит чем-то помочь или как-то ускорить студента.

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

Самый простой вопрос: если так происходит, зачем вообще подавать заявки в гугл на участие в GSoC?

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

Еще один вопрос: почему наставник отстранился от логического завершения проекта, от слияния кода с основной веткой? 

Изменение диалога Печать - это достаточно серьезно, это надо специально и отдельно тестить. А когда тестить, если этого нету в билдах ежедневных?

В общем и целом - получилось совсем нехорошо для проекта.

Фото с конференции LibreOffice 2018 в Тиране

Прямо сейчас проходит ежегодная конференция разработчиков и вообще всех причастных к созданию LibreOffice в столице Албании городе Тирана. Ниже общее фото всех присутствующих:

PS: Майк, я тебя вижу :D

Выпуск LibreOffice 6.1.2

The Document Foundation объявил о выпуске минорной версии LibreOffice 6.1.2. Данный выпуск состоялся после всего одного релиз кандидата, про который я писал в предыдущем посте. Если кто-то скачал и установил себе первый релиз кандидат с версией 6.1.2.1, то обновляться смысла нет, сборки побайтно идентичны.

Быстрый выпуск версии 6.1.2 был сделан для соблюдения сроков выпуска последующих релизов, в связи с тем, что предыдущий корректирующий выпуск версии 6.1.1 был выпущен с задержкой.

Скачать дистрибутив LibreOffice можно как всегда по ссылке https://www.libreoffice.org/download/.

Выпуск LibreOffice 6.1.2.1

Доступен для скачивания первый релиз кандидат версии LibreOffice 6.1.2.

Список исправленных ошибок - https://dev-builds.libreoffice.org/pre-releases/src/bugs-changelog-libreoffice-6-1-2-release-6.1.2.1.log

Скачивать как всегда отсюда - https://dev-builds.libreoffice.org/pre-releases/

Отдельно отмечу исправление 12 критических ошибок, приводивших к падениям офиса.

Советую всем, использующим в работе версию LibreOffice 6.1 обновиться до 6.1.2.1.

Критичные для меня баги в LibreOffice. Шёл 2018 год

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

Так вот, изменилась ли ситуация с этими багами за год? Давайте поглядим (список из предыдущего поста):

1. Мерцает интерфейс пользователя, когда по меню водишь мышкой, причем для видеокарт от Интел в среде ОС Windows это никак не лечится, а глаза мне дороги. - в версии 6.1.1.2 присутствует до сих пор.

2. Рендеринг шрифтов в документе и в интерфейсе пользователя стал просто ужасный. - исправлено.

3. Рендеринг встроенных в документ изображений PNG также хромает, это не критично по сути, так как экспорт в ПДФ или печать выполняются с нормальным качеством, но смотреть на это убожество при работе в самом документе сил нет никаких. - это бага, связанная с OpenGL, и это не исправлено до сих пор.

4. В Calc не работает автофильтр при попытке фильтровать записи по дате. Это вообще нонсенс. По сути достаточно большой кусок реальной работы просто не может быть выполнен с использованием LibreOffice. - исправлено.

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

6. До сих пор LibreOffice может выдать критическую ошибку в каком-то одном модуле и унести в ад ВСЕ открытые документы ВО ВСЕХ модулях. - не исправлено и не может быть исправлено! Ну давайте так, на мой взгляд критичных багов, приводящих к крашам в LibreOffice меньше не становится. В последнем чейнджлоге между 6.0 и 6.1 я насчитал 22 фикса крашей. Ну куда это годиться?! То, что в адъ уносятся ВСЕ документы - это архитектурная особенность LibreOffice - это мы выяснили ещё в прошлый раз, однако легче от этого не становится. Эта МЕГАошибка видимо будет присутствовать в LibreOffice всегда, пока будет ТАКОЕ количество крашей.

Итог: исправлена половина багов. Это достаточно хорошо.

А теперь немного новых бяк, которые меня огорчили за прошедший год в LibreOffice, и которые пока не исправлены:

1. LibreOffice безумно медленно открывает таблицы в формате Excel с большим количеством комментариев в ячейках. Не то, чтобы это беда беда, но приятного мало.

2. LibreOffice безумно медленно отрабатывает автофильтр в таблицах в формате Excel с большим количеством комментариев в ячейках. А вот это беда беда, потому что замедляет работу с таблицей. Автофильтр я дергаю в рабочей таблице достаточно часто. Это явно проблема фильтра импорта, потому что автофильтр на том же контенте с комментариями в формате ODS (родном) работает достаточно моментально.

3. Совсем не бага, но отсутствие функционала - не получилось найти вменяемый и производительный способ собирать данные из разных файлов и нескольких таблиц по 2000 строк и 20 столбцов в одну большую таблицу в отдельном файле. Для того же Excel нашлась надстройка Power Query, которая может кучу разных вещей и при этом, для получения нужного результата, мне, простому юзеру-ламеру, не потребовалось изучать работу БД и программирование макросов.

Я имею надежду, что что-то улучшится в плане исправления багов за следующий год.

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

Инфографика от Collabora

Товарищи из компании Collabora опубликовали немного инфографики в своем блоге (см.ниже).

Коротенько: LibreOffice поддерживает 205 различных форматов файлов, имеет 200 миллионов активных пользователей по всему миру, тестируется на 105 тысячах документов, за год с июля 2017 по июль 2018 года в проект было сделано 16 749 коммита, из которых треть сделана сотрудниками Collabora, образ docker с онлайн офисом CODE был скачан 7,5 млн.раз, загод добавили 1753 юнит теста, из которых 41% заслуга Collabora, Collabora Office используют 250 тысяч пользователей в 55 странах.

Выпуск LibreOffice 6.1.1

The Document Foundation объявил о выпуске первого корректирующего релиза LibreOffice 6.1.

Всем пользователям, использующим версию 6.1 крайне рекомендуется обновиться до 6.1.1.

Списки исправленных ошибок:

https://wiki.documentfoundation.org/Releases/6.1.1/RC1

https://wiki.documentfoundation.org/Releases/6.1.1/RC2

Скачать новую версию можно как всегда по ссылке https://www.libreoffice.org/download/.

Руководство по условному форматированию в LibreOffice Calc

Вздумалось мне пографоманить и я решил написать обо всех доступных вариантах условного форматирования, доступного в LibreOffice Calc версии 6.0. В итоге просто список опций перерос в небольшое руководство с картинками, комментариями и пояснениями. 

Скачать Руководство в формате гибридного PDF для версии 6.0.
Скачать Руководство для версии 6.2.

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

Ошибка	Статус	Суть ошибки
119407	Новая	Запрос на улучшение: добавить настройку для указания дня начала недели (сейчас это Воскресенье!)
119402	Исправлено	Неправильно отображалось количество дней в неделе, 9 вместо 7
118482	Исправлено  в 7.2	Не работает прокрутка мышью в списке условий
118481	Новая	Запрос на улучшение: позволить полный вид отображения условия в списке (сейчас отображается полностью только выделенное условие)
117899	Новая	Изменяются настройки условного форматирования при копировании диапазона из Calc в Writer как OLE объекта
117871	Дубликат	Запрос на улучшение: позволить импортировать стили из существующих документов в текущий, как это можно во Writer
117809	Исправлено	Не обновляется тип значка в условном форматировании, если удалить минимальное или максимальное значение в диапазоне
117787	Новая	Столбцы гистограмм слипаются, если в соседних ячейках одинаковые значения
117764	Новая	Некорректная работа при использовании нового пункта контекстного меню ячейки "Условное форматирование"
117720	Исправлено  в 6.3	Необходимо удалить элемент Максимум из списка, который задает Минимум, и удалить элемент Минимум из списка, который задает Максимум
117715	Новая	Проблема с форматом числа при применении условного форматирования, если формат числа в ячейке был изменен вручную
117647	Исправлено	Нужно изменить некоторые названия условий для типа "Значение ячейки" (там, где было указано число 10)