giovedì 20 marzo 2008

Vi mode per la shell bash

Essendo un utente molto assiduo di vim, mi è capitato più volte di utilizzare i suoi comandi in contesti nei quali quei comandi non sono validi, come la finestra di composizione di claws-mail, la finestra del browser, OpenOffice ecc...

Quando mi sono trovato a creare sequenze di comandi molto complesse con la bash, spesso ho sentito l'esigenza di potere utilizzare i comandi a me familiari per potermi muovere all'interno della riga creata.

Giusto oggi ho scoperto che è possibile, sfruttando la modalità vi per bash. È una caratteristica integrata nella shell, e si attiva semplicemente digitando '''set -o vi'''.

Con riferimento alle modalità di ViM, durante l'utilizzo normale della shell saremo proiettati in modalità inserimento, e la pressione del tasto ESC ci consentirà di passare alla modalità normale.

Ovviamente avremo a disposizione solo un sottoinsieme dei comandi di vi, ma che comunque è più che sufficiente per i piccoli task di spostamento all'interno della riga che possono essere utili per velocizzare l'editing del comando.

Se trovate interessante questa caratteristica, date un'occhiata al post che mi ha ispirato quest'articolo.

:wq

domenica 16 marzo 2008

Editing (comodo) di più file in ViM

Finalmente è arrivata la mia copia di Hacking ViM!

La sola visione della copertina mi ha ispirato questo post, in cui voglio descrivere come utilizzo le funzionalità di ViM 7 per gestire l'editing contemporaneo di più file, ovvero split windows e tab.

Come prima cosa, sarà introdotta la funzionalità di mapping di ViM.

Successivamente sarà descritta prima la modalità tradizionale di utilizzo di queste caratteristiche, e successivamente alcune agevolazioni e binding che sfrutto per accelerare di molto il processo di editing.

Mapping


Il mapping permette di definire (o ridefinire) il significato di una sequenza di tasti in ViM. Considerando che ViM è un editor modale, i mapping possono funzionare solo in determinate modalità. Il comando :map sequenza comandi funziona per le modalità normale e visuale (oltre che per la modalità waiting for operator, che non ci interessa), mentre il comando :imap sequenza comandi funziona per la modalità inserimento.

Split windows


La prima, utile caratteristica di ViM che viene in aiuto sono le split windows, ovvero la possibilità di dividere la finestra corrente in più finestre.

La divisione può essere orizzontale o verticale. Il comando per suddividere orizzontalmente la finestra è :sp nomefile, da eseguire in modalità command. Per la suddivisione verticale, si può utilizzare :vsp nomefile. Per chiudere la finestra, basta il semplice :wq, mentre per passare da una finestra all'altra è necessaria la combinazione di tasti <CTRL-w><CTRL-w>.

Quest'ultimo comando permette di spostarsi ciclicamente tra le finestre. Per massimizzare l'ampiezza della finestra corrente, si utilizza <CTRL-w>_.

Iniziando a provarle, vi accorgerete di quanto sia potente questa funzionalità!

Un paio di osservazioni:

  1. È alquanto scomodo premere in continuazione <CTRL-w><CTRL-w> per passare tra le finestre

  2. La finestra non si massimizza totalmente, ma mostra comunque una riga per ciascun file aperto in contemporanea



Per superare l'ultima limitazione, basta utilizzare il comando :set wmh=0, che imposta l'altezza minima di una finestra a 0, lasciando visibile solo una riga con il nome del file invece di due righe,

Per accelerare i tempi di transizione tra le finestre, è sufficiente creare un mapping personalizzato. Con le due istruzioni :map <C-J> <C-W>j<C-W>_ e :map <C-K> <C-W>k<C-W>_ associeremo alla combinazione di tasti <CTRL-J> il movimento allo split inferiore (con conseguente massimizzazione dello stesso), ed alla combinazione <CTRL-K> il movimento allo split superiore (con massimizzazione).

I tab


