continua (next page) Frasi Famose index main index

La traduzione in italiano è a metà di questa pagina.

Whooops. I found QT3 out. I got it (downloaded 16Mb at 28k8, arrrgh). It took 154 minutes of a P3/750+192Mb to compile everything. Two little bugs (I had to add "-lqt-mt" and strip executables by hand), but it runs, and gives stunning extra capabilities (QT library and QT designer), and so far I still haven't checked for all new features. Well, this article may appear obsolete. But it's too nice to leave in the oblivion directories of my huge hard disks. Here it is - just to let you have a look at the nice images in this page.
Note: after trying this QT3, I am even more convinced that KDE and QT are stunning, and better and faster than Gnome and GTK+.

A little note before beginning.

It was Ye Ancient Times when I reconfigured my home system with a new full Linux distribution, to get rid of Slackware and FVWM.

This time, I installed Gnome. Great: lots of colors, lots of windows, lots of time to wait a window to be drawn. Yawn. Then I upgraded my system to a Celeron/400 (overclocked to 500 MHz) with plenty of RAM (when 192 Mb were "plenty"), and it became decent.

But, bug after bug, "MIT-Magic-Cookie" refused and other little nasty things, I began to think "Gnome sucks". One day I searched around Internet the "Gnome sucks" string, and I found the Official Response to "Gnome sucks" sentence: Miguel de Icaza said "If you think that Gnome sucks, then you have the RedHat version installed".

Yes, it was a RedHat 6.1, and "Gnome sucks" is an approved sentence for it.

(well, I have to say that I used it for years; GNU/GPL softwares under Linux let you go to sleep without panic)

One day one of my friends told me "Try this Mandrake distribution: it's a «stable» version of RedHat". Yes, I tried it, and - dunno why - it started with KDE instead of Gnome. And it was nice and fast and clean and - persuasively - without strange bugs. I decided to "give it a try", and it's almost seven months (so far, October 2001) that I'm "trying" it without even the littlest remote desire to switch back to Gnome (a full Gnome installation is available in the Mandrake disks, but without the bunch of little problems of the "sucks" installation of RedHat. Maybe in the meantime RedHat became better...).

Yes, I still use KDE and I am very happy. It's three years and I won't switch back to Gnome. KDE just ROCKS!

KDE is built on top of TrollTech's QT, and this proves that QT is stable and efficient even more than KDE. But the story doesn't end here...

I don't use dialog editors. I had a bunch of problems a lot of years ago using the delicate Borland's one, because of the brain-damaged Wi****s environment (and also because of the dirty Borland C++ compiler bugs), and promised myself I won't ever try one: "better and faster to write by hand (and not in a W*****s environment)".

I had a quick try on a "Caldera Application Builder" some years ago. I built (after a number of tries and a number of strange errors) the classic "Hello world!" window. It gave me an 1.5 Mb executable file linked against at least 40 (forty) libraries, and it didn't run on the first tries. I promised again "I will never try another application- or dialog-builder".

Well, some days ago I found QT 2.3 Designer; I started it, and I liked its nice "splash" screen, so I decided to give it a try.

Well, it worked. Without bugs. Fast and clean, and gave nice (simple to read and edit) source files for the great rock-solid QT library. I draw a fairly complex dialog and, following the simple instructions found in the HTML pages of the manual, it compiled fine just on the first attempt, giving me a clean and little executable, that ran 100% OK on the first try (and also on all of the following).

"I must write to TrollTech guys a «You're great!» email", I said. But, when I read their point of view about callback functions, I felt a little unhappy.

Designer and QT simply don't know about callbacks. QT is built on a safer (and stabler) signal/slot scheme, pretending you to extend base classes with signal- (not the ones of /usr/include/signal.h) and slot-functions (to "receive" the above "signals").

I considered that a tool like Designer should allow an user to add a bit of code to a dialog. It would be nice to have an extra "Add C++ code" property for objects in widgets. QT Designer allows you to define your slots, but only places a stoooopid qWarning("Form1::XXX() not implemented") line in it. What about letting user (me) to write in it a couple of instructions?

Well, I think that they will tell me "wait for next major release" (if not a sad "Real Programmers Don't Use CallBacks"). And I needed a fast solution, to develop a bunch of little programs that need a well-drawn dialog and no more than a dozen of lines of code to be executed at a button press.

So I developed this Makefile to automate everything. I use this Makefile for every little QT application I need, without even changing a byte. To create a "sample" application (from now on, I assume you know at least basics of QT and Designer), the steps are:

  1. create "sample.ui" with Designer (I prefer the "Dialog" style);
  2. add to "sample.ui" the needed callbacks (oops: "slots") to the main form (leaving its name to "Form1"), and connect buttons and listviews to them;
  3. create a "sample.cpp" source with callbacks:
  4. use the Makefile of above giving the command (all in one line): APP=sample make (define APPlication name as "sample" and then immediately execute make).

Yay, this is really simple, in spite of all above notes.

Let's develop a dialog box containing a fixed listview: when the user selects (double-clicks on) a string, some C++ code applies. We don't care about OK/Cancel sequences, because OK is "double-click" and Cancel is the normal close-window command.

So we create "cdselect.ui" application dialog, with only one slot ("Suona"). In the Edit/Slots/Properties we add the "QListView*" parameter (so it will be "Suona(QListView*)" instead of "new_slot()") to get the slot "callable" from the doubleClicked function of the QListView class.

Then we create "cdselect.cpp" C++ source file with our favourite text-editor. It has to include qlistview.h because we need to fetch string from QListViewItem pointer we got in input - example: char *clickedstr=(char*)p->text(0).latin1();.

The CallBack::Suona function, after using the clickedstr of above, may even decide to call "accept()" to terminate the dialog.

Another little note: the cdselect.cpp may contain other classes, functions, #includes, etc, but if you want to build a more complex application (adding other libraries and other source files) you will need to modify the Makefile.

Well, I needed more time to explain what I did than to develop and debug (huh? debug? it went 100% OK from the first attempt!) the entire cdselect application. Let's see again the steps:

  1. create cdselect.ui using Designer;
  2. create cdselect.cpp "callback" functions;
  3. get a Makefile in the same directory;
  4. invoke make by typing: APP=cdselect make

YES, you need to create only two files: the user interface dialog with QT Designer, and the needed "non-QT" code using a text editor. The Makefile does all of the remaining work. Enjoy!

But... what exactly does the Makefile?

  1. deletes temporary source files, if they still exist;
  2. creates an app.cpp main file with CallBack class definition (that is: a Form1-derived class with public slots defined) and minimal startup code (QApplication and setMainWidget);
  3. runs MOC (QT meta object code generator) to generate MOC definitions. Note: MOC and UIC generate correct code that will be compiled without warnings (even with "-Wall" g++ option), so the only file to take care of is the hand-made "callback-functions" C++ source;
  4. runs UIC (QT user interface generator) to create the form interface header file and the dialog-building code (form implementation);
  5. creates a list of public slots (in callbackfunctions.h, included only from app.cpp) grepping "virtual" function definitions from QT UIC's form interface;
  6. compiles and links everything.

I had a great fun with it. With an unmodified Makefile, an UI file and tiny C++ source I build little KDE applications in a minute.

Well, for more examples get this tar.gz file. Again, sorry for my poor English.

Greater fun will be in the days when Designer will generate himself a Makefile and will let user to add some lines of code to widget events.

Post Scriptum.

I just tried KDevelop. Gee, it's not really that nice. Despite of its "2.0" release number, it has a number of nasty little bugs (at least, in the Mandrake 8.1 distribution RPMs). I tried to create some little programs and I got a bunch of warning messages and "not found" erros. I got finally some things running (true little KDE applications), but they needed a lot of hand-work on source files to add even a simple dialog. So, I can uninstall now KDevelop and go back again to this lovely QT Designer...!


