Com\’è dura la professione!

16 novembre 2009

Sfruttare il system tray per controllare i job di KDE

Filed under: kde4,Open Source,Programmazione — lbell @ 22:07

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:

26 ottobre 2009

Compilare KDE 4.4 con Qt4.6 e kdesvn-build

Filed under: kde4,Open Source,QT — lbell @ 21:55

Con il passaggio del trunk di KDE a Qt4.6 avvenuto il 10 ottobre non è più possibile utilizzare il sistema di build basato su kdesvn-build 1.9.1, dato che i sorgenti delle librerie Qt sono affidati a git e kdesvn-build si interfaccia con Subversion, occorrerebbe gestire manualmente il modulo qt-copy. Occorrerebbe, perché è appena stata rilasciata la versione 1.10, che è in grado di gestire git per il solo modulo qt-copy. E’ disponibile nel sito ufficiale da un paio di giorni e nel repository svn di KDE in branches/work/kdesvn-build-1.10. Per usarlo, occorre modificare la sezione relativa al modulo qt-copy nel file .kdesvn-build.rc nel modo seguente nella sezione dedicata a git:

module qt-copy
	#opzioni di compilazione
	configure-flags -system-zlib -qt-gif -system-libjpeg -system-libpng \
			-no-exceptions -fast -debug -dbus \
	            -no-phonon # Phonon built separately
	make-options -j2

	# opzioni di gestione git
	branch 4.6-stable-patched
	repository http://git.gitorious.org/+kde-developers/qt/kde-qt.git
end module

Sito di kdesvn-build:

http://kdesvn-build.kde.org/releases/kdesvn-build-1.10.php

8 aprile 2009

Activities are for humans

Filed under: kde4,Programmazione — lbell @ 21:48

Computers are very versatile tools, used in a variety of situations, to work, listen music, write documents, but it is very difficult to create a comfortable user environment for each task. When working to an important document, mail notifications are very annoying, but turning off completely notifications is not the ideal solution, mails related to the activity are welcomed. What is missing is the possibility that the computer adapts his environment to different activities.

Virtual desktops are the more advanced solution to implement activities today, but this is only a start.

There is a difference between a virtual desktop and an activity: virtual desktop is a collection of resources (windows mainly), an activity is a collection of related resources. You can work for a project, read documents, contact people, receive mails and so on and all these items can stay associated to the activity you are currently operating.

We can roughly consider an activity on top of a collections of virtual desktops.

A ‘recent document’ menu can contain a lot of unrelated documents, a personal letter written in a pause together with work documents and worst, it has a finite length, so new documents of unrelated activities are pushing into oblivion very important bookmarks.

Activities are useful to categorize and filter environment items, but it is not practical to manually label each resource that can reside in an activity, so the workspace should automatically collect informations, like the mylyn plugin in Eclipse world

http://www.ibm.com/developerworks/java/library/j-mylyn2/

When in an activity you can associate not only documents related to that activity, but also contacts, sites, and so on.

We work on different projects and we use the computer for personal activity each day. Computers are universal devices and can be used for different purposes.

As a further example, it is an annoyance to receive mail notifications from people not related to projects ( with obvious exception for emergencies ) in working hours. An activity can filter what that can distract, without hiding information, but focusing out of view not relevant factors.

It is important to have a simple ‘relations’ manager to handle what resources are related to an activity and move or copy them from a workspace to another (maybe using the KDE plasmoid zoom interface).

It is important to have multiple activity configurations, you can use same laptop at work and at home, even applications menu can change in different situations.

Activities attributes and resources should be shared between teams.

There are two types of applications: specialized ones (video, audio, graphics editor for instance ) and generics ones ( word processors, time tracker, etc) that should have different behavior. How horizontal applications like file browsers should behave? Why not filter activity related directories in ‘Open File’ dialogs? Currently this dialog supports only a simple filter that maps to file type (a word processor filter documents, a spreadsheet csv and so on)

How to save data in application specific format and not using specialized Desktop Environment routines? How to integrate, for example, Open Office? We should use the metadata we are using for browsers: the tags, but there is the problem to maintain metadata in sync with data when moving files, doing backups and so on. All the files that user opens or write should be logged, but the metainformations should be stored in the document or in the filesystem?

Even phones have different modes: mute, normal, meeting etc.

Tags and activities are separate concepts, tags are traversal and additive, activities are thematic.

Desktop Environment should leads the user how to enter and how to exit from an activity. We should decrease normal desktops visual clutter that confuses the user about his state.

Another problem is how to include external resources if the filter are restrictives, maybe by adding a button in each “Open File” dialog that let us choose to stay in the current activity environment or see all the resources.

Other open problems are how to integrate in this vision externals resources like network infrastructure, network, printers, etc.

Talking about concrete cases, like the recent documents menu, why not make it central for a desktop or expand it to order it for ( I often need this ) creation date, write date, access timestamp or access frequency, category?

Why not display this menu in a cloud representation? More, the vertical list used is a very short and useless representation. A timeline can be more useful.

