About Dialog Command in una applicazione RCP

Per visualizzare la finestra di dialogo about dialog configurata all'interno di un prodotto Eclipse RCP è possibile usare il comando org.eclipse.ui.help.aboutAction nel seguente modo:

                  commandId="org.eclipse.ui.help.aboutAction"
                  icon="img/info.png"
                  id="hrpm.rcp.menu.aiuto.about"
                  label="Informazioni sull'applicazione"
                  style="push"
                  tooltip="Visualizza le informazioni di rilascio di questa applicazione">
            
         

Throw your code away....or release it as OpenSource!

Internet is full of discussions about the importance of OpenSource: OpenSource code is available for everyone, allows you to learn, depending on the license allows you to modify and adapt the software to your needs and, if the code is Free Software, it costs you almost nothing. In this post I want to point out another important reason: research activity. I don't mean what kind of research you can do with OpenSource code, but what quality of code you can produce during your research. It seems to me that almost every research activity produces code of very poor quality, and puts such code under a prototype umbrella. Most of the time, producing a prototype make researcher feeling as they must produce nothing more than a proof of concept. This is true, but leads to a very waste of resources and efforts: if the proof of concept works, before it goes to production it needs refinements and code rewriting, on the contrary if the proof of concept does not work, well, it must be rewritten. Since the proof of concept (the prototype) is kept private and usually does not get out of the laboratory bounds, it is allowed to be a mess of code. Once the code will be distributed outside the laboratory, it will become more and more beauty and clean. Staying confined within research lab boundaries means that the prototype does not have users. This also means that the XP paradigm cannot be applied, or it does not make sense to apply it: there is no need to release often, there is no need to keep the code clean and the repository always stable (or at least filled with code that does not have compile errors).

Why and how OpenSource can help researchers producing good quality code? First of all, releasing a project or a prototype publicly means you could have users, and users can help you (or bother you) to find problems, suggest patches, and sometimes can make some work on your behalf. Most notably, releasing the code means you have to keep it documented, keep it clean and at least easy to compile and run. Releasing a product as OpenSource means you are subscribing a contract between you and (possible) users, and you are asked to keep the project on the rails. This does not mean you have to lead the project forever, but means that the project can live forever, surviviving problems.

So why does not researcher release OpenSource code? Well, most of them do, but a lot of project dies behind a laboratory walls. The main reason is that researches are afraid someone else can steal their brilliant ideas having access to their implementation. This lies two problems:

1. the idea should be a model, not an implementation. The implementation is language and architecture dependent, and evvery good developer can do it;
2. researches do not know OpenSource licenses, that can protected and guard their work and ideas.

Just as an example: I started studying and working on JikesRVM before version 2, when it was not a full OpenSource project. At that time the code was really undocumented, organized in a single directory (for code cleanup issues) and it was difficult to get internal details without digging the code. Now, that the project is hosted as OpenSource, its code structure is well organized, the documentation can really help new users and the list of contributors and users has grown as well as the list of features. As a counter-example, I worked in a research project about Ambient Intelligence called LAICA. In such project I have seen a lot of commercial partners producing very low quality code, and the reason I perceived was the whole project had has to be a proof of concept, and in the case it was proved to be good, other funds would have been available to support its production-rewriting.

So, when you are starting a new research project, ask yourself if you can release at least a part of it as OpenSource, and in the case, do it. I believe it's really worthing.

SWT.FULL_SELECTION: momenti di panico nella migrazione di un prodotto

Le tabelle SWT hanno un comportamento abbastanza curioso: di default su piattaforma Linux consentono la selezione di una tupla cliccando su uno qualunque degli elementi visualizzati, mentre su piattaforma Microsoft Windows no. Ho scoperto questo dopo aver migrato un prodotto da Linux a Windows: all'avvio del programma su Windows tutto sembrava regolare, fino a quando non mi sono accorto di essere incapace di selezionare qualunque tupla di una qualunque tabella. Dopo vari esperimenti, aggiornamenti di JVM, ri-esportazione del prodotto, clean dell'intero progetto, il panico ha iniziato a prendere il sopravvento. Poi per caso ho scoperto di riuscire a selezionare la prima cella di ogni riga, e che quello corrispondeva alla selezione dell'intera riga. Avendo ripreso lucidità ho fatto qualche indagine arrivando a scoprire che esiste un particolare flag di SWT, SWT.FULL_SELECTION, che abilita la selezione di una tupla di una tabella indipendentemente dalla cella sulla quale si effettua il click del mouse.

Comportamento abbastanza bizzarro!

Delta pack per Eclipse 3.5.x

Eclipse RCP consente la creazione di applicazioni Java con un launcher nativo per un determinato sistema operativo. Tuttavia, anche nella sua versione Plugin-Development l'IDE Eclipse viene distribuito con il solo launcher per la propria piattaforma. Questo limita l'esportazione di un prodotto ad un solo sistema operativo, a meno che non si installi il Delta Pack con i launcher per gli altri sistemi operativi.

Nella versione di Eclipse 3.5.1 (e immagino in tutte le versioni del ramo 3.5) l'installazione del Delta Pack è differente dalle precedenti release. Anzitutto occorre scaricare il delta pack appropriato dal sito di Eclipse. Occorre fare attenzione ai numeri di versione, poiché se si scarica un delta pack errato (es. quello per la 3.5.0 quando si usa la 3.5.1) si otterranno strani (e incomprensibili) errori nell'esportazione del prodotto. In particolare è facile incappare in errori del tipo Cannot find plugin org.eclipse.equinox.launcher.

Il delta pack non va installato nella home di eclipse, può rimanere in un qualsiasi percorso del sistema operativo. Una volta scaricato e installato il delta pack, è sufficiente andare nelle preferenze di sistema, alla voce Plug-in Development e poi Target platform, selezionare la piattaforma attualmente in uso e cliccare su Edit.  Successivamente si deve selezionare Add e poi Directory e selezionare il percorso che contiene il delta pack estratto. Il risultato sarà il caricamento dei plugin con i launcher delle altre piattaforme (ispezionabili dal tab plugin contents) e il refresh della target platform selezionata.

Visibilità dei comandi nelle viste di Eclipse

Sto lavorando ad una applicazione RCP che include diverse viste master/slave in forma tabellare: alla selezione di una tupla su una vista master cambia l'output della vista slave. Ogni vista ha una serie di comandi che contribuiscono (sotto forma di pulsanti) alla UI e alcuni di essi, ad esempio modifica devono essere visibili solo quando esiste una selezione attiva nela vista stessa. Il problema è che usando i comandi di visibilità sulla sola selezione non nulla, si ottiene che quando si seleziona qualcosa in una qualunque vista, anche i comandi delle altre viste si attivano. Questo perché la selezione usata in una clausola with ragiona sull'intera pagina attiva, non sulla vista a cui è collegato il comando. Occorre allora forzare un test in parallelo anche sul tipo di componente attivo in quel momento, in modo da verificare che la selezione non sia nulla e il focus sia su una determinata vista. Si deve quindi mettere in AND logico il test sulla proprietà activePartId che deve essere uguale all'identificativo RCP della vista stessa.

Maggiori dettagli in questo thread del forum Eclipse.

Backup semplice con git

Utilizzo git per tutti i miei progetti importanti, e come ogni buon utente che si rispetti, tendo a non fare mai backup del mio albero dei sorgenti (se non in momenti assolutamente inutili, come le vacanze di Natale!). Ebbene git puo' semplificare la creazione di una copia di scorta live dell'albero dei sorgenti: è sufficiente creare un repository remoto da aggiornare di tanto in tanto.
Detto fatto! Sulla mia chiavetta usb ho clonato i repository che mi interessano con:

git clone /sviluppo/java/eclipseWorkspace/mioProgetto

dopodiché devo solo dare un bel

git pull origin

dalla directory della chiavetta usb che contiene i progetti da aggiornare. Così sulla mia pendrive ho sempre una copia quasi aggiornata (con tanto di storia) del mio albero dei sorgenti.