A z meho pohledu je to absolutne nepouzitelne, to na co jsem obvykle v OOo nadaval ze je v calcu pomale, tak KOffice spreadsheet to zabije uplne.
Jako prohlizec to asi nejakou sanci ma, nezkousel jsem to dost dlouho abych tohle mohl soudit, ja jen zkusil zakladni funkcnost v tabulkach, 3× to zabil pres task manager a s KOffice jsem asi na delsi dobu skoncil. Presto doufam ze se to brzo zlepsi, protoze po „ribonizaci“ OOo to asi nevydrzim a budu chtit pouzivat neco jineho.
Konkretne co jsem zkousel jako prvni (a posledni diky vysledku pokusu): otevrit tabulku, dejte si nekam do prvniho sloupce treba 30× „=ROW()“, pak u prvniho z nich napravo dejte „=Ax+1“ a rozkopirujte doprava asi tak 20×, a pak vlevo nahore dejte soucet leve/horni hodnoty „=Ay+Bx“, tohle rozkopirujte na celou 20×30 tabulku. Ted zmente vychozi Ax hodnotu z „=ROW()“ na nejake jine konkretni cislo… v horsim pripade KO zhebne (pri „velke“ tabulce prudce roste spotreba RAM nekolik minut, dyl nez jsem vydrzel cekat), v lepsim (pri malych tabulkach) prepocita nejblizsi 1–2 hodnoty a zbytek tabulky necha na starych hodnotach, pri opakovanem mackani F9 postupne po 2 bunkach prepocitava ten zbytek.
Podotykam ze 30×20 nepovazuji za velkou tabulku, bezne pouzivam v OOo podobny system tabulek jeste s neprimou indexaci skrz HLOOK indexovani o rozmerech pres 50×50, kde pri zmene vychozich udaju uz na OOo lze videt jak dlouho bunky prepocitava (i kdyz treba v ASM by to CPU zabralo asi tak 10–20 instrukci na bunku, celkem tedy tak 25k-50k jednoduchych instrukci, jen plus, minus a vyber hodnoty z pameti). Tak jsem si myslel ze OOo je pomale…
KOffice 2.0 nebylo ani určeno k běžnému použití. Psát při vydání verze 2.2, že jsem zrovna zkoušel 2.0, mi připadá dost mimo. Rozhodně hodnotnější by bylo zjistit, jestli je popsaný problém vidět i ve verzi 2.2.
Verze 2.2 stále ještě není označena za verzi pro široké použití, v každém případě by tohle ale stálo za nahlášení (kecat na fóru umí každý, nikdo ale nic nereportuje).