Vedere de ansamblu X Window - HOWTO

Acest document intenţionează să prezinte o vedere de ansamblu a arhitecturii sistemului X Window, cu speranţa de a da cititorilor o mai bună înţelegere a motivelor pentru care sistemul este proiectat aşa cum este proiectat, a componentelor ce se integrază cu X şi a modului în care acestea se îmbină împreună pentru a furniza un mediu de lucru grafic şi ce alegeri există în legătură cu aceste componente.

Vom explora câteva concepte care sunt menţionate adesea dar pot fi oarecum neclare pentru cei fără o pregătire tehnică, cum ar fi widget-urile şi toolkit-urile, managerii de ferestre şi mediile desktop. Vor fi de asemenea prezentate câteva exemple care arată cum interacţionează aceste componente în folosirea de zi cu zi a aplicaţiilor.

Acest document este în mod deliberat la un nivel tehnic nu prea ridicat. El este bazat pe cunoştinţele (empirice ale) autorului referitoare la subiect şi deşi este menit în principal ca o introducere non-tehnică, el poate cu siguranţă beneficia de pe urma oricăror comentarii, exemple şi explicaţii adiţionale şi nu în cele din urmă corecţii tehnice. Autorul apreciază orice întrebări şi comentarii referitoare la acest document şi poate fi contactat (în limba engleză) la adresa roadmr@entropia.com.mx.

Pe vremea când UNIX-ul era o noutate, prin 1970, interfeţele grafice pentru utilizatori erau doar o ciudăţenie cu care se jucau nişte cercetători în laboratorul Xerox PARC. Astăzi, în schimb, orice sistem de operare ce speră să fie competitiv are nevoie de un subsistem GUI (Graphical User Interface, adică Interfeţe Grafice pentru Utilizatori). Interfeţele grafice, GUI, ar trebui să fie uşor de folosit. Acest lucru însă nu a fost de prea mult interes sub UNIX, care în mod tradiţional a fost, într-o oarecare măsură destul de ostil cu utilizatorul, preferându-se versatilitatea în schimbul uşurinţei de folosire. Totuşi, există câteva motive pentru care o interfaţă grafică este de dorit chiar şi pe un sistem UNIX. De exemplu, dată fiind natura sa multitasking, este natural să existe o mulţime de programe ce rulează simultan într-un anumit moment. O interfaţă grafică furnizează un control mai bun asupra modului în care informaţiile sunt prezentate pe ecran, prin urmare furnizând facilităţi mai bune pentru a avea o mulţime de programe pe ecran în acelaşi timp. De asemenea, unele tipuri de informaţii sunt mai bine prezentate într-o formă grafică (unele, cum ar fi imaginile şi alte date inerent grafice, pot fi prezentate numai în formă grafică).

Din punct de vedere istoric, UNIX-ul a avut o mulţime de îmbunătăţiri făcute în mediile academice. Un bun exemplu este codul de reţea BSD care i-a fost adăugat spre sfârşitul anilor '70, cod dezvoltat la University of California, în Berkeley. În fapt, sistemul X Window (numit şi X dar niciodată X Windows), care este fundaţia pe care se sprijină cele mai multe dintre subsistemele GUI găsite în sistemele UNIX moderne, inclusiv Linux şi BSD, a fost de asemenea rezultatul unui proiect academic, şi anume proiectul Athena de la Massachusetts Institute of Technology (MIT).

Unix-ul a fost un sistem de operare multi-utilizator, multi-tasking şi time sharing încă de la începuturile sale. De asemenea, după incorporarea tehnologiei de reţea, acesta a avut capabilitatea de a permite utilizatorului de a se conecta (de) la distanţă (remotely) şi a lucra pe sistem. Anterior, acest lucru se realiza fie prin terminale seriale ordinare (dumb) sau prin conexiuni cu legendarul telnet.

Când a sosit timpul a se dezvolta un sistem GUI care să poată rula în principal sub Unix, aceste concepte au fost reţinute şi incorporate în design. În fapt, X are un design destul de complex, care adeseori a fost menţionat ca un dezavantaj. Totuşi, datorită acestui design, este un sistem cu adevărat versatil şi aceasta va deveni clar pe măsură ce vom explica cum toate părţile ce compun un sistem GUI funcţionează împreună sub Unix.

Înainte de a arunca o privire la arhitectura X-ului, este necesar un foarte scurt tur istoric ce descrie cum ajuns aceasta pe sistemul d-voastră Linux.

X a fost dezvoltat de proiectul Athena şi a fost lansat în 1984. În 1988 o entitate numită "X Consortium" a preluat X-ul şi până în prezent acesta se ocupă de dezvoltarea şi distribuţia sa. Specificaţia X este disponibilă în mod liber, iar aceasta a fost o mişcare deşteaptă pentru că a făcut X aproape omniprezent. Astfel a fost creat XFree86, care a fost implementarea de X pe care o folosim pe computerele noastre Linux. XFree86 este funcţional şi pe alte sisteme de operare, cum ar fi *BSD, OS/2 şi probabil altele. De asemenea, în ciuda numelui său, XFree86 este funcţional şi pe alte microprocesoare.

X a fost proiectat cu o arhitectură client-server. Aplicaţiile în sine sunt clienţii; ele comunică cu serverul, fac cereri către acesta şi de asemenea primesc informaţii de la server.

Serverul X menţine un control exclusiv al display-ului (dispozitivul de afişare grafică) şi serviciilor cerute de clienţi. În acest moment avantajele folosirii acestui model sunt destul de clare. Aplicaţiile (clienţii) trebuie să ştie doar cum să comunice cu serverul şi nu trebuie să ştie detaliile referitoare la dispozitivul de afişare grafică în sine. Simplificat, un client îi spune serverului ceva de genul "desenează o linie de aici până aici", sau "desenează acest şir de caractere, folosind acest font, la această poziţie pe ecran".

Aceasta nu ar fi cu nimic diferit faţă de folosirea unei biblioteci grafice pentru a scrie aplicaţia noastră. Totuşi, X merge un pas mai departe. Acesta nu constrânge clientul să fie pe acelaşi computer ca şi serverul. Protocolul folosit în comunicaţiile dintre clienţi şi server poate funcţiona printr-o reţea sau, în fapt, prin orice "mecanism de comunicare între-procese ce furnizează un curent (stream) fiabil de octeţi". Bineînţeles că modul preferat de a realiza acest lucru este folosirea protocoalelor TCP/IP. Precum se vede modelul X este într-adevăr puternic; un exemplu clasic este să rulez o aplicaţie ce foloseşte procesorul intensiv pe un super-computer Cray, un monitor de baze de date pe un server Solaris, o aplicaţie de e-mail pe un mic server de mail BSD, un program de vizualizare pe un server SGI şi să afişez toate acestea pe ecranul staţiei mele de lucru Linux.

Până acum am văzut că serverul X este acela care se ocupă de afişarea (desenarea) în sine a informaţiei grafice. În plus, întrucât serverul X rulează pe computerul la care lucrează utilizatorul, este responsabilitatea serverului X să realizeze toată interacţiunea cu utilizatorul. Această responsabilitate include citirea mausului şi tastaturii. Toate aceste informaţii sunt transmise aplicaţiei client, care bineînţeles va trebui să reacţioneze la acestea.

X furnizează o bibliotecă de funcţii, numită Xlib, care are grijă de toată comunicaţia la nivel jos (low-level) între client şi server. Este evident de aceea că clientul va trebui să invoce funcţii conţinute în Xlib pentru a-şi face toată treaba.

În acest moment totul pare să funcţioneze corespunzător. Avem un server responsabil de afişarea ieşirilor vizuale şi colectarea intrărilor de la utilizator, aplicaţiile client şi o cale prin care acestea comunică între ele. Dacă ne imaginăm o posibilă interacţiune între un client şi un server, clientul ar putea cere serverului să-i aloce o suprafaţă dreptunghiulară pe ecran. Fiind un client, nu sunt interesat unde sunt afişat pe ecran. Îi spun doar serverului "dă-mi o suprafaţă de X pe Y pixeli" şi apoi chem funcţii pentru a realiza acţiuni cum ar fi "desenează o linie de aici până acolo", "spune-mi unde mută utilizatorul mausul în suprafaţa mea de ecran" şi aşa mai departe.

Totuşi, n-am menţionat niciodată cum se ocupă serverul X de manipularea suprafeţelor afişate de clienţi pe ecran (numite ferestre). Este evident pentru oricine a folosit vreodată o interfaţă grafică (GUI) că este necesar să ai control asupra "ferestrelor client". În mod normal puteţi muta, aranja, schimba dimensiunea, maximiza sau minimiza ferestrele. Cum se ocupă serverul X de aceste acţiuni? Răspunsul este: nu el o face.

Unul dintre principiile fundamentale ale X-ului este "noi furnizăm un mecanism, nu politici". Aşadar, deşi serverul X furnizează o cale (mecanism) pentru manipularea ferestrelor, el nu spune în fapt cum este făcută această manipulare (politici).

Tot acest amalgan de mecanisme/politici se poate rezuma la aceasta: este responsabilitatea altui program să gestioneze spaţiul de pe ecran. Acest program decide unde să poziţioneze ferestrele, furnizează mecanisme prin care utilizatorii controlează aspectul ferestrelor, poziţia şi dimensiunile lor şi de obicei mai furnizează "decoraţiuni" cum ar fi titluri pentru ferestre, rame şi butoane, care ne dau control asupra ferestrelor în sine. Acest program ce gestionează ferestrele se numeşte "manager de ferestre" (window manager).

"Managerul de ferestre în X este doar un alt client -- el nu este parte a sistemului X, deşi el se bucură de privilegii speciale -- şi nu există un singur manager de ferestre; de fapt există o mulţime, care suportă moduri diferite prin care utilizatorul să interacţioneze cu ferestrele şi stiluri diferite de aşezare şi decorare a ferestrelor, tastatura, focus-ul şi harta de culori (colormap)."

Arhitectura X furnizează căi prin care un manager de ferestre să realizeze toate aceste acţiuni cu ferestrele; dar nu furnizează un manager de ferestre în sine.

Există, bineînţeles, o mulţime de manageri de ferestre, pentru că fiind un concept extern, este uşor să scrieţi un manager de ferestre conform propriilor preferinţe, a modului în care doriţi să arate ferestrele, sau să se comporte acestea, unde să fie aşezate şi aşa mai departe. Unii dintre manageri sunt simpli şi urâţi (twm); alţii sunt strălucitori şi includ absolut totul mai puţin chiuveta din bucătorie (enlightment); alţii se se poziţionează între cele două extreme: fvwm, aniwm, icewm, windowmaker, afterstep, sawfish, kwm şi nenumăraţi alţii. Există manageri de ferestre pe gustul tuturor.

Un manager de ferestre este un "meta-client", a cărui misiune de bază este să gestioneze alţi clienţi. Cei mai mulţi manageri de ferestre furnizează câteva facilităţi adiţionale (iar unii furnizează o mulţime). Totuşi una dintre facilităţile ce par să fie furnizate de cei mai mulţi manageri de ferestre este o cale de a lansa aplicaţii. Unii dintre ei furnizează o linie de comandă unde puteţi tasta comenzi standard (care apoi pot fi folosite la lansarea aplicaţiilor client). Altele au un meniu aspectuos şi convenient ce poate lansa aplicaţii. Acest aspect nu este standardizat; din nou, cum X nu dictează politicile (regulile) prin care o aplicaţie client este lansată, această funcţionalitate trebuie implementată în programul client. În vreme ce, în mod normal, un manager de ferestre se ocupă de acest lucru (şi fiecare dintre ei o face într-un mod diferit) este posibil să existe aplicaţii client a căror misiune unică este să lanseze alte aplicaţii client; gândiţi-vă la o rampă de lansare a programelor. Şi bineînţeles că s-au scris o mulţime de aplicaţii gen "rampă de lansare" a programelor.

Să ne gândim pentru un moment la un program client. Imaginaţi-vă că doriţi să scrieţi un program pornind de la zero, folosind doar facilităţile furnizate de X. Veţi descoperi rapid că X-ul este destul de spartan şi că lucruri cum ar fi punerea de butoane pe ecran, text, sau controale conveniente şi utile (bare de poziţionare, căsuţe radio) pentru utilizatori este teribil de complicat.

Din fericire, alţii au cheltuit o grămadă de timp şi efort programând acele controale şi ni le-au dat într-o formă ce poate fi folosită, o bibliotecă. Aceste controale sunt de obicei cunoscute ca "widget-uri" şi bineînţeles biblioteca este o "bibliotecă de widget-uri". Atunci eu nu trebuie decât să chem o funcţie din această bibliotecă cu ceva parametri şi să apară un buton pe ecran. Exemple de widget-uri includ meniuri, butoane, butoane radio, bare de pozitionare (scrollbars) şi canvase.

Un "canvas" este un tip interesant de widget, pentru că este un principiu o parte din suprafaţa alocată clientului unde pot desena ceva. Bineînţeles, întrucât n-ar trebui să folosesc Xlib direct, pentru că ar interfera cu biblioteca de widget-uri, biblioteca însăşi furnizează o metodă prin care să desenez obiecte grafice oarecare în interiorul widget-ului canvas.

Întrucât biblioteca de widget-uri este cea care desenează de fapt elementele pe ecran şi interpretează acţiunile utilizatorului ca intrări, biblioteca folosită este în mare parte responsabilă pentru aspectul şi comportarea fiecărui client. Din punctul de vedere al celui care dezvoltă programe, o bibliotecă de widget-uri conţine şi un set de funcţii (API, Application Programming Interface) şi aceasta ar putea fi decisivă în decizia folosirii unei anumite biblioteci.

Biblioteca originală de widget-uri dezvoltată de proiectul Athena este bineînţeles biblioteca de widget-uri Athena, cunoscută ca widget-uri Athena. Aceasta este foarte elementară şi neatrăgătoare iar folosirea ei nu este intuitivă după standardele de azi. De exemplu, pentru a muta bara de pozitionare (scrollbar) sau controlul linear (slider control) nu trageţi pur şi simplu de acestea; în schimb, apăsaţi pe butonul din dreapta al mausului pentru a-l mişca în sus şi pe cel din stânga pentru a-l mişca în jos. Prin urmare biblioteca nu prea mai este folosită în mod curent.

În mod similar managerilor de ferestre, există o mulţime de toolkit-uri, cu diferite scopuri de design. Unul dintre cele mai vechi toolkit-uri este binecunoscutul Motif, care a fost parte a mediului grafic Motif de la Open Software Foundation. Acesta constă dintr-un manager de ferestre şi un toolkit corespunzător. Istoria OSF-ului nu face parte din obiectivul acestui document, dar toolkit-ul Motif, fiind superior widget-urilor Athena, a devenit foarte popular în anii '80 şi începutul anilor '90.

În ziua de azi, Motif nu este o alegere populară de toolkit. Acesta nu este liber (în sensul expresiei "libertatea cuvântului") şi OSF Motif costă bani dacă doriţi o licenţă pentru a dezvolta programe ce folosesc acest toolkit, deşi este OK să distribuiţi un program care include această bibliotecă. Probabil că cea mai cunoscută aplicaţie Motif, pentru utilizatorii Linux cel puţin, este Netscape Navigator/Comunicator (înainte de Mozilla).

Pentru o vreme Motif a fost singurul toolkit decent disponibil şi de aceea există o mulţime de programe ce folosesc Motif. Bineînţeles că oamenii au început să dezvolte alternative şi acum există o paletă largă de toolkit-uri, cum ar fi XForms, FLTK şi altele.

Motif nu prea mai este folosit astăzi, în special în lumea software-ului liber. Motivul este că există acum alternative mai bune, în termeni de licenţiere, performanţă (Motif este considerat de mulţi ca fiind extrem de lacom de resurse) şi facilităţi.

Unul dintre aceste toolkit-uri, extrem de popularul şi cunoscutul Gtk, a fost creat în mod special pentru a înlocui Motif pentru proiectul GIMP (unul dintre înţelesurile posibile pentru Gtk este "GIMP ToolKit"). Gtk este acum foarte popular pentru că este relativ mic (light-weight), bogat în facilităţi, extensibil şi liber în totalitate (în sensul expresiei "libertatea cuvântului"). Versiunea 0.6 a GIMP-ului a inclus propoziţia "Bloatif a fost extirpat" în jurnalul schimbărilor. Această sentinţă este o mărturie al lăcomiei/mărimii Motif-ului.

Un alt toolkit foarte popular astăzi este Qt. Acesta nu a fost cunoscut prea bine până la lansarea proiectului KDE care foloseşte Qt pentru toate elementele sale grafice. Nu vom intra în discuţia referitoare la problemele licenţierii Qt şi disputa KDE/GNOME. Gtk a fost pomenit pe larg din cauză că istoria sa ca înlocuitor al Motif-ului este interesantă; Qt este menţionat pe scurt pentru că este foarte popular.

În încheiere, o altă alternativă ce merită menţionată este Lesstif. Numele este un joc de cuvinte pe seama Motif-ului şi Lesstif intenţionează să fie un înlocuitor liber al Motif-ului, compatibil ca interfaţă de programare (API). Nu este prea clar în ce măsură Lesstif ţinteşte a fi folosit în noi programe sau a-i ajuta pe cei ce au cod Motif cu o alternativă liberă (free), în timp ce ei se presupune că modifică aplicaţiile lor pentru a folosi un alt toolkit.

Până acum avem o idee de cum X are o arhitectură client-server, unde clienţii sunt programele noastre. Sub acest sistem grafic client-server putem avea unul dintre mulţii manageri de ferestre îndeplinind funcţia de gestionare a suprafeţei disponibile de ecran; mai avem şi aplicaţiile noastr client care sunt ceea ce de fapt folosim noi pentru a ne face treaba, iar clienţii pot fi programaţi folosind unul din nenumăratele toolkit-uri.

Şi aici începe dezordinea. Fiecare manager de ferestre are o metodă diferita de a gestiona clienţii; comportamentul şi decoraţiile sunt diferite de la unul la altul. De asemenea, în funcţie de toolkit-ul folosit de fiecare dintre clienţi, aceştia pot arăta şi comporta diferit. Mai mult, cum nu există nimic care spune autorilor cum să folosească toolkit-ul pentru aplicaţiile lor, este perfect posibil ca un utilizator să ruleze, să zicem, şase aplicaţii diferite, fiecare scrisă cu un toolkit diferit şi fiecare dintre ele să arate şi să se comporte diferit. Aceasta crează probleme deoarece comportarea aplicaţiilor nu este consistentă. Dacă aţi folosit vreodată un program scris cu widget-uri Athena, aţi observat probabil că nu e prea apropiat de ceva scris folosind Gtk. Şi vă amintiţi ce neplăcut este să folosiţi toate aceste aplicaţii care arată şi comportă atât de diferit. Aceasta crează probleme deoarece comportarea aplicaţiilor nu este consistentă. Dacă aţi folosit vreodată un program scris cu widget-uri Athena, aţi observat probabil că nu e prea apropiat de ceva scris folosind Gtk. Şi vă amintiţi ce neplăcut este să folosiţi toate aceste aplicaţii care arată şi comportă atât de diferit. Aceasta practic anulează de la început avantajul folosirii unui mediu GUI.

Dintr-un punct de vedere mai tehnic, folosind o mulţime de toolkit-uri diferite creşte numărul de resurse folosite. Sistemele de operare moderne suportă conceptul de biblioteci împărtăşite (shared) dinamic. Aceasta înseamnă că dacă am două sau mai multe aplicaţii folosind Gtk şi am o versiune ce foloseşte dinamic biblioteca Gtk, atunci acele aplicaţii folosesc aceeaşi copie de Gtk, atât pe disc cât şi în memorie. Aceasta economiseşte resurse. Pe de altă parte, dacă am o aplicaţie Gtk, o aplicaţie Qt, ceva bazat pe Athena, un program ca Netscape bazat pe Motif, un program ce foloseşte FLTK şi un altul folosind XForms, va trebui să încarc în memorie şase biblioteci, una pentru fiecare dintre toolkit-uri. Reţineţi că toate toolkit-urile furnizează în esenţă aceeaşi funcţionalitate.

Mai există câteva probleme aici. Modul în care sunt lansate programele diferă de la un manager de ferestre la altul. Unele au nişte meniuri specializate pentru lansarea aplicaţiilor; altele n-au şi se aşteaptă ca noi să tastăm o comandă de lansare sau să folosim o combinaţie oarecare de taste, sau chiar să deschidem un xterm şi să lansăm aplicaţiile tastând comenzi. Din nou, cum nu există nici un standard aici, rezultatul e un haos.

În încheiere, există unele utilitare pe care le aşteptăm de la un mediu GUI pe care le-am descris până acum. Lucruri cum ar fi utilitare de configurare sau "panou de control"; sau un manager grafic pentru fişiere. Bineînţeles că aceste aplicaţii pot fi scrise ca aplicaţii client. Şi, tipic în cazul software-ului liber, există sute de manageri de fişiere şi sute de programe pentru configurarea sistemului ceea ce posibil extinde şi mai mult haosul creat de situaţia de a avea o mulţime de programe independente.

Aceasta este situaţia în care apare conceptul de mediu desktop. Ideea este că un mediu desktop furnizează un set de facilităţi şi reguli cu scopul de a standardiza tot ceea ce am menţionat anterior şi astfel să fie minimizate problemele menţionate.

Conceptul de mediu desktop este ceva nou pentru cei care vin pentru prima dată în contact cu Linux pentru că acesta este ceva pe care alte sisteme de operare (cum ar fi Windows şi MacOS) îl au integrat implicit. De exemplu, MacOS, care este una dintre primele interfeţe grafice pentru utilizator, vine cu un aspect şi comportament foarte consistent pe întreaga durată a unei sesiuni în faţa calculatorului. De exemplu, sistemul de operare pune la dispoziţia utilizatorului multe dintre utilităţile pe care le-am menţionat: un manager de fişiere implicit (finder-ul), un panou de control al întregului sistem şi un singur toolkit pe care toate aplicaţiile trebuie să îl folosească (pentru ca ele să arate similar). În final, mai există un set de indicaţii/reguli care spun dezvoltatorilor cum ar trebui să se comporte aplicaţiile lor, recomandă amplasarea şi aspectul controalelor şi sugerează comportamentul în concordanţă cu cel al celorlalte aplicaţii de pe sistem. Toate acestea sunt făcute de dragul consistenţei şi uşurinţei de folosire.

Aceasta ne face să ne punem întrebarea, "de ce nu au făcut acelaşi lucru şi dezvoltatorii de X de la început?". Pare evident şi ar fi evitat toate problemele pe care le-am menţionat anterior. Răspunsul este că în proiectarea X-ului, creatorii săi au dorit să-l facă cât mai flexibil cu putinţă. Revenind la paradigma politici/mecanism, MacOS furnizează în general politici. Mecanismele sunt acolo, dar ele nu-i încurajează pe dezvoltatori să se joace cu ele. Prin urmare pierd din versatilitate, dacă nu-mi place cum îmi gestionează ferestrele MacOS sau dacă toolkit-ul nu are funcţionalitatea de care am nevoie, sunt practic neputincios. Aceste lucruri nu se întâmplă sub X, unde aşa cum am văzut înainte, preţul pentru flexibilitate este o complexitate mai mare.

Sub Linux/Unix şi X, totul se rezumă la a cădea de acord asupra unui lucru şi a rămâne consistent. Să luăm de KDE de exemplu. KDE include un singur manager de ferestre (kwm) care gestionează şi controlează comportarea ferestrelor noastre. El recomandă folosirea unui anume toolkit grafic (QT), pentru ca toate aplicaţiile KDE să arate la fel, în ceea ce priveşte controalele ce apar pe ecran KDE extinde QT furnizând un set de biblioteci specific mediului (kdelibs) pentru realizarea unor acţiuni comune cum ar fi crearea meniurilor, căsuţe informative gen "despre", bare de unelte (toolbars) pentru programe, comunicarea între programe, tipărirea, selectarea fişierelor şi altele. Acestea fac munca programatorului mult mai uşoară şi standardizează felul în care se comportă aceste capabilităţi speciale. KDE mai furnizează un set de indicaţii/reguli pentru design şi comportament pentru programatori, în ideea că dacă fiecare le respectă, programele ce rulează sub KDE vor arăta şi comporta foarte similar. KDE mai furnizează, ca parte a mediului desktop, un panou de lansare (kpanel), un manager de fişiere (konqueror) şi un utilitar de configurare al sistemului (control panel) din care putem controla multe dintre aspectele mediului nostru desktop, de la setări cum ar fi fundalul desktopului şi culoarea barei de titlu până la configuraţia hardware.

Panoul KDE exte echivalent cu taskbar-ul din MS Windows. Acesta furnizează un punct central din care să lansaţi aplicaţii şi un loc în care aplicaţiile mici, numite "applets", să fie arătate/incorporate în interiorul său. Aceasta dă funcţionalităţi cum ar fi micul ceas fără de care cei mai mulţi dintre noi nu pot trăi.

