Vypada to naozj zaujimavo - vzdy sa na nove verzie tesim. Osobne preferujem poratble verzie LO. Mam uz dlhsiu dobu ale jeden dost zavazny problem a neviem cim to je - a sice pri kopirovani textu do schranky (ctrl+c) trva bezmala aj 15-20 sec kym tento text mozem vlozit do inej aplikcaie... netusi nahodou niekto cim to je?
Tak timhle jsem trpěl taky a taky mně to dost štvalo. Ale kupodivu to tak blbnulo jak na OO, tak na Libre, tak i ve win programech. Onehdy jsem nainstaloval poslední OO a LO mám 4.1.1.2 a přestalo to.
Jenže taky jsem přitom vyčistil cache adresáře v Opeře, protože jsem si všiml, že nemám zapnutý automatický mazání při vypnutí. Pak jsem ještě našel nějakou havěť avastem.
Takže jestli jsem tam měl natáhnutej nějakej bordel z netu a nebo to byla chyba OO fakt nevim.
Co jsem tak pročítal web (hledaje rozdíli v načítání LO/AOO na různých OS, tak jsem došel k tomu, že pomalé načítání se projevuje na blbě nastavených Windows. Jak nastavených, na to jsem už přesně nepřišel.
S verzí LO 4.1 jsem začal mít trochu problémy: několikrát to při práci s velkými tabulkami vytuhlo. Když je edituji, pracuji s klávesnicí - enter a kurzorové šipky. Nejprve se jakoby textový kurzor přestane pohybovat, kam ho posouvám a potom, když vezmu myš, abych ho tam "vrazill" myší, tak to spadne. Jená se o tabulky nad 1000 řádek a ve více, jak polovině řádek 4 dlouhé vzorce (vedle dalších dat). Nejsem schopen reprodukovat, ale stalo se mi to tak 3-5x.
Ano podobné problémy určitě byly, ale hodně se toho už odstranilo. Mně například na 4.2. Beta nejde End v nějaké kombinaci. Když to přestavím, tak to chvíli chodí a pak zas z neznámého důvodu je klávesová zkratka nefunkční a musím to znovu nastavit - ale to se dá rozdýchat. Možná dělám nějakou chybu já.
Ty pády jsem také zaznamenal, ale ne na 4.1. Poslední stable by měla být asi 4.1.5, takže pokud nemáte tuto verzi tak se není asi čemu divit.
Ty pády mohou být přetíženám (nedostatkem nějaké paměti - nejspíš stránkovací.) Já mám takový dojem, že vývojáři to nenechají vytuhnout na doraz, ale shodí to bez nějakýcm zábran do outu. Je totiž zajímavé, že se mi to po pádu obnovuje na 100% stavu před pádem - například ne do poslední zálohy, ale fakt do posledního kliknutí.
Pokud vylepšili právě tuto vlastnost zálohy pro nenadálé události, není ani důvod nechat tejrat mašinu.
Poslední stabilní verze je 4.1.4, verze 4.1.5 bude vydána až týden po 4.2.0. Verze 4.2.0 má řadu věcí dost zásadně přepsaných (například skoro celý základ práce s tabulkami), takže vyřeší některé neduhy dosavadních verzí, ale současně tam mohou být nové chyby, vzhledem k "syrovosti" té implementace.
Co se týká nedostatku paměti, to je dost nepravděpodobné. Je samozřejmě rozdíl mezi různými operačními systémy (každý s pamětí pracuje trochu jinak), ale nezažil jsem případ, že by vinou AOO/LO paměť došla (ani ve Windows, ani v Linuxu). Například v Linuxu se to skoro ani nemůže stát, protože ve výchozím nastavení aplikace dostane tolik paměti, kolik si vyžádá - pokud by paměť v systému skutečně došla, jádro by se ji nejdřív usilovně snažilo nějak získat (maximální odswapování, redukce diskové cache) a v případě neúspěchu by se aktivoval OOM killer, který by začal sestřelovat procesy podle jejich vypočítané "žravosti". Rozhodně by nenastal pád aplikace "jen tak".
Já z Windows takovou zkušenost mám. Vyskočí hláška, že systém zvětšuje stránkovací paměť a do té doby nemám nic dělat protože hrozí pád. Často se mi dařilo obdržet důsledek dřív nežli upozornění. Fungovalo jen manuální nastavení stránkovací paměti na doraz. (Ale ani tak jsem se úplně neubránil.)
Stránkovací paměť mám ve "W" nastavenu do 2 disků a na maximum. Pro AOO i Lo nastavuji v "možnostech" jen 10 kroků zpět a podobné věci. jenže v LO se to nastavuje trošku jinak - například "jen na obrázky" a "vložené objekty". Dříve jsem nastavoval nejn čas po který se udržuje aktivní aplikace v paměti, ale paměť na soubor ap. - nemluvě o počtu kroků "zpět", které jsem v nouzi nejvyšší nastavil na 2 (normálně 100 přednastaveno).
Když je to moc velké, paměť například není včas uvolněna a jiné zádrhele, které ani nezjistím. LO spadne, ale OS ne.
Stránkovací paměť podle mne není jen prostor na disku vyhrazená jako rozšíření pro udržení objemu informace. Také to musí souviset s cashováním na disk, nebo vyhrazením prostředků operační paměti. Tam jde určitě o priority úloh, přímé přístupy do paměti a plno věcí o kterých asi ani nic nevím.
LO RC1 prakticky téměř vždy skončí po vypnutí hláškou, že něco na adrese....tuším že operace read... nebylo možno provést, a nejde o pád aplikace - jen o běžné vypnutí křížkem ap.
Když skutečně LO spadne, opravdu se obnoví až na poslední uhození klávesy, což jsem nikdy před tím neviděl. Samozřejmě v paměti poslední operace nejsou, ale když například něco dělám, tak se vše až k tomu místu kde to spadlo skutečně obnoví. Z takového chování OS nepodezřívám.
Paměť skutečně dojde - ale proč není jisté. Faktem je, že se musí někdy něco uvolnit, aby se jen stále neplnila - pak v podstatě "přeteče" a bum.
Zvětšovat nastavení moc smysluplné není, ale když dělám se soubory etalonů, které obsahují mnohem váce řádků, nežli sešit, musím testovat kam až se dá zajít. Pak to posouvám na extrémy jak to jen jde. Netvrdím, že totéž dělají, nebo ne - jiné "W - čka", nebo nedej bůh Linux. Je to na na mých XP Sp3.
U Windows bohužel nevím, jak přesně funguje správa paměti. Hlášku o zvětšování stránkovacího souboru a odmítnutí požadavků na alokaci paměti znám taky, ale ještě jsem se s ní nikdy nesetkal u OO/LO.
Pokud dostáváte u RC1 (mimochodem už je k dispozici RC2) hlášku, že nebylo možné provést nějakou operaci a program spadne, bylo by žádoucí to ohlásit (https://www.libreoffice.org/get-help/bug/). Bude to téměř jistě chyba v aplikaci, která se dá opravit.
jinak stejně se vždy přesvědčím u zdroje
http://download.documentfoundation.org/libreoffice/stable/
Teď jsem koukal, že reaguju na příspěvek z ledna, tak se omlouvám.
Zdravim. Tak ma napadlo, ze by bolo velmi uzitocne, aby sa v Calcu zvysil maximalny pocet riadkov. Teraz po implementacii OpenCl by to malo este vacsi zmysel. Casto sa mi stava, ze potrebujem importovat vacsi csv subor s niekolkymi milionmi riadkov a samozrejme to neide. Zatial si pomaham pri spracovani tychto csv suborov pythonovskymi skriptami, no bolo by to jednoduchsie, keby moje ulohy sli riesit v Calcu. Je aspon nejaky vyhlad, ze sa v blizkej dobe zvysi maximalny pocet riadkov?
Tohle asi zatím nikdo nežádal. Byl už požadavek na větší počet sloupců: https://bugs.freedesktop.org/show_bug.cgi?id=50916 Těch je totiž zatím jen 1024, což může dělat problémy hlavně při importu z MS Office, kde je limit 16384 (řádkový limit je i tam 1048576, takže s ním problémy nejsou).
Upoutalo mě tam toto:
„First we would need to rework all internal cell datastructures like I did for sheets in 3.5. We still use fixed size containers for columns. That means that increasing the column limit will increase the the memory needed for every sheet extremelly. The column limit of 1024 is a design decision by us. If you are really in need for LibO with a bigger column limit you can easily build one yourself and I tell you the line you need to change to increase the limit.“
Z toho plynou dvě věci: jednak že to lze relativně jednoduše změnit (ovšem ve zdrojáku a pak se to musí překompilovat), a zadruhé že by se to teď po přepracování mohlo řešit. Předpokládám, že u řádků je to prakticky stejné jako u sloupců.
Tak nejvíc mě dostala ta změna se smajlíkem :D ... Každopádně, už se těším, až dorazí 4.2.0 do repozitářů :-) Neví někdo kdy to tak bude? (mám tuším přidané LO ppa )
Zdravím, zkoušel už někdo řešit to číslování nadpisů ve verzi 4.2 nebo nadpisy typu:
1. BLA
1.1 blabla
1.2 bla bla,
vážně neudělám jinak než ručním psaním?
kdyby tak nekde existovala dokumentace k politikam, nebo k registru HKEY_LOCAL_MACHINE\SOFTWARE\Policies\LibreOffice
Dnes jsem hledal vsude mozne asi pul hodiny a nic :-(
Všechno pěkné. Wokna 7, poklikám na soubor, otevřeno za 5 vteřin. Spustím Writer/Calc..., dám menu Otevřít, nebo něco napíšu a dám Save/"Save as" a čekám skoro 3 minuty, než mi komplet naběhne dialogové wokno otevření/ukožení souboru. Tudíž pro mě nepoužitelné. Všiml jsem si, že s tímhle měly trochu problém i předchozí verze. Ale u verzí 3.x to bylo něco přes 10 vteřin a i tak to byl opruz. Mašina gigahetze a gigabajty a já čumím na přesýpací hodiny, jako u Win 3.1 na na 0,5 GB RAM na starém AT. Asi skončím u produktů jedné nejmenované společnosti, předribbonové verze. Možná to na Linuxu nedělá, ale pro práci v LO nemíním přebootovat nebo spouštět virtuální mašinu. Pro satelitní kartu bahužel potřebuji Wokna.:-( Co to proboha je, vždyť operace se soubory by měly být prioritou. Od skinovatelnosti a ikonek se neodvíjí spokojenost uživatele.
Nepochybuji o tom, že na woknech jsou LO pomalejší - zkušenosti z práce. Ale pokud máte trochu "normálnější" hw konfiguraci, rozdíl nepoznáte. To je zase zkušenost z domova...
Problém bude nejspíš ve vaší mašině, ne v LO. Pominu-li W7 s SSD diskem, kde to běhá bleskově, tak i na starším netbooku s Atomem běhá LO velice svižně. Skoro bych podezříval antivirový program, který dokáže být na starším HW dost velká brzda, na netb. s Atomem žádný antivir nemám.
Uff, tak podruhé. Vnouče na chodbě povypínalo všechny jističe.:-)
Rezidentní antivirus nepoužívám.
Mohl za to firewall (Online Armor). LO se mi z nějakého přehlédnutí nainstalovalo na disk C a mělo být na D, takže ho FW znal i neznal. Po vypnutí FW to bylo jak blesk. Po opravě pravidla asi 5x pomalejší, ale snesitelné. Jdu LO odendat ze systémového disku a nainstalovat kam patří.
Projevuje se ten problém jen v systémových dialozích nebo i v těch přímo od LibreOffice (v nastavení: LibreOffice -> Obecné -> Dialogy Otevřít/Uložit, zaškrtnout Použít dialogy LibreOffice)? Jinak spíš to vypadá na problém systému, může to dělat již zmíněný antivirový program, může to být problém se síťovým diskem (pokud je nějaký připojený), nebo mohou být nakopnuté systémové registry... Prostě důvodů může být mnoho a příčina přímo v LO je poměrně málo pravděpodobná.
Je zajímavé, že pokrok jde vpřed tak rychle, že si málokdo všímá historických souvislostí : Win 3.x by se z půl GB RAM asi zbláznily - tenkrát to běhalo na 2-4MB, šťastnější na 8 nebo 16 MB.
512 MB RAM bylo maximem pro Win 9.x, s více to blblo.
Pokud jsem použil nesprávné vlákno, omlouvám se. Jako začátečník v LO mám takový problém. Potřebuji v makru CALCu ukrýt několik řádků. Spustím nahrávání, označím řádek a dám v menu "skrýt". To opakuji pro těch několik řádků. Ukončím nahrávání, uložím. Po odstarování makra na původním dokumentu, se ukryje jeden řádek (tam kde je "kurzor" ....."vybraná buňka"). V makru není mnou označená (při nahrávání) oblast vůbec zaznamenána. V EXCELu vše stejně provedené funguje. Dělám něco špatně, nebo tyto fce nejsou vůbec implementovány ?
Záznam maker je nedokončená, experimentální funkce, která ani není ve výchozím nastavení povolena. Tedy je to skutečně tak, že to není doimplementováno.
Děkuji za odpověď. Pokud se najde programátor ochotný se touto problematiou zabývat, jsem k dispozici s testováním funkčnosti. Je škoda tuto oblast jinak velmi solidního projektu zanedbávat. Bohužel moje schopnosti programování končí někde u praktického použití těch maker ....takže mohu přispět jen tímto kouskem práce....
Zacali sme nasadzovat verziu 4.2.0, mala nejake problemy tak sme presli na 4.2.1. Po nasadeni na par stanic sa zistilo, ze u vacsich XLS tabuliek cca nad 20MB im poskodi vzorce a tabulku zmensi na 16-17MB. Potom polovica vzorcov nefunguje. U LibreOffice 4.1.5, alebo OpenOffice 4.0.1, to nerobilo. Takze sa vraciame k tymto dvom verziam.
Chtěla bych se zeptat - v dřívějších verzích libre office fungoval nástroj vlnka - v nové verzi nefunguje a ani když si stáhnu starší verze tak mi nefunguje. Potřebovala bych poradit, co s tím, popřípadě jaký nový nástroj stáhnout a přidat do verze 4 místo vlnky.
Děkuji.