Posso dire di...

[rebraist]

@saimon69
l'idea è proprio quella del blog (anche se tenuto qui a rubare banda a ikir!!). perchè alla fine quando scrivo ragiono anche sulle cose che faccio. ma tenere un blog di programmazione significa comunicare anche cose, quali chiarezza di progettazione, che non credo di essere in grado di comunicare.

Nel frattempo... credo di dover ampliare il concetto di stato di rebulator (molto modestamente così ho battezzato la calcolatrice!!!).
Ad oggi essa ha i seguenti stati:
normal = stato di accensione, nella quale essa aspetta i comandi. nessun'operazione è stata ancora richiesta.
op= è lo stato delle operazioni aritmetiche: se premo il più passa in stato plus aspettando il secondo operando e così via.
error= non accetta comandi ed è ferma fintantochè non si resetta.
standby=stato di fermo non di errore. è lo stato che assume la macchina dopo aver premuto enter.
Ampliare gli stati della macchina perchè? Ad oggi gli stati gestiscono alla grande le operazioni binarie (la macchina entra ad esempio in stato plus se il primo operando ha senso aspettando così il secondo operando). Di fatto però essa non gestisce direttamente i singoli operandi se non come espressioni dello stato in cui si trova. Questo è a mio avviso un modello valido ma (e qui viene il ma). Un operatore unario come il +/- (che serve a cambiare il segno del singolo operando) o viene gestito con una gestione del singolo operando (ad esempio inserendo uno stato primo operando-secondo operando) così che si sa a quale operando ci si sta riferendo, oppure come un ulteriore "stato" inteso non come stato della macchine ma come attributo dell'operando. Pro e contro? Il primo caso introduce l'operando come ente a sè con tutti gli innegabili vantaggi (altri operatori unari, anche se impropriamente detti, sono la gestione della memoria o meglio la radice quadrata, la percentuale), ma richiede una riprogettazione di tutto. Il secondo caso è quello più logico perchè in realtà il segno è un attributo del singolo numero e non qualcosa che giustifichi un'introduzione di "nuove vie". filosofia. ed è tardi per la filosofia.

edit:
a breve sicuramente tradurrò in inglese (e italiano) i tutorial di guru meditation che sono stati il mio trampolino di lancio per le poche cose che so fare con mui. di una semplicità disarmante.
così come tradurrò e butterò giù le traduzioni di amiga university per intuition che pure sono magnifiche. anche se credo che abbiano un'utilità più "storica" che altro.
avevo iniziato a buttare giù questo blog (che "voleva" essere basato su intuition) ma quando ho scoperto mui ho abbandonato tutto perchè ho pensato fosse una cosa inutile. prima o poi lo riprenderò.
http://arosamiga.blogspot.com

[rebraist]

in questi giorni sto approfondendo ancora la creazione dell'interfaccia.
sotto aros (ma potrebbe essere lo stesso mui) non riesco a gestire due vgroup in cascata:
vgroup
...
end

vgroup
...
end

come ci provo il sistema va in freeze.
non ho provato ancora sotto morphos e stasera lo faccio.
Invece un'altra cosa che sto vedendo è il passaggio da un layout liquido a un layout fisso o qualcosa che ci assomigli.
esempio:
hgroup
bottone1
bottone2
vgroup
bottone3
bottone4
end
end.
quel che voglio è che l'altezza complessiva di bottone3 e di bottone4 sia uguale a all'altezza di bottone1, che a sua volta deve essere uguale all'altezza di bottone2.
la situazione è qualcosa del tipo
o o : (dove i due pallini sono i primi due bottoni e i due punti sono i secondi due bottoni).
Ho provato con fixed_height (un'altra cosa che manda in crash il mio bravo aros), con weight etc ma non ho risultati alcuni.
Probabilmente è perchè uso delle macro (simplebutton e vgroup piuttosto che hgroup) che non mi permettono di "toccare" con mano la struttura delle stesse e quindi capire dove piazzare le coppie di tag. In questi casi dove si vuole gestire al massimo il layout credo che le macro ti legano le mani.

[rebraist]

Yahoo! Su morphzone mi hanno risposto! Per evitare che tutti i pulsanti abbiano l'altezza determinata dal testo (il problema è questo) bisogna settare la proprietà MUIA_Text_SetVMax a False. Leggendo gli autodoc MUIA_Text_SetVMax serve a fissare la dimensione y. In particolare se MUIA_Text_SetVMax è settata a TRUE la dimensione verticale è determinata dal testo contenuto. Mettendola a false la dimensione verticale è slegata dal contenuto. E in particolare mettendo il vgroup di due bottoni in un hgroup dovrei ottenere ciò che voglio io, cioè che l'altezza TOTALE del VGroup sia quella degli altri componenti l'HGroup.
Rebulator: si avvicina alla fine:D
Gestisce le quattro operazioni, la radice quadrata, la pecentuale, il cambio di segno, gli errori e la memoria! Come calcolatrice base può pure andare:P
Alla fine non ho scelto la strada della gestione degli stati aggiuntivi. Se deve essere un esempio di programmazione che sia un pessimo esempio di programmazione:DD
Ciò che vedo scorrendo il listato è che si nota la non continuità nello sviluppo, potendo dedicare solo un paio d'ore al massimo e non tutti i giorni! Per cui per certe situazioni ho usato la soluzione A e per certe cose la soluzione B. Riguardando poi avrei potuto utilizzare in entrambi i casi la soluzione B ma per pigrizia non ho modificato niente. Questa è una cosa da evitare perchè una strada consolidata evita bug che, con un'altra strada che in quel momento sembra la migliore, possono insorgere.
Poi sto pensando di scrivere un libro sull'ontologia delle enumerazioni... Prima o poi ne capirò la natura intrinseca. Credo di non essere l'unico però visto che ho trovato su internet una mini disquisizione sulla natura duale delle enumerazioni...
Nel frattempo ho letto di un tipo che sta portando su aros un ide pascal!
Una figata unica! Io sono nato all'itis con il compilatore in standard pascal su macchinoni hp a riga di comando. Non so se fossero unix o altro. Ricordo solo un armadio pieno di fili, delle colonnine tipo museo con dentro i nastri, i professori in camice bianco e noi che sui terminali dovevamo prima loggarci e poi si andava avanti.

EDIT PER ME: Devo ancora provare su morphos le sequenze di vgroup. Su aros sicuramente si inceppa tutto. Uh! E credo che ormai devo abbandonare le macro. Lo dico sempre ma non lo faccio mai...

[rebraist]

si è mangiato tutta l'indentazione ma... ecco a voi un pezzetto di codice di rebulator!

//APPLICATION1 E'IL NOME DEL PUNTATORE ALL'OGGETTO APPLICAZIONE
//DOPO AVER DICHIARATO IL NOSTRO OGGETTO APPLICAZIONE, DOBBIAMO DEFINIRNE ALCUNE PROPRIETA'
// MUI RAGIONA COL MECCANISMO DELLE TAG: SONO COPPIE ORDINATE ATTRIBUTO-VALORE CHE COMUNICANO
// "QUALCOSA" AL COMPILATORE.
// LE TAG SI COMPONGONO IN SEQUENZA. QUELLA SEQUENZA SI CHIAMA TAG LIST.
// CHIARAMENTE LE SINGOLE TAG SONO DEFINITE ALL'INTERNO DELLE LIBRERIE CHE USIAMO.
// QUELLE DI MUI INIZIANO SEMPRE CON LA DICITURA MUI ED A SECONDA DELLA TIPOLOGIA HANNO IL SUFFISSO
// A,I,O PIUTTOSTO CHE M. RIMANDO ALLA GUIDA DI SHINKURO PER MAGGIORI DETTAGLI.
// AD ESEMPIO LA COPPIA ORDINATA CHE SEGUE DA IL VALORE "$VER: MUI CALCULATOR 0.1" (UNA STRINGA, CIOE' UN TESTO)
// ALL'ATTRIBUTO (LA A DOPO MUI STA PER ATTRIBUTO) MUIA_Application_Version.
// DI SOLITO LE TAG SONO AUTOESPLICATIVE PER CUI MUIA_Application_Version CONTIENE LA VERSIONE DEL PROGRAMMA
// NON HO APPROFONDITO MA CREDO CHE QUEL $VER MI SA TANTO DI TOKEN, CIOE' DI VARIABILE.
//SEGUONO GLI ALTRI ATTRIBUTI CHE SONO ABBASTANZA ESPLICATIVI
// RITORNANDO I NOMI TROVERETE CHE GLI ATTRIBUTI INIZIANO SEMPRE CON MUIA_ e l'oggetto al quale fanno riferimento:
// ES: MUIA_Application_ sono attributi dell'applicazione
// MUIA_Window delle finestre (window) e così via!
// DA NOTARE DUE COSE: 1) MUI E'CASE SENSITIVE. 2) SEMPRE PRIMA L'ATTRIBUTO POI IL VALORE. LE TAG SONO SEMPRE ORDINATE NELLO SCHEMA
// CHIAVE-VALORE. PREFERISCO CHIAVE PERCHE'ATTRIBUTO IN MUI SIGNIFICA UNA COSA SPECIFICA
// E PERCHE' DOPO PRANZO NON MI VIENE NIENTE DI MEGLIO.


application1= ApplicationObject,
MUIA_Application_Version , "$VER: Mui Calculator 0.1",
MUIA_Application_Copyright , "Public Domain",
MUIA_Application_Author , "Rebraist",
MUIA_Application_Description , "First Calculator",

SubWindow, window1 =
WindowObject,
MUIA_Window_Title, "Li'lCalculator",
WindowContents,
VGroup,


Child, risultato= TextObject,
TextFrame,
MUIA_Text_PreParse, "\33r",
MUIA_Background, MUII_TextBack,
MUIA_Text_Contents, "0",
End,




Child, HGroup,
MUIA_Group_SameSize, TRUE,

Child, button_memr = SimpleButton("MR"),
Child, button_memc = SimpleButton("MC"),
Child, button_memp = SimpleButton("M+"),
Child, button_memm = SimpleButton("M-"),
Child, button_canc = SimpleButton("C"),
End,


Child, HGroup,
MUIA_Group_SameSize, TRUE,

Child, button_seven = SimpleButton("7"),
Child, button_eight = SimpleButton("8"),
Child, button_nine = SimpleButton("9"),
Child, button_mul = SimpleButton("*"),
Child, button_minplus = SimpleButton("±"),
End,

Child, HGroup,
MUIA_Group_SameSize, TRUE,
Child, button_four = SimpleButton("4"),
Child, button_five = SimpleButton("5"),
Child, button_six = SimpleButton("6"),
Child, button_div = SimpleButton("/"),
Child, button_perc = SimpleButton("%"),
End,

Child, HGroup,
MUIA_Group_SameSize, TRUE,
Child, button_one = SimpleButton("1"),
Child, button_two = SimpleButton("2"),
Child, button_three = SimpleButton("3"),
Child, button_minus = SimpleButton("-"),
Child, button_square = SimpleButton("S"),

End,

Child, HGroup,
MUIA_Group_SameSize, TRUE,
Child, button_zero = SimpleButton("0"),
Child, button_point = SimpleButton("."),
Child, button_enter = SimpleButton("="),
Child, button_plus = SimpleButton("+"),
Child, button_euro = SimpleButton("¤"),
End, //HGroup

/* Child, risultato= TextObject,
TextFrame,
MUIA_Background, MUII_TextBack,
MUIA_Text_Contents, "0",
End,*/

End, //vgroup

End, //windowobject


End; //applicationobject

[rebraist]

A un livello molto base (il mio) possiamo dire un'interfaccia grafica costruita con mui sarà data da come viene composta la taglist opportuna.
Ricapitolando quindi:
1) Definire un generico puntatore ad oggetto:
object *application1;
2) Questo puntatore conterrà tutta quella che è la descrizione della nostra interfaccia (finestre, pulsanti e così via) e le sue proprietà.
Il puntatore a oggetto è un puntatore generico per cui gli dobbiamo dire di volta in volta a che tipo di oggetto si deve conformare.
Non è imperativo però associare a un oggetto fisico (un gadget) della nostra interfaccia, un oggetto logico (un puntatore ben preciso). Questo perchè chi ha progettato mui l'ha resa talmente semplice che basterebbe, per creare un'interfaccia, darne solo la sua descrizione in termini di taglist: "cameriere per favore un'applicazione con una finestra, tre pulsanti in riga e due caserlle di testo incolonnate. provveda lei a sistemarli sul vassoio! grazie!"
Questo, scherzosamente è ciò che si può fare con mui.
Dove voglio andare a parare? Mettiamo che io voglia un'interfaccia con una riga di testo con su scritto "ciccio", un pulsante e un'altra riga di testo. La casella che contiene ciccio voglio che non faccia altro per tutto il programma: contenga la scritta ciccio e basta.
L'ultima riga di testo invece deve variare con le pressioni del pulsante: ad esempio tiene il totale delle pressioni del pulsante incrementandosi di uno ogni volta che lo premo.
Quindi della seconda casella di testo devo avere tutti gli elementi necessari per far si che la mia programmazione la faccia "variare". Dobbiamo allora poterla identificare in una qualche maniera. Domandiamoci: come facciamo a identificare, in maniera semplice semplice qualcosa? Chiamandola per nome! Ecco. Se associo il mio gadget (o oggetto fisico ad esempio una finestra o un programma) al puntatore oggetto che ha quel determinato nome avrò quegli elementi necessari per poter modificare quella casella. Non solo, ma quando prendo il puntatore generico ad oggetti (object *) e lo associo a un oggetto finestra piuttosto che applicazione o pulsante, avrò circoscritto il suo raggio d'azione e il sistema saprà di che tipo di oggetto si tratta, con tutte le conseguenze del caso.
Se lo associo a un gadget pulsante conterrà in sè tutte le caratteristiche proprie del pulsante, se una finestra una finestra e così via.
Ora è chiaro che ho bisogno di compiere quest'operazione per il pulsante e per la casella di testo che si incrementa. Per quella che nasce ciccio e muore ciccio, cioè non varia mai, non ho necessariamente bisogno di associarla a un oggetto logico per la semplice ragione che è tanto carina sulla mia interfaccia ma, di fatto, non è oggetto della mia elaborazione! Mui permette questo come dicevo: creare dei gadget a video senza bisogno di associarli a dei puntatori ad oggetto. Poi lasciamo stare che è bene farlo per altre ragioni, ad esempio l'ordine.

(Questo come appunto: puntatori, puntatori, puntatori. Ma che so sti puntatori? In breve? Sono variabili che contengono degli indirizzi di altre variabili. e proprio in virtù di questo, permettendo l'accesso diretto all'indirizzo di memoria dove si trova un determinato "oggetto" permettono di modificarlo. Si capisce perciò perchè è tanto importante conoscere il "tipo" di oggetto al quale il puntatore fa riferimento: cambia totalmente tutto. Non sto qua a entrare nello specifico ma internet è piena di tutorial, spiegazioni, dissertazioni e natura ultima dei puntatori. Quel che non capisco io ad esempio, in mui, ma credo in generale nella programmazione di amiga è quest'utilizzo disinvolto di puntatori a oggetti generici. Ma come al solito io sono un niubbo e del perchè si siano fatte determinate scelte non sono ancora ai livelli necessari per comprenderli. detto questo riprendiamo con mui)

Ritorniamo a noi. Come faccio ad associare il gadget (o oggetto fisico) all'oggetto puntatore?
Parlando dell'applicazione dobbiamo dirgli che è un puntatore ad oggetto applicazione:
application1= ApplicationObject,
3) definito questo, senza entrare nel merito delle singole tag, cosa manca al nostro programma per avere una scintillante interfaccia? Beh, sicuramente una finestra!
4) Ecco perchè dichiariamo un bel puntatore a oggetto ancora una volta:
object *window1;
5) Come per l'altro dobbiamo dirgli che non è un puntatore generico ma un puntatore ad oggetto finestra, per cui:
window1= WindowObject,
6) Anche qui ci sono una serie di tag.
7) Stesso procedimento per i singoli gadget: bottoni, caselle di testo e così via:
object *button1;
button1=SimpleButton(...),...

Mui però non si ferma qui:
Caoticamente facciamo un passo indietro:
La struttura di un'interfaccia mui è più o meno questa:
oggetto_applicazione:
oggetto_finestra1:
singoli gadget o gruppi di gadget
fine oggetto_finestra1;
eventuale finestra 2,3 o 4:
singoli gadget o gruppi di gadget
Fine oggetto finestra 2,3 o 4...
Fine applicazione.

Pranzo!!!

[rebraist]

Rebulator è partito per aros archives!
Ora aspetto che lo pubblichino!
Ha sicuramente dei bugs e spero che qualcuno sia così gentile da comunicarmi tutti gli errori che trova!
Devo dire che questa bella avventura sta avendo inizio.
Il piacere è quello di aver prodotto (l'ennesimo) programma inutile sotto amiga.
Ma è il mio programma!
Insieme al file lha è presente anche il file.c e un piccolo readme.
Ci sarà sicuramente da migliorare tanto, tantissimo ma è comunque una partenza per levarsi la ruggine di dosso e imparare qualcosa di nuovo.
Tanto più che finalmente ho capito, dopo un bel pò di tempo, in maniera molto elementare le basi di mui le tecniche di programmazione orientata agli eventi di zune/mui.
Ho delle funzioni di base per la gestione dell'input, ho bene o male idea delle problematiche che si affrontano. Anche se a un primo, primissimo livello.
Risultato? Sono contento.

[rebraist]

Per risolvere i problemi di layout e su suggerimento di mazze di aros ho abbandonato le macro simplebutton.
D'altronde credo che sia la via naturale di proseguire nello sviluppo di interfacce mui.
Stasera ho giocato parecchio tempo sul layout dei tasti della calcolatrice e sono arrivato a un pò di conclusioni:
1) puoi piangere quanto vuoi un textobject avrà (come è giusto che sia) almeno la dimensione minima del testo che contiene. In pratica muia_fixheight (un attributo che fissa l'altezza di un oggetto a tot pixel) serve come il due di picche. Molto meglio usare muia_innerbottom, right etc almeno ti elimini quel paio di pixel (li ho misurati sono realmente due) che possono essere comunque di aiuto. Chiaramente se si modifica la dimensione del font le cose cambiano perchè il pulsante si regola di conseguenza. Io avrei sperato in un pulsante che tagliasse il testo ma, almeno sotto il mio icaros 1.2.5 non è stato così.
2) I Vgroup possono non solo essere messi in sequenza ma addirittura innestati l'uno dentro l'altro. Evidentemente ci deve essere un problema sulla mia icaros 1.2.6 sul portatile perchè invece le stesse cose sulla 1.2.5 da fisso viaggiano egregiamente.
3) Potenza dei frame!!! Ho usato per la prima volta i frame per "evidenziare" gli oggetti sul "form" (usiamo un termine windowsiano). Si tratta di mettersi a perdere un pò di tempo e finalmente la calcolatrice avrà un suo stile.
4) Usando i textobject come pulsanti sono riuscito a inserire gli shortcut da tastiera e i relativi highchar (in pratica il carattere evidenziato sotto un comando), così che adesso la calcolatrice funziona non solo con i click del mouse ma anche da tastiera.
Rimane che devo capire come esportare le opzioni di zune e come attivare il tastierino numerico (questo secondo me lo trovo nelle preferenze). Ah si! E come associare un'icona a rebulator!

[rebraist]

Eccolo qua! Il primo screen di rebulator 0.2 a layout liquido!

[MacGyverPPC]

Se modifichi il post e usi il tasto fimg per le immagini, così si evitano schermate tronche!
Grazie