OpenOffice.org 3 beta (diskuse)

[newman]

Asi trochu blahove jsem doufal, ve vykreslovani skrz Cairo a nativni binding na GTK+ a la SWT; no jo, my optimisti...

[xkucf03]

Cairo?

http://zrusin.blogspot.com/2006/10/benchmarks.html

http://www.abclinuxu.cz/zpravicky/rychlost-qt-4-oproti-cairo

[newman]

Ano, Cairo. Proc se ptas?

Pribalovat Qt4 knihovnu k OO.o mi neprijde ucelne vzhledem k velikosti vysledneho produku. Cairo je oproti Qt4 mizive velike a obecne prijimane v non-Qt svete (Mozilla).

Navic jsem nemel na mysli pocet vyrendovanych polygonu za vterinu, ale zlepseni kvality vystupu, pro ktery je Cairo predevsim (diky backendum), ktery je u OO.o tristni. Nakresli si v OO.o Draw elipsu.

Jak to muze vypadat lepe se podivej na Sun blogu + dalsi pokus a dalsi.

Asi ze zeptam hloupe, ale opravdu neznam odpoved, ktery program pouziva Arthura k rendovani?

Ke zminenym odkazum: Zack pres mnoho zadosti v komentarich nezverejnil zdrojaky testovacich prikladu, a proto jeho vystupum nedavam tak velkou vahu, jako by mohly mit.

[R]

Neviem, preco by mali k OOo pribalovat Qt. Dynamicke kniznice maju v Linuxe priponu .so, co znamena Shared Object. Takze v systeme je len raz a v pamati tak isto.

[newman]

OO.o bali sve vlastni baliky pro Win, Lin, MacOS X, ... kde by to nutne museli zahrnout.

I kdyz nepouzijes oficialni build OO.o, tak stejne bys musel mit Qt v systemu.

newman@dhcp-lab-110 ~ $ ldd /usr/lib/openoffice.org/program/soffice.bin | grep -i gtk
	libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x049aa000)

newman@dhcp-lab-110 ~ $ rpmquery -f /usr/lib/libgtk-x11-2.0.so.0
gtk2-2.12.8-2.fc8

To uz by nam pak chybel jenom binding na Motif a Athenu :).

[Espinosa]

Asi máte oficiální build, já žádnou závislost na uvedené libgtk-x11 ani Qt/KDE. Používá se pěkně ta ze systému přes VCL plugin jak to má být.

[espinosa@pavilon ~]$ ldd /usr/lib/ooo-2.4/program/soffice.bin | grep -i gtk
[espinosa@pavilon ~]$ 
[espinosa@pavilon ~]$ find /usr/lib/ooo-2.4/program -name '*gtk*'
/usr/lib/ooo-2.4/program/libvclplug_gtk680li.so
/usr/lib/ooo-2.4/program/libqstart_gtk680li.so
[espinosa@pavilon ~]$ find /usr/lib/ooo-2.4/program -name '*kde*'
/usr/lib/ooo-2.4/program/kdebe1.uno.so
/usr/lib/ooo-2.4/program/libvclplug_kde680li.so
/usr/lib/ooo-2.4/program/kde-open-url
/usr/lib/ooo-2.4/program/fps_kde.uno.so
/usr/lib/ooo-2.4/program/kdefilepicker

Ono jde o to, že některé distribuce jen přebalí oficiální build, takový "rebranding", možná změní logo a zabalí do RPM nebo DEB, zato jiné distribuce si skutečně pohrají s nastavením a rebuildují zdrojáky.

P.S. Mám PCLinux

[newman]

Mam build z Fedora 8, coz neni jenom prebaleny oficialni build, ale vzhledem k tomu, ze Fedora se snazi pracovat s upstreamem co nejuzeji, tak je mozne, ze je tomu oficialnimu dost blizko.

libgtk-x11 je soucast GTK+, takzen ativni binding. VCL plugin tam je taky, takze gulas. Na Qt ani KDE se to poji leda skrz vcl.

[Espinosa]

Ona jde OOo zbuildovat na tisíc způsobů. Mluvím z vlastní zkušenosti, několikrát jsem se o to pokusil a většinou úspěšně.

Fedora se aktivně podílí na vývoji OOo, spolu se SUNem a Novelem, a taky na vývoji Gnome, takže snaha o co nejuží propojení OOo a Gnome, mě nepřekvapuje. Pointa je opět v tom, jak, s jakými z těch desítek a možná stovek parametrů se to zkompiluje.

[Espinosa]

OOo má nativní binding pro KDE a SWT už několik let. Jmenuje se to VCL a je to zhruba obdoba SWT. Pravda, pokrývá to widgety ale ne canvas. Díky tomu je OOo skinovatelné, bohužel není úplně ideání, ne všechny skiny tomu sednou, problémy měl například Plastic, hlavně s TabbedPane, moje oblíené QtCurve je OK :) Podobně je to s GTK, Motifem, Windows. A v záloze mají svoji původní Xlib only implementaci widgetů. O jiném bindingu nevím.

Něco ke čtení: http://wiki.services.openoffice.org/wiki/VCL
http://gsl.openoffice.org/vcl/plugins/index.html
http://kde.openoffice.org/

S tím canvasem je to horší. Impress ho údajně používá od roku 2005 zbytek nevím. Viděl jsem videozáznam z OOo 2005 konference kde to demonstrovali. A jedním dechem dodali, že je dost zklamal výkon Caira. Údajně Cairo není příliš optimalizované pro interaktivní grafiku a dost možná na rychlost obecně. No snad se toho za ty dva roky změnilo k lepšímu.

[newman]

Diky za odkazy, zajimave cteni.

Nemyslel jsem binding na SWT, ale jako SWT. Tedy, ze nepujde poznat, jaka knihovna je na nejvyssi urovni abstrakce pouzita. Coz u OO.o poznat jde. Porad je to pro me napodobenina jako je v Mozilla Firefoxu 2 a v Java 6 pri pouziti swing-u.

Treba prekreslovani vybrane polozky v menu ("File", "Edit", "View") se, u mne, prekresli o neco pozdeji nez u jakekoliv "nativni" (porad se toho drzim) GTK+ aplikace. Nebo napriklad scrolovani nad zalozkama se chova v OO.o, FF 2, Java aplikacich stejne, neskroluje jako v "nativnich" a SWT, treba.

Mozna je to jenom problem u mne.

[Espinosa]

U VCL a SWT jde pricipiálně o stejnou věc, to ale neznamená že implementace je nas tejné úrovni, že je stejně vyspělá. Jak jste si všimnul, tak není. Proces jde pomalu. Dodnes některé widgety pokryty nejsou, určitě ne TreeView a combo a list boxy tak nějak napůl. Popisovaných problémů jsem si nevšimnul, jednak mám poměrně silný stroj a jednak používám KDE VCL. Trochu mě to překvapuje, Gnome integrace bych hádal, že bude vychytanější, je starší a má silněší zázemí (SUN, Fedora, Ximian-Novell)

[belisarivs]

Zkousel jsem posledni build m11 a nejak mi to prijde stejne jako 2.4.

Necekal jsem kdo vi co, ale treba prechod mezi 1.x a 2.x byl znatelnejsi.

I ty grafy, a v jejich vylepseni jsem doufal nejvice, mi prijdou stejne jako ve 2.4.

[Archman]

A konečně by ten Open-source bastl moh být pro 64-bit..

[David Watzke]

Už dávno se na 64bitu zkompiluje... nebo ne? Tak to já ho půjdu vyhodit

Asi myslíš ofic. 64bit buildy, co? O těch nic nevím.

[neal_cz]

Oficiálně se poprvé (alespoň česky) objevila v 64-bit verze 2.0.3 skoro před 2 lety.

[David Watzke]

Tak teda nevím o co mu jde.

[AsciiWolf]

No, podle mě má jen potřebu rýpnout si do všeho,co je Open Source. Holt typický Windowsák...

[JoHnY2]

No vycitat opensourcu podporu 64bit jak uzivatel widli je usmevny, ne li primo ubohy. MS je v dnesni dobe snad nejmin 64bit friendly korporace v IT svete. Na druhou stranu je to z duvodu zpetny nekompatibility celkem pochopitelny. (coz neznamena ze omluvitelny ;))

[Algi]

Mě by spíš zajímalo, k čemu mu bude 64-bitové OpenOffice? To hodlá pracovat s dokumenty, které zabírají více než 3 giga v paměti? Protože jiné využití v dnešní době 64-bitů opravdu nemá. A namlouvat si, že jsou takovéto programy díky tomu rychlejší je bláhové...

[Käyttäjä 11133]

Nepotřebnost 32-bit knihoven?

[Algi]

Hm, myslíš, že chce dosáhnout ideálu, kde v systému bude mít všechny knihovny a programy 64-bitové? K čemu je to dobré? Já mám taky plně 64-bitový systém, ale s výjimkou Apache a Netbeans mi všechny procesy běží jako 32-bitové. A že by mě to nějak extra trápilo, to se říct nedá. Jediný program, který bych snad 64-bitový pochopil, by byl asi Photoshop, popř. další programy od Adobe. To jsou nenažranci paměti. Ale třeba Firefox, nebo OpenOffice? Nevím, nechápu...

[Käyttäjä 11133]

Jo, proč ne? Kdybych měl 64-bit systém, taky bych si tam nechtěl zatahovat 32-bit knihovny.

[Algi]

Nj, ale nemáte s tím na Linuxu problémy? Třeba 64-bitové pluginy pro Firefox, apod. Já si totiž pořád bláhově myslím, že 64-bit je zatím více v módě, než k užitku. Krom toho, místo na disku mi to nebere a mám aspoň jistotu, že mi tam poběží programy jak pro 32-bit, tak pro 64-bit. Samozřejmě se těším, až technologie překladačů dospějí na takovou úroveň, že budou produkovat rychlejší kód, než na 32-bitovém systému. Ale něco mi napovídá, že to asi jen tak nebude...

[David Watzke]

Už tomu tak je, ale spíš než o OpenOffice.org a podobně jde o multimédia, třeba video encoding. Link.

[Algi]

Aha. Díky za odkaz. Docela zajímavé výsledky. S těmito druhy programů ja bohužel nemám moc zkušeností, takže se nechám rád poučit. To víš, v programu na personalistiku je mi 64-bitů platný, jak mrtvýmu trenýrky Nám říkali, že 64-bitů většinou nemá moc velký význam, pokud nepracuji s velkými objemy dat... Asi jsem zapomněl tu druhou část, kde se zmiňovali právě o multimediálních programech Já si spíš z té přednášky pamatuju hrátky s Core Animation, ale to už je jiné téma.

[trekker.dk]

To by mě zajímalo, jestli při přechodu z 16bit na 32bit x86 taky byla všude spousta keců na téma "a k čemu vám to je... to budete jako dělat s dokumenty, které mají víc, než 65kB?"

[JS]

No jo, ale 65kB napisete za tyden, kdezto 3GB nenapisete za cely zivot. :) Takze ta otazka u 64-bitovych programu je opravdu na miste.

[xkucf03]

Význam 64 bitovosti by se neměl omezovat jen na větší RAM. A taky člověk ty gigabajty nemusí napsat, ale třeba namalovat, nafotit, nafilmovat...

BTW: 64 bitový procesor mám už několik let, ale 64 bitový systém jsem na něj nahodil teprve nedávno a jen experimentálně. Pořád to ještě není ono, chtělo by to nějaký velký třesk, prostě aby všichni přešli a programy a systémy se dělaly všechny 64 bitové

[trekker.dk]

Mě spíš zajímá, proč nepřejít na 64bit - jaký to má důvod? Vždyť většinu programů by nemělo být problém přeložit na 64bit procesor ve chvíli, kdy je dostupný překladač.

