DISCLAIMER: questo non è uno di quei post da guerra dei Sistemi Operativi. Messaggi come “ma però il mek è caro” o “sì ma il pinguino è difficile” o “ma uindous c’hai i viruss” non saranno tollerati. L’idea è che qualunque scelta venga fatta, se consapevole, è giusta: quindi ad ognuno il suo OS.Se vi ricordate moooolto tempo fa avevo proposto un articolo intitolato In che direzione sta andando la GUI, in cui mettevo a confronto l’evoluzione delle GUI nei vari OS: oggi vorrei fare qualcosa di uguale ma diverso, semplicemente prendendo lo stato dell’arte attuale e confrontando 3 o 4 soluzioni base, cercando di trovare i pro e i contro.

Mac OS X Leopard: dock + menubar
Non è un caso se la GUI di OS X è spesso presa ad esempio da altri OS o da chi si occupa di realizzare temi per i vari Desktop Environment. Al di là del fatto che possa essere considerata “bella” o “brutta”, l’interfaccia di OS X presenta alcuni importanti punti di forza (ma anche qualche debolezza)
Configurazione
l’interfaccia è così strutturata:

Dock: questo elemento raccoglie in se varie funzioni:

  • Lanciatore
  • Notifica (vedi indicatori sotto le applicazioni attive e icone che rimbalzano)
  • Gestione delle finestre (quelle ridotte a icona, con anteprima)
  • Alcune basilari funzioni del file mangager (vedi Stacks)

Barra dei menu: qui si trovano

  • Un menu di sistema
  • Tutti i menu dell’applicazione in primo piano
  • L’area di notifica delle applicazioni e degli indicatori che risiedono nella menubar

Questa configurazione praticamente unica nel panorama dei sistemi operativi moderni, porta con sé i seguenti vantaggi:
Dock: È facilmente configurabile tramite drag & drop, consente di inserire moltissimi lanciatori e di gestire e monitorare vari aspetti dell’interfaccia grafica (applicazioni aperte, finestre ridotte ad icona, “badge” in sovraimpressione sulle icone).
Barra dei menù: ha il vantaggio fondamentale di non seguire la finestra: è sempre lì, nel bordo alto del monitor, pronta ad essere raggiunta lanciando il mouse con nemmeno troppa precisione. Consente di distinguere il concetto di “chiusura dell’applicazione” da quello di “chiusura della finestra”, concetto quasi mai presente in altri OS. Sganciando la barra dei menu dalla finestra, rende l’interfaccia grafica molto più semplice e razionale: se ho due finestre aperte della stessa applicazione, che senso ha duplicarne i menu?
L’integrazione di Dock e Barra dei menu consente di realizzare una configurazione salvaspazio, molto razionale ed ergonomica… ma fino ad un certo punto! Infatti ecco le dolenti note, ovvero gli svantaggi:
Dock: il dock è molto semplice, ma poco flessibile. Non è possibile, se non attraverso applicazioni di terze parti, avere più di un dock o, ancora meglio, avere un dock per Space (desktop virtuale).
Questo è abbastanza limitativo, poiché l’altro difetto del dock è quello di non potersi espandere all’infinito: più icone di applicazioni inserisco, più lui si espande, fino al limite fisico del bordo del monitor. A questo punto comincerà a diminuire le dimensioni delle icone, e così via ogni volta che si riduce ad icona una finestra, fino a rendere minuscole ed inutilizzabili le icone. Questo è in parte mitigato dall’ottimo lavoro di lanciatore svolto da Spotlight, ed in parte da applicazioni di terze parti come Dock Spaces (gratuito, UB), che consente di avere fino a 10 dock dock diversi e di assegnarli ai vari Space, con una limitazione di massimo 4 Spaces.
L’altro enorme difetto è che il dock non gestisce il raggruppamento delle finestre ridotte ad icona, ovvero se riduco 10 finestre della stessa applicazione, mi ritrovo 10 icone con anteprima nel dock. Ha senso? Secondo me no! Il bello è che la soluzione al problema è suggerita da una funzione già presente in Dock: gli Stacks! Basterebbe applicare questo concetto alle applicazioni ridotte ad icona e tutto sarebbe molto coerente.
Barra dei menu: un difetto che salta subito agli occhi dei possessori di iBook e simili è che i menù delle applicazioni tendono spesso a sconfinare nella zona di notifica, senza che però vi sia un pulsante o qualcosa di simile per espandere questa zona e raggiungere una menulet coperta dai menù. Con l’avvento dei monitor 16:10 dotati di risoluzioni sempre maggiori, questo problema si è affievolito ma non è comunque stato risolto. Anche in questo caso c’è un’applicazione di terze parti (Minu, gratis, per PPC e Intel) che viene in aiuto, ma sarebbe bello avere una soluzione già integrata.
L’altro grave, anzi gravissimo!, difetto della barra dei menu è che questa non viene duplicata sui monitor esterni nel caso di estensione della scrivania. Se questo può essere tollerato per il dock, non può esserlo per la menubar: così facendo ci si ritrova con finestre posizionate in un monitor che sono fisicamente lontane dal monitor in cui sono presenti i menu dell’applicazione stessa. Ciò significa vasche col mouse e scomodità immensa. Soluzione di terze parti: utilizzare DejaMenu (gratuito, UB), ma non è la stessa cosa e presuppone il passaggio da una scorciatoia da tastiera. Apple, datti una mossa!

KDE 4.2: pannello + menu nella finestra
Questa è la configurazione “classica”, quella a cui da tempo ci ha abituato ad esempio Windows, che per molti è la configurazione “scontata” e “naturale”, pur presentando alcuni importanti limiti sull’ergonomia.
Configurazione

La disposizione è molto semplice, con un pannello sul fondo che racchiude menu di sistema, qualche lanciatore, lo spazio per la riduzione ad icona delle finestre e la zona di notifica delle applets. I menù dell’applicazione sono integrati direttamente nella finestra. Questo genere di configurazione, secondo me, aveva senso quando il multitastking era sconosciuto e le applicazioni erano costituite da una finestra a tutto schermo. Nonostante ciò, ance oggi presenta alcuni vantaggi:
Menu nella finestra: ovunque vada la finestra, i menu la seguono. Questo significa che nel caso di utilizzo della scrivania estesa su più monitor, anche se la finestra è presente in un monitor distante dal principale, posso comunque facilmente raggiungere i menù senza farmi delle vascate col mouse.
Pannello: occupa meno spazio di un dock, gestisce il raggruppamento delle finestre ridotte ad icona. Si può avere anche un’anteprima della finestra ridotta ad icona, ad esempio installando Compiz ed abilitando l’apposito plugin. Un vantaggio per le persone più pigre è che questa è l’impostazione a cui sono già abituate in windows e quindi è più o meno uguale in tutti i computer dell’ufficio ed in quelli del 95% dei propri colleghi.
Rovescio della medaglia, gli svantaggi:
Menu nella finestra: se chiudo la finestra, addio menu. Questo significa che non c’è più separazione tra chiusura di tutte le finestre e chiusura dell’applicazione, non avendo senso lasciare aperta un’applicazione senza i menu corrispondenti. Questo è il motivo per cui la riduzione ad icona delle finestre ha tanta importanza in questo tipo di interfacce, mentre io non su OS X non la uso praticamente mai. C’è il trucco della riduzione nell’area di notifica, ma è un’operazione molto simile alla riduzione ad icona.
Inoltre l’integrazione tra menu e finestra fallisce in quei casi in cui vi sono finestre di supporto all’applicazione stessa, non dotate di menu. Caso tipico: browser web e finestra dei download. Se chiudo la finestra principale e non quella dei download, rimango con un’applicazione attiva, senza menu e con una finestra aperta. Se ne esce solo con scorciatoie da tastiera, click destri e così via.
Vie è poi la questione della duplicazione inutile e senza senso dei menu. Se ho due finestre della stessa applicazione, che senso ha mostrare due menu identici nelle due finestre?
Infine, i menù non sono sempre nello stesso punto : sposto la finestra, si sposta il menù, quando mi serve devo ricordarmi dov’è ed andare a prenderlo, con un certo grado di precisione. Sembra una stronzata, ma per qualcuno non lo è.
Pannello: lo svantaggio principale è dato dal numero di lanciatori inseribili. Se ne possono mettere pure tantissimi, ma in questo caso bisognerà passare attraverso un pulsante di “espansione” e addio immediatezza. Inoltre non vi è alcuna integrazione tra lanciatore e notifica dell’applicazione corrispondente, che si riflette in un ulteriore utilizzo di spazio da qualche parte, tipicamente nell’area di notifica.

Gnome 2.6: pannello sotto + menù nella finestra + pannello sopra
Questa io proprio non la capisco.
Configurazione

C’è un pannello sotto in cui si trovano: un pulsante per mostrare il desktop, la zona di riduzione delle icone, il selettore degli spazi virtuali, il cestino. La finestra presenta i menù integrati. Sopra, c’è un altro pannello, contenente: i menù di sistema, qualche lanciatore, l’area di notifica. La domanda è: perché? È ovvio che questa soluzione presenta gli stessi pregi e difetti di quella descritta sopra, con in più l’aggravante di un inutile spreco di spazio.

Mettiamoci una pezza: gnome2-globalmenu + docky
Grazie a VirtualBox e alla mia curiosità mai soddisfatta, sto seguendo alcuni progetti che cercano di portare una configurazione “OS X style” su Gnome: impresa non facile e ricca di imprevisti.
Questo è il risultato ottenuto sulla mia installazione di Linux Mint:

Per la barra dei menù ho utilizzato Globalmenu, mentre per il dock ho usato Docky.
Globalmenu: progetto che affonda le sue radici nella notte dei tempi, stoppato e ripreso più volte, riscritto da zero, ora sembra aver acquistato un po’ più di solidità. Nasce per dare a Gnome qualcosa di analogo alla barra dei menù di OS X e di KDE3.x (per ora assente nella KDE4.2). Purtroppo ha alcuni pesanti limiti dovuti al fatto che non è un componente sviluppato “globalmente” in Gnome, ma un add-on, e come tale si deve adattare ad una “filosofia” già prescritta. Innanzitutto funziona solo con applicazioni GTK+, niente Qt (imparentate con KDE), niente “ibridi” come OpenOffice e Firefox, due dei prodotti opensource più famosi al mondo (penso). Secondariamente ha una funzione puramente estetica, non completamente funzionale, ovvero non realizza quella separazione tra “chiusura dell’applicazione” e “chiusura della finestra” che invece è presente in OS X. Cosa significa tutto ciò? Che finché questo progetto non diventerà qualcosa di veramente “globale”, ovvero gestito ad un livello più alto ed in grado di integrarsi alla perfezione (o quasi) nel mondo eterogeneo delle distribuzioni Linux e dei suoi DE, avrà più svantaggi che vantaggi.
Docky: questo è un progetto che mi ha sorpreso, perché veramente innovativo e fuori dal comune. Docky non è altro che un interfaccia per GNOME-Do, che altro non è che l’omonimo di Quicksilver di Mac-os-x-iana memoria per Linux. Docky svolge esattamente le stesse funzioni di GNOME-Do, ma integrando anche la funzione di dock. Ha contemporaneamente qualcosa in meno e qualcosa in più del dock di OS X.
Qualcosa in meno perché non presenta un’area dedicata alla riduzione ad icona della finestra che, quindi, sparisce nel nulla; inoltre non ho trovato niente di analogo agli stacks di OS X.
Qualcosa in più perché è estendibile tramite i plugin di GNOME-Do, che una volta attivati sono raggiungibili dal menu contestuale che si ottiene col click destro su un’icona. Inoltre poiché svolge la funzione di ricerca tipica di GNOME-Do, è possibile aggiungere un lanciatore semplicemente cercando l’applicazione corrispondente e clickando sull’apposito pulsante “+”.
Per il resto, gestione molto simile a quella del dock di OS X con drag & drop e tutto il resto.
Docky è sicuramente il “simil-dock” che più si avvicina all’idea di dock in OS X, è pronto e funzionale, e le funzioni mancanti possono essere aggiunte tramite il sistema dei plug-in, cosa molto interessante e che sarebbe bello poter sfruttare anche su OS X. Il bello è che, a dispetto del nome, GNOME-Do è compatibile con i più diffusi DE del mondo Linux, da XFCE a KDE, senza particolari problemi.

’nuff said