Frissen tanult szitokszavak – meg a szomszéd képe

Sokat regéltem már róla hogy két OS van az általánosan használt gépemre telepítve, ebből az egyik a mindenkor aktuális Fedora. Ezen – mivel mindenből jellemzően a legfrissebbet hozza – ki lehet próbálni általában a legújabb „találmányokat”. Viszont meglehetősen kapkodós módon frissül; az aktuális hibákat az embernek nincs is ideje megszokni, a megjavulásukkal egy időben (vagy a javulásuk helyett) jellemzően jönnek újabbak. :) Nem is értem, miért van belőle klasszikus (verziózott) kiadás, majdnem rolling-rilíz a stuff, talán csak megszokásból van számozás. De az első szitokszó nem a Rolling Release lesz, ahelyett simán választ az ember olyan disztribúciót, aminek hagyományos(abb) a frissítési ciklusa.

A másik OS a kapkodós frissítés szöges ellentéte, a CentOS a maga megnyugtatóan unalmas régi csomagjaival. Legalábbis, az volt… A 8-as verziót még használtam egy darabig, de az – ha jól emlékszem – már az ájbíem alatt lett kiadva. És meg is kezdődtek a furcsaságok… Az első ilyen amire emlékszem (most azt ne is számoljuk ide, hogy kihagyták a komplett Xfce-t, ez hiányzott másnak is, az az EPEL-be bekerült), hogy bizonyos programokban nem működött a billentyűzet numerikus része. Némi próbálgatás után kiderült, hogy nem a billentyűzettel van gond (nyilván), hanem csak azokkal a programokkal, amik Qt-s alapúak. Ha az adott helyen az Alt? Shift? + numerikust nyomja a júzer, megkerülnek a hiányzó számok. Erről a hibáról van egy hibajegy is, az ott fellelt kommentekből az derült ki, hogy ez egy qt5-qtbase fordítási hiba, „majd javítják”. Na de! Az újraforgatást akár én is meg tudnám ejteni… A csomagkezelő a megfelelő paraméterre megmondja, hogy az adott fájl milyen forráscsomagból készült, egy másik paraméterrel az adott forráscsomag meg letölthető. Lenne, ha arra nem azt üzente volna vissza, hogy ilyen néven nem talál csomagot. (Máshonnan nem akartam forrást vadászni, pont nem azért használnék „enterprise” OS-t, hogy ilyen csomagokat cserélgessek a rendszer alatt.) Később a szokásos frissítések alatt jött a csomagból újabb verzió → hiba megmaradt → forráscsomag továbbra se érhető el. Ez vajon véletlen..?

A következő ilyen „fájdalmam” előre tudható volt; a 8-as verzióból kiszedték a floppy kezelést. De mindenestől, nem csak úgy, hogy az alaptelepítés nem tartalmazza, nem is lehet felrakni. (Nem tudom, kinek ártott az a vagy 10 kB, nekem néha azért még jól jön…) Én, kis naiv, gondoltam, hogy jól megoldom: van egy IDE/ATAPI/PATA csatlakozós, belső LS120-as meghajtóm, ami tud kezelni hagyományos 1.44 MB-os 3½-es floppy-t, az nekem pont elég is. Az OS-ben a FAT12/16/32 kezelése nyilván benne van, így nem lehet gond. Hát, majdnem! Miután a bekötött eszköz nem jelent meg a /dev alatt, némi nyomozás kiderítette, hogy az OS-ből kidobták annak a csipnek is a kezelését, ami az alaplapomon a PATA csatolót implementálja. Ezek a kidobált eszközök másnak is hiányoztak, így készült hozzá egy közösségi repó, ahonnan ezek visszavarázsolhatóak a rendszerbe. Az adott csiphez tartozó kernel-modult felrakva („enterprise” OS? Muhaha…) az LS120 továbbra se látszik (PATA-s HDD mintha ment volna), szóval igen, a feladat sikeresen végre lett hajtva, tényleg ki lett szedve a floppy a rendszerből.

Ahogy az előző hibára, úgy erre a hiányosságra se lett megoldásom, de a „pontot az i-re” az tette fel, amikor az egyik frissítés után elkezdett nem működni az a kb. 2 program, amit AppImage formában használtam. (Jobban preferálom a natív csomagot, de ha az nincs éppen (ami a CentOS esetén azért bőven megesik), akkor ez egy vállalható kompromisszum, amikor a „futtatás” / „fordítás közben zajló sz.pás” között választhat a felhasználó.) Úgyhogy valamikor itt lett elegem a CentOS8-ból, de a végső lökést a stream adta meg, annak a „kötelező bevezetését” már nem vártam meg. (Azaz az eddigiek „nem ma” történtek, hanem kicsit régebben.) Mert ha ez már a cern-nek sem felel meg, akkor csak nyavalyoghatok én is… :-D

A CentOS sajnos ment, helyette meg nem lett Rocky, Alma, meg egyéb RHEL származék. A jelenlegi tulaj több szoftveres terméke is járt már pórul; tényleg remélem, hogy sokáig meglesz az „upstream vendor”, ezt majd az idő megmutatja. De az biztosnak tűnik, hogy jelenleg a fókusz inkább a felhős dolgok alá való OS-en van, a munkaállomás-vonal eddig se volt nagyon a központban, ezután meg pláne. (Persze szerintem.) A „nem túl idegbeteg” frissítési stratégia (inkább régebbi, de stabil(abb) alapok) igénye az viszont megmaradt, emiatt a választás egy régi ismerősre, az openSUSE-re esett, ebből is a Leap kiadásra. A Tumbleweed itt legalább deklaráltan rolling-release változat, ezzel is lett némi tapasztalat, lesz is szó róla hamarosan. A Leap alaprendszere egy ideje a SLES/SLED repóiból frissül egyenesen, ami azért – talán – ad némi bizakodásra alapot. Egy ideje használom már, nyilván itt is megvannak a hozzá tartozó nyűgök, de eddig kb. bevált. Amivel meg gond van, arra anyázok bőszen. :-D

Időközben felmerült egy olyan igény, hogy a „munkaállomás” gépemet egy másik helyiségből is jó lenne tudni néha használni. Egyből a „hagyományos” vékonykliens-felépítés jutott az eszembe, a célra bőven megfelelne. A „munkaállomás” lesz a szerver, kliensnek elsőre egy sima rPi jutott az eszembe, ez végül egy miniITX alaplapos „rendes” (de jó csirke CPU-s) pécé lett, azzal a címszóval, hogy bizonyos feladatokra akár natívan is alkalmas lehet. Ez utóbbi állapot még várat magára (kellene némi plusz RAM minimum), de „távképem” már van. :) A kép meg a sallangok a (belső) hálózaton jönnek-mennek, erre Linuxon több megoldás is van. A leglogikusabb nyilván az lenne, ha az X szervert futtatná a (vékony)kliens, a „munkaállomás”-on futó programok meg ehhez kapcsolódnának. Ez elvileg működik is, de van egy csúnya hibalehetőség: ha a kommunikáció valami miatt megszakad (megáll a rúter, pl.) akkor az éppen futó programok (amiknek a képe a „szomszédban” látszik) szépen szállnak is elfele. :) Emiatt célszerű valami olyan megoldást használni, aminél nem lesz gond az ilyesmi.

Linuxon talán a VNC különböző implementációi használatosak, süsü alatt a gyári megoldást a TigerVNC adja, ennek a beállításához van is egy modul a YaST-ban, de itt sikerült „belemennem a málnásba”™, annyira, hogy még most se keveredtem ki belőle.

Viszont először ehhez az egészhez kelleni fog egy kliens, ami a fent említett miniITX-es alaplapból lett összerakva. Erre kell egy OS is, ami – ha lúd, legyen kövér alapon – az openSUSE rolling változata lett, mert kíváncsi voltam rá, mennyire hasonlít a Fedora-ra. Hát, talán még őrültebb tempójú a csomagfrissítések gyakorisága. :-D (Ezen nem tudom, miért lepődtem meg…) Egyelőre működni látszik ez a verzió is, de a vas alatta tényleg karcsú. Ez egy AMD-s Brazos platform, azon belül is egy E350-es Zacate, ami a másik oldali Atom ellenfele akart lenni. „Ahhoz képest” nem rossz, de azért nem egy kapkodó idegbeteg. Illetve ehhez jelenleg 2 GB RAM van benne, ami szintén nem tesz jót a felhasználói élménynek. A „távmegjelenítés” viszont működik, itt nem érezni semmi lassúságot. A morgásaim viszont itt jöttek elő újra, már a sokadik alkalommal…

A felállás ugyan használható, de a kliens „alatt” az egyik nap lehalt a HDD (régi használt darab, nem bántom érte), emiatt lehetett ezt a rendszert újratelepíteni. És eközben előjöttek a címben emlegetett szitkok bőséggel. Ezek jellemzően nem új keletű témák, mindegyik a „pofa be, majd mi tudjuk, mi kell a júzernek” hozzáállású UI fejlesztőktől jött.

Az egyik ilyen téma nem más, mint a CSD, azaz a „Client Side Decoration”. Ez – ahogy olvasom – még 2013-as (meg korábbi) téma, a GTK3.valamelyik verziójával lett bevezetve, azóta erőltetik. Én meg kb. azóta keresek másik programot, amikor meglátok egy „régi kedvencet” átalakulva erre a borzalomra. A linkelt oldalon van egy lista, hogy „mit is szeretnének ezzel”: hát, izé… Nem lettem meggyőzve, hogy ez nekem jó. :| Írhatnám, hogy megosztó az UI ezen átalakítása, de a témára keresve jellemzően dühöngést / mérgelődést olvasni róla, nagy ritkán elszórva egy-egy „nekem tetszik” hozzászólást. Előnyét én eddig nem láttam; a ködös „jobban kihasználja a helyet”-et leszámítva valaki tud ilyent mondani? :) A helykihasználás emlegetése meg eleve vicc: egy vékonyabb ablakkeret, alatta a programhoz tartozó fix menüsor kisebb magasságú mint ez a „kövér” dekoráció, amiben nincs menü! (Na jó, ez talán túlzás.)

Én alapból Xfce-t használok, a teljes ámokfutás ezt a környezetet egyelőre elkerülte, de a GTK3 meg a funkciói nyilván ide is megérkeztek. Ahogy nézem, a CSD eléggé „véleményes” itt is; pl. a Mousepad konfigurálható, hogy ilyen, vagy hagyományos ablaka legyen-e. :) Ha már muszáj, ennek a megoldásnak én mindenképpen örülök, legalább visszakapcsolható a normális kinézet. (A kódot karbantartani gondolom annyira nem vicces, ez meg egy egyszerű editor csak.) A morgásra ez a program emiatt pont nem jó példa, de itt van pár kép:

Valami ilyesmi lenne az elvárt. A CSD-s meg ilyen gyönyörű:

Hát már hogy néz ez ki? :) Az ujjnyi-vastag ablak-fejléctől már a zikszpénél™ is szédültem! Tudom, én vagyok az egyetlen, aki azért vesz nagyobb monitort, mert több dolgot akar a képen egyszerre látni és nem azért, hogy ugyanazt lássa nagyobb betűkkel! :-D Szó se róla, pár pixellel keskenyebb (ha az ablak szélességét akarod állítani, nehogy véletlenül meg tudd egérrel fogni, gondoltam elsőre, de ezt „megoldották: az ablak melletti rész is „megfogható”, muhaha…), de hát na! Amikor ez anno megjelent, akkor még az ablak-gombok sorrendjét / pozícióját se volt képes átvenni az ablakkezelőtől, annyira kliens-oldali volt a dekoráció. Odáig legalább már eljutott, bár az ablak „felgördítés” gomb valahol elveszett, de a színséma az nyilván sehol. A fenti képeken balra egy aktív, jobbra egy inaktív változat látható az adott ablakból. Vajon melyik verzió látszik jobban? (Igen, CSD esetén ennyi a különbség: halványabbak lettek a feliratok. Ha van a képen több ilyen ablak, lehet keresgetni, hogy melyik is az éppen kiválaszt(ód)ott közülük.)

