Risposta Stile Testo Dimensione:  10 12 14 16 18 20 24 30 Colore:  Rosso Viola Verde Blu Giallo Grigio Arancio Rosa Allinea:  Centrato Giustificato Linea vuota A capo Altri comandi Emoticons Clicca per riportare il codice nell'area di testo oppure posizionati su un'immagine per vederne il relativo comando. Testo In risposta a ShInKurO [quote=ShInKurO] [auto-justify][quote] 1) MUI crea problemi di stabilita'. Non importa se Reaction avrebbe potuto/potrebbe fare lo stesso. [/quote] Uhm, non è molto corretta una cosa simile :) MUI e Reaction sono BOOPSI, dunque tutto ciò che accade su MUI, a meno di modifiche sostanziali al sistema (come quella citata da te riguardante le classi caricate in una memoria privata accessibile solo al programma che usufruisce di quella versione della classe), accade su Reaction. Perchè allora un utente non lo vede? :) La risposta è semplicissima: i bug sono talmente evidenti e non aggirabili che è il programmatore stesso ad abbandonare Reaction, lo ha fatto l'autore di Wookiechat, ma anche molti altri :) In sintesi, non è molto positivo il fatto che certe classi BOOPSI siano non sfruttate per i numerosi bug e limitazioni, ma passino per stabili agli occhi dell'utente :) Fa sorridere un ragionamento del genere :"eh, è instabile perchè usa MUI, se usasse Reaction sarebbe meglio", come dire che le auto di formula-1 del nostro periodo sono troppo lente rispetto a quelle degli anni '80. Sicuro, sono più lente, ma anche estremamente più sicure, nessuno sostiene che si dovrebbe ritornare a guidare le macchine degli '80 solo perchè erano più veloci ;-) [quote] MUI li crea e non ha nessuno strumento che consenta all'utente comune (quello a cui DOVETE aspirare se non volete restare in 2 geek nostalgici) di risolvere situazioni di crash dovute a classi instabili. [/quote] Ma non è MUI a doverlo avere, è AmigaOS a doverlo fornire. Cose come quella suggerita da te dovrebbero essere a livello di intuition/exec, al massimo a livello di rootclass, non a livello di classi specifiche. Beh certo, l'autore di MUI poteva pacthare la rootclass per ottenere una cosa del genere, ma poi non avrebbe rispettato più il sistema ;-) Poi dubito molto che nel '95 ci fossero idee simili, non c'era la cultura verso le situazioni anomale che si sono poi verificate e di cui tutti, riguardo MUI, si lamentano. E' però interessante notare come in tutti gli OS Amiga non si sia considerato questo grande feedback (="classi bacate buttano giù i programmi che li usano e il sistema stesso") e non si sia sviluppato nulla per porvi rimedio. In sintesi sono d'accordo con te sul fatto che ci dovrebbe essere un sistema per gestire le situazioni anomale, ma dovrebbe essere il sistema operativo stesso a fornirlo, ed è assurdo notare come nessuno dei team ci abbia ancora pensato. [quote] 2) MUI sara' nativa in mOS ma non lo e' in AmigaOS4 e non si integra con l'OS, nemmeno pagando. [/quote] MUI3.9 è ppc!! chi ha mai parlato di programmare su un coso 68k per un OS PPC :) Pagando non solo l'utente ha la possibilità di integrazione agli eventuali aspetti custom di intuition che l'utente ha scelto, ma può anche avere numerosi vantaggi in più rispetto a ciò che offre intuition. Ad esempio sarebbe possibile mettere come sfondo delle finestre, dei gruppi, delle pagine ecc (dappertutto) dei gradienti, mentre intuition permette gradienti solo ai bordi delle finestre, sui menu e sui bottoni. [quote] 3) Solo su Amiga poteva verificarsi l'anomalia per cui gli utenti devono pagare perche' i programmatori vogliono faticare meno. [/quote] E' un'anomalia nata dalla litigiosità della comunità. La cosa più logica che si sarebbe dovuta fare nel momento in cui si fosse riconosciuto MUI come standard de facto sarebbe stata quella di implementarne una versione gratuita, come lo è adesso Zune. Ma no, si è andati sul particolare, pensando di poter soppiantare MUI con un'estensione dell'antico sistema BOOPSI, arrivando addirittura a patchare la rootclass per ottenere qualcosa di concreto. Anche su Linux GTK è nato come risposta alla strana licenza di QT, ma al contrario di ClassAct GTK offriva pari funzionalità a QT, o sbaglio? [quote] a) Mega e mega di thread flammosi e non nei ng, su irc, nei forum. [/quote] Sempre dipendenti dalla litigiosità della comunità. Purtroppo non sempre i ragionamenti più logici sono stati quelli intrapresi. Perchè su Linux pur sviluppandosi thread flammosi si è giunti a soluzioni? In quanto la comunità Linux non è cresciuta attendendo i voleri di una casa madre e prendendo per oro colato tutte le scelte, giuste o sbagliate, di questa casa madre. ClassAct, come molte altre soluzioni alternative di dubbia utilità e con pochi servizi, nasce innanzitutto come risposta a MUI e segue l'indirizzamento iniziale di Commodore, senza alcun giudizio super partes sul sistema proposto dalla casa madre. E si è arrivati addirittura a patchare gli strumenti proposti dalla casa madre pur di affermare di fronte alla comunità :"io rispetto gli standard Commodore". Un giudizio super partes doveva valutare i vantaggi e gli svantaggi della soluzione BOOPSI/MUI e giungere alla conclusione di sviluppare un sistema al di fuori di BOOPSI (come Feelin), in quel modo sarebbe già stata un'alternativa. Ma a quel tempo nessuno l'avrebbe usata, del resto le alternative del genere ci furono (wizard.library, BGUI, ecc...), ma pochissimi le usarono. Il motivo è semplice: non seguivano i dettami Commodore e dunque erano etichettati come errati sin dall'inizio. Per la comunità quello che aveva fatto Commodore era oro colato, se non fosse così saremmo tutti su AROS 4.0. [quote] b) l'assenza di uno standard per la GUI che complica la vita all'utente e riduce l'usabilita'. [/quote] Immagino volessi scrivere "la presenza" :) In realtà MUI ha aumentato l'usabilità della piattaforma e ne ha allungato la longevità in assenza di qualcuno che portasse avanti l'OS. Visto che adesso sei all'esterno di Amiga prova a dare un'occhiata all'evoluzione fatta dalle GUI negli altri sistemi operativi. MUI ha anticipato i tempi in molti contesti, magari non era quello il suo scopo, ma caratteristiche come l'adattabilità della GUI (e del layout) alle diverse risoluzioni e ai diversi font scelti dall'utente sono cose che si sono viste con Swing, e non è cosa da poco per uno standard nato negli anni '90 come MUI. GTK, si è detto più volte, è ispirato a MUI. Per non parlare della prima versione di Cocoa su NextStep. Basta dare un'occhiata al manuale di sviluppo IPhone, c'è una pagina storica riguardante la prima versione di Cocoa, e fa sorridere notare una somiglianza del genere su un sistema come NextStep :) Forse da tutti i miei post qualcuno potrebbe fraintendere pensando che io sia un fan sfegatato di MUI, ma non è così. Chi mi conosce lo sa bene, del resto se fosse così non scriverei da OS4. Ma sono anche un informatico, e come tale devo guardare la situazione da un punto di vista più tecnico e distaccato, Mi dispiace dirlo, ma dall'esterno, un programmatore senza alcun interesse e senza alcun coinvolgimento con la piattaforma Amiga, a meno di contratti vincolanti o prese di posizione politiche, sceglierebbe MUI per programmare qualcosa di nativo su Amiga. [quote] c) il proliferare di programmi instabili e/o scomodi creati da inesperti ammaliati dalla possibilita' di creare GUI luccicanti (stesso problema che si ebbe su Windows all'uscita di Visual Basic). [/quote] Dipende da: 1) poca esperienza nella programmazione; 2) poca documentazione (ci sono talmente tante finezze MUI che senza un libro scritto dallo stesso autore l'unico modo per programmare qualcosa in modo corretto è chiedere a chi è coinvolto nello sviluppo di MUI. Ricordi quando ti lamentavi del fatto che un programma monothread MUI, durante l'apertura di una finestra modale in simple refresh bloccava tutta la grafica dell'applicazione? E' davvero una cosa scema da risolvere, ma bisogna chiedere alle giuste persone, e dovrebbe essere una cosa documentata meglio. Senza un libro di riferimento la gente ha programmato MUI come BOOPSI, e questo fu/è il problema); 3) serietà; [quote] d) nel 21o secolo, l'assenza di stimoli, per programmatori e software house, a portare su Amiga veri toolkit moderni che consentirebbero o almeno faciliterebbero i porting delle agognate applicazioni indispensabili. [/quote] Il fatto è che MUI risulta abbastanza moderno. Avrà anche i suoi retaggi culturali e le sue idiosincrasie per rispettare BOOPSI e rimanere retrocompatibile con le prime tecniche di programmazione BOOPSI, ma tolto tutto questo rimane comunque qualcosa di moderno rispetto alle altre alternative Amiga. Certo, avrebbe potuto patchare la rootclass, ma MUI rispetta il sistema ;-) Se poi sostieni che sarebbe meglio portare un GTK su Amiga, beh, ottimo per i porting, ma la piattaforma ha comunque bisogno di un framework "nativo" al passo con i tempi, altrimenti...GTK si programma benissimo su Linux ;-) [quote] Detto questo, lasciamo a chi si crogiola con MUI su OS4 l'idea di star facendo un favore all'utente. Qualsiasi guida di usabilita' dira' il contrario. ;-) [/quote] Punti di vista :) Io credo che qualsiasi guida all'usabilità dia come essenziale il fornire all'utente i servizi dell'OS in modo quanto più semplice ed intuitivo possibile. Beh, è quello che fa MUI :) Per esemio fa sorridere il fatto che nello stesso style guide di Commodore si parli di una gestione degli schermi per ciascuna applicazione che solo MUI ha implementato negli anni (seguendo lo style guide), e solo in OS4 Intuition tenta di riprendere ;) Per non parlare del fatto che solo le applicazioni MUI dalla versione 3.9 ti danno la possibilità di passare da uno schermo ad un altro solo cliccando su un gadget... Insomma ci sono talmente tanti vantaggi sia per l'utente quanto per il programmatore che la domanda più scontata è: Ma perchè non hanno reimplementato opensource MUI in tutti questi anni? :) Eh beh, ho già dato precedentemente la risposta, e per fortuna un pò di luce è data da Zune ;)[/auto-justify] [/quote] formattazione A sinistra Giustificata Nessuna

