Folgendes Problem: Habe ein Programm mit .net geschrieben, funktioniert auch bestens. (sharp development). Kann das ganze auch nach C# exportieren, das sollte die Sache vereinfachen. Das ganze soll jetzt auch als Mac-Version angeboten werden, ich selbst habe aber mit Apple noch nie was zu tun gehabt, dürfte also einige Zeit dauern, bis da was sinnvolles rauskommt :-) Kann mir jemand etwas unter die Arme greifen? Oder das komplett übernehmen?
Mit Mono könntest Du Chancen haben: http://mono-project.com/Mono:OSX
Gast
#1235833
wenn du m$-spezifische libs vwerendest wird's haarig, das läuft dann meistens auf neu programmieren der gui hinaus.
H.joachim Seifert wrote: > Folgendes Problem: > Habe ein Programm mit .net geschrieben, funktioniert auch bestens. > (sharp development). Kann das ganze auch nach C# exportieren, das sollte > die Sache vereinfachen. Das ganze soll jetzt auch als Mac-Version > angeboten werden, ich selbst habe aber mit Apple noch nie was zu tun > gehabt, dürfte also einige Zeit dauern, bis da was sinnvolles rauskommt > :-) > Kann mir jemand etwas unter die Arme greifen? Oder das komplett > übernehmen? Würde zuerst mit dem Mono Migration Analyzer nachsehen wo es Probleme geben könnte, dann kann man Überlegen was man weiter machen will/muss. http://mono-project.com/MoMA zwieblum wrote: > wenn du m$-spezifische libs vwerendest wird's haarig, das läuft dann > meistens auf neu programmieren der gui hinaus. Welche? Oder nur alles was P/Invoke benutzt oder WinForms etc. Letzteres ist mittlerweile so gut wie vollständig implementiert.
Gast
#1236030
in der regel alles was mit gui zu tun hat. du brauchst ein gui framework oder darfst nur jenen teil deines frameworks nehmen, das auf mac und windows existiert - und linux, wenn wir schon dabei sind, target ist ja mono. was existiert und was nicht ist eher rätselraten und ausprobieren. winforms existieren teilweise in mono. wie weit du kommst musst du ausprobieren. installier' mal mono auf windows und versuche das projekt zum laufen zu bringen.
Na gut, dann schon mal vielen Dank. Ich hatte gehofft, es findet sich jemand, der es kann oder zumindest ein wenig Erfahrung in der Mac-Welt hat und es machen möchte :-) Gibts evtl. einen Windows-Emulator für den Mac? Das wäre auch in Bezug auf die Wartung des ganzen ein Vorteil, wenn das Windows-Programm dort laufen würde.
> Gibts evtl. einen Windows-Emulator für den Mac? Das wäre auch in Bezug > auf die Wartung des ganzen ein Vorteil, wenn das Windows-Programm dort > laufen würde. Sofern es ein Intel-Mac ist, kannst Du entweder Windows in einer virtuellen Maschine laufen lassen (z.B. mit VMware Fusion oder Parallels Desktop) oder aber WINE bzw. dessen kommerziellen Ableger Crossover verwenden. PPC-Macs können mit Microsoft Virtual PC auch Windows emulieren, das aber mit wirklich grottiger Performance.
Gast
#1236268
wie soll ich das ausdrücken ... wegen einem einzigen programm wird dir kein mac-user windows anwerfen. entweder machst du's ordendlich oder du läßt es. der witz von m$ mit .net ist ja eben, dass es nicht portabel ist - aber alle dran glauben bis sie's ausprobieren.
Rufus t. Firefly wrote: > oder aber WINE bzw. dessen kommerziellen Ableger Crossover > verwenden. Wenn man versucht mit wine ein .NET Programm zu starten (auch wenns als .EXE verpackt ist) kommt nur ne schnöde Textmeldung, dass man es doch bitte stattdessen mit Mono versuchen soll :) das hat zumindest mit dem AVR-.Net-IO Programm von Pollin dann funktioniert: Beitrag "Pollin Net-IO: Original-Software?"
zwieblum wrote: > in der regel alles was mit gui zu tun hat. du brauchst ein gui framework > oder darfst nur jenen teil deines frameworks nehmen, das auf mac und > windows existiert - und linux, wenn wir schon dabei sind, target ist ja > mono. was existiert und was nicht ist eher rätselraten und ausprobieren. > winforms existieren teilweise in mono. Da ist nichts mit Rätselraten dabei. Siehe Link zum MoMA. WinForms ist so gut wie vollständig oder wie es so auf der Seite steht: "Currently, all of the controls are pretty much complete. We are now mainly fixing bugs in our implementation.". Sonst im entsprechenden Blog nachlesen: http://jpobst.blogspot.com/ Gleiches gilt auch für ASP.NET inkl AJAX > wie soll ich das ausdrücken ... wegen einem einzigen programm wird dir > kein mac-user windows anwerfen. entweder machst du's ordendlich oder du > läßt es. der witz von m$ mit .net ist ja eben, dass es nicht portabel > ist - aber alle dran glauben bis sie's ausprobieren. FUD s.o.
Gast
#1236476
wenn "H.joachim Seifert" sein projekt da durch jagt, wissen wir ja bald ob's wirklich so einfach geht. .
Gast
#1238443
Wirklich portablen Programmcode, aus dem frickelfrei auf Knopfdruck lauffähige Programme für drei Plattformen (Win, Mac OS X, Linux) entstehen, kann man derzeit m.E. nur mit zwei Werkzeugen erstellen: - Java - RealBasic Vor Allem wenn man Wert darauf legt, dass die Oberfläche jeweils nativ aussieht und sich auch so verhält, wie es der jeweilige Nutzer erwartet. Das ist m.E. der größte Mangel vieler z.B. mit Qt gestrickter Tools ... Frank
Gast
#1238483
oder aus der anderen ecke: - lispworks - allegro cl
Gast
#1238494
Frank wrote: > Wirklich portablen Programmcode, aus dem frickelfrei auf Knopfdruck > lauffähige Programme für drei Plattformen (Win, Mac OS X, Linux) > entstehen, kann man derzeit m.E. nur mit zwei Werkzeugen erstellen: > > - Java > - RealBasic > > Vor Allem wenn man Wert darauf legt, dass die Oberfläche jeweils nativ > aussieht und sich auch so verhält, wie es der jeweilige Nutzer erwartet. Ich habe noch keine Java-Anwendung gesehen, die auf dem Mac nativ aussieht und sich auch so verhaelt. Und ein guter Teil der wirklichen Java-Anwendungen (nicht nur kleine Tools), laeuft gleich gar nicht.
Gast
#1238533
>Ich habe noch keine Java-Anwendung gesehen, die auf dem Mac nativ >aussieht und sich auch so verhaelt. Und ein guter Teil der wirklichen >Java-Anwendungen (nicht nur kleine Tools), laeuft gleich gar nicht. Mit ein wenig gutem Willen geht das schon. Das Programm "Sweet Home 3D" ist z.B. in Java geschrieben und man merkt es eigentlich nicht: http://www.sweethome3d.eu/de/ Frank
Gast
#1238739
doe meisten programmierer wissen nicht wie sie plattformunabhängig arbeiten sollen. alleine der pfadseperator wird von 90% als "\\" hart kodiert, anstelle das ding aus java.io.File.pathSeparatorChar zu beziehen. der beispiele gibt es leider viele. man glaubt ja gar nicht wie erfinderisch wunderwuzzis da sind.
Frank wrote: >>Ich habe noch keine Java-Anwendung gesehen, die auf dem Mac nativ >>aussieht und sich auch so verhaelt. Und ein guter Teil der wirklichen >>Java-Anwendungen (nicht nur kleine Tools), laeuft gleich gar nicht. > > Mit ein wenig gutem Willen geht das schon. Das Programm "Sweet Home 3D" > ist z.B. in Java geschrieben und man merkt es eigentlich nicht: > > http://www.sweethome3d.eu/de/ > > Frank Man sieht's am Dateiauswahldialog, an den massiven Redraw-Fehlern beim Ändern der Fenstergröße, am sehr langsamen Neuaufbau des Fensters danach, an den Redraw-Fehlern beim Scrollen, an den Toolbar-Icons, an der Anordnung der Schaltflächen in Dialogen...
zwieblum wrote: > doe meisten programmierer wissen nicht wie sie plattformunabhängig > arbeiten sollen. alleine der pfadseperator wird von 90% als "\\" hart > kodiert, anstelle das ding aus java.io.File.pathSeparatorChar zu > beziehen. der beispiele gibt es leider viele. man glaubt ja gar nicht > wie erfinderisch wunderwuzzis da sind. Nur der Vollständigkeithalber: - pathSeparatorChar -> "This character is used to separate filenames in a sequence of files given as a path list. On UNIX systems, this character is ':'; on Win32 systems it is ';'." - separatorChar -> "The system-dependent default name -separator character. [..]. On UNIX systems the value of this field is '/'; on Win32 systems it is '\'."
Gast
#1240784
oops, soory :-)
Ich ärgere mich jedes Mal über das hässliche \ auf dem Windows. Nur Probleme gibt es damit, weil der Bill an dieser Stelle seine Kreativität uns zeigen wollte :)
Daniel -------- wrote: > Ich ärgere mich jedes Mal über das hässliche \ auf dem Windows. > Nur Probleme gibt es damit, weil der Bill an dieser Stelle > seine Kreativität uns zeigen wollte :) Wenn man keine Ahnung hat... http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maximum_path_length "Note File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections." Gleiches gilt auch für cmd.exe/die Eingabeaufforderung und den Explorer.
Gast
#1241474
ich lese und staune. alt kann das noch nicht sein, unter win2000 wars sicher noch nicht so implementiert. unter xp? keine ahnung, soll mal wer prüfern.
Win98: Unter Java: Egal ob / oder \ Ausführen --> c:/windoWS/desktop/ funktioniert, ebanso in der Adresszeile von IE... command.com --> geht nicht / wird als parameterübergabe interpretiert, Anführungszeichen führen dazu das alles hinter / ignoriert wird.
Command.com von Windows 98 ist DOS. Das kann nicht mit der "Eingabeaufforderung" ernstgemeinter Windows-Versionen verglichen werden. Sieht zwar ähnlich aus, ist aber was komplett anderes.
zwieblum wrote: > ich lese und staune. alt kann das noch nicht sein, unter win2000 wars > sicher noch nicht so implementiert. unter xp? keine ahnung, soll mal wer > prüfern. Seit MSDOS 2.0! Zu verdanken ist das allerdings IBM (siehe Kommentare auf der Seite). http://blogs.msdn.com/larryosterman/archive/2005/06/24/432386.aspx
Gast
#1241913
> Wirklich portablen Programmcode, aus dem frickelfrei auf Knopfdruck > lauffähige Programme für drei Plattformen (Win, Mac OS X, Linux) > entstehen, kann man derzeit m.E. nur mit zwei Werkzeugen erstellen: > > - Java > - RealBasic > > Vor Allem wenn man Wert darauf legt, dass die Oberfläche jeweils nativ > aussieht und sich auch so verhält, wie es der jeweilige Nutzer erwartet. Imho fehlt da Qt.
Gast
#1242598
und wxwidgets http://wxwidgets.org/
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.