Ergonómiai szempontból melyik változat a jobb? (Költői kérdés.) Olyan példát most hirtelen nem is találtam, ahol a menü is el van dugva egy gomb alá (Hamburger-menü, mi? Melyik gyorsétterem szponzorálta?), jellemzően ezek is belekerülnek a „fejlécbe”, nehogy a szokott helyen meg lehessen fogni? Van ilyen program bőven, de ha tehetem, azonnal le is szedem a csomagkezelővel, és keresek helyette másikat. Csak példának felraktam az egyik régi kedvencem, a gedit-et:

Hát, hogy néz ez már ki? :-D Itt a szmájli, de a program felrakása után készült a kép róla, azt még ki se mentettem, mikor már le is szedtem a stuffot, annyira idegesít. Az a vicc, hogy valójában nem tudom, mitől vagyok ennyire rosszul ettől, de valami miatt igencsak megüli a gyomrom. Mutogatni lehet, de használnom azt ne kelljen. Amúgy ha csak az ablakdekor vastagsága zavarna, ahhoz talán akad megoldás: némi css (!) varázslattal (már ez is önmagában röhej) visszább lehet venni a méretét. Így – most ezt végiggondolva – talán az zavar benne, hogy eddig az ablakkereten nem a programhoz magához, hanem az ablakokhoz általában tartozó dolgok voltak csak, amiknél egy véletlen klikk nem okoz a hozzá tartozó programban semmit. Egyedüli kivétel talán a bezárás, azt én (jó régi AMIGÁ-s szokás alapján) átrakom mindig balra. De a többi ablakgomb nem okoz semmi „maradandót” a programnak. Itt meg egy sima ablak odébb rakásnál is arra kell koncentrálni, hogy nehogy rossz helyen fogjam meg a fejlécet. Aki ezt így kitalálta… De hogy legyen még egy rossz példa:

Erre ismét csak azt tudom kérdezni: ez meg hogy néz már ki? (Ezt a dialógusablakot épp’ az aktuális Fedora+Xfce+Firefox fájlmentése hozza elő például.) Szívesen megkérdezném a megálmodójától, hogy egy kérdőívet is úgy tölt-e ki, hogy először bejelöli a választ, majd utána olvassa el a kérdést? Erre szerencsére van megoldás, az Xfce-nek van egy „beállításszerkesztő” stuffja (xfce4-settings-editor), ott az xsettings/Gtk/DialogsUseHeader-t kell átkapcsolni, ami után a hagyományos(abb) ablak fogad:

Érdekes, a gombok a megszokott (és logikus) helyükön. :) Amúgy most kezdjek el hápogni a gombok melletti ikonokon is? Régen örültünk neki, hogy egyáltalán pár színt ki lehetett rakni egy képre. Manapság már egymilliárd+ színt is ki lehet pakolni, végtelen+ a felbontás, erre mit látunk itt? Gagyi fekete-fehér ákombákomok a normális (már régen kész!) rajzok helyett. (Persze a bárgyún néző sz@rkupac emodzsi az kell, lehetőleg 3 árnyalatban, hogy a híg, a közepes meg a kemény verzió is meglegyen.) Ez mondjuk „csak” egy ikonkészlet lecserélésével orvosolható, de a trend akkor sem tetszik, talán egyszer kilábalunk ebből. :)