Google
 
Web www.alfonsomartone.itb.it

(Italian translation follows...)

Oops. Ho appena rimediato QT3, con un bel download di 16Mb a 28k8 (arrgh). Si compila in appena 154 minuti su un P3/750+192Mb. Vedo un paio di piccoli bug (ho dovuto aggiungere "-lqt-mt" e strippare gli eseguibili manualmente), però funge, e lascia intravedere una marea di features in più (tanto di libreria quanto del Designer), ed ancora non l'ho visto tutto. Bah. L'articolo qui sotto può apparire obsoleto, ma era troppo carino per consegnarlo all'oblio di una directory sperduta dei miei favolosi hard disk. Eccolo qui, dunque, se non altro per farvi dare un'occhiatina alle splendide immagini di questa pagina.
N.B.: anche con QT3, confermo che KDE e QT sono di una potenza colossale, più belli e più veloci di Gnome e GTK+.

Un piccolo aneddoto prima di cominciare.

Fu nei Tempi Antichi che riconfigurai il computer di casa con una nuova distribuzione Linux, per sbarazzarmi di quella Slackware con FVWM.

Stavolta installai Gnome. Notevole: un sacco di colori, un sacco di finestre, un sacco di tempo in attesa che venissero disegnate le finestre. Finché non aggiornai il sistema ad un Celeron/400 (overclockato poi a 500 MHz) con una montagna di RAM (beh, all'epoca 192 Mb erano una "montagna") e finalmente andò a velocità decente.

Ma, bug dopo bug, "MIT-Magic-Cookie" rifiutati e altre piccole odiose cosucce, cominciai a pensare che Gnome facesse un po' schifo. Un giorno cercai su un motore di ricerca "Gnome sucks" e ne trovai il Responso Ufficiale da parte di Miguel de Icaza: diceva che "Se pensate che Gnome sia una schifezza, allora sicuramente avete la versione RedHat".

Esatto: la mia "nuova" distribuzione era una RedHat 6.1, e per quella era verissimo che Gnome è una schifezza.

(fra parentesi, devo pure ammettere che dopotutto è andata avanti per anni; con i software GNU/GPL sotto Linux si può andare a nanna abbastanza tranquilli)

Un giorno uno dei miei amici mi disse "Prova questa distribuzione Mandrake: è una versione «stabile» della RedHat". Sì, la provai e - non so esattamente perché - la feci partire col KDE invece che con Gnome. Ed era simpatica e veloce e pulita e - persuasivamente - senza strani bug. Così, decidendo di "fare comunque qualche prova", mi ritrovo che sono quasi sette mesi (e siamo a ottobre 2001) che lo sto "provando" senza neppure la più piccola tentazione di tornare a Gnome (che pure è disponibile su questa Mandrake senza i tremila problemini e problemucci della RedHat. Magari, però, la RedHat nel frattempo ha migliorato...).

KDE è basato sul QT della TrollTech, e questo dimostra perlomeno che QT è stabile ed efficiente più dello stesso KDE. Ma la storia non finisce qui...

Io semplicemente odio i dialog editor. Ebbi una carretta di problemi un sacco di anni fa usando quello delicatissimo della Borland (ma fu soprattutto a causa dell'ambiente scervellatissimo Wi****s, oltre che degli sporchi bug del compilatore Borland C++), e mi promisi che non ne avrei mai più usato e nemmeno provato uno: "meglio scrivermeli a mano, si fa più presto (e meglio non scriverli sotto W*****s)".

Una volta però provai rapidamente un "Caldera Application Builder", qualche annetto fa. Misi su (dopo un po' di tentativi e diversi strani errori) la classica finestra "Hello world!". Ne ebbi uno spaventoso eseguibile di 1,5 Mb linkato ad almeno una quarantina di librerie (non scherzo!), e non funzionò subito ai primissimi tentativi. Mi ripromisi di nuovo che non avrei mai tentato un altro application- o dialog-builder.

Bene, pochi giorni fa ho trovato il QT 2.3 Designer; l'ho lanciato, e mi è piaciuto lo "splash-screen" iniziale, e (viva la coerenza!) ho deciso di provarlo "per non più di un minutino".

Incredibile: funziona. Senza bug. Veloce e pulito, e tira fuori interessanti listati (facili da leggere e modificare) per quella libreria QT già notoriamente solida come una roccia. Ho disegnato un dialog alquanto complesso e, seguendo le semplici istruzioni trovate nelle pagine HTML del manuale, l'ho compilato senza errori al primo colpo, ottenendo un piccolo eseguibile che è andato bene al primo tentativo (nonché tutti i tentativi seguenti).

"Devo mandare una email a quelli della TrollTech per dire loro «Siete grandi!»", mi son detto. Ma quando sfogliando la documentazione sopracitata ho letto del loro punto di vista sulle funzioni callback, mi sono raffreddaton un po'.

Il Designer e le QT stesse semplicemente non conoscono callbacks. QT è costruita su un sistema a segnali e slot che è decisamente pù sicuro e stabile, ma pretende che ognuno si estenda le classi base con nuovi "segnali" (non sto parlando di quelli di /usr/include/signal.h) e "slots" riceventi detti "segnali" (segnali e slot sono member functions)

Ho pensato che un tool come Designer dovrebbe permettere all'utente di aggiungere qualche riga di codice in un dialogo. Sarebbe simpatico avere una proprietà "Aggiungi codice C++" per gli oggetti nei widgets. Designer permette di definire dei propri slot, ma ci piazza dentro solo una stupidissima e inutilissima riga di codice ("qWarning("Form1::XXX() not implemented")).

E allora, come permettere all'utente (cioè a me) di scriverci dentro un paio di istruzioni?

Beh, ho pensato che quelli di TrollTech mi avrebbero risposto "attenda la prossima major release" (nel migliore dei casi! perché può andare anche peggio: "i Veri Programmatori NON Usano CallBacks"). Ed io avevo bisogno rapidamente di una soluzione per sviluppare un cumulo di programmini che hanno bisogno solo di un dialog disegnato bene e non più di una dozzina di righe di codice associate alla pressione di un bottone...

Così, ho sviluppato questo Makefile per automatizzare tutto il lavoro. Uso questo stesso Makefile per ogni piccola applicazione basata su QT, senza cambiarne neppure un byte. Per esempio, per creare un'applicazione dal nome "sample" (da qui in poi assumo che abbiate almeno un minimo di conoscenza di QT e del Designer), i passi da seguire sono:

  1. creare "sample.ui" col Designer (personalmente preferisco lo stile "Dialog");
  2. aggiungere a "sample.ui" i callback (oops: "slot") necessari nel form principale (lasciando il nome fisso a "Form1"), e connettervi i bottoni e le listview necessarie;
  3. creare con un text-editor un file "sample.cpp" con i callback:
  4. usare il Makefile sopra segnalato digitando il comando (tutto in una sola riga): APP=sample make (cioè: APPlicazione è "sample", e quindi esegui subito make).

Beh, è assai più semplice di quanto non possano far sembrare le note di poche righe fa.

Sviluppiamo per prova un dialog contenente una listview, cioè un elenco di stringhe: quando l'utente ne seleziona una (col doppio click), viene eseguito del codice C++ in funzione di quella stringa. Siamo esonerati da sequenze OK/Cancel, perché l'OK corrisponde al doppio click e Cancel non farebbe altro che chiudere la finestra.

Dunque creiamo il dialog "cdselect.ui" col Designer, con un solo slot ("Suona"). In Edit/Slots/Properties aggiungiamo il parametro "QListView*" (cioè, ci serve "Suona(QListView*)" invece di "new_slot()") affinché lo slot sia "chiamabile" dalla funzione doubleClicked della classe QListView.

Quindi creiamo il file sorgente C++ "cdselect.cpp" col nostro text-editor preferito. Deve #includere il file qlistview.h perché abbiamo bisogno di recuperare la stringa cliccata dal QListViewItem passatoci come parametro - per esempio: char *clickedstr=(char*)p->text(0).latin1();.

La funzione CallBack::Suona, dopo aver usato la clickedstr di cui sopra, può perfino decidere se chiamare la "accept()" per terminare il dialog (e dunque il programma).

Altro piccolo suggerimento: la cdselect.cpp può contenere altre classi, funzioni, "#include", etc, ma per costruire un'applicazione più complessa (aggiungendo altre librerie e altri file sorgenti) c'è bisogno di modificare il Makefile.

Beh, ci ho messo più tempo per spiegare come ho fatto che non per sviluppare e fare debugging (huh? debugging? è filato tutto liscio fin dal primo tentativo!) dell'intera applicazione cdselect. Rivediamo un attimo gli steps:

  1. creare cdselect.ui col Designer;
  2. creare cdselect.cpp con le funzioni "callback";
  3. piazzare il Makefile nella stessa directory;
  4. invocare make col comando: APP=cdselect make

Esatto, c'è bisogno di creare solo due files: il dialog col Designer e le funzioni C++ "non QT" con un text-editor. Il Makefile fa tutto il resto del lavoro. Che delizia!

Ma... cos'è che fa esattamente il Makefile?

  1. cancella i file sorgenti temporanei, se ne esistono;
  2. crea il sorgente principale app.cpp con la definizione della classe CallBack (cioè: una classe derivata da Form1 con in più le definizioni dei public slots, alias dei nostri "callback") e un minimo di codice di startup (QApplication e setMainWidget);
  3. esegue MOC (QT meta object code generator) per generare le definizioni MOC. Nota bene: MOC e UIC generano codice compilabile senza warning (perfino con l'opzione "-Wall" del g++), cosicché l'unico file di cui ci si deve preoccupare è quello delle "callback functions" fatte a mano in C++;
  4. esegue UIC (QT user interface generator) per creare l'interface header file del form ed il dialog-building code ("form implementation");
  5. crea una breve lista dei public slots (in callbackfunctions.h, incluso solo da app.cpp) recuperando col grep le linee con le definizioni di funzioni "virtual" dall'interface header;
  6. compila e linka tutto.

Mi sono divertito proprio un mondo. Con un Makefile già pronto (e che non necessita di modifiche), un file UI ed un minuscolo sorgente C++ posso metter su piccole applicazioni KDE in un minuto.

Beh, per qualche esempio in più, prendi questo file tar.gz file.

Un giorno ci sarà parecchio da divertirsi, quando i tizi della TrollTech si decideranno a implementare nel Designer la generazione automatica dei Makefile e la possibilità di associare un po' di codice direttamente sugli eventi degli oggetti QT.

Post Scriptum.

Certo, è ovvio, ho provato anche KDevelop. Beh, non è proprio tanto carino. A dispetto di essere in versione "2.0", ha un bel numero di piccoli odiosi bugs (o almeno, ce li ha nella versione distribuita dalla Mandrake 8.1). Ho provato a creare alcuni programmini e, dopo un buon numero di warning e qualche errore "not found", finalmente ottengo una vera piccola applicazione KDE. Ma c'è stato bisogno di un sacco di lavoro, perfino per la semplice aggiunta di un dialog. Insomma, posso tranquillamente disinstallare il KDevelop e tornare felicemente a lavorare con questo delizioso QT Designer...!



Subiaco

send e-mail - continua (next page)