Tech blog

10 passi per diventare un (potenziale) programmatore Open Source

Luigi -

Avete installato GNU/Linux, lo utilizzate, ma volete andare oltre. ... Il software libero è bello anche perché c'è il codice quindi perché non approfittarne per imparare qualcosa di nuovo?



In questo howto analizzeremo in generale un caso sufficientemente specifico. L'obiettivo non è diventare dei guru della programmazione, ma raggiungere l'obiettivo conoscendo un minimo i "blocchi" che ci interessano.


(1) Motivazione

Indipendente dalle capacità tecniche, chi contribuisce al software (filosoficamente) libero o (tecnicamente) Open Source lo fa per uno o più dei seguenti motivi:
- Adattare al meglio il software alle nostre esigenze
- Interesse nel campo specifico
- Lavoro / soldi
- ...

In questo caso il motivo interessato è il primo perché "Se metto uno sfondo chiaro al Desktop di GNOME(Nautilus), i caratteri non si leggono bene".
Purtroppo questo valore non si può cambiare, neanche con un tema, perché questa informazione è proprio scritta nel codice (hardcoded). Non resta quindi che mettere mano al codice e risolverlo in qualche modo.

I colori verranno poi gestiti dall'interfaccia dei temi e a seconda della tonalità del desktop, verrà usato il viola o il giallo-verdino (che ovviamente l'utente potrà cambiare).



Ovviamente questa modifica è molto semplice da fare e non è neanche detto che venga accettata, comunque è un buon esempio giusto per iniziare.

(2) Documentazione

Prima di avventurarvi nel codice del programma, potrebbe interessarvi, almeno a grandi linee, come è stato strutturato. In questo modo eviterete di vagare in parti che non vi interessano.
In questo caso il programma è Nautilus (il file manager di GNOME) la parte interessata si chiama NautilusIconContainer

(3) Preparazione (Strumenti di sviluppo)

Per poter compilare il codice sorgente del programma interessato avete bisogno di strumenti appositi tipo gcc (compilatore C), automake, .. (in Ubuntu: build-essential) e i pacchetti "-dev" delle librerie che andrete ad utilizzare. In questo caso serve anche subversion per poter prelevare i sorgenti aggiornati.

(4) Ambiente di sviluppo

Avete bisogno di una cartella dove ospitare i sorgenti dei programmi, se si trova nella vosta $HOME non dovete avere permessi particolari.
 mkdir ~/development
In modo analogo dovete avere una cartella per i binari sperimentali che andrete a compilare
 mkdir ~/testing

(5) Sincronizzazione (Versioning Control System)

La caratteristica principale dei progetti Open Source è quella di essere in continuo sviluppo, il codice si evolve molto rapidamente e ogni programmatore coinvolto deve sincronizzarsi con il lavoro degli altri, oltre che procedere con il proprio.
Su http://svn.gnome.org/viewcvs/nautilus/trunk/ possiamo vedere molte informazioni interessanti, ma in realtà i file che andremo a prelevare sono su http://svn.gnome.org/svn/nautilus/trunk
 cd ~/development
svn co http://svn.gnome.org/svn/nautilus/trunk nautilus
Al termine dell'operazione avremo una sotto cartella nautilus con tutti i file che abbiamo visto
Per aggiornarla in futuro basterà (da dentro la cartella nautilus)
 svn up

(6) Prima compilazione

Bisogna prima controllare che nel sistema ci siano tutte le librerie e i sw necessari, inoltre viene passata la cartella dove verranno installati successivamente i binari
 cd nautilus
./autogen.sh --prefix=${HOME}/testing
Eventualmente si possono abilitare o disabilitare certe feature o librerie leggendosi
 ./autogen.sh --help
Una volta che tutto è apposto e non ci sono errori, è arrivata l'ora del fatidico
 make
..che dopo una sbrodolata di informazioni vi darà i binari, ogni volta che modificate un sorgente dovrete usare make, la differenza è che dovrebbe essere un pochino più veloce perché compilerà solo quello che è cambiato.
Infine installate il tutto (in ~/testing) con
 make install
Essendo Nautilus un po' particolare accertatevi prima di averlo tolto da gnome-session-properties o aver rinominato l'originale, altrimenti partirà sempre la versione vecchia.
 cd ~/testing/bin
./nautilus
Ecco davanti a voi, l'ultima versione disponibile (Aiuto -> Informazioni vi darà la conferma).

(7) Apportare le modifiche

Trattandosi di semplici file di testo ogni editor di testo va bene.
Cercate le funzioni che vi interessano e fate le modifiche che vi servono, dopodiché compilate e testate.
Quando siete soddisfatti potete estrarre le modifiche con
 svn diff > ../nautilus-my-super-mega-feature.patch
Nel nostro caso la patch riguarda solo un file ed è questa:
Index: libnautilus-private/nautilus-icon-container.c
===================================================================
--- libnautilus-private/nautilus-icon-container.c	(revisione 12793)
+++ libnautilus-private/nautilus-icon-container.c	(copia locale)
@@ -7250,8 +7250,15 @@
 				  LABEL_INFO_COLOR, 
 				  eel_gdk_color_is_dark (&widget->style->base[GTK_STATE_NORMAL]) 
? light_info_value : dark_info_value);
 	} else {
-		if (container->details->use_drop_shadows || eel_background_is_dark (background)) {
-			setup_gc_with_fg (container, LABEL_COLOR, 0xEFEFEF);
+		if (!eel_background_is_dark (background)) {	  
+			if (!eel_gdk_color_is_dark (&widget->style->base[GTK_STATE_NORMAL])){
+				container->details->use_drop_shadows = FALSE;
+				setup_gc_with_fg (container, LABEL_COLOR, 
+					  eel_gdk_color_to_rgb (&widget->style->text[GTK_STATE_NORMAL]));
+			} else {
+				setup_gc_with_fg (container, LABEL_COLOR, 
+					  eel_gdk_color_to_rgb (&widget->style->text[GTK_STATE_INSENSITIVE]));
+			}
 			setup_gc_with_fg (container, 
 					  LABEL_INFO_COLOR, 
 					  light_info_value);

(8) Pubblicare le modifiche

La via migliore per non far perdere nel nulla le nostre modifiche è quella di pubblicarle in un Bug Tracking System. Aprire un bug, per segnalare il problema (o nuova funzionalità), e allegare la patch.
Se siamo fortunati la patch verrà inclusa nel programma e se siamo stati anche bravi potremo chiedere, dopo un po' di patch, un account per pubblicarle direttamente nel VCS (commit).
Se volete riapplicare la vostra patch o volete provare quelle di qualcun'altro
 patch -p0 < ../another-cool-feature-or-bugfix.patch

Carino, no?

(9) Creare il pacchetto

Ogni distribuzione (o quasi) ha il suo modo di fare i pacchetti binari, ma in generale uno strumento molto utile è checkinstall. Questo software vi permette di fare un pacchetto di vari tipi senza troppi sforzi. Anche se un pacchetto di questo tipo non è considerato "a regola d'arte", per lo meno sarà di facile installazione o disinstallazione, quindi il vostro sistema rimarrà il più possibile pulito.

(10) Conclusioni e consigli per tutti i giorni

Spero di avervi incuriosito abbastanza, non compilatevi staticamente in testa i tool che ho usato, perché magari per modificare il programma che vi interessa ve ne serviranno altri; piuttosto cercate di approfondire all'occorrenza il blocco che più vi interessa (anche perché quello che è meglio oggi non è detto che lo sarà anche domani)
Vi lascio con qualche link.
Documentazione
GNU make & C.
Kde
Freedesktop
GNOME (e versione Live)

Text Editor / IDE
La scelta dipende da 3 fattori: linguaggio scelto, funzionalità e RAM che avete.
  • vi/emacs per linguaggi C-like e poca RAM
  • gedit, kate,.. multiuso
  • Eclipse(Java), Kdevelop(QT/C++), Monodevelop(C#), più specifici e con più funzionalità(integrazione svn, class browser) ma richiedono più RAM.
Versioning Control System
http://it.wikipedia.org/wiki/Controllo_versione
http://gentoo-wiki.com/HOWTO_Subversion (usato da GNOME, Kde,..) GUI
http://bazaar-vcs.org/QuickHackingWithBzr (usato da Ubuntu) GUI
http://linux.yyz.us/git-howto.html (usato da Linux) GUI
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

Dimenticavo..
Happy Hacking