OpenOffice.org 1.1.3-kde

GTK2-s verziónak jobban örülnék.

Nem próbáltad a ximian féle változatot? Az a gtk2/gnome-hoz lett igazítva.

GTK2 = UTF8-as istencsapása. :I

En orulok neki, este le is huzom!

Szeretnek mar minden progival atterni QT-s feluletre.

Marcsak a Mozilla Firefox -ot kellene ilyenben megcsinalni :)

Mert a QT az mióta nem UTF-8 ha szabad kérdeznem?

Mellesleg az UTF-8 nem istencsapása, hanem kábé az egyetlen manapság ismert járható út az ékezetes betűk korrekt kezelésére, amikor nem történnek olyan istencsapások, hogy írsz egy ű betűt, mire az másvalakihez már kalapos u-ként (û) érkezik meg például...

> Mert a QT az mióta nem UTF-8 ha szabad kérdeznem?

dehogynem :)

> Mellesleg az UTF-8 nem istencsapása, ...

lehet, h én vok az elmaradott, de nagyon úgy tűnik, h sok progi még nagyon nincs erre felkészülve. emiatt kicsit én is jogosnak érzem az istencsapását ;-)

Ez jó; de engem spec kiver a víz a KDE-s ikonoktól. Én még a KDE-s alkalmazásokban is lecseréltem őket a gnome ikonjaira :)

Fogalmam sincs, hogy a Qt belül mit csinál, nem vagyok fejlesztő.

Viszont - amit itt a többiek is írtak utánad - ne legyen kötelező ez már. Legjobb emlékeim szerint a Qt-os alkalmazások nem nyávognak és böfögik tele a konzolt/.xsession-errors-t, hogyha egy-egy filenév úgy tartalmaz 8 bites karaktereket, hogy pl. a latin2-es kódtáblát használtam hozzá. A GTK2 ezt simán megteszi és finoman szólva is idegesítő.

Meg a fő baj: hadd dönthessem el én, hogy milyen kódolást szeretnék használni, és ne legyek rákényszerítve!

Valóban sok szoftver még nem tudja kezelni ezt és van emiatt az UTF8-nak egy olyan hátránya, ami a latin2-es kódtáblával pl. nem jelentkezik: egy síkhülye szövegszerkesztőben is tudod szerkeszteni a latin2-es szöveget, nem kell hozzá az UTF8 több byte-os entitásait dekódolni. Legföljebb kalapos ő-t látsz a magyar helyett, de az kibírható, a lényeg az, hogy látod. Vagy pl. hogyan nézel meg more-ral v. less-szel egy UTF8-as szöveget?

Mellesleg a több byte-os ékezetes karakterek miatt megnő a szövegek mérete, még ha minimális mértékben is.

A kódolás meg nem probléma, amit írsz, mert egyszerűen csak (pl. az adott e-mail fejlécében, ugye) el kell tárolni, hogy az milyen kódlappal történt.

Egyébként nem az UTF8-cal van problémám, hanem azzal, ahogy a GNOME ezt rátolja az emberre.

IMHO ezen a kódoláson is meglátszik (mint eddig az összesen), hogy olyan nyelvterületen kezdték kidolgozni, ahol nincsenek ékezetes betűk és fogalmuk sincs az ottani nyelvet beszélőknek a mi bajainkról.

És ezt honnan lehet letölteni?

Legjobb emlékeim szerint a Qt-os alkalmazások nem nyávognak és böfögik tele a konzolt/.xsession-errors-t, hogyha egy-egy filenév úgy tartalmaz 8 bites karaktereket, hogy pl. a latin2-es kódtáblát használtam hozzá. A GTK2 ezt simán megteszi és finoman szólva is idegesítő.

Olvasd el a gtk2 forrásán belüli README fájlt. Sokat fogsz tanulni belőle. Segítek: keresd a G_BROKEN_FILENAMES környezeti változót. Ez kell neked. "The assumption of GLib and GTK+ by default is that filenames on the filesystem are encoded in UTF-8 rather than the encoding of the locale; the GTK+ developers consider that having filenames whose interpretation depends on the current locale is fundamentally a bad idea." Teljesen egyetértek velük. Nehogymár én létrehozok egy fájlnevet magyar ű betűvel, mire azt Jean-Paul haverom kalapos u-ként látja... nem, az nem kalapos u, az akkor is maradjon magyar ű, ha valaki nem magyarul használja a rendszert. Erre csak unicode alapú (leginkább utf8) karakterkészlet képes.

Csak egy kis adalék: míg a Gnome világ következetesen locale-től függetlenül utf8-at használ a fájlnevekben, addig a KDE szépen kavar. Épp tegnap találkoztam azzal a hibával, hogy k3b-ből nem lehet ékezetes fájlokat CD-re írni, mert a fájlnevet (ami valid utf8 az én esetemben) ő átalakítja latin2-re és így adja oda az mkisofs-nek, amelyik így nyilván nem találja meg a fájlt. Most akkor bocsi, de melyik is a jobb? :-)

Valóban sok szoftver még nem tudja kezelni ezt és van emiatt az UTF8-nak egy olyan hátránya, ami a latin2-es kódtáblával pl. nem jelentkezik: egy síkhülye szövegszerkesztőben is tudod szerkeszteni a latin2-es szöveget, nem kell hozzá az UTF8 több byte-os entitásait dekódolni. Legföljebb kalapos ő-t látsz a magyar helyett, de az kibírható, a lényeg az, hogy látod. Vagy pl. hogyan nézel meg more-ral v. less-szel egy UTF8-as szöveget?

Na, akkor egy kis körkép. Az UHU 2.0-ban ugyanis UTF-8-at fogunk használni, de az átállás igen jelentős részét már most, a készülő 1.2-re megtettük. Lássuk...

vim, emacs, joe, mutt, lynx, w3m, more - mainstream tök jól kezeli az utf8-at.

ne, le és még jópár szinte-soha-senki-nem-hallott-róla típusú konzolos szövegszerkesztő szintén jól kezeli az utf8-at.

less - mainstream majdnem tökéletesen kezeli az utf8-at, a keresés mező hibás, de van rá patch, alkalmaztuk.

nano - dolgoznak rajta a fejlesztők, az alapjai már megvannak az 1.3-as sorozatban, 1.4-re igérik a véglegesítést.

mc, mcedit, mcview, pico, pine - létezik hozzájuk patch, már alkalmaztuk őket.

Annyi megjegyzés, hogy a szövegszerkesztők és fájlkezelők némelyike csak olyan kódolású szövegfájlt tud szerkeszteni, ami megegyezik a terminál kódolásával. Az okosabbak (például vim, joe) tudnak utf8 terminál fölött latin2 szöveget és latin2 terminál fölött utf8 szöveget is szerkeszteni.

Némely más programokat mi magunk véges mennyiségű munkával fel tudunk készíteni utf8 használatára.

Csak azért nyújtottam egy ilyen kis körképet, mert tudom, hogy az elmúlt 1-2 évben nagyon sokat fejlődtek ilyen téren a szoftverek, tényleg amikor a redhat behozta az utf8 konzolt akkor még nagyon sok probléma volt vele. Ugyanakkor mostanra már igencsak biztató a helyzet.

Ha van egy kis időd, rakj fel egy 1.2 snapshotot, /etc/env.d/locale-ben írd át hu_HU.UTF-8-ra a nyelvet, és nézz körül a grafikus felületen, illetve grafikus terminálon belül is (a linux konzolt bonyolultabb átállítani), keress hibásan működő programokat. Én most körülbelül 5-öt tudnék felsorolni: gmplayer, dselect/dpkg, man, és most hirtelen elakadtam. Szóval nem kell ám parázni az utf8-tól.

Legföljebb kalapos ő-t látsz a magyar helyett, de az kibírható

Ez ízlés kérdése. Szerintem nem bírható ki, én ugyanis hányingert kapok tőle. Az utf8 pont arról szól, hogy ilyen _soha_ ne fordulhasson elő.

A kódolás meg nem probléma, amit írsz, mert egyszerűen csak (pl. az adott e-mail fejlécében, ugye) el kell tárolni, hogy az milyen kódlappal történt.

Az olyan helyeken, ahol használsz valami kódolást, és azt meg is tudod nevezni, mint például e-mailekben, html oldalakon, ott ez tényleg nem gond, és a latin2 is tök jó. A gondok inkább ott vannak, ahol nincsen lehetőséged eltárolni a használt kódolást, például fájlnevekben, sima plain text fájlokban.

IMHO ezen a kódoláson is meglátszik (mint eddig az összesen), hogy olyan nyelvterületen kezdték kidolgozni, ahol nincsenek ékezetes betűk és fogalmuk sincs az ottani nyelvet beszélőknek a mi bajainkról.

Fogalmam sincs, ezt mire alapozod, ugyanis baromira nincs így. Egyszer kell felkészíteni a szoftvereket utf8-ra, és onnan kezdve tökéletesen megfelelel szinte minden nyelv beszélői számára. Persze vannak még csiszolnivalók rajta (mármint a unicode-on), folyamatosan fejlesztik is, de ugyan, szerinted mi az benne, ami nem felelne meg például a magyar ajkúaknak? A történet épp fordítva fest. A 8 bites kódolások idején általában még magasról letojták a többnyelvűség kérdését a fejlesztők, és ilyen szempontból ***** minőségű szoftverek készültek. Később felmerült az igény a korrekt többnyelvűségre, de rájöttek, hogy a sok-sok locale tarkasága technikailag megoldhatatlan problémák tömkelegéhez vezet, így merült fel az igény egy egységes kódolási rendszerre. A Unicode-ot, utf8-at valós igény szülte és ezeket az igényeket jól ki is elégítik.

Nekem is csak gondom volt belőle. Ha például telnet-elni, vagy shh-zni szeretnék egy UTF-8as szervert, putty-ban be kell kapcsolnom az UTF-8-as fordítást

Gondolom a latin2-t is bekapcsoltad, nem? Vagy jók neked a latin1-nek álcázott "magyar" betűk? Csak mert ez esetben tényleg semmivel sem több munka latin2 helyett utf8-at beállítani. Ráadásul a putty gépenként külön képes megjegyezni ezen beállítást.

szóval amíg lokalizált kódlapokkal dolgozik minden gép

Tényleg, minden gép? Linuxok közül Fedora és SUSE már utf8-as. Mac iszonyú rég óta utf8. A Windows is tudtommal jobban szereti a unicode vonalat, mint a 8 biteset, bár ebben nem vagyok biztos. Az átkapcsolás pedig nem szedvedés, hanem (az iránytól függően) kb. 1 parancs. Van luit, ttyconv, ez két olyan progi, ami egyfajta terminál fölött másmilyet emulál, aztán escape szekvenciával normális terminálok a 8bites módból ideiglenesen utf8-ra kapcsolhatók, például az UHU-ban már megjelent egy "u" nevű szkript, ha érdekel elküldöm, ami utf8-ra kapcsolja a terminált és a locale beállításokat az argumentumában megadott parancs futásának idejére, szóval latin2 gépről utf8 gépre "u ssh gépnév..." ennyi, nem több.

Mint minden átállás, ez is nyilván nehézségekkel jár felhasználói oldalról is. Amennyiben a szoftverek már képesek az utf8 helyes kezelésére, az esetben a tiszta utf8-ra átállás jóval kevesebb *****ást tartalmaz felhasználói szemszögből, mint a tiszta latin2 (és pláne mint a kettő keverése). Erről teljes mértékben meg vagyok győződve.

Ha tartjátok azt a filozófiát, már ami a frugalt illeti, hogy szerintetek a mainstream progi úgy jó ahogy van, hülyeség patchelgetni, akkor bizony még sokáig így fog tűnni neked. A hozzáállással én nem értek egyet, szerintem a célokat a felhasználó szemszögéből kell megfogalmazni, és ha ez a cél patchelést igényel, akkor patchelni kell... Mi megfogalmaztuk célként, hogy kb. 1 év múlva utf8-at használó disztribet adjunk ki, és ennek érdekében már most az elmúlt pár hónapban is nagyon sokat léptünk előre, természetesen sehol nem a készülő latin2-es 1.2 rovására.

Először is ne vedd magadra, amiket írtam, mert rögtön az UHU-ból hozol (ellen)példákat. :)))

A G_BROKEN_FILENAMES-ről tudtam, meg arról is, hogy újabban a G_FILENAME_ENCODING-ban kell ezt állítgatni, de akkor is zavar. Miért nem lehet ezt a KDE-hez hasonlóan állítani valami kényelmes módon? Vagy a qtconfig-ot is mondhatnám. A kényelmesen persze nem elsősorban azt értem, hogy ablakos-grafikus klikk-klikk, hanem legyen valahol ez nyilvánvaló, könnyen elérhető, dokumentált. Ne egy mélyen elásott README file-ban találjam meg, hogy milyen környezeti változót kell átírnom. Miért nem lehet ezt a .gtkrc-ben állítani pl.? Pluszban: miért kell a GDK_USE_XFT-vel is szívnom, ha ki akarom kapcsolni az élsímítást, mert én meg attól hányok? Hála az égnek nagyon jók a szemeim és nekem az homályos, nincsen rá szükségem.

A kalapos ő-t meg utálhatod, de ha valami régebbi rendszeren nézel meg egy filenevet, vagy egy szövegfile-t, van a latin1-es kódolásnak egy baromi nagy előnye az UTF8-cal szemben: olvasható marad. Nem kell a több byte-os kriksz-krakszokból kihámozni, hogy az most vajon milyen karaktert takarhat. Pontosan ezt írod le te is is a kódolásoknál, csak más következtetésre jutsz. Én azt akarom és nekem az a fontos, hogy olvasható maradjon a file neve és tartalma akkor is, ha UTF8-at értelmezni nem tudó, egyszerűbb eszközökkel állok neki.

Az UTF8 kidolgozásával meg az a bajom, hogy nem kompatibilis visszafele. Bár ezt meg lehet kerülni és át lehet rá költöztetni mindenféle programot, fileneveket, szöveget stb., de kényelmetlen (de hosszú távon megoldható). Ha tényleg natívan ezt a kódolást kezdi az ember használni, és minden eszköze tudja értelmezni, akkor valóban jó dolog. Csak most nem ez a helyzet.

De alapvetően nem is az UTF8 zavar igazán, hanem az, ahogy a GTK2 ezt kezeli. Csak ismételni tudom magamat: ne legyek rákényszerítve valamire, ne akarja egy szoftver nálam jobban tudni, hogy mi jó nekem.

UHU-t meg nem próbálok ki, köszönöm, ha már fölajánlottad. Megvagyok egyrészt jól a Sarge-ommal, másrészt nincs ilyesmire sajnos időm. :(

Én kb. 1 évvel ezelőtt használtam utoljára RH9-essel, azóta nem követem a dolgot. De attól tartok, azóta, hogy a Novell beszívta őket, egy kicsit nehezebb ingyenbe beszerezni a dolgot. A Novell Linux-ban biztos benne van. De ha körülnézel a ximian szerverén, akkor ott biztos találsz valamit, ami kipróbálható (ftp.novell.com/pub/ximian/).