01 Luglio 2008 Postato da: Seiya OS4 e MOS: punto situazione

molto velocemente possiamo notare un notevole stallo di OS4 non nel suo percorso di sviluppo, ma nell'uso quotidiano. Basta fare un paragone tra software per MOS e OS4, in particolare quelli ludici. per MOS c'è VirtualGP2 HD mentre per OS4 c'è JaggedAlliance 2.. Come dire che per sviluppare un certo tipo di software gli sviuppatori più dotati sembrano lavorare per mos più che OS4. Basta vedere i porting per OS4 rispetto a quelli MOS. Dal lato ludico, non ci sono santi per OS4 - non sta al passo con la farfalla blu manco a spinta e i pochi sviluppatori che ci sono non sono al livello di quelli che a quanto pare lavorano su MOS. Anche software non ludico, programmi di grafica, browser internet sembrano previleggiare mos rispetto ad OS4. OS4 molto legato all'SDL molto di più di MOS. OS4 vive di wrapper: SDL, X11 ecc. OS4 è bello, ha belle icone, ha mantenuto la strattura classica di AmigaOs, ma dal pure lato "usabilità" ha perso molto, sopratutto nel campo software. Chi vuole usare un sistema alternativo per giocare, navigare o lavorare in un ambiente amigoso deve prendere MorphOS. la causa Amiga Inc e Hyperion ha congelato ogni voglia o tentativo di fare quel qualcosa in più. L'hardware per girare OS4 non c'è, SAM per uso domestico dipende molto da OS4 e se non esce per SAM in tempi brevi, non so quanti siano interessati e qualcuno di interessato a SAM lo conosco pure io, ma solo con OS4. Direi che sarebbe bello oggi avere un mos x86 o un mos su pearpc altro che OS4. La causa andrà avanti all'infinito perchè evidentemente si è capito che questa causa porterà gravi danni economici ad una delle due parti: quella più debole, ossia Hyperion e partners. Ricordatevi che se la causa riguardava qualunque altro OS si sarebbe risolta in pochissimo tempo, ma essendo Amiga una nicchia della nicchia non c'è fretta di risolvere.

