суббота, 28 октября 2017 г.

Улучшения в настройке списков в 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 это будет выполнено. И вишенка: эту работу им оплатила администрация г.Нант!

понедельник, 16 октября 2017 г.

Статистика коммитов в код LibreOffice за период с августа 2016 по сентябрь 2017

Недавно в Риме прошла конференция разработчиков LibreOffice. И сейчас потихоньку разработчики начинают выкладывать свои презентации с этой конференции. В одной из презентаций одного из разработчиков, Michael Meeks'a, которая вообще-то посвящена компании Collabora и её вкладу в развитие LibreOffice, я увидел слайд с небольшой статистикой по коммитам за прошедший год, с августа 2016 по сентябрь 2017:
Итак: всего в проект внесено почти 19 тысяч коммитов за год, а это по полторы тысячи коммитов в месяц, по 50 в день! А дальше мы видим интересную картинку под названием "Кто разрабатывает ОпенСорц? Альтруисты? Студенты? Не думаю". По 33% от общего числа коммитов внесли работники из Collabora и Red Hat. Работники, которым платят зарплату за то, что они пишут код (и правят баги) LibreOffice. И только 27% кода (считая в коммитах) за прошедший год внесено волонтерами / свободными кодерами / теми самыми альтруистами / студентами (части из которых кстати Google заплатила денег по программе GSoC). Ну и есть некоторое количество кода, написанное людьми из TDF, CiB, Cannonical, SuSe и прочая.
Я к чему это всё написал. Не подумайте, что я идеалист, и верю, что человек может питаться святым духом и делать всем в мире добро просто потому, что он себе это может позволить. Я наоборот рад видеть, что людям за развитие опенсорц проекта платят деньги, а сам проект с открытым исходным кодом служит основой для ведения бизнеса отнюдь не маленьких софтверных компаний. 
Ну и конечно же было бы очень круто увидеть в этой статистике увеличение количества коммитов от платных разработчиков / новых организаций, а еще лучше от российских платных разработчиков / организаций.

вторник, 10 октября 2017 г.

Выпуск LibreOffice 5.3.7.1

Разработчики выпустили первый релиз-кандидат последней версии LibreOffice в ветке 5.3. - 5.3.7.1. Судя по отчету, исправлено большое количество реальных и потенциальных фатальных ошибок, приводящих к падению программы. А также, хоть явно про это и не написано, исправлена такая неприятная штука, как мерцание главного меню при отключенном OpenGL в ОС Windows, которая появилась где-то в версии 5.3.2. Для веток 5.4 и 6.0 это исправление также уже внесено в код.
Скачать версию 5.3.7.1 можно как всегда с сервера с ежедневными сборками http://dev-builds.libreoffice.org/pre-releases/, доступны сборки под операционные системы Linux, Windows, macOS в 32-битной и 64-битной итерациях.

воскресенье, 8 октября 2017 г.

Фатальная ошибка LibreOffice в Linux, связанная с JAVA

Наткнулся на аварийное завершение работы LibreOffice 5.4 и 6.0 в Linux. Причем офис просто закрывается молча без никаких сообщений об ошибках. Вы просто наводите курсор мыши на пункт меню Файл > Отправить и офис канает в небытие.
Связано это, как оказалось, с JAVA, причем с его открытой итерацией в виде openjdk. С JAVA от Oracle таких проблем вроде бы нет.
Разработчики о проблеме знают, в багзилле предлагается даже какой-то костыль попробовать, для обхода проблемы. Однако я предлагаю, во избежание недоразумений с потерей документов, просто отключить использование JAVA в диалоге "Параметры LibreOffice", который открывается из меню Сервис > Параметры, далее LibreOffice > Расширенные возможности, справа снимаем галочку у пункта "Использовать виртуальную машину JAVA".
Если использование JAVA в LibreOffice по любым причинам необходимо, то удалите openjdk и установите версию от Oracle, скачав ее отсюда http://www.oracle.com/technetwork/java/javase/downloads/jre9-downloads-3848532.html правда версии, доступные для Linux, только 64-битные (мода такая пошла в последнее время).
Update: по ссылке из комментария Майка написано, что проблема затрагивает 32-битные системы (и офис соответственно тоже 32 битный), возможно для 64-битных систем такой проблемы нет, мне негде проверить, у меня все линуксы 32 битные.

четверг, 5 октября 2017 г.

LibreOffice 6.0 и Microsoft Visual C++ 2015 Redistributable

Дожили. Раньше при установке дистрибутив LibreOffice сам устанавливал в Windows нужную ему версию Microsoft Visual C++ Redistributable. Начиная с версии LibreOffice 6.0 эту библиотеку от MS нужно будет устанавливать отдельно, скачав ее с сайта MS
Причем необходимо соблюсти соответствие битности библиотеки и LibreOffice 6.0. То есть, если виндовс 64-бит, а LibreOffice 32-бит, то библиотеку необходимо скачать на 32-бит, а не на 64!
Администраторы будут рады, простые пользователи тоже, я думаю, воспылают счастьем.
Кстати, в чем причина того, что нельзя сейчас в дистрибутив LibreOffice 6.0 засунуть микрософтовую библиотеку, я не уловил, надо бы спросить товарищей.
ps: спросил, оказывается это политика MS, не хотят они, чтобы люди юзали старый софт, а хотят всех и всеми методами подсадить на убогую виндовс 10.