Разработчик, который перевел LibreOffice на Skia, ушел из проекта

Я абсолютно случайно сегодня узнал, что Luboš Luňák, разработчик LibreOffice из Collabora, ушел из этой самой Collabora и из проекта LibreOffice соответственно. А это был человек, который в одно лицо перевел LibreOffice на использование библиотеки рендеринга Skia. И соответственно все оставшиеся не решёнными баги, связанные со Skia в LibreOffice, так и останутся не решёнными.

Я, откровенно говоря, и не удивлен даже подобному. Это нормальная история, когда человек меняет работу. Не нормально только, что никто более в Skia внутренностях в проекте не разбирается. Даже обновить Skia на новую версию скорее всего никто не возьмется (у нас версия m103, текущая в апстриме - m111), а ведь там могли бы найтись возможно фиксы и для наших проблем.

Ну Skia - это одна сторона вопроса, прямо конкретная. А вторая сторона, более общая, что Luboš очень грамотный разработчик и его уход конечно скажется в принципе на проекте.

Сравнение таблиц в LibreOffice Writer, OnlyOffice Документ и Мой офис Текст

Я тут случайно наткнулся на интересное. Проверял актуальность одной ошибки в LibreOffice Writer, связанной с невозможностью удалить таблицы размером более, чем 25 х 1000 ячеек. То есть создать такую таблицу можно, а вот удалить нет, Writer зависает. 

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

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

Во-первых, ни ОО Документ, ни МО Текст не позволили создать таблицу в 25 столбцов и 1000 строк! ОО Документ дает ввести значение 1000 строк, но при создании таблицы оно сбрасывается на 100 и создаётся соответственно 100 строк и не более. МО Текст не позволяет ввести более двух знаков в диалоге для вставки таблиц, то есть максимум 99 строк. При этом оба позволяют добавить строки к таблице, используя механизм "Вставить строку ниже"! 

Во-вторых, ОО Документ умеет в вычисления в таблицах, предлагая точно такие же функции, как MS Word (и точно также не обновляет результат сам), а МО Текст - не умеет.

В-третьих, преобразовать таблицу в текст с разделителями ОО Документ - может, МО Текст - не может.

В-четвёртых, ОО Документ не умеет выравнивать текст по вертикали в ячейке таблицы (я долго искал опцию, не нашёл), а МО Текст - умеет это делать и значок этот там на видном месте, где ему и положено быть. 

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

Я, кстати, уже часто достаточно вижу в сети, что люди советуют, как замену MS Office, именно OnlyOffice, а не LibreOffice =(

Проблемы с производительностью LibreOffice Calc на примере функции VLOOKUP (ВПР)

Печальный пост будет. При разгребании баг репортов в нашей багзилле я наткнулся на проблему, связанную с очень большим временем (минуты!), которое тратит Кальк на вставку формулы, которая содержит функцию VLOOKUP (ВПР), в большое количество ячеек. Также Кальк весьма задумчив, если VLOOKUP имеет в качестве аргумента огромный диапазон для проверки значений (около 100000 записей), и мы заполняем несчастные сто строк такой формулой.

Вот один багрепорт, вот второй.

Ладно, Ноэль попытался что-то сделать с первым, однако общее улучшение не очень значительно, порядка 20% по времени всего. Проблема где-то глубоко внутри LibreOffice Calc, как я понял.

Ради интереса я проверил тот же самый случай в MS Excel. Результат - просто моментальная работа. Ладно, ОК, MS потратило миллиарды баксов на разработку и оптимизацию Excel. Говорят, там внутри давно уже все сделано, как база данных, именно для скорости работы.

Но есть и ещё один софт аналогичного функционала для работы с электронными таблицами и он OpenSourse. Я говорю про Gnumeric.

Я проверил те же проблемы с VLOOKUP (ВПР) в Gnumeric (по счастью он умеет открывать ODS файлы напрямую). Результат - моментальная работа! Не хуже, чем в MS Excel!

Я конечно этой ситуацией опечален. Наличие фундаментальных проблем с производительностью LibreOffice весьма удручает. А ещё больше удручает, что никто не берется туда залезть. Как всегда, нету квалфицированных, заинтересованных кодеров. Тут студент из GSoC программы не справится, тут нужен ОЧЕНЬ грамотный и опытный специалист в С++.

LibreOffice 7.0 от TDF внезапно стал Personal Edition

Полюбуйтесь на скриншот выше (он из текущей мастер ветки 7.1, но уверяю вас, что в 7.0 изменения уже внесены!). Особенно на фразу в диалоге "О программе" - "The Personal edition is suported by volunteers and intended for individual use"! Если первая часть фразы не вызывает никаких эмоций, то "предназначено для персонального использования" вызывает! Это фактический запрет ставить LibreOffice в любые организации. Никто из проверяющих никогда не полезет проверять, что там имел ввиду TDF, что написано в лицензии MPL 2.0. Они тупо ткнут в эту фразу носом любого и будут правы! Написано что? "Для персонального"! 

На мой вопрос за каким чёртом это было сделано, я ответа не получил. Говорят, что было обсуждение в рассылке маркетинга. Почему нет анонса об этом в блоге, например? Ну кто там читает ту рассылку?

Ну и у меня есть мысли свои по поводу того, за каким же все же чёртом это сделано. Смотрим внимательно, кто в основном пишет код в LibreOffice. Это сотрудники компаний Collabora, CiB, Red Hat, NSIZ и самого TDF. Эти компании вносят 85% кода в проект (я не говорю про дизайнерские изыски в виде нового оформления, значков и прочего барахла, я про тот код, который реализует функционал). И эти компании хотят зарабатывать денег на своём вкладе. Отсюда и эти изменения в ванильной сборке от TDF.

А следствием этого изменения будет то, что LibreOffice резко потеряет популярность, которая и так не высокая. Ну вот как я могу рекламировать LibreOffice друзьям, если они смогут его использовать только дома, и не смогут использовать на работе? Как я могу школьникам рассказывать о LibreOffice, если не будет никаких шансов за то, чтобы LibreOffice в школах появился теперь?

TDF, ты поехал куда-то не туда!

Ошибки в официальных гайдах

Я тут открыл для себя Америку, когда переводил первые две главы руководства пользователя LibreOffice Calc Guide 6.2 на русский язык.

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

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

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

Критичные для меня баги в LibreOffice. Шёл 2019 год

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

По традиции, давайте посмотрим, что произошло за этот год в плане исправления тех ошибок из 2017-2018 годов:

Сначала первый блок:

1. Мерцает интерфейс пользователя, когда по меню (и не только по меню) водишь мышкой, причем для видеокарт от Интел в среде ОС Windows это никак не лечится, а глаза мне дороги. - ИСПРАВЛЕНО в версии 6.3! Спасибо Miklos Vajna за это.

3. Рендеринг встроенных в документ изображений PNG также хромает, это не критично по сути, так как экспорт в ПДФ или печать выполняются с нормальным качеством, но смотреть на это убожество при работе в самом документе сил нет никаких. - в текущей разрабатываемой версии 6.4 я этого не вижу => исправлено.

6. До сих пор LibreOffice может выдать критическую ошибку в каком-то одном модуле и унести в ад ВСЕ открытые документы ВО ВСЕХ модулях. - не исправлено и не может быть исправлено! В прошлом посте было много слов на эту тему, они все актуальны =)