Ez a CSD téma olyan, hogy jellemzően „nincs rá megoldás”, nyilván azon kívül, hogy az ilyen programokat kerülöm amennyire lehet. (Ugyan létezik olyan, hogy gtk3-nocsd, de ez sajnos csak egy workaround.) A Leap az Xfce 4.16-ot hozza, itt a DE-nek több ablaka is ilyen (Névjegy, beállítások, …), de ezekkel szerencsére ritkán találkozok (nem a napi rutin részei a használatuk). A Tumbleweed-ben a 4.18 van, ott ezek az ablakok hagyományos módon vannak dekorálva alapból, és – nahát – lehet konfigurálni:

Neeeem, eszem ágában sincs bekapcsolni! :-D (Ez a beállítás „most került elő”, a Fedora-s Xfce-ben még nem láttam, bár az F38-ra frissítés még hátra van, majd megnézem ott is.)

Hogy ne csak félig (se) megoldott morgásom legyen, jöhet a következő szitkozódásom tárgya, az overlay scrollbar. Ezzel az első gondom az volt, hogy nem találtam megfelelő keresőszót hozzá, ami alapján egyáltalán tippet kaptam volna arra, hogy merre keressek. Most már bezzeg megy… :)

Alapból „semmi” (némi szaggatott vonal jelzi t’án hogy arra lehet valami), az egérrel matatásra meg megjelenik „valami”, amire ráállva lesz valamivel nagyobb méretű… Hát, izé… Én már alapvetően az elképzelést is ostobaságnak tartom: ki gondolta azt jó ötletnek, hogy érdemes eldugni a felhasználó elől azt, hogy amit lát, az szkrollozható, kb. mennyi része látszik, illetve hogy hol tart benne? Persze tudom: mobil! Meg tapicskolós képernyő! (Ott is ugyanúgy gáz, hogy nem látni ezeket.) Az előző linken viszont konkrét hibákat is felsorolnak, nem csak az „én nem így szoktam meg” a lényeg. Kicsit az az érzésem, hogy a fejlesztők kerestek maguknak egy álproblémát (unjuk a jól beváltat, csináljuk meg úgy hogy más legyen mint eddig), majd lelkesen megoldották hibásan. Pedig messze nem kellett volna nézni: az eddigi változat azért lett olyan, amilyen, mert bevált. De nem baj, ha a miénk sz@r, legalább más mint ami eddig volt! :| Ezen – egyelőre? – szerencsére lehet (még) segíteni, (globálisan is) letiltható a dolog: az /etc/environment fájlba a következő jön (ha nincs ilyen fájl alapból, létre kell hozni):

GTK_OVERLAY_SCROLLING=0

És láss csodát:

Meglepő, hogy hol tart a technika! Nyilván, GUI-ra kivezetett konfigurálási lehetőség felejtős, mert esetleg a többség még vissza fogja állítani..?

De ez még mind semmi! Van mááásik! A mai utolsó „annyira rühellem, hogy csak na” téma szintén a mire keressek kérdésen bukott majdnem el: ez az ablakok „finom görgetése”, amit mindenféle flancos nevekkel illetnek. (Smooth scrolling, kinetic scrolling, ...) Persze egyik se jó keresőszónak, jellemzően a „hogy lehet kikapcsolni” kérdésre tonnaszámra jönnek az ezer éves „hogy lehet bekapcsolni” fórumtopikok. Ez ugye az a featúra, amikor egy ablakban „mozogva” a benne levő (amúgy szkrollozódó) tartalom nem nagyobb lépésekben ugrik, hanem „odateker” / „odaúszik” a kívánt pozícióra; először gyorsan, aztán ahogy közeledik a kívánt helyre, úgy lassul le a mozgás. És persze: nem hogy nincs hozzá ki / bekapcsoló gomb valamerre, hanem még a nevét se lehet tudni… Hogy ez miért is zavar? Ha elmesélem, téged is zavarni fog! :-D Nem tudom, ezzel ki hogy van, de én úgy szocializálódtam, hogy a számítógép van értem, és nem én a gépért. Azaz: a gép feladata az, hogy megcsinálja, amire utasítom. Ha pl. nyomok egy PageDown billentyűt, akkor azt várom el, hogy az ablakban a lehető leghamarabb (jó esetben már a következő képkiírásban) az egy lappal lejjebbi tartalmat lássam, szemmel már kereshetem is, amiért a gombnyomás történt. Ehelyett itt mi történik? Mozog a tartalom valameddig, addig nem lehet keresni a kívánt részt. Tehát itt nem történik egyéb, mint a szoftver a CPU-t meg a videokártyát dolgoztatja a saját szórakoztatására, és közben elcseszi az időmet.

