воскресенье, 28 октября 2018 г.

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

В целях проверки изменений, которые вы захотите внести в код LibreOffice, вам в обязательном порядке потребуется собственная сборка на основе самого свежего исходного кода проекта (ветка core).
Ниже ссылки на страницы вики проекта для сборки LibreOffice на разных операционных системах:
Мне нужна была своя сборка в 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 clone https://gerrit.libreoffice.org/core libreoffice (которая у меня в каталоге /home/roman создала подкаталог /home/roman/libreoffice и развернула там исходный код проекта)
Пятое - после завершения предыдущей команды, переходим в каталог libreoffice, дав команду cd libreoffice
Шестое - даём команду ./autogen.sh (заметьте, безо всякого sudo!)
Седьмое - если предыдущая команда завершилась без ошибок и предупреждений, то последняя команда - это make (также без sudo).
Далее придется ждать от 2-х до 8-9 часов. Это очень сильно зависит от вашего процессора и дисковой подсистемы (крайне желательно разворачивать дерево исходников на SSD). Чем более многоядерный и высокочастотный процессор и чем быстрее диск, тем быстрее пройдет сборка.
Восьмое - после успешного окончания работы команды make, LibreOffice можно запустить командой instdir/program/soffice.

суббота, 27 октября 2018 г.

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

В LibreOffice основные графические элементы интерфейса - главное окно, диалоги и элементы управления в них (кнопки, чекбоксы, выпадающие списки, радиокнопки и так далее) описаны в файлах с расширением .ui. Внутри это XML файлы, которые в принципе можно править и создавать в любом текстовом редакторе. Однако всегда удобнее видеть готовый результат сразу и управлять размещением графических элементов в специальном редакторе. Таким редактором для LibreOffice является Glade - редактор интерфейса из проекта Gnome.
Примечание: аналогичные файлы с расширением .ui создает ещё один аналогичный редактор графических интерфейсов Qt Designer из проекта KDE. Файлы .ui, созданные в Glade не совместимы с файлам .ui, созданными в Qt Designer, и, соответственно, для редактирования .ui файлов из LibreOffice программа Qt Designer не подходит (а жаль)!
К сожалению, современные версии Glade не доступны для ОС Windows, поэтому для работы нужно будет использовать любой удобный вам дистрибутив Linux. Будем считать, что с установкой 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 было понятно, что это за тип виджета и что он делает.
Если вы ошибочно установили виджет не на то место, какое планировали изначально, то виджет можно либо удалить, нажав на клавишу Delete на клавиатуре, либо переместить на нужное место в контейнере используя параметры виджета "Прибавление слева" и "Прибавление сверху" на вкладке "Упаковка" на правой боковой панели. Номера строк и столбцов в контейнерах начинаются с нуля. То есть левая верхняя ячейка нашего контейнера будет иметь адрес 0,0.
Вот итоговый вид нашего диалога (пока итоговый) в Glade:
 А вот, как диалог будет выглядеть в KDE:

среда, 17 октября 2018 г.

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

По состоянию на сейчас в LibreOffice управление макросами реализовано в интерфейсе через одно место.
Проблемы, как я их вижу, такие:
Из меню Сервис->Макросы->Управление макросами доступны ЧЕТЫРЕ разных диалога управления макросами, для каждого доступного языка отдельно. Basic, JavaScript, BeanShell и Python. Причем все они разные.
Причём диалог для Basic не позволяет управлять макросами. Для собственно управления макросами Basic нужно открыть отдельный дополнительный диалог.
Кнопка Правка во всех диалогах позволяет редактировать сам макрос, а вовсе не имя/положение библиотеки/модуля/диалога.
Я предлагаю всё это безобразие упразднить и сделать ОДИН диалог для управления макросами и запуска макросов.
Вот такого примерно вида (я на английском делал, потому что в багзилле так ВСЕ поймут, о чем речь и зачем):
В левой части диалога мы именно управляем библиотеками/модулями/диалогами, а также умеем делать импорт/экспорт. А в правой части мы работаем непосредственно с макросами: запускаем, назначаем макросы на события и редактируем их, если надо.
Никакого разделения по языкам программирования не нужно, в силу того, что LibreOffice сам различает на каком языке программирования написаны макросы в библиотеках и, я так понимаю, не допустит, чтобы из библиотеки Basic запустился модуль на Python. А значит и в моем варианте диалога нужно заставить LibreOffice значками выделять библиотеки/модули на разных ЯП и они все просто будут иерархически в одном дереве.
Есть ещё один момент: в текущей версии LibreOffice для работы с макросами на Python нужно внешнее расширение APSO. Без него не получится даже создать соответствующую библиотеку. Почему так сделано, я не очень понимаю, как и то, почему это расширение не включено в базовую поставку LibreOffice, раз базовый функционал просто нерабочий.
Так вот, при переделке диалога управления макросами этот странный факт также необходимо будет учитывать.

вторник, 16 октября 2018 г.

Охота на ошибки 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

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

четверг, 11 октября 2018 г.

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

Поглядел я на количество открытых багов в багзилле проекта, оценил количество активных разработчиков в gerrit, плюсом внимательно поглядел на общую фотографию с конференции в Тиране. И сделал печальный вывод: разработчиков, которые непосредственно пишут код в проект крайне мало и они все достаточно возрастные. И задумался я о преемственности поколений девелоперов, и пришла мне в голову мысль попробовать привлечь в проект студентов или начинающих программистов, которые возможно захотят поучаствовать в большом проекте с открытым исходным кодом, повысить свои навыки программирования, а также иметь несколько патчей в проекте, чтобы было что показать работодателю в не таком и далёком будущем.
Написал я объявление, нацеленное на развешивание в профильных ВУЗах (вот ссылка на ПДФ), которое попросил распространить среди студентов там, где мог (не так кстати и много мест, где я попробовал, надо расширять ареал распространения информации). В объявлении ищутся именно начинающие кодеры на С++ (это важно).
На сегодня прошло не так много времени с момента просьбы о размещении объявления, однако есть уже некоторые результаты:
1. Появилась пара человек, которые захотели поддерживать инфраструктуру проекта, пока в виде русскоязычного сайта ru.libreoffice.org, и будут разрабатывать/поддерживать новую версию сайта в дальнейшем.
2. Из этой пары человек один также будет пробовать писать код, начав с Easy hacks
3. Ещё один человек заинтересовался проектом LibreOffice, как ещё одним проектом, куда он может слать патчи на С++. Не факт, что он будет это делать, но хотя бы он теперь знает, что можно.
4. И ещё один товарищ написал мне отдельное письмо, что также желает писать код в проект, и как только настроит необходимое окружение, так появится на нашем IRC канале #libreoffice-ru в сети freenode.net (вот вэб-интерфейс для простоты вхождения в IRC, если кто-то заинтересовался).
И это собственно вовсе не те люди, на которых было ориентировано само объявление. Это люди, которые узнали о теме из просьбы разместить объявление. Это как в теоретической науке: исследуют нейтронные звезды, а в качестве практического применения люди получают технологию wi-fi. 
В общем и целом, я не уверен, что само объявление появится хоть в одном ВУЗе и что хоть один человек заинтересуется проектом, однако то, что хоть какой-то результат есть уже сейчас - это хорошо.
Если кто-то заинтересуется кодингом на С++ в проект LibreOffice - милости просим.
Если кто-то может распространить объявление среди студентов ИТ специальностей - буду благодарен.

четверг, 4 октября 2018 г.

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

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