Different activities can be created for different purposes even using same programs.

In a desktop system I can save programs state on disk passing from an activity to another one, but not on phone system for device limits.

Anyway each journey begins with a single step, and Plasma is a good one.

http://techbase.kde.org/Projects/Plasma

19 marzo 2009

Un viaggio in WebKit transitando per Plasmaland

Filed under: kde4,Open Source,Programmazione,QT — lbell @ 22:55

Scrivendo una piccola utility per Plasma mi sono fatto tentare dall’uso della nuova versione di WebKit per gestire l’interfaccia utente.

In effetti integrare WebKit in un programma QT o KDE non è troppo difficile, grazie all’uso degli slot e delle metainformazioni che QT aggiunge alle classi. E’ possibile richiamare direttamente i metodi di oggetti residenti nel nostro programma, sfruttando il meccanismo dei segnali e degli slot, dalla pagina HTML via Javascript. Per prima cosa occorre inserire nelle pagine HTML riferimenti agli oggetti C++ della nostra applicazione come se fossero variabili Javascript native, utilizzando un identificatore che verrà mappato sugli oggetti fisici a tempo debito. Fatto ciò possiamo codificare funzioni Javascript che sfruttino i metodi dichiarati come slot, in corrispondenza di determinati eventi, come la pressione di un pulsante. Possiamo quindi dalla pagina HTML eseguire metodi dei nostri oggetti passando quali parametri entità definite al livello HTML, come ad esempio i valori di un form.

Ogni collegamento tra WebKit e la nostra applicazione avverrà sempre tramite funzioni Javascript, quindi sarà WebKit ad iniziare le operazioni.

Facciamo un esempio:

Supponiamo che il nostro obiettivo sia di richiamare da Javascript il metodo ‘reload’ di un’istanza di una classe C++ descritta in questo modo:

class DBusApplet : public
Plasma::PopupApplet
{
    Q_OBJECT
    ...
public
slots:
    void reload(const QString &selection);
private:
    ...
};

in Javascript la nostra istanza può essere mappata come segue, assumendo che sia stata associata all’identificatore ‘appletInterface’:

function execute(selection)
{
    appletInterface.reload(selection);
}

Dato che la conversione dei tipi di base è automatica, quello che occorre fare è ‘iniettare’ gli oggetti C++ all’interno del componente WebKit, ma è necessario attendere che sia il componente ad avvertirci del momento più opportuno.

Al termine del caricamento di una pagina HTML, che la si assegni direttamente da programma o attraverso un URL, il frame corrente emette infatti il segnale “javaScriptWindowObjectCleared”, che occorre avere cura di catturare nel solito modo che QT ci mette a disposizione:

connect(page()->mainFrame(),

SIGNAL(javaScriptWindowObjectCleared()), this, SLOT(populateJavaScriptWindowObject()));

Alla ricezione del segnale possiamo, attraverso il metodo collegato (nell’esempio precedente ‘populateJavaScriptWindowObject’), passare finalmente il riferimento dei nostri oggetti a WebKit attraverso il metodo addToJavaScriptWindowObject, i cui argomenti sono il nome della variabile Javascript associata e l’indirizzo dell’oggetto stesso.

page->mainFrame()->addToJavaScriptWindowObject(“appletInterface”, this);

Se tentassimo di associare i nostri oggetti prima che la pagina sia stata effettivamente caricata, il collegamento non avrebbe successo.

http://doc.trolltech.com/4.4/qtwebkit.html

http://webkit.org/

http://code.google.com/p/dbusapplet/

4 gennaio 2008

È nato il nuovo anno, è nato KDE 4.0.0

Filed under: kde4,Open Source — lbell @ 21:47
Tags: ,

Non sarà il passo che porta alla salvezza del genere umano, o un capolavoro come la Gioconda, ma KDE 4.0.0 è praticamente pronto per il rilascio di metà gennaio, proprio nei giorni del mio compleanno, in un evento in grande stile a Mountain View nella sede di Google. La versione attuale non sarà tuttavia un ambiente che qualunque utente potrà desiderare di utilizzare già da ora al posto della 3.5 attuale, ma piuttosto una base su cui far crescere il KDE di domani: il processo di sviluppo del software Open Source è diverso da quello del software proprietario e questo post di Aaron Seigo lo descrive bene:
http://aseigo.blogspot.com/2008/01/talking-bluntly.html.
La fretta e la confusione con cui sono state eseguite le ultime traduzioni per rientrare nella deadline imposta, valida anche per il congelamento del codice, mi ha ricordato per certi versi l’atmosfera di un giornale al momento di andare in stampa. Più di 700 commit in un paio di giorni non è una cifra da disprezzare.
Forse è troppo tardi per la applicazioni desktop, ma KDE4 è comunque un’avventura affascinante.
Buon anno KDE, da lunedì si torna al lavoro con Windows.

Crea un sito o un blog gratuitamente presso WordPress.com.