rebulator1

rev. 31 maggio 2011. Stanotte ha piovuto. I fulmini erano possenti e uno ha colpito il parafulmini sulla torre più alta… Si è mosso… ha gorgogliato…. Rebulator è alla 0.3!!! Oggi l’ho compilato sotto morphos Apro la shell e digito: “gcc rebulator3.c -noixemul -o rebulator3″ Immediatamente gcc mi segnala dei problemi di dichiarazione variabili. Da bravo caprone io metto insieme dichiarazioni e definizioni e gcc sotto aros il problema non me lo crea. Ho modificato allora il codice e ho messo prima tutte le dichiarazioni e poi a seguire tutte le inizializzazioni. Problema risolto. Diciamo ora che è un pò di tempo (almeno una settimana che non scrivo). Ho risolto un pò di problemi. Nell’ordine: 1) Ora rebulator ha un layout liquido. Cioè lo ingrandisci o rimpicciolisci quanto ti pare ma è sempre visibile. Uno degli attributi dell’oggetto window (finestra) è MUIA_Window_SizeGadget, che, come dice il nome, controlla la presenza o meno del gadget di ridimensionamento. Volevo fare la cosa figa e avevo scritto, in seno alla definizione della mia finestra la seguente riga: MUIA_Window_SizeGadget, FALSE, Come prima cosa notiamo che il secondo elemento di muia etc è un bool (cioè un tipo di dato che assume i valori FALSE E TRUE, falso e vero). Dicendo FALSE ho detto che non lo voglio. Di default (cioè di base) il gadget di ridimensionamento è settato a TRUE. Cavemann di aros-exec mi fece notare la cosa dicendo: se metti un workbench in alta risoluzione che fai? Ti cechi? Ecco fatto. Cancellata la riga e riabbiamo il rebulator ridimensionabile!!! Voglio in futuro prevedere la possibilità di aumentare la dimensione del font man mano che aumento le dimensioni della finestra. Se no cavemann si ceca lo stesso.:) 2) Ho introdotto come potete vedere delle cornicette intorno agli oggetti principali! In inglese (e mui non fa eccezione) si chiamano FRAME. L’oggetto frame è come tutti gli altri componenti dell’interfaccia MUI un gadget. Tradott da boopsi in oggetto. Quindi ha i suoi bravi attributi e i suoi bravi metodi. Quelli che ci interessano di più quali sono? Vado a vedere che non mi ricordo:D:D Partiamo con un pochetto di teoria dicendo che come molti delle classi di MUI anche la classe FRAME deriva dalla classe AREA ereditandone quindi attributi e metodi. Per la stessa e identica ragione MUI sa come definire un FRAME praticamente per ogni oggetto: basta dirgli il tipo di oggetto al quale deve “conformarsi”. Prendiamo il seguente pezzo di codice Child, VGroup,//FRAME VISORE MUIA_Frame, MUIV_Frame_Group, Child, primo= TextObject, …. End, Child, secondo= TextObject, …. End, End, Con questo pezzo di codice creo un VGROUP cioè un gruppo verticale (cioè uno sotto l’altro). Nello specifico gli oggetti saranno due: primo e secondo, due bravi textobject con le loro proprietà (…). Come vedete la seconda riga dice: MUIA_Frame, MUIV_Frame_Group, Questa è la chiave. La coppia ordinata MUIA_Frame, MUIV_Frame_Group dice: ho bisogno di un frame che faccia da “contenitore” a un gruppo. Questi due semplici tag ci permettono di ottenere un frame che avvolga totalmente un gruppo. Dei frame devo dire che inizialmente mi confondeva una cosa: MUI è molto visuale. E si scrivono i tag necessari nel posto (fisico direi) dove ce n’è bisogno. Per cui tendevo a voler mettere i tag del frame all’esterno del gruppo visto che un frame circonda il gruppo cioè ne è all’esterno. Ma se ci ragioniamo la dicitura: Child, VGroup, … End, Alla fine è un insieme di macro (“abbreviazioni”) di una serie di tag che servono a creare un gruppo di oggetti. Nello specifico VGroup è l’abbreviazione di MUI_NewObject(MUIC_Group, dove la virgola finale sta a indicare che MUI si aspetta altri tag che caratterizzino il nostro gruppo (vale per qualsiasi oggetto non solo i gruppi). Quindi è più che logico che io il frame lo crei dopo l’apertura del gruppo! Tanto per dirne un’altra l’HGroup (che è il gruppo orizzontale cioè oggetti in sequenza sulla stessa riga) è l’abbreviazione di: MUI_NewObject(MUIC_Group,MUIA_Group_Horiz,TRUE Cioè un gruppo normalissimo, con in più l’attributo MUIA_Group_Horiz settato a TRUE cioè VERO. Le abbreviazioni in mui sono spesso presenti e “spesso” ci semplificano la vita. Un’altra caratteristica utile dei frame di gruppo (parliamo sempre della cornice che circonda un gruppo di oggetti) è la possibilità di avere un titolo! Si, proprio un titolo: Hmmmm… immaginiamoci un programma di contabilità (che fantasia!!)! Una finestra ci chiede di inserire i vari dati di un cliente. Potremmo distinguere le varie tipologie di dati separando i gadget in vari frame e nominando i vari frame con dei titoli: “dati anagrafici”, “ordini”, “bilancio” e così via. Quella del titolo del frame è una piccolezza ma molto utile per l’ordine a video. Come impostare il titolo di un frame? Semplicemente, al solito avremo una coppia ordinata attributo-valore: MUIA_Frame_Title, “si si si un bel titolo qui”, Come si vede i frame sono una figata immensa. P.s. se andate a vedere il sorgente di rebulator si possono inserire più frame innestati l’un dentro l’altro. 3) Ora i tasti di rebulator non sono attivabili solo da mouse. Come spiegavo più giù sono dovuto passare dai simplebutton() ai TextObject. Entriamo un pò di più nel dettaglio. Più volte ho parlato di macro, define, sostituzioni e abbreviazioni. Per chi programma un pò in c si sa che è usanza di andare a scrivere il programma polpacchioso in uno o più file sorgente (source file) aventi estensione .c (cpp per gli adoratori di stroustrup ma sono dei pervertiti quindi lasciamoli stare :D) e “l’anima leggera” le dichiarazioni di costanti, funzioni e direttive varie all’interno di uno o più file intestazione (header file) aventi estensione .h (pare che gli adoratori di stroustrup non abbiano trovato di meglio qui). E’nel nostro file h che spesso si trovano appunto le macro. Senza riscoprire la ruota in c esiste un’istruzione detta di “preprocessore” a nome “define”, meglio ancora #define. Uno dei vari usi di #define (non l’uso) è quello di sostituire un “nome” a una serie di istruzioni o valori. Esempioooooooooooo: #define PIGRECO 3.14 #define moltiplicazione(x) x*x #define SimpleButton(label) MUI_MakeObject(MUIO_Button,label) -Nel primo caso sto istruendo il compilatore con il fatto che ogni qualvolta lui trovi scritto PIGRECO lui sostituisca il valore 3.14, così che se scrivo una cosa tipo x+PIGRECO il compilatore sa che invece deve operare come x+3.14; Questo primo caso è quello cosiddetto della costante simbolica perchè abbiamo creato una costante (3.14) dandogli un nome (PIGRECO). PS non provate ad assegnare valori che il compilatore vi picchia. E’una costante non una variabile. - Nel secondo e terzo caso invece andiamo a sostituire a un nome (o a un’espressione) un’ulteriore espressione. Ecco cos’è una macro! MACRO(CIOE’GROSSA, CICCIOTTA) OPERAZIONE! In pratica scrivo Simplebutton(“ciao”) e lui crea un casino creandomi un oggetto MUI basato su di un oggetto “prefabbricato” (arriveremo pure a questo. ci sono malati mentali che creano le macro di macro, credetemi… ma per ora non distraiamoci) MUIO_Button con titolo label. Molto più semplice no? Provare per credere. Idem per l’operazione. In pratica con define quindi vado a creare delle vere e proprie funzioni o comunque a semplificare la vita con le costanti simboliche di chi programma. Ma tutto questo ha un prezzo… Il simplebutton è semplicissimo da usare: lo scopo delle macro in mui è proprio quello. Mascherare la complessità. Ma contemporaneamente non si ha controllo completo su quello che si fa. Ho dovuto abbandonare simplebutton e alcune (non tutte. non sono masochista) macro nel momento in cui ho capito che con simplebutton non avrei potuto: 1) modificare a piacimento le dimensioni dei pulsanti. 2) modificare a piacimento (di conseguenza) il layout di rebulator 3) non poter usare i comandi da tastiera per i pulsanti (ad esempio usare il tastierino numerico per eseguire i calcoli della calcolatrice). Sono dovuto quindi tornare agli oggetti (non inteso come programmazione) ma inteso come oggetti fisici, come gadget con tutte le loro brave funzioni. Senza sconti. Chi ha scaricato o ha visto una delle ultime versioni di rebulator ha notato un pò di cose rispetto alle versioni precedenti (con tutti i pulsanti uguali): - i pulsanti + e = sono alti il doppio rispetto agli altri; - i pulsanti di gestione della memoria sono molto più schiacciati e larghi; - i pulsanti della terza fila sono molto più stretti rispetto agli altri; - se si prova a modificare le dimensioni della finestra di rebulator vengono mantenute le proporzioni del layout base. Ora noi sappiamo che per programmare l’aspetto di MUI bisogna intervenire sui tag (cioè sugli attributi) dei singoli elementi che compongono l’interfaccia. E gli oggetti con macro di loro sono già dei pacchetti “intoccabili”. Sono un tutto incluso invariabile. Ora noi sappiamo (non è vero lo sto dicendo ora) che gli oggetti pulsante altro non sono che degli oggetti “text” con delle caratteristiche particolari. Ho mentito prima. Devo parlare di programmazione orientata agli oggetti (oop). Ma giuro che mi mantengo a un livello teorico. Odio la programmazione orientata agli oggetti. Allora… L’elemento base dell’oop è la CLASSE. La classe in oop è la rappresentazione, il modello, l’astrazione di un concetto. Esempio: qui ho il mio gatto. Voglio astrarre il concetto di gatto e quindi creare “la gattità”, cioè l’insieme di tutte quelle proprietà ed attività che rendono tale un gatto. Nel momento in cui avrò fatto questo avrò creato “la classe gatto”. Ora il mio gatto a parte dormire perchè oggi piove, di solito mangia e spesso miagola. E queste sono le attività (in oop quelli bravi le chiamano “metodi”). Le caratteristiche, le proprietà invece quali sono?? 1) le vibrisse 2) le orecchie a punta 3) la coda flessuosa 4) le zampe con le unghie retrattili. Ecco, molto approssimativamente questo è un gatto. “la classe gatto” composto quindi di una serie di attributi (le proprietà) e i metodi (le funzioni). E gli oggetti? L’oggetto è un’istanziazione della classe. Che vorrà dire? Semplicemente: la classe gatto riunisce in sè le caratteristiche di cui prima, ma quel gatto particolare, quello con il pelo a strisce che non mangia cibo secco e che rompe se mi metto sul letto senza di lui e che risponde al nome di Pachino, ecco, quello è un oggetto. “Un particolare gatto” quello è l’oggetto della classe gatto. Ma, se riflettiamo, anche il cane mangia e dorme, solo che non miagola: abbaia. La classe cane allora ha qualcosa di simile alla classe gatto. La canità è affine alla gattità. E infatti entrambi sono animali (un’altra classe!!!). La classe animale ha allora una serie di caratteristiche comuni a tutte le classi che da essa derivano quali mangiare e dormire, poi qualcuno vola, qualcuno striscia e qualcuno corre. Se ci riflettiamo quest’attività di classificazione è qualcosa a noi di naturale: è ciò che facciamo in ogni branca di lavoro o scibile. Ritornando alla oop: dicevamo che esiste una classe animale che ha in sè delle proprietà e dei metodi base (mangiare, dormire, massa, volume). Questi proprietà e metodi base vengono “ereditati” dalle classi “derivate” e talvolta vengono “adattate” alla singola classe. E’chiaramente differente il “mangiare” del gatto rispetto a una sanguisuga. Ma entrambi mangiano. Sintetizzando possiamo dire allora che in oops: Da una classe base (superclasse) possiamo derivare una o più classi (derivate) che conservano le proprietà e i metodi della classe base (ereditarietà). Ritorniamo a MUI così capiamo pure un pò di cose. Prima di tutto vi invito a visionare l’insieme di tutte le classi di MUI http://http://www.sasg.com/mui/autodocs/index.html#idx_Area C’è una lista di tante belle cosette che significano poco. Al massimo potrebbero essere le fermate della metro o gli svincoli della tangenziale. Scherzi a parte, iniziando a leggere dall’alto verso il basso avremo il primo elemento “rootclass” che è la “Classe radice” superclasse delle superclassi dell’universo MUI. Se ho capito bene non è una vera classe ma uno stratagemma che stuntz (il creatore di MUI) usa per collegarsi a BOOPSI. http://http://en.wikipedia.org/wiki/BOOPSI La prima vera superclasse è NOTIFY dalla quale discendono praticamente tutte le altre (se vedete il grafico semaphore è a parte). Dire che tutte (o quasi) discendono da notify significa che tutte le classi derivate da notify ne erediteranno metodi e proprietà. Facciamo un bel click su notify. Si apre la pagina della guida relativa a questa classe: si inizia con una breve descrizione della stessa e poi un insieme di attributi (iniziano sempre con MUIA) e metodi (cioè funzioni proprie di quella classe e iniziano sempre con MUIM). Questi metodi e attributi, magia dell’ereditarietà saranno fruibili anche da tutte le classi derivate! Ma cosa centra tutto questo col nostro bravo pulsante? Ecco qua! Child, button_memr=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, MUIA_Text_HiChar, ‘r’, MUIA_ControlChar, ‘r’, MUIA_Text_Contents, “MR”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 1, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Ecco cosa centra! Abbiamo detto che un oggetto pulsante è in realtà un oggetto della classe text con alcune particolarità. Vi invito ad aprire quihttp://http://www.sasg.com/mui/autodocs/MUI_Text.html E’la pagina di documentazione della classe text. Se ci fate caso i tre quarti degli attributi che ho scritto sopra non ci sono nella classe text! Alla classe text degli attributi che ho scritto su appartengono solo: MUIA_Text_HiChar, MUIA_ControlChar, MUIA_Text_Contents, MUIA_Text_PreParse, MUIA_Text_SetVMax. E il resto? Da dove sono usciti? Semplice! Guardando un pò la documentazione in linea di MUI scopriremo che gli altri attributi appartengono alle superclassi dalle quali la classe text è stata derivata! Quindi volendo sempre rimanere a un livello terra terra, io posso usare tutti gli attributi (e i metodi) che sono stati scritti per la mia classe e per quelle dalle quali questa deriva! Volendo chiamare le cose col loro nome: MUIA_Font, CLASSE AREA MUIA_Text_HiChar, CLASSE TEXT MUIA_ControlChar, CLASSE TEXT MUIA_Text_Contents, CLASSE TEXT MUIA_Text_PreParse, CLASSE TEXT MUIA_InputMode, CLASSE AREA MUIA_Background, CLASSE AREA MUIA_CycleChain, CLASSE AREA MUIA_Text_SetVMax, CLASSE TEXT MUIA_InnerBottom, CLASSE AREA MUIA_InnerTop, CLASSE AREA //MUIA_FixHeightTxt, CLASSE AREA //MUIA_FixWidth, CLASSE AREA //MUIA_VertWeight, CLASSE AREA Come vedete abbiamo quindi usato nel nostro pulsante non solo gli attributi della classe text ma anche quelli della classe area che è uno dei genitori di text. Questo in MUI vale sempre. Potete usare e sperimentare gli attributi delle superclassi nelle derivate e vedere che succede! Qualcuno giustamente avrà notato una cosa: ma TextObject e ButtonFrame ma da dove escono? Non sono descritti da nessuna parte. Da dove li prendo? Poi questo che scrive ci fa due scatole lui che tutto deve avere il prefisso MUIA, MUIV, MUIC e questi non ce li hanno? Risposta: manco simplebutton aveva il prefisso MUI. Si capisce allora (a intuito e a mazzo) che ButtonFrame e TextObject, ancora una volta sono il frutto di due #define… Ma ste cacchio di define dove le trovo tutte quante? Prima rispondo e poi mi lamento: nel file mui.h contenuto in questo archivio http://http://uk.aminet.net/dev/mui/mui38dev.lha. Ora mi posso lamentare: io non sono un buon programmatore, e se scrivo questa guida è perchè così butto giù due appunti che forse sono più utili a me che a chi legge, tanto sono caotici. Ma se c’è una cosa per la quale ho sofferto, soffro e peno, se ancora scrivo questa guida è perchè in Amiga ormai manca totalmente il concetto di “documentazione”. Qualcuno si incavola? E’così. Per capire qualcosa di MUI ho buttato letteralmente il sangue quando è di una banalità assurda. Le uniche cose esistenti su questa terra sono l’ottima guida di shinkuro e l’egualmente ottimo sito di guru-meditation in francese. Per il resto è un buttamento di sangue. E se io non mi ricordavo che i programmatori c vanno a leggersi i file h “per documentarsi” io manco ci arrivavo a quel poco ove sono arrivato. E se io ho un pò di teoria e poca pratica immagino chi difetta anche di quel poco e cerca un testo, un libro che lo introduca a tutto ciò. Orbene se vi andate a leggere il file mui.h troveremo che #define ButtonFrame MUIA_Frame, MUIV_Frame_Button cioè buttonframe è una macro per costruire un frame(MUIA_Frame) di tipo MUIV_Frame_Button (MUIV sta per MUI Value). Stesso vale per TextObject: #define TextObject MUI_NewObject(MUIC_Text Per ora non ci soffermiamo molto sulle istruzioni come newobject, sappiate però che è un metodo che, come dice il nome, serve a creare un oggetto (NewObject) di un determinato tipo (nel nostro caso derivante dalla classe MUIC_Text MUIC sta per MUI Class cioè classe mui). Andiamo invece ad analizzare nel dettaglio il codice del nostro pulsante: Child, button_memr=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, MUIA_Text_HiChar, ‘r’, MUIA_ControlChar, ‘r’, MUIA_Text_Contents, “MR”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 1, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Tanto per iniziare notiamo di come, al solito, iniziamo e chiudiamo tutto con i tag Child ed End che, rispettivamente, aprono e chiudono un oggetto “figlio” del layout di MUI. Poi, abbiamo: button_memr=TextObject, in pratica dichiariamo un TextObject, il cui indirizzo è memorizzato in button_memr. button_memr è un puntatore a object che ho dichiarato precedentemente nel codice. Quando abbiamo parlato delle variabili abbiamo visto di come non sia strettamente necessario definire una variabile per un gadget ma se lo faccio, poi, posso usarlo per l’elaborazione! A seguire abbiamo ButtonFrame che, come abbiamo visto, è quella macro che circonda il nostro textobject con una bella cornicetta da “pulsante”. Se andiamo a vedere in mui.h vedremo che ci sono diversi tipi di frame predefiniti. Li elenco brevemente: #define NoFrame MUIA_Frame, MUIV_Frame_None #define ButtonFrame MUIA_Frame, MUIV_Frame_Button #define ImageButtonFrame MUIA_Frame, MUIV_Frame_ImageButton #define TextFrame MUIA_Frame, MUIV_Frame_Text #define StringFrame MUIA_Frame, MUIV_Frame_String #define ReadListFrame MUIA_Frame, MUIV_Frame_ReadList #define InputListFrame MUIA_Frame, MUIV_Frame_InputList #define PropFrame MUIA_Frame, MUIV_Frame_Prop #define SliderFrame MUIA_Frame, MUIV_Frame_Slider #define GaugeFrame MUIA_Frame, MUIV_Frame_Gauge #define VirtualFrame MUIA_Frame, MUIV_Frame_Virtual #define GroupFrame MUIA_Frame, MUIV_Frame_Group #define GroupFrameT(s) MUIA_Frame, MUIV_Frame_Group, MUIA_FrameTitle, s, MUIA_Background, MUII_GroupBack Come vediamo ce n’è per tutti i gusti e sono anche abbastanza intuitivi. Giusto a ulteriore bonus mui.h contiene anche diversi esempi di codice. Io me lo sono stampato e ogni tanto, quando ho qualche dubbio, me lo spulcio. A seguire c’è un attributo utilissimo che è MUIA_Font: serve a impostare, come si intuisce, il font per quel determinato oggetto (dico oggetto e non pulsante in virtù delle considerazioni fatte sull’ereditarietà e quindi tale attributo lo useremo anche per altri oggetti così che ogni oggetto di una finestra MUI potrebbe avere il suo font diverso!Attualmente è impostato a MUIV_Font_Button. Che è il font specifico per i pulsanti. Ciò non toglie che esistono diversi valori che possono essere usati per MUIA_Font e li troviamo bel belli nella documentazione sul sito di MUI. Ve li elenco. MUIV_Font_Inherit MUIV_Font_Normal MUIV_Font_List MUIV_Font_Tiny MUIV_Font_Fixed MUIV_Font_Title MUIV_Font_Big MUIV_Font_Button MUIV_Font_Slider MUIV_Font_Gauge Dico la verità ho usato solo il tiny, il normal e il button. Gli altri poi li andrò a usare.Provare, provare, provare. MUIA_TExt_HiChar, prendendo ad esempio il pulsante che, sappiamo, è composto di un’area cliccabile col mouse e una “label” cioè una scritta più o meno intuitiva che ci fa capire a cosa serva quel pulsante (ad esempio OK piuttosto che ANNULLA o SALVA) e l’HiChar è quel carattere, tra quelli della label, che apparirà sottolineato. Questo è solo un effetto grafico e non da effetti reali. Cmq, nel nostro caso la riga MUIA_Text_HiChar, ‘r’, fa si che il carattere r appaia sottolineato sul pulsante in questione. Ovviamente ci aspetteremmo però che non sia solo un effetto grafico e che premendo r si metta in funzione quel pulsante. Questo è dato da MUIA_ControlChar. Questo attributo MUI non ha effetti grafici ma se scrivo la riga che ho scritto: MUIA_ControlChar, ‘r’, allora premendo il tasto r il pulsante in questione produrrà i suoi effetti. MUIA_Text_Contents è invece il tag che definisce la label (l’etichetta) di un pulsante. Può essere una stringa delimitata da virgolette oppure un vettore (puntatore) a char nel caso in cui vogliamo una variabile da elaborare.Ricordo qualche tempo fa di aver avuto dei problemi con un oggetto stringa risolti con dei casting (verso varchar??) o iptr? e chi si ricorda:D Appena riprendo i listati correggo. E’ possibile formattare le stringhe con le sequenze di escape. al solito rimando alla documentazione di mui ed in particolare al seguente link: http://www.sasg.com/mui/autodocs/MUI_Te … t_Contents E’arrivato il turno di MUIA_Text_PreParse. Serve a dare una formattazione alla label (centrata, sottolineata etc) senza modificare la stringa originale. Nel nostro esempio abbiamo: MUIA_Text_PreParse, “33c”, 33 è una sequenza di escape (come si dice tra quelli che parlano stretto) ed è un codice che viene applicato in fase di lettura della stringa e sua formattazione. la “c” sta per “centra”, cioè: la label del pulsante deve essere centrata. Se aggiungessi un b e quindi abbiamo 33c33b a quel punto ho due codici: il c, come già detto, per la centratura e la b per il grassetto. Alla prossima…