Управление макросами в 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 7.4 включили поддержку тёмной темы в Windows окружении

Caolán McNamara запилил патч, который добавляет в LibreOffice поддержку тёмной системной темы. Выглядит это как-то вот так:

На мой взгляд, оттенки чёрного в окне LibreOffice не совпадают с системными (сравните цвет панели задач Windows и цвет внутри окна LibreOffice).

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

Улучшения Навигатора в LibreOffice 7

Один из разработчиков LibreOffice, Jim Raykowski, реализовал несколько улучшений для Навигатора (открывается по F5 или в Боковой панели).

Если категория в Навигаторе не содержит в себе ни одного элемента, то такая категория выделяется серым цветом, для наглядности. Это работает в Writer и Calc.

В контекстные меню всех элементов Навигатора в Writer (Заголовки, Таблицы, Изображения, Врезки, Закладки, и всё остальное) добавлены пункты Go to (Перейти к), Edit (Правка), Delete (Удалить), Rename (Переименовать).

В контекстное меню Навигатора в Writer, для элементов категории Headings (Заголовки) добавлены пункты для управления уровнем и месторасположением заголовков - Promote/Demote Chapter и Promote/Demote Level.

В Навигатор добавлена возможность отслеживания положения текстового курсора в документе и выделять соответствующий заголовок (подзаголовок) в Навигаторе. В английской версии этот функционал называется Outline Tracking. Доступны три состояния для этой функции: Default (По умолчанию), Focus (Фокус) и Off (Выключено). Отличаются они поведением Навигатора:

- По умолчанию. При перемещении курсора по разным разделам текста, в Навигаторе раскрывается структура заголовков до соответствующего уровня и, после перемещения курсора в следующий раздел, структура остается развёрнутой.

- Фокус. При перемещении курсора по разным разделам текста, в Навигаторе раскрывается структура заголовков до соответствующего уровня, но после перемещения курсора в следующий раздел, структура сворачивается до уровня 1, а отображается только структура выделенного в настоящее время раздела.

- Выключено. Положение курсора в тексте не отслеживается и в Навигаторе соответствующие заголовки не выделяются.

В Навигаторе была отдельная панель навигации, которая позволяла выбрать по какому именно объекту будет осуществляться навигация. Эта штука не очень-то удобная, потому что сделана была, как отдельная плавающая панель, её нельзя было прикрепить к Навигатору или куда-то ещё, а ещё есть пара багов связанных с этой панелью. Jim удалил её и добавил в Навигатор просто выпадающий список (см.картинку выше).

Насколько я вижу в gerrit.libreoffice.org, Jim продолжает работу над Навигатором и скорее всего будут реализованы какие-то ещё полезности.

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

Спасибо, Jim, за твою работу!

Изменение шрифтов в диалоге инсталлятора LibreOffice в Windows

Сегодня диалог инсталлятора LibreOffice в Windows использует шрифт Tahoma с кеглем 8. В багзилле есть запрос на приведение шрифтов к стандартному шрифту в Windows для GUI, коим является Segoe UI с кеглем не менее, чем 9. Попробуем это сделать (спасибо Майку за теорию!)

Инсталлятор LibreOffice использует стандартный для Windows механизм msi. Любой файл msi можно редактировать ручками, используя специальную утилиту от MicroSoft - Orca. Скачать ее можно по этой ссылке.

После установки Orca нужно щёлкнуть правой кнопкой по файлу инсталлятора LibreOffice с расширением .msi и выбрать пункт "Edit with Orca". Откроется вот такое окно:

С первого взгляда ничего не понятно и вообще страшно глядеть, одни цифры и символы.

Примечание: вот кстати ссылка на документацию по msi: https://docs.microsoft.com/en-us/windows/desktop/Msi/windows-installer-portal.

Будем разбираться. Итак, в левой части окна мы видим список таблиц, используя данные из которых, msi и формирует внешний вид диалоговых окон инсталлятора. А в правой части окна мы как раз видим данные той таблицы, которая выделена в настоящий момент в левой части окна.

Для изменения только лишь шрифтов нам необходима таблица TextStyle. Найдем её в левой части окна и выберем её:

Это относительно простая таблица. По столбцам содержится следующая информация:

TextStyle - это внутреннее название шрифта, которое используется в других таблицах внутри нашего msi.

FaceName - это название шрифта, которое отображается в операционной системе. Обязательно корректное написание.

Size - это кегль шрифта, который будет отображаться в диалоге.

Color - здесь можно задать цвет шрифта, если ничего не указано, то шрифт скорее всего выставлен в "Авто". Я с цветом экспериментов не ставил, мне было ни к чему.

StyleBits - это отдельный признак форматирования символов шрифта. Цифра 1 - жирное написание, 2 - курсив.

Вот ссылка на более подробную информацию по этой таблице.

Обратите внимание, как много самых разных шрифтов прописано в таблице. При этом, как оказалось, большинство указанных шрифтов просто нигде в нашем диалоге не используется. Проверяется это очень просто: жмём Ctrl+F, открывается окно поиска, забиваем туда внутреннее имя шрифта и жмём кнопку "Найти". Поиск осуществляется по всем таблицам файла msi с текущей строки сверху вниз. Когда поиск дойдет до последней строки в последней таблице, просто на соответствующий вопрос (Продолжить поиск с начала?):

нужно ответить "Да".

И вы увидите, что больше ни в одной таблице шрифт, например MSSGreySerif8, не используется. Аналогично нужно было проверить все остальные шрифты, что и было сделано.

Далее мы осознали, что всего для нашего диалога нам требуется три вида шрифта: основной, основной с жирным написанием и заголовок. Соответственно основной шрифт - Segoe UI кегль 9, заголовок - Segoe UI кегль 11. Вот какой вид приняла таблица TextStyle после наших правок:

Описаны всего три шрифта, все три это Segoe UI. Обратите внимание на StyleBits равном 1 (жирное начертание) для двух из них. Также были изменены внутренние названия шрифтов.

Теперь, в связи с тем, что мы изменили внутренние названия шрифтов, необходимо для ВСЕХ управляющих элементов диалогов (Controls) и для текста в диалогах (Text) прописать новые внутренние названия.

Делается это:

- во-первых в таблице Property, где необходимо в строке DefaultUIFont задать в столбце Value внутреннее имя нашего основного шрифта - DialogDefault. Это мы задали шрифт по-умолчанию для всего диалога.

- во-вторых в таблице Control, где необходимо в каждой строке, которая имеет в столбце Text первыми символами, например {&Tahoma8} заменить их на например {&DialogHeading}. Этим мы задаём форматирование конкретно этого текста не шрифтом по-умолчанию, а другим, но также заданным в таблице TextStyle.

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

В принципе, на этом замена собственно шрифтов в диалоге закончена. 

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

Примечание: кстати, цифры, которыми обозначены размеры диалогов, областей текста, отступы контролов, - это вовсе не пикселы, как я сначала подумал. Это некий стандартный юнит, который равен 1/12 размера шрифта MS Sans Serif с кеглем 10! Я сначала вообще был в шоке от такой забавной привязки. А потом всё же стал разбираться. По сути, это сделано так по очень простой причине: пользователь может масштабировать весь UI в системе на, например, 125%. А так как размер любого шрифта в системе (включая тот самый MS Sans Serif) зависит от DPI, то и диалог наш точно также масштабируется пропорционально.

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

Всего диалоговых окон в инсталляторе msi LibreOffice 31 штука, включая информационные окна и сообщения об ошибках при установке. ВСЕ из них необходимо предварительно просмотреть, используя возможности Orca. Выберите пункт меню Tools->Dialog Preview, откроется вот такое окно:

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

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

Не забываем, что чтобы корректно отобразить весь текст в диалоге, мы должны увеличить область с текстом и следом размер самого диалога!

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

Размеры диалогов указаны в таблице Dialog в столбцах Width (ширина) и Height (высота). Соответственно для каждого диалога мы меняем 374 на 474.

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

Dialog - внутреннее имя диалогового окна

Control - внутреннее название контрола 

Type - тип контрола (кнопка, выпадающий список, радио-кнопка, поле для ввода/отображения данных, область с текстом)

Х - расстояние от левого края диалога до контрола в юнитах.

Y - расстояние от верхнего края диалога до контрола в юнитах.

Width - ширина контрола в юнитах

Height - высота контрола в юнитах

Text - собственно надпись на контроле. На это поле мы будем глядеть, чтобы понимать, а какой блок мы двигаем на диалоге, иногда это не очень очевидно.

Логика при изменении контролов была такая:

- если мы трогаем кнопки - меняем значение в столбце Х (двигаем кнопку!), просто добавляем 100. Но не для всех кнопок, например Help как была в левой части диалога, так и осталась!

- если мы трогаем область с текстом, выпадающий список или поле для ввода/отображения текста - меняем значение в столбце Width (увеличиваем ширину!), также просто добавляем 100.

После завершения манипуляций для одного диалога - смотрим превью получившегося. Если всё ОК - переходим к следующему.

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

Это были Control, Dialog, Property, RadioButton, TextStyle. Используйте пункт меню Tables->Export Tables для экспорта таблиц на диск.

Далее можно спокойно формировать патч для LibreOffice, как вам удобно.
ps: кстати, вот, что получилось в итоге (показано одно из диалоговых окон). Слева новый вариант, справа - старый):

pps: после ревью патча выявилось несколько проблем:
- я полностью заменил таблицы Dialog и Control и теперь проблемно отследить в каких строках, что менялось. Попросили исправить. Это чисто оформительская проблема.
- в файлах .idt в исходниках LibreOffice были прописаны идентификаторы текстовых строк, вместо самого текста, как мне показывал Orca. Это сделано для возможности локализации интерфейса. Поэтому тем более нельзя просто весь файл заменить на новый: помимо проблем оформления и читабельности патча это ломает локализацию.
- баннер в верхней части диалога нужно перерисовать, увеличив его длину. На скриншоте выше явно видно, что баннер растянут.
ppps: замечания ревью были исправлены и патч был влит в исходники LibreOffice 27 июня 2019 года. Теперь выявилась другая проблема: диалог доступен на куче языков, а я проверял внешний вид только на английском. Это в принципе нормально, я на это и рассчитывал изначально, что патч будет принят, а затем "возможно" будут какие-то замечания к внешнему виду текста в различных языках. Например, в русском обрезаются палочки и хвостики букв "у", "р", "ф" и тому подобное в некоторых строках. Завтра будет доступен свежий ежедневный билд и каждый сможет поглядеть, как стал выглядеть диалог инсталлера на английском. Исправление проблем с обрезанием текста будем делать после выхода 1 альфа версии 6.4, чтобы люди из разных стран могли протестировать на родных языках инсталлер.

Удаление поддержки тем Firefox из LibreOffice 6.3

В связи с тем, что Mozilla изменили свое API для доступа к темам Firefox, было принято решение удалить поддержку тем Firefox в LibreOffice 6.3. В дальнейшем будут реализованы собственные темы LibreOffice, возможно даже с некой настройкой или возможностью создания тем прямо в LibreOffice (там сложного-то ничего нет).

Разработка LibreOffice. Изменение имён стилей маркированных списков в боковой панели Writer

В своё время Yousuf Philips изменил в LibreOffice Writer стили нумерованных списков и заодно изменил на более понятные имена для стилей нумерованных списков, которые показываются в боковой панели Writer. Имена нумерованных стилей стали вида "Numbering 123", "Numbering abc", "Numbering IVX". То есть теперь явно видно, какой тип нумерации будет использован при выборе стиля. 

Однако стили маркированных списков остались без изменений и со стандартными именами типа "List 1", "List 2", и так далее по пятый. В русской локализации был перевод "Маркированный список 1", "Маркированный список 2", который все равно не позволял видеть сразу, какой именно маркер будет использован при выборе стиля.

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

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

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

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

Изменение войдет в будущий выпуск LibreOffice 6.3.

Update: к сожалению в реализации этой фичи выявились проблемы. LibreOffice берет символ Unicode (который справа от слова Bullet) вовсе не обязательно из шрифта OpenSymbol, а по какой-то другой логике и, в результате, может оказаться так, что в используемом для GUI шрифте данный символ отсутствует и получается элемент маркированного списка без показа самомго маркера.
Мнения по поводу того, оставлять ли такую текущую реализацию, доработать механизм или откатить изменения пока не принято. Из того, что я услышал от разработчиков, я понял, что сам не осилю доработать механизм. Посмотрим.

Разработка LibreOffice. Локализация интерфейса пользователя и справки

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

Заходим на сайт https://translations.documentfoundation.org/

Нажимаем большую зелёную кнопку "Войти" и видим:

Если аккаунт уже есть, то вводим логин/пароль и входим, если нет, то жмём ссылку "Зарегистрироваться, как новый пользователь", появится следующее окно:

в котором нужно придумать себе логин (Имя пользователя), ввести адрес вашей работающей электронной почты, задать пароль, повторить пароль, установить галочку/флажок у опции (метка которой почему-то не локализована) "I agree to the privecy policy" и нажать кнопку "Зарегистрировать".

Далее вам покажут следующее окно (адрес почты конечно будет вашим):

Идем в почту, переходим по ссылке из полученного письма, чтобы подтвердить адрес почты и регистрацию.

Далее просто в первом окне вводим ваш логин и пароль и попадаем на собственно сайт:

Я зашел под своей учеткой, и у меня сразу выбран целевой язык "Russian". У вас язык может быть задан, как "Все языки". В этом случае щёлкните по этим словам и во всплывающем окне введите в единственное поле Russian и выберите его.

Обратите внимание на разноцветные строки с вполне говорящими названиями типа LibreOffice 6.2 - UI или LibreOffice 6.2 - Help. Это соответственно переводы интерфейса пользователя и справки. Числа справа по столбцам подписаны и это количество:

красное - критические (ошибки)

коричневое - предложения по переводам, которые ждут подтверждения от людей с правами подтверждать переводы

синее - не завершённые переводы (термины и предложения).

Справка сегодня находится просто в невменяемом состоянии. Кто захочет помочь с переводами - вери велкам, что называется.

На сегодня нас интересует перевод UI в версиях 6.2 и в master (это будущий 6.3 на сегодня).

В строке LibreOffice 6.2 - UI щёлкаем по числу на синем фоне "Не завершено" и попадаем непосредственно в интерфейс перевода:

По середине у вас будет большое поле для ввода перевода, над которым располагается непосредственно термин или фраза, которая перевода требует. Старайтесь переводить максимально понятно и максимально КОРОТКО.

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

Справа от поля для ввода перевода находятся две связанные кнопки "Зафиксировать"<->"Предложить". У вас будет доступна для работы только "Предложить", которую и нужно нажимать после ввода перевода. После этого фрагмент перейдет в коричневый статус "Предложения переводов", нажав на которые люди с правами смогут подтвердить или исправить ваш перевод. Так что не бойтесь ничего испортить, вам просто не дадут ;-)

После нажатия кнопки "Предложить" система автоматически предложит вам следующий требующий перевода термин/фразу.

Также в правом верхнем углу показывается число оставшихся фрагментов для перевода и стрелки возле них "Вверх" и "Вниз". Нажимая на стрелки, можно пропускать фрагменты, если не знаете, как перевести.