Commenti: 124  Aggiungi - Pagine: 1...-3-4-5-6-7

Corri veloce Regina delle corse!! Post inviati: 243	Commento ShInKurO 21 Agosto 2008    08:34:08
	Citazione 1) MUI crea problemi di stabilita'. Non importa se Reaction avrebbe potuto/potrebbe fare lo stesso. Uhm, non è molto corretta una cosa simile MUI e Reaction sono BOOPSI, dunque tutto ciò che accade su MUI, a meno di modifiche sostanziali al sistema (come quella citata da te riguardante le classi caricate in una memoria privata accessibile solo al programma che usufruisce di quella versione della classe), accade su Reaction. Perchè allora un utente non lo vede? La risposta è semplicissima: i bug sono talmente evidenti e non aggirabili che è il programmatore stesso ad abbandonare Reaction, lo ha fatto l'autore di Wookiechat, ma anche molti altri In sintesi, non è molto positivo il fatto che certe classi BOOPSI siano non sfruttate per i numerosi bug e limitazioni, ma passino per stabili agli occhi dell'utente Fa sorridere un ragionamento del genere :"eh, è instabile perchè usa MUI, se usasse Reaction sarebbe meglio", come dire che le auto di formula-1 del nostro periodo sono troppo lente rispetto a quelle degli anni '80. Sicuro, sono più lente, ma anche estremamente più sicure, nessuno sostiene che si dovrebbe ritornare a guidare le macchine degli '80 solo perchè erano più veloci Citazione MUI li crea e non ha nessuno strumento che consenta all'utente comune (quello a cui DOVETE aspirare se non volete restare in 2 geek nostalgici) di risolvere situazioni di crash dovute a classi instabili. Ma non è MUI a doverlo avere, è AmigaOS a doverlo fornire. Cose come quella suggerita da te dovrebbero essere a livello di intuition/exec, al massimo a livello di rootclass, non a livello di classi specifiche. Beh certo, l'autore di MUI poteva pacthare la rootclass per ottenere una cosa del genere, ma poi non avrebbe rispettato più il sistema Poi dubito molto che nel '95 ci fossero idee simili, non c'era la cultura verso le situazioni anomale che si sono poi verificate e di cui tutti, riguardo MUI, si lamentano. E' però interessante notare come in tutti gli OS Amiga non si sia considerato questo grande feedback (="classi bacate buttano giù i programmi che li usano e il sistema stesso") e non si sia sviluppato nulla per porvi rimedio. In sintesi sono d'accordo con te sul fatto che ci dovrebbe essere un sistema per gestire le situazioni anomale, ma dovrebbe essere il sistema operativo stesso a fornirlo, ed è assurdo notare come nessuno dei team ci abbia ancora pensato. Citazione 2) MUI sara' nativa in mOS ma non lo e' in AmigaOS4 e non si integra con l'OS, nemmeno pagando. MUI3.9 è ppc!! chi ha mai parlato di programmare su un coso 68k per un OS PPC Pagando non solo l'utente ha la possibilità di integrazione agli eventuali aspetti custom di intuition che l'utente ha scelto, ma può anche avere numerosi vantaggi in più rispetto a ciò che offre intuition. Ad esempio sarebbe possibile mettere come sfondo delle finestre, dei gruppi, delle pagine ecc (dappertutto) dei gradienti, mentre intuition permette gradienti solo ai bordi delle finestre, sui menu e sui bottoni. Citazione 3) Solo su Amiga poteva verificarsi l'anomalia per cui gli utenti devono pagare perche' i programmatori vogliono faticare meno. E' un'anomalia nata dalla litigiosità della comunità. La cosa più logica che si sarebbe dovuta fare nel momento in cui si fosse riconosciuto MUI come standard de facto sarebbe stata quella di implementarne una versione gratuita, come lo è adesso Zune. Ma no, si è andati sul particolare, pensando di poter soppiantare MUI con un'estensione dell'antico sistema BOOPSI, arrivando addirittura a patchare la rootclass per ottenere qualcosa di concreto. Anche su Linux GTK è nato come risposta alla strana licenza di QT, ma al contrario di ClassAct GTK offriva pari funzionalità a QT, o sbaglio? Citazione a) Mega e mega di thread flammosi e non nei ng, su irc, nei forum. Sempre dipendenti dalla litigiosità della comunità. Purtroppo non sempre i ragionamenti più logici sono stati quelli intrapresi. Perchè su Linux pur sviluppandosi thread flammosi si è giunti a soluzioni? In quanto la comunità Linux non è cresciuta attendendo i voleri di una casa madre e prendendo per oro colato tutte le scelte, giuste o sbagliate, di questa casa madre. ClassAct, come molte altre soluzioni alternative di dubbia utilità e con pochi servizi, nasce innanzitutto come risposta a MUI e segue l'indirizzamento iniziale di Commodore, senza alcun giudizio super partes sul sistema proposto dalla casa madre. E si è arrivati addirittura a patchare gli strumenti proposti dalla casa madre pur di affermare di fronte alla comunità :"io rispetto gli standard Commodore". Un giudizio super partes doveva valutare i vantaggi e gli svantaggi della soluzione BOOPSI/MUI e giungere alla conclusione di sviluppare un sistema al di fuori di BOOPSI (come Feelin), in quel modo sarebbe già stata un'alternativa. Ma a quel tempo nessuno l'avrebbe usata, del resto le alternative del genere ci furono (wizard.library, BGUI, ecc...), ma pochissimi le usarono. Il motivo è semplice: non seguivano i dettami Commodore e dunque erano etichettati come errati sin dall'inizio. Per la comunità quello che aveva fatto Commodore era oro colato, se non fosse così saremmo tutti su AROS 4.0. Citazione b) l'assenza di uno standard per la GUI che complica la vita all'utente e riduce l'usabilita'. Immagino volessi scrivere "la presenza" In realtà MUI ha aumentato l'usabilità della piattaforma e ne ha allungato la longevità in assenza di qualcuno che portasse avanti l'OS. Visto che adesso sei all'esterno di Amiga prova a dare un'occhiata all'evoluzione fatta dalle GUI negli altri sistemi operativi. MUI ha anticipato i tempi in molti contesti, magari non era quello il suo scopo, ma caratteristiche come l'adattabilità della GUI (e del layout) alle diverse risoluzioni e ai diversi font scelti dall'utente sono cose che si sono viste con Swing, e non è cosa da poco per uno standard nato negli anni '90 come MUI. GTK, si è detto più volte, è ispirato a MUI. Per non parlare della prima versione di Cocoa su NextStep. Basta dare un'occhiata al manuale di sviluppo IPhone, c'è una pagina storica riguardante la prima versione di Cocoa, e fa sorridere notare una somiglianza del genere su un sistema come NextStep Forse da tutti i miei post qualcuno potrebbe fraintendere pensando che io sia un fan sfegatato di MUI, ma non è così. Chi mi conosce lo sa bene, del resto se fosse così non scriverei da OS4. Ma sono anche un informatico, e come tale devo guardare la situazione da un punto di vista più tecnico e distaccato, Mi dispiace dirlo, ma dall'esterno, un programmatore senza alcun interesse e senza alcun coinvolgimento con la piattaforma Amiga, a meno di contratti vincolanti o prese di posizione politiche, sceglierebbe MUI per programmare qualcosa di nativo su Amiga. Citazione c) il proliferare di programmi instabili e/o scomodi creati da inesperti ammaliati dalla possibilita' di creare GUI luccicanti (stesso problema che si ebbe su Windows all'uscita di Visual Basic). Dipende da: 1) poca esperienza nella programmazione; 2) poca documentazione (ci sono talmente tante finezze MUI che senza un libro scritto dallo stesso autore l'unico modo per programmare qualcosa in modo corretto è chiedere a chi è coinvolto nello sviluppo di MUI. Ricordi quando ti lamentavi del fatto che un programma monothread MUI, durante l'apertura di una finestra modale in simple refresh bloccava tutta la grafica dell'applicazione? E' davvero una cosa scema da risolvere, ma bisogna chiedere alle giuste persone, e dovrebbe essere una cosa documentata meglio. Senza un libro di riferimento la gente ha programmato MUI come BOOPSI, e questo fu/è il problema); 3) serietà; Citazione d) nel 21o secolo, l'assenza di stimoli, per programmatori e software house, a portare su Amiga veri toolkit moderni che consentirebbero o almeno faciliterebbero i porting delle agognate applicazioni indispensabili. Il fatto è che MUI risulta abbastanza moderno. Avrà anche i suoi retaggi culturali e le sue idiosincrasie per rispettare BOOPSI e rimanere retrocompatibile con le prime tecniche di programmazione BOOPSI, ma tolto tutto questo rimane comunque qualcosa di moderno rispetto alle altre alternative Amiga. Certo, avrebbe potuto patchare la rootclass, ma MUI rispetta il sistema Se poi sostieni che sarebbe meglio portare un GTK su Amiga, beh, ottimo per i porting, ma la piattaforma ha comunque bisogno di un framework "nativo" al passo con i tempi, altrimenti...GTK si programma benissimo su Linux Citazione Detto questo, lasciamo a chi si crogiola con MUI su OS4 l'idea di star facendo un favore all'utente. Qualsiasi guida di usabilita' dira' il contrario. Punti di vista Io credo che qualsiasi guida all'usabilità dia come essenziale il fornire all'utente i servizi dell'OS in modo quanto più semplice ed intuitivo possibile. Beh, è quello che fa MUI Per esemio fa sorridere il fatto che nello stesso style guide di Commodore si parli di una gestione degli schermi per ciascuna applicazione che solo MUI ha implementato negli anni (seguendo lo style guide), e solo in OS4 Intuition tenta di riprendere Per non parlare del fatto che solo le applicazioni MUI dalla versione 3.9 ti danno la possibilità di passare da uno schermo ad un altro solo cliccando su un gadget... Insomma ci sono talmente tanti vantaggi sia per l'utente quanto per il programmatore che la domanda più scontata è: Ma perchè non hanno reimplementato opensource MUI in tutti questi anni? Eh beh, ho già dato precedentemente la risposta, e per fortuna un pò di luce è data da Zune
	Ciao da ShInKurO! http://shinkuro.amiga.it