вторник, 29 января 2019 г.

Разработка 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 у термина, либо сбой слияния перевода при подготовке билда. Это явно не проблемы самого перевода, но сообщить о таком всё равно надо.

суббота, 12 января 2019 г.

LibreOffice принимает теперь донаты и в криптовалюте

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

пятница, 4 января 2019 г.

Отчёт LibreOffice QA за декабрь 2018 года

TDF QA инженер Xisco Fauli опубликовал ежемесячный отчет о работе QA в проекте LibreOffice за декабрь 2018 года. По ссылке много разной информации и цифр.
Я обращу ваше внимание на две весьма показательные цифры из всего отчёта:
Подано отчетов об ошибках в декабре - 560.
Исправлено ошибок в декабре - 150.
Я не буду искать и вникать в то, насколько критичные ошибки были поданы в декабре и насколько критичные ошибки были исправлены в декабре. Вдумайтесь только в их количественное соотношение! Более чем в 3,5 раза ошибок новых заведено, чем было исправлено. И такое соотношение оно не только в декабре было. Оно ежемесячно сохраняется.
Это говорит об очень простой вещи. Проекту не хватает кодеров. Причем кодеров любого уровня и с самыми разными талантами.
Так что, если вы используете LibreOffice дома (абсолютно бесплатно) или на работе (опять же бесплатно, по своей воле или вам его навязал работодатель, который его с 99% вероятностью не купил), то вы легко сможете отблагодарить проект:
Персонально вы - можете найти программиста среди своих друзей или на просторах интернета, который за бутылку пива, хороший кофе, просто спасибо или некое вознаграждение исправит пару ошибок в LibreOffice.
Ваш работодатель - может сделать абсолютно то же самое. А может завести постоянную хорошую практику - платить какие-то деньги штатному/наемному программисту за исправление ошибок в LibreOffice, которые мешают именно его работникам.
О том, как зайти в проект и начать исправлять ошибки написано вот тут https://wiki.documentfoundation.org/Development и здесь https://wiki.documentfoundation.org/Development/GetInvolved

среда, 2 января 2019 г.

Макросы на Python в LibreOffice

Не все знают, что в LibreOffice можно использовать Python для написания макросов вместо Basic. Преимуществом будет в разы бОльшая производительность макроса. Недостатком - невозможность нормального написания и отладки макроса в IDE, встроенной в LibreOffice.
Самое первое, что нужно сделать, если вы захотите использовать Python для написания своих макросов (помимо знания самого Python'a) - это установить расширение APSO для возможности нормально управлять макросами, написанными на Python.
Второе - осилить вот эти статьи (на английском, к сожалению) и все ссылки с них на другие статьи: https://wiki.documentfoundation.org/Macros/Design_Guide, https://wiki.openoffice.org/wiki/Python.
Ах да, учитывайте, что LibreOffice таскает в своей поставке свой Python, уж не знаю какой версии. Однако, есть возможность использовать и внешний Python. Другое дело, что в этом случае будет возможность напороться на то, что ваш макрос на другом компьютере работать не будет из-за несовместимостей в версиях Python (я про 2.7 vs. 3.x).
По-хорошему, следовало бы развивать эту замечательную возможность в LibreOffice, начиная от приведения во вменяемый вид диалогов управления и организации макросов и внедрением в базовую поставку какой-нить простенькой IDE для Python, и заканчивая написанием полного хорошего руководства по написанию макросов на Python. Однако, к сожалению и как всегда, этим просто некому заниматься =(.
Update: иностранные товарищи подсказали мне, что внезапно они пишут справку по макросам на Python. Вот ссылка https://help.libreoffice.org/6.3/en-US/text/sbasic/python/main0000.html.

пятница, 28 декабря 2018 г.

QA в Libreoffice

Сокращение QA означает quality assurance, дословно - гарантия качества.
Команда QA - это часть сообщества LibreOffice, которая занимается тестированием LibreOffice. Обо всех ошибках пишутся отчеты на специальный ресурс проекта
Внимание! Если вы нашли ошибку в LibreOffice и не сообщили о ней в багзиллу проекта, то разработчики никогда не узнают о проблеме и никогда ошибку не исправят.
В связи с тем, что LibreOffice проект огромный и разносторонний, то и количество различных существующих ошибок в нём также огромное. По вот такой ссылке на сегодня выдается 13066 ошибок в статусе NEW (то есть ошибка в свое время была подтверждена и возможно до сих пор воспроизводится).
Примечание: также можно найти информацию об ошибках в статусе UNCONFIRMED (не подтвержденные). Таких ошибок ориентировочно около 500 штук всего, включая старинные отчеты, по которым либо нет единого мнения у людей, которые ошибки проверяли или имеются разные результаты, полученные в процессе проверки.
Вдумайтесь в цифру! 13 тысяч ошибок! Это действительно огромная цифра. Для обработки такого количества информации нужно такое же огромное количество человек.
И на сегодня перед командой QA в LibreOffice стоят такие первоочередные задачи, как:
1. Проверять ежедневно появляющиеся сообщения об ошибках на достоверность и повторяемость. Часто необходимо вытягивать информацию из пользователя, который прислал отчет об ошибке, задавая ему наводящие вопросы. Также желательно сразу сортировать ошибки, заполняя соответствующие поля. Ещё более желательно проверять новые воспроизводимые ошибки на предмет регрессии. Например, в LibreOffice 6.2 ошибка есть, а в 6.1 её не было. И тогда нужно выполнить операцию bibisect для того, чтобы определить коммит и разработчика, который регрессию в код внёс.
2. Самостоятельно тестировать ежедневные, альфа, бета и RC версии LibreOffice на предмет любых ошибок и писать на них отчеты в багзиллу проекта.
3. Перепроверять старые ошибки, по которым более одного года не было никаких сообщений. Это нужно для актуализации сведений об ошибке. Также бывает, что ошибка в последних версиях LibreOffice не воспроизводится и тогда её необходимо закрыть с соответствующим сообщением и указанием версии LibreOffice, в которой была проведена проверка. Список таких ошибок, кандидатов на перепроверку есть в вики проекта.
4. Каталогизировать ошибки по так называемым МЕТА. МЕТА - это по сути определенная категория ошибок, аналог каталога в файловой системе, куда складывают файлы по одной тематике. Все существующие МЕТА перечислены в вики проекта. Например, есть большое количество МЕТА для ошибок, связанных с форматом DOCX:
Разработчикам по таким МЕТА удобнее следить за ошибками по теме, в которой они разбираются.
Полная проверка одной ошибки, включая регрессионное тестирование в предыдущих версиях, и, если нужно, bibisect, может занимать от часа времени. Такие проверки в команде QA сейчас делают всего несколько человек. Огромное количество ошибок в багзилле просто подтверждаются, без какого-либо регрессионного тестирования.
Поэтому проекту LibreOffice нужны волонтёры, готовые потратить пару часов своего времени на тестирование ошибок в LibreOffice. Любая помощь приветствуется.
Команда QA всегда готова помочь вам. Есть IRC канал #libreoffice-qa в сети Freenode.net (нужна регистрация в связи со спам атаками в последнее время, ссылка для доступа через браузер https://webchat.freenode.net/?channels=#libreoffice-qa) и есть также Телеграм канал, связанный с IRC чатом в единое пространство, @libreoffice_qa (ссылка для доступа через браузер https://web.tlgrm.eu/#/im?p=@LibreOffice_QA). Каналы англоязычные. Если у вас проблемы с английским, то можете попросить помощи и на русском IRC канале https://webchat.freenode.net/?channels=#libreoffice-ru или Телеграм канале https://web.tlgrm.eu/#/im?p=@libreofficeru

воскресенье, 23 декабря 2018 г.

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

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

среда, 19 декабря 2018 г.

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

Товарищи из дизайн-тимы запилили опрос по поводу сохранения функционала библиографии в LibreOffice.
Один единственный вопрос звучит так: "Что вы думаете по поводу удаления функционала библиографии из LibreOffice?"
Ответов два:
1. Да, удалить
2. Нет, погодите...

Ссылка на статью https://design.blog.documentfoundation.org/2018/12/19/save-the-bibliography/ , опрос конце статьи на сером поле. 
Голосуй или проиграешь! Или как там было в истории...

пятница, 7 декабря 2018 г.

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

По умолчанию в новом документе типа электронная таблица Libreoffice Calc создавал верхний и нижний колонтитулы, содержащие некоторые данные. На мой взгляд (и не только на мой) такое поведение по умолчанию абсолютно не нужно, новая электронная таблица должна быть пустая абсолютно. Если мне нужны будут колонтитулы, я их сам добавлю. В новом текстовом документе Writer ведь нету по умолчанию включенных колонтитулов, почему же они есть в Calc?
Вот соответствующая ошибка в багзилле.
Наконец, в бета выпуске LibreOffice 6.2 колонтитулы были отключены для новой электронной таблицы. Победа, я считаю.
Однако оказалось не все так просто. В меню Calc есть такой пункт, как Вставка->Колонтитулы, который открывает одноимённый диалог (это ещё версия 6.1):
Обратите внимание, мы как бы! вставляем колонтитул, однако по сути колонтитул УЖЕ вставлен и УЖЕ содержит данные (в данном случае поле номера листа "Лист1"). В версии 6.1 этот пункт меню всегда активен по умолчанию, поскольку и колонтитулы включены по умолчанию.
Теперь, после отключения колонтитулов в 6.2, этот пункт меню по умолчанию не активен, что вызывает некий когнитивный диссонанс. Пользователь хочет ВСТАВИТЬ колонтитулы, а пункт меню, вполне логично расположенный в меню Вставка, не работает. Бага же! И у этой баги тоже есть свой номер в багзилле. Вторая бага явно вытекает из первой, её надо бы до релиза исправить.
По хорошему было и есть несколько способов решить данную "проблему" (на мой взгляд):
1. Просто удалить пункт меню Вставка->Колонтитулы и включать колонтитулы только в диалоге Формат->Страница, как это возможно и сейчас.
2. Сделать так, чтобы при выборе пункта меню Вставка->Колонтитулы открывался диалог Формат->Страница на нужной вкладке, где даже сейчас явно видно, КАК включить колонтитул.
Можно было хорошенько подумать, и придумать совместно еще какой-то вариант, время-то позволяет, нерабочий пункт меню, при наличии работающей альтернативы - это не такая супер важная проблема.
Знаете, что разработчики сделали в итоге? Просто откатили патч, который отключал колонтитулы. Выбрали самый бредовый вариант, который оставил бОльшую проблему на мой взгляд не решённой.
Беда сообщества LibreOffice, что подобного рода вопросы не выносятся на какой-нибудь общедоступный ВСЕМ ресурс, где можно было бы собрать мнения и многих разработчиков LibreOffice и простых пользователей, и кого-то из команды документации. А сейчас данную "проблему" со второй багой обсудили между собой ДВА человека во внутреннем списке рассылки команды дизайна, один из которых, как мне показалось, просто плюнул и пошел по пути наименьшего сопротивления, просто всё вернул в то состояние, какое было до его правки.
Может быть пора что-то поменять в плане подхода к обсуждению изменений в проекте?
PS: а вообще есть обходной путь, чтобы иметь новый файл Calc без колонтитулов - это конечно же сделать шаблоном по умолчанию новый пустой документ с отключенными колонтитулами.

пятница, 30 ноября 2018 г.

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

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

понедельник, 19 ноября 2018 г.

Выпуск LibreOffice 6.2 beta 1

The Document Foundation объявил о доступности для тестирования LibreOffice 6.2 beta 1. Скачать можно по ссылке https://dev-builds.libreoffice.org/pre-releases/ для операционных систем Windows, Linux, macOS в 32- и 64-битных версиях.
Обо всех найденных ошибках нужно сообщать разработчикам в багзиллу проекта .
Список исправленных ошибок и нового функционала доступен по ссылке https://dev-builds.libreoffice.org/pre-releases/src/bugs-changelog-libreoffice-6-2-release-6.2.0.0.beta1.log