Вернуться к списку проектов можно, нажав на синюю ссылку "Вернуться к просмотру".
Обратите внимание, что пока названия emoji мы не локализуем! В левой части, если видите такое слово, то термин просто пропускайте.

Это собственно всё! Каждый может зайти и предложить свой перевод! Спасибо заранее всем, кто захочет сделать LibreOffice лучше.

ps: в принципе, даже если система будет показывать, что все возможные фрагменты переведены, LibreOffice всё равно может оказаться без каких-то переведённых терминов. Но, это уже, либо отсутствие ID у термина, либо сбой слияния перевода при подготовке билда. Это явно не проблемы самого перевода, но сообщить о таком всё равно надо.

Очередные метания разработчиков 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, при условии, что такая кнопка выделена.

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

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

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

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

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

Разработка 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.1

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

Ссылка на опрос по поводу нового виджета для вставки специальных символов в LibreOffice 6.1:

https://docs.google.com/forms/d/e/1FAIpQLSfVqGMXKzz4vjCzqzK2cZi2mBFk9qUFpkrIci5VeUilmBlRFw/viewform

Риббон в LibreOffice. Ситуация на апрель 2018

Давно я не делал обзор текущего состояния реализации ленточного интерфейса в LibreOffice

Примечание: Все картинки в статье из разрабатываемой сейчас версии LibreOffice Writer 6.1 с английским интерфейсом, потому что в ежедневные сборки для Линукс русский язык не добавляют.

Итак, разработчики реализовали наконец-то давно напрашивающееся изменение в управлении типами интерфейса. Сейчас переключатель классика/лента выполнен в ОДНОМ пункте меню View > User Interface, в подменю которого можно СРАЗУ выбрать нужный тип ГУИ (полный список доступен только, если активированы экспериментальные возможности в диалоге Tools > Options):

Standard Toolbar - это классический ГУИ с парой панелей инструментов в верхней части экрана. Тут ничего нового нет и быть не может. Вот он:

Single Toolbar - это также классический ГУИ, но с одной панелью в верхней части экрана, в которой сконцентрированы самые часто используемые инструменты по мнению дизайнеров LibreOffice (это тоже уже давно доступный вариант):

Sidebar - это боковая панель (по умолчанию находится в правой части окна LibreOffice). Зачем они вынесли активацию Боковой панели именно в это меню - непонятно. Этот же пункт есть в View > Sidebar, наравне со Status Bar например, где ему и самое место.

Contextual groups - это первый из уже ШЕСТИ вариантов ленточного ГУИ в LibreOffice. В настоящее время им никто не занимается, моё мнение, что это нужно просто удалить. В настоящее время этот вариант выглядит вот так:

Очевидно, что эта штука ест много места по вертикали.

Contextual Single - это вариант предыдущего типа ГУИ, просто менее толстый:

По сути напоминает вариант с Single Toolbar, только называется по другому и немного реагирует на контекст выделения в документе.

Tabbed - это вариант ленты с вкладками, полная пародия на Риббон в MS Office. Сама идея, что надо по вкладкам щелкать, чтобы найти не очевидно спрятанную кем-то умным опцию, она ужасна по-моему. Этот вариант выглядит вот так:

Tabbed Compact - это тоже лента с вкладками, только менее толстая по вертикали:

Groupedbar - это лента, но без вкладок и без строки главного меню в верхней части. Также реагирует соответствующим изменением набора доступных инструментов на контекст вроде таблиц, картинок или врезок:

В принципе, из всех лентоподобных вариантов, мне лично нравится именно этот. Однако, он страдает детскими болезнями, типа расположенных в разных уровнях элементах выпадающих списков меню или разного размера шрифта в одинаковых элементах управления. Также, если установить курсор в таблицу, то полностью лента перестает помещаться в 1366 px по горизонтали. Почему-то этот вариант упорно толкают к снятию экспериментального статуса уже в релизе 6.1 этим летом, чтобы обычные пользователи смогли оценить всю его прелесть без дополнительных движений.

Groupedbar Compact - это последний вариант ленты-риббона. Из названия ясно, что это опять же менее толстый вариант предыдущей итерации:

Обратите внимание на слово Rows. Видите насколько оно не в одной линии с остальными пунктами "меню"? И значки в этой секции больше, чем аналогичные. Я специально создал таблицу и установил туда курсор, чтбы показать "интерактивность" этого варианта риббона.

На сегодня эти риббоны в разной степени готовности доступны только для трех модулей LibreOffice: Writer, Calc и Impress.

Есть вроде бы желание у разработчиков реализовать вариант Groupedbar для Draw. Но скорее всего этого в 6.1 не случится.

Кстати, я видел дискуссию между разработчиками на тему того, что куча недопиленных вариантов ГУИ а-ля риббон плохо влияет на карму самого LibreOffice и надо бы их количество сократить, а качество повысить.
Ах да, возможности настроить риббоны под себя всё ещё нет. Только крайне муторная ручная правка .ui файла в Glade.

Тема значков Office 2013 в виде расширения для LibreOffice 6.0

Я писал как-то про тему значков Office 2013 для LibreOffice. Теперь можно установить её крайне быстро просто, так как автор сделал из неё расширение.

Вот ссылка на сайт автора https://www.deviantart.com/art/Office-2013-theme-for-LibreOffice-512127527

Вот прямая ссылка на скачивание расширения от автора https://www.deviantart.com/users/outgoing?https://www.dropbox.com/s/fuoe9k7k3jqjzj7/Office2013-theme.oxt?dl=0

Я скачал расширение к себе в расшаренный каталог https://drive.google.com/open?id=0B18cIZiP-Jo-dEdGSTFoZWlMQmc, качать файл Office2013-theme.oxt

Установить его можно, как используя диалог Сервис-Управление расширениями, так и просто запустив его на исполнение из диспетчера файлов в вашей ОС.

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

Новое в LibreOffice 6.1. Вставка номера страницы из выпадающего меню колонтитула

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

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

Улучшения в настройке списков в Impress

Товарищи из дизайн-тим провели натурный опыт на пользователях LibreOffice из славного французского города Нант. Они пытались выяснить, а что же в основном мешает работать с маркированными и нумерованными списками в Impress. Итак:

Уровни списка.

Первой задачей для пользователей было создание списка маркеров и изменение уровня некоторых элементов в соответствии с заданным примером. Все субъекты опыта использовали клавишу табуляции [Tab], чтобы увеличить уровень, но некоторые не смогли «откатить» эту операцию, так как клавиша [Backspace] удаляет маркер, а не «вставленнцю табуляцию» (Microsoft Powerpoint работает точно так же, как Impress, и никогда не понижает уровень списка при нажатии на [Backspace]). Предлагаемый сейчас способ управления уровнем списка - используя четыре кнопки со стрелками на боковой панели или на панели инструментов, а также через контекстное меню.

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

Есть не обозначенная этими пользователями, но обнаруженная разработчиками при пристальном рассмотрении проблема - несогласованность между Impress и Writer в сочетаниях клавиш  (уровень может быть скорректирован по [Tab] / [Ctrl] + [Tab], как в Impress, так и в Writer, но только в Impress есть сочетание клавиш [Alt] + [Shift] + [Left] / [Right] в качестве основного сочетания клавиш), а функция "Увеличить отступ", доступная и в Impress, изменяет уровень списка только в Writer.
Хотя существует множество способов улучшить удобство использования, разработчики хотят для начала обеспечить последовательность в пользовательском интерфейсе. Поэтому они видят следующие пути для этого:

• Унификация сочетаний клавиш между Impress и Writer - добавить сочетания [Alt] + [Shift] + [Left/Right/Down/Up] в Writer.

• Одинаковая функциональность отступов:

• управление уровнем списка через увеличение/уменьшение отступа абзаца в Writer следует удалить;
• отступ абзаца должен быть ограничен интервалом между маркером (или нумерацией) и текстом элемента списка, что означает
• кнопки для увеличения / уменьшения отступа абзаца должны заработать и в Impress (сегодня нажатие на кнопки эффекта не дает)

• Улучшение пользовательского интерфейса:

• лучшая организация элементов интерфейса в боковой панели, как показано на рисунке ниже, с выделенным сектором для списков и значками, тесно связанными со стилем списка с позиционными подсказками

Изменение стиля списка.

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

Все участники сначала попробовали кнопку «Маркированный список» на боковой панели, хотя это влияет только на текущее выделение. То же самое верно для диалога Маркеры и Нумерация, что было второй идеей во время теста. Участники в конечном итоге использовали копирование форматирования для выполнения задачи, кроме тех, кто был знаком со стилями и перешел в диалог «Редактировать стили». В этом диалоговом окне отсутствует ключ, по которому он работает, т.е. выделение, слайд, презентация. Кроме того, только на вкладке «Настройка» показано, на каком уровне работает модификация (обычно все соответственно «1-10»). Большая часть заблуждения исходит из того факта, что Impress имеет только один стиль списка, который определен в мастер-слайде.

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

Хотя текущий диалог обеспечивает быстрый доступ к нескольким предопределенным маркерам, нумерации или символам, неясно, к чему применяются эти пресеты. Разработчики предлагают удалить вкладки и разместить все возможные элементы управления на одной странице. Кроме того, добавляется переключатель "Область применения" (на рисунке это "Scope"), и пользователи могут решить, относится ли изменение к текущему выделению или ко всему слайду. На случай, если изменение должно примениться ко всем слайдам, использующим текущий мастер-слайд, добавлена кнопка «Применить к мастер-стилю» (Apply to Master Style). При запуске этого диалогового окна из мастер-слайда, так как это означает по сути определение стиля, функция "Область применения" должна быть отключена.

В дополнение к этому переработанному диалоговому окну, из боковой панели должен быть возможен быстрый доступ к стилю маркера (или нумерации). Это можно сделать с помощью дополнительного выпадающего списка. На рисунке ниже показана часть боковой панели  с доступом к вариантам объекта. Модификация будет применяться только к выделению.

Копирование / вставка элементов списка.

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

На рисунке ниже показано текущее и предполагаемое поведение. Прямой выбор текста возможен только в синей области. Нажатие на маркер, показанное красным цветом, работает как выбор фрейма, аналогичный области сверху, и заканчивается перемещением текстового поля вместо выбора части текста. Такое поведение указывается изменением формы курсора мыши на тип «перемещение» (в форме руки или четырехсторонней стрелки, в зависимости от настроек ОС). Предложение заключается в том, чтобы добавить заштрихованную область в принятое пространство для редактирования, в идеале, включая сам маркер.

После копирования текста его стиль не используется во время операции вставки. На самом деле никакие свойства не принимаются вообще. Например, если в документе A есть красные маркеры, определенные на мастер-слайде, а в документе B - синие маркеры, вставка A в B заканчивается черными маркерами. Эта проблема должна быть решена. Пользователь, скорее всего, ожидает полного стиля оригинала (применяется как прямое форматирование, если отличается мастер), но могут быть ситуации, когда противоположное значение истинно и должен использоваться целевой стиль. Решение может состоять в том, чтобы иметь специальную опцию вставки вида «вставка с исходным стилем» (по умолчанию для просто вставки), «вставить с целевым стилем» и «вставить без стиля».

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

Update from 2019: разработчики из Collabora начали реализовывать эту идею, планируется, что к выпуску LibreOffice 6.3 это будет выполнено. И вишенка: эту работу им оплатила администрация г.Нант!