Tut für Socket/Window

[tiris]

Hi,
ich hab vor ein kleines frontend (oder so ähnlich) für meinen Linuxserver zu bauen. Sollte unter Windoof laufen, wäre klasse wenn man es einfach portierten könnte.

Mein Problem:
--> Tut für Socketprogrammierung (Netzwerkverbindung zum Server)
--> Tut für Fenster/Grafikprogrammierung (Textkonsole kann ich auch gleich per ssh haben)

Hat jemand was?
Ich bisher nur entweder sauteure oder absolut sinnlose Bücher gesehen die erklären dass ich mit VC von M$ für 1.000.000 U$ schöne Fenster automatisch erstellen und dann beutzen kann. Will ich aber selbst stricken.

Gruß tiris

[peschmae]

da stellt sich die Frage der Programmiersprache:

C/C++/Java/Perl/Python/...

und die des zu verwendenden Toolkits:

Qt/Gtk/Fox/Fltk/Swing/SWT/WxWindows/...

du musst halt schon ein bisschen konkreter werden. Oder hast du noch keine Ahnung?

MfG Peschmä

[tiris]

C wäre voll cool weil ich da an der Kommandozeile (Also einfach Programme die keine graphische Ausgabe erfordern) schon recht fit bin.
Mit c++ könnte ich mich auch anfreunden, aber dann muss auch noch was dabei sein dass das Klassenkonzept erläutert.

Toolkit ist mir Wurst. Wenn's ohne ginge, so zu Fuß wäre ich auch zufrieden. Unter Win benutze ich den DEV-cpp von www.bloodshed.net . Mit dem bin ich voll zufrieden bis jetzt. Der kann auch Fenster machen, aber das ist dann auch so 'ne automatische Sache und ich würde es ja gerne selbst machen.

Gruß tiris

[tuxipuxi]

hi,

wenn du gerne das gerne mit C machen möchtest empfehle ich dir Gtk+( http://www.gtk.org ).
das ist das unter unix/linux meistbenutzte C toolkit mit bindings für viele andere sprachen.


gruss,
tuxipuxi.

[Lin728]

Grafische Programme (GUI) mit C zu schreiben ist eher unangenehm.

Objectorientierte Programmierung ist gerade beim erstellen von grafischen Oberflächen was feine

[peschmae]

Ich kann Ceisserer eigentlich nur zustimmen. Am besten informierst du dich mal erst möglichst objektiv über Gtk, Qt und Swing. Eventuell noch WxWindows.

Allerdings würde ich den Unterschied zwischen Konsolenprogrammierung und GUI-Programmierung keineswegs unterschätzen. Vor allem OOP muss erst mal verstanden sein - sonst bringts nichts und du nutzt die Vorteile überhaupt nicht aus.

Auf jeden Fall würde ich neben den "ernsthaften" Programmiersprachen (C, C++, Java) auch die Scriptsprachen - hier vor allem Perl und Python nicht aus den Augen verlieren. Mit diesen kann man oft sehr viel schneller zum (genau gleichen) Ziel kommen - unter Verwendung irgend eines "normalen" Toolkits.

MfG Peschmä

[tiris]

GTK+ scheint für meine Anforderungen ganz geeignet zu sein. Ich hab auch nichts gefunden das die Portabilität einschränken könnte, oder lieg' ich da falsch?

gruß tiris

[peschmae]

Natürlich gibts ne Windows-Version von Gtk. Aber die Portierung dahin ist nicht ganz ohne. Schlussendlich gibts von den wenigsten Gtk-Programmen die ich kenne Windows-Portierungen (z.B. Gimp, Gaim)

Mit Gtk hast du dich aber noch nicht für eine Programmiersprache enschieden. Gtk selber ist in C geschrieben, das aber um Objektiorientierung erweitert wurde. Zudem gibts noch Bindings für C++, Python, Perl, C#, Java,...

MfG Peschmä

[anda_skoa]

Ich denk am einfachsten ist es in Java.

Sonst musst du dir entweder ein Toolkit suchen, das auch Sockets Crossplatform hat, oder umständlich den Socketcode auf jeder Plattform anpassen.

Ciao,
_

[Lin728]

anda_skoa hat (wiedermal) recht: Am einfachsten gehts wohl mit java...

Bei den Scripsprachen hast du das Problem dass bindings für die entsprechende Sprache installiert sein müssen....

[tiris]

Also ich kenne ja den Unterschied zwischen normalen und Skriptsprachen. Die einen arbeiten wie Pascal oder eben Java einen Quelltext Schritt für Schritt ab, der muss dann aber nicht kompiliert werden. -->läuft langsamer, aber ist mit Laufzeitumgebung auf jeder unterstützen Plattform lauffähig.
Die anderen können nur im kompilierten Zustand ausgeführt werden. --> läuft schneller, aber nur auf der kompilierten Plattform.

Da aber auch Java einen kleinen Compiler (und Linker und so, ich weiß, aber ich will nicht alles aufzählen) an Board hat kann ich die Sachen doch nach dem Linken und dem Präkompilieren als Maschinencode in den Compiler von einer C-Umgebung laden und habe dann alle Vorteile die es gibt, oder?

gruß tiris

[Lin728]

Grüssi!



Da aber auch Java einen kleinen Compiler (und Linker und so, ich weiß, aber ich will nicht alles aufzählen) an Board hat kann ich die Sachen doch nach dem Linken und dem Präkompilieren als Maschinencode in den Compiler von einer C-Umgebung laden und habe dann alle Vorteile die es gibt, oder?



Wenn du Java von SUN benutzt, wird Java immer interpretiert (also es wird erst zur Laufzeit in Maschienencode übersetzt).

Bei einer Scripsprache ist der Ablauf folgender:
1.) Quellcode einlesen, Sythax checken und in ein universelles bytecode-format übersetzten.
2.) Universellen bytecode für den jeweiligen Prozessor in Maschienensprache übersetzten. Dies erfolgt Schritt für Schritt und ist daher langsam.