Szerencsére most könnyen találtam megfejtést: a ~/.config/gtk-3.0/settings.ini fájlba kell a következőt beszúrni:

[Settings]
gtk-enable-animations=0

(Ha nincs meg a fájl, létre kell hozni, ha már megvan és van benne [Settings] szekció, ahhoz hozzáadandó.) Ezt az „apróságot” megcsinálva – végre – megszűnik ez a kellemetlenség is. A paraméter nevét elnézve ez kikapcsol minden animációt, bár hogy milyen egyéb animációk akadnak még, arról nem tudok nyilatkozni. (Viszont egész biztosan nem fognak nekem hiányozni!) Azért valahol szomorú, hogy programozók küzdenek ilyen ficsőrök létrehozásával, én meg azzal küzdök, hogy kiiktassam. De az többször is eszembe jutott, hogy ezen programozók vajon használják is a produktumuk, vagy csak csinálják? Mert ha az utóbbi, akkor már mindent IS értek.

Hogy a téma miért is került most elő? Először ezekkel az „okosságokkal” még jó pár éve, Fedora alatt futottam az első köröket. Nyilván duplán, mert a netbúkomon is ez van fent. Aztán előkerültek ezek a CentOS8 telepítése után egyből (az is megért volna pár mondatot…), majd amikor az lecserélődött az openSUSE-re, akkor újra. Majd jött a „vékonyklienses” SUSE, ami a HDD fejreállása miatt ismét duplán számít. Kezdem unni, hogy mindig keresgethetek. Most hogy leírtam, remélem nem (azért nem) lesz szükség rá (mert megszűnnek ezek a tvíkek működni, akkor tényleg nem tudom, hova menekülök – DOS-ra?).

A „picsogást” lassan ideje lesz befejeznem... A VNC-ről most legyen elég annyi, hogy megy. :) Kissé kényelmetlen ugyan, mert a „szerver” oldalon be kell jelentkezni meg el kell indítani a vncserver parancsot, (korábban volt egy tűzfal-port engedélyezés,) utána a „kliensről” a vncviewer-tigervnc-t elindítva meg kell adni a „szerver” címét (192.168.x.x::5901, a SUSE alapból erre a portra rakja), utána már látszik is a desktop. Van azért gond vele több is, amit majd érdemes lenne kikavarni (hogy mást ne mondjak: a „távképen” ha olyan dolgot indítok, ami root felhasználót igényel, akkor a jelszóbekérő ablak a „szerver” monitorán jelenik meg :-D ), de arra, amire nekem most kell, megfelel.

„Irodalom”:

• CSD a gnome szerint
• További magyarázat hogy ez nekem miért is kéne, hogy tetsszen
• Más is „szereti”
• CSD „fejléc” vastagságállítás
• Xfce dialógusablak
• gtk3-nocsd – vész esetére
• Nem kérünk a CSD-ből? Xfce fórumtopik
• Még mindig CSD, ez talán lassan okafogyottá válik
• Eltűnő szkrollbárok egyéb bugjai
• Eltűnő szkrollbárok eltüntetése
• Finomszkroll se kell

balagesz

---

2023.04.26.
2024.08.25. Kép.jav.