А теперь второй блок:

1. LibreOffice безумно медленно открывает таблицы в формате Excel с большим количеством комментариев в ячейках. Не то, чтобы это беда беда, но приятного мало. - были фиксы этого в 6.3, задержка осталась, но она стала вместо почти минуты всего 7-8 секунд => исправлено.

2. LibreOffice безумно медленно отрабатывает автофильтр в таблицах в формате Excel с большим количеством комментариев в ячейках. А вот это беда беда, потому что замедляет работу с таблицей. Автофильтр я дергаю в рабочей таблице достаточно часто. Это явно проблема фильтра импорта, потому что автофильтр на том же контенте с комментариями в формате ODS (родном) работает достаточно моментально. - в версии 6.3 автофильтр отрабатывает за 4-6 сек, приемлимо => исправлено.

3. Совсем не бага, но отсутствие функционала - не получилось найти вменяемый и производительный способ собирать данные из разных файлов и нескольких таблиц по 2000 строк и 20 столбцов в одну большую таблицу в отдельном файле. Для того же Excel нашлась надстройка Power Query, - эта совсем не бага будет висеть достаточно долго ещё, пока кто-нибудь не проплатит соответствующий функционал.
Ну смотрите, из 6 багов исправлено 4. А оставшиеся 2 - это неисправляемая в текущих реалиях фундаментальная особенность LibreOffice и запрос на доп.функционал. Неплохой результат, как по мне.
Однако, за 2019 год добавилась (ну вернее они и были всегда, просто я на них наткнулся) ещё проблем, связанных со сводными таблицами в формате XLSX. Их было штук пять, но большинство было исправлено (причем это было проплачено кем-то из заказчиков).
Но осталась всё же одна, которая мне мешает - LibreOffice Calc портит сводную таблицу в файле XLSX при сохранении в этот же формат - не сохраняется группировка в сводной. В текущем мастере это не исправлено.
В общем и целом это крайне положительный результат для персонально моего использования LibreOffice за год.

Нужно ли обучать пользователей работе в офисных пакетах?

Философский вопрос, правда? Я не хочу затрагивать тему, какому именно офисному пакету  из существующих сегодня надо (или не надо) учить, это больная тема, но вот сама идея необходимости обучения такой простой штуке, как офис. "Чего там сложного-то?" и "Чему там учить? Тексты набирать?". Знакомо?

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

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

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

Мое мнение, что обучать офису надо и начинать надо именно со школы, просто программу надо изменить.

А вот работодателям надо бы понять, что взрослого человека, работника, ТОЖЕ нужно обучать работе в офисном пакете, если работодателю внезапно потребовались какие-то вещи от работника, которые тот (пока) не знает. Или, например, специалист хороший, нужный, но в работе с офисом у него беда. И заказать работнику расширенный курс по электронным таблицам - это не ох и ах, "дополнительные расходы, пусть он сам учит, если хочет у нас работать", а нормальная практика.

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