I tab sono stati introdotti in ViM 7, e sono una funzionalità che ritroviamo in molte applicazioni (principalmente web browser, ma anche altri editor o IDE).

Ecco i comandi di ViM per utilizzare i tab:

  • :tabe nomefile Apre un nuovo tab.

  • :tabn Vai al tab successivo.

  • :tabp Vai al tab precedente.



Vi renderete conto che è alquanto scomodo passare da un tab all'altro. Per questo ho creato questi due mapping:

  • :map <C-L> :tabn<CR>

  • :map <C-H> :tabp<CR>



Questi mapping associano ai tasti indicati i movimenti verso il tab precedente e successivo. Ora mancano solo due passaggi per terminare la personalizzazione.

La modalità inserimento


I mapping che abiamo indicato funzionano in modalità normale ed in modalità visuale. Sarebbe utile che funzionassero anche in modalità inserimento, possibilmente senza dover uscire dalla stessa.

Per fare ciò, sfruttiamo il comando imap:


  • :imap <C-J> <Esc><C-J>a

  • :imap <C-K> <Esc><C-K>a

  • :imap <C-L> <Esc><C-L>a

  • :imap <C-H> <Esc><C-H>a



I comandi di mapping sono ricorsivi, ovvero si può inserire un mapping dentro un altro mapping.

Nei mapping della lista descritta sopra, la prima cosa che viene eseguita è la simulazione della pressione del tasto Escape, e ciò ci porta in modalità normale. Successivamente viene simulata la pressione di una combinazione di tasti, che richiama una delle combinazioni che sono state descritte precedentemente. Infine, viene simulata la pressione del tasto a, che ci riporta in modalità inserimento.

Mettiamo tutto nel file .vimrc


Ovviamente è desiderabile non dover digitare ogni volta tutti questi comandi, quindi inseriamo tutto nel nostro .vimrc, in modo che ogni volta che ViM venga avviato possiamo usufruire di questi mapping.

Ecco la sequenza completa da inserire:

map <C-J> <C-W>j<C-W>_
map <C-K> <C-W>k<C-W>_
map <C-L> :tabn<CR>
map <C-H> :tabp<CR>
imap <C-J> <Esc><C-J>a
imap <C-K> <Esc><C-K>a
imap <C-L> <Esc><C-L>a
imap <C-H> <Esc><C-H>a
set wmh=0


Da notare l'assenza dei due punti all'inizio dei comandi.

Conclusioni


Da quando utilizzo questi mapping, sono molto più veloce nell'utilizzo di vim, e ciò mi permette di concentrarmi su ciò che sto facendo piuttosto che sull'utilizzo dell'editor stesso.

Ciò dimostra come, sebbene la curva di apprendimento sia ripida, imparare ad utilizzare ViM può incrementare notevolmente la produttività.

Ed ora.. godetevi questi mapping!

martedì 15 gennaio 2008

Linux Day: no alla strumentalizzazione!

Come membro del GNU/Linux Users Group di Catania, sento sia giusto dare risalto alla lettera che è stata oggi inviata a buona parte dei LUG italiani ed al coordinamento nazionale di ILS da parte di molti dei LUG siciliani.

La lettera esprime la voglia che noi abbiamo di discutere della trasformazione che, in alcuni contesti, il Linux Day ha subito, da giornata di promozione del software libero e di Linux a vetrina commerciale.

Non mi dilungo oltre, preferisco che a parlare sia la lettera, che propongo con particolare trasporto perché sono stato reclutato dal GLUG/CT proprio durante un Linux Day, e credo fortemente nel suo significato divulgativo.


Sono ormai sette anni che in Italia si organizza il Linux Day, la "giornata nazionale di Linux e del Software Libero". In questi anni, la manifestazione si è allargata in modo impressionante: da circa 40 eventi si è arrivati a superare ampiamente il centinaio. La manifestazione è cresciuta ed è cambiata, ILS ha proposto delle linee guida per i partecipanti, al fine di dare una connotazione unitaria ed omogenea ad una manifestazione che è il momento di massima visibilità per la comunità italiana del Software Libero.

In tutti questi anni noi abbiamo partecipato a questa manifestazione con il massimo entusiasmo: sentivamo il bisogno di un momento comunitario per comunicare all'esterno che l'utopia del Software Libero stava finalmente diventando realtà quotidiana, che GNU/Linux era l'alternativa possibile, e che il LD era l'occasione che stavamo aspettando.

A nostro modo di vedere, il Linux Day è una festa dedicata alla promozione del Software Libero e di GNU/Linux, prima di tutto come scelta etica e sociale e poi come risultato di un processo di
sviluppo "a sorgente aperto" che si traduce automaticamente in software valido, robusto ed efficiente dal punto di vista tecnologico; il Linux Day è il giorno in cui proporre alle persone
una scelta di libertà.

Guardando però i programmi delle decine di LD che sono stati organizzati in Italia negli ultimi anni, spesso ci sembra che lo spirito e gli scopi di queste manifestazioni non siano in linea con
questo nostro punto di vista. Secondo noi alcune manifestazioni locali degli ultimi quattro o cinque anni hanno, poco o nulla a che vedere con quello che dovrebbe essere l'obiettivo principale del LinuxDay, e cioé - secondo le linee guida - "promuovere l'uso e
la conoscenza del sistema operativo GNU/Linux e del software libero".

Alcuni Linux Day ci sembrano veri e propri "congressi" il cui intento principale è spesso quello di promuovere un prodotto o un'azienda. Che questa azienda abbia qualche connessione (più o meno
lasca) con GNU/Linux e col software libero ci sembra secondario. Gli intenti di un'azienda hanno giocoforza poco o nulla a che vedere con la diffusione di ideali di libertà e con la condivisione del sapere, essendo più incentrati sulla promozione di determinati prodotti o sulla pubblicizzazione di determinate realtà commerciali.

Riteniamo che le ragioni dello scollamento che avvertiamo tra chi, all'interno della comunità, crede come noi nel Linux Day come giornata per "promuovere l'uso e la conoscenza del sistema operativo GNU/Linux e del software libero", e chi invece lo interpreta come vetrina pubblicitaria per operatori del settore che hanno scelto di passare a GNU/Linux per motivazioni spesso molto diverse da quelle etiche e sociali, siano da ricercare prima di tutto nelle intenzioni
e nelle motivazioni dei LUG.

Probabilmente alcuni LUG italiani ritengono che promuovere GNU/Linux in qualsiasi forma e con qualsiasi mezzo, prescindendo anche dalle motivazioni etiche che spingono altri LUG e altre associazioni, sia in ogni caso giusto e necessario al fine di allargare il bacino degli utenti Linux. Questa posizione è, per quanto ci riguarda, rispettabile, ma crediamo fermamente che tale tipo di promozione prettamente commerciale o utilitaristica di GNU/Linux sia assolutamente in contrasto con le motivazioni che quotidianamente ci spingono ad impegnarci nella diffusione della Cultura del Software Libero e dell'uso dei sistemi operativi liberi, GNU/Linux in testa. E che sia in contrasto anche con le stesse motivazioni che ci spingono ad investire tempo e fatica nell'organizzazione del Linux Day.

Pensiamo che la promozione commerciale e per le aziende possa essere fatta 364 giorni all'anno, e soprattutto che il LinuxDay non sia il luogo in cui farla. In quest'ottica, le attuali Linee Guida proposte da ILS lasciano forse eccessivo spazio anche a manifestazioni che in realtà non hanno come scopo principale quello di divulgare cultura e di spronare alla consapevolezza, inserendo pertanto nel "Programma del Linux Day" anche eventi locali in sostanziale antitesi con le intenzioni iniziali dei promotori della manifestazione (vedi l'annoso problema, finora non risolto e forse nemmeno affrontato, delle sponsorizzazioni e delle autopromozioni
commerciali....).

Vorremmo pertanto aprire un dibattito all'interno della comunità per capire, finalmente in modo chiaro, quanti sono quelli che credono, come noi, che il Linux Day debba essere una manifestazione libera e commercialmente disinteressata, volta principalmente alla diffusione
di Cultura e alla presentazione di un modello di condivisione di Conoscenze.

Crediamo che porre questa domanda sia importante per la comunità e per le nostre associazioni, dal momento che non ci troviamo più a nostro agio ad aderire ad una manifestazione le cui espressioni locali sono spesso, in sostanza, molto diverse dalla "facciata" che presentano e dai principi ispiratori delle linee guida che, sempre formalmente, rispettano.

Vorremmo che questo chiarimento avvenisse in maniera pacata e serena, e che fosse un vero e sostanziale momento di confronto all'interno della comunità, che ci permetta di capire se la pensiamo allo stesso modo sulle questioni fondamentali, se gli obiettivi che ci poniamo sono simili e se abbiamo la forza di agire e di "camminare" insieme per raggiungerli, rendendo tra l'altro più esplicite le linee guida del Linux Day nell'indirizzare la natura
dell'evento.

Pensiamo che uno dei luoghi piu' adatti per affrontare questo dibattito possa essere la lista lug@lists.linux.it, utilizzata negli ultimi anni come spazio per il coordinamento delle attività dei LUG italiani.

--
Clug - Caltanissetta Linux user group
Freaknet MediaLab - HackLab (Catania)
GLUGCT - GNU Linux user group Catania
LUGSR - Siracusa Linux user group
MeLUG - Messina Linux user group
PALUG - Palermo Linux user group
Poetry - HackLab (Palazzolo Acreide)
Solira - Associazione Software Libero di Ragusa


Per chiudere, sottolineo come l'aspetto commerciale del software libero sia cosa buona e giusta, almeno a mio avviso.

Ma non è durante il Linux Day che vanno portate avanti iniziative promozionali o commerciali, sebbene relative al software libero.

Attendiamo gli sviluppi della discussione.

giovedì 3 gennaio 2008

Implementazione di una macchina a stati sequenziale in JavaScript

Come macchina a stati sequenziale potremmo definire una normale macchina a stati (che supporremo finiti) in cui le uniche transizioni permesse siano quelle tra stati adiacenti. Ad esempio, dallo stato 3 è possibile passare solo allo stato 2 od allo stato 4.

Nelle interfacce uomo-macchina è possibile associare questo tipo di macchine a stati al concetto di wizard, ovvero un tipo di interfaccia che guidi l'utente passo per passo nello svolgimento di un compito.

I wizard sono strumenti abbastanza potenti, perché facilitano di molto l'interazione con gli utenti, e quindi se ne fa largo uso anche durante la realizzazione di interfacce web.

Durante la mia prima avventura con JavaScript, mi sono trovato a realizzare qualcosa che si avvicina di molto ad un wizard, ovvero un'interazione sequenziale con l'utente che abbia anche la caratteristica della reversibilità, ovvero fornisca all'utente la possibilità di tornare sui propri passi.

Per fare ciò, ho sfruttato l'estrema dinamicità del linguaggio JavaScript, ed ho semplicemente creato una lista di oggetti simile alla seguente:


MYAPP.phases = [
{
'title' : 'breve descrizione fase 1',
'desc' : 'lunga descrizione fase 1',
'handler' : function() {
// Lista di istruzioni da eseguire
// non appena si passa alla fase 1
},
'event1_handler' : function() {
// Lista di istruzioni da eseguire
// se si verifica l'evento 1 nella
// fase 1
}
},
{
'title' : 'breve descrizione fase 2',
'desc' : 'lunga descrizione fase 2',
'handler' : function() {
// Lista di istruzioni da eseguire
// non appena si passa alla fase 2
},
'event1_handler' : function() {
// Lista di istruzioni da eseguire
// se si verifica l'evento 1 nella
// fase 2
}
},
[altri N - 2 elementi di questo tipo...]
};


Ciascuno di questi oggetti implementa un'interfaccia comune, che mi permetterà di scrivere codice indipendente dallo stato in cui mi trovo, secondo la ben nota tecnica del pattern State.

La velocità del linguaggio JavaScript permette di implementare questo pattern senza la necessità di creare una gerarchia di classi, in maniera molto veloce ed intuitiva. Creo direttamente gli oggetti, non ho bisogno di creare una classe!
Il codice risulta compatto e di facile comprensione per chi abbia un minimo di confidenza con il linguaggio.

Per terminare l'implementazione, è necessario mantenere traccia dello stato corrente, creare una funzione di variazione di stato e creare due funzioni che si occupino di incrementare o decrementare lo stato attuale:

MYAPP.current_phase = 0;

MYAPP.setPhase = function(num) {
var cur = MYAPP.phases[num];
$("#phase-title").empty();
$("#phase-title").append("Fase " + (num + 1) + ": " + cur.title).wrap("");

$("#phase-desc").empty();
$("#phase-desc").append(cur.desc);

cur.handler();
MYAPP.current_phase = num;
}

MYAPP.next_phase = function() {
if(MYAPP.current_phase < MYAPP.phases.length - 1)
MYAPP.setPhase(++MYAPP.current_phase);
}

MYAPP.prev_phase = function() {
if(MYAPP.current_phase > 0)
MYAPP.setPhase(--MYAPP.current_phase);
}

Nella funzione di variazione di stato ho lasciato parte del codice che ho utilizzato nella mia applicazione, che utilizza l'ottimo framework jQuery.

Quel codice cambia il contenuto dei div #phase-title e #phase-desc a seconda dello stato attuale, richiama l'handler dello stato attuale e modifica il valore della variabile che mantiene traccia dello stato.

Per far sì che il comportamento dell'applicazione dipenda dallo stato è necessario utilizzare la tecnica del doppio inoltro, ad esempio in questo modo:

<a onclick = 'MYAPP.phases[MYAPP.current_phase].event1_handler();'>Testo</a>

Così l'azione che si verifica al click dipenderà dallo stato corrente, e non sarà necessario scrivere codice pieno di istruzioni switch che vanno modificate di volta in volta.

Considerando che all'utente è consentito scorrazzare abbastanza liberamente tra gli stati, sarà necessario implementare meccanismi robusti di gestione dell'errore ed adeguate politiche di reversibilità. Ricordate che si dovrebbe consentire all'utente di effettuare solo azioni lecite, in modo da incoraggiarlo ad utilizzare la vostra applicazione.

In conclusione, la dinamicità di JavaScript consente di implementare in maniera agile buona parte delle tecniche tradizionali di programmazione e di interazione, basta conoscere un po' il linguaggio ed utilizzare bene il paradigma che offre.

domenica 30 dicembre 2007

L'informatica è una guerra...


.. e questo lo sa chiunque, per motivi vari ed eventuali, si trovi a combattere con una certa frequenza in campo informatico.

In trincea, però, a volte noi soldati abbiamo la fortuna di sentire voci illuminate che indicano chiaramente quale sia la direzione da seguire, quale sia la prossima mossa da effettuare, come limitare i danni: è anche grazie a queste voci che, ogni giorno, si riesce a sopravvivere e ad andare avanti.

La lingua dell'informatica è notoriamente l'inglese, ma da un paio di settimane è possibile udire - chiara e forte - una di queste voci che impiega la lingua del nostro Bel Paese.

Stacktrace.it si auto-definisce "aperiodico di resistenza informatica", ed è un sito che ha come mission la creazione di contenuti originali di elevatissima qualità nell'ambito dell'informatica.

In questi pochi giorni di attività è già emersa la qualità del lavoro del team di Stacktrace.it, composto da professionisti italiani dell'informatica, e gli articoli pubblicati sono interessanti ed originali.

L'idea è ottima, i risultati iniziano già a farsi vedere. Non resta che aggiungere il feed al nostro feed-reader (RSSyl, nel mio caso) e sperare che i ragazzi di Stacktrace.it continuino così!

mercoledì 26 dicembre 2007

Un'occhiata a JavaScript

Personalmente ho sempre considerato JavaScript un linguaggio di seconda categoria (anche di terza, volendo), forse perché non gode di ottima reputazione o forse perché uno dei principali ambiti di applicazione è la creazione di contenuto web dinamico lato client.

Dovendo però utilizzarlo per motivi accademici, oltre che per motivi di lavoro, mi sono deciso a dare uno sguardo un po' più approfondito a questo linguaggio, visto che sono convinto che sia necessario essere in grado di comprendere il funzionamento di un linguaggio per poterlo utilizzare, e che ogni linguaggio di programmazione abbia delle caratteristiche idiomatiche che è necessario conoscere.

Ho trovato davvero ottima l'introduzione al linguaggio JavaScript a cura di Douglas Crockford disponibile su Yahoo! Video.
Crockford è Chief JavaScript Architect in Yahoo!, e questo fornisce un'idea approssimativa della qualità del materiale proposto. Il video è diviso in quattro parti e la durata complessiva è inferiore alle due ore:


L'esposizione è chiara, il discorso scorrevole. È adatto ad un pubblico con nozioni generali di programmazione, che abbia intenzione di capire le differenze tra JavaScript e gli altri linguaggi di programmazione.

Consigliatissimo a tutti coloro debbano scrivere anche solo qualche riga di codice in JavaScript.

domenica 9 dicembre 2007

Una piccola applet personalizzata per il pannello di GNOME


Vi siete mai chiesti quale sia la forza che spinge gli sviluppatori di software libero a continuare a scrivere utili programmi, spesso di elevata qualità?
Ci sono sicuramente tante concause, ma penso che la soddisfazione di un'esigenza personale (gli anglofoni dicono "scratching his own itch") sia uno dei fattori maggiormente rilevanti.

Bene, oggi mi sono tolto una piccola soddisfazione, che voglio condividere con voi: la realizzazione di una piccola e rozza applet per il pannello di GNOME che mostri la qualità del segnale della mia scheda wireless.

So bene che ci sono già delle applicazioni che lo fanno, ma nessuna era semplice come volevo io, nessuna mi dava solo quell'informazione, nessuna mi appagava.

E poi, il bello è proprio questo: ce ne saranno migliaia, ma nessuna è mia! :)

Qui riporto alcuni dei passaggi fondamentali da me seguiti nella realizzazione dell'applet ed il codice sorgente completo della stessa, rilasciata sotto GNU GPL 3.

Prelievo dell'informazione sul segnale
Primo problema: come trovo l'informazione sulla potenza del segnale?
Penso che tutti conoscano l'utility iwconfig, che, tra le altre, fornisce anche l'informazione che cerco, sotto la voce "Link Quality".

Python, tramite il modulo commands, fornisce la possibilità di ottenere l'output di un comando. Vediamo come sfruttarlo:

import commands

interface = "eth2"

def get_signal_strength():
str = commands.getoutput("/sbin/iwconfig " + interface).split("\n")
for row in str:
pos = row.find("Quality=")
if pos > 0:
sig = row.split()[1].split("=")[1]
return sig

return ""

Questa funzione elabora l'output di iwconfig, cercando la riga contenente l'informazione ed estrapolandola. L'output di questa funzione sarà una stringa tipo "49/100", che è proprio quello che andremo a posizionare, rozzamente, nel pannello di GNOME.

Realizzazione di un'applet per il pannello
Perfetto, ora che abbiamo l'informazione che ci serve, dobbiamo solo mostrarla nel pannello ed aggiornare ad intervalli regolari quest'informazione. Come fare?

Fortunatamente esiste un modulo di python, chiamato gnomeapplet, che serve proprio a realizzare applet per il pannello di GNOME. Sotto debian, il pacchetto si chiama python-gnome2-desktop, ed installandolo vi tirerete dietro anche i binding Python per le GTK+ e per GNOME, che sono ovviamente necessari.

A questo punto, vista la solita mancanza di documentazione, non ho fatto altro che andare a spulciare gli esempi di gnomeapplet, ed ho verificato che è necessario, oltre alla scrittura del codice python, realizzare un file per Bonobo (uno dei componenti fondamentali di GNOME) in modo da fargli notare che esiste anche la nostra applet, e visualizzarla così nella finestra "Aggiungi al pannello" che mostra tutte le applet che si possono inserire.

Bando alle ciance, ecco il codice per l'applet vera e propria, wimonitor.py:

import pygtk
pygtk.require('2.0')

import gtk
import gnomeapplet
import gobject
import commands

interface = "eth2"
interval = 1000

def get_signal_strength():
str = commands.getoutput("/sbin/iwconfig " + interface).split("\n")
for row in str:
pos = row.find("Quality=")
if pos > 0:
sig = row.split()[1].split("=")[1]
return sig

return ""

def update_signal(label):
label.set_text(get_signal_strength())
return True

def applet_factory(applet, iid):
label = gtk.Label(get_signal_strength())
applet.add(label)
applet.show_all()
gobject.timeout_add(interval, update_signal, label)
return True

gnomeapplet.bonobo_factory("OAFIID:GNOME_WiMonitor_Factory", gnomeapplet.Applet.__gtype__, "hello", "0", applet_factory)


Ed ecco il codice del file GNOME_WiMonitor.server:

<oaf_info>

<oaf_server iid="OAFIID:GNOME_WiMonitor_Factory" type="exe" location="/home/andrea/wimonitor/wimonitor.py">

<oaf_attribute name="repo_ids" type="stringv">
<item value="IDL:Bonobo/GenericFactory:1.0"/>
<item value="IDL:Bonobo/Unknown:1.0"/>
</oaf_attribute>
<oaf_attribute name="name" type="string" value="WiMonitor"/>
<oaf_attribute name="description" type="string" value="Semplice monitor del segnale wireless"/>
</oaf_server>

<oaf_server iid="OAFIID:GNOME_WiMonitor" type="factory" location="OAFIID:GNOME_WiMonitor_Factory">
<oaf_attribute name="repo_ids" type="stringv">
<item value="IDL:GNOME/Vertigo/PanelAppletShell:1.0"/>
<item value="IDL:Bonobo/Control:1.0"/>
<item value="IDL:Bonobo/Unknown:1.0"/>
</oaf_attribute>
<oaf_attribute name="name" type="string" value="WiMonitor"/>
<oaf_attribute name="description" type="string" value="Semplice monitor del segnale wireless"/>
<oaf_attribute name="panel:category" type="string" value="Utility"/>
<oaf_attribute name="panel:icon" type="string" value="bug-buddy.png"/>
</oaf_server>

</oaf_info>


È necessario modificare l'attributo location del primo tag oaf_server in modo da renderlo coerente con la posizione reale del file wimonitor.py.

Potete posizionare il file wimonitor.py dove preferite, mentre il file GNOME_WiMonitor.server va posizionato in /usr/lib/bonobo/servers.

Configurate l'applet modificando opportunamente i valori delle variabili interface e interval.

Se tutto è andato bene, troverete WiMonitor tra le applet da aggiungere al pannello, ed aggiungendola potrete avere sott'occhio l'andamento del segnale della vostra scheda wireless.

Conclusioni
Effettivamente l'applet è un po' bruttina, non è personalizzabile.. È decisamente migliorabile!
Ma onestamente a me non interessava creare un sexy framework di monitoraggio delle prestazioni di rete, volevo soltanto avere sott'occhio velocemente quell'informazione e dare un'occhiata alla programmazione GNOME in Python.

Spero che questo post sia utile come introduzione a tutti coloro che abbiano voglia anche loro di togliersi uno sfizio del genere.

E ricordate... Python RULEZ!