Plattformunabhängig programmieren

[Mithrandir]

@Feuervogel:
Der einzige Nachteil wäre vielleicht, dass WPF-Anwendungen nicht von Mono unterstützt werden...

[Phoenix]

Nicht unbedingt.
Silverlight ist am kommen, und SL-Anwendungen kann man auch auf dem Desktop laufen lassen (out-of-browser applications). Und mit Moonlight gibt es die Mono-Version von Silverlight auch auf allen Plattformen - auch mit out-of-browser support.

[BUG]

Wenn Java als Sprache nicht gefällt, gibt es auch einige andere interessante Sprachen (z.B. Scala, Gosu) die auf der JVM laufen und Java-kompatibel sind.

[fkerber]

Hi,

erstmal wow für die Vielzahl und die Länge der Antworten, danke.


@Phoenix:
Danke für die Ausführungen, jetzt bin ich schlauer.


@Unwissender:
Ich habe diese Aussage zum Anlass genommen, um mal "über den Tellerrand" zu schauen.
Natürlich renne ich jetzt nicht los und suche was anderes, nur weil jemand gesagt hat "Java ist doof" - und mir sind die Vorteile von Java ja ebenfalls geläufig und ich weiß sie zu schätzen. Allerdings hat mich gerade die GUI-Entwicklung beim letzten Projekt nahezu in den Wahnsinn getrieben und mich viel Zeit gekostet, damit es wenigstens ansatzweise manierlich aussah - und trotzdem war es hässlich. Dazu kommen dann auch so Sachen, dass bspw. unter Mac die Tastenkombis zum Kopieren, Einfügen etc nicht wie gewohnt mit Apfel+C/V funktionieren sondern nur mit Strg+C/V - das ist für Otto-Normal-Nutzer ungewohnt und vllt. sogar unhandlebar, weil er nicht auf die Idee kommt etc. Auch die Integration ins Fenster-Schließen-Konzept von Mac geht von Haus aus nicht wie sie soll, sondern erfordert ein extra Eingreifen etc. - halt so viele Kleinigkeiten.

Daher will ich einfach mal schauen, was es da sonst so gibt. Da ich privat gänzlich unter Mac unterwegs bin (von VMs abgesehen) sind schon alleine wegen der Verbreitung von Windows Lösungen für mich interessant, die ich sowohl für mich programmieren kann, aber vllt. auch irgendwo "unters Volk" bringen kann (und dann sollte Volk nicht auf Mac-User beschränkt sein).
Dank Android werde ich Java so oder so nicht so schnell den Rücken kehren, aber ich denke, es schadet nichts, auch mal was anderes anzutesten.


@Rollstuhlfahrer
Das mit Python ist auch durchaus interessant.
Wie im Eingangspost erwähnt habe ich auch schon einiges mit Python gemacht und die Sprache und Ihre Funktionalitäten finde ich auch recht sympathisch. Allerdings waren das bislang reine Entwicklung für Multi-Touch-fähige Eingabegeräte mit einer speziellen Bibliothek, die sowohl das Tracking übernimmt, wie auch sämtliche grafische Elemente zur Verfügung stellt (--> www.libavg.de ). Ist ne nette Sache, aber eben nicht für normale Alltagsprogramme sondern quasi nur solche Programme, deren GUI komplett durch Grafiken bzw. zumindest grafische Elemente dargestellt wird (und nein, ein normaler Button ist kein grafisches Element in dem Sinne, den ich meine ).

Also mal schauen, was es da gibt, um normale GUIs zu produzieren.
Gibt es "prominente" Programme, die mit normaler GUI in Python geschrieben sind?


@BUG:
Doch doch, Java als Sprache gefällt (zumindest mir) - meine Aufgaben konnte ich damit bisher gut umsetzen, solange sie keine GUI hatten


Liebe Grüße,
Frederic

[JamesTKirk]

QuickAndDirty hat zwar schon Free Pascal und Lazarus angesprochen, ich möchte da jedoch noch etwas ausholen.

Erstmal Free Pascal ist ein Open Source Object Pascal Compiler und für unterschiedliche Plattformen (x86, x86_64, ARM, Sparc, Power PC) und Betriebssysteme (u.a. Windows, Windows CE, Linux, Mac OS X, BSD, Solaris, DOS, OS/2) verfügbar. Der Compiler kompiliert die Anwendungen nativ für die jeweilige Zielplatform, ist also dann an den CPU Typ und das Betriebssystem gebunden (im Gegensatz zu Java, manchen .NET Programmen und den Scriptsprachen).

Aber auch wenn die Anwendung binär an ein bestimmtes Betriebssystem gebunden ist, so bietet Free Pascal eine plattformunabhängige RTL (so Sachen wie Writeln, TList, etc) und die Möglichkeit Code nur für bestimmte Plattformen zu kompilieren (wie es in Delphi ja auch möglich ist). Auch das Einbinden von anderen Bibliotheken (DLL, SO, Dynlib), welche eine flache C API bereitstellen, ist relativ einfach möglich (das berühmte "external 'Foo' name 'Bar'"). In der Entwicklungsversion des Compilers kannst du sogar Objective-C Klassen anbinden (hierzu wurde von der Mac Community eine eigene Spracherweiterung namens Objective Pascal entwickelt).

Das Kompilieren von verschiedenen Betriebssystemen nach Windows und Windows CE ist im großen und ganzen ohne weitere Verrenkungen möglich (dank internem Linker und zumindest für x86 und x86_64 auch internem Assembler). Um von Windows nach Linux zu kompilieren benötigt man schon passende Binutils (vor allem Linker) und die Bibliotheken des Zielsystems (z. B. libc, libpthreads, libgtk, etc.). Letzteres kann auch mal ein Problem sein, wenn du ein auf z. B. einem ArchLinux kompiliertes Programm (mit solchen Abhängigkeiten) auf einem Ubuntu laufen lassen möchtest, da ersters andere (meist neuere) Bibliotheken verwendet (Linux ist da etwas unverzeilicher als Windows). Hier hilft dann nur auf dem Zielsystem neu kompilieren. Das Cross Kompilieren nach Mac OS X ist dann (sowohl von Windows, als auch von Linux) ein noch größerer Terz (ähnliche Problematik wie unter Linux, nur noch etwas kopfzerbrechender).

Kompilierst du allerdings auf der jeweiligen Zielplatform (Windows CE und iPhone mal ausgenommen), hast du mit den Bibliotheken kaum Probleme.

Free Pascal alleine bietet allerdings keine GUI (von FreeVision, einem Klon von TurboVision für die Textmode IDE mal abgesehen). Du kannst natürlich auf die verschiedenen GUI Toolkits zugreifen (WinAPI, GTK(2), Qt, Carbon, Cocoa), musst allerdings für jedes Toolkit ne Extrawurscht machen (bei GTK und Qt etwas weniger, da diese auch auf anderen Plattformen als Linux laufen).
Möchtest du jedoch plattformunabhängig mit GUI arbeiten, so sind drei bekanntere Varianten möglich:

• LCL
• fpGUI
• MSEgui

Ersteres wird von der Delphi ähnlichen IDE Lazarus zur Verfügung gestellt und lässt sich ähnlich zur VCL verwenden. Die Entwickler streben danach LCL-Anwendungen auf dem jeweiligen System so nativ wie möglich aussehen zu lassen. Für die Plattformunabhängigkeit wurde eine Abstraktionsschicht, das sogenannte Widgetset eingeführt und erlaubt es dir zu bestimmen, ob eine kompilierte Anwendung nun die WinAPI oder Qt (als Beispiele) verwendet. Du kannst so zum Beispiel auch Qt Anwendungen für Windows entwickeln (nicht alle Kombinationen machen allerdings Sinn, wie Cocoa auf Windows CE). Diese Abstraktionsschicht bringt allerdings auch Performanceeinbußen mit sich. Ich persönlich empfinde diese jedoch nicht als so gravierend wie von Hisoka beschrieben. Hier empfehle ich dir (falls näheres Interesse besteht) einfach mal die IDE herunterzuladen und zu schauen, ob dir die Performance ausreicht (wobei du hier eventuell warten solltest, da sich zur Zeit ein neues Release in Vorbereitung befindet - das "aktuelle" ist bereits über ein Jahr alt und dementsprechend viel hat sich seitdem geändert).

Im Gegensatz zur LCL sind fpGUI und MSEgui komplette Neuentwicklungen. Beide haben den selben Look der Anwendung unter allen unterstützten Plattformen zum Ziel. Zu MSEgui kann ich jedoch nicht viel sagen, da ich mich noch nicht damit auseinandergesetzt habe. fpGUI ist jedoch näherungsweise ähnlich zur LCL/VCL und unterstützt zur Zeit Windows und Linux (bzw. allgemeiner: X-Server basierte Systeme). Mac OS X Unterstützung sowie Unterstützung für Open GL und Linux Framebuffer als Backend sind in Entwicklung bzw. Planung. Während mseGUI eine komplette eigene IDE (MSEide) mitbringt, bietet dir fpGUI nur einen Formulardesigner an. Der eigentliche Code wird in der IDE deiner Wahl (MSEide, Lazarus, Free Pascal IDE) entwickelt.

Ich persönlich bin sehr zufrieden mit Free Pascal und Lazarus (fpGUI teste ich hin und wieder aus). Die "Cross Compile" Funktionalität setze ich vorwiegend ein, um Anwendungen für Windows CE zu entwickeln (Hauptentwicklung/-test unter Win32, Details korrigieren dann unter WinCE). Die Variante Linux => Windows verwende ich seltener. Ich habe jedoch einiges an Code, den ich unter Linux und Windows verwende und weiterentwickle, wobei kaum IFDEFs vorhanden sind.

Ich hoffe dies hat dir einen kleinen Einblick gegeben.

Edit: Link zu fpGUI korrigiert.

Gruß,
Sven

[rollstuhlfahrer]

Zitat von fkerber:

Gibt es "prominente" Programme, die mit normaler GUI in Python geschrieben sind?

Auf Anhieb fällt mir da nur Calibre ein (eBook-Sortierprogramm). Ansonsten habe ich eine Liste gefunden. Ob die alle jetzt GUI haben weiß ich nicht. Aber lang ist die Liste.

Bernhard

[Insider2004]

Ich arbeite jetzt schon 10 Jahre plattformunabhängig. Der Witz ist, man braucht es einfach nicht. 90-95% aller Kunden verwenden die Windows Plattform. Die paar Prozent, die mit Linux oder Mac arbeiten sind wirklich teuer für eine Entwicklung. Es lohnt sich einfach nicht Cross-Software anzubieten. Ich bestreite alles mit Delphi auf Windows. Ist schnell, native und (fast) fehlerfrei. Die Karten werden neu gemischt, wenn Delphi für Mac dieses Jahr rauskommt. Viel verdienen wird man an einem Mac-Port aber nicht, so meine Einschätzung.

[Die Muhkuh]

Zitat von Insider2004:

Es lohnt sich einfach nicht Cross-Software anzubieten.

Das kommt wohl sehr auf die Software an, die Du erstellst.

[mkinzler]

Je kleiner der Aufwand für eine Portierung, desto niedriger die Hürde und desto mehr lohnt es sich. Es gibt ja Softwarehersteller, die nur für MacOSX entwickeln und die davon leben können.

[Insider2004]

Zitat von Die Muhkuh:

Zitat von Insider2004:

Es lohnt sich einfach nicht Cross-Software anzubieten.

Das kommt wohl sehr auf die Software an, die Du erstellst.

Das ist richtig. Wenn man nur cmd-line-Tools und dergleichen entwickelt dann ist es relativ einfach. Bei GUI wird es verdammt schwierig bis unmöglich.