Výjimkou jsou samozřejmě programy, které používají assembler (s mp3lib v mplayeru jsem měl jednu dobu problém) - těch tolik není - a potom programy, které jsou napsané prasácky (nebo někoho napadá jiný důvod, proč není 64 bit flash plugin?) - těch bude asi víc.

Zkrátka mi přijde, že jediný závažný důvod, proč nepřejít na 64bit, je lenost skrývaná za spoustu důvodů, proč to nemá cenu.

[Käyttäjä 11133]

nebo někoho napadá jiný důvod, proč není 64 bit flash plugin?

Možná proto, že ten virtuální stroj tam je je napsaný v assembleru...

[trekker.dk]

Ano, ano, máš pravdu - flash je rychlý a efektivní, to by programu psaném v assembleru odpovídalo.

[phero]

Ja zas mam vsechny aplikace 64bit a taky me to netrapi

[David Watzke]

No, je pochopitelný, že člověk, kterej používá 64-bitovej systém, chce 64-bitový aplikace.

[petr_p]

Ne každý si pořizuje novou architekturu kvůli adresnímu prostoru. Např. NX bit nebo dva krát větší registry taky mohou být důvod.

[Majkls]

nx bit umí i 32bitové core duo, ale to jen pro doplnění. 64bit je ale dobrý především, tam, kde potřebujete výkon. třeba u takových databází je to sakra znát.

[Pev]

No já bych to třeba uvítal, pač bych mohl instalovat devel verze do 64bit distribuce.

[michich]

Což na distribuci, která má multilib, není problém.

[neal_cz]

Vždyť už nějakou dobu je. Tak 2 - 3 roky...

[Smajchl]

No to je super Všichni Windowsáci co chtěj vypadat drsně používaj OOXML - aby bylo vidět že maj novej Ofis. To že v tom je jenom malá tabulka hodnot, kterou bych rád taky viděl je nesere. Už se těším, až to půjde otevřít.

BTW: Umí MS Office 2007 (nebo 2008 - já nevim kterej je novej) otevírat ODF ?

A to že na Mac OSX běží bez X11 je skvělý, ten starej byl nepoužitelnej jak to pod ixkama bylo pomalý, ještě že existuje je Neo Office.

[Vin]

BTW: Umí MS Office 2007 (nebo 2008 - já nevim kterej je novej) otevírat ODF ?

V základu ne, musí se myslím nainstalovat plugin (odfláknutej od Microsoftu nebo spolehlivější od Sunu).

[xkucf03]

nebo spolehlivější od Sunu

Když jsem ho zkoušel posledně, tak si ten filtr někde v pozadí spustil OpenOffice, přechroustal dokument a ten se otevřel ve Wordu. Rychlost a pohodlnost dost mizerná. Navíc tam otravovala hláška z Wordu, jako že ten formát ve kterém to chci uložit není dost dobrý a jestli to radši nechci v .docu. Jasně že za to Sun nemůže a je to lepší než nic, ale k praktické použitelnosti to mělo ještě daleko. Změnilo se od té doby něco?

[neal_cz]

OOo běží na Mac OS X IMHO nativně už od 2.4. Trojková řada tuto vymoženost přináší akorát pro PPC macy.

[Boris Dušek]

no ta 3.0 beta je jen pro Intel Macy

[neal_cz]

Jo, ale OOo 2.4, který na Intel Macu používám a je nativní, jsem pro PPC nikde nenašel. Na něm jsem zatím měl pouze řadu 2.3, nebo nějakou starší betu (080314)

[Frt]

Je (nebo bude) někde možnost stáhnout betu 3 v české verzi ?

[petr_p]

ftp://ftp.linux.cz:/pub/localization/OpenOffice.org/devel/BEA300/BEA300_m2/Build-1/"OOo_BEA300_m2_LinuxX86_install_cs_rpm.tar.gz (157 MB)

[Frt]

Díky za odkaz