(Ich weiß dass klingt sinnlos, aber Perl und Python machen es genau so)

Bei Java findet 1.) im Java-Compilier statt und die Runtime übernimmt den 2. Teil.
Da dies aber zu langsam war, hat man sich eine Menge an Optimierungsmethoden einfallen lassen, somit ist Java zur schnellsten interpretierten Sprache geworden die es gibt (auch wenn .NET schön langsam aufhohlt). Der neue HotSpot-JIT (just in tmie compilier = zur laufzeit compilier) merkt sich jene stellen, die besonders oft durchlaufen werden und führt z.b. nur auf diesen aggressive Optimierungen aus, die sich Stellen die nur ein paar mal aufgerufen werden nicht auszahlen.
Teilweise ist HotSpot sogar schneller als C, aber das sind eher Ausnahmefälle.

Java ist aus zwei Gründen langsamer als C++:
1.) Es übernimmt sehr viele Aufgaben des Programmierers, wie z.B. Arraybereichs-Überprüfungen und Speichermanagement, und das kostet natürlich zeit.
2.) Es ist trotz der vielen Optimierungen noch immer eine mehr oder weniger interpretierte Sprache.

Einen precompiler gibts in java überhaupt gar nicht, sowas machen eigene Tools wenn mans unbedingt braucht.
Auch einen Linker in dem Sinn wie bei nativen Sprachen gibts eigentlich nicht, dass erledigt die Runtime zur Laufzeit.

Aber Java ist bis auf SWING (was angeblich in Java-1.5 viel besser werden soll (OpenGL, neues Metal-Theme)) eine wirklich runde Sache, schade ist nur, dass es nicht OpenSource ist was natürlich immer Risiken in sich birgt.

[tiris]

