DCOP: chi era costui


Vi siete mai chiesti a cosa servono i personal computer? Oggi tutti li usano di continuo, cercando sempre il programma più adatto alle proprie esigenze e, nel caso di GNU/Linux, l’ambiente più idoneo. Quello che soddisfa maggiormente i propri bisogni, quello che offre più applicazioni, un comfort maggiore, arrivando a personalizzare ogni elemento del desktop stesso, un po’ come ordinare la propria scrivania sistemando gli appunti e i libri che servono. Una delle ragioni che ha portato alla diffusione crescente dei computer è stato proprio questo, ovvero la possibilità di semplificare fortemente la vita e il lavoro degli utenti. Tale lavoro è stato affidato ai programmi, che sono stati “educati” ai loro compiti da chi ha creato lo schema di comportamento. Si è poi capito che se questi possono cooperare tra di loro, come avviene nella vita quotidiana tra le persone che riescono a realizzare un progetto complesso dividendosi i compiti, allora da un computer si riesce a ottenere ancora di più. Infatti si realizzano applicazioni più complesse tramite la cooperazione di altre meno elaborate che si dedicano però a compiti specifici in modo specializzato. Il risultato per l’utente è quello di goderne i vantaggi usando applicazioni ancora più complete e ricche di funzionalità. Questo concetto è stato applicato in UNIX da sempre con l’uso della “pipe” che permette di usare i dati elaborati da un programma come nuovi dati in ingresso a un secondo programma, quindi comunicando. E tale concetto è stato esteso e applicato anche alle moderne interfacce grafiche. I nuovi programmi possono facilmente usare funzionalità presenti in altri per poter soprattutto ottenere una maggiore integrazione tra le parti. In un ambiente desktop come KDE 3 si parla di DCOP (in KDE 4 c’è la nuova tecnologia DBUS comune non solo a KDE, ma anche ad altri Desktop Environment).

1. Cos’è DCOP?

Il termine DCOP è l’acronimo di Desktop COmmunication Protocol, ovvero Protocollo di Comunicazione del Desktop. Tale nome indica per l’appunto un insieme di strumenti che i programmi di KDE usano per trasmettersi informazioni. DCOP è stato reso disponibile all’utente il 23 ottobre 2000, ovvero con la versione 2.0 del desktop. Da allora DCOP, tecnologia specifica di KDE, si è sviluppato e integrato in tutte le sue applicazioni, mettendo a disposizione diverse interfacce DCOP per i vari programmi. KDE, inoltre, non è esclusivamente un ambiente grafico, in realtà è qualcosa di più, infatti sono stati ben integrati la linea di comando e lo scripting. DCOP è utilizzabile, tra l’altro, anche tramite script per poter controllare così l’intero ambiente con qualche linea di bash, perl, Python, C#, Java. Tale integrazione la si ottiene tramite il pacchetto kdebindings.

Ogni applicativo di KDE fornisce un’interfaccia DCOP base che, per esempio, produce il ridimensionamento della finestra principale o imposta la stessa per restare “sempre in primo piano”. A queste funzioni di base si aggiungono quelle specifiche di una data applicazione, infatti la maggior parte dei programmi KDE fornisce anche delle interfaccie che permettono di guidare una buona parte dell’applicazione stessa. In KMail, per esempio, si può controllare l’arrivo di email o creare un nuovo messaggio con il testo desiderato e il soggetto specificato, con la possbilità di allegare anche un file. In Konqueror si può aprire una nuova finestra con una specifica URL, e in KWord si possono cambiare le proprietà del documento aperto in quel momento. La lista potrebbe continuare ancora per molto, ma è meglio scoprire queste cose dopo aver spiegato meglio cos’è DCOP.

2. Motivo e architettura DCOP

Il K Desktop Environment è stato progettato sin dal principio come un insieme di programmi, ognuno con lo scopo di risolvere una determinata e ristretta categoria di problemi. E similmente agli altri desktop precedenti KDE presenta un buon sistema di comunicazione tra le applicazioni al fine di ottenere una maggiore integrazione tra i suoi componenti. Inizialmente si valutarono varie tecnologie, tra cui CORBA che fu usata per circa un anno, ma questa aveva notevoli problemi prestazionali e alla fine, per una comunicazione efficiente tra le applicazioni di KDE, si optò per l’alternativa che ha poi accompagnato KDE sino ad oggi, ovvero DCOP.

Il DCOP si fonda sul paradigma client/server, infatti ogni applicazione che ha necessità di comunicare con un’altra rappresenta un client DCOP. Dopo aver effettuato il login in KDE, questi lancia l’esecuzione di un server DCOP (il cui nome del processo è dcopserver), che resta in esecuzione permanente per smistare i messaggi che ogni client gli invia. Inoltre, il fatto che il client debba utilizzare un server per inviare messaggi a un altro client è solo un dettaglio di natura tecnica, infatti nello specifico risulta completamente trasparente, cioè ogni client vede se stesso, molto semplicemente, come parte di un’architettura di peer in cui comunica direttamente con gli altri client.

Il server DCOP prevede una funzionalità di registrazione. Essa serve a quei client che elaborano dati, infatti le applicazioni devono registrarsi presso il server per poter mettere a disposizione i propri “servizi”, accessibili tramite DCOP. Solo così possono ricevere e processare i messaggi degli altri client DCOP che ne richiedono i servizi, e senza identificarsi risulterebbe impossibile, quindi con la registrazione i client si riconoscono come peer per altri peer.

Alcuni client DCOP (detti “a sola chiamata”) possono usufruire di un meccanismo di messaggio anonimo. Questi tipi di client sono quelli che non corrispondono ad applicazioni che offrono un’interfaccia DCOP, ma sfruttano quelle delle altre. Ricadono in questo tipo di categoria, per esempio, gli script bash, infatti un modo di utilizzare DCOP, come accennato, è quello di usare linguaggi di script. Uno script non offre servizi DCOP, ma utilizza quelli delle altre applicazioni registrate.

I messaggi che i programmi KDE inviano ad altri programmi KDE, possono essere di due tipi:

  • chiamate ai metodi: in questo caso si usa il nome di un oggetto affinché il client che riceve il messaggio possa implementare la chiamata al metodo corretto;
  • emissione di segnali: ciò permette comunicazioni signal/slot in stile Qt tramite DCOP.

È con le chiamate ai metodi che si sfruttano direttamente le funzioni disponibili nell’applicazione scelta. Si vedranno alcuni esempi pratici a fine articolo.

3. Un client DCOP

In KDE si dispone di due client DCOP anonimi: ‘kdcop’ e ‘dcop’.

Il primo prevede un’interfaccia grafica, mentre il secondo è costituito dalla classica linea di comando utilizzabile in Konsole oppure da una shell remota in modo opportuno. kdcop non si trova in alcuna voce del menu K. Lo si può eseguire in diversi modi, per esempio si può scegliere “Esegui comando…” dal menu K e poi scrivere “kdcop” premendo il tasto di INVIO ottenendo quanto riportato in figura. Si cercherà ora di descrivere il funzionamento di tale client per poter poi affrontare il concetto di “script con DCOP” con l’uso del client testuale ‘dcop’. Nella finestra principale il client grafico riporta l’elenco di tutti i client DCOP registrati presso il server e da cui, quindi, è possibile ottenere dei “servizi”.

kdcop in azione

Eseguendo Konqueror si noterà che nell’elenco dei client registrati ne compare uno nuovo, per esempio: konqueror-5002. Il numero di seguito al nome dell’applicazione sta a indicare il pid del processo, infatti in Konqueror, a differenza di altre applicazioni come noatun e KMail, è possibile aprire più istanze. C’è da dire di più. Se si richiudesse il Konqueror aperto si noterebbe che dall’elenco di kdcop non sparisce, questo perché viene semplicemente nascosto all’utente mantenendosi in esecuzione, in modo che se successivamente si torna a eseguirlo, verrà resa visibile l’istanza già in elenco a kdcop rendendo quindi immediata la riapertura del programma. In questo modo KDE intende ottimizzare il tempo di apertura proprio di Konqueror che risulta un’applicazione dai tanti usi. Espandendo la visualizzazione ad albero di konqueror-5002 notiamo una serie di sottoelementi. Sono le interfacce/oggetto, ovvero i tipi di servizi disponibili e per ognuno di essi si ha un ulteriore sotto elenco che costituisce i membri utilizzabili, ovvero le funzioni vere e proprie. È possibile ordinare all’istanza di Konqueror di nascondersi o di rendersi nuovamente visibile? Naturalmente. Come? Se si scorre l’interfaccia/oggetto konqueror-mainwindow#1 si noteranno due membri: ‘void hide()’ e ‘void show()’ che permettono rispettivamente di nasconde e mostrare a video la finestra in cui è racchiuso l’applicativo.

È complicato? Ricorriamo alla casella di ricerca e digitiamo show… Facile, no? E se si volesse sapere se tale istanza già è visibile o meno? Sempre in questa interfaccia/oggetto esistono i membri ‘bool visible()’ e ‘bool shown()’ che rendono noto se l’istanza è visibile. Operando un doppio clic col tasto sinisto del mouse si otterrà il valore ‘true’ nell’area indicata da ‘Tipo di dato restituito:’ se è per l’appunto visibile, altrimenti restituirà il valore false.

ecco la funzione che ci interessa: show

Ogni membro è caratterizzato da un tipo di dato restituito e da un elenco di parametri richiesti. Il tipo di dato restituito è void se non rende nulla, altrimenti sarà di uno specifico tipo C++/Qt/KDE, per esempio visible() è di tipo bool ovvero si usa come valore di verità. Quando il membro non ha bisogno di parametri allora questi non saranno indicati, altrimenti questi sono elencati nelle parentesi specificandone il tipo e il nome. Per esempio, se si desidera aprire una URL in Konqueror basta accedere sempre all’interfaccia konqueror-mainwindow#1, utilizzando il metodo

void openURL(QString url)

e usando il doppio clic, tramite una finestra di dialogo sarà richiesto di immettere una URL:

ecco la funzione che ci interessa: openURL

premuto il tasto INVIO Konqueror si adopererà per caricare l’indirizzo specificato. Se si desidera aprire un ulteriore indirizzo URL in una linguetta senza perdere la pagina precedente basta usare il metodo

void newTab(QString url)

E per selezionare tutti gli elementi della pagina in una linguetta? Basta usare void selectAll(). Si può selezionare col puntatore del mouse una porzione di testo, ma quale membro restituirà il testo selezionato? Semplice:

QString selectedText()

Ci sono varie funzioni DCOP utili in Konqueror e nelle altre applicazioni di KDE, basta scoprirle dedicandovi un po’ di tempo.

4. Drag & Drop per DCOP e scripting da Konsole

Dopo aver scoperto la semplicità dei clic con kdcop, ci si renderà conto subito che non è l’uso di tali clic che avvicina agli script DCOP, infatti ci sono ancora alcuni semplici concetti che potranno prepararne la strada. Se si trascina il membro selezionato in Konsole, si avrà l’idea di quale sia la vera chiamata che va effettuata per realizzare uno script, per esempio, bash.

Si consideri il membro QString currentURL() sempre nell’interfaccia konqueror-mainwindow#1. Trascinando la selezione in Konsole si ottiene:

dcop konqueror-1285 konqueror-mainwindow#1 currentURL

ecco la funzione che ci interessa: currentURL

che restituirà in output la URL aperta nell’istanza di Konqueror.

Come si nota si è utilizzato il client testuale ‘dcop’ in Konsole. Si vedranno ora le caratteristiche di tale client e alcuni comandi testuali di ‘dcop’ utili per alcune funzioni. L’utilizzo di ‘dcop’ è il seguente:

dcop [opzioni] [applicazione [oggetto [funzione [arg1] [arg2]...]]]

Se non si specifica nulla si otterrà semplicemente la lista delle applicazioni registrate sul server DCOP:

linux@kde-it.org ~> dcop
konsole-5566
kwin
kwrite-3460
kicker
...
konqueror-5002
ksnapshot-1310
klipper
ksmserver

altrimenti è possibile come si faceva in ‘kdcop’ scorrere un “albero” accedendo al tipo di funzioni disponibili da un oggetto (che rappresenta l’interfaccia di una applicazione DCOP registrata) di una data applicazione. Si ottiene la lista degli oggetti/interfacce accessibili indicando solo il nome dell’applicazione DCOP registrata. Per esempio:

linux@kde-it.org ~> dcop konqueror-5002
qt
KBookmarkManager-/home/linux/.kde/share/apps/konqueror/bookmarks.xml
KBookmarkNotifier
KDebug
KDirNotify-1
KIO::Scheduler
KShortURIFilterIface
KURIIKWSFilterIface
KURISearchFilterIface
KonqFavIconMgr
KonqHistoryManager
KonqUndoManager
KonquerorIface (default)
LocalDomainURIFilterIface
MainApplication-Interface
konqueror-mainwindow#1
ksycoca
unnamed

se oltre all’applicazione si indica anche l’interfaccia/oggetto a cui si desidera accedere, si otterà l’elenco di tutti i membri/funzioni disponibili. Per esempio:

linux@kde-it.org ~> dcop konqueror-5002 konqueror-mainwindow#1
QCStringList interfaces()
QCStringList functions()
...
void show()
void openURL(QString url)
void newTab(QString url)
void reload()
DCOPRef currentView()
DCOPRef currentPart()
DCOPRef action(QCString name)
QCStringList actions()
QMap actionMap()
bool windowCanBeUsedForTab()

Se si prova

dcop konqueror-5002 konqueror-mainwindow#1 openURL www.kde.org

si visualizzerà la pagina del sito di KDE. Se non sembra accadere nulla, forse precedentemente è stata chiusa l’istanza di Konqueror. Basta eseguire

dcop konqueror-5002 konqueror-mainwindow#1 show

e sarà resa visibile nuovamente. Naturalmente 5002
è il pid di konqueror sul sistema su cui sono stati eseguiti gli esempi, quindi per ripeterli va individuato il pid di Konqueror semplicemente annotandolo da kdcop o dalla
linea di comando dcop.

Nel caso in cui si desideri avviare un’applicazione e ottenere il valore di riferimento da usare con DCOP per effettuare tutte le chiamate, si può utilizzare il comando ‘dcopstart applicazione‘. Per esempio:

dcopstart konqueror

che esegue konqueror e restituisce l’identificativo con cui si è registrato presso il server DCOP. Quindi se si desidera realizzare uno script bash basta utilizzare:

idkonq=`dcopstart konqueror`

in questo modo $idkonq conterrà l’identificativo che serve. Bisogna fare attenzione perché le virgolette usate per il comando precedente non sono le solite virgolette, ma sono ottenute con la combinazione di tasti AltGr + ‘ . Nel caso si volesse aprire in tale istanza di Konqueror il sito di KDE basterà scrivere:

dcop $idkonq konqueror-mainwindow#1 openURL www.kde.org

oppure eseguire direttamente:

dcop `dcopstart konqueror` konqueror-mainwindow#1 openURL www.kde.org

5. Esempi di scripting DCOP

Produrre un unico grande esempio di DCOP non è lo scopo del presente articolo, infatti le istruzioni DCOP andrebbero magari utilizate nel codice C++ o con alcuni elementi grafici possibili anche da linea di comando con kdialog, quindi a questo punto si chiariranno i concetti affrontando degli esempi pratici di scripting DCOP.

5.1 script remoti

DCOP è un concetto che in un certo senso permette davvero di tenere sotto controllo un PC. In che modo? Si immagini di avere una propria LAN… In effetti bastano anche solo 2 PC collegati tra loro. Si immagini di avere su uno dei due PC l’ambiente KDE in esecuzione assieme a un server SSH. Magari su tale PC si possiede una buona scheda sonora con un
altrettanto buon sistema di diffusori. Un’idea potrebbe essere quella di ascoltare una lista di canzoni dando i comandi tramite l’altro PC. Con questo esempio non si scopre nulla di nuovo, ma si propone una visione diversa di KDE per chi l’ha sempre visto come un ambiente da usare in modo “statico”.

Naturalmente nella propria rete si è configurato tutto in modo da essere a conoscenza delle password dell’utenza del PC a cui si vuole accedere. Prima di tutto bisogna per l’appunto creare un canale verso il PC che abbiamo deciso debba eseguire da remoto alcuni brani audio, quindi il primo passo è quello di eseguire:

ssh utenza@indirizzoIP

a tal punto si scopre per esempio che juk è lì pronto nel pannello di sistema visto che compare nelle applicazioni DCOP registrate sul server DCOP. E se non lo fosse? Non si può eseguirlo con ‘dcopstart juk‘ e nemmeno con un semplice ‘juk‘. Bisogna fare per prima cosa:

export DISPLAY=":0.0"

visto che si è in una shell remota, ovvero non è definito il $DISPLAY per accedere al desktop. Dopo questa operazione si può eseguire:

idjuk=`dcopstart juk`

poiché l’identificativo di juK è sempre e solo ‘juk’, la variabile $idjuk risulta superflua, ma è un metodo valido in generale.

Allora. Si vuole eseguire una canzone? Naturalemente deve essere lì sul disco remoto pronta all’uso:

dcop juk Player play file-audio

E se invece si desidera riprodurre la solita sequenza della playlist già pronta in juk? Allora basta non indicare file-audio. È troppo tardi? Già avete lanciato l’esecuzione? Basta fermarla con:

dcop juk Player stop

e riprovare con

dcop juk Player play

Ancora non va bene? Stavolta è il volume che è troppo basso?

dcop juk Player volumeUp

Non è cambiato molto? Si può riprovare di nuovo con volumeUp, ma se la variazione è ancora poca cosa allora si può verificare il livello del volume per aumentarlo di conseguenza:

dcop juk Player volume

1.000000

Si può provare a raddoppiarlo:

dcop juk Player setVolume 2

al limite triplicarlo, ma non bisogna eccedere perché sennò si otterrà una distorsione dello stesso. Ora che si è ottenuto il livello giusto suona il telefono? Basta rendere muto juK con un

dcop --user utenza juk Player mute

senza dimenticare di mettere in pausa il brano. Si è stanchi della canzone corrente? Si provi a passare alla successiva, ormai dare le istruzioni passo per passo sarebbe inutile. Di certo avete appreso il meccanismo. Per esercizio si consiglia di ripetere le varie operazioni utilizzando amarok anzicché juK. Il computer che sta riproducendo i brani è di vostro fratello e ha uno sfondo poco piacevole? È il vostro e non volete spostarvi, ma operare da remoto la modifica dello sfondo? È semplice. Si ricorre a kdesktop con un:

dcop kdesktop KBackgroundIface setWallpaper file-immagine 1

che imposta lo sfondo sul primo desktop. Il valore ‘1’ indica la modalità. Si provino valori differenti per vederne le differenze. Se si intende modificare lo sfondo di un’altro desktop virtuale diverso dal primo basta specificarne il valore tra il ‘setWallpaper‘ e ‘file-immagine‘.

5.2 Copia e incolla

Un altro esempio consiste nello sfruttare gli appunti di KDE. Si può per esempio inserire il contenuto di un file di testo negli appunti oppure fare il contrario, ovvero creare un file di testo dal contenuto degli appunti. Si analizzeranno entrambe i casi. Per il primo, per esempio si può pensare di sfruttare kwrite e in tal caso bastano le seguenti righe in bash:

1. #!/bin/bash
2. idkwrite=`dcopstart kwrite $1`
3. if [ $? -eq 0 ]; then
4.    sleep 2
5.    dcop $idkwrite SelectionInterface#1 selectAll
6.    dati=`dcop $idkwrite SelectionInterface#1 selection`
7.    dcop klipper klipper setClipboardContents "$dati"
8.    dcop $idkwrite MainApplication-Interface quit
9. fi

Cosa fa il codice? Esegue kwrite (linea #2) con il primo paramentro passato dalla linea di comando (naturalmente deve essere il nome di un file di testo). Se kwrite è stato lanciato correttamente (linea #3), si attendono 2 secondi (#4) in modo che l’applicazione abbia il tempo di inizializzarsi e registarsi presso il server DCOP. A tal punto si seleziona tutto il testo (#5), si copia la selezione in una variabile dati (#6), si imposta il testo catturato negli appunti di KDE (#7) e si chiude kwrite (#8). Fatto ciò si può provare ad aprire per esempio KWord e incollare il testo premendo il tasto cetrale del mouse (oppure il tasto sinistro e destro contemporaneamente se il centrale non va).
Naturalmente un attento praticante di DCOP si accorge subito che questo script non va bene. Certo funziona, ma non è il miglior modo per eseguire l’esercizio, infatti al posto delle righe #6 e #7 bastava:

dcop $idkwrite ClipboardInterface#1-1 copy

In realtà questo è uno script didattico, infatti si è semplicemente voluto introdurre il concetto di ‘appunti di KDE’ in DCOP, solo per lanciare un altro input nei confronti di chi vuole saperne di più. Al solito per vedere le funzionalità DCOP degli ‘appunti di KDE’ basta usare ‘dcop klipper‘. Come ottenere ora un file testuale da ciò che è stato copiato negli appunti di KDE, per esempio selezionando alcune righe di una pagina internet aperta con Konqueror? Ecco il codice:

#!/bin/bash
appunti=`dcop klipper klipper getClipboardContents`
echo "$appunti">$1

Tale codice va salvato e poi eseguito con un parametro che indica il nome del file da creare. Per esempio:

sh ./script-paste esempio.txt

Controllando il file esempio.txt si ottiene ciò che resideva negli appunti di KDE.

5.3 Salve dottor Falken

L’esempio riportato di seguito riguarda Kopete, il programma di messagistica istantanea multi protocollo di KDE. Tale script è presente nel sito dell’IBM developerWorks. Il collegamento preciso lo trovate nei riferimenti (4). Mi è sembrato semplice e interessante, così, col permesso dell’autore, lo riporto:

#!/bin/bash
name=$1;
msg=$2;
echo Sto aspettando che $name si colleghi al server
while ((`dcop kopete KopeteIface reachableContacts | grep -c $name` == 0))
do
  sleep 5
done
echo Sto inviando il messaggio "$msg" a "$name"
dcop kopete KopeteIface messageContact $name "$msg"

Lo script prevede l’uso di due parametri e di Kopete. I due parametri sono riferiti al nome del contatto a cui volete inviare un messaggio e al messaggio stesso. Lo script si mette in attesa, aspetta che il contatto che si è scelto effettui la connessione al server e poi gli inoltra il messaggio. Naturalmente Kopete deve essere in esecuzione e connesso al server a cui il vostro amico si collega. Si può lasciare il PC acceso e avviare lo script coi due parametri specificati e poi allontanarsi. Ci si chiederà: “perché non mandare una email che è più semplice?” In questo modo saprete subito se la persona ha ricevuto o meno il messaggio sempre che non vi disconnettiate prima che il messaggio possa essere spedito.

6. KDE 4 e conclusioni

Come visto le caratteristiche di base e la sintassi DCOP sono abbastanza semplici, ma in ogni caso per impararlo la pazienza è un requisito fondamentale, infatti dopo il tempo speso inizialmente su DCOP, il numero di cose che si potranno fare saranno davvero tante. Per potersi impadronire definitivamente di questo utile strumento si consiglia di imparare a usare le varie interfacce che le diverse applicazioni di KDE mettono a disposizione. Esercitatevi e sperimentate. Sperimentate.

Nel frattempo se avete avuto modo di installare da SVN quello che in futuro sarà KDE 4 avrete di certo notato che DCOP è stato sostituito da D-BUS, una tecnologia standard
che permetterà la comunicazione tra tutte le applicazioni che rispettano detto standard, quindi non solo quelle di KDE, infatti DCOP è una tecnologia creata dagli sviluppatori di KDE per KDE, mentre D-BUS è nata in maniera generica e che può essere utilizzata dai diversi Desktop per far comunicare le loro applicazioni in modo simile a quanto avviene
per DCOP. La migrazione non è complessa, quindi non sprecherete tempo se ora vi impegnerete a usare DCOP. Preparerete solo il terreno per lo studio di D-BUS in attesa di KDE 4 nel 2007.

Il commit che ha rimosso definitivamente le tracce di DCOP è stato il #546830 in data 31 maggio 2006.

RIFERIMENTI:

(1) http://developer.kde.org/documentation/library/kdeqt/dcop.html
(2) http://developer.kde.org/documentation/books/kde-2.0-development/ch13.html
(3) http://www.blackie.dk/~dfaure/conf/OSDEM/html/slide_7.html
(4) http://www-106.ibm.com/developerworks/linux/library/l-dcop/index.html?ca=dgr-lnxw02ConnectKDE
(5) http://www.linux-magazine.com/issue/36/KDE_Scripting_DCOP.pdf

Giovanni Venturi

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...