Una delle funzionalità offerte da KDE4 a sviluppatori ed utenti è quella di gestire i lavori a lungo termine delle applicazioni mediante un componente del vassoio di sistema. L’infrastruttura mette a disposizione dell’utente un unica locazione dalla quale può controllare l’andamento delle operazioni, opzionalmente sospenderle, sbloccarle o controllarne l’esito anche dopo il loro termine. Si evita così che ogni applicazione che intende avvalersi di questa funzionalità debba implementare una interfaccia di controllo. Dal punto di vista del programmatore, la fatica di imparare una nuova serie di API è ripagato dal fatto che è l’ambiente a prendersi in carico il compito di interagire con l’utilizzatore, sia per quello che riguarda l’aspetto funzionale, sia per l’interfaccia utente. Ovviamente i soli lavori di cui dovrà essere notificato lo stato di avanzamento mediante questa caratteristica sono solo quelli a lungo termine, per evitare di confondere l’utente con una miriade di messaggi irrilevanti.
Vediamo ora come si può sfruttare questa funzionalità:
Le applicazioni che intendono sfruttare il sistema di notifica devono incapsulare direttamente o indirettamente l’attività in una struttura KIO::Job, ad esempio derivando da essa la nostra classe di esempio KJobTest.
#include <kjob.h> class KJobTest : public KIO::Job
Se si desidera che l’utente, una volta comparsa la notifica, possa mettere i lavori in pausa, riprenderli o annullarli occorre, nella nostra classe, chiamare la funzione
setCapabilities()
cui va passato come argomento un insieme di flag che ne determinano il comportamento. Con il valori Kjob::Suspendable si concede all’utente la possibilità di sospendere un lavoro, con KJob::Killable anche di terminarlo. Per abilitare entrambe le funzionalità, scriveremo:
setCapabilities(KJob::Killable|KJob::Suspendable);
Quando si è pronti per presentare il job all’utente, lo si deve registrare presso una struttura globale:
KIO::getJobTracker()->registerJob(m_jobTest);
Da questo punto in poi il job è visibile all’utente. Emettendo il segnale ‘infoMessage‘ si può forzare il pannello a mostrare la descrizione desiderata per indicare il proprio job.
Il job può essere attivato in modalità sincrona o asincrona. Nel primo caso tutto quello che dovrà fare l’applicazione per gestire il job sarà richiamarne il metodo ‘exec‘, definito nella classe base, che restituirà l’esito mediante un valore booleano. Dietro le quinte verrà attivato un loop di messaggi nascosto. Riporto l’esempio di utilizzo definito nella documentazione KDE:
void SomeClass::methodWithSynchronousJobCall()
{
KJob *job = someoperation( some parameters );
if ( !job->exec() )
{
// An error occurred
}
else
{
// Do something
}
}
Nel caso si intenda utilizzare il job in modo asincrono, metodo preferito per la gestione di operazioni a lungo termine, occorre attivare il job attraverso il metodo start(), richiamato in modo nascosto anche nel caso sincrono, e mettersi in attesa dei risultati collegando il segnale ‘result‘ ad uno slot. Ecco l’esempio relativo, sempre tratto dalla documentazione KDE:
void SomeClass::methodWithAsynchronousJobCall()
{
KJob * job = someoperation( some parameters );
connect( job, SIGNAL(result(KJob*)), this, SLOT(handleResult(KJob*)) );
job->start();
}
void SomeClass::handleResult( KJob *job )
{
if ( job->error() )
doSomething();
}
Nel metodo start(), da reimplementare nella nostra classe derivata da KJob, occorre utilizzare un meccanismo asincrono, come ad esempio un timer di tipo oneShot, per innescare il job, per evitare che un’attivazione direttamente nella funzione start() provochi un malfunzionamento della gestione sincrona del job attraverso la funzione exec(), per motivi derivanti dall’implementazione della funzione exec stessa. Se abbiamo deciso di non utilizzare mai l’interfaccia sincrona potrebbe sembrare una precauzione inutile, ma scrivendo codice che si deve integrare in un ambiente, occorre sempre rispettarne i dettami.
Quando l’utente decide di intervenire nella vita del job cambiandone lo stato, il pannello del vassoio di sistema richiamerà metodi doSuspend(), doResume() e doKill() del nostro job, mediante i quali si potranno realizzare le dovute azioni.
Durante il suo ciclo di vita, il job può inviare al pannello segnali riguardo il proprio stato o la percentuale di avanzamento.
Emettendo il seguente segnale:
emit infoMessage(job, messageText, messageRichText );
si può provocare la comparsa della scritta relativa allo stato puntuale del job. Allo stesso modo è possibile inviare informazioni relative alla velocità attuale ed alla unità di misura utilizzata, nel caso sia compresa tra quelle dell’enumeratore ‘Unit’ di KJob.
Come esempio di utilizzo possiamo utilizzare un semplice programma, jobsample, mediante il quale è possibile provare le tecniche esposte, configurare i parametri principali a disposizione di un job ed osservare i risultati.
I sorgenti di jobsample sono disponibili a questo indirizzo:
http://www.tsc4.com/lbell/presentazioni/src/jobsample.tgz
Finestra principale di jobsample:
job sample in esecuzione:
