mboost-dp1
Mono
Mono-project skrev:Mono's Version Policy Explained
For an X.Y.Z tuple:
X is the major version mumber
Y is the minor version number
Z is a revision number
The major version number is used to indicate which ABI/API version Mono uses. When it changes, there is no gaurantee that existing code will continue to work (though the utmost effort will be made to maintain compatibility). The major version changes infrequently.
The Minor version number consists of two sets: even numbers (stable releases) and odd numbers (development releases). The only improvements that stable releases receive are bug fixes; all new feature work is done in development releases. Features may be backported from a development release to a stable release, if appropriate. Stable releases are API and ABI stable, and can be expected to have minimal changes.
Development releases may break ABI/API compatibility, especially if the stable release they lead up to will change the Major version number. In particular, development releases are likely to add new API, and the use of new API can change between development releases. When a development release is converted into a stable release, we will maintain the API/ABI, and the new stable release should be fully compatible with the previous stable series having the same major number.
Revision numbers signify the release of a Major/Minor pair. Within a stable series, ABI/API compatibility should not be broken when the revision changes.
hvis de klaphatte nu gad addresserer de essentielle problemer med mono, såsom manglende understøttelse af WCF (havde de ikke sidst jeg kiggede...) samt en GC der ikke suger kogler...
EDIT: "WCF client and server, the subset exposed by Silverlight 2.0."
så glem det med WCF...dog på høje tid de fik det...skidtet er fra .net 3 :(
EDIT: "WCF client and server, the subset exposed by Silverlight 2.0."
så glem det med WCF...dog på høje tid de fik det...skidtet er fra .net 3 :(
Jeg kan også anbefale at læse følgende: http://tirania.org/blog/archive/2009/Nov-23.html i relation til nyheden.
Specielt hvis man har interesse i Silverlight, eller GUI udvikling på Linux.
Det hjælper jo heller ikke at en lang række tekniske kompetenter brugere på newz.dk, siger de fravælger Mono pga. mulige pantentproblemer som kun opstår når de tager deres sølvpapirshat på.
Specielt hvis man har interesse i Silverlight, eller GUI udvikling på Linux.
Der er desværre mangel på contributers, og med en ret fanatisk omverden, der mener Stallman er gud, og Mono/Novell er ondskaben selv, går det langtsom fremad.mgX (3) skrev:hvis de klaphatte nu gad addresserer de essentielle problemer med mono
Det hjælper jo heller ikke at en lang række tekniske kompetenter brugere på newz.dk, siger de fravælger Mono pga. mulige pantentproblemer som kun opstår når de tager deres sølvpapirshat på.
Tror han taler om: http://www.mono-project.com/Compacting_GC
Som ikke er klar endnu, men Boehm virker fint ? Hvilke specifikke klager har du ?
Som ikke er klar endnu, men Boehm virker fint ? Hvilke specifikke klager har du ?
Jeg har faktisk for nyligt været med til at bygge et .NET GUI cross-platform program, med System.Windows.Forms...
... og det lykkedes! ^^
(Jeg har i de sidste "mange" år, løbende forsøgt. Og det er første gang at et rigtigt program har kunne porteres.)
Men det er nu stadigvæk ikke uden problemer. Og Localization ser ikke ud til at være synderligt implementeret endnu.
Personligt har jeg dog altid syntes, at Mono-folkene brude fokusere noget mere på at understøtte .NET 2.0 til fulde, fremfor at implementere 3.0, 3.5 og nu 4.0.
Lad os kaste nogle opløftende buzz ord efter dem:
STABILITEEEEEET
PERFORMAAAAANCE
KOMPATIBILITEEEEEEET
... og det lykkedes! ^^
(Jeg har i de sidste "mange" år, løbende forsøgt. Og det er første gang at et rigtigt program har kunne porteres.)
Men det er nu stadigvæk ikke uden problemer. Og Localization ser ikke ud til at være synderligt implementeret endnu.
Personligt har jeg dog altid syntes, at Mono-folkene brude fokusere noget mere på at understøtte .NET 2.0 til fulde, fremfor at implementere 3.0, 3.5 og nu 4.0.
Lad os kaste nogle opløftende buzz ord efter dem:
STABILITEEEEEET
PERFORMAAAAANCE
KOMPATIBILITEEEEEEET
Hvis de virkeligt vil implementere hele Windows Forms så ser jeg intet problem i at lave sine GUI's i det.
Jeg skrev en klon af Disk Usage Analyzer (fra standard Ubuntu installationen) i C# med Windows Forms og en masse drawing stuff til at tegne de cirkulere charts. Det meste så ud til at virke bortset fra nogle enkelte detaljer som de nok måske allerede har rettet eller snart får rettet.
Jeg skrev en klon af Disk Usage Analyzer (fra standard Ubuntu installationen) i C# med Windows Forms og en masse drawing stuff til at tegne de cirkulere charts. Det meste så ud til at virke bortset fra nogle enkelte detaljer som de nok måske allerede har rettet eller snart får rettet.
#12 enig... Har selv brugt det en del... Det er godt nok meget besværligt en windows.forms... Men kan tilgængel også nogle andre ting... som er vildt fede...
Og efter at have brugt både Qt og Gtk, må jeg nok indrømme at jeg ikke har meget til overs for den måde man laver layouts i Windows.Forms... WinForms har heller ikke actions og ikoner... Og mange af deres widgets er ikke specielt rige... Label med markup findes f.eks. både i Qt og GTK og det er vildt fedt... ville godt nok nødigt leve uden...
Og efter at have brugt både Qt og Gtk, må jeg nok indrømme at jeg ikke har meget til overs for den måde man laver layouts i Windows.Forms... WinForms har heller ikke actions og ikoner... Og mange af deres widgets er ikke specielt rige... Label med markup findes f.eks. både i Qt og GTK og det er vildt fedt... ville godt nok nødigt leve uden...
Virkelig? Windows har da i det mindste support for layers, og en ordenlig docking model.jopsen (14) skrev:Og efter at have brugt både Qt og Gtk, må jeg nok indrømme at jeg ikke har meget til overs for den måde man laver layouts i Windows.Forms
Prøv at lægge 2 knapper oven på hinanden i GTK, og så senere ændre på deres z-index. Det kan ikke lade sig gøre i GTK, men virker fint i Windows og WPF.
Jeg vil nødigt level uden docking modellen. En typisk grid layout som i GTK er utrolig fustrende at lave det mindste advancede layout med!
Jo? Derudover bruger man events i C#, hvilket også er implementeret nogenlunde (men dårligt) i GTK#.jopsen (14) skrev:WinForms har heller ikke actions og ikoner
På Windows er de mere rige en hvad GTK tilbyder. Ved ikke præcist hvor meget de har implementeret under Mono.jopsen (14) skrev:Og mange af deres widgets er ikke specielt rige... Label med markup findes f.eks. både i Qt og GTK og det er vildt fedt... ville godt nok nødigt leve uden...
Men tankegangen bag QT og GTK er god og dårlig. Windows Presentation Foundation, WPF, tager det bedste fra alle verdener, og giver et endnu bedre resultat.
Jeg håber meget på at Mono vil give sig i kast med opgaven, da GTK og QT udvikler sig utrolig langtsomt i forhold til WPF/WinForms.
#12 Ja, GTK har altid været fint understøttet under Mono. Men kun fordi at det var den lette løsning. At implementere .NET Framework'et uden System.Windows.Forms, svarer til at implementere Java uden swt, awt og swing. Eller VB6 uden ActiveX.
Og hvis man som virksomhed begynder at fedte rundt med GTK i .NET, så kan man næsten ligeså godt implementere projektet i Java. (Så slemt er Java heller ikke.) .NET Framework'et uden Windows.Forms er til gengæld et hobby-projekt.
Men som jeg nævnte tidligere, så er System.Windows.Forms ved at være på plads, brugbart og stabilt i Mono ;)
Og hvis man som virksomhed begynder at fedte rundt med GTK i .NET, så kan man næsten ligeså godt implementere projektet i Java. (Så slemt er Java heller ikke.) .NET Framework'et uden Windows.Forms er til gengæld et hobby-projekt.
Men som jeg nævnte tidligere, så er System.Windows.Forms ved at være på plads, brugbart og stabilt i Mono ;)
Et perfekt .NET Framework til *nix kunne være vildt fedt. Man ville ligeså stille kunne konvertere en hel *nix distribution til C# og på den måde reducere kode-mængden med, hvad 40-60%? (Og man vil stadigvæk have adgang til alle de eksisterende *nix-programmer.) Og hvis man ser bort fra macro'erne, så er ANSI C ret nemt at konvertere. Og der er rigtig meget ANSI C ;)
Damn, et godt overblik og indsigt man ville kunne få i en sådan distribution.
(Og nej, CosmOS og Singularity vil næppe nogensinde blive brugbare.)
... indtil da er jeg nødt til at forsætte med det her amatør Windows OS. Bah!
Damn, et godt overblik og indsigt man ville kunne få i en sådan distribution.
(Og nej, CosmOS og Singularity vil næppe nogensinde blive brugbare.)
... indtil da er jeg nødt til at forsætte med det her amatør Windows OS. Bah!
#16
Alt har en pris. Man kan vælge GTK# funktionaliteten og ikke have problemer med portabiliteten. Eller man kan vælge Win Forms og konstant skulle teste om de features man bruger nu virker.
Mono projektet siger selv (http://go-mono.com/status/status.aspx?reference=3.5&profile=2.0&assembly=System.Windows.Forms) om System.Windows.Forms assembly:
33 missing members
158 members som smider NotImplementedException
så der er stadig muligheder for problemer.
Alt har en pris. Man kan vælge GTK# funktionaliteten og ikke have problemer med portabiliteten. Eller man kan vælge Win Forms og konstant skulle teste om de features man bruger nu virker.
Mono projektet siger selv (http://go-mono.com/status/status.aspx?reference=3.5&profile=2.0&assembly=System.Windows.Forms) om System.Windows.Forms assembly:
33 missing members
158 members som smider NotImplementedException
så der er stadig muligheder for problemer.
#17
Jeg går ud fra at det kun er alle libraries og utilities du vil konvertere - ikke kernen.
Men det er vel også 95% af koden.
Og det burde give en reduktion i kode størrelsen for samme funktionalitet på ca. 60%.
Jeg er dog ikke sikker på at det er en nem konvertering. For at kunne opnå en optimal kode som faktisk ville være de 60% mindre skal der nok redesignes grundigt - ikke bare omskrive fra C til C#, men også omskrive fra C style til C# style.
Jeg går ud fra at det kun er alle libraries og utilities du vil konvertere - ikke kernen.
Men det er vel også 95% af koden.
Og det burde give en reduktion i kode størrelsen for samme funktionalitet på ca. 60%.
Jeg er dog ikke sikker på at det er en nem konvertering. For at kunne opnå en optimal kode som faktisk ville være de 60% mindre skal der nok redesignes grundigt - ikke bare omskrive fra C til C#, men også omskrive fra C style til C# style.
Ser ud til at der er navne dublikering.arne_v (24) skrev:GTK signals er et observer pattern implementeret i et proceduralt sprog
Signals i GTK og QT forstand er en række strings med tilknyttet string callback. Pointen er mere at det ikke er strong typed, og ideen om at sende strings istedet for at udnytte events i C# er utrolig dumt.
GTK# er bedre end QT# på det punkt. Men generelt har GTK# en række problemer i forhold til mapping, som jeg gerne så løst.
(Arbejder pt. på patches og koncept eksempler på API forbedringer)
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund