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).

    Válasz

      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! 🙂

        Válasz

        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.

          Válasz

          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. 🙂

            Válasz

            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”…

              Válasz

              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. 🙂

                Válasz

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

      Válasz

  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.

    Válasz

        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…)

          Válasz

    2. 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.

      Válasz

      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.

        Válasz

  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…)

    Válasz

      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…

        Válasz

        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”.

          Válasz

  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.

    Válasz

    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…

      Válasz

      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ó.

        Válasz

  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

    Válasz

  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.

    Válasz

    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? 😀 😀 😀

      Válasz

      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…)

        Válasz

  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.

    Válasz

    2. “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? 😀

      Válasz

      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.)

        Válasz

        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álasz

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

Az e-mail-címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük