( Raynes | 2022. 08. 23., k – 05:41 )

De bloat a TB. Persze ekézni nem akarom, mert a többi grafikus mailkliens még bloatabb, és még szarabbak is sajnos, főleg az Electron-szutykok nagyon erőforrás-pazarlók. A CLI/TUI mailkliensek a képeket, HTML-mailokat, egyéb csatolmányokat természetesen grafikus programban nyitnak meg (vagy amiben te akarod, beállítod), szöveges nézetben csak egy link látszik. Az e-mailek nagy része viszont ma is plain text, és nem tartalmaz grafikus cumót. A HTML-es mailek a kivétel, de azokat meg általában hírlevelekben, meg kéretlen szutykokban szoktál tolni, esetleg ritkán cégesben. A HTML-es mailek is ugyanolyan mailek, mint a nem HTML-s, csak bele van kódolva csatolmányként egy HTML-es „melléklet”, amiben HTML-kód van. Továbbá de, még ma is minden mail plain text. A nem ilyen részek base64 kódolással vannak benne, ami szintén plain text. Ha nem hiszed el, nyisd meg akármelyik e-mailed forrását. Így lett RFC-kben rögzítve, és ez a jövőben sem fog változni, visszafelé kompatibilitás miatt.

A levélfiók felcsatolása helyi fájlrendszernek nem abszurd. Természetesen ebből a szerver üzemeltetője semmit nem lát, épp úgy csak annyit, hogy néha van szinkronizálás a szerverrel új levelekért, ahogy a többi mailkliensnél. Extra terhelést ez a koncepció nem okozna szerveroldalon, csak a letöltött levelek tárolása, rendezése történne más formában.

A downloadmail csak egy ötlet volt, egy elképzelést vázoltam, nem egy már létező programot, így annak hívjuk, aminek akarjuk. A GUI-val az a baj, hogy feleslegesen növeli a kódméretet. A mai modern mailkliensekben van egy csomó szutyok, SQL-kelezés, JS és webengine (hiszen lényegében egyben bújtatott böngészők is) sandboxinggal, Gtk-témázás, címjegyzék, naptárfunciók, biztonsági védelmek, meg még sorolni is nehéz lenne, simán több millió kódsor van bennük. Ezek közül nekem egyik sem kéne egy mailkliensben. Mondom, a neomutt meg is felelne, ha nem indulna olyan pokolian lassan, és nem a betöltési idő, mert az betöltődne pár ms alatt, hanem a levelek lekérése a szerverről lassú, és nem a háttérben történik. Továbbá a CLI/TUI-megoldásoknak, minimalizmusnak az is előnye a kis hardverigény mellett, hogy kevesebb biztonsági rés van benne, mivel kisebb kódbázis, továbbá nem futtat le mindenféle szutykot magától, ahogy a grafikus megoldások.

A Scroll Lockra jelzést meg össze lehet hozni nem GUI-s szoftvernél is. Nem mintha akarnám, egy desktop gép kivételével minden más gépemen (laptopok), nincs is ilyen led. A mostani elsődeleges notimon még Num Lock led sincs, elsőre kicsit furcsa volt, de meg lehetett szokni, meg csináltam rá workaroundokat.

Nekem már majdnem minden szoftverem, amit használok, CLI/TUI, még a lockscreenként szolgáló screensaver is (terminálban futó asciiquarium, ami transzparens alock-kal van lezárva). A mindenen azt kell érteni, hogy tényleg szinte minden, text editor, fájlkezelő, számológép, rendszerinformációs és rendszeradminisztrációs programok, zenelejátszó, konvertálók, tömörítők, task manager, szótár, csomagkezelés, naptár, időjárás, password manager, szedőprogram (XeTeX), torrentkliens, még a táblázat/adatbázis-kezelést is meg tudnám oldani, ha használnék ilyet. Már csak a mailkliens, böngésző (ezekben futnak az üzenetküldő szolgáltatások is), gaming szolgáltatások launcherei GUI-k. Továbbá a játékok nem GUI-k, de grafikusak, az mpv, sxiv, zathura szintén nem GUI-s, de grafikus bufferbe jelenitik meg, amit kell, ezt nem is lehet máshogy, különben nem lenne grafikájuk. A dmenu tartozik még ebbe a kategóriába, de lehet azt is kiváltom terminálban futó fzf-fel. Notification-t nem használok, de azt is terminálban oldanám meg. Böngészőnél, játéklaunchernél nem tudsz mit csinálni, azt csak így írják, csak így használhatók. A mailkliens így már csak, ami pengeélen táncol nálam. Igazából ha a böngésző megoldható lenne még, és lenne konzolon truecolor támogatás grafikus gyorsítással, és jobb Unicode-támogatás (valamilyen szinten támogatott, de a tty-fontoknak a nagy része nem túl sok Unicode glyphet tud), akkor ellennék tty konzolban is az idő nagy részében.

Vagyis még van egy GUI-s program nálam, de ezt is a böngésző indokolja. A file picker. Ugyanis a böngészők, mikor fájlt töltesz le adott helyre, vagy töltesz fel, akkor ahhoz nem drótozhatsz be saját kedvre akármilyen terminálos fájlkezelőt, egyszerűen nem kivitelezhető, pedig jó lenne. De ezt nem veszem külön kategóriának, mivel böngésző használja csak, annak a részének, opcionális függőségének tekintem. Továbbá van pár szoftvertípus, ami csak GUI-ban használható, bár nem használok ilyeneket, de pl. rajzolóprogramok, képmanipulálók, videóvágós szoftverek, DAW, CAD és 3D renderelős szoftvere, stb. nagyon nem lenne hatékony vagy kivitelezhető CLI/TUI alapon, de ilyet kevés átlag felhasználó használ. Átlagon itt azt értem, hogy nem ez a munkája, nem szakember ezeken a területeken, amikhez ezek a spéci szoftverek készültek, hanem csak hobbistaként használja.