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

Автор Centuriones, 9 сентября 2011, 02:54

0 Пользователи и 1 гость просматривают эту тему.

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

Цитата: Dworkin от  9 сентября 2011, 11:42а что тут холиварного, это пюросто констаттация факта
Это на всякий случай.  ;) На родных просторах на отдельных людей словосочетание LibreOffice действует как красная тряпка на быка. ;D

Цитата: Vladjmir от  9 сентября 2011, 20:44Скоро LO будет совсем другим офисом. Особенно, когда у него появится новая  морда.
Вариация на тему "Симфонии Лотоса"?  ;D


Vladjmir

Цитата: Centuriones от  9 сентября 2011, 21:26Вариация на тему "Симфонии Лотоса"?
Что-то в этом роде. Хотя у меня эта морда не вызывает отвращения, я бы предпочёл, чтобы опционально оставили старый добрый панельный интерфейс.

ape

Vladimir! У Симфонии (по склерозу) панельки справа. Слева - у Microsoft Office.
Два момента, которые настораживают (см. топик-стартёр; выделено красным):
ЦитироватьРассматривая только код на языке С++, в LibreOffice было удалено 678 файлов с устаревшим кодом (binfilter, поддержка OS/2, adabas, evo1 и т.п.) и добавлено 914 файлов с ... , кодом поддержки Gtk+32, фильтром SVG1 и т.п. 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

Цитата: ape от 10 сентября 2011, 10:49Vladimir! У Симфонии (по склерозу) панельки справа. Слева - у Microsoft Office.
Ну я и сказал: что-то вроде того. Сам принцип боковой панели. То что она слева -- это лучше с точки зрения минимизации пробега мыши, т.к. пишем слева направо и меню запуска в основных рабочих окружениях (Win, GNOME, KDE, XFCE, LXDE и др.) находятся слева, поэтому указатель мыши тоже большей частью находится в левой части экрана.

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

Цитата: ape от 10 сентября 2011, 10:49Использование для 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

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

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

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

Поищи на русских сайтах посвященных Гимпу. Вроде тут: 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.

Цитата: ape от 10 сентября 2011, 11:49
...
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 "забил", впрочем, как и "Голубой Г."  ;D

Vladjmir

Цитата: Centuriones от 10 сентября 2011, 17:12Иными словами: для работы с изображением будет применяться GEGL, для отрисовки - применяться связка Cairo/GTK+3.
Я думаю, в силу того, что часть функций GEGL и Cairo дублируются, разработчикам GIMP'а следует сделать упор именно на Cairo, как наиболее отработанную и используемую на сегодняшний день технологию. А за GEGL оставить обработку растровой графики. В вики сказано, что GEGL пока ещё не достаточно доработан, особенно в части производительности:
ЦитироватьУсловием выпуска версии 2.8 является обеспечение скорости отрисовки, достаточной для комфортной работы.
Там ещё много работы по оптимизации.


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


Vladjmir

Цитата: Centuriones от 10 сентября 2011, 17:12Резюмируя: перевод LO с GTK+2 на GTK+3/Cairo приведёт к тем же преимуществам, как и у GIMP.
Интересно, а есть такие планы?

Vladjmir

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

ВсеМыБывшие

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

Centuriones

Цитата: Vladjmir от 10 сентября 2011, 20:00Как раз 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

Цитата: Centuriones от 11 сентября 2011, 01:42
... компьютер реально старый: мать на базе чипсета 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, и КДЕ оставили о себе очень тягостные воспоминания.
Цитата: Vladjmir от 10 сентября 2011, 21:28
Начал планомерно устанавливать 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

Цитата: Vladjmir от 10 сентября 2011, 15:24
Надеюсь, что это болезни роста. На практике этот SVG не так уж часто нужен, по крайней мере мне. А когда популярность SVG достигнет хотя бы уровня  PNG, к тому времени TDF отладит этот фильтр.
Формат SVG востребован, т.к. векторная графика, если это схема или чертёж, а не "фотка", значительно меньше весит. Болезни роста у Офиса, к сожалению таковы, что, исправляя одно, портим другое. Примеры - экспорт в ДОКументы и импорт SVG.
В 1-м случае вернули возможность экспорта таблиц с числом колонок >32 (а эта возможность была ещё у Ru.OOo-1.1.5), но загубили экспорт ссылок. 2-й случай легче всего оценить, последовательно открыв файлы, взятые мною с сайта Фонда, в Inscape, затем в LibO-3.5(350m1)\OOo-3.4b, затем в любом Офисе предыдущих версий: ни один из Офисных пакетов ОБА файла правильно не откроет.  ???
Цитата: Centuriones от 10 сентября 2011, 18:12В этом плане разработчики GIMP поступают весьма правильно: они не устраивают интерфейсных и иных революций, а идут эволюционным путём. В условиях нехватки ресурсов (в данном случае - недостаток разработчиков) это наиболее правильный путь.
Если склероз не изменил, ГИМП-2.8 должен иметь новый интерфейс, у которого боковые панели будут плавать внутри главного окна и всплывать там же (после сворачивания). От этого оказались (для Windows сделан только 2.7.1, 2.7.3 так и нет)?

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