LibreOffice 3.6.0 beta 1

 

LibreOffice A Document Foundation örömmel jelenti be a LibreOffice 3.6.0 első bétaverzióját. A LibreOffice 3.6.0 a negyedik főkiadás lesz a LibreOffice két éves történetében, és sok szép új funkciót tartalmaz. A LibreOffice 3.6.0 beta 1 nem ajánlott a mindennapi munkára, erre a célra a LibreOffice 3.5.4 megfelelőbb.

A kiadás Windows, Linux és Mac OS X rendszerekre érhető el az előzetes kiadások letöltési oldalán.

Megjegyzés Windows-felhasználóknak: ez a bétaverzió a jelenlegi stabil verzió mellé telepíthető, így egymás mellett is tesztelhető a stabil és az új kiadás. Ennek mellékhatása, hogy a beta nem ír a registrybe, tehát a fájlformátumokat nem fogja magához rendelni, és nem regisztrálja a shell extensionjeit a Windows Explorerhez. A registry írása a WRITE_REGISTRY=1 property beállításával kikényszeríthető (msiexex /i LibO-Dev_3.6.0beta1_Win_x86_install_multi.msi WRITE_REGISTRY=1).

A 3.6.0 új funkcióinak listája a wikioldalunkon készül, még szerkesztés alatt van.

Az esetleges hibákat a FreeDesktop Bugzillába kérjük jelenteni.

Jó módja a bétatesztelésnek a manuális tesztelés. A tesztesetektől a TCM wikioldalon lehet többet megtudni.

Az ismert és a kijavított hibák listája szintén a wikiben olvasható, a 3.6.0 beta 1 kiadási megjegyzéseiben.

A cikk szerzőjéről

Tímár András 1999-ben kezdett foglalkozni a szabad szoftverek honosításával. Magalakulásakor csatlakozott az FSF.hu Alapítványhoz, ahol vezető tisztséget is vállalt. 2002 óta dolgozik az OpenOffice.org (2010-től a LibreOffice) magyar verzióin. 2011-től főállású LibreOffice-fejlesztő, jelenleg a Collabora Productivity Ltd.-nek dolgozik.

Hozzászólások

  1. Hegedüs Zoltán szerint:

    Nekem konkrétan nincs szükségem a funkcióira. Én amondó vagyok hogy javítsuk ki az összes bejelentett hibát, csináljuk meg hogy 32 biten használja a CMOV, … utasításokat mert az gyorsabb mint az ugrások, le lehessen fordítani 64 bites Windows-ra, valamint BSD-re, Linuxra, AIX-ra, z/OS-re, SunOS/Solaris-ra, architektúrákból Power, ARM, Itaínium, UltraSPARC, mindből 32 és 64 biteshez is, és ha ez mind készvan, akkor majd ráér 1000-es verziót írni. Remélem a 3.6-osnál már minden bejelentett hibát kijavítanak 3.7-es vagy 4-es írása helyett.

  2. Bendegúz szerint:

    Ahhoz képest, hogy nem ír a reg-be, az alap betűkészleteket csodásan feltelepítette… Apropó, a betűkészletek telepítését nem lehetne választható funkcióvá tenni a telepítőben? Minden egyes verzió után nagytakarítás a fontok között, mert mindig elfelejtem írásvédetté tenni a Windows Fonts mappáját…

    Egyébként csatlakozom – véleményileg – az előttem szólóhoz.

    • A registry írásának semmi köze a betűkészletek telepítéséhez. A betűkészletek telepítését lehetne választható funkcióvá tenni, csak erre még nem gondolt senki. Sokan úgy vélik, hogy így is túl sok az opció. Mac OS X-en pl. egyáltalán semmi válogatási lehetőség nincs. Engem nem zavarnak a betűkészletek, ma már nem mondhatjuk azt, mint 15 éve, hogy sok helyet foglalnak és lassítják a gépet. Elférnek. Azért lehet, hogy megcsinálom, hogy opcionális legyen, majd meglátjuk.

      A LibreOffice közösségi projekt, a hozzájárulók azzal járulnak hozzá, amivel akarnak. Ha nektek az Itaniumra portolás tetszik, csináljátok azt. Jó kis desktop architektúra, úgy hallottam, meg terjed is, mint a szélvész. Érdemes sok ezer munkaórat beleölni. :) De viccen kívül, bármit szeretnétek segíteni, szabad a pálya, és mindennek örülünk. A hibajavításoknak főleg.

      Sok hibát javítunk, de azzal nem lehet villantani az újságokban és a konferenciákon, hogy mennyit javítottunk. Az rossz PR, mert akkor azt hiszik a tájékozatlan emberek, hogy ó, mekkora szar volt ez, hogy ennyi hiba volt benne, és biztos még mindig szar. Kellenek az új funkciók. A legtöbbnek még értelme is van. Egyébként nekem sem kell egyik sem, alig használom a programot, mert a munkámhoz nem kell, csak fejlesztem. ;-)

  3. Sziasztok!

    Én spec. nagyon örülök az új funkcióknak, igaz a Writeren és az Impressen kívüli részét egyelőre nem használom (ki). Ráadásul nekem a „munkámhoz” is kell.

    Egyetlen dolgot sajnálok – talán – hogy a portable változatot nem a TDF készíti el, ill. a bétákból (alfából) nem készül portable.

    Tetszik a 3.6 újdonságlistája, a bevezetéssel kapcsolatban ajánlásokhoz meg ott a „kiadási politika”, ha valakit érdekel.

  4. Hegedüs Zoltán szerint:

    Mivel nem kifejezetten hibabejelentés, jobb híján ide írom.

    Sokszáz oldalas dokumenmtumnál még mindig lassú a megnyitás, mentés, pdf export, a sebességen semmit se változtat ha kikapcsolom a .odt file méretének optimalizálását, ami gondolom tömörítést jelent.
    Jó lenne ha .txt file megnyitásakor és egész file beszúrásakor megkérdezné hogy mi a kódolása, és nem kellene direkt értelmetlen vezérlőkaraktereket beszúrni hogy rákérdezzen.
    Korábban egy kis darabig nagy szöveget ki lehetett jelölni Shift+PageUp/Down-nal, most nem, gondolom a 3.5.4.-ben tűnt el. Jó lenne visszahozni, mert kurzorral elég lassú. A 3.5. sorozatból a mégrégebbiekben sincs benne, lehet hogy csak a 3.5.3.-ban volt.

    Az itteni hozzászóláshoz e-mail címet kell megadni. Ha ott lenne hogy nem jelenik meg, valódit írnék oda és nem azt hogy secret@secret.secret, ugyanis nem hiányzik napi 1 millió SPAM hogy a weben látja minden e-mail cím gyűjtő program.
    Én C++ program dokumentációjának elkészítéséhez használom a Writer-t, így furán hangzott hogy aki fejleszti annak nem kell a munkájához.

    Nálam egyébként ez a fontossági sorrend:
    – Nekem kellő funkciók
    – Ne legyen benne hiba
    – Könnyű kezelhetőség
    – Sebesség
    – Forráskódnál: minél többéle fordítóprogrammal le lehessen fordítani
    – Minél többféle operációs rendszeren menjen
    – Minél többféle architektúrán menjen (a MIPS64-et előzőleg kihagytam)
    – Egyéb funkciók
    Korábban kifelejtettem még az érintőképernyős tabletekre való portolást ahol nincs egér. Például Windows 8 Metro felülete jó példa erre.

    A portolás egyébként a forráskód átnézésével jár, tehát hibákat vehetünk észre, akkor is ha nem utasításkészletre hanem operációs rendszerre portolunk. A C++ kódnak csak a töredékét kell módosítani, csak az assembly betéteket kell újraírni, azok meg úgyis rövidek meg egyszerűek, és operációs rendszerre portolásnál át se kell írni.

    A sebességgel kapcsolatban: a C++ fordítónak meg lehet adni hogy rövid ugrások helyett CMOV utasításokat használjon ami gyorsabb. Ehhez csak annyi kell hogy 686-os utasításkészletet használjon. Egyébként hardveres vektorműveleteket is lehet használni de egy szövegszerkesztőhöz az nem nagyon kell, a Calc-hoz annál inkább kellhet, és ha a Draw sokat tud, ahhoz is. Az assembly betéteket is át lehet írni feltételes ugrások helyett CMOV-osra. Itt az alapelv hogy a programrész előtt és után ugyanott van a vezérlés, csak közben van feltételvizsgálat, ez kikerülhető ha az összes esetre kiszámítjuk a regiszterek és a memóriacellák értékét, és aztán egy feltételes értékadással, egy CMOV-val beírjuk. Elég azokat kiszámítani amik megváltozhatnak. Ha egy memóriában levő változó nem biztos hogy megváltozik, akkor az eredeti értéke is az egyik lehetséges eset, amit visszaírhatunk. Ekkor először regiszterbe tesszük, majd azt írjuk a memóriába. Ha a változók között lehet átfedő címtartományú arra ügyelni kell. Ilyen használható például ha előjeleset hasonlítunk előjeltelenhez, mert azt a C++ nem tudja, de * / % esetén se tudja keverni. Vagy ha 32 bites utasításokból kell 64 biteseket építeni. Amikhez nem kell CMOV: xchg, mov, movzx, movsx, test, and, or, xor, not, add, adc, sub, sbb, mul, push, pop, bswap, neg, inc, dec. Az utóbbi 3 nem tud átvitelt tehát a felső részre nem jó, és az alsóra se mert nem állítja be az átvitelbitet, így 0-x, x+1, x-1 -ként lehet megoldani, tehát maga a neg, inc, dec utasítás ekkor nem fordul elő a kódban. A movsx 2 regiszteres méretre egyszerűen mov majd sar 31. Amihez jó ha van CMOV: bt, btc, btr, bts, bsf, bsr, shl, shr, sar, shld, shrd, rol, ror, rcl, rcr, imul, div, idiv, cmp. Ilyen #include file-okat tudok küldeni, de szerintem nincs rá szükség, mert egy szövegszerkesztőnél nem gyakori műveletek, csak egy példát írtam. C++ kód esetén a fordító főleg a ?: fordítására használja, illetve rövid if-ek esetén, amikor mindkét ágban értékadás van ugyanarra, vagy ugyanazt a függvény hívjuk más paraméterrel, vagy mindkét ágban return, throw, … van.

    • Andras Timar szerint:

      A .odt file méretének optimalizálása azt jelenti, hogy az xml-ekbe nem ír felesleges whitespace-eket, gyorsabb parse-olni, de nehezebb embernek elolvasni.

      Nekem megy a kijelölés Shift+PgUp/PgDown-nal. 3.5-ben és 3.6-ban is.

      A hozzászólásnál megadott e-mail cím nem jelenik meg az oldalon.

      A nem használattal kapcsolatban túloztam, pl. szoktam előadásokat írni Impressben, én szerkesztettem a LICENSE.odt-t, meg tesztelek dolgokat. De nem használom nap mint nap, és nem is értek hozzá különösebben.

      Mostanáig fogalmam sem volt a CMOV létezéséről, de úgy tűnik, nem csodaszer, Linus Thorvalds pl. nem javasolja (http://ondioline.org/mail/cmov-a-bad-idea-on-out-of-order-cpus). Ha valami konkrét mérésed van, hogy egy compiler kapcsolótól a LibreOffice valamelyik területen jelentősen gyorsul, az nagyon jó volna, és örömmel vennénk, ha megírnád a libreoffice @ lists.freedesktop.org listára. Ezen kívül is bármilyen hozzájárulásnak, patchnek örülünk, az elméleti fejtegetéseknek nem annyira, ha azt nem támasztja alá kód vagy mérés.

      • Hegedüs Zoltán szerint:

        Érdekes módon most nekem is megy a kijelölés közbeni lapozás, eddig nem ment.
        Mindig tanul az ember, azt hittem CMOV-val sokkal gyorsabb. Egyenlőre akkor nincs mit megírnom a listára, mert azt gondolom biztos tudják hogy például 64 bitesre fordítva gyorsabb.
        Én szinte csak C++ program dokumentálásához használom (programozói dokumentáció), de mégis azt mondom hogy sűrűn használom, és emiatt több LibreOffice könyvet is elolvastam és kijegyzeteltem, a kijegyzetelt dolgokat természetesen be is gépeltem.