Window Maker 0.96.0

X, Wayland, Mir

Több mint három év után újabb kiadással jelentkezett a szabad és nyílt forráskódú, X Window System-hez fejlesztett ablakkezelő rendszer, a Window Maker. Változások a 0.96.0-s kiadásban:

  • Screen corners can be assigned an external command to be executed when the mouse pointer is entering those areas. In WPrefs, “Hot Corner Shortcut Preferences” can be used for configuration or by manually adding a “HotCorners” key and value to “YES” in the ~/GNUstep/Defaults/WindowMaker file. Hot Corners feature is disabled by default. Actions are specified by the “HotCornerActions” and are defined as a four entries list (“top left action”, “top right action”, “bottom left action”, “bottom right action”). A screen corner area is a cube shape defined by the “HotCornerEdge” which is a number of pixels from 2 (by default) to 10. To lower the risk of triggering that feature accidentally a “HotCornerDelay” key can be used which is the time before the action is triggered while the pointer is in one of the screen corner. Default value is 250 ms.
  • In WPrefs “Keyboard Shortcut Preferences” tab, three new actions can be configured: “Capture a portion of the screen”, “Capture a window”, “Capture the entire screen”. The file is saved in ~/GNUstep/Library/WindowMaker/Screenshots directory under a filename format “screenshot_%Y-%m-%d_at_%H:%M:%S” followed by the extension. Which can be png or jpg based on WRaster dependencies.
  • libXRes is now an optional dependency. XRes the resource extension for the X protocol is used to find the underlying processes (and PIDs) responsible for displaying the windows.
  • Support for _NET_WM_FULLSCREEN_MONITORS hint. That hint allows applications that support it to be set as fullscreen on multiple heads. It depends on Xinerama extension support.
  • To keep the dock on the primary head in a multi-head setup, set the option “KeepDockOnPrimaryHead” in ~/GNUstep/Defaults/WindowMaker to “YES” or click “Keep dock on primary head” under the WPrefs “Expert User Preferences” tab.

Részletek itt.

( bimi3 | 2023. 08. 08., k – 10:50 )

Van valami Widowmaker nevű fegyver is, bár az inkább hardver ;-)

( doc | 2023. 08. 08., k – 11:00 )

Wow, nem gondoltam volna hogy ezt meg fejlesztik, mar akkor is eleg regimodinak szamitott mikor kb 15 evvel ezelott Slackware-en alapos idomitas utan ez lett az elso szamu WM-em :)

Ja, ez is, mint az IceWM, egy nagyon régi WM. Jópofa retrós. Mivel én már kb. 5 éve csak billentyűzetorientált tiling WM-et használok, ezért az én workflow-mba nem illik bele, de nem egy rossz WM. 26 éve konzisztens, nem változik, nem kell újat megszokni, feature complete, kis erőforrás-igényű. Sokkal jobb választás adott esetben, mint a nagy mainstream, idiótákra szabott, bloat DE-k. Ez a Linux szépsége, hogy ennyiféle régi ökoszisztéma működik rajta (terminálban, tty-ban a még régebbiek is, a 70-80-as évekből), még olyanok is vannak, mint klasszik MacOS-jellegű WM (mlvwm), Amiga-szerű (amiwm), régi unixos (CDE, IRIX, Ultrix, stb.) felületek (mwm, nsCDE, 4dwm, 5dwm, uwm), de az IceWM, fwvm, JWM-hez is vannak Win3.x-es, Win9x-es, BeOS-es, OS/2-es témák, panelek, stb.. Esetleg a KDE3-fork, a Trinity.

Az flwm, Enlightenment is 26 éves már. Sőt, van, aki használja még az X-be épített twm-et (Tom's Windows Manager), az 1987-es. Nekem az használhatatlan lenne, meg ronda, de vannak nosztalgiázók, akik kitartanak mellette. Sok korai tiling WM is már lassan a 20+ évet tapossa. A Gnome, KDE is nagyon régi, de azokat azért nem számolom, mert pár évenként teljesen újraírják, új toolkit verzióra, teljesen átalakítják adott esetben, így olyan, mintha új lenne, köze sincs a régihez. A Compiz sem mai már.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

, aki használja még az X-be épített twm-et

o/

Igaz, nem "desktop" hanem olyan szerveren ahol kell X 1-2 alkalmazas vegett, oda a TWM + vnc kivalo valasztas ... Hasznalok meg icewm -et is ha kicsit tobb kell mint a TWM, de az elsodleges desktopom gnome :>

Fedora 42, Thinkpad x280

Én szeretem a minimalizmust, de a TWM-et nem bírom megszokni. Annyira furcsa a workflow-ja, ablakok előméretezése, meg nagyon egéralapú. Bár az is igaz, hogy lehet akármilyenre konfigurálni, és eddig nem sok valódi esélyt adtam neki, lehet egyszer komolyabban eljátszok vele.

Esetleg még amit nem említettem az előző hozzászólásban, és még retrós, az a olvwm (Openlook), ami a régi SunOS/Solaris grafikus felülete portolva modern rendszerekre.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Tévedtem, találtam a twm-hez jó konfigokat, ezen és ezen az oldalon. Hihetetlen, hogy a FreeBSD-s csávó miket ki nem hoz belőle.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( vidak | 2023. 08. 08., k – 14:38 )

Nahát, azt gondoltam volna hogy 26 év alatt elérik az 1.0-t

ők - és az akkoriban életre kelt projektek - általában igen szerényen kezelték a verziószámozást :)

Tipikusan senki nem mert 1.0 release-el nyitni, mert tudta, hogy még nincs kész.

 

Ehhez képest nézd meg mi van ma a browser 'piacon' :D számháboróznak, hogy épp melyiknek a legnagyobb ;)

zrubi.hu

$ git tag

Attol meg, hogy neked van aliasod, hogy natural sortingoljon, a tobbieknek a csapatbol nem lesz, csak beirjak ezt lustasagbol.

Aztan ha valaki ennek az outputja miatt szar taget csinal, egy elmeny letorolni. Eleg ha egyvalaki nem torli a sajatjarol es visszapusholja githubra.

Ott nem az van, hogy a git tag bármi lehet, nem csak verziószám?  Azaz logikus, hogy alfanumerikusan sortol és nem feltételezi, hogy version number minden tag.  Vagy ahogy írod is, van rá git config opció (tag.sort version:refname).  A human errort kiküszöbölendő lehet akár helper scripteket bevezetni a taggingre, de talán az jobb megoldás, ha a CI tagel és nem humán.

Jó, lehet, hogy loopba kerültünk, de itt azt mondod, hogy bizonyos embereknél nincs beállítva az a config opció, ami az ő tevékenységét - ember által végzett ismétlődő, tanulható, favágó melót - segítené, akkor ő majd jól elbaltázza és akkor utána takarítani kell.  Akkor miért nem az van, hogy

a) Megtanítjuk az érintett kollégákat, hogy miként lehet jól csinálni (írunk doksit a config opcióról, helper scriptet, amivel egyszerűbb ez a tevékenység, ilyesmik)
b) Beállítjuk a tagging permissiont. Nálunk épp nem github van a git "előtt", de biztos vagyok benne, hogy ott is megoldható, hogy ne tudjon bárki random taget felpusholni.
c) Miként tudjuk automatizálni. Erre írtam a "CI tagel" opciót, ami a mi Jenkinsünkben kb. úgy működik, hogy source-ból történő build idejében rákerül mindenre egy tag (ez a build numberből van képezve) és ha megfelelő tesztek lefutnak és a release-ready "pecsét" is rákerül (ez tulajdonképpen egy másik Jenkins jobot triggerel), akkor a verzió specifikus tag is rákerül. Ha indokolt, innen lehet később maintenance branchet leágaztatni.

( peterson v | 2023. 08. 09., sze – 07:17 )

Szerkesztve: 2023. 08. 09., sze – 07:18

Mindig is a kedvenc DE-m volt. De manapság nincs rá időm.

Viszont ha még 23 évig fejlesztik (mai állás szerint kb akkor megyek nyúgdíjba), akkor visszaállok rá, és olyan asztalt csinálok vele (1-11 év alatt :) ), hogy a KDE és társai is megirigylik, de tizedannyi erőforrásból. :D :D :D

"A megoldásra kell koncentrálni nem a problémára."

Nyilván a KDE-vel nem tud versenyezni feature-ök és grafikai cicoma terén, de nem is erre szánták. Az ilyen WM-eknél az a fő cél, hogy ne legyen útban, jól megszokott környeztet nyújtson, meg esetleg ennél némi retró style. Azt hozza is simán, 100-ad annyi erőforrásból, mint egy KDE. De mint írtam, a legnagyobb előnye ezeknek a kis WM-eknek, hogy stabilak időben, feature complete, egyszer megcsinálod hozzá a konfigot, és azt elmented (ami könnyű, mert csak egy-két plain text file, pl. git-tel kezelhető, vagy akár /home partíción is megmarad), akkor utána minden disztrón, környezetben (virtuális, valódi hardver, stb.) ugyanazt a workflow-t tudod portolni, évtizedekig változatlanul használni, és később sem érnek meglepetések, mint Gnome-nál, KDE-nél, hogy állandóan átvariálnak benne mindent, pluginek törnek el, nem fog bugzani, stb.. Nincs ezeknek sok függősége, kevés sornyi forráskód miatt akár lefordítva is gyorsan lefordulnak (ez fontos szempont, pl. ha Gentoo-t használsz, vagy olyan disztrót, aminek a tárolójában nincsenek meg ezek a WM előfordítva). Jó, a Window Maker az pont 12 konfig fájl, de ebből a legtöbb csak 1-2 soros, defaulton lehet hagyni, igazából csak az 1-2 főbb konfig az, amit érdemben kell hegeszteni.

Persze kell hozzá némi retró hajlam, főleg ehhez a Window Maker-hez, mert van egyfajta 90-es évekbeli logikája, kicsit a Win3.x-hez, korai MacOS-hez, némileg OS/2-höz hasonló, pl. alkalmazások minimalizálása asztalra, dokkba, szóval szokni kell mai szemmel, de nem rossz. Lehet némi idő, mire bekonfigurálod, de azt is csak egyszer kell megcsinálni az életben, és utána sok évig használod, bőven megéri. Rég nem használtam, lehet én is felteszem, de ma már annyira benne vagyok a tiling WM-ekben, meg a keyboard only, vi/vim-kiosztásos workflow-ban, hogy nem sok előnyt nyújtana, inkább egy kis visszalépés lenne a jelenlegi bspwm-hez képest. Viszont ahhoz képest meg van egyfajta retrós hangulata, bája, ami meg változatosságnak lehet jó lenne, meg a floating programokat is jobban kezeli, úgyhogy felteszem szerintem és bedrótozom, hogy pl. tty3-ból bejelentkezve ez töltsön be a bspwm helyett. A tty1 marad a bspwm, a tty2-ön meg vagy dkwm vagy IceWM megy, de azokat ritkán veszem elő, most az IceWM nincs is fent.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Raynes v | 2023. 08. 13., v – 22:25 )

Szerkesztve: 2023. 08. 14., h – 17:41

Na, most hétvégén feltettem Arch-ra. Forráskódból kézi forgatással kellett vitézkedni, a windowmaker és windowmaker-extra esetében is, mert az AUR-ban csak 0.95.9-es verzió van, és a windowmaker-extra is erre dependel. Ezt leszámítva simán fordult és települt mindkettő, a 0.96.0-ás és 0.1-es extra verzió.

A memóriafogyasztás 32760 KiB RSS, a valóságban nem ennyivel dobja meg a fogyasztást, mert ezek jó része shared lib (26750 KiB). Végül is ez nem rossz, mert jelenlegi bspwm-em hiába áll meg 2176 KiB-ból, de meg mellette az sxhkd, polybar, úgy meg együtt hárman 25560 KiB RSS-t megesznek, igaz ennek is jó része shared lib (20204 KiB) kb. ugyanezek voltak a számok dkwm esetén is, alig pár KiB eltéréssel. Egy dwm is elkéri a magáét, egy fullosabbra patchelt dwm, egy csomó hotkey-vel belefordítva is simán megeszik 8-10 MB memóriát, igaz ebben billentyűzetkezelés és bar is benne van, de pl. a bar-hoz kell futtatni saját scripteket, ez se nagyon fog 8-10 MB alatt megállni, szóval 16-20 megával itt is lehet számolni, és ez a helyzet a többi minimalista tiling WM-mel is, valami panelnek (dwm-blocks, i3bar, swaybar, polybar, lemonbar, dzen2, stb.), billentyűzetdemon-nak azoknál is kell futni, hogy működjön (sxhkd, mxhkd, xbindkey-s, vagy hasonló), és akinek kell systray meg notification, akkor ezek is. Egy 7-10 megával így is több kell a wmakernek, mint a szóban forgó WM-eknek, de cserében a wmakerben ott van a dokk, menü, háttérképkezelő, ikonkezelés, Xinemara, ICCCM támogatás (de nem tud cserében EWMH-t), runlauncher, tehát annyival többet is nyújt. Ami nincs benne, és egyeseknek hiányozhat (extra csomagok feltelepítésével pótolható): panel, notification, systray, screenshot, kompozitor, automount, lomtár, vágólap-kezelő, naptár, hálózatkezelő, egyéb alap beépített programok (fájl-, kép-, archívumkezelő, stb.), tehát továbbra sem annyira fullos DE, mint egy Xfce, Mate, Gnome, KDE, ezzel nem árt tisztában lenni, nagyon kezdőket ezért frusztrálhat, míg nem állítják be, nem teszik fel a szükséges csomagokat.

Nyilván ezek a tételek afölött értendők, hogy a Xorg bekajálta a maga 110-150 MB-ját, meg az xinit is azt a neki járó 2-3 megáját vagy ehelyett, ha login manager fut, akkor annak a fogyasztása vagy ha kell valakinek kompozitor (picom, compton, compiz), akkor az is. A tételek modern verziós, 64 bites, generic kerneles rendszeren értendők.

Maga a wmaker elég aranyosan retrós, kora 90-es évekbeli kinézetre, bár működésre szerintem nem hatékony, több kattintás is kell, pl. mire egy ablakot kitesz teljes képernyőre, valószínű hotkey-vel vagy a configba belenyúlással egyszerűsíthető, csak rá kéne szánnom az időt. A menüben egérrel szerencsétlenkedés is kontraproduktív egy billentyűzetorientált tiling WM-hez képest, de gyorsbillentyűk is beállítható, ha rászánja az ember az időt a konfigurálásra.

Egy dolog még zavar benne, hogy a wmaker beállításai és témái szét vannak szórva 7 konfigfájlba és 5 almappába, mind a ~/GNUstep/ mappában vannak, tehát szemetelik a home mappát, mikor erre a kulturált megoldás a $XDG_CONFIG_HOME-ban tárolás lenne, saját mappa alatt, mindent 1-2 konfigfájlba tömörítve (a ~/.config/wmaker/config ./autostart és ~/.config/wmaker/themes/). Gondolom ez még a régi hagyományok miatt van, de ma már nem számít polkorrektnek.

A másik, hogy az extra témák a wmaker-hez szerintem elég rondák, rosszabbul néznek ki, mint a default. Ezeket felesleges feltenni (wmaker-extra), megspórolom másnak is a köröket. Nagyon nagy piros pont viszont, hogy támogatja a vizuális ablakváltást, ikonokkal mutatja, hogy mire fog ugrani. Ez az egy funkció, ami hiányzik nekem a tiling WM-ekből, és bár valamennyire rofi-val pótolható, de az meg bugos. Sőt, egy videó rámutatott arra, hogy tud tilingot is, igaz egérrel körülményes, de hozzárendelhető gyorsbillentyű. Jó, lesz ez, szerintem megtartom, de előbb be kell állítani rendesen.

Szerk.: pozitív meglepetés, de ténylegesen friss boot után mérve csak 311 MiB memóriát eszik wmaker-rel a rendszer, míg friss boot után bspwm-mel 340 MiB volt a legalacsonyabb mutatott idle érték. Magyarán 29 MiB-tal kevesebbet eszik ténylegesen. Persze, ingadozik, de a legalacsonyabb értéket veszem figyelembe, az API váltás előtti free parancs módszerével mérve (used = total - cache/buf - shard). Az is igaz, hogy bspwm alatt a panelon van kint hasznos infó, hangerő, dátum-óra, előtérben futó alkalmazás neve, de ha ezeket kiteszem wmaker-re is, akkor azonos lesz szerintem a fogyasztás. Ám így is figyelemreméltó ez, veri ebben a legsoványabb WM-eket, és azokhoz képest tud egy csomó mindent. Mindenesetre egy fullos dwm-mel, JWM-mel lehet egy szinten, és soványabb, mint az IceWM, Openbox vagy az Awesome. Régi és retró gépeseknek nagyon ajánlom, mert nem csak sovány, de a tiling WM-eknél felhasználóbarátabb és hangulatosabb is.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Szerk.: pozitív meglepetés, de ténylegesen friss boot után mérve csak 311 MiB memóriát eszik wmaker-rel a rendszer,

Mekkora szar bloatware lett, hogy frissítették, bezzeg az icemwm :D

[ventura@fedora ~]$ free -m
               total        used        free      shared  buff/cache   available
Mem:            1953         278        1173           1         502        1529

Asszem nyertem \o/ :D

Fedora 42, Thinkpad x280

Nálam az IceWM többet eszik, nem emlékszem konkrétan, de kb. 100 MiB-tal, de most nincs fent. Biztos, hogy 64 bites, systemd-s rendszeren méred? Mert nálam simán tty konzonolon mérve majdnem 280 MiB az idle fogyasztás, amikor se WM, se X nem fut még.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Azon

[ventura@fedora ~]$ free -m
               total        used        free      shared  buff/cache   available
Mem:            1819         286        1232           2         300        1317
Swap:           1818           0        1818
[ventura@fedora ~]$ uname -a
Linux fedora-xen 6.4.10-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Aug 11 12:20:29 UTC 2023 x86_64 GNU/Linux

Tessék egy másik rendszer, itt kicsit "többet" eszik :D

Viszont lófaszt nem számít, mert fogok egy böngészőt elindítom pár tab pár bloatware js oldal és máris beszippantott 2G-t. És akkor baromira mind1, hogy a wm 280M vagy 380M et eszik ...

Fedora 42, Thinkpad x280

Ja, az szép, akkor az Arch bloat. Pedig nálam nem fut semmi extra, egy NTP-n kívül, a többi az szokásos systemd-cucc (systemd, logind, udevd), amit nem lehet kikapcsolni (journald-t lehetne, de nem érdemes). Ami sokat eszik nagyon, az a Pipewire. Az is igaz, hogy nálam a böngésző nem mindjárt eszik 2 gigát, általában 600 mega, mert csak az aktuális fület tölti be, de igen, ahogy böngészgetek több fülön, nálam is a 2 gigánál jár a Firefox.

Egyébként netbookokon, SBC-ken, régi gépeket (1-2 giga RAM-mal) nagyon nem mindegy, hogy a WM mekkora, meg ha sebességre gyúrsz.

A vicc az, hogy azóta megpróbáltam bspwm-et, most a polybar is ki volt kapcsolva, mégse ment 340-350 mega alá, amit sokallok. Már Alucard kolléga is mondta, hogy nála Debianon is kevesebben esznek ugyanazok a dolgok, mint Arch-on.

Közben kipróbáltam, és csak a tty-on 265 MiB fogyasztást mutat, bekonfigurálatlan IceWM alatt 315, ez csak 4 megával több, mint a wmaker, viszont 25-35 megával kevesebb, mint a bspwm. Amit nem értem hogy kikapcsolt polybar-ral is többet eszik a bspwm, holott a htop szerint a bswpwm és sxhkd folyamata csak 2-2 mega RSS-t eszik, ennek nagy része is shared lib, tehát kevesebbet kéne neki foglalni, mint az IceWM-nek, wmaker-nek.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

>mert fogok egy böngészőt elindítom pár tab pár bloatware js oldal és máris beszippantott 2G-t.

Nagyjából ezt akartam hozzászólni pár napja aztán lusta voltam, de amúgy kb. emiatt maradtam én is pár éve már xfce-nél, előtte openbox/wmii ment nálam főleg. Aztán amikor realizáltam, hogy egy firefox indítás után kb. tök mindegy mert teljesen felborul az egész memória-felhasználás aránya akkor maradtam xfce-nél. Végül is jól jön az a pár extra szolgáltatás amit tud.

Valahol attól is függ, hogy ki milyen programokat használ. Mert pl. aki csak Gtk-s vagy Qt-s programokat használ, annak egy Gnome, Xfce, vagy Qt esetén a KDE/LXQt nem nagy tétel, mert igaz, hogy nagyobbak, mint egy WM, de előtöltik maguknak a sok Gtk-s vagy Qt-s shared libet, amit viszont az utánuk induló program használnak közösben, és nem kell újra betöltögetniük, így a DE nem okoz nagy többletfogyasztást, az összfogyasztásba beolvad shared lib formájában.

Míg egy sovány WM hiába foglal keveset, nem nagyon tölt elő libeket, így ha valaki WM-en elindít sok Gtk-s, Qt-s programot, akkor ez kiegyenlítődik, mert akkor az alkalmazásuk maguk töltik be a libeket, és összességében az össz-memóriafogyasztás kb. ugyanott lesz, függetlenül attól, hogy a grafikus felület önmagában mennyit eszik.

Amit nem értek, hogy egy wmaker, IceWM esetén a teljes felállt rendszer hogy tud 311 és 315 MiB-ot enni, mikor egy még minimalistább tiling WM-mel (bspwm, dwm, dkwm) meg 340-350 környékén futkorászik panel nélkül ugyanazon a rendszeren. Sőt, most kipróbáltam WM nélkül csak st terminált futtatva X.org-ban, ilyenkor WM sem fut, se sxhkd, se panel, se háttérkép, és ekkor evett a rendszer 314 MiB-ot, cold boot után. Ezt nem értem, hogy a wmaker, IceWM hogy csinálja, hogy 0-val dobják meg lényegében a fogyasztást egy WM nélküli állapothoz képest. Valamilyen módon a shared libekekkel játszanak rettenet ügyesen. Mindenesetre a ps aux, és htop kimenete alapján nem így kéne kinéznie a felállásnak. Ezt nem sikerül megfejtenem.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Használgattam, reszelgettem egy kicsit, javulgat használhatóságban ez a wmaker. Bár már találtam egy korlátját, ami miatt lehet nem lesz soha a fő WM-em. Ez pedig, hogy nem kezel billentyű-akkordokat (Emacs/tmux-stílus), vagy módokat (vi/vim/Kakoune/Helix-stílus). Nekem valamelyik kell, mert minden funkciót bill-ről érek el, minden alkalmazást arról indítok, és ha nincs akkord/mód, akkor csak pár layert használhatok, super+egyéb, control+super+egyéb, control+super+shift+egyéb, control+alt+egyéb, és ez bár soknak tűnik, de pont nem elég. bspwm alatt is van már vagy 4 extra réteg akkordként, ahhoz, hogy mindenre legyen külön bill-kombó (és még 22+ layer lehetséges a szabadon maradt billentyűkombinációk miatt). Elvileg sxhkd-vel pótolható, az a megoldás WM-független (bár ehhez az is kell, hogy az adott WM-nek lehessen üzengetni CLI messaging-gel, vagy IPC-vel), majd kísérletezek ilyen irányban is.

A másik korlát, hogy a wmaker nem tud dinamikus/automata tilingot, de az is igaz, hogy mivel hivatalosan stacking WM, nem tiling, ezért nem is lehet tőle elvárni. Már így is szép, hogy legalább a kézi tilingot támogatja, amit szintén nem lenne kötelessége.

Azt is meg kell jegyezni, hogy tökéletes WM nincs. Mindegyiknek más az előnye, de cserében más a nyűgje. Pl. az i3wm/Sway tud tabbed módot, meg billentyű akkordokat és módokat, de nem tud automata/dinamikus tilingot, a dwm tud dinamikusat, de nem támogat füleket, akkordokat, módokat, és pain in the ass patchelni, nem tud IPC/messaginget, nem támogat EHWM vagy hasonló protokollt, amivel üzeni lehetne neki. Az Openbox csak snappinget támogat, tilingot nem, az XML-es konfigja hülye, billentyűzetakkordokat tud, de módokat nem. A bspwm tud automata tilingot, de csak egyféle kiosztást, cserében sxhkd-t igényel, ami tud bill-akordokat, de nem módokat. Az awesome tud mindent, de cserébe a legbloatabb. Az Fluxbox tud a BeOS/Haiku-ból ismert egy ablakba több alkalmazást fülként integrálni, pl. ez is cool, amit más WM nem tud, cserében viszont nuku tiling, és nem tud bill-módokat. A Qtile Python alapú, azt meg utálom, az Xmonad-ot nagyon nehéz konfigurálni, mindent hosszasan Haskell-ben megírva kell újraforgatni, jó sok függőség is kell neki. Az IceWM nem tud tilingot egyáltalán, és bill-módokat/akkordokat se. Herbstluft WM-nek az automata tiling funkciója elég korlátozott, és sxhkd-t igényel (így kb. az az előnye-hátránya mint a bspwm-nak, és ilyen a dkwm is). A JWM nem tud tilingot, bill-rétegeket és pain in the ass konfigolni. A StumpWM-nek kell a Common Lisp, ami miatt bloat. Az exwm (Emacs WM-je) Emacs-függő, lassú, egy szálas, elég sok korlátja van. Nálam nincs, de a multimonitort is mindegyik máshogy támogatja, más erősségekkel, gyengeségekkel. Lehetne még sorolni napestig.

Szóval reszelgetem még, hogy megnézzem mit lehet kihozni ebből a wmaker-ből. Mindenesetre a retró hangulata a legjobban tetszene az összes WM közül, az IceWM, Fluxbox, Openbox, JWM mellett kezdőknek is nagyon ajánlom gyenge és retró gépekre, pl. netbookok, régi P2-P4, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Közben kitaláltam, hogy hogyan fogom megvalósítani a billentyűakkordokat. Az akkordok első, rétegkijelölő elemét wmaker-ben hozzárendelem egy figyelőalkalmazás indításához, fzf, dmenu, sxhkd-példány, hasonló, ami beveszi az akkord többi elemét, lereagálja (elindítja rá, amit kell) és utána kilép. Ezzel egy WM független módszerem lesz, ami memóriát se foglal, mert csak addig fut, ameddig szükség van rá, utána kilép azonnal.

Valamennyire az sxhkd, mxhkd, xbindkeys, stb. is WM függetlenek, de néhány WM-mel összeakadhatnak, meg állandóan kell fussanak a háttérben, hogy a billentyűeseményeket figyeljék.

A másik, amire gondoltam, hogy a bar-t, polybart kiváltom valami mással. A virtuális asztalokat a wmaker úgyis kijelzi. Ablakcímek nem kellenek. A hangerőt, fényerőt bele tudnám drótozni értesítésként, hogy mikor állítom, akkor lássam mire állt át, hány %-ra, nem kell annak mindig kint lenni, utána kiléphet. Amivel bajban vagyok, az a dátum+idő, annak kint kell lenni, és nem tudom mivel tegyem ki. A wmaker-hez van egy idő/dátum modul, azt majd kipróbálom. Most az xclock-ot próbáltam, esetleg a conky jön szóba, de azok majdnem annyit foglalnak önmagukban, mint egy komplett polybar. Ha ezeket meg tudnám oldani, akkor akár a fő WM-em is lehetne a wmaker, mert a hiányosságai körbehekkelhetők, és amúgy tetszik.

Azért rugózok ezen ennyit, mert a bar-t és a billentyűkezelést amúgy is el akartam hagyni már tiling WM-ek alatt is. Növeli a bloatot, memóriafoglalást, függőségeket, és érzem, hogy meg lehetne oldani egyszerűbben, minimalistábban, WM-függetlenül. Ez a saját, nowm-típusú megoldásomhoz is jól jönne.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

> akár a fő WM-em is lehetne a wmaker

Ennyi tilling wm használat után, meglepődtem ezen. Megszokott tillingről nem nagyon szoktak visszajönni. Rövid <1 perc videót dobhatnál fel, tilling meg wmaker desktopodról, böngésző, pár konzol megnyitása, váltás köztük, ilyesmi. Kíváncsi lennék rá hogy működik ez nálad. 

Igen, furcsa tiling után a stacking, óriási visszalépés hatékonyságban. Bár én legtöbbször kvázi teljes képernyős (az i3wm nyelvén monocle) módban használom a legtöbb programot (windowgap sincs, se ablakdekoráció, se keret), és csak néhány virtuális asztalomon van tiling (master-stack vagy grid, általában kerettel és résekkel, de dekoráció nélkül), ha tilingot akarok, akkor átküldöm az illető programot ezekre az asztalokra, de ez ritkább. Illetve a játékok és mpv-vel nyíló vagy böngészőben nézett videók azok, amik meg teljes képernyőn mennek (ez tényleg full screen, a bar se látszik).

A wmaker viszont tud némi tilingot, 2 ablakos edge snapping és 3 ablakos master-stack vagy 4 ablakos corner snapping / grid lehetséges benne, az nekem talán elég. Bár nem automatán tudja, csak kéziben, de lehet az is elég.

Az a baj, hogy a videón nem sokat látnál, csak egy háttérképet, felül fekete bar-ral, meg hogy a semmiből mindenféle terminál pattan fel mindenféle méretben, aztán az egész értelmetlennek tűnne, meg vizuálisan se látványos (se kompozitor, se átlátszóság, se árnyékok, se animációk nincsenek), mivel nagyon puritán, nem vagyok designer. A wmaker még nincs kész se, csak kísérletezek vele, hátha beválik. Nem biztos, de megér egy esélyt adni neki.

Leginkább azonban az egész történetben nekem a memóriafogyasztás megmagyarázhatatlan. Hogy egy nagyobb RSS = USS + SHR foglalású wmaker és icewm betöltése után hogyan foglalhat a frissen bootolt rendszer idle-ben kevesebb memóriát, mint a htop/ps/smem szerint is tized annyi foglalású WM nélküli vagy tiling WM-es állapottal (bspwm, dk wm). Mert a wmaker-ben ott vannak az asztali ikonok, dokk, ablakdekorációk, Wing-framework, stb., és mégis kevesebb memóriából áll meg. Most én nem értem, hogy hogyan működnek a dolgok, vagy itt valami nagy félreértés, félremérés van.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Igen, a top is ugyanazokat a számokat írja, mint a htop. Tudom, hogy tud kimenetet menteni a -n kapcsolóval csak korlátozott lépésben fut le, utána kilép, a kimenetét meg el lehet menteni, vagy másik parancsba pipe-olni. Viszont szerintem is a libekkel játszadozás lesz a megoldás, de még az se teljesen áll össze, mert a bspwm, sxhkd-nak max. ilyen XCB, xinemara a függősége, míg a wmakernek több van. Sehol se stimmelnek a számok.

Természetesen az összes futó binárist és libet figyelembe veszem, nem csak a WM folyamatát, hanem minden extrát, ami azzal együtt fut.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Na, azt hiszem rájöttem. Egyrészt a memóriafogyasztást monitorozó szkriptem, amivel bspwm/dk alatt monitorozok, az eszik többet, ezt belámultam, míg icewm, wmaker, twm alatt nem azzal néztem (hotkey hiányában nem indítottam el), hanem csak st terminálban vmstatból kinyerő egyszerűbb szkripttel (a free nem játszik, mióta az API-ja megváltozott). Korábban nem vettem észre, de az xss-lock folyamata is fut tiling alatt. Plusz a polybar, és a háttérkép buffere (maga a feh, ami betölti a hátteret, az nem foglal memóriát, mert kilép azonnal a kép kitétele után). Ezek nélkül már összeértek a WM-ek fogyasztásai, kb. 310-315 MB körül van mindegyik, icewm, wmaker, twm, bspwm.

A trükk egyébként nem is igazán ezekben, van, hogy a polybar, xss-lock eszi a saját RSS-ét, hanem hogy ezek közvetve a Xorg szerver folyamatának a memóriahasználatát is meghízlalják. Ez az, amit az icewm, wmaker nem csinál, és ezt még mindig figyelemre méltónak tartom, valahogy irtó ügyesen játszanak a shared libekkel, vagy máshogy hajtják meg a Xorg-ot, így erőforrás-takarékosabbak, kb. egy bspwm, twm fogyasztásából hoznak egy csomó extra funkciót, dokk vagy tálca, menü, ablakdiszítések, aktív sarkok és snapping, stb.. Azt kell mondjam, hogy iszonyat ügyesen vannak optimalizálva memóriafogyasztásra is. Látszik, hogy profik írják ezeket, nem most kezdték a szakmát.

310 MB alá nem nagyon lehet bemenni használható WM-mel, 64 bites rendszeren legalábbis nem, mert már nem a WM eszi azt a memóriát, hanem a kernel, a systemd alap szutykai (logind, journald, egyebek), pipewire és társfolyamatai, dhcpcd, Xorg, xinit, és sajnos a wpa_supplicant se nélkülözhető nálam a Wi-Fi miatt. Egy 32 bites, systemd-mentes, pipewire helyett max. pulseaudiot vagy apulse-t, és vezetékes kapcsolatot használó gépen viszont be lehet menni 310 mega alá, talán még 200 alá is. Egy custom minimál kerneles Gentoo-val talán még jobban. Viszont 100 alá nem hinném, vagy csak valami lényeges funkció vagy használhatóság rovására. Még Waylanddel sem, mondjuk Sway, Hyperland, mert ott meg a XWayland fogyasztása fog visszaegyenlíteni. 100 alá maximum BSD-kkel lehet bemenni.

Szerk.: dobtam az xss-lock-ot, és a képernyővédő+lock kombót a suckless-féle xssstate+xsidle.sh párossal indítom. Ezzel nyertem kb. 4,4 MB memóriát az xss-lock-hoz képest, ami 9 mega - 4,5 mega shared lib-et evett, a mostani meg 4 megát - 3,9 mega shared libet, azaz a tényleges fogyasztást csak kb. 100 KB-tal dobja meg 4,5 MB helyett. Így már csak a polybar az, ami sokat eszik, azt majd kiváltam valahogy mással.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Raynes v | 2024. 04. 07., v – 02:41 )

Közben észrevettem egy újabb jó tulajdonságát ennek a WindowMaker-nek. Hajlandó külön tty-on indított startx-szel akkor is futni, ha már más WM fut más tty-ról bejelentkezve. Így párhuzamosan futtatható más WM-ekkel. A bswpm, dkwm is tudja, feltehetőleg az egyszerűbbekkel mind megy. Az IceWM viszont nem hajlandó így futni, még másik display-re kényszerítéssel sem.

Iszonyat cool több WM-et egyszerre futtatni. Zephyr-rel lehet WM-ben WM-et is, de akkor egyes billentyűesemények ütközhetnek, így meg nincs velük gond. Az is igaz, hogy ilyet a Wayland is tud, hogy több kompozitor fusson egymás mellett, akár ugyanaz a kompozitor több példányban, vagy különbözőek. Persze lehet ott sem mindegyik támogatja.  Illetve Wayland alatt natívan megy az is, hogy futó kompozitorból futtatjuk a másikat, ami egy ablakban fut. Sőt, az XWayland rootful-lal tud ablakban X-es WM-et futtatni, azt még nem próbáltam.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”