Hallo zusammen,
derzeit gibts Überlegungen, einen Neuen Anlauf in einem Programmierprojekt zu starten.
Es handelt sich hierbei um eine stark GUI-lastige Netzwerkanwendung, die direkt auf TCP und UDP aufbauen soll. Das ganze ist ein Hobbyprojekt mit 2 Mann.

Jetzt stehen wir vor der Frage, mit welchem Werkzeug das umgesetzt werden könnte. Delphi beherrschen wir beide, wären dann aber an Windows gebunden.
Als Alternativen, in die sich jeweils einer von beiden verstärkt einarbeiten müsste, wären Java oder C#.
Ideal wäre es zudem, wenn die Entwicklung ebenfalls auf verschiedenen Systemen (Windows und Linux) von Statten gehen kann.

Java ist in meinen Augen die bessere Variante, was Plattformunabhängigkeit angeht. Eclipse ist vollständig portiert und eine recht schöne IDE. Die Anwendungen hierzu sind auf beiden Plattformen gut ausführbar, da allermeistens die JVM schon installiert ist.
Was ich oft bei Java als große Schwäche höre, ist die GUI. Ich selbst habe mal ein kleines Tool mit Swing und dem einen GUI-Builder-Plugin in Eclipse gebastelt. Das Ergebnis war nciht unbedingt so toll (auch was nativen Look&Feel angeht). Vielleicht hab ich da auch einfach was falsch gemacht?!

Mit C# sehe ich folgendes:
Die Entwicklung ist mit Visual Studio Express in meinen Augen sehr effizient möglich. Dazu gibt es MonoDevelop, was allerdings keinen Windows.Forms Designer mitbringt (oder hab ich da was übersehen) und nicht mit Visual Studio 2008 direkt in einer Source-Repository zusammenarbeitet (*.sln als Beispiel).
Unter der Ausführung soll Mono (2.2) noch nicht ganz zu .NET 2.0 kompatibel sein. Auf Mono-project.org gibt es ein paar Artikel dazu, die erahnen lassen, wie groß der Aufwand ist, allerdings waren das sehr spezielle Projekte. Könnt ihr da Erfahrungswerte beisteuern?
Auch möchte ich nicht in die Situation kommen, dass am Ende, um die Anwendung ausführen zu können, auf Windows auch noch Mono installiert werden muss. Ebenfalls auch ungerne GTK#.
Ist das mit C# also unrealistischer als mit Java?

Die Bilbiotheken spielen (abgesehen von GUIs) glaube ich bei der Entscheidungsfindung eine untergeordnete Rolle. Es gibt in .NET/Mono, wie in der JRE ähnliche Klassen für Standardaufgaben, wie TCP- und UDP-Sockets, XML usw.

Diese Entscheidung hängt auch davon ab, ob wir genug Zeit finden, uns in eine neue Sprache und API einzuarbeiten. Ansonsten leibts wohl oder übel bei Delphi. Trotzdem würde ich das gerne hier diskutieren, weil mich das als Linuxer insgesamt auch interessiert.

Viele Grüße
alias5000

alias5000 hat folgendes geschrieben :

Was ich oft bei Java als große Schwäche höre, ist die GUI. Ich selbst habe mal ein kleines Tool mit Swing und dem einen GUI-Builder-Plugin in Eclipse gebastelt. Das Ergebnis war nciht unbedingt so toll (auch was nativen Look&Feel angeht). Vielleicht hab ich da auch einfach was falsch gemacht?!

Der Fehler dürfte "Swing" heißen . Eine ernsthafte GUI ist wohl nur in SWT möglich, ob das aber an die von Delphi/.Net gewohnte Qualität, v.a. in puncto Designer-Freundlichkeit, heranreicht, kann ich nicht sagen. Aber dass der Swing/SWT-Designer Eclipse um 2 Versionen hinterherhängt, finde ich ziemlich befremdlich .

alias5000 hat folgendes geschrieben :

Dazu gibt es MonoDevelop, was allerdings keinen Windows.Forms Designer mitbringt (oder hab ich da was übersehen)

Ja, gibt es nicht. MD ist in erster Linie eine Gtk#-IDE, man geht wohl davon aus, dass WindowsForms-Nutzer auch unter Windows programmieren.

alias5000 hat folgendes geschrieben :

und nicht mit Visual Studio 2008 direkt in einer Source-Repository zusammenarbeitet (*.sln als Beispiel).

