Programmer World (@ProgrammerWorld) ha twittato alle 8:00 p. on lun, ott 22, 2012: Mono 3.0 is out http://t.co/lpWQX0nS (https://twitter.com/ProgrammerWorld/status/260440498102218752) Scarica l'app ufficiale di Twitter su https://twitter.com/download
Visualizzazione post con etichetta mono. Mostra tutti i post
Visualizzazione post con etichetta mono. Mostra tutti i post
lunedì 22 ottobre 2012
mercoledì 4 maggio 2011
Quale sarà la fine di Mono?
Dopo l'acquisto di Novell da parte di Attachmate, sono stati "liberati" un numero imprecisato di sviluppatori che lavoravano al progetto Mono. Quale sarà ora il suo destino?
http://blog.internetnews.com/skerner/2011/05/attachmate-lays-off-mono-emplo.html
http://blog.internetnews.com/skerner/2011/05/attachmate-lays-off-mono-emplo.html
lunedì 21 giugno 2010
Delphi incontra .NET
E dopo tanto peregrinare, si ritorna all'origine.
Mi sono allontanato abbastanza in questi anni dal Delphi, quasi snobbandolo come linguaggio minore, anche se in fondo in fondo mi ha sempre dato da mangiare.
E alla fine l'ho rincontrato, e declinato nella maniera più innovativa possibile.
Come sapete (o forse no ma si dice sempre così) il progetto Delphi.NET è definitivamente morto e sepolto, ma è stato creato un altro compilatore per piattaforma .NET, che si chiama Delphi Prism, da una società, la RemObjects. Il progetto Delphi Prism, poi acquistato da Embarcadero (che ora detiene i diritti del Delphi) non è semplicemente il porting su .NET di delphi, ma un linguaggio che, partendo dal Pascal del Delphi, lo ha esteso alle specifiche della piattaforma .NET (Generics, namespace e quant'altro).
La cosa veramente interessante di tutto ciò è, anche se l'IDE (o meglio il plugin per Visual Studio) è a pagamento, il compilatore a linea di comando è gratuito e scaricabile da qui. Quindi, anche senza tanti aiuti grafici, si può comunque pensare di compilare i progetti Delphi per .NET, apportando solo alcune modifiche.
E uno dirà: ma non si fa prima a fare tutto in c#? Supponete però di avere, come ho io, una bella base di codice esistente scritto in Delphi, e che magari la si vuol migrare a .NET. Almeno per la parte di business logic questo potrebbe essere il modo di fare il porting cambiando veramente pochissimo, ho fatto la prova.
In più, meraviglia delle meraviglie, il framework target non è solo quello di Microsoft, ma anche Mono, tanto vituperato ma per me tanto utile in questo momento per il cross platform.
Mi sono allontanato abbastanza in questi anni dal Delphi, quasi snobbandolo come linguaggio minore, anche se in fondo in fondo mi ha sempre dato da mangiare.
E alla fine l'ho rincontrato, e declinato nella maniera più innovativa possibile.
Come sapete (o forse no ma si dice sempre così) il progetto Delphi.NET è definitivamente morto e sepolto, ma è stato creato un altro compilatore per piattaforma .NET, che si chiama Delphi Prism, da una società, la RemObjects. Il progetto Delphi Prism, poi acquistato da Embarcadero (che ora detiene i diritti del Delphi) non è semplicemente il porting su .NET di delphi, ma un linguaggio che, partendo dal Pascal del Delphi, lo ha esteso alle specifiche della piattaforma .NET (Generics, namespace e quant'altro).
La cosa veramente interessante di tutto ciò è, anche se l'IDE (o meglio il plugin per Visual Studio) è a pagamento, il compilatore a linea di comando è gratuito e scaricabile da qui. Quindi, anche senza tanti aiuti grafici, si può comunque pensare di compilare i progetti Delphi per .NET, apportando solo alcune modifiche.
E uno dirà: ma non si fa prima a fare tutto in c#? Supponete però di avere, come ho io, una bella base di codice esistente scritto in Delphi, e che magari la si vuol migrare a .NET. Almeno per la parte di business logic questo potrebbe essere il modo di fare il porting cambiando veramente pochissimo, ho fatto la prova.
In più, meraviglia delle meraviglie, il framework target non è solo quello di Microsoft, ma anche Mono, tanto vituperato ma per me tanto utile in questo momento per il cross platform.
domenica 13 settembre 2009
Mono, MonoDevelop e Gtk#
Stavo guardando Mono e MonoDevelop.
Abituato come sono a VisualStudio e allo sviluppo WinForms, ho subito cercato di fare un progetto WinForms.
Bene, ho scoperto che sotto MonoDevelop non si possono creare progetti WinForms, ma solo progetti Gtk#.
Ho anche scoperto che non esiste nessun designer pronto per applicazioni WinForms: l'unico che c'è è ancora in versione beta.
OK, no problem: vediamo come funziona lo sviluppo Gtk#, mi sono detto, sarà più o meno come quello WinForms.
Quindi, Nuovo->Soluzione->Progetto Gtk# 2.0
La soluzione viene creata, il progetto anche, ed aggiunge una classe MainWindow.cs che contiene una window di default.
Il designer è carino, gestisce bene la form.
E qui primo piccolo problema: se metto un bottone direttamente sulla form la riempie tutta... ok, ho capito, bisogna mettere un container che gestisca la posizione dei widget. Metto un FixedContainer e tutto va a posto, il disorientamento è durato veramente poco.
OK, piccola differenza ma basta farci l'abitudine. Metto un bottone, creo l'evento di Click, (Clicked si chiama in Gtk#) e provo a fare comparire un MessageBox.
Dunque, dunque, MessageBox.Show non funziona qui, chissà come sarà.... Googola che ti rigoogolo alla fine ho trovato!
Bisogna creare un MessageDialog e poi fare run!
OK, il mio primo test con Mono finisce qua. Convincere mi convince, però solo un pensiero mi attanaglia... se deve essere la versione open delle specifiche .NET, perché non implementare già da subito la System.Windows.Forms e supportarla da subito su MonoDevelop? Fra l'altro sembra anche che il porting sia completo al 100% e che funzioni anche piuttosto bene!
Se avrò tempo approfondirò i test.
Abituato come sono a VisualStudio e allo sviluppo WinForms, ho subito cercato di fare un progetto WinForms.
Bene, ho scoperto che sotto MonoDevelop non si possono creare progetti WinForms, ma solo progetti Gtk#.
Ho anche scoperto che non esiste nessun designer pronto per applicazioni WinForms: l'unico che c'è è ancora in versione beta.
OK, no problem: vediamo come funziona lo sviluppo Gtk#, mi sono detto, sarà più o meno come quello WinForms.
Quindi, Nuovo->Soluzione->Progetto Gtk# 2.0
La soluzione viene creata, il progetto anche, ed aggiunge una classe MainWindow.cs che contiene una window di default.
Il designer è carino, gestisce bene la form.
E qui primo piccolo problema: se metto un bottone direttamente sulla form la riempie tutta... ok, ho capito, bisogna mettere un container che gestisca la posizione dei widget. Metto un FixedContainer e tutto va a posto, il disorientamento è durato veramente poco.
OK, piccola differenza ma basta farci l'abitudine. Metto un bottone, creo l'evento di Click, (Clicked si chiama in Gtk#) e provo a fare comparire un MessageBox.
Dunque, dunque, MessageBox.Show non funziona qui, chissà come sarà.... Googola che ti rigoogolo alla fine ho trovato!
Bisogna creare un MessageDialog e poi fare run!
OK, il mio primo test con Mono finisce qua. Convincere mi convince, però solo un pensiero mi attanaglia... se deve essere la versione open delle specifiche .NET, perché non implementare già da subito la System.Windows.Forms e supportarla da subito su MonoDevelop? Fra l'altro sembra anche che il porting sia completo al 100% e che funzioni anche piuttosto bene!
Se avrò tempo approfondirò i test.
Iscriviti a:
Post (Atom)