А вы что думаете по этому поводу? Если будете писать комментарий, не поленитесь указать вашу область деятельности и "уровень компетенций" (рядовой сотрудник, нач.отдела, руководитель организации).

Простые правила создания хороших электронных таблиц

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

В качестве примера: большое количество объединенных ячеек, сложно составленные заголовки опять же с использованием объединения ячеек, таблицы, которые начинаются не с адреса А1, а с G45 (O_o), отформатированные насквозь строки и столбцы (когда нужно всего 10х10 ячеек), таблицы с данными не отделены от финальных сводных отчетов, задана группировка диапазонов, в которых находятся вообще не нужные данные, вместо удаления таких данных. Можно бесконечно продолжать.

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

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

Итак, хорошая электронная таблица/лист с исходными данными:

• Начинается с ячейки А1, а не с А340 или G43
• Имеет отдельный столбец для каждого типа данных (например, номер договора и дата договора должны быть в разных столбцах, дата начала работы и дата окончания работы - тоже в разных столбцах)
• Имеет в заголовке каждого столбца краткое и "говорящее" название
• Имеет шапку/заголовок таблицы в ОДНОЙ строке БЕЗ объединенных ячеек

А в целом файл с электронными таблицами имеет:

• Отдельные листы с исходными Данными и отдельные для Расчетов или/и Отчетов
• Формулы в ячейках, не содержащие внутри себя явно заданные значения (например, формула =А1+12 содержит константу 12)
• Комментарии для сложных формул, что именно и как именно считает формула, на отдельном листе
• Минимальную цветовую раскраску ячеек, а общая цветовая гамма должна позволять комфортно работать с данными. Это вопрос здоровья самого пользователя, заменять глаза людям на новые человечество ещё не научилось
• Условное форматирование только для тех ячеек, где действительно необходимо
• И не имеет сквозного форматирования целых строк или столбцов

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

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

По умолчанию в новом документе типа электронная таблица Libreoffice Calc создавал верхний и нижний колонтитулы, содержащие некоторые данные. На мой взгляд (и не только на мой) такое поведение по умолчанию абсолютно не нужно, новая электронная таблица должна быть пустая абсолютно. Если мне нужны будут колонтитулы, я их сам добавлю. В новом текстовом документе Writer ведь нету по умолчанию включенных колонтитулов, почему же они есть в Calc?

Вот соответствующая ошибка в багзилле.

Наконец, в бета выпуске LibreOffice 6.2 колонтитулы были отключены для новой электронной таблицы. Победа, я считаю.

Однако оказалось не все так просто. В меню Calc есть такой пункт, как Вставка->Колонтитулы, который открывает одноимённый диалог (это ещё версия 6.1):

Обратите внимание, мы как бы! вставляем колонтитул, однако по сути колонтитул УЖЕ вставлен и УЖЕ содержит данные (в данном случае поле номера листа "Лист1"). В версии 6.1 этот пункт меню всегда активен по умолчанию, поскольку и колонтитулы включены по умолчанию.

Теперь, после отключения колонтитулов в 6.2, этот пункт меню по умолчанию не активен, что вызывает некий когнитивный диссонанс. Пользователь хочет ВСТАВИТЬ колонтитулы, а пункт меню, вполне логично расположенный в меню Вставка, не работает. Бага же! И у этой баги тоже есть свой номер в багзилле. Вторая бага явно вытекает из первой, её надо бы до релиза исправить.

По хорошему было и есть несколько способов решить данную "проблему" (на мой взгляд):

1. Просто удалить пункт меню Вставка->Колонтитулы и включать колонтитулы только в диалоге Формат->Страница, как это возможно и сейчас.

2. Сделать так, чтобы при выборе пункта меню Вставка->Колонтитулы открывался диалог Формат->Страница на нужной вкладке, где даже сейчас явно видно, КАК включить колонтитул.

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

Знаете, что разработчики сделали в итоге? Просто откатили патч, который отключал колонтитулы. Выбрали самый бредовый вариант, который оставил бОльшую проблему на мой взгляд не решённой.

Беда сообщества LibreOffice, что подобного рода вопросы не выносятся на какой-нибудь общедоступный ВСЕМ ресурс, где можно было бы собрать мнения и многих разработчиков LibreOffice и простых пользователей, и кого-то из команды документации. А сейчас данную "проблему" со второй багой обсудили между собой ДВА человека во внутреннем списке рассылки команды дизайна, один из которых, как мне показалось, просто плюнул и пошел по пути наименьшего сопротивления, просто всё вернул в то состояние, какое было до его правки.

Может быть пора что-то поменять в плане подхода к обсуждению изменений в проекте?
PS: а вообще есть обходной путь, чтобы иметь новый файл Calc без колонтитулов - это конечно же сделать шаблоном по умолчанию новый пустой документ с отключенными колонтитулами.

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

Поглядел я на количество открытых багов в багзилле проекта, оценил количество активных разработчиков в gerrit, плюсом внимательно поглядел на общую фотографию с конференции в Тиране. И сделал печальный вывод: разработчиков, которые непосредственно пишут код в проект крайне мало и они все достаточно возрастные. И задумался я о преемственности поколений девелоперов, и пришла мне в голову мысль попробовать привлечь в проект студентов или начинающих программистов, которые возможно захотят поучаствовать в большом проекте с открытым исходным кодом, повысить свои навыки программирования, а также иметь несколько патчей в проекте, чтобы было что показать работодателю в не таком и далёком будущем.

Написал я объявление, нацеленное на развешивание в профильных ВУЗах (вот ссылка на ПДФ), которое попросил распространить среди студентов там, где мог (не так кстати и много мест, где я попробовал, надо расширять ареал распространения информации). В объявлении ищутся именно начинающие кодеры на С++ (это важно).

На сегодня прошло не так много времени с момента просьбы о размещении объявления, однако есть уже некоторые результаты:

1. Появилась пара человек, которые захотели поддерживать инфраструктуру проекта, пока в виде русскоязычного сайта ru.libreoffice.org, и будут разрабатывать/поддерживать новую версию сайта в дальнейшем.

2. Из этой пары человек один также будет пробовать писать код, начав с Easy hacks

3. Ещё один человек заинтересовался проектом LibreOffice, как ещё одним проектом, куда он может слать патчи на С++. Не факт, что он будет это делать, но хотя бы он теперь знает, что можно.

4. И ещё один товарищ написал мне отдельное письмо, что также желает писать код в проект, и как только настроит необходимое окружение, так появится на нашем IRC канале #libreoffice-ru в сети freenode.net (вот вэб-интерфейс для простоты вхождения в IRC, если кто-то заинтересовался).

И это собственно вовсе не те люди, на которых было ориентировано само объявление. Это люди, которые узнали о теме из просьбы разместить объявление. Это как в теоретической науке: исследуют нейтронные звезды, а в качестве практического применения люди получают технологию wi-fi. 

В общем и целом, я не уверен, что само объявление появится хоть в одном ВУЗе и что хоть один человек заинтересуется проектом, однако то, что хоть какой-то результат есть уже сейчас - это хорошо.

Если кто-то заинтересуется кодингом на С++ в проект LibreOffice - милости просим.

Если кто-то может распространить объявление среди студентов ИТ специальностей - буду благодарен.

Критичные для меня баги в LibreOffice. Шёл 2018 год

Я год назад писал мысли вслух на тему ошибок в LibreOffice, которые мешают мне использовать его в рабочем процессе (дома я его юзаю вполне успешно, мне хватает).

Так вот, изменилась ли ситуация с этими багами за год? Давайте поглядим (список из предыдущего поста):

1. Мерцает интерфейс пользователя, когда по меню водишь мышкой, причем для видеокарт от Интел в среде ОС Windows это никак не лечится, а глаза мне дороги. - в версии 6.1.1.2 присутствует до сих пор.

2. Рендеринг шрифтов в документе и в интерфейсе пользователя стал просто ужасный. - исправлено.

3. Рендеринг встроенных в документ изображений PNG также хромает, это не критично по сути, так как экспорт в ПДФ или печать выполняются с нормальным качеством, но смотреть на это убожество при работе в самом документе сил нет никаких. - это бага, связанная с OpenGL, и это не исправлено до сих пор.

4. В Calc не работает автофильтр при попытке фильтровать записи по дате. Это вообще нонсенс. По сути достаточно большой кусок реальной работы просто не может быть выполнен с использованием LibreOffice. - исправлено.

5. В текстовых документах Writer могут легко слететь стили, причем не все, а только некоторые и в произвольном порядке, а в больших документах, где стили обычно и надо использовать обязательно, это можно легко не заметить. По сути все преимущество стилей теряется для пользователя, поскольку необходимо постоянно глазами контролировать оформление текста и думать, а не слетели ли стили. - на сейчас такой бяки нет. 

6. До сих пор LibreOffice может выдать критическую ошибку в каком-то одном модуле и унести в ад ВСЕ открытые документы ВО ВСЕХ модулях. - не исправлено и не может быть исправлено! Ну давайте так, на мой взгляд критичных багов, приводящих к крашам в LibreOffice меньше не становится. В последнем чейнджлоге между 6.0 и 6.1 я насчитал 22 фикса крашей. Ну куда это годиться?! То, что в адъ уносятся ВСЕ документы - это архитектурная особенность LibreOffice - это мы выяснили ещё в прошлый раз, однако легче от этого не становится. Эта МЕГАошибка видимо будет присутствовать в LibreOffice всегда, пока будет ТАКОЕ количество крашей.

Итог: исправлена половина багов. Это достаточно хорошо.

А теперь немного новых бяк, которые меня огорчили за прошедший год в LibreOffice, и которые пока не исправлены:

1. LibreOffice безумно медленно открывает таблицы в формате Excel с большим количеством комментариев в ячейках. Не то, чтобы это беда беда, но приятного мало.

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

3. Совсем не бага, но отсутствие функционала - не получилось найти вменяемый и производительный способ собирать данные из разных файлов и нескольких таблиц по 2000 строк и 20 столбцов в одну большую таблицу в отдельном файле. Для того же Excel нашлась надстройка Power Query, которая может кучу разных вещей и при этом, для получения нужного результата, мне, простому юзеру-ламеру, не потребовалось изучать работу БД и программирование макросов.

Я имею надежду, что что-то улучшится в плане исправления багов за следующий год.

ps: кстати, в багзилле есть приоритезация по критичности багов. Однако оперативно реагируют по сути только на critical (а это либо краши, либо некая штука, которая делает работу с программой просто невозможной). А все остальные статусы равноценны, поскольку разработчики все равно правят только те баги, которые им интересны, или за которые им заплатили, не глядя на приоритет совсем.

Crazy Idea для LibreOffice Online

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

Идея возникла спонтанно, в порядке бреда и живого общения. Есть 99,(9)% вероятность того, что на это даже смотреть не будут, но для памятки я это тут расписал. Это конечно всё можно еще больше конкретизировать, уточнить кучу рабочих моментов и т.д. и т.п.

Критичные для меня баги в LibreOffice. Мысли вслух

Я тут внезапно осознал, почему я не использую на постоянной основе LibreOffice в работе, а юзаю только время от времени только дома. Причина - наличие ошибок (багов) в LibreOffice, которые для меня критичны. Их не так много (мы говорим о версии 5.4 для Windows):

1. Мерцает интерфейс пользователя, когда по менюшкам водишь мышкой, причем для видеокарт от Интел это никак не лечится, а глаза мне дороги.
2. Рендеринг шрифтов в документе и в интерфейсе пользователя стал просто ужасный.
3. Рендеринг встроенных в документ изображений PNG также хромает, это не критично по сути, так как экспорт в ПДФ или печать выполняются с нормальным качеством, но смотреть на это убожество при работе в самом документе сил нет никаких.
4. В Calc не работает автофильтр при попытке фильтровать записи по дате. Это вообще нонсенс. По сути достаточно большой кусок реальной работы просто не может быть выполнен с использованием LibreOffice.
5. В текстовых документах Writer могут легко слететь стили, причем не все, а только некоторые и в произвольном порядке, а в больших документах, где стили обычно и надо использовать обязательно, это можно легко не заметить. По сути все преимущество стилей теряется для пользователя, поскольку необходимо постоянно глазами контролировать оформление текста и думать, а не слетели ли стили.
6. До сих пор LibreOffice может выдать критическую ошибку в каком-то одном модуле и унести в ад ВСЕ открытые документы ВО ВСЕХ модулях.

Это реально печально.

Руководство пользователя LibreOffice Calc (PDF). Мысли о вечном

Наткнулся в сети на PDF файл "Краткое руководство по Calc" для версии LibreOffice 4.3. Собственно, на самом деле это кусок большой книги, которую мы в свое время обозвали "Краткое руководство пользователя", хотя на самом деле в оригинале нечто вроде "Руководство по быстрому старту". Не суть.

Так вот, этот самый PDF файл, он нужен и полезен, не смотря на ниже написанное, поскольку полноценного перевода LibreOffice Calc Guide на русский язык нет. Однако, при этом, по моему скромному мнению, есть пара НО:

Первое - текст в файле не является просто дословным или литературным переводом оригинального английского гайда. В тексте есть отсебятина от Дмитрия Мажарцева про систему общей работы над текстами в виде использования связки read the docs, Sphinx и GitHub. К предмету книги эта информация крайне мало относится, однако это была идея фикс Дмитрия и при создании этого PDF лишняя информация была туда добавлена, благо лицензия оригинала это позволяет.

А второе, которое мне не понравилось намного больше, - на обложке гордо сияет имя одного Дмитрия Мажарцева, хотя изначально перевод был сделан мной и был вклад от Леры Гончарука. Справедливости ради хочу заметить, что наши имена в тексте в разделе авторство фигурируют в разделе "Команда", однако, в таком случае, следовало бы на обложку вынести всю "команду" или не прописывать никого, как это сделано в официальных гайдах по LibreOffice - на обложке просто название и версия LibreOffice, а авторы перечислены по тексту самой книги.

Повторюсь ещё раз: я ни коим образом не против распространения этого конкретного файла, однако меня покоробило выпячивание одного члена "команды" на самое видное место в книге. Я считаю такое просто не этичным.

Разработчики LibreOffice опять чудят

В LibreOffice 5.3 реализовали стили таблиц Writer и сделали в Боковой панели отдельный раздел для быстрого и удобного управления ими. Однако, при попытке изменить стиль, используя контекстное меню в Боковой панели, LibreOffice падает намертво, унося в преисподнюю все открытые документы. В багзилле есть соответствующий баг на эту тему, однако разработчики видимо хотели или заглушку вставить, или еще что-то сделать, поскольку функция создания и редактирования стиля таблиц Writer пока просто не реализована. Что же я увидел сегодня в багзилле на эту тему? А там появилось предложение вообще этот раздел Боковой панели убрать с глаз долой. То есть, вместо небольшого напильника в виде подсказки, что эта функция пока не работает, они берут скальпель и режут полностью функционал. 

Я уже писал на тему того, что одни разработчики пилят фичу, а другие через минимальное количество времени её режут по живому. Сила опенсорца во всей красе =( И это реально раздражает. Все же единоначалие в некоторых вопросах разработки свободных проектов необходимо.

Различные взгляды на появление и развитие нового интерфейса Muffin в LibreOffice

На днях я имел нескучную беседу с пользователями LibreOffice и товарищами из команды разработчиков самого LibreOffice на канале его в Телеграме. Началось всё с того, что кто-то вбросил ссылку на статью на стороннем ресурсе о новом интерфейсе LibreOffice под названием MUFFIN. Причем статья крайне негативная. И товарищи на канале очень удивились и огорчились, что новый, недоделанный и кривой (в силу недоделанности) интерфейс пользователя обозреватели не приняли на ура. Когда я им попытался объяснить, что если они прямо сейчас рекламируют новый GUI, (но при этом прячут его в экспериментальные возможности, однако рассказывая, как его активировать), чтобы люди посмотрели недоделку, то не надо удивляться, что люди верят своим глазам, а не маркетологам Либры (которым бы лучше помолчать в тряпочку, вместо того, чтобы рассказывать про глубокую новую философию в видении интерфейса пользователя), то они обиделись на меня всем миром. А самое страшное, что задело апологетов MUFFIN'a - это то, что новый MUFFIN сравнивают с Robbon'ом из MS Office 2007 и более поздних. Но позвольте, а с чем же его сравнивать, если внешне он копия Ribbon, концепция взята явно оттуда же, да и сама команда дизайна из разработчиков LibreOffice в своем документе обсуждает возможности именно Ribbon?!

Товарищ Итало Виньоли начинает свою речь о целях  Muffin'a словами "...мы не заботимся о пользователях MS Office, мы заботимся о пользователях LibreOffice...", а заканчивает через предложение "...новый интерфейс MUFFIN позволит мягко перевести пользователей MS Office на LibreOffice...". Так о ком же заботится г-н Итало? Кого он обманывает? Себя? Я понял бы, если бы он честно сказал, что для облегчения миграции с MSO на LO делают тупую копию Ribbon. Логика есть в этом, пусть и спорная. Но начинать юлить и рассказывать сказки, что всем дали информацию (это речь о вышеуказанной заметке в блоге разработчиков) о "философии" нового интерфейса, а люди такие сякие (и особенно журналюги пархатые) читать это не стали, а просто посмотрели на унылие в его нынешнем виде и высказали справедливое фи на весь Интернет, - это конечно здорово.

Господин Виньоли также упрямо настаивает на том, что сам термин Ribbon употреблять нельзя, поскольку это неофициальное название GUI от MS Office, а нужно говорить Fluent UI. Основная мысль в том, чтобы уйти от прямого сравнения с Ribbon и опять кого-то обмануть, рассказывая, что с Ribbon новый GUI в LibreOffice не слизали. Кто вообще помнит о том, КАК там официльно назывался ленточный интерфейс MS Office? Да никто, по большому счету. А вот, что такое Ribbon знают гораздо больше человек.

К чему я все это выше так эмоционально изложил? К тому, что на появление Muffin даже внутри команды, имеющей отношение к разработке/тестированию/переводам LibreOffice, есть диаметрально противоположные мнения на принципиальную нужность этого новшества, не говоря уж о такой мелочи, как источник вдохновения "дизайнеров" LibreOffice.

Моя персональная точка зрения такова - этот самый MUFFIN есть копия ленточного интерфейса от MS Office по парадигме, по задумке, по внешнему виду и по тому простому факту, что оно отжирает вертикального пространства даже больше, чем сам Ribbon. В связи с указанным он просто не нужен, на него расходуются ресурсы разработчика (одного кстати, один несчастный чешский парень это пилит), пусть он и доброволец, которые можно было бы направить в иное русло. Добавление этого MUFFIN'a 146% повлечет за собой многочисленные ошибки (да уже повлекло), на исправление которых потребуются дополнительные усилия грамотных программистов, которых и так мало. А вот профита никакого эта штука не принесёт.

Кстати, надо бы попытаться натолкнуть их на мысль провести опрос среди самих разработчиков LibreOffice на предмет их отношения в новшествам в интерфейсе.

Причины использовать LibreOffice, а не MS Office

По мотивам недавней заметки про 10 причин использовать LibreOffice. Всё нижесказанное - это моё глубоко личное мнение, не претендующее на истину.

Давайте сразу обозначим самую главную причину и для домашнего пользователя и для корпоративного бизнеса: это БЕСПЛАТНОСТЬ LibreOffice. Все остальные причины не имеют такого подавляющего веса при выборе между LibreOffice и MS Office.

Вторая возможная причина - необходимость корректно открывать документы в формате ODF, которые Вам кто-то дал. Например, в школе выдали задание и дали (или задали создать) файл в формате ODF, который MS Office открывает, но криво, а делать надо, благо LibreOffice бесплатен и его можно в любой момент скачать и установить.

Третья причина - Вы используете операционную систему на основе ядра Linux, в которой MS Office сам по себе не запускается, зато в поставке подавляющего большинства дистрибутивов уже есть LibreOffice. Чего же мудрить, когда уже есть готовый к употреблению софт? Та же ситуация и у пользователей macOS, за исключением того, что им придется скачать и установить LibreOffice самим.

Четвертая причина - Вам требуется работать на разных компьютерах с разными операционными системами с файлами в формате ODF. MS Office работает только на Windows, LibreOffice - это мультиплатформенный софт.

Пятая причина - классический панельный интерфейс в LibreOffice. Если Вам тошно от риббона, то использовать LibreOffice - это хорошая идея.

А вот говорить о том, что ODF такой прекрасный и прогрессивный формат файла, что он не меняется годами и через 10 лет Вы сможете без проблем открыть файл, созданный сегодня - это такая же пропаганда, как и та, которую нам рассказывает MS про свой офис. Доля правды в ней не велика, явно.

Делать упор на то, что LibreOffice продукт с открытым исходным кодом, в отличие от МСО, - это также плохая причина его использовать. Мне, как пользователю, глубоко фиолетово, какой там код у софта, мне важно, чтобы софт делал своё дело так, как мне нужно.

Очень много стилей в базовой поставке LibreOffice Writer

Сегодня почитывал вики проекта, страничку посвященную идеям, которые бы разработчики хотели отдать студентам на GSoC (Google Summer of Code). И увидел там интересную запись про то, что неплохо бы было почистить список стилей, которые есть по умолчанию в Writer. Причем с пометкой типа "их там много, очень много, и большая часть никогда и никем не используется совсем!"

Для тех, кто не знает, что такое стили, вот ссылка на хорошее пособие по стилям.

Так вот, я открыл Writer и начал считать ручками стили, а оказалось их 122 (СТО ДВАДЦАТЬ ДВА, КАРЛ!!) только стилей абзаца! А есть еще стили символов, врезок, страниц и списков - это ещё 54 штуки. Неопытный пользователь, который наслушался бредней про то, что стили это круто, сразу потеряется в огромном количестве стилей, которые УЖЕ ЕСТЬ в LibreOffice, и которые ему не подходят, так как требования к оформлению у него свои (а так чаще всего и есть) и стили ему надо делать тоже свои.

Приведу пример, откуда взялось столько стилей: есть стили абзаца для нумерованных списков, их 5 штук, для каждого из них есть ДОПОЛНИТЕЛЬНО стиль начала списка, стиль продолжения списка и стиль окончания списка. Пять на три - это 15 ненужных абсолютному большинству стилей абзаца для стилей списка. То же самое верно и для стилей маркированных списков. Уже 30 лишних сущностей. Есть ещё 10 стилей указателей пользователя. Что это вообще такое?

По моему крайне нескромному мнению следовало бы оставить в базовой поставке LibreOffice Writer следующие стили: 

для абзацев: 
1. базовый стиль (ибо с него все начинается и растут ноги ВСЕХ стилей в Либре);
2. стили заголовков (можно сократить с 10 до 5, которые потом собираются в оглавление);
3. стиль для основного текста;
4. стиль названий для встраиваемых картинок, таблиц, диаграмм и так далее;
5. стиль для колонтитулов (один оставить, без разделения, как сейчас, на верхние и нижние, на слева, на справа и на по центру в сумме 6 штук лишних сущностей получилось)
6. стиль для списков (естественно всю кучу идиотских делений стилей внутри списков из базовой поставки надо убрать)
7. стиль для сносок
8. стиль для заголовка таблицы
9. стиль для содержимого таблицы
для символов:
1. базовый стиль
2. жирный стиль
3. курсив стиль
4. подчеркнутый стиль
5. стиль для гиперссылки
6. стиль для посещённой гиперссылки
для врезок:
всё можно оставить, как есть сейчас
для страниц:
всё можно оставить, как есть сейчас
для списков:
1. стиль для нумерованного списка (с арабской нумерацией, многоуровневый)
2. стиль для маркированного списка (с маркерами в виде маленьких точек).

Сколько осталось? Я насчитал 38 стилей всего. Вместо 176. В четыре с лишним раза меньше стало. У этой оптимизации будет и ещё один положительный момент - список стилей будет помещаться в экране целиком. И при просмотре взгляд не будет теряться среди сотен однотипных строк с названиями стилей. И не надо мне говорить про фильтр, который есть в нижней части списка стилей, он конечно позволяет сокращать список отображаемых в списке стилей, однако это не отменяет того факта, что огромное преднастроенное количество стилей в Writer - это лишнее.

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

LibreOffice и JAVA

Новички часто спрашивают такую вещь: "Зачем для работы LibreOffice нужен JAVA? Он написан на JAVA и поэтому так тормозит?" Приходится объяснять, что нет, LibreOffice не написан на JAVA, а написан на С++, а JAVA (даже не вся JAVA, а только JAVA Runtime Environment (JRE)) ему нужна для некоторых модулей и функций, в частности это некоторые мастера (пошаговые помощники для, скажем, организации почтовых рассылок прямо из LibreOffice), отдельный, дополнительный модуль решателя для Calc, встроенный движок баз данных HSQLBD и ещё по мелочи. Так вот, если не устанавливать JAVA (полную инсталляцию или только JRE в любом виде), то LibreOffice работать все равно будет. Не будут работать только вышеперечисленные функции. Субъективно при подключении JAVA в LibreOffice тот начинает работать медленнее, но видно это только, если мало ОЗУ (оперативной памяти).

А теперь к тому, ради чего я начал вообще этот пост: версии JAVA периодически обновляются в связи с закрытием каких-то ошибок (внутри ветки 1.7 скажем), а также в связи с добавлением каких-то новых фич (с выходом версии 1.8 соответствено) и я заметил такую неприятную тенденцию, что LibreOffice с JRE 1.8 стал просто падать при любых попытках работать с Base. Есть субъективное мнение, что версия JRE 1.7 работает стабильнее, а также, что LibreOffice для 32 битных систем (речь про сборку для ОС Windows) вкупе с 32-битным JRE версии 1.7 работает (во всяком случае не падает на ровном месте), а как только вы начинаете использовать 64-битный LibreOffice с 64-битным же JRE (поскольку работает только так, 32 бит LibreOffice не будет работать с 64 битным JRE и наоборот), то начинаются чудеса. Также не нужно мешать на одной машине две инсталляции JRE для разных архитектур.

Резюмируя, если вам нужны функции баз данных (остальное не так падуче):

1. Используйте JRE 1.7 максимум

2. Используйте 32-битный LibreOffice и соответсвующий JRE

3. Попробуйте использовать ОС на основе ядра Linux и там работать в LibreOffice, используя открытую реализация JAVA Open-JDK (которая есть в репозиториях вашего дистрибутива)
Обновлю пост из 2019 года. По поводу п.3: к сожалению в 2017 году появилась в дистрибутивах Linux проблема с JAVA и LibreOffice. Я написал об этом отдельный пост.

Разработчики LibreOffice с моей точки зрения

Этот пост сугубое ИМХО и основан на терках всего с одним разработчиком. Суть проблемы в том, что некто Маркус Морхард (или типа того как-то) запилил (а вернее допилил даже) фильтр импорта файлов в формате .gnumeric (от одноименной программы Gnumeric) для LibreOffice. Он сделал патч, запихал его в мастер-ветку, написал о своем достижении в вики проекта, как одну из фич предстоящего выпуска версии 5.1 и успокоился. Ради пустого интереса я решил эту фичу проверить. Оказалось, что фича не работает должным образом, о чем и было в багзиллу доложено. Г-н Маркус, после того, как к нему обратились с просьбой багу починить, через губу ответил, что будет заниматься тем, чем угодно ему самому и править те баги, которые интересны ему, а не кому-то там. После поднятия волны в списке рассылки, он таки пересилил себя и родил патч, исправляющий проблему...как оказалось только для Linux! Багу резко закрыли, как "фикс" с камментом, что кто-то там в чате сказал, что Маркус багу пофиксил и типа этого достаточно. О как. Друг подруги телки брата сказал, что всё ОК. Сама бага правда была заведена для Windows, и после проверки оказалось, что бага для Linux реально исправлена и импорт работает вменяемо, а для Windows по каким-то причинам исправление не сработало и дальнейших действий не последовало. Товарищ Маркус отписался от баги с тем же переплевыванием через губу "у меня нет винды, идите в задницу, я самый умный аще". А дальше началось самое интересное. В IRC-чате разработчиков на просьбу к Маркусу таки исправить этот баг, ВСЕ, кто был активен встретили такое в штыки! "У нас свободный проект, а значит каждый волен заниматься тем, что ему нравится или ближе!" - сказали они. "У большинства кодеров нет винды и нам трудно править вин-специфичные баги" - сказали они. Отличное, просто прекрасное положение вещей. Получается, что каждый недоумок, который научился вчера писать "хелло мир" на паскале, может смело ринуться в проект LibreOffice, анансировать супер патч, впихнуть его в мастер (и его пропустят безо всяких тестов!) и свалить в туман. А править регрессии или тупые недоработки самого патча не будет никто. О как. Свобода во все поля, в том числе и от ответственности за свой код. Хоть вирусню запихни в Либру, все прокатит.

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

Update во имя справедливости из 2017 года: в итоге оказалось, что проблема была в библиотеке, которая отвечает за импорт и разбор формата gnumeric, как-то там не так ее собирали сами создатели. Им было об этом отписано, проблему в либе исправили и Маркус таки родил еще пару патчей, которые проблему в LibreOffice исправили и импорт gnumeric-файлов заработал, как было изначально задумано. В итоге на всё про всё потребовалось полтора года времени.