Keine Möglichkeit den Maschinencode beim Ausführen abzugreifen und dann anständig zu compilieren? :(

Schade.

Aber ansonsten denke ich ist Java dann doch ganz nett.

gruß tiris

[peschmae]

Nein.

Allerdings gibt es schon native Compiler für Java. Die sind aber nicht sehr weit verbreitet.

Beispiele sind:
gcj (teil von gcc): http://gcc.gnu.org/java als freie Software

GCJ hat allerdings nicht die komplette Klassenbibliothek von Java implementiert. SWT funktioniert. Swing fehlt und AWT ist auch noch nicht fertig.

und dann jede Menge kommerzielle:
http://www.excelsior-usa.com/jet.html - für Win, komplette Klassenbilbiothek

und dann gibts noch jede Menge anderer. Wie gross da dann der Performancegewinn ist und so ist aber auf einem anderen Blatt geschrieben.

MfG Peschmä

[tiris]

Ich denke ich benutze dann mal Java. hat einer einen guten Literaturtipp zu Java, weil da muss ich mich dann doch mehr reinarbeiten als bei C/C++. So ein Buch dass einem da verschiedene Kleinigkeiten erklärt und Nebenbei noch OOP vermittelt wäre ganz nett.

Tipps zur IDE?
Oder lieber ohne?

Gruß tiris

[peschmae]

gratis:
Javabuch: www.javabuch.de
und zum vertiefen (auch gratis)
Thinking in Java: www.bruceeckel.com

und zum kaufen & vertiefen
Core Java 1 & 2

Zum Anfangen sicher ohne IDE arbeiten. Nachher würde ich mir mal Eclipse/Netbeans/JBuilder anschauen, wobei ich Eclipse bevorzuge (SWT ist schneller als Swing).

MfG Peschmä

[tiris]

Ich hab mir mal das sdk von der Sun page runtergeladen, muss allerdings sagen, dass das mit der PATH Variable bei mir nicht geklappt hat. Ich hab zwar den richtigen Pfad eingetragen und so, aber "#erde> javac hello.class" hat einfach nicht gefunzt. "#erde> java hello.class" brachte zwar eine Ausgabe, allerdings nur die Fehlermeldung, dass ein Fehler im Quellcode wäre. Ich denke ich schau mir mal die anderen Umgebungen an, und ob ich dann auch anständig an der Shell kompilieren kann. Zum Glück hab ich vorher ein Backup gemacht, das doofe Ding hat mir alle Systemvariablen zum Teufel geschickt.

Danke für den Buchtipp.

Hab's mir mal runtergeladen. Scheint nach der ersten kurzen Übersicht nicht schlecht. Bin aber weiterhin für Tipps offen.

gruß tiris

[Lin728]

Grüssi!

Nun, so gesehen hat das Ausführen einer .class-Datei nix mit $PATH zu tun....
In Path steht nur, dass du einfach java eingeben kannst und nicht andauernd /usr/lib/java2/jdk/jre/bin/java order ähnlihes eingeben musst.

Schau mal bezüglich Groß/Kleinschreibung etc., vieleicht liegt da was im Argen?

lg

[peschmae]

Nein. Das was im Argen liegt - und zwar arg, aber das ist nicht ungewöhnlich, das ging mir auch so - ist die Bedienung der Tools:



Hello.java:

public class Hello {
public static void main(String[] args) {
System.out.println("Hallo");
}
}


Kompilieren (java->class): "javac Hello.java"
Ausführen (interpretieren): "java Hello"

Das Interpretieren _ohne_ die .class-Endung. Dazu muss allerdings (vielleicht gehts auch sonst, aber ich glaub nicht - hat sich aber möglicherweise seit den letzten Versionen geändert) der aktuelle Ordner "." im CLASSPATH sein. Also zuerst das ausführen: "export CLASSPATH=.:$CLASSPATH"

Das was du machtest konnte nicht gehen, weil
1) "javac Hello.class" versucht, die bereits kompilierte Klasse noch einmal zu Kompilieren :p
2) "java Hello.class" nach der Klasse Hello.class sucht - also nach der Datei Hello.class.class - und die gibts nicht

Noch so wichtig: In Java werden Klassennamen üblicherweise mit Grossbuchstaben begonnen. Variablen mit kleinen. Die Datei muss _exakt_ gleich heissen wie die Klasse (natürlich mit dem Anhängsel .java oder .class) - Gross- und Kleinschreibung inbegriffen.

MfG Peschmä

[tiris]

Daran hatte es nicht gelegen. Ich hatte ja verschiedene Schreibweisen ausprobiert, aber keine hat zunm Erfolg geführt. Nach dem Zurückspielen eines Systembackups hab' ich das ganze noch einmal installiert und siehe da: Es funktioniert. Allerdings erscheint mir der Netbeans IDE ziemlich lausig. Lies sich aber nicht vermeiden, dass j2sdk den mitinstalliert. Muss ihn ja nicht benutzen.

gruß tiris

[peschmae]

Das JDK gibts auch ohne Netbeans - die Version mit ist nur auf der Downloadseite zuoberst ;)

Lausig finde ich Netbeans nicht. Nur lahm, wie es sich für Swing gehört. Naja, am Anfang verzichtest du am besten eh darauf.

Eclipse ist besser :D

MfG Peschmä

[tiris]

Eclipse funzt aber nicht. Fehlercode -1.

gruß tiris

[peschmae]

boaaaah, mit so vielen Angaben kann ich dir sicher Helfen. :D

MfG Peschmä

[tiris]

Erst mal frohes Neues.

Also ich pinsel jetzt mal ab was in dem Fenster steht wenn ich versuche Eclipse zu starten:

_____________________
JVM terminated. Exit Code=1
C:\Windows\system32\javaw.exe
-cp D:\eclipse\startup.jar org.eclipse.core.launcher.Main
-os win32
-ws win32
-arch x86
-showsplash D:\eclipse\eclipse.exe -showsplash 600
______________________________________________

Nur ein Button mit ok ist noch drunter.

Die Meldung sagt doch nur was alles da ist und dass es nicht klappt, oder?

gruß tiris