WM_CLIENT_LEADER
De ICCCM-eigenschap die naar het leidervenster van een programma wijst, het enige met de sessie-ID, zodat een sessiebeheerder weet welke vensters bij hetzelfde programma horen.
Een programma kan vijf toplevel-vensters hebben, maar een sessiebeheerder wil één commando per programma, niet per venster. ICCCM 2.0 loste dat in 1994 op, in dezelfde ronde als XSMP: elke client wijst een leidervenster aan, bij voorkeur een onzichtbaar dat nooit wordt gemapt, zet daarop SM_CLIENT_ID met de ID die de sessiebeheerder uitdeelde, en zet op elk van zijn toplevel-vensters, de leider inbegrepen, WM_CLIENT_LEADER op de venster-ID van de leider. Het pad van een venster naar het juiste herstartcommando is dus twee opzoekingen. Zodat de vensterbeheerder na een herstart het juiste venster op de juiste plek kan terugzetten, kreeg elk venster ook WM_WINDOW_ROLE, een string die het hoofdvenster onderscheidt van het voorkeurenvenster.
GTK en Qt doen dit alles zonder dat de programmeur het merkt: GDK maakt per display een onzichtbaar leidervenster dat ook WM_CLASS draagt, en xprop op vrijwel elk GTK-venster toont WM_CLIENT_LEADER(WINDOW): window id # 0x…. Vensterbeheerders hergebruikten de eigenschap als groepsmarkering: KWin bundelt vensters met dezelfde leider in de taakbalk, naast de oudere groep in WM_HINTS. De sessiekant wordt zelden gebruikt, omdat weinig programma's verstandig op SaveYourself reageren, zodat de eigenschap vooral een tweede leven leidt. Wayland verving beide door app_id, één string per toplevel-venster, zonder sessie-ID.