LibreOffice 6.0.2

LibreOffice logó A The Document Foundation bejelentette, hogy megjelent a LibreOffice 6.0.2, a 6-os sorozat második hibajavító kiadása. A fejlesztők kb. 50 hibát javítottak a 6.0.1-hez képest.

A változások résztes listája megtekinthető a TDF Wikiben: RC1.

“LibreOffice 6.0.2” bejegyzéshez 35 hozzászólás

  1. Csak ülök, és mesélek.
    Új verziók megjelenésekor bele szoktam nézni a javított hibák listájába, megnézem a magyar közreműködők tételeit (is). Itt jött szembe velem Kelemen Gábor úr, és az általa javított Draw színpaletta hiba. Nyilván megnéztem, és itt vágott mellbe, hogy a magyar LibreOffice lefordította az RGB-t VZK-ra.
    Lehet, hogy nem kellett volna… (Nem most történt, már az 5-ös ágban így volt, az 5.4.2-ben biztos.)
    Lehet, hogy másnak rövidebb (vagy hosszabb) idő alatt esik le, hogy ez mijafene, de az élmény maradandó volt.
    Mese:
    Miután a 90-es évek végén a “Számítástechnika” hetilap szerkesztőjeként napi feladatom volt az angol IT-kifejezések magyarítása, arra vagyok szocializálva, hogy lehetőleg magyarul nevezzük meg a dolgokat. Heves hányingert kapok a “rúter” szótól – pedig a bájthoz és a fájlhoz hozzászoktam. (Nem mellékesen a nevezett eszköz nem útválasztó (router), hanem kapcsoló (switch)…)
    Soha, SOHA, S_O_ H_ A nem jutott volna eszembe az RGB-t lefordítani.
    Részt vettem egy megbeszélésen hazai Microsoft-fejlesztőkkel, ahol az Excel függvényneveinek magyarításáról (is) szó volt, mi (a Számítástechnika szerkesztői, élen Brückner Hubával, az IT-magyarítás fáklyahordozójával) azt mondtuk, hogy nem kellene, mert csak bonyodalmat okoz. Így született meg pl. a SZUMHA… (nem hallgattak ránk).

      1. Hasonlo emelyges szokott elfogni, amikor az Excel-ben magyaritott VÉL() fuggvennyel hoz ossze a sors, ami eredetileg RANDOM() volt, csak _f_e_l_t_e_t_l_e_n_u_l_ le kellett forditani. A “bájt” es a “fájl” irasmod nekem is bizarr volt eredetileg, de egesz hamar megbaratkoztam vele.

        Szerencsere a magyaritas ket koronazatlan kiralya nem eresztett gyokeret, de ha mosolyogni tamad kedvem, akkor gyakran felidezem oket:
        – kurzor helyett “helyőr”
        – weboldal helyett “ottlap”
        A Chip magazinban olvastam oket anno. Ilyenkor mindig kuncogok egy kicsit. 😀

        A VZK rovidites viszont az en szemoldokomet is felszalajtotta.

        Persze nem a magyar nyelv az informatika egyetlen ellensege. Nemetben is vannak olyan forditasok, amik bar ne lennenek, mint pl. Schnittstelle a vagolapra. Szoval eros mezonyben kell helytallnunk, na! 🙂

        1. Festplatte… olyan bájos!
          És a francia? Fichier (fájl), Megaondes (megabájt…)

          Komolyabban: az internetkorszak elején a megtanulás, a felzárkózás fontos volt, ezért erős volt a motiváció a kifejezések honosítására.
          Ma már nem az. Az Y és Z generációt nem érdekli a nyelvi szabatosság, helyette az információ elküldése a fő szempont, amit nem ítélek el. A nyelvet nem a szakemberek, hanem a népesség alakítja, ebbe bele kell törődnünk.

          1. En a magam reszerol ugy vagyok vele, hogy nem banom, ha a magyar nyelvbe keverednek angol szavak, ha azon hangzasilag beleillesztehetok. Hajlekony lemez helyett floppi, merevlemezes hattertar helyett vincseszter teljesen OK. Hasonlokeppen a kurzor, a ruter, a monitor, web, stb., mind johet.

            Legalabb egyertelmu, hogy ezek alatt mast ertunk, mint a magyar forditasuk alatt. Ha kerek valakitol egy floppit, akkor biztos, hogy floppy disc-re gondolunk, mig ha lemezt kerek, akkor lehet, hogy Dolly Roll, lehet, hogy farost, lehet, hogy badoglemez lesz az, amit kapok. 🙂

            1. A „vincseszter” szerintem határozottan és tudatosan kerülendő. Ha másért nem, mert a cég, amelyről a dolgot elnevezték, rég elmerült a feledés homályában, de amikor ismert volt, akkor is csak az egyik, nem túl súlyos szereplője volt a piacnak.
              A vincseszter szó egyébként hungarikum: csak nálunk volt használatos… Egy archaikus, magyar tájszólás… mint a „böllenkedés”…

              1. Az manapsag mar nem is vincseszter, hanem vinyo. De mindegy is, mert meg 1-2 ev, es el is felejtjuk, hogy az SSD elott az volt a hattertar. 🙂

    1. Mihály, RGB és SZUMHA ügyben nagyon egyetértek veled (bár a VZK még nem jött velem szembe…)

  2. Sajnos a Draw régóta meglévő súlyos hibája a 6.0.2 verzióban is benne maradt:

    Az objektum stílusokat nem képes megfelelően menteni, ha azok hierarchikusan, az öröklődés rendje szerint vannak létrehozva:
    az Alapértelmezett alapján létrehozott saját Főstílus – majd annak az al-stílusai – és további al-alstílusok.

    Amíg létrehozza az ember, addig jól működnek, de .odg fájlformátumba mentés és annak újbóli megnyitása után minden al- és al-alstílus egyenrangúvá válik az Alapértelmezettel, és elveszti a létrehozásakor a szülőstílusától örökölt (és akkor még működő) tulajdonságokat.
    Ilyenkor vonszolással a Stílustáron ismét fel lehet építeni a hierarchiát, és a 6.0.2 verzió ezután ezeket a stílusokat már jól menti.

    De ha újabb hasonló Stílus struktúrát hozunk létre a már létezőkön kívül, akkor újbóli mentés és megnyitás után megint elvész az újabbak struktúrája, amit aztán újból összerendezve a következő megnyitástól már jól kezel a program…

    Mindez nálam Win7 prof 64 bites op.rendszeren, de 32 bites LO programmal történik: LO 5.4.5 fixen telepített verzióval is, és a LO 6.0.2 winPenPack-os hordozható verzióval is. A hiba már a LO 4.4.7 verzióban is létezett.

        1. Hú, ez szuper!

          A következő 6.x.x-ben lesz benne, vagy esetleg már az 5.4.6 ban is megjelenik? (Jó lenne, ha a mostani Still verzióban is megjelenne a javítás…)

    1. Valószínűleg engem jellemez, hogy ezt a „hierarchikus stílusok” dolgot, bár láttam, soha nem használtam ki. Egyfajta udvariassági gesztusnak vettem, hogy az „öröklés innen” mező hatására nem kellett nekem beirkálni az attribútumokat, de hogy ezt a LO precízen be- és nyilvántartja?! Legalábbis ez lenne a dolga?
      Jó tudni.

      1. Igen, ez a dolga. És ezzel jár természetesen az is, hogy ha egy szülőstílusnak egy olyan tulajdonságát megváltoztatod, aminek a gyerekstílusaiban nem bíráltad felül az öröklési rendet, akkor azokban is automatikusan frissül az a tulajdonság.

        Ez a funkció régóta remekül működik a Writerben és a Calcban.

  3. Egy másik érdekes fejleményt tapasztalok éppen: megnyitásra és mentésre már csak a LO párbeszédablakait lehet használni, a rendszerét (Windowsban) nem. (Eszközök -> Beállítások -> Általános: “Megnyitás és mentés párbeszédablak” jelölőnégyzet)

    Nekem ugyan nem fáj, mert mindig átállítottam az (eddig alapértelmezett) windowsosról libreoffice-osra, de lehetnek, akiket ez korlátoz. (Többeket is ismerek, akik szeretik, ezért ismerik, ezért használják a Windows Intézőt… Csak engem idegesít halálra, hogy nem jegyzi meg az állapotait – ablakméret, oszlopméret, rendezés stb? Azt bezzeg igen, hogy melyik alkönyvtárban volt ikonos vagy listás…)

      1. További érdekesség: a 6.0.x „beleragadt” a LO megnyitás-mentési dialógjába — mert az 5.4.5 abban volt a 6.0-ra frissítéskor. Ezt a kvázi registry-tippet azért köszönöm…

        1. Ez azért van mert nem tiszta telepítést csináltál, és az újabb verzió átvette a régebbi verzió felhasználói profiljának a beállításait. Nálam a tiszta telepítés a Windows párbeszédpanelekkel “ébredt”.

  4. Csak azért, hogy az enyém legyen az utolsó szó (komment, erre a bejegyzésre).
    Volt itt pár utalás az „Elementary” ikonkészletre. Annak elismerése mellett, hogy a több száz kis alkotás tetszetős és szemléletes, megjegyzem, hogy
    — a „Mentés” ikon, és a LO saját „Megnyitás és mentés” dialóg „Eggyel feljebb lép” ikonjának lefelé mutató nyila vaskos kognitív tévedés. Pl. a „Tango” készlet nem követte el ezt a hibát. Amely azért súlyosabb, mint az ikonok és a képernyő területének aránya, mert igen gyakran használjuk ezeket.

    1. “Amely azért súlyosabb, mint az ikonok és a képernyő területének aránya”
      Ezzel mi a gondod? Az ikonméreteket két érték között (kicsi és nagy) tudod váltani. Ez szerintem elég. Persze ha az operációs rendszer megjelenését is nagyítod, akkor esetleg kevés lehet ennyi lehetőség…

      1. Ó, bocs. Túltoltam a poént. Semmi gondom az ikonméretekkel. (*)
        Azt akartam kifejezni, hogy egyetlen ikon rajzolata is lehet nagy probléma, ha az az ikon gyakran használatos — és a kifogásoltak ilyenek. (Az Elementary készlet “Mentés” ikonját egyébként a LO design blog kommentelői sem imádták.)

        (****** offtopic ******)
        Az ikon- (és a szöveg-) méretek egy filozófiai méretű problémakör részei.
        Igen a Windowsban (is) lehet ezeket változtatni, amiből aztán előre nem látható, változó súlyosságú bajok adódnak azokban az alkalmazásokban, amelyek nem mindent vesznek át a befogadó OS API-jaiból.
        Ha az alkalmazás “keményen” írja elő egy panel méretét, akkor a 110%-ra állított szövegméret miatti többletsor ki fog lógni belőle, nem (jól) lesz olvasható.

  5. Sajnos az 5-ös verzióban megírt leveleim megnyitásakor a 6-os eddigi bármelyik verziójában /ha a levélre kattintok/ azonnal a javítási panel ugrik fel, és javítás után hibaüzenettel a program leáll úgyhogy visszatértem az 5-öshöz, és ez hibátlanul működik

  6. Ez itt egy durva offtopic.
    Talán a 6.0.0 óta van, hogy a LO Writer stíluspanelje WYSIWYG: a stílus neve megmutatja a formázást.
    Ez az esetek 99 százalékában kiváló és kényelmes — kivéve, ha a betűszín fehér.
    Ekkor ugyanis a stílus neve eltűnik a fehér hátterű stíluspanelről.
    Álljon tehát itt egy RFF (request for feature): legyen a stíluspanel háttere világosszürke (mondjuk #ddd).
    És ismét: nem vagyok hajlandó megtanulni a Document Foundation bugzillájának használatát, tehát nem tudom ott bejelenteni, és nem tudom felkeresni, vajon másnak is fájt-e már ez. Reménykedem, hogy igen, és akkor előbb-utóbb valahogy megoldódik. Remélem, megérem.

    Ez meg itt a mese: ugyanebben a hibában szenved a legtöbb blogmotor (CMS) “vizuális” szerkesztője — miközben a sötét hátterű téma a divat legalább 6 éve. Sötét háttéren fehér betűket használunk — tehát a vizuális szerkesztőben nem látszik a szöveg.
    Évek óta nem oldják meg, hogy állítani lehessen a szerkesztő háttérszínét. WordPressben van egy plugin, amely lehetővé teszi (sajnos, sok más dolog mellett, mintegy mellékesen), Joomlában a szerkesztők CSS-ében esetleg fel lehet túrni, de az a CSS egyrészt minimalizált (nincsenek soremelések és sorközök), másrészt a függőségek miatt nem kívánt mellékhatások jelentkeznek.

    1. “Talán a 6.0.0 óta van, hogy a LO Writer stíluspanelje WYSIWYG: a stílus neve megmutatja a formázást.
      Ez az esetek 99 százalékában kiváló és kényelmes — kivéve, ha a betűszín fehér.
      Ekkor ugyanis a stílus neve eltűnik a fehér hátterű stíluspanelről.”
      A funkciót ugyanott (az Oldalsáv Stíluspanelján) ki tudod kapcsolni: “Előnézetek megjelenítése” – vedd ki a pipát, és máris látszik a név…

      “Álljon tehát itt egy RFF (request for feature): legyen a stíluspanel háttere világosszürke (mondjuk #ddd).”
      …És akkor mi lesz a világosszürke betűkkel? 😀 😀 😀

      1. Volt egy rossz előérzetem, hogy valamit földbambán elnézek. Hát, igen. Ez volt az.

        (A világosszürke az csak egy szín a sok közül, a fehér meg egy “alap”szín. Ha a #abcdef (világos égkék) színre vágynék, az ilyen színű betű szintén eltűnne…)

  7. 1. Szóközök nincsenek a minimalizált forrásfájlokban.
    2. A probléma, mint mindig, komplexebb annál, hogy egyszerűen le lehessen írni. Ha a fehér betűs bekezdésstílusnak nem fehér a háttere, akkor nincs probléma. Akkor van baj, ha a bekezdésnek NINCS háttérszíne, mert egy keretbe kerül — és annak van háttérszíne.
    Igen, tudom, a fehér betűt a keretstílusban adjam meg, amelynek nem fehér a háttere, és ha többféle hátterű keretet akarok használni, akkor a szülő keretstílusban legyen fehér a betű, a hátterek meg lehetnek különbözők a gyerekeknél.

    1. “1. Szóközök nincsenek a minimalizált forrásfájlokban.”
      Ezt értenem kellene egyszerű, de legalábbis közepesen gyakorlott felhasználóként, vagy kifejezetten a fejlesztők felé kódoltad az üzenetet? 😀

      1. A “minimalizálás” egy szívatás.
        Szó szerint arról van szó, hogy a minimalizált HTML (CSS, PHP, JavaScript stb.) szöveges forrásfájlokban nincsenek szóközök, sortörések, tabok — amelyek a szintaxishoz nem kellenek, de az olvashatósághoz igen.
        Egy példa: a bootstrap.min.js. A Bootstrap egy nyílt forrású Javascript kódkönyvtár (sablon) interaktív, reszponzív weboldalakhoz, godzillion WordPress, stb. template alapul rá, és a közösség bátran ajánlja a használatát, és bátorít a tetszés szerinti módosítására.
        Az olvasható verzió 170k, a minimalizált 120k. Azért az 50k-ért lényegében letitkosítják, elvileg a rövidebb betöltődés érdekében, gyakorlatilag a laikus, vagy kevésbé gyakorlott “újrafelhasználók” szívatására. (Nyilván sértődött vagyok a minimalizálás miatti többletmunka és hibázási lehetőség miatt.)
        Ha valaki még mindig nem értené, itt a fenti komment “minimalizált” változata:
        A”minimalizálás”egyszívatás.Szószerintarrólvanszó,hogyaminimalizáltHTML(CSS,PHP,JavaScriptstb.)szövegesforrásfájlokbannincsenekszóközök,sortörések,tabok–amelyek aszintaxishoznemkellenek,deazolvashatósághozigen.Egypélda:abootstrap.min.js.ABootstrapegynyíltforrásúJavascriptkódkönyvtár(sablon)interaktív,reszponzívweboldalakhoz,godzillionWordpressstb.templatealapulrá,ésaközösségbátranajánljaahasználatát,ésbátorítatetszésszerintimódosítására.Azolvashatóverzió170k,aminimalizált120k.Azértaz50k-értlényegébenletitkosítják,elvilegarövidebbbetöltődésérdekében,gyakorlatilagalaikus,vagykevésbégyakorlott”újrafelhasználók”szívatására.Nyilvánsértődöttvagyokaminimalizálásmiattitöbbletmunkaéshibázásilehetőségmiatt.)

        1. Hááát… A mai Terabájtos tárolók világában nem nagyon értem, hogy miért éri meg ilyen módon sűríteni…

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.