Am folosit KDE ca exemplu dar asta nu înseamnă că acesta a fost primul mediu desktop pentru sistemele Unix. Probabil că unul dintre primele a fost CDE (Common Desktop Environment), un alt produs ala OSF. Conform documentaţiei FAQ referitoare la CDE: "Common Desktop Environment este un standard de desktop pentru Unix, ce furnizează servicii utilizatorilor de rând, administratorilor de sistem şi dezvoltatorilor de aplicaţii în mod consistent, pe multiple platforme". Elementul cheie aici este consistenţa. Totuşi, CDE nu a fost bogat în capabilităţi şi uşor de folosit aşa cum ar fi trebuit. Împreună cu Motif, CDE a dispărut practic din lumea software-ului liber, fiind înlocuit de alte alternative mai bune.

Sub Linux, cele mai populare medii desktop sunt KDE şi GNOME, dar ele nu sunt singurele. O scurtă căutare pe Internet ne arată în jur de jumătate de duzină de medii desktop: GNUStep, ROX, GTK+XFce, UDE, pentru a numi câteva. Acestea toate furnizează facilităţile de bază pe care le-am menţionat anterior. GNOME şi KDE au cel mai mult suport, atât din partea comunităţii utilizatorilor cât şi a industriei, aşa că ele sunt cele mai avansate, furnizând un număr larg de servicii utilizatorilor şi aplicaţiilor.

Am menţionat KDE şi componentele care îndeplinesc serviciile specifice sub acel mediu. Ca un bun mediu desktop, GNOME este oarecum similar în această privinţă. Cea mai evidentă diferenţă este că GNOME nu forţează folosirea unui anume manager de ferestre (cum KDE face cu kwm). Proiectul GNOME a încercat să fie întotdeauna neutru în privinţa managerilor de ferestre, recunoscând că cei mai mulţi utilizatori devin foarte ataşaţi de managerii lor preferaţi şi prin urmare forţându-i să folosească altceva care ar gestiona ferestrele diferit i-ar putea pierde de utilizatori. Iniţial GNOME a favorizat managerul de ferestre Enlightenment, iar acum managerul preferat este sawfish, dar panoul de control GNOME a avut întotdeauna un selector pentru managerul de ferestre.

În afară de acesta, GNOME foloseşte toolkit-ul Gtk şi furnizează un set de funcţii şi facilităţi de nivel mai înalt prin setul de biblioteci gnome-libs. GNOME are propriul său set de indicaţii de programare pentru a garanta un comportament similar între aplicaţiile care le respectă; acesta furnizează un panou (panel), un manager de fişiere (gmc, deşi acesta va fi probabil înlocuit cu Nautilus) şi un panou de control (centrul de control gnome).

Fiecare utilizator este liber să folosească mediul desktop în care se simte cel mai confortabil. Rezultatul final este că dacă folosiţi un sisten numai-kde sau numai-gnome, aspectul şi comportarea mediului sunt foarte consistente; iar toate aplicaţiile d-voastră interacţionează între ele foarte convenabil. Acest lucru nu era nicidecum posibil când aveam aplicaţii scrise în multitudinea de toolkit-uri diferite. Gama de facilităţi oferite de un mediu desktop modern sub Linux mai permite câteva lucruri utile cum ar fi arhitectura componentelor (KDE are Kparts iar GNOME foloseşte careul de lucru pentru componente Bonobo), care permite lucruri cum ar fi o tabelă de calcul (spreadsheet) sau grafic modificabil în interiorul unui procesor de texte; facilităţi de tipărire globale, similare cu contextele de tipărire în Windows; sau limbaje de scriptare, care permit utilizatorilor mai avansaţi să scrie programe ce combină împreună aplicaţii şi le fac să interacţioneze şi coopereze într-un mod interesant.

Sub Unix, conceptul de "mediu desktop" permite să aveţi programe dintr-un anumit mediu rulate sub altul. Aş putea de exemplu folosi konqueror (aplicaţie KDE) sub GNOME sau gnumeric (aplicaţie GNOME) sub KDE. La urma urmei acestea sunt doar nişte simple programe. Bineînţeles că întreaga idee a unui mediu desktop este consistenţa, aşa că este normal să folosiţi aplicaţiile care au fost proiectate pentru mediul d-voastră în particular. Dar dacă sunteţi dispus să aveţi de-a face cu aplicaţii care nu par "la locul lor" şi nu interacţionează cu restul mediului d-voastră, sunteţi complet liber să o faceti.

Acesta este un exemplu de cum decurge o sesiune normală GNOME sub un mediu desktop modern pe un sistem Linux. Este foarte similar cu modul în care decurg lucrurile sub alte medii, desktop, presupunând că ele lucrează deasupra X-ului.

Când un sistem Linux porneşte X, serverul X porneşte şi iniţializează dispozitivul grafic, aşteptând cereri de la clienţi. Mai întâi porneşte un program numit gnome-session, care setează sesiunea de lucru. O sesiune include lucruri cum ar fi aplicaţii pe care le deschid întotdeauna şi le poziţionez pe ecran în acelaşi loc şi aşa mai departe. Următorul care porneşte este panel-ul. Panel-ul apare la baza ecranului (de obicei) şi este un fel de pupitru pentru mediul de ferestre. Acesta lansează programe, vede care sunt programele care rulează şi controlează cum funcţionează mediul de lucru. Urmează managerul de ferestre. Întrucât folosim GNOME acesta ar putea fi oricare dintre nenumăraţii manageri disponibili, dar în cazul de faţă vom presupune că folosim Sawfish. În final porneşte managerul de fişiere (gmc sau Nautilus)/ Managerul de fişiere controlează prezentarea icon-urilor de pe desktop (cele care apar direct pe desktop). În acest moment sistemul meu GNOME este gata de lucru.

Până în acest punct toate programele care au fost pornite sunt clienţi, conectaţi la serverul X. În cazul de faţă serverul X se află pe acelaşi computer, dar, precum am văzut anterior, acest lucru nu este (absolut) necesar.

O să deschidem acum un xterm şi o să testăm câteva comenzi. Când facem clic pe icon-ul xterm, panel-ul lansează aplicaţia xterm. Acesta este o altă aplicaţie client pentru X, aşa că atunci când porneşte se conectează la serverul X şi începe să afişeze mesajele sale. Când serverul X îi atribuie spaţiu de ecran xterm-ului meu, acesta îl lasă pe managerul de ferestre (Sawfish) să decoreze fereastra cu o bară de titlu şi să decidă unde să apară pe ecran.

Să navigăm puţin Internetul. Facem clic pe icon-ul Netscape de pe panel (pupitru) şi pe ecran apare un navigator (browser). Reţineţi că acest browser nu foloseşte facilităţile GNOME şi nici nu foloseşte toolkit-ul Gtk. Arată prin urmare puţin nelalocul lui; de asemenea nu interacţionează prea bine cu restul mediului. O să deschid meniul File. Motif furnizează controale pe ecran, aşa că este treaba bibliotecii Motif să cheme funcţiile care trebuie din Xlib, să deseneze pe ecran elementele necesare pentru a afişa meniul şi să pot selecta opţiunea "Exit", închizând aplicaţia.

Acum deschid o tabelă de calcul cu Gnumeric şi încep să lucrez ceva. La un moment dat trebuie să lucrez pe xterm-ul deschis anterior aşa că fac clic pe el. Sawfish vede acest lucru şi, fiind responsabil de gestionarea ferestrelor, aduce xterm-ul în prim-plan şi îi acordă focus-ul pentru a putea lucra acolo.

După aceasta mă întorc la Gnumeric, acum că am terminat şi vreau să-mi tipăresc documentul. Gnumeric este o aplicaţie GNOME, aşa că poate folosi facilităţile furnizate de mediul GNOME. Când tipăresc, Gnumeric cheamă biblioteca gnome-print, care comunică de fapt cu imprimanta şi produce copiile de care am nevoie.

Versiunea în limba engleză este Copyright (c) 2001 de Daniel Manrique

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found here.

Versiunea în limba română este Copyright (c) 2003 de Laurenţiu Buzdugan

Vă este acordată permisiunea de a copia, distribui şi/sau modifica acest document conform termenilor licenţei GNU Free Documentation License, Versiunea 1.2 sau orice versiune ulterioară publicată de către Free Software Foundation fără nici o secţiune invariantă, fără texte de copertă-faţă şi fără texte de copertă-spate. O copie a licenţei poate fi găsită aici.