Morphos sdl?

su morphzone mi rispondono che non c’è maniera. ho fatto un tentativo… la funzione SDL_GetWMInfo permette di ottenere informazioni dal windows manager in relazione alla finestra. Usa una struttura SDL_SysWMinfo che viene riempita con le opportune informazioni. Nel file sdl_syswm.h la struttura in questione ha una definizione diversa a seconda del sistema operativo. A titolo di esempio quella di windows è questa. typedef struct SDL_SysWMinfo { SDL_version version; HWND window; /**< The Win32 display window */ HGLRC hglrc; /**< The OpenGL context, if any */ } SDL_SysWMinfo; E’chiaro che se ho l’HWND ho tutto ciò che mi serve. Ci ho provato in passato e tutto funzionava alla perfezione: menu, gadget, barre varie etc. Con aros e gli altri sistemi amiga non c’è una vera definizione. Si usa la struttura generica che è questa: /** The generic custom window manager information structure */ typedef struct SDL_SysWMinfo { SDL_version version; int data; } SDL_SysWMinfo Mi sono detto: chissà ora faccio una bella fprintf %p del valore restituitomi in data e vediamo cosa succede. Ho verificato con scout per verificare che la finestra del mio programma abbia effettivamente l’indirizzo che mi riporta “data” ma niente. Il dato che mi riporta data è sempre diverso da qualsiasi indirizzo di finestra riportato da scout di aros… A questo punto ipotizzo che sdl di aros (morphos) non abbia una versione implementata di questa funzione? O sbaglio io qualcosa? Evidentemente il sistema operativo fornisce un altro sistema per il recupero dell’indirizzo di una finestra (scout da qualche parte lo deve prendere). Riformulo la domanda: laddove riuscissi in una qualche maniera a trovare l’indirizzo della finestra, ovviamente a runtime, c’è una possibilità di dire a mui che l’oggetto finestra che voglio è proprio quello con quell’indirizzo? In breve gli “monto” i gadget a finestra già creata…

Ancora Rebulator

e questo è l’ultimo su mui rebulator! non ho più continuato a scrivere perchè mi accorsi che il divertimento era passato: non lo facevo più per me ma mi rivolgevo a qualcuno quasi fosse una guida. continuai di lì a poco la stesura del prg che effettivamente funziona ma non ho più continuato la documentazione dello stesso nè lo studio di mui. devo dire che è questo è stato il primo progetto dopo anni che ho affrontato con passione. stavo imparando qualcosa di nuovo e mi è piaciuto molto. causa la mancanza di documentazione devo ringraziare in primis shinkuro per la sua guida. benchè affronti le tematiche in maniera forse troppo “oltre” per un neofita, in quel testo ti ritrovi sempre un qualcosa che poi ti fa passare oltre. così come gli autodoc di stuntz sono una vera e propria manna. per non parlare della più grande, disponibile e appassionata comunità di programmatori che conosca che è quella di morphos. 13/07/2011 Siamo a metà luglio e fa un caldo boia. Rebulator è andato avanti e i menu sono completi da un pò. In questi giorni sto affrontando l’uso dei font per i singoli oggetti. Qualcuno dirà: e che c’è da studiare sui font? Risposta: poi si vedrà… Ritornando ai nostri bravi menu… Come dicevo si tratta di creare la nostra menu strip e definire le nostre voci di menu, sottomenu e i loro attributi. Qualche tempo fa accennavo alla struttura newmenu. Cos’è nello specifico? E’una struttura che contiene “la descrizione” di tutte le singole voci di menu con gli attributi. L’uso di strutture per definire oggetti è una pratica che nasce “prima” dell’epoca degli oggetti. Non per niente, in mui, che è object oriented grazie a boopsi, è vero che si può usare la struttura NewMenu ma, contemporaneamente, si può usare anche la gestione diretta degli oggetti in tempo reale. Per carità ognuno ha o suoi gusti, io ho preferito optare per la seconda possibilità visto che MUI mi dava tale possibilità. Spiegheremo anche la NewMenu ma prima parleremo dell’implementazione dei menu di rebulator alla maniera di MUI. Riporto un frammento di codice che definisce i menu in rebulator 0.4: La prima riga crea l’oggetto menustrip (notare il cast verso IPTR sennò Gcc rompe) MUIA_Application_Menustrip, (IPTR)(MenustripObject, La seconda crea invece il primo menu come oggetto Child della classe family (MUIA_Family_Child). MUIA_Menu_Title come dice il nome imposta il nome del menu MUIA_Family_Child,(IPTR)(MenuObject,MUIA_Menu_Title, “Rebulator”, Qui, sempre come oggetto child, creiamo (MUI_MakeObject) un Menuitem (cioè una voce di menu) a nome “About, che abbia come lettera di tastiera per selezionarlo (con il tasto amiga) la lettera “A” e che non abbia altre particolarità (0,0) a questo associo una variabile oggetto “infomenu” MUIA_Family_Child, (IPTR)(infomenu = MUI_MakeObject(MUIO_Menuitem,”About”, “A”, 0,0)), Idem qui:creo una voce di menu Quit associata a un oggetto quit. MUIA_Family_Child, (IPTR) (quit = MUI_MakeObject(MUIO_Menuitem, “Quit”, “Q”,0,0)), Lo end chiude “il menu object”: i menu item non hanno bisogno di end!! End), Secondo menu chiamato Tools! MUIA_Family_Child, (IPTR) (MenuObject, MUIA_Menu_Title, “Tools”, Oops… ma come? prima di chiudere con un End il menu Tools aggiungo, non un menu item, bensì un altro oggetto menu (menuobject) chiamato keys? Ebbene si: inserire un oggetto menu in un altro oggetto menu è la maniera di MUI per creare… I SOTTOMENU!!! Niente di più semplice ma non so quanto tempo ho penato per capirlo (giuro per puro caso) Non c’è scritto da nessuna parte nella documentazione se non buttato la, in maniera peraltro semplicistica, nell’introduzione al capitolo dei menu. Roba che io le introduzioni non le leggo manco di solito… MUIA_Family_Child, (IPTR) (MenuObject, MUIA_Menu_Title, “Keys”, Qui riprende il flusso congeniale: un menu item per il nostro menu!! il suo titolo è base ed è associato all’oggetto “menu_standard”, ed ha alcune particolarità: 1) possiede l’attributo MUIA_Menuitem_Checkit, TRUE: serve a dire che la voce di menu è “checkabile”, cioè il click su di esso fa apparire un segno di spunta vicino al suo nome (per impostare qualcosa…) 2) MUIA_Family_Child,(IPTR) (menu_standard = MenuitemObject, MUIA_Menuitem_Title, (IPTR)”Base”, MUIA_Menuitem_Shortcut, (IPTR) “b”, MUIA_Menuitem_Checkit, TRUE, MUIA_Menuitem_Checked, TRUE, MUIA_Menuitem_Exclude, 2+4+8, End), MUIA_Family_Child,(IPTR) (menu_extended = MenuitemObject, MUIA_Menuitem_Title, (IPTR)”+Extended”, MUIA_Menuitem_Shortcut, (IPTR) “x”, MUIA_Menuitem_Checkit, TRUE, MUIA_Menuitem_Exclude, 1+4+8, End), MUIA_Family_Child, (IPTR) (menu_trigonometric = MenuitemObject, MUIA_Menuitem_Title, (IPTR)”+Trigonometric”, MUIA_Menuitem_Shortcut, (IPTR) “t”, MUIA_Menuitem_Checkit, TRUE, MUIA_Menuitem_Exclude, 1+2+8,End), End), End), End), Rispondi Citazione Attiva notifiche Rimuovi 835 LINGUAGGI – PROGRAMMAZIONE. / RE: [C][MUI]REBULATOR: A TROLL CALCULATOR… PENSIERI SPARSI « il: 16 Settembre 2011, 15:57:15 » chiaramente preso da manie di protagonismo, riporto gli ultimi uno o due post che avevo scritto sul mio blog riguardo rebulator. questa calcolatrice che sa fare un pò tutto e di fatto non sa fare il resto di niente!!!so che non potevate vivere senza… 23/06/2011 0.4! La principale novità della 0.4 rispetto alla 0.3 è l’introduzione dei menu. Certo, anche la correzione di alcuni bug (chiamarli così è riduttivo) è importante, ma l’introduzione dei menu è quel che mi ha portato ancora avanti nello studio di mui. Vediamo… Ovviamente tutti sappiamo cosa siano i menu in un programma: sono quelle liste di alimenti cucinati più o meno male a cui è associato un prezzo più o meno spropositato. Ennò… non è proprio così! I menu sono uno degli elementi fondamentali dei sistemi operativi a finestre e, anzi, a volte la posizione, il comportamento degli stessi definisce un pò tutto l’aspetto del sistema operativo. Prendete per esempio i vari sistemi amigoidi: tutti hanno la barra dei menu in alto con menu che si sviluppano verso il basso da sinistra verso destra. Stessa storia per i sistemi apple o per windows fino alla 3.x. Da win 9x in poi (ma già su nt) la barra menu principale è posta in basso e si sviluppa verso l’alto. Un’altra caratteristica peculiare dei sistemi amiga (e dei sistemi apple…) è che i programmi non hanno menu perennemente visibili ma divengono visibili con la pressione del tasto destro del mouse. In windows invece ogni programma ha la barra menu che fa parte della finestra del programma stesso ed è sempre visibile. Anche se a vedere windows 7 le cose stanno cambiando anche lì (prendete office o ie9). Ritorniamo ad amiga: Su amiga (eventualmente anche per MUI) per poter usare dei menu in un programma bisogna definire una struttura NewMenu che contiene tutti i dati necessari per il comportamento dei menu del programma. L’insieme di tutti i menu del programma vengono chiamati “menu strip”. Tradotto letteralmente significa striscia di menu: se teniamo presente come è strutturato un insieme di menu, cioè l’uno affianco all’altro con i propri sottomenu, la definizione di striscia è visivamente azzeccata. Quindi abbiamo questa striscia di menu. Composta di menu. I quali a loro volta sono composti di elementi singoli o di ulteriori sottomenu: MENUSTRIP -MENU1 —MENUITEM1.1 —MENUITEM1.2 —SUBMENU1.3 ——MENUITEM1.3.1 ——MENUITEM1.3.2 -MENU2 —MENUITEM2.1 —SUBMENU2.2 —–MENUITEM2.2.1 —–MENUITEM2.2.2 —–MENUITEM2.2.3 —MENUITEM2.3 Quello precedente è lo schema di una menustrip con due menu principali (menu1 e menu2), Menu1 ha due elementi (item) menuitem1.1 e menuitem1.2, nonchè un sottomenu (submenu1.3). Submenu1.3 ha due elementi menuitem1.3.1 e menuitem1.3.2. Lo stesso vale per menu2. P.S. la numerazione è qualcosa di messo da me e non fa parte nè del linguaggio nè di niente, serve solo per “dividere” i menu logicamente sulla carta. Ma non è imperativa. In MUI la classe Menustrip (la barra menu) è una sottoclasse (sottoinsieme) della classe family. Dalla definizione che ne da Stuntz (per i nuovi arrivati è il creatore di MUI) las family.class è la classe di base per tutti quegli oggetti capaci di gestire liste di “oggetti figli”. E se ci riflettiamo un menu ha nelle sue voci e nei suoi sottomenu, figuratamente, dei figli. Tanto per iniziare MUI permette di definire una barra menu per l’applicazione o per la singola finestra. Quindi potremo avere un’applicazione composta da due finestre separate che ha due menustrip separate. Un altro attributo fondamentale per le menustrip è MUIA_Menustrip_Enabled: booleano. Se settato a true la barra menu è attiva (enabled) altrimenti risulta disattivata. Questo viene stabilito in fase di creazione della menustrip usando i seguenti attributi: MUIA_Application_Menustrip MUIA_Window_Menustrip La prima, come si intuisce creerà una barra menu globale all’applicazione mentre la seconda riga creerà una barra menu relativa alla singola finestra nella quale sarà referenziata. In rebulator ho usato la MUIA_Application_Menustrip ma vale anche per la MUIA_Window_Menustrip. La riga MUIA_Application_Menustrip, (IPTR) (MenustripObject, crea le basi dell’oggetto MenuStrip. Nello specifico MenuStripObject è una define (contenuta come al solito in mui.h). Riporto di seguito le quattro define che riguardano i menu #define MenustripObject MUI_NewObject(MUIC_Menustrip #define MenuObject MUI_NewObject(MUIC_Menu #define MenuObjectT(name) MUI_NewObject(MUIC_Menu,MUIA_Menu_Title,name #define MenuitemObject MUI_NewObject(MUIC_Menuitem

Morphos Addicted

letteralmente drogato da morphos. l’ho letto da qualche parte su qualche sito. si addice perfettamente a me. sono arrivato al punto di temere la rottura del mac mini e addirittura di comprarne un secondo. poi mi dico che è meglio aspettare la 3.0 e vediamo che macchine supporta… Che devo dire: mi prende in maniera mostruosa. E’fatto bene, veramente bene, mostruosamente bene. L’unica cosa che non mi piace di morphos sono i vari temi. Quel che mi piace è amiga25. Anche ofour non è male. In questo bisogna dire che il più bel tema per sistemi amiga è quello di os4. Sicuramente non amo ferox anche se tra i builtin è il migliore. @jamballah: il tema che mostri nelle preferenze di polynet ng qual’è? è molto carino! Ritornando invece a morphos devo dire che fa tutto quel che gli è richiesto e anche oltre. In queste due settimane è stato costretto a un riavvio causa penna usb. Inserita, staccata senza particolari procedure e risultava come “bloccata”. Ho reinserito la penna, ho cliccato su espelli e lì il sistema è andato in freeze. Ma, devo dire, il sistema per il resto si comporta egregiamente. Cosa ci fai con morphos? Attività principale navigazione e visione di video su youtube. A volte scrittura di testi e programmini. Giochi poco e niente perchè non ce ne sono che amo. Diciamo che ormai sono pochi i giochi che mi prendono e sono da super next gen. Oppure da minimo minimo. Ma sicuramente non platform sdl. A proposito: ho installato osx in dual boot, con morphos che mi parte di default. Ho scoperto inoltre un pò di cosette del sistema “amiga” di cui non avevo idee e mi rendo conto, lavorando anche con aros, di quanto tutti questi figli di os3 abbiano tanto in comune. Ho installato un pò di mason icons (ancora una volta per i miei gusti il lato grafico del versante os4 è vincente) e sostituito alcune def_icons. Amiga ng… In questi momenti capisco un pò di più perchè ci siano dei pazzi che spendono cifre blu per comprarsi macchine a perdere. Non c’è nessun simil unix che può sostituire un sistema amigoso… Ma in questi momenti penso ancor più che ppc è una prigione per questo sistema operativo. Che dopo quasi 30 anni ha ancora tanto da dire.

Aros il Giovane

L’uomo vestito di grigio tolse il cappellaccio dalla sua testa e in tono teatrale disse: “Corvi neri all’orizzonte! Il giovane aeros ha in sè il potere di linux il vecchio e la velocità di suo fratello aros. Ma non ne ha la saggezza! Egli vuole essere schedulato e roccheggiante! Grande è la sua ambizione! Dalle sue azioni dipenderà la sopravvivenza del suo veloce ma gracile germano…” detto ciò si riaccomodò. Si alzò dal suo scranno la blu vestita sacerdotessa dell’Ordine della Farfalla. “Viandante, capisco le tue preoccupazioni ma credo che siano eccessive. Aeros ha una grande forza: la giovinezza. Porterà a noi nuovi amici! Giovani guerrieri e creature fantastiche: uccelli tonanti, volpi di fuoco e infine i cinque rossi!” disse quest’ultimo nome con accentuata drammaticità aspettando una reazione dalla platea. Come una furia si alzò il custode della tradizione: il custode della magica sfera bianco-rossa: “Scempio su di noi! Scempio su di noi che attraversiamo queste terre non meritandolo! Il custode dello schermo della morte starà solo ridendo di noi in questo momento! Affidiamo i nostri destini a un eretico! Affidiamo le nostre vite a un pervertito meticcio! Nel suo sangue scorre il sangue della bestia…” gesticolando con le mani continuava “ho scrutato la sua memoria… e ho visto… il marchio… il basso endian… voi tutti sapete di cosa parlo!” si rivolse con un sorrisetto verso il viandante “non dire che non sai di cosa parlo. anche tu ti sei contaminato” Il viandante si stava per alzare sfoderando la spada quando irruppe nella sala un giovane macilento quanto rapido. Nei suoi occhi cerchiati si vedeva una scintilla strana. Assomigliava in una maniera distorta al vecchio biancorosso vestito e anche alla sacerdotessa. Ma era diverso. “Sono io il corrotto!” disse lui “ma non potete negare che il mio sangue è anche il vostro” “Perfino tu!” rivolto al custode della sfera porti con te il tuo famiglio, indicando con mano malferma un cigno assomigliante in maniera innaturale a un pinguino. Il viandante si avvicinò al ragazzo e lo sorresse: “hai ragione aros ma non capisci. aeros è pericoloso! va fermato! non ci porterà altri amici. Quando vedranno la sua potenza e la tua velocità penseranno che sei tu. Siete indistinguibili… molti abbandoneranno la causa…” Il giovane sottrasse il suo braccio alla presa del viandante “STO CAXXO CHE SIAMO UGUALI. QUELLO C’HA DELLE SCHIFOSISSIME ICONE TIPO OSX PERCHE’ IL TIPO CHE L’HA FATTO E’UNO CHE CI PIACIONO LE MELE FRADICIE!” Detto questo svenne. “Era in trance! Era in trance! Ha avuto un messaggio dall’Altissimo!” esclamò la sacerdotessa bluvestita. In quel clima di perplessità ognuno si interrogava se il vecchio viandante non avesse avuto ragione…

Su cosa lavori?

Su aros-exec c’è un topic: what are you working to? Bene, questa ne è la versione povera. Perchè in realtà sono quelle cose alle quali mi dedico a tempo perso e, troppe insieme, quindi difficilmente se ne finisce una. 1) comic reader per windows ce in c#: ti devi studiare le zlib e sicuramente qualche altra schifezza per aprire zip e rar. e quindi studiarti il formato zip e il formato rar… ma poi perchè non lo posso fare in c? perchè devo morire. 2) videoscrittura: abbandono delle sdl in favore di cairo o freetype. debugging delle funzioni di impaginazione (almeno qua ormai si vede la luce). fare prove con font multipli. collegamento con mui o intuition per farlo funzionare sotto un sistema amigoide. tenere conto nelle funzioni di impaginazione così ci mettiamo pure le immagini dentro! 3) morphos: completare il tema os4.1. è odioso e noioso ritagliare pezzi di immagine. 4) imparare a usare il make. sono sicuro che quando l’avrò imparato non mi servirà a una mazza 5) imparare c#. non mi serve a una mazza ma non si sa mai. 6) buttare giù un gioco di avventura. ho iniziato la videoscrittura proprio per un gioco di avventure testuali a schermate fisse. ora che la parte principale è pronta non ho più voglia di buttare giù il gioco. in compenso ho scelto la colonna sonora: wagner. la caduta degli dei. ah si—>7) 7) imparare a usare un programma per presentazioni così faccio l’intro. prima o poi mi butto giù qualcosa. avevo un’idea sul vampiro di polidori ma non mi sento ispirato. non lo ricordavo bene e mi sa che ho fatto confusione con carmilla di le fanu. 8) buttare giù un programma di musichette touch per windows ce 9) allungare le ore della giornata…

Cairo o Freetype?

Sempre per il mio progettino di videoscrittura, partito con sdl_ttf, devo prendere una decisione: cairo o freetype? Cairo ha il grande vantaggio di essere portabile, esiste su aros e morphos e ha anche funzioni di disegno incorporate per i font. Freetype è sicuramente più veloce ma dovrei poi implementare funzioni di disegno diverse per sistemi diversi. Io programmo sotto windows e poi compilo sotto aros (laddove necessario). Con sdl il grande vantaggio era che quel che funzionava sotto windows funzionava uguale sotto aros senza modifiche. Sorge inoltre un altro problema: abbandono sdl perchè non si può interfacciarlo con i gadget di mui senza stravolgere sdl stesso o ricorrere a dei trick strani e mui vuole che la finestra sia creata con mui. Freetype chiaramente ha il vantaggio che la finestra se la crea mui e nessuno gli rompe le scatole. Cairo invece? Ho letto stamane un tutorial. Si parlava di “superfici” e la cosa mi ha disturbato non poco. Non è che finisce che mi va a creare lui le finestre e quindi non mi interfaccio con mui? Grazie!! edit: ma cairo che fa????? gli unici esempi che trovo sono appoggiati a gtk:|:|:| sotto windows di fatto che si fa? mi rimpiazza semplicemente le gdi? ok. capito come funziona sotto windows. la portabilità sta nel fatto che “sono le api di disegno che lo sono” la finestra me la creo come il sistema operativo vuole e (esempio in windows) mi limito a passargli i puntatori necessari per le superfici della finestra nella chiamata a on paint. la velocità sembra discreta. un ciclo di pittura di 800*600 rettangoli a schermo mi è sembrato decentemente veloce. Alla fine io devo disegnare caratteri e ridisegnare continuamente le zone variate. Non arriverò mai a dover disegnare in blocco 480000 caratteri. se prendo uno schermo 1280*1024 usando come esempio un piccolo carattere box di 100 pixel (10*10) otterrei circa 13.000 caratteri. Su un 1600*1200 arriverei a 19200 caratteri. Diciamo che le prestazioni sono buone. Per ora vince cairo 1 a 0… Il passo successivo sarà di vedere sotto aros come si comporta. A questo punto mi dovrò creare la mia brava finestra e vedere come interfacciarlo con cairo. Leggevo che sotto morphos è stato usato per webkit (quindi owb??)… sperem… aggiungo a titolo di esempio il codice per la realizzazione di un rettangolo #include #include #include #include /* Declare Windows procedure */ LRESULT CALLBACK WindowProcedure (HWND, UINT, WPARAM, LPARAM); /* Make the class name into a global variable */ char szClassName[ ] = “CodeBlocksWindowsApp”; int WINAPI WinMain (HINSTANCE hThisInstance, HINSTANCE hPrevInstance, LPSTR lpszArgument, int nCmdShow) { HWND hwnd; /* This is the handle for our window */ MSG messages; /* Here messages to the application are saved */ WNDCLASSEX wincl; /* Data structure for the windowclass */ /* The Window structure */ wincl.hInstance = hThisInstance; wincl.lpszClassName = szClassName; wincl.lpfnWndProc = WindowProcedure; /* This function is called by windows */ wincl.style = CS_DBLCLKS; /* Catch double-clicks */ wincl.cbSize = sizeof (WNDCLASSEX); /* Use default icon and mouse-pointer */ wincl.hIcon = LoadIcon (NULL, IDI_APPLICATION); wincl.hIconSm = LoadIcon (NULL, IDI_APPLICATION); wincl.hCursor = LoadCursor (NULL, IDC_ARROW); wincl.lpszMenuName = NULL; /* No menu */ wincl.cbClsExtra = 0; /* No extra bytes after the window class */ wincl.cbWndExtra = 0; /* structure or the window instance */ /* Use Windows’s default colour as the background of the window */ wincl.hbrBackground = (HBRUSH) COLOR_BACKGROUND; /* Register the window class, and if it fails quit the program */ if (!RegisterClassEx (&wincl)) return 0; /* The class is registered, let’s create the program*/ hwnd = CreateWindowEx ( 0, /* Extended possibilites for variation */ szClassName, /* Classname */ “Code::Blocks Template Windows App”, /* Title Text */ WS_OVERLAPPEDWINDOW, /* default window */ CW_USEDEFAULT, /* Windows decides the position */ CW_USEDEFAULT, /* where the window ends up on the screen */ 544, /* The programs width */ 375, /* and height in pixels */ HWND_DESKTOP, /* The window is a child-window to desktop */ NULL, /* No menu */ hThisInstance, /* Program Instance handler */ NULL /* No Window Creation data */ ); /* Make the window visible on the screen */ ShowWindow (hwnd, nCmdShow); /* Run the message loop. It will run until GetMessage() returns 0 */ while (GetMessage (&messages, NULL, 0, 0)) { /* Translate virtual-key messages into character messages */ TranslateMessage(&messages); /* Send message to WindowProcedure */ DispatchMessage(&messages); } /* The program return-value is 0 – The value that PostQuitMessage() gave */ return messages.wParam; } /* This function is called by the Windows function DispatchMessage() */ LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) { HDC hDC; PAINTSTRUCT Ps; switch (message) /* handle the messages */ { case WM_DESTROY: PostQuitMessage (0); /* send a WM_QUIT to the message queue */ break; case WM_PAINT: int i,j; hDC = BeginPaint(hwnd, &Ps); // TODO: Add any drawing code here… cairo_surface_t *surface; cairo_t *cr; //FUNZIONE WINDOWS PER RESTITUIRE IL PUNTATORE DEL CONTESTO FINESTRA WIN32 PER CREARE //CONTESTO (LA SUPERFICIE) SULLA QUALE CAIRO DISEGNA surface = cairo_win32_surface_create(hDC); cr = cairo_create(surface); cairo_set_source_rgb (cr, 0, 0, 0); cairo_rectangle (cr, 20+i,20+j,120+i,80+j); cairo_fill (cr); cairo_destroy(cr); break; default: /* for messages that we don’t deal with */ return DefWindowProc (hwnd, message, wParam, lParam); } return 0; } uhuhhuhhhuhhhuhhhuh (risata scomposta) che bella cosa i file header. io mi dimentico sempre della loro esistenza… in cairo-aros.h cairo_public cairo_surface_t * cairo_aros_surface_create (struct RastPort *rastport, int xoff, int yoff, int width, int height); nella versione per morphos c’è anche un esempio. stasera mi sa che mi diverto un poco…

Bug morti?

e non puzzano? mia moglie non credo sia molto d’accordo… cmq ne sto lasciando molti di morti… sto trasformando e ripulendo il codice e temporeggio… cacchio se temporeggio e rimando…. perchè leggendo un pò in più la guida di shinkuro ho deciso che dovrei leggermi un pò qualcosa sulla filosofia boopsi—> studiare ancora. Ora penso io ma non esiste un xxxxxxxx che produce un wordprocessor per amiga così che mi trovo un altro hobby??? Per carità è bellissimo mettersi lì e vedere crescere il codice man mano ma è parimenti avvilente realizzare qualcosa su una piattaforma che pensavi di conoscere e man mano che vai avanti ti rendi conto che conosci meno del meno. se poi si aggiunge che pensi che quel programma non lo userai mai. al massimo lo useranno 10 persone (100 considerando tutti gli amighisti del pianeta) il mio narcisismo viene a battere cassa. l’unica maniera per convincerlo a ripassare in altro momento a pretendere i suoi crediti è mostrargli la vera soddisfazione di ogni programmatore: i bug… vedere bug che nascono, crescono e si riproducono e pensare: hanno messo su famiglia grazie a me… in quei momenti mi sento molto padrone della bassa padana… Digressioni di solito funziona così: luce spenta. tutti dormono. si sente solo il rumore delle unghie sui tasti (causa chitarra classica) tipo segretaria. ogni tanto salto dalla sedia quando “la creatura” (il progetto) si muove. mi alzo. penso. giro intorno alla sedia o mi metto a pensare col naso incollato alla finestra. alle due di notte penso che caxxo ci starà a fare una luce accesa di fronte (dove per di fronte si intende un centinaio metri di distanza dal prossimo fabbricato). mi risiedo. controllo su google tutto quello che esiste sul nemico (il nemico è la libreria in oggetto: chi è, che fa e perchè lo fa). dopodichè bestemmio tutti i santi degli sviluppatori che hanno deciso che quella libreria gli fosse utile per un qualcosa. guardo un file make e lo guardo come si guarda uno scritto in arabo. solo che l’arabo è almeno esteticamente bello. capisco finalmente che @libs@ è una sorta di stringa di rimpiazzo. tipo: unire i puntini per costruire la figura. e io secondo loro dovrei mettermi a rimpiazzare una paginata di quei cosi? aspè ho letto che esiste un auto coso automake o giù di lì. farà questo? alla fine si è qualcosa di simile. da shell provo automake: non è un eseguibile. faccio una ricerca. è uno script in perl. proviamo a lanciarlo con perl. realizzo che il perl serve almeno a qualcosa. parte ma con una serie di errori. è vero avevo modificato i makefile… boh. domani rimetto quelli originali. adesso è tardi.se ne parla domani (cioè oggi). la programmazione (chiamiamola così) è un’esperienza totalizzante. una di quelle cose che paragono al modellismo con linguetta di fuori mentre incolli il pezzo minuscolo con la lente, piuttosto che la ripetizione della stessa battuta musicale per due ore consecutive. sai che l’hai studiata bene quando arriva l’urlo della moglie:EBBAASTAAAAAAAAAAAAAAA. non si sa se ce l’ha con me o col metronomo. (meglio del metronomo e sicuramente meno politically correct del maestro). Questo (non questa) è la programmazione. Una bella attività mentale. E faccio anche ginnastica intorno alla poltroncina girevole. Oltre che i fatti di quello “di fronte” alla fine ho vinto io contro l’infame!!! ho ricompilato cairo con supporto freetype:D:D ho disegnato dei caratteri freetype con cairo in una finestra mui. sicuramente non è chissà che risultatone ma se pensiamo che owb usa sdl per disegnarsi…. boh. io ho scritto su aros-exec. se è una cosa buona lo saprò a breve, sennò continuo con il mio progettino di videoscrittura. sicuramente posto le nuove cairo su aros archives e l’esempio sul wiki. “STO TUTT ECCITAT” ai che ero convinto che la versione aros usasse sdl? sarà che ho letto proprio ultimamente un post di nikolaos (quello di aspireos) che parlando dell’owb di fab, riporta le parole di quest’ultimo, il quale afferma che un port di owb morphos sarebbe più facile se si abbandonasse sdl in favore di cairo. cmq al di la di tutto ora ho la base per poter continuare i miei progettini:D Qualche nuovo progresso. Ho imparato qualcosa della dos library. Sono riuscito a caricare in un bel vettore di stringhe tutti i file ttf presenti in una data directory. Dopo aver buttato tonnellate di sangue mazze mi ha illuminato e ho scoperto che const char* ciao[] è equivalente a strptr array[] ai fini di un cycle object mui. Con mia somma gioia mi appresto a gestire un redraw della finestra e mi sovviene il fatto che mui non gestisca direttamente il resize gadget se non tramite programmazione a oggetti (kronos). Cosa che non voglio fare. Credo che nei prossimi giorni mi imbarcherò in una delle più schifose cose esistenti: mischiare messaggi mui e idcmp. Vedremo cosa ne uscirà… è passato un pò di tempo. abbandonata l’idea di fare miscugli alieni alla fine ho usato mui come vuole essere usato: istanziando degli oggetti. la cosa comoda è che non devi usare necessariamente l’oop. nel senso che un oggetto mui (cito shinkuro) è una struct del linguaggio c. nè più e nè meno. per le notifiche (la comunicazione interna all’applicazione) esiste una cosa magnifica che si chiama dispatcher: a sollecitazione a corrisponde azione b su oggetto c. saltata la fase degli hook perchè mi è aliena e mi sono buttato sull’implementazione di metodi custom (qualcuno direbbe ereditati). tutto ciò per scoprire che cairo non supporta i caratteri con diacritic (ad esempio un accento), piuttosto che il corsivo o il grassetto. anche usando freetype e fontconfig. se per il corsivo ho imparato pure le trasformazioni con le matrici… per il grassetto dovrei imparare a usare i pattern di fontconfig… e, a leggere dalle mailing list, non è detto che funzioni… non per niente spingono pango. le trasformazioni già mi bastano. ma studiare un ulteriore libreria per un grassetto mi sa che è eccessivo… ho visto in sdl_ttf che lantinga gestisce il grassetto modificando la bitmap in una qualche maniera. domani mi rubo un pò di codice… aggiornamento: non che se ne sentisse il bisogno ma così cerco di salire di grado scrivendo vaccate… abbandonato totalmente cairo. sto usando una libreria ttf interna trovata su aros-exec. nell’ultimo mese sono andato un pò a tentoni ma sono riuscito a trasformare l’applicativo che sta nascendo in un oggettone mui. la black box centrale riceve in ingresso un testo in un qualche formato simil richtext, lo trasforma in un suo formato interno, lo formatta, lo spara a video e chiaramente ne permette l’interazione. ho imparato a mie spese che per togliere la cera e mettere la cera bisogna usare i metodi di mui sennò si “piglia molta collera” e non funziona niente. assolutamente niente. ho imparato che per programmare sotto aros non solo devi morire ma anche oltre. non essendoci un ambiente di programmazione degno di questo nome, bisogna andare a tentoni: -1 scrivere -2 salvare -3 compilare -4 se va bene eseguire sennò ripetere da 1 -5 se va bene l’esecuzione ripetere da 1 e continuare ad aggiungere - 6 se si impalla il sistema isolare gli errori. Per isolare un errore sotto aros, come si fa? Si prende una mazza grossa e un elmetto da vichingo. Ci si precipita nel mucchio degli errori e spaventarli a morte finchè non hai quello che ti interessa e bastonarlo. I piccoli bastardi si nascondono sotto la mia scrivania… li sento… mi osservano… mi guardano e sorridono… Ma li fotto io. Li fotto! Quando sento quelle vocine che fanno “bug bug bug bug” ne schiaccio uno ed è una soddisfazione sentire il croc sotto la scarpa… Ovviamente scherzo. Sarei impazzito se veramente facessi questo. Per isolare un bug bisogna mettere una carota rossa e succosa fuori la sua tana e aspettare… aspettare… aspettare… Poi quando esce mettere un elmetto da vichingo e un grosso bastone… edit: se quei simpaticoni e facinorosi non l’avessero capito, shinkuro il portatile morphos o comunque IL PLAUSO DELLA COMUNITA’ se lo merita, non per aver scritto shadow of the beast iv ma per aver scritto L’UNICO DOCUMENTO VALIDO ESISTENTE SU MUI. Io poi vorrei sapere che killer app hanno realizzato gli altri… l’unico che poteva parlare era fab e non l’ho visto parlare.