среда, 13 декабря 2017 г.

Используем bibisect для поиска регрессий в коде LibreOffice

Регрессия в программном коде - это, когда после внесения изменений в программу, перестаёт работать то, что должно было продолжать работать. Например, разработчик написал код, добавляющий новую фичу (или исправляющий ошибку) в одном месте программы, а в другом месте программы из-за этого возникла другая ошибка, например стал неправильно отображаться формат ячейки или некорректно стало считаться некое вычисляемое значение, да и вообще все, что угодно.
Когда обнаруживается такая регрессия (в 5.3. работало, в 5.4 перестало работать или работает с ошибками), то для облегчения жизни кодерам (и для сокращения затрат их времени) люди из QA команды делают bibisecting.
Bibisect - это инструмент GIT, который используется для определения момента, когда ошибка впервые появилась в LibreOffice. То есть мы будем искать первый коммит, который привел к появлению некой ошибки.
В вики проекта есть страничка с описанием процесса для ОС Windows (на английском языке), но, читая ее, я сам не смог корректно проделать процедуру, потому что я дочитал до момента "установите git" и полез ставить официальный клиент git for windows.
ВНИМАНИЕ! Это было ОШИБКОЙ, потому что официальный клиент git for windows странно работает с репами bisect от LibreOffice, вываливаются ошибки, которые не дают выполнять bibisect!
А если бы я почитал чуть далее, то увидел бы, что ставить нужно cygwin!
Итак, начнем.
Шаг №1. Идем на сайт cygwin и качаем инсталлятор в любом виде для вашей битности Windows. В процессе установки будет предложено выбрать дополнительные пакеты, там есть фильтр, введите в нем git и просто установите все пакеты, которые оно вам покажет. Хотя Майк советовал выбрать просто сам git и всё.
Шаг №2. Для корректной работы LibreOffice в Windows необходимы библиотеки типа msvcrXXX.dll от Visual C++ Redistributable Packages for Visual Studio соответствующих версий. Скачать их можно с сайта MicroSoft. Если вы ищете ошибку в той версии офиса, которая уже установлена и работает, то скорее всего нужные библиотеки от MS уже установлены. Если решили проверить альфу или бету версию офиса, то нужно уточнить у разработчиков, какие библиотеки нужны и нужны ли вообще.
Шаг №3. Нужно скачать репозиторий бинарников для той версии офиса, в которой вы собираетесь искать регрессию. Создаем каталог, где будут храниться репы, например E:\libo. Запускаем cygwin, откроется окно терминала:

нужно перейти в наш рабочий каталог, выполнив команду cd /cygdrive/e/libo, приглашение командной строки изменится на соответствующий путь.
Далее выполняем команду git clone git://gerrit.libreoffice.org/bibisect-win32-5.4 (последние две цифры 5.4 означают номер версии LibreOffice, которую мы будем исследовать, если вы работаете с иной версией LibreOffice измените последние две цифры на нужную версию).
Ждем достаточно долгое время, пока сформируется архив на сервере, пока он выкачается к Вам на компьютер, а затем распакуется. В терминале все эти шаги будут отражаться.
Шаг №4. Начинаем собственно процесс поиска плохого коммита. Теоретически, нужно проделать 12 итераций (но по факту их может быть и на один или два больше!) - запусков сборок LibreOffice из репы-bisect, для каждой из которых нужно проверить наличие или отсутствие ошибки. Git сам в итоге выведет итоговый коммит, который приводит к сбою.
Сначала нужно убедиться, что мы используем нужную репу для поиска нашей регрессии. Мы проверим, что в последнем билде в данной ветке наша ошибка уже присутствует, а в первой еще нет. Для этого введите команду git checkout master, оно чуть подумает и выведет некий результат:
Если вывод в терминале будет раскрашен в красный цвет или будет пестрить фразами типа error, значит что-то пошло не так и нужно разбираться и просить помощи (как это делал я, когда мучался в начале процесса).
Следующая команда instdir/program/soffice запустит последнюю сборку (или билд - от английского build) LibreOffice в данной версии bisect-репозитория. Теперь в этом запущенном экземпляре LibreOffice вы делаете те действия, которые приводят к Вашей ошибке. Это нужно, чтобы убедиться, что ошибка УЖЕ есть в данном билде.
ВНИМАНИЕ! Часто бывает, что команда instdir/program/soffice не запускает LibreOffice и ничего не выводит в консоль. Дайте эту команду повторно. И только если и после второй попытки запуска LibreOffice не запустился, то можно говорить о том, что есть проблема либо с репозиторием, либо с git, либо что-то ещё.
ПРИМЕЧАНИЕ: если в последнем билде Вашей ошибки нет, это значит, что вы ищете регрессию не в той версии!
ПРИМЕЧАНИЕ: Вы должны искать только Вашу ошибку, на иные ошибки не обращайте внимание, за один цикл итераций (см.ниже) вы находите одну конкретную регрессию, которая привела именно к Вашей ошибке.
Убедились, что ошибка есть? Хорошо. Следующая команда будет git checkout oldest. И следом за ней сразу instdir/program/soffice. Эта последовательность запустит самый первый билд в версии. Выполните снова действия, которые приводят к Вашей ошибке. Убедитесь, что ошибки ЕЩЁ НЕТ! Если это так (в последнем билде есть ошибка, а в первом нет), то регрессия была внесена где-то между этими билдами. И мы начинаем самое главное.
Даем команду git bisect start master oldest.
И начинаем выполнять следующие действия раз за разом:
1. Вводим команду instdir/program/soffice - запускаем LibreOffice, проверяем на наличие ошибки, просто закрываем LibreOffice (либо, если ошибка критическая, то он сам закроется), и
2. - если ошибка есть, даем команду git bisect bad
    - если ошибки нет, даем команду git bisect good
3. Возвращаемся к пункту 1.
ВНИМАНИЕ! Обратите внимание на то, что ошибка обязательно должна проявиться при выполнении этих итераций хотя бы пару раз. Если у вас все время ответ будет good, это значит, что что-то пошло не так и нужно разбираться со знающими людьми! 
ВНИМАНИЕ! Может случится так, что LibreOffice не будет стартовать вовсе или с какими-то ошибками, это может означать, что билд был неработоспособный. В таком случае необходимо дать команду git bisect skip, и вернуться к пункту 1.
По мере выполнения этих шагов git будет писать нечто вроде "Осталось 11 (10, 9......2, 1) шагов до конца". Может писать и "Осталось 0 шагов до конца, но при этом не покажет финальный результат (о нем чуть ниже), поэтому процесс нужно продолжать до тех пор, пока git не покажет примерно такой вывод в консоли:
Это и есть наша регрессия. Это то, что мы должны показать в багзилле в качестве результата проведенной операции bibisecting'a.
ВНИМАНИЕ! Из этого вывода нам нужна строка source-hash и Author из НИЖНЕГО блока, в нашем случае Jan Holesovsky.
В багзиллу проекта помимо описания бага, Вы должны после bibisecting'a написать нечто вроде: "I bisected this bug. First bad commit 2d19e9bb07ccff3134f855812dddfda5c07b1fe4 from Jan Holesovsky." И в доказательсво привести вывод из вашей консоли git с результатом bibicting'a.

среда, 6 декабря 2017 г.

LibreOffice в государственной экспертизе Липецкой области

Зашёл по служебной надобности на сайт госэкспертизы Липецкой области http://lipeksp.ru/dokumenty/formy-zayavleniy/, и там в разделе документы увидел замечательное:
Хотелось бы надеяться, что документы в формате ODT созданы все же в LibreOffice. Да и советуют они использовать именно Либру.
Так что дело продвижения и использования свободного офисного пакета движется тихой сапой и в госорганах.

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

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

Очень часто мы создаем документы методом копипасты кусков текста из разных источников и последующего приведения этих кусков текста к единому виду и более или менее наличию смысла в тексте в общем.
С чем чаще всего мы сталкиваемся в этих кусках скопированного текста?
Более одного пробела идущего подряд, знаки разрыва строки вместо знака абзаца, абзацы разделены друг от друга пустыми абзацами, некие спецсимволы в большом количестве.
Перво наперво нужно включить отображение непечатаемых символов. Делается это путем нажатия на соответствующий значок на панели инструментов или нажать сочетание клавиш Ctrl + F10, или выбрать пункт меню Вид > непечатаемые символы.
Для устранения этих "проблем" в тексте нужно использовать диалог "Найти и заменить", вызываемый по нажатию сочетания клавиш Ctrl+H или из меню "Правка".
Замена множества знаков пробелов идущих подряд на один такой же знак:
1. В диалоге "Найти и заменить" в строку "Найти" вбиваем \s+
2. В строку "Заменить" вбиваем один пробел (он не будет обозначен каким-то специальным символом, его не будет видно, но по положению курсора в строке понятно, что пробел таки есть)
3. Далее раскрываем "Другие параметры" и отмечаем галочкой опцию "Регулярные выражения"
4. Нажимаем на кнопку "Заменить все". На этом всё.
Замена знака разрыва строки на знак абзаца (если этого не сделать, то, не смотря на перенос строки, Либра будет считать текст одним абзацем и применять стили соответственно, что может весьма удивить пользователя):
1. В диалоге "Найти и заменить" в строку "Найти" вбиваем \n
2. В строку "Заменить" также вбиваем \n
3. "Регулярные выражения" также должны быть активированы
4. Нажимаем на кнопку "Заменить все". На этом всё.
Замена нескольких подряд идущих знаков абзаца на один знак абзаца:
1. В диалоге "Найти и заменить" в строку "Найти" вбиваем ^$ (знак доллара!)
2. В строку "Заменить" ничего не вбиваем!
3. "Регулярные выражения" также должны быть активированы
4. Нажимаем на кнопку "Заменить все". На этом всё.

Вся эта информация есть на просторах интернета, этот пост я сделал больше для себя. 

четверг, 16 ноября 2017 г.

Crazy Idea для LibreOffice Online

Встречался в Москве с Майком. Хорошо пообщались, реально интересно и познавательно было. И под конец встречи зашел разговор про Коллабору и ее вклад в ЛибреОфис. И глядя на звезды я думал о проекте CODE. Это онлайн ЛибреОфис от Коллабора, который можно юзать совершенно свободно. Однако эта штука подразумевает использование выделенного сервера более или менее могучего, в зависимости от количества одновременно подключенных юзеров. Я подумал про общедоступный всему миру сервисе Google Docs, который тоже суть онлайн офис. Однако Google имеет огромные финансовые возможности и серверную инфраструктуру, чтобы обеспечить весь мир всегда доступным онлайн офисом. При этом огромным минусом сервиса является 146% гарантия того, что Google ваши документы читает. О конфиденциальности речь не идет ни разу. Коллабора такого сервиса людям во всем мире предложить не может, несравнимые весовые категории ну и непонятно, как монетизировать это именно Коллаборе. И у меня возникла идея, как "осчастливить" весь мир доступом к свободному от слежки онлайн офису на основе ЛибреОфиса. Сначала подумалось о некоей технологии на основе битторрент, исходя из идеи, что каждый юзер предоставлял бы каждому нуждающемуся юзеру ресурсы, но Майк раскритиковал ее на корню. Потом подумалось о такой штуке: люди по всему миру добровольно ставят себе некую серверную часть либры онлайн, и предоставляют ресурсы своего компа для запуска либры онлайн кем-то со стороны. Центральный сервер той же Коллабора занимается тем, что знает обо всех запущенных юзерами серверах либры онлайн и при запросе от юзера-пользователя направляет его на ближайший запущенный юзер-сервер с минимальным пингом относительно запрашивающего. Документы юзера держатель серверной части не должен видеть или контролировать ни при каких обстоятельствах. Если юзер-запрашивающий желает, то документы он может хранить в облачном сервисе, том же дропбоксе или я.диске, и конечно локально, при этом он должен явно сделать осознанный выбор.
Идея возникла спонтанно, в порядке бреда и живого общения. Есть 99,(9)% вероятность того, что на это даже смотреть не будут, но для памятки я это тут расписал. Это конечно всё можно еще больше конкретизировать, уточнить кучу рабочих моментов и т.д. и т.п.

суббота, 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. Основываясь на результатах теста удобства использования, разработчики предлагют переработать диалог свойств, как показано на одном из рисунков выше, ввести панель содержимого на боковую панель, чтобы текущее выделение в списке можно было быстро изменить, а также решить пару проблем в коде. Результат должен сделать рабочий процесс интуитивно понятным и легким.






понедельник, 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.