Анализ различий текущего состояния кодовой базы OpenOffice.org и LibreOffice

[Centuriones]

Утащено с OpenNET: http://www.opennet.ru/opennews/art.shtml?num=31709

Майкл Микс (Michael Meeks), входящий в управляющий совет организации Document Foundation, опубликовал в своем блоге результаты изучения степени отличия текущей кодовой базы LibreOffice и OpenOffice.org. По мнению Майкла уровень отличий уже настолько высок, что из-за конфликтов при наложении патчей обмен новыми наработками между OpenOffice.org и LibreOffice уже излишне усложнен.

Рассматривая только код на языке С++, в LibreOffice было удалено 678 файлов с устаревшим кодом (binfilter, поддержка OS/2, adabas, evo1 и т.п.) и добавлено 914 файлов с реализацией фильтра lotuswordpro, поддержкой VBA, переработанным фильтром RTF, сборщиками для ODMA и KDE, поддержкой OpenXML, новым набором unit-тестов, кодом поддержки Gtk+3, фильтром SVG и т.п. Eсли сравнить общие для обоих проектов 21.5 тыс. файлов, размер потенциально конфликтующих изменении составляет около двух миллионов строк в формате "diff -u".

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

P.S. Т.к. тема достаточно "холиварная", то открыл её здесь, а не в "новостях".

[Dworkin]

а что тут холиварного, это пюросто констаттация факта

[Vladjmir]

Скоро LO будет совсем другим офисом. Особенно, когда у него появится новая  морда.

[Centuriones]

а что тут холиварного, это пюросто констаттация факта

Это на всякий случай.  На родных просторах на отдельных людей словосочетание LibreOffice действует как красная тряпка на быка.

Скоро LO будет совсем другим офисом. Особенно, когда у него появится новая  морда.

Вариация на тему "Симфонии Лотоса"? 

[Vladjmir]

Вариация на тему "Симфонии Лотоса"?

Что-то в этом роде. Хотя у меня эта морда не вызывает отвращения, я бы предпочёл, чтобы опционально оставили старый добрый панельный интерфейс.

[ape]

Vladimir! У Симфонии (по склерозу) панельки справа. Слева - у Microsoft Office.
Два момента, которые настораживают (см. топик-стартёр; выделено красным):

Рассматривая только код на языке С++, в LibreOffice было удалено 678 файлов с устаревшим кодом (binfilter, поддержка OS/2, adabas, evo1 и т.п.) и добавлено 914 файлов с ... , кодом поддержки Gtk+3², фильтром SVG¹ и т.п. Eсли сравнить общие для обоих проектов 21.5 тыс. файлов, размер потенциально конфликтующих изменении составляет около двух миллионов строк в формате "diff -u".

1. `TDF открыто заявил о поддержке импорта SVG-файлов в LibreOffice-3.4. В действительности же фильтр реализован криво - проверял на SVG-файле с офисными иконками, который взял с сайта Фонда. Нормальную, если не считать за ошибку неумение импортировать текстовые слои, реализацию этот фильтр имеет только в Мастере LibO-dev_OOO350m1. Загвоздка в том, что аналогичным образом, но с возможностью открыть SVG-файл из меню "Файл" (Мастер от 2-го сентября этого не умеет), работает фильтр импорта SVG-файлов ОО.орг-3.4"бета" от 11 апреля.
2. Использование для GUI библиотек GTK+3, скорее всего, приведёт к медленной или прожорливой для RAM работе интефейса. GIMP, например, потихоньку "уезжает" в GEGL.

[Vladjmir]

Vladimir! У Симфонии (по склерозу) панельки справа. Слева - у Microsoft Office.

Ну я и сказал: что-то вроде того. Сам принцип боковой панели. То что она слева -- это лучше с точки зрения минимизации пробега мыши, т.к. пишем слева направо и меню запуска в основных рабочих окружениях (Win, GNOME, KDE, XFCE, LXDE и др.) находятся слева, поэтому указатель мыши тоже большей частью находится в левой части экрана.

В действительности же фильтр реализован криво

Надеюсь, что это болезни роста. На практике этот SVG не так уж часто нужен, по крайней мере мне. А когда популярность SVG достигнет хотя бы уровня  PNG, к тому времени TDF отладит этот фильтр.

Использование для GUI библиотек GTK+3, скорее всего, приведёт к медленной или прожорливой для RAM работе интефейса. GIMP, например, потихоньку "уезжает" в GEGL.

GIMP портируют в том числе на GTK+3.
http://git.gnome.org/browse/gimp/log/?h=gtk3-port

Скорость GTK+3 на самом деле очень высокая по сравнению с GTK+2, потому что он отрисовывает через библиотеку векторной графики Cairo. Я погонял LiveCD Fedora 15 с GNOME 3 -- на моём компе летает. На форумах ни  у кого нет претензий к скорости GTK+3 + рендера Cairo, претензии в основном к графическому интерфейсу GNOME 3, который оптимизирован под планшеты, а для десктопа его юзабилити не выдерживает критики.

У меня сложилось впечатление, что GEGL -- это граф.библиотека для  обработки и преобразования изображения в GIMP'е, а Cairo --это библиотека для отображения (рендеринга) на конкретной аппаратуре, т.е. прослойка между софтом, генерящим изображение, и железом. Функции GEGL и Cairo где-то пересекаются, но GIMP, скорее всего, будет обрабатывать картинку в GEGL, а выводить на экран через GTK+3 / Cairo. Может быть, я ошибаюсь, но буду признателен, если найдётся хорошая инфа на эту тему.

[Centuriones]

У меня сложилось впечатление, что GEGL -- это граф.библиотека для  обработки и преобразования изображения в GIMP'е, а Cairo --это библиотека для отображения (рендеринга) на конкретной аппаратуре, т.е. прослойка между софтом, генерящим изображение, и железом.

Впечатление сложилось совершенно правильное.

Может быть, я ошибаюсь, но буду признателен, если найдётся хорошая инфа на эту тему.

Поищи на русских сайтах посвященных Гимпу. Вроде тут: http://www.progimp.ru/ и тут: http://gimp.ru/

Навскидку: Главное о GIMP 2.7.2

Сам по себе порт на GTK+3 — это не какая-то неведомая скучная ерунда, которую можно проигнорировать. Как выяснилось, тесно интегрировав Cairo в GTK+3, авторы GTK+ изрядно улучшили производительность отрисовки. Недавние тесты показали, что в существующем порте GIMP на GTK+3 можно практически без тормозов рисовать кисточкой с диаметром от 500 до 1000 пикселов по холсту размером 5000×5000px.

и вот тут: Как в проекте принимаются решения по реализации функционала и чего ждать в будущем

Момент с портированием на GTK+3 требует отдельного пояснения. Для GIMP это выигрыш сразу на нескольких фронтах: более чистый и удобный API для программирования интерфейса, принципиальное ускорение отрисовки при работе с кистями большого диаметра (500-1000px без задержек), стабильно работающие расширенные устройства ввода, такие как графические планшеты (в GTK+2 многое разломано).

Со стороны окончательной интеграции GEGL планы таковы: сначала выпускается версия 2.10 с необходимой доработкой API в GIMP, затем выпускается версия 3.0, где тот же интерфейс и тот же функционал, что в 2.10, но на GTK+3 и с обработкой в режиме 32 разряда на цветовой канал. Если порт на GTK+3 окажется готов раньше, теоретически может быть принято решение выпустить 3.0 без окончательной интеграции GEGL, но это пока что маловероятный сценарий.

Про GEGL: Описание графической библиотеки GEGL

Текущие возможности GEGL:

    1. 8-/16-/32-разрядные (с плавающей точкой) режимы, внутренняя обработка — в 128-разрядном режиме;
    2. RGB, CIE LAB, YCbCr и простой вывод в CMYK;
    3. мозаичный, неплотный и пирамидный буферы, буфер больше размеров RAM; в качестве теста успешно загружалось изображение размером 86400×43200px;
    4. загрузчики PNG, JPEG, SVG, EXR, RAW и пр.;
    5. арифметические операции, композитные операции Портера-Даффа, режимы наложения SVG, прочие режимы наложения, применение маски;
    6. работа с векторными объектами (полилинии, кривые Безье, кривые Спиро);
    7. базовые инструменты цветокоррекции;
    8. большинство операций обработки функционирует в HDR;
    9. расширяемость через модули.

Иными словами: для работы с изображением будет применяться GEGL, для отрисовки - применяться связка Cairo/GTK+3.

...
2. Использование для GUI библиотек GTK+3, скорее всего, приведёт к медленной или прожорливой для RAM работе интефейса. GIMP, например, потихоньку "уезжает" в GEGL.

Не скорее всего и не приведёт, т.к. у библиотек GEGL и GTK разное назначение: обработка изображений и отрисовка результатов. Наоборот, сейчас GIMP усиленно портируется с GTK+2 на GTK+3/Cairo и эта работа будет выполнена раньше, чем портирование средств обработки на GEGL. Подробнее - выше.

Резюмируя: перевод LO с GTK+2 на GTK+3/Cairo приведёт к тем же преимуществам, как и у GIMP. Сравнение с проблемами KDE4 и GNOME3 тут совершенно некорректное, т.к. эти DE, будь они работали бы на Qt3 или GTK+2 - были бы абсолютным тормозом. То, что они сейчас тормозят, то это от того, что разработчики, применив новые библиотеки, решили "оторваться" на все 200%.

В этом плане разработчики GIMP поступают весьма правильно: они не устраивают интерфейсных и иных революций, а идут эволюционным путём. В условиях нехватки ресурсов (в данном случае - недостаток разработчиков) это наиболее правильный путь. Мало того, они потихоньку ещё и баги исправляют, что в своё время Sun так и "ниасилил", а Oracle "забил", впрочем, как и "Голубой Г." 

[Vladjmir]

Иными словами: для работы с изображением будет применяться GEGL, для отрисовки - применяться связка Cairo/GTK+3.

Я думаю, в силу того, что часть функций GEGL и Cairo дублируются, разработчикам GIMP'а следует сделать упор именно на Cairo, как наиболее отработанную и используемую на сегодняшний день технологию. А за GEGL оставить обработку растровой графики. В вики сказано, что GEGL пока ещё не достаточно доработан, особенно в части производительности:

Условием выпуска версии 2.8 является обеспечение скорости отрисовки, достаточной для комфортной работы.

Там ещё много работы по оптимизации.

То, что они сейчас тормозят, то это от того, что разработчики, применив новые библиотеки, решили "оторваться" на все 200%.

Как раз 3-й Гном не тормозит. Я его юзал с LiveCD. Ребята на линукс-форумах пишут, что пробовали GNOME 3 на относительно слабых машинах, там он уделывает GNOME 2. Жаль, что разрабы делают 3-й Гном под планшеты, а на десктопы забили. Одна надежда: либо они рано или поздно очухаются и сделают доп. интерфейс под десктоп, либо появятся расширения для GNOME Shell, с помощью которых Гном можно будет довести до состояния, пригодного к употреблению на десктопе.

[Vladjmir]

Резюмируя: перевод LO с GTK+2 на GTK+3/Cairo приведёт к тем же преимуществам, как и у GIMP.

Интересно, а есть такие планы?

[Vladjmir]

Начал планомерно устанавливать LO 3.4.3  на все компы в нашей конторе. Субъективно по скорости запуска он догнал Firefox. Заметил, что LO на некоторых машинах загружается быстрее, чем FF (холодный старт). С принтерами эта версия тоже вроде работает лучше, чем 3.3.x. Правда, проверил ещё не на всех моделях принтерах.

[ВсеМыБывшие]

Насчёт лучшей скорости LO 3.4.Х увы не могу согласиться. К сожалению на больших файлах calc виснет при начале и окончании работы.

[Centuriones]

Как раз 3-й Гном не тормозит.

Ну не знаю. Я пробовал и чистый третий ГНОМ (сборка для Open SuSE, Live), и в Убунтовом варианте (Unity). По сравнению с Debian Lenny, который стоит на том же компьютере - тормозилово то ещё. Тормозит и по сравнению с KDE4 (Live от Aptosid - немецкий роллинг-дистрибутив на базе Debian). С Linux Mint (что в "убунтовой" редакции, что в "дебиановской") лучше и не сравнивать. Правда компьютер реально старый: мать на базе чипсета VIA 693A, 768 Мб оперативки, процессор Celeron Coppermine 1000 и видео на базе GF Ti4200 c 128 Мб видеопамяти. Примерно такая же ситуация с компьютрерами, где 815 чипсет от Intel и Celeron Tualatin 1300. Несколько побыстрее, конечно, но принципиальной разницы нет.

[ape]

... компьютер реально старый: мать на базе чипсета VIA 693A, 768 Мб оперативки, процессор Celeron Coppermine 1000 и видео на базе GF Ti4200 c 128 Мб видеопамяти. Примерно такая же ситуация с компьютрерами, где 815 чипсет от Intel и Celeron Tualatin 1300. Несколько побыстрее, конечно, но принципиальной разницы нет.

На более новых "железках" (I945gl_s478 + P4_3GHZ_fsb200 + NV9500GT512MB + RAM_2GB; NF650i + Core2_E7200_3.4GHz_fsb358 + NV9800GTX1GB + RAM_8GB + RAID_0=2xCorsarForce60_SSD) и Гном-3, и КДЕ оставили о себе очень тягостные воспоминания.

Начал планомерно устанавливать LO 3.4.3  на все компы в нашей конторе. Субъективно по скорости запуска...

Всего-навсего уменьшены примерно вдвое ресурсы со значками GUI. Убрали из тем высококонтрастные значки. Писал им об этой ошибке ещё в начале года, но убрали только в "3.4". Если "перетрясёте" любой дистрибутив - получите тот же эффект. На моих ПК основной Офис - ОО.про-3.11_Win32 - стартует ничуть не дольше, чем Либре. Личное впечатление: master~2011-09-06_02.34.59_LibO-Dev_OOO350m1_Win_x86 уже ничуть не хуже LibO-3.4.3, т.е. в феврале возможно появится 1-й рабочий релиз ЛиО. Возможно, что и не появится - всё зависит от того, куда пойдёт Novell.

[ape]

Надеюсь, что это болезни роста. На практике этот SVG не так уж часто нужен, по крайней мере мне. А когда популярность SVG достигнет хотя бы уровня  PNG, к тому времени TDF отладит этот фильтр.

Формат SVG востребован, т.к. векторная графика, если это схема или чертёж, а не "фотка", значительно меньше весит. Болезни роста у Офиса, к сожалению таковы, что, исправляя одно, портим другое. Примеры - экспорт в ДОКументы и импорт SVG.
В 1-м случае вернули возможность экспорта таблиц с числом колонок >32 (а эта возможность была ещё у Ru.OOo-1.1.5), но загубили экспорт ссылок. 2-й случай легче всего оценить, последовательно открыв файлы, взятые мною с сайта Фонда, в Inscape, затем в LibO-3.5(350m1)\OOo-3.4b, затем в любом Офисе предыдущих версий: ни один из Офисных пакетов ОБА файла правильно не откроет. 

В этом плане разработчики GIMP поступают весьма правильно: они не устраивают интерфейсных и иных революций, а идут эволюционным путём. В условиях нехватки ресурсов (в данном случае - недостаток разработчиков) это наиболее правильный путь.

Если склероз не изменил, ГИМП-2.8 должен иметь новый интерфейс, у которого боковые панели будут плавать внутри главного окна и всплывать там же (после сворачивания). От этого оказались (для Windows сделан только 2.7.1, 2.7.3 так и нет)?

[вложение удалено Администратором]