rebulator3

MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, Gli ultimi 6 elementi riguardano tutti la “spaziatura” e il layout dell’oggetto bottone che rebulator implementa. Gli ultimi 3 in particolare sono commentati visto che alla fine non li ho usati. La mia esigenza era quella di creare per rebulator dei pulsanti che non avessero necessariamente tutti la stessa dimensione o lo stesso aspetto. MUI di suo tende a dividere lo spazio della finestra in oggetti di egual dimensione o comunque ad accomodare in maniera armonica gli oggetti su di essa. Non sempre però è ciò che si vuole: sulle calcolatrici il pulsante + o il pulsante = di solito sono più grandi degli altri così come il modello di rebulator, che è una calcolatrice cinese da tre soldi, ha i pulsanti della gestione memoria più piccoli rispetto agli altri. Come ottenere quindi pulsanti di dimensioni diverse pur rimanendo nell’ambito di un layout omogeneo? Le strade sono varie: creare gruppi ad hoc (ricordo che MUI permette di creare dei frame l’un dentro l’altro così da creare delle gabbie di oggetti ma non mi piace come cosa), così come giocare sugli attributi. Quelli presenti nelle righe che vedremo permettono un bel pò di personalizzazioni in merito: 1) MUIA_Text_SetVMax (BOOLEANO) Derivato dalla classe TEXT, è un attributo che stabilisce in un oggetto se l’altezza massima dello stesso sia limitata all’altezza del testo in essa contenuto. In pratica l’oggetto non potrebbe mai espandersi verticalmente se questo attributo avesse come valore TRUE In rebulator è settato a FALSE perchè Rebulator ha un layout liquido (non so manco cosa significhi lontanamente ma una volta in metro c’erano due fanatici di css che parlavano solo di questo così ho deciso che un giorno oltre a trovare indastria e liberare lana avrei creato qualcosa con un layout liquido): se si allarga la finestra anche i suoi pulsanti si devono allargare o allungare di conseguenza. Una delle prossime cose che studierò sarà come ingrandire i font in tempo reale. 2) MUIA_InnerBottom Definisce, in pixel, lo spazio che il sistema deve lasciare dal “bottom” cioè dalla base del testo alla cornice. Settandolo a 0 gli ho detto che non voglio pixel tra la base del testo e la cornice. Mi serviva per i tasti memoria per “schiacciarli” in altezza il più possibile 3) MUIA_InnerTop Idem come inner bottom. Solo che lo spazio stavolta è quello riservato sopra il testo. Settando a 0 questo attributo dico a MUI che non voglio spazio di pixel tra il testo e la cornice. 4) MUIA_FixHeightTxt E’commentato dunque non è attivo in rebulator. E’ un attributo che dice a MUI che l’altezza di quel determinato oggetto (height) debba essere fissata (fix) all’altezza del testo che gli si passa come valore (in questo caso MR). Utile per limitare l’altezza. Credo faccia a cazzotti con MUIA_Text_SetVMax, FALSE. 5) MUIA_FixWidth Anch’esso commentato. Attributo che riceve come valore il numero di pixel il cui valore rappresenta la larghezza dell’oggetto. Utile per delimitare la larghezza 6) MUIA_VertWeight Un argomento particolarmente interessante e importante di MUI sono i “pesi”. Dicevo che MUI cerca di organizzare il layout in maniera armonica. Come dice il termine, dando quindi a tutti gli oggetti un “peso” uguale o quantomeno quel giusto tot. Il peso di un oggetto è il meccanismo invece che MUI usa per alterare questo equilibrio. Il peso di un oggetto, inteso come spazio (verticale o orizzontale o entrambi) che l’oggetto deve occupare rispetto a ciò che normalmente gli sarebbe concesso in funzione del numero e tipo di oggetti presenti nel suo gruppo, è definito in “percentuale”. Se un oggetto deve occupare più del suo normale spazio avrà quindi un valore di attributo superiore a 100. Viceversa se ne deve occupare di meno sarà inferiore a 100. Un valore pari a 0 (laddove non produca dei bei crash di sistema:p) indica a MUI che l’oggetto deve occupare “sempre” il minimo dello spazio consentito. Ora gli attributi che si occupano di gestire il peso di un oggetto MUI sono 3: - MUiA_Weight: gestisce il peso dell’oggetto sia in verticale che in orizzontale. Esempio: MUIA_Weight, 300, significa che l’oggetto (in verticale e in orizzontale) occuperà il 300% del normale spazio. - MUIA_VertWeight: come prima ma regola solo il “peso” verticale (quindi lo spazio in altezza) dell’oggetto. - MUIA_HorizWeight: idem. Solo che abbiamo a che fare con il peso orizzontale. Perchè avevo messo tutto a 0? Semplicemente perchè volevo che i pulsanti di gestione memoria non fossero “armonici” ma fossero schiacciati. edit: ho l’impressione che il tipo di mui fosse abruzzese. questo mette in crisi diverse teorie Arriviamo adesso alle cose interessanti! Non che le altre cose non lo siano ma queste lo sono particolarmente. Precedentemente avevamo detto che in MUI un oggetto pulsante vero e proprio non esiste bensì esso altro non è che un oggetto derivato dalla classe AREA. Non l’avevamo detto? L’ho detto ora:D Cosa rende un pulsante tale? Una bella area (manco a farlo apposta) che se la clicco (di solito col pulsante sinistro del mouse) succede un qualcosa. MUI utilizza due attributi booleani (i primi due) e un attributo intero (con funzione di temporizzatore) per la gestione del pulsante sinistro del mouse nell’ambito della classe Area: 1) MUIA_Selected: è quell’attributo (vero o falso) dell’oggetto che ha a che fare con la sua selezione. 2) MUIA_Pressed: è quell’attributo (vero o falso) il cui valore ha a che fare con la pressione (o meno) del pulsante sinistro del mouse sull’oggetto 3) MUIA_Timer: è un temporizzatore che memorizza da quanto tempo il pulsante sinistro del mouse è premuto su un gadget bottone. Ora, la classe area ha nell’attributo MUIA_InputMode un importante strumento per definire il comportamento dei gadget BOTTONI et similia (non i bottoni del mouse proprio i gadget delle finestre. Tra bottoni, pulsanti e oggetti ci si confonde:P) In pratica gestisce, come suggerisce il nome, il comportamento di un oggetto di fronte all’input e (nello specifico) rispetto alla pressione del pulsante sinistro del mouse. Entrando più nel dettaglio MUIA_InputMode ha quattro possibili valori: MUIV_InputMode_None, MUIV_InputMode_Relverify, MUIV_InputMode_Immediate e MUIV_InputMode_Toggle. Ma che relazione hanno i valori di MUIA_InputMode e gli attributi sopra visti? Semplicemente, scegliendo uno dei valori di MUIA_InputMode, sceglieremo anche come il nostro oggetto si regolerà rispetto agli attributi MUIA_Selected, MUIA_Pressed e MUIA_Timer. Vediamo come: 1)MUIV_InputMode_None: come dice il none (non è abruzzese è inglese e significa nessuno) l’oggetto in questione non risponde agli input e quindi se ne frega alla grande di MUIA_Selected, MUIA_Pressed e MUIA_Timer 2) MUIV_InputMode_RelVerify: è il valore di default per i bottoni. - MUIA_Selected (ricordiamo che è un bool): vero quando il pulsante sx viene premuto su esso falso quando il pulsante sx viene rilasciato falso quando il gadget è selezionato ma il mouse esce dall’area dell’oggetto vero quando il mouse rientra nell’area dell’oggetto. In pratica definendo MUIV_InputMode_RelVerify come valore di MUIA_InputMode avremo scelto di associare all’oggetto in questione questi comportamenti. - MUIA_Pressed vero quando il pulsante sx viene premuto su esso (come MUIA_Selected: ovviamente se premo il pulsante sinistro lo sto anche selezionando) falso quando lascio il pulsante sx. Qui si aprono due strade: –se il mouse è ancora sull’oggetto si scatena una notifica. –se il mouse non è sull’oggetto all’atto del rilascio non si scatena una notifica. Perchè si scatena una notifica quando lascio il pulsante sinistro del mouse se il puntatore è ancora sull’oggetto? Beh, fateci caso. Quando premete il pulsante del mouse su un bottone non succede un bel niente. E’quando lo rilasciate che succede qualcosa. PRovare per credere!!:))) - MUIA_Timer: attributo long, come dicevamo si tratta di un temporizzatore che entra in funzione dopo che un bottone RelVerify è stato premuto e tiene conto del tempo di pressione del pulsante sx. Non l’ho ancora usato e quindi è da approfondire. 3)MUIV_InputMode_Immediate: è il valore che ha a che fare con i radio button e altri oggetti che, come dice il nome, hanno una reazione immediata alla pressione del mouse. Proprio a causa di questo suo modo di essere l’attributo MUIA_PRessed non è definito MUIA_Selected: si scatena non appena il pulsante sx viene premuto sull’oggetto 4)MUIV_InputMode_Toggle: è il valore degli oggetti come i check (toggle tradotto letteralmente significa togli e se volete ciò che si fa con i check è proprio togliere e metter quella benedetta x nella casellina) Anche qui MUIA_Pressed non ha senso. MUIA_Selected invece diventa falso quando si preme il pulsante sx del mouse (al contrario di MUIV_Input_Immediate). Ricordo sempre che con get e set c’è la possibilità di leggere e scrivere questi valori negli oggetti così da “forzare” la mano laddove necessario o reperire gli stessi! Ritorniamo alle decorazioni: Continuando nella descrizione del nostro pulsante, incontriamo la coppia attributo-valore MUIA_Background, MUII_ButtonBack, Come possiamo immaginare MUIA_Background è quell’attributo MUI che gestisce lo sfondo (background) di un oggetto. Lo sfondo di un oggetto è normalmente un’immagine e il nostro sfondo non fa eccezzione: il valore infatti è MUII_ButtonBack. Ricordiamo che MUII sta per MUI Image, cioè Immagine Mui. Valore che in questo caso è guarda caso ButtonBack, cioè sfondo per i bottoni. MUIA_Background assume diversi valori tutti da provare e vi rimando alla documentazione MUI a riguardo. Carina come cosa è quella di provare varie immagini per vari tipi di oggetto: siamo nell’ambito delle decorazioni e allora perchè non provare a cambiare? Se la vocina nel cervello vi dice: “per non confondere le cose!” Non ascoltatela! Provate provate provate. E poi fatemi sapere. Mi incuriosisce quello shine back.:p Alzi la mano chi ritiene il mouse senza tastiera utile. Il mouse senza tastiera è meno utile della tastiera senza mouse. Sono in vena di frasi massime quindi passatemela. Devo presentarvi MUIA_CycleChain, 1, e sono quindi giustificato. Chi ha usato windows almeno una volta nella sua vita sa che per passare da un oggetto all’altro basta premere il tasto TAB. Se questa cosa non la sapete è perchè non avete manco acceso mai il vostro computer. Bene, sotto amiga per ottenere lo stesso effetto si batte il tasto INVIO. La sequenza di tutti gli oggetti cui si passa dall’uno all’altro tramite INVIO (o tab sotto amiga), si chiama Cycle Chain, cioè catena ciclica. Questo perchè arrivati all’ultimo oggetto della catena (tab tab tab oppure invio invio invio, ricordo che dovete aver acceso il computer) si ricomincia dal primo oggetto. Per far si che un oggetto entri nella cycle chain bisogna settare l’attributo MUIA_CycleChain a 1. Questo da manuale: da mia esperienza pratica deve essere un qualsiasi intero positivo. Il numero che ci mettete indica la posizione nella catena. Ovviamente 1 viene prima di 2 che viene prima di 3 e così via. Provare per credere. Quindi se il tasto X lo volete al terzo posto della cycle chain scriverete: MUIA_CycleChain, 3, Purchè vi ricordiate di accendere il computer…