Könnte sich mit 2.0 Beta 1 geklärt haben. Hoffe ich jedenfalls .

alias5000 hat folgendes geschrieben :

Unter der Ausführung soll Mono (2.2) noch nicht ganz zu .NET 2.0 kompatibel sein.

Der WindowsForms-Teil ist jedenfalls feature complete, das größte Problem dürfte also höchstens sein, dass es unter Linux nicht ganz das Aussehen einer nativen Gtk#-App erreichen wird.

alias5000 hat folgendes geschrieben :

Auch möchte ich nicht in die Situation kommen, dass am Ende, um die Anwendung ausführen zu können, auf Windows auch noch Mono installiert werden muss. Ebenfalls auch ungerne GTK#.

Wenn ihr auf Gtk# setzt, wird zwar auch .Net reichen, aber ohne die 8MB Gtk#-Libs wird's eben nicht funktionieren.

Kha hat folgendes geschrieben :

alias5000 hat folgendes geschrieben : Was ich oft bei Java als große Schwäche höre, ist die GUI. Ich selbst habe mal ein kleines Tool mit Swing und dem einen GUI-Builder-Plugin in Eclipse gebastelt. Das Ergebnis war nciht unbedingt so toll (auch was nativen Look&Feel angeht). Vielleicht hab ich da auch einfach was falsch gemacht?! Der Fehler dürfte "Swing" heißen . Eine ernsthafte GUI ist wohl nur in SWT möglich, ob das aber an die von Delphi/.Net gewohnte Qualität, v.a. in puncto Designer-Freundlichkeit, heranreicht, kann ich nicht sagen. Aber dass der Swing/SWT-Designer Eclipse um 2 Versionen hinterherhängt, finde ich ziemlich befremdlich .

Dito. Das offizielle Release arbeitet ja auch gar nicht mit Eclipse 3.3 und 3.4
Ich hab jetzt das Ding aber auf 3.4 zum Laufen gebracht. Naja, ich kenn ihn ja schon, was "Luxus" angeht.
Das mit SWT sieht schon viel besser aus.
Aber das sieht mir alles noch sehr komisch aus, da gibts noch viel zu tun.

Kha hat folgendes geschrieben :

alias5000 hat folgendes geschrieben : Unter der Ausführung soll Mono (2.2) noch nicht ganz zu .NET 2.0 kompatibel sein. Der WindowsForms-Teil ist jedenfalls feature complete, das größte Problem dürfte also höchstens sein, dass es unter Linux nicht ganz das Aussehen einer nativen Gtk#-App erreichen wird.

Gut zu wissen, dass es feature-complete ist Das ist mir bisher entgangen.

Kha hat folgendes geschrieben :

alias5000 hat folgendes geschrieben : Auch möchte ich nicht in die Situation kommen, dass am Ende, um die Anwendung ausführen zu können, auf Windows auch noch Mono installiert werden muss. Ebenfalls auch ungerne GTK#. Wenn ihr auf Gtk# setzt, wird zwar auch .Net reichen, aber ohne die 8MB Gtk#-Libs wird's eben nicht funktionieren.

Das ist doch widersinnig! Warum wird nicht ein Designer auf Windows.Forms aufgesetzt, damit man ne einheitliche Lösung hat? Ich mein, W.F ist ja eh implementiert. GTK# extra auf Windows zu installieren ist für mich ein No-Go, alleine wegen dem Look&Feel.
Damit scheidet MonoDevelop eher aus. Ich könnte natürlich die GUI-Angelegenheiten dann komplett in VSE machen, aber dann kann ichs dort auch komplett machen. Schade eigentlich.
Was für ein Toolkit ist eigentlich in W.F implementiert? Auf Screenshots sah das alles nicht ganz nach reinem gtk# aus?!

Abgesehen von diesen konkreten Fragen wird sich die Sache eh daran entscheiden, ob das Vorhaben mit ner teilweise neuen Sprache zeitlich überhaupt umsetzbar wird. Aber trotz allem ists interessant. Langfristig möchte ich auf dem Gebiet schon noch etwas unternehmen.

Gruß
alias5000

alias5000 hat folgendes geschrieben :

Das ist doch widersinnig! Warum wird nicht ein Designer auf Windows.Forms aufgesetzt, damit man ne einheitliche Lösung hat?

Deswegen :

www.mono-project.com/FAQ:_Winforms hat folgendes geschrieben:

Why not implement System.Windows.Forms on top of Gtk# or Qt#? Compatibility. Although it is possible to run simple Windows.Forms applications with the Gtk#-based backend of Windows.Forms, it is very unlikely that the implementation will ever implement everything needed for full compatibility with Windows.Forms. The reason is that Windows.Forms is not a complete toolkit, and to work around this problem some of the underlying Win32 foundation is exposed to the programmer in the form of exposing the Windows message handler (WndProc). Any control can override this method. Also developers often P/Invoke into Win32 to get to functionality that was not wrapped. To achieve full compatibility, we would have to emulate this, and it would take too long.

und (doppelt hält besser )

www.mono-project.com/WinForms hat folgendes geschrieben:

Why Not Use Native Widgets? It is not feasible to use native widgets on all operating systems. Each OS/Windowing system has different behavior/properties/features for what on the surface looks like the same widget. A RadioButton in Gnome is different from a RadioButton in Win32, which is different from a RadioButton in OS X. To use the native widgets means to reduce the functionality of MWF to the least common denominator of all supported operating systems. If we were designing our own GUI toolkit, this might even be acceptable, however we are implementing an already defined API with defined behavior (and even with application relied-upon side-effects). A RadioButton has to behave exactly like it behaves on Win32 with MS.Net, or else applications written for it may not work properly anymore. And that's the whole point of Winforms: to allow existing .Net SWF apps to run on Mono. For other uses, there are other choices that may be more appropriate, such as Gtk#.

alias5000 hat folgendes geschrieben :

Was für ein Toolkit ist eigentlich in W.F implementiert? Auf Screenshots sah das alles nicht ganz nach reinem gtk# aus?!

Das setzt aus oben genannten Gründen auf System.Drawing auf, was unter Linux wiederum Cairo nutzt.

Hier noch eine schöne Übersicht über das ganze Dilemma:
www.mono-project.com/Gui_Toolkits
Gerade die Screenshots am Ende zeigen, dass ein vereinheitlichtes Toolkit nicht ganz einfach werden dürfte.
Aber ich gebe schon zu, dass für Anwendungen, die auf jeder Plattform nicht perfekt sondern akzeptabel aussehen müssen, .NET kein geeignetes Toolkit anbietet.

alias5000 hat folgendes geschrieben :

GTK# extra auf Windows zu installieren ist für mich ein No-Go, alleine wegen dem Look&Feel.

Ich bin Linux-User und benutze Gnome wegen dem Design-Considerations die die Leute mal getroffen haben, für mich wäre eine WinForms-Anwendung aus dem gleichen Grund ein No-Go. Und nu?
Wenn du plattformunabhängig Programmieren willst, bleibt dir kaum was anderes übrig, als entweder das Frontend immer wieder neu zu implementieren, oder in den sauren Apfel zu beißen und irgendeiner Anwendergruppe eine Anwendung vorzusetzen, die nicht so aussieht, wie sie es gewohnt ist und die sich auch nicht so bedient und verhält, wie sie es gewohnt ist.
Dei größten Krücken an Anwendungen unter Linux sind für mich jene proprietären, die für Windows entwickelt wurden und irgendwann portiert wurden. Ob es nun früher Kylix war oder heute Google Earth, Skype und Azureus. Sieht *mist*e aus, verhält sich *mist*e, erzeugt meistens Frust. Das fängt für mich auch schon an, wenn ich KDE-Anwendungen benutze.

Kha hat folgendes geschrieben :

Aber ich gebe schon zu, dass für Anwendungen, die auf jeder Plattform nicht perfekt sondern akzeptabel aussehen müssen, .NET kein geeignetes Toolkit anbietet.

Why not? Gtk+ sieht auf allen Plattformen außer OSX gut aus, und auf OSX auch nur deshalb nicht, weil es keine native Engine für mit ohne X-Server gibt. wxWidgets bringt alles wenigstens auf den kleinsten gemeinsamne Nenner und spricht auch Cocoa. Und WinForms sehen einfach überlal gleichermaßen *mist*e aus
Das Toolkit, das sich auf allen Plattformen nahtlos in die entsprechende Umgebung einbettet kann es nicht geben, wie du ja schon erkannt hast.
Blieben noch die entsprechenden Java-"Toolkits", mit denen fühlt sich wenigstens kein einziger Anwender zuhause, es wird also niemand bevorzugt

Ich würde die Entscheidung vielmehr davon abhängig machen, womit ich mich als Programmierer wohlfühle, sprich womit ich schneller an mein Ziel komme.