| Autor |
Beitrag |
    
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Montag, 13. Mai 2002 - 11:40 Uhr: | 
|
Hallo!
Ich denke, es wird Zeit, die Diskussionen zum Thema "NobraControl für Mac" nicht mehr unter dem Stichwort "Linux" laufen zu lassen. Für mich läuft das Projekt unter dem Namen "MacNobra", was andeuten soll, dass es sich nicht um eine 1:1 Übertragung von NobraControl auf den Mac handelt, sondern um ein anderes Programm, das die gleiche Hardware bedient. Die Programme sollten natürlich gut zusammenarbeiten, wenn es um Chat & Net geht, aber soweit bin ich noch nicht...
Hier also ein kleiner Bericht über den Stand der Dinge:
- Die Gestaltung der Oberfläche für die direkte Ansteuerung ist fertig. Mein Motto war dabei "as simple as possible". Es kann eine minimale und eine maximale Vibrationsstärke eingestellt werden, eine Art der Vibration (konstane Stärke, ansteigend, ansteigend & abfallend, zufällig, also wie in NobraControl). Eine "Zeitintervall"-Einstellung gibt an, wie schnell sich die Stärke ändern soll. Dann noch einen "Ein/Aus"-Schalter - das wars schon. Natürlich gehört noch das Speichern von Einstellungen dazu, damit man nicht jedesmal von 0 anfangen muss und die Einstellung, welche serielle Schnittstelle verwendet werden soll.
- Die Software ist bisher noch nicht unter realistischen Bedingungen getestet worden, dazu fehlt mir noch die "Hardware" von nobra.
- In diesem ersten Schritt ist das "Speichern" von Sequenzen noch nicht enthalten, der Chat ebenfalls nicht. Es geht zunächst einmal um die "vitalen Funktionen" der Software, ob die elementare Kommunikation klappt. Aber ich darf als "Bonbon" schon einmal einen neuen Vibrationstyp ankündigen, den ich mir sehr schön vorstelle, die direkte Steuerung per Maus: Maus nach links -> minimale Stärke, Maus nach rechts -> maximale Stärke, wobei der Sprung auch durch eine kleine Mausbewegung ausgelöst werden kann. Ich denke, das könnte Spass machen, wenn man nicht immer auf den Monitor starren und auch einmal die Augen schliessen will... More to come soon...
- Das Ganze schreit also nach "Ausprobieren". Wenn ich die Harware von nobra bekomme, werde ich die Software gerne an andere Leute weitergeben, um zu sehen, ob es auch noch auf anderen Computern funktioniert... ;-)
- Zur mentalen Vorbereitung für alle potentiellen Tester der Software: Wir werden neben dem Vib und der Steuerkiste noch ein Kabel brauchen, um die serielle Schnittstelle des Mac anschliessen zu können. Da gibt es kommerzielle Adapterkabel (Conrad oder Völkner), man kann das auch selbst Löten (http://ati83.ati.ac.at/Public/Links/LAM_HTM_018/lam.htm). Erfahrungsgemäss ist es beim Selbstlöten einfacher, ein vorhandenes aber nicht mehr gebrauchtes Druckerkabel in der Mitte durchzuschneiden und die Kabel an einen Stecker zu löten.
- Also: Wer hat Interesse, die Software zu testen und Fehler & Verbesserungsvorschläge an mich zu melden?
Zum Schluss noch einige Bemerkungen an Kai:
1. Vielen Dank noch einmal für den Quellcode. Die Offenlegung des Quellcodes ist wirklich eine sehr positive Einstellung und ich werde das mit MacNobra natürlich genauso handhaben. Allerdings habe ich mir nicht allzu viel Mühe gegeben, den Code Stück für Stück zu verstehen. Dafür kenne ich einfach Profan nicht und kenne in meiner Umgebung auch niemand, der damit arbeitet. Am wichtigsten war für mich die Spezifikation der Kiste. Und das wird wahrscheinlich auch für die fehlenden Teile gelten: Nach welchen Spielregeln wird der Chat abgewickelt?
Gibt es dazu eine Art Dokumentation?
2. Die Software kann ja nun nicht überprüfen, ob wirklich eine Nobra-Steuerkiste an der ausgewählten Schnittstelle hängt, weil die Kiste sich nicht durch irgendeine Antwort bemerkbar macht. Gab es schon einmal Probleme damit, dass ausversehen ein anderes Gerät an einer anderen Schnittstelle die Befehle bekommen hat, bzw. sollte man den Benutzer nochmal ausdrücklich warnen?
3. Was ist denn die kürzeste sinnvolle Intervall-Zeit. Ich weiss, dass die Kiste die Befehle im 10ms-Takt entgegennehmen kann, aber wie sinnvoll wären denn Wechsel der Stärke in diesem Rhythmus. Ich vermute mal, die Hardware ist da etwas träger. Im Quelltext habe ich was von 100ms als Grenze gefunden, das wären 10 Wechsel pro Sekunde. Gibt es dazu Erfahrungswerte? Sicherlich...
Viele Grüße
Thomas |
kai
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Dienstag, 14. Mai 2002 - 21:56 Uhr: |
|
Hi Thomas,
super, dass Du schon soweit gekommen bist! Völlig OK, dass Du das Thema abgetrennt hast, so bleibt ein wenig mehr Übersicht im Thread :-)
Der Tip mit dem "Selbstbaukabel" ist prima, da kann sich so mancher geschickter Bastler sicher die Ausgabe für ein Kabel sparen.
Verwendet werden an der 9poligen SUB-D Buchse des Steuergerätes ohnehin nur Pin 3 (RxD/TxD) und pin 5 (Masse).
Wenn ich die Seite Deines Links richtig lese, hat der Mac eine 8 bzw. 9 polige RS422 MiniDIN Buchse? Wichtig erscheint mir dann dieses:
Die RS 422 benützt zwei Leitungen für das Übertragen bzw. Empfangen. Die Spannungspegel sind dabei plus bzw. minus 5 Volt. Die RS 232 dagegen benützt nur eine Leitung (damit wird gesendet und empfangen), die Spannung beträgt dabei minus 12 Volt. Die RS 422 kann eine RS 232 emulieren wenn RxD+ auf Masse gelegt wird.
Damit müssten eigentlich nur MiniDIN Pin 3 (TxD) und RS232 Pin 3 (RxD) sowie Masse verbunden werden (Zweidrahtlösung sozusagen), wenn am MAC RxD+ auf Masse gelegt wird, um RS232 zu emulieren...
Klingt kompliziert wie ich das geschrieben habe *arrrg* Ich hoffe, Du verstehst, was ich gemeint habe?
Nun zu Deinen Fragen:
zu1. Die Chatspielregeln sind ein Problem, mit dem wir es bei der Portierung zu Linux auch zu tun haben... Leider ist das schon bei den zur Zeit vorhandenen Programmen NobraNet und NobraChat nicht einheitlich und die beiden sind auch nicht zueinander kompatibel, das geht schon mit den unterschiedlichen Ports los, auf denen die Programme arbeiten...
Das zweite Problem ist, dass der Sourcecode von NobraChat nicht ist und die komplette Abwicklung des TCP/IP Sockets im NobraNet einer DLL obliegt, die ebenfalls nicht transparent ist...
Langfristig wäre es wirklich toll, wenn es einen Standard gäbe und zwar einen offenen, nach dem alle Nobra Programme arbeiten und auch miteinander kompatibel sind.
Die Frage ist nur, auf welche Basis stellt man das Ganze (welche Programmiersprache erlaubt es mit möglichst wenig Änderungen das alles auf diverse OS zu portieren)?
zu 2. Eine Geräteerkennung findet nicht statt, da hast Du recht.
In der Praxis gab es damit bisher aber keine Probleme, da ein COM-Port am PC ohnehin nur von einem Programm benutzt werden kann und solange für alle anderen gesperrt ist. Sollte z.B. ein Modem mal aus Versehen die Daten des Vibis empfangen, so macht ihm das bestimmt nix aus, es wird darauf wohl nicht reagieren. Eine grössere Gefahr sehe ich auch nicht, wenn das Vibisteuergerät aus Versehen Modemdaten bekommt... im schlimmsten Fall hüpft ein angeschlossener Vibi mit Fullspeed vom Tisch :-) Dagegen hilft dann aber einfaches Ausstöpseln der Stromversorgung.
Es sind bisher jedenfalls kleine Probleme bekannt.
zu3. Weniger als 100ms Intervallzeit machen aufgrund der Masseträgheit des doch sehr grossen Fliehgewichtes eines Nobra Vibis keinen Sinn, das haben wir ausgiebig ausgetestet :-) Mit 100ms ist es möglich, den Vibi quasi stufenlos hoch und runter zu regeln ohne dass das zu langsam erscheint...
Also zusammengefasst ist Punkt 1 bezüglich eines einheitlichen Chatsystems auf jden Fall das grösste Problem... da muss ein einheitlicher Standard her...
Ich hoffe, Du kannst mit meinen Antworten schon mal was anfangen
Viele Grüsse
Kai
|
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Mittwoch, 15. Mai 2002 - 01:31 Uhr: |
|
Hallo Kai,
klar verstehe ich, was Du mit den RS422-RS232 Geschichten meinst, ich habe nach diesem Rezept schon diverse Kabel gelötet. Ich denke, ich werde noch mal ein kleines Bild machen mit den ensprechenden Verschaltungen, für alle, die das zum ersten Mal ausprobieren. Wenn die NobraControl-Kiste nur so wenig braucht, umso besser...
Ja, das mit dem Chat klingt nicht einfach. Eigentlich sind die text-basierten Chat-Protokolle nicht allzu kompliziert, aber dafür kenne ich die Funktion der DLLs nicht, die da im Hintergrund arbeiten. Vielleicht sollte ich mal die Nobranet bzw. Nobrachat-Software in aktion erleben, um ein Gefühl dafür zu bekommen, wo die Probleme liegen könnten.
zu 2. Naja, wenn das kein Problem ist, auch gut. Ich kenne solche Sachen, dass man durch Verwechseln der Schnittstellen manche Geräte ganz schön verwirren kann. Klar, wenn ein anderes Programm die Schnittstelle belegt, ist es noch einfach.
zu 3. die "Versuchsreihen" waren sicher sehr lustig...
Bis bald
Thomas |
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Mittwoch, 15. Mai 2002 - 23:45 Uhr: |
|
hallo thomas, hallo kai, hallo alle anderen!
ich muss hier nochmal meinen senf loslassen, auch wenn ich von mac keine ahnung habe.. ;-))
also: zum chat muss ich sagen, dass das hauptproblem meiner meinung nach jenes ist: keiner weiss genau, was übertragen wird... wenn ich dich, kai, richtig verstanden habe nutzt auch dein programm dafür eine dll... das ist sicher ganz schön und gut, aber da es sich um microschrott-dlls handelt, sind diese selbstverständlich völlig untransparent und vor allem garantiert total proprietär... stellt sich die frage, ob es trotzdem "kompatible" unter linux und mac gibt... ich fürchte eher nicht.. selbst wenn, wir hätten dann eine verbindung, aber wissen wir, wie die software die jetzt existiert, den vibi auf der anderen seite zum virbrieren bringt? ich fürchte nicht...
thomas, ich hätte da an dich eine frage: wie sieht das beim mac aus mit ansi-c? hast du dafür einen compiler? wenn ja, dann könnte man diese software neu schreiben, open source und rein mit ansi-c, was den vorteil bietet, dass die ansi-c libraries auf allen systemen meines wissens gleich sind... unter windows und linux lässt sich ein ansi-c programm jedenfalls unverändert oder mit leichten änderungen ("/dev/ttyS0" unter linux und "com1" unter winblöd zum beispiel) compilieren... die socket.h gehört soweit ich weiss auch noch zu ansi-c und somit wäre diese frage dann geklärt... ich müsste mich nur mal hinsetzen und die sache programmieren... das kann ich schon morgen in angriff nehmen... wir sollten aber vielleicht im vorfeld klären, wie wir das machen... als protokoll auf netzwerkebene würde ich udp vorschlagen, da dieses meines wissens den vorteil hat, dass es eigentlich recht problemlos mit nat operiert... die nächste frage wäre, ob es sinn macht das ganze weiter in chat und "fernsteuerung" aufzuteilen, oder ob man dafür dieselbe verbindung nutzt... sprich ein udp-port für chat _und_ steuerung...
meldet euch dazu einfach mal... morgen bin ich sicher früh zu hause (berufsschule is um 13 uhr zu ende) und kann mich dann damit befassen...
gruss
frozen |
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 17. Mai 2002 - 02:03 Uhr: |
|
hallo frozen,
ich glaube, ich gehe an so eine aufgabe eher pragmatischer ran. natürlich ist open-source software, noch dazu plattform-übergreifend, eine sehr gute lösung. aber ich kann und möchte das nicht machen. ein paar leute haben nach einer version der software für den mac gefragt, was ich gut verstehen kann. in dem bereich kenne ich mich aus, also kann ich etwas beitragen. ich mache das jetzt mit realbasic, eine software, die im prinzip auch für windows compiliert werden kann. das "im prinzip" ist aber nach meiner erfahrung eine echte einschränkung. der teufel steckt im detail, und wenn man die anderen systeme nicht direkt zur hand hat, ist ein entwickeln der "perfekten" software sicher schwer. du schreibst "meines wissens...", "oder mit leichten änderungen","soweit ich weiss","eigentlich recht problemlos". Also da lauern bestimmt noch einige Überraschungen. Mein Lieblings-Zitat in diesem Zusammenhang ist: "Was ist der Unterschied zwischen Theorie und Praxis? In der Theorie gibt es keinen..."
Ich möchte dich nicht demotivieren. Aber vielleicht ist es am besten, Du entwickelst ein gutes Programm für linux, und wenn es andere auch noch brauchen können, umso besser.
Bis bald
Thomas |
-
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 17. Mai 2002 - 04:15 Uhr: |
|
nobrachat cgi dispatcher client:
--------------------------------
// anfrage / anmeldung (in C, sorry)
connect (urlStr,80); //tcp,http-port
tmpStr = format("GET %s/nobrachat.pl?name=%s&port=%d&hw=%c&t=%d HTTP/1.0"
,subdir
,pseudo
,port
,hardwaretype
,refreshtime);
tmpStr += 13;
tmpStr += 10;
tmpStr += "Host: ";
tmpStr += urlStr;
tmpStr += 13;
tmpStr += 10;
tmpStr += 13;
tmpStr += 10;
send(tmpStr);
// antwort ist selbsterklaerend
"HTTP/1.1 200 OK" = connected
"<#>Pseudo;IP;port;N;" = client 1, no hardware
"<#>Pseudo;IP;port;N;" = client 2, no hardware
"<#>Pseudo;IP;port;V;" = client 3, vibrator
etc ...
die anfrage wird nach "refreshtime" wiederholt
----------------------------------------------
chat-protokoll nobrachat
------------------------
server tcp, port 27100 (egal, lauft ueberall)
jedes nobrachat ist server und client.
daten sind ascii-textbasiert.
client: macht tcp connection zum server (IP/port)
server: "<01>"
client: "<02:pseudo>"
server: "<03:ok>" (angenommen)
oder: "<03:ko>" (abgelehnt)
client oder server:
"textmeldung" (ascii)
"<$>a" (vibi steuerungsbefehl, a-o, p)
|
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 17. Mai 2002 - 08:56 Uhr: |
|
lieber thomas,
das problem ist, dass wir dann 3 unabhängige varianten hätten, die nicht miteinander chatten oder "fernsteuern" können... macuser könnten untereinander, linuxuser könnten untereinander und windowsuser ebenfalls nur untereinander... das ist das eigentlich problem was ich sehe! sockets die unter linuix gebaut wurden laufen auch unter windows, man muss nur ein oder 2 ergänzungen wegen winsock machen... macintosh kenne ich wie gesagt gar nicht... aber dort muss es auch sockets geben, die ich nutzen kann... gibt es den gcc für mac? da muss ich mich mal schlau machen... ich denke man könnte den server auf linux programmieren und laufen lassen... den client nur mehr oder weniger nackt implementieren und die gui dann separat darauf setzen hätte vorteile... der client wär überall gleich und hat schnittstellen auf der die jeweiligen betriebssysteme eine gui aufsetzen können... unter linux ein qt programm, unter windows ein vb, c++ oder sonstwas programm und unter mac ein realbasic programm... diesen client müsstest du nicht opensource machen...
diese meldung von - ist interessant... wer auch immer das war.. ;-)) ich werde mir das mal ansehen...
gruss frozen |
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 17. Mai 2002 - 11:24 Uhr: |
|
Hallo frozen,
den zweiten teil deiner nachricht kann ich gut unterstützen. wenn es klar ist, wie die kommunikation im nobrachat/net gehen soll (und die letzte nachricht scheint so etwas zu beinhalten und von kai zu sein...), dann kann das jeder in seiner software umsetzen. wenn man sich in den irc-chat einhängt, der sowieso schon existiert, dann braucht man wohl auch keine spezielle server-software. von daher sehe ich nicht die gefahr, dass nur die leute mit den selben computern sich fernsteuern können. das wäre für die mac- und linuxuser wohl etwas trist... ;-) |
kai
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 17. Mai 2002 - 19:19 Uhr: |
|
Hallo,
nee, ich wars nicht, aber ich ahne, wer uns da unter die Arme greifen will, Danke! ;-)
Ihr habt das zum Ausdruck gebracht, worüber ich mir auch schon den Kopf zerbrochen habe...
Frozen, Du hast recht, die DLLs unter Windoofs sind leider nicht transparent und damit kommen wir langfristig auch nicht weiter. Ich muss dazu allerdings sagen, dass ich nicht der Netzwerkprogrammierfuzzi bin und deswegen wohl noch eher auf dem Schlauch stehe, als ihr...
Thomas, was meinst Du mit in IRC reinhängen? Dachtest Du dabei daran, das dort verwendete "Protokoll" zu nutzen? Denkbar wäre dann ja, eine Art Zusatzfunktion zu implementieren, die Steuerbefehle ausfiltert und an die COM-Schnittstelle gibt. Gibt es denn "Vorlagen" für einen einfachen IRC-Chat, die man anpassen könnte?
Viele Grüsse
Kai
|
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Samstag, 18. Mai 2002 - 12:59 Uhr: |
|
hmmm... hallo thomas, hallo kai, hallo unbekannte person (;-)) )...
naja, das ircprotokoll zu nutzen wäre sicher möglich... es gibt unter linux mehrere varianten von clients und servern die man im quellcode beziehen kann... das dumme ist nur, dass man da den code verändern und anpassen müsste, womit eine version entsteht, die nicht mit einem normalen irc-client und auch nicht mit einem normalen irc-server zusammenarbeitet... dennoch wäre es machbar... was ich nicht weiss, ist ob ein linux-irc-server oder ein linux-irc-client sich auch unter windoofs compilieren lässt... dazu müsste man den quellcode analysieren...
es wäre immernoch auch möglich das ganze nochmal bei null beginnen zu lassen und eine xml-struktur für das protokoll zu nehmen... xml gibt es inzwischen auf jeder plattform... (auch auf dem macintosh, da bin ich mir sicher ohne es zu wissen).. den ansatz jeden client gleichzeitig auch als server laufen zu lassen halte ich für sinnvoll... man muss schliesslich unter den clients direkt eine verbindung aufbauen... der eigentliche server der als cgi oder daemon irgendwo läuft ist eigentlich nur vermittler... ähnlich wie bei irc, wenn die kommunikation der user untereinander nur via dcc laufen würde... dieser server wäre nur dafür da, dass sich die user untereinander finden...
man könnte auch versuchen aus den kurzen aber bedeutsamen informationen der "unbekannten person" -- auch von mir nochmal: danke! -- einen client/server für die verschiedenen betriebssysteme zu basteln...
was meint ihr? was sollen wir machen?
wir haben 3 ansätze:
1.: komplett neu und dann evtl. mit xml oder so..
2.: aus dem beitrag weiter oben einen client basteln..
3.: uns ins irc reinhängen...
ich kann mich nicht so direkt entscheiden...
variante 1 ist mit aufwand verbunden und würde recht lang brauchen um fertig zu werden..
variante 2 wäre sicher einfacher, aber wir haben noch immer nicht den sourcecode des servers, können also nicht bei bedarf zusätze implementieren...
variante 3 ist auch sehr aufwendig und bedeutet analyse von vorhandenem code um den gegebenfalls crosscompilebar zu machen...
welche variante gefällt euch am besten?
viele grüsse
frozen |
hahase
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Sonntag, 19. Mai 2002 - 12:31 Uhr: |
|
Hallo zusammen
Ich bin ein passionierter Mitleser und möchte nun auch mal meinen Senf beitragen.
Warum das Rad zweimal erfinden. Es gibt schon gute multiplatform Libraries für alle Systeme. Schaut mal unter: http://www.libsdl.org/projects/SDL_net/
Ich habe zwar selber das SDL_net Ding noch nicht gebraucht aber das SDL selber funktioniert gut und ich bin gerade daran eine Crossplatform-Grafikanwendung mit SDL zu schreiben (Bis jetzt getestet auf Win32 und MacOSX). Ich denke, es ist einen Versuch wert, diese offenen Tools mal genauer anzuschauen um einen neuen multiplatform Nobra-Chat zu bauen.
Liebe Grüsse
Hahase |
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Sonntag, 19. Mai 2002 - 15:41 Uhr: |
|
danke lieber hahase!
mal sehen, scheint mir auf den ersten blick der totale overkill zu sein, aber es ist definitiv nen blick wert!!!
gruss
frozen |
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Dienstag, 21. Mai 2002 - 02:27 Uhr: |
|
Hallo zusammen,
"das Rad nicht neu erfinden" ist ein guter Leitsatz, hahase. Aber genau deshalb würde ich nicht vorschlagen, einen neuen multiplatform Nobra-Chat zu bauen. Es gibt ja schon einen chat, der offenbar funktioniert, auch wenn einige von uns daran bisher noch nicht teilnehmen konnten.
Wenn ich vom Programmieren leben würde (Konjunktiv!!!) und eine plattformübergreifende Lösung verkaufen wollte, würde ich wohl auch so einen großen Rundschlag wählen. Aber wenn ich es recht sehe, machen wir das alle nebenher und ich vermute, nur wenige von uns haben die Möglichkeiten, ihre Programme auf vielen verschiedenen Systemen zu testen. Und wenn man das kleingedruckte der Tools für die Multiplatform-Libraries liest, gibt es genug Einschränkungen (ab welchem System, welche Befehle werden unterstützt...). Und wie verhält sich das Ganze, wenn es neue Betriebssystemversionen bzw. neuer Compiler-Versionen gibt. Ich denke, jeder der auf seinem System schon das ein oder andere Jahr programmiert hat, wird da ein Lied singen können.
Mal etwas mit Abstand betrachtet und tief durchgeatmet: Unsere Programme sollen (1) ein paar Buchstaben auf eine serielle Schnittstelle schreiben, (2) ein paar Zeilen Text per chat mit einem anderen User im Universum austauschen können, und (3) eine nett & einfach zu bedienende Oberfläche haben. Hey, das ist nicht zu schwer. Unsere Programme sollten kompatibel sein unter Punkt (2). Ich vermute, wir haben viel, viel weniger Arbeit, wenn die neuen Versionen (Mac, Linux) sich einhängen in den Chat, der bereits funktioniert.
Dazu muss ich allerdings sagen, dass ich trotz unserer interessanten Diskussion bisher immer noch nicht verstanden habe, wie der Chat bisher funktioniert. Das liegt wahrscheinlich daran, dass ich bisher noch nicht die Möglichkeit hatte, den Chat mitzuerleben. Aber vielleicht würde es mir und den anderen hier helfen, noch ein paar Details mehr zu wissen - auch wenn es banal ist...
1. Nobra hat einen Verweis auf einen #p.o.p-chat, auf den ich auch mit einem irc-client zugreifen kann. Ist das der selbe Chat, über den auch die NobraNet/Nobrachat-Software kommuniziert? Oder läuft für diese Software auf einem anderen Computer noch ein anderer Server, ein Nobra-Server sozusagen?
2. Schritt für Schritt: Wenn Ihr Euch entscheidet, im Internet nach anderen Nobra-Usern zu suchen, was passiert dann? Ihr wählt einen Server an (mit dem Connect-Befehl von oben vermute ich). Bei welchem Server? Dann bekommt ihr eine Liste der anderen Benutzer mit entsprechenden Angaben (ebenfalls s.o.).
3. Wenn Ihr eine Nachricht an alle oder an einen bestimmten Benutzer schickt, wie werden die Nachrichten verwaltet?
In meiner ganzen Naivität denke ich, dass das alles keine wirklich komplizierten Abläufe sind. Es werden einfache Textzeilen an einen Server geschickt.
Wenn es sich um den Nobrachat-Server handelt, der oben beschrieben wurde, dann liefert dieser z.B. Hardware-Informationen mit, die die Clientsoftware einfach entschlüsseln kann. Umgekehrt können Nachrichten einen Steuerbefehl enthalten, den die Software auf der anderen Seite in einen Befehl für die serielle Schnittstelle umwandeln kann. Ok. Wenn wir von Mac oder Linux aus diese Befehle nachahmen wollen, müssen wir einfach Textzeichen schicken, empfangen und entschlüsseln können. Ich denke, das sollten wir auch ohne Multiplatform-Bibliotheken können.
Wenn wir uns in einen "gewöhnlichen" IRC-Server einklinken wollen, dann wäre der zweite Aspekt (Steuerbefehle aus einer Nachricht rausholen) ebenfalls leicht. Schwieriger wäre es, sich mit seinen Hardware-Angaben anzumelden, obwohl man sich dafür evtl. ebenfalls eine Konvention überlegen könnte, also z. B. anmelden als Pseudo#Hardware. Die Software könnte es einem dann abnehmen, die verschiedenen Teile der Anmeldung wieder in sinnvolle Teile zu zerlegen und getrennt darzustellen. Leute, die über einen normalen IRC-Client mitmischen, müssen die Steuerbefehle kennen (über dieses Board hier) und erscheinen als User, die keine Hardware haben. Also alles nicht wirklich ein Problem.
Um es also ein wenig kürzer zu sagen: Von den 3 Möglichkeiten, die frozen vorgeschlagen hat, finde ich die 2. und 3. die naheliegendsten, Variante 1 bleibt für die, die gaaaaaaaaanz viel Zeit haben ;-). Die Probleme mit dem irc-Protokoll sehe ich nicht. Wir brauchen keinen irc-server schreiben, den Job machen doch schon andere für uns. Und dass das Einbauen von irc-Protokollen in unsere Software dazu führt, dass wir damit keinen allgemeinen irc-Client schreiben ist ja auch klar. Was sollen Leute in anderen irc-gruppen mit unserer Hardware-Angabe anfangen?
Sorry für diese langen Ausführungen. Vielleicht klären sich ja die Nebel, wenn jemand meine Fragen (s.o.) beantwortet hat. Und vielleicht bin ich ja zu naiv...
Bis bald
Thomas |
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Dienstag, 21. Mai 2002 - 12:40 Uhr: |
|
Hallo Leute!
<snip>
Ich vermute, wir haben viel, viel weniger Arbeit, wenn die neuen Versionen (Mac, Linux) sich einhängen in den Chat, der bereits funktioniert.
</snip>
das stimmt schon... damit sind wir weiterhin abhängig von einer variante die für uns starr ist, die wir nicht verändern könne, die closed source ist... das ist erstmal kein problem, aber könnte schwierig werden, wenn wir mal zusatzfeatures haben wollen... oder veränderungen machen müssen/wollen... wie siehts zum beispiel aus, wenn wir mal plötzlich 500 user haben, die damit chatten wollen? oder 1000? ist vielleicht unwahrscheinlich, aber möglich! Linus hätte auch nie gedacht, dass sein Linux mal solche Bedeutung haben würde! ;-) Was aber machen wir, wenn dieser Nobraserver unter derartiger Last zusammenbricht? Z.B. mit nem Segfault... Oder unendlich träge wird? Das wäre aber auch alles, was dagegen spricht... ;-)
<snip>
1. Nobra hat einen Verweis auf einen #p.o.p-chat, auf den ich auch mit einem irc-client zugreifen kann. Ist das der selbe Chat, über den auch die NobraNet/Nobrachat-Software kommuniziert? Oder läuft für diese Software auf einem anderen Computer noch ein anderer Server, ein Nobra-Server sozusagen?
</snip>
nein, es ist nicht derselbe chat... Es läuft ein "Nobraserver", der früher mal programmiert wurde, in closed source... die entwicklerin ist meines wissens nicht mehr so ganz so greifbar... da müsste man kai fragen, ob da noch kontakte bestehen...
<snip>
2. Schritt für Schritt: Wenn Ihr Euch entscheidet, im Internet nach anderen Nobra-Usern zu suchen, was passiert dann? Ihr wählt einen Server an (mit dem Connect-Befehl von oben vermute ich). Bei welchem Server? Dann bekommt ihr eine Liste der anderen Benutzer mit entsprechenden Angaben (ebenfalls s.o.).
</snip>
es gibt einen nobrachatclient... der wird gestartet und verbindet sich automatisch mit dem nobraserver... als nächstes sehe ich vor mir ein fenster indem für jeden user ein bildchen ist, mit seinem nick darunter... die kann ich dann anwählen und wenn der andere user annimmt kommt das chatfenster für diesen user mit balken zur steuerung des vibis... schaus dir am besten mal in nem icafe oder so auf nem winblödrechner an...
<snip>
3. Wenn Ihr eine Nachricht an alle oder an einen bestimmten Benutzer schickt, wie werden die Nachrichten verwaltet?
</snip>
tja... das ist die grosse frage... diese kurze mail von weiter oben enthält unsere einzigen hinweise dazu...
der verzicht auf multiplattformbibliotheken ist sicher kein problem... einziger nachteil: für alle plattformen völlig unterschiedliche programme... du hast jedenfalls recht, das was da im einzelnen abläuft ist nicht sooo schwierig... ich bastele im moment an einer (noch testweise) konsolenbasierten variante... und ich muss sagen, das klappt überraschend einfach.. der sourcecode den ich bisher produziert habe muss man auch mit leichtesten änderungen (die man automatisieren kann) unter windows compilieren können... sicher, es läuft noch nicht, und es ist auch noch lange nicht fertig, aber es würde klappen, wenn ich daran weitermache...
<snip>
Wenn wir uns in einen "gewöhnlichen" IRC-Server einklinken wollen, dann wäre der zweite Aspekt (Steuerbefehle aus einer Nachricht rausholen) ebenfalls leicht.
</snip>
jein... du müsstest entweder einen angepassten irc-client oder einen angepassten irc-server verwenden... wenigstens clientseitig muss eine veränderte version genutzt werden... gibt es opensource irc-clients für mac? und für windows?
mpf... du sagst, alles kein problem... ich sehe das etwas anders... siehe oben...
<snip>
Um es also ein wenig kürzer zu sagen: Von den 3 Möglichkeiten, die frozen vorgeschlagen hat, finde ich die 2. und 3. die naheliegendsten,
</snip>
die 3. halte ich aus genannten gründen für schwierig, aber möglich... die 2. hat die oben genannten einschränkungen...
<snip>
Variante 1 bleibt für die, die gaaaaaaaaanz viel Zeit haben ;-).
</snip>
wie gesagt: so schlimm ist das ganze nicht... wenn ich jeden tag ein paar stunden daran basteln könnte, dann würde ich das vielleicht sogar noch diese woche fertig kriegen (wohl ohne gui), je nachdem welche features wir wollen... es ist wirklich nicht so schwer!
deine lange ausführung ist für mich okay! ;-)
Ich hoffe, dass sich die nebel jetzt gelichtet haben! ;-))
ich tendiere immer stärker in richtung selber neu programmieren... wie gesagt, der quellcode, den ich da momentan bastele, ist ansi-c, der muss auch unter anderen betriebssystemen laufen! ansi-c ist ein standard, der auf allen plattformen eingehalten wird...
angenommen, ich würde das ganze als textbasierte variante für alle plattformen coden. was spricht dagegen, dass wir dann darauf eine QT-gui setzen? obwohl... das läuft wohl nur mit mac os x... naja, für windows und linux wäre so jedenfalls eine einheitliche oberfläche garantiert... für macos müsstest du, thomas, dann leider was anderes nehmen... wäre das ein ansatz?
ich bin auf eure antworten gespannt...
frozen |
-
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Dienstag, 21. Mai 2002 - 14:02 Uhr: |
|
nobrachat besteht eigentlich aus 2 teilen.
1.-------------------
der search&find teil mit dem cgi-server.
dieser teil ist zum auffinden der chatpartner.
die IP, pseudo und harware jedes eingeloggten
benutzers werden so bekannt. es werden aber weder
chat-texte noch steuerbefehle uebertragen.
ausprobieren kann man das mit dem http explorer.
z.b.
http://www.erosoft.de/cgi-bin/nobrachat.pl?name=test&port=27100?hw=n
zurueck kommt eine liste der pseudos, deren IP
und deren port.
2.-------------------
der eigentliche chat teil lauft ueber direcktverbindung IP to IP, ohne einen gemeinsamen
server. dieser teil kann mit telnet ausprobiert werden.
z.b.
-> telnet 62.43.12.36 27100
<01>
-> <02:thomas>
<03:ok>
-> hallo
-> <$>b
etc...
man kan also auch vom mac aus mittels telnet mitchatten, allerdings nur als anrufer.
|
-
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Dienstag, 21. Mai 2002 - 14:08 Uhr: |
|
sorry, kleiner fehler in der url.
hier kommts richtig:
http://www.erosoft.de/cgi-bin/nobrachat.pl?name=thomas&port=27100&hw=n |
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Dienstag, 21. Mai 2002 - 16:21 Uhr: |
|
hallo unbekannte person!!!
besten dank!!! das ganze scheint ja doch recht einfach aufgebaut zu sein... (telnet als anrufer heisst implizit plaintext).. tja, ich denke, das sollte kein problem sein, dass auf linux und mac umzusetzen...
vielen dank!
frozen |
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Dienstag, 21. Mai 2002 - 23:52 Uhr: |
|
Hallo!
Das Problem mit den 1000 usern halte ich wirklich ein wenig zu optimistisch. Und wenn es so viele user gibt, dann hat wohl jeder server seine probleme. obwohl der nobrachat-server ja wohl nur die adressen verwaltet, ist wohl nicht wirklich ein problem.
frozen: opensource irc-clients für mac? und für windows? natürlich sollte man keinen ganzen irc-clienten verwenden. wenn du mal unter google nach informationen zum irc-protokoll suchst, siehst du, dass es ganz einfach ist, die wesentlichen befehle in ein Nobra-Programm zu übernehmen. Einen ganzen IRC-Clienten möchte ich sicher nicht schreiben...
Aber nach der Meldung von ? brauchen wir das gar nicht...
Mit der "gaaaaaaaaanz viel Zeit" meinte ich nicht deine Zeit, sondern die Zeit, das Programm für alle Systeme auch wirklich zu implementieren. und du sagst das so ganz lapidar "du müsstest dann halt was anderes nehmen". Was soll für mich der Vorteil so einer Lösung sein, wenn wir uns über einen einfachen Austausch von ein paar Textzeichen viel einfacher einigen könnten?
Frozen, solltest Du trotz der letzten Meldung noch an eine neue Serverlösung denken, dann mach die Schnittstelle für den Chat doch ähnlich einfach wie beim jetzigen Nobrachat. Dann könnte ich mich auch mit meiner Software reinhängen, wenn ich keine Lust & Zeit habe, "mir was anderes zu nehmen"... ;-)
Bis bald
Thomas
|
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Mittwoch, 22. Mai 2002 - 00:24 Uhr: |
|
hallo thomas!
naja, das mit dem "dann müsstest du dir halt was anderes nehmen" bezog sich nur auf die gui! sorry!! war nicht so fies gemeint wie es vielleicht klang...
Also sehe ich das richtig, dass wir dann doch für jedes betriebssystem einen völlig unabhängigen client basteln wollen? du einen für mac, ich einen für pc und kais ding für winschrott bleibt? das ist sicher unschön, aber kein problem! der vorteil ist: es sind native programme... es sind also keinerlei einschränkungen wegen reiner ansi-c programmierung zu erwarten... wenn du mit realbasic gute erfahrungen gemacht hast kannst du dabei bleiben... bleibt der nachteil, dass es 3 total andere programme sind... eins unter profan, eins unter realbasic und eins unter c/c++... wenn einer von uns stirbt und 2 wochen später ein neues feature angekündigt wird ist die jeweilige plattform arm dran... ;-)
du hast recht, der nobraserver ist sozusagen ein reiner "vermittler", die clients könnten theoretisch sogar ohne den...
also würde ich auch dir vorschlagen (mit kai bin ich mir da recht einig), dass wir jeder für sich einen client basteln... und zwar einen, der das oben nochmal verständlicher (nochmal danke!)beschriebene protokoll der bereits existierenden variante nutzt... ich denke mal, das sollte jeder auf "seiner" plattform hinbekommen... wenn du verständnisprobleme bezüglich des verwendeten protokolls hast, dann frag mich, ich glaube ich habe das ganze verstanden... ;-))
was wichtig wäre, ist, dass wir uns von der oberfläche her ein wenig an dem bereits existierenden orientieren... wenn einem von uns verbesserungen einfallen, kann man die immernoch besprechen und implementieren... zum glück sind die guielemente überall die selben! ;-)) für grafiken könnte ich gerne bei bedarf NACH dem programmieren versuchen, selber was zu machen... mit 3d studio max oder so...
irgendwann (in version 3.4 oder so) könnte man den client ja von der gui trennen und somit auf allen plattformen exakt das selbe programm einsetzen, dass nur eine andere gui hat... ;-))
der weg des geringsten widerstandes ist im moment der, dass wir auf das bereits bestehende aufbauen... ich denke, wir brauchen da nicht weiter zu diskutieren, da sind wir uns wohl alle einig...
heute ist leider was dazwischen gekommen, morgen gebe ich abends nen pc-kurs für anfänger aber am freitag kann ich wahrscheinlich anfangen! ich weiss aber nicht, wie lange ích brauchen werde... ich habe leider vieeel zu wenig zeit um so richtig zu programmieren... :-((
ich nehme an, da bist du schneller auf deinem mac, als ich... ich wäre dir dankbar, wenn du mir in diesem fall eventuelle probleme auf die du stösst, mitzuteilen... damit nicht wieder jeder von uns das rad neu erfinden muss! ;-))
sorry nochmal wegen dem "dann musst du halt..."!
viele grüsse
frozen |
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Mittwoch, 22. Mai 2002 - 09:36 Uhr: |
|
Hallo frozen,
kein Problem wegen dem "dann musst du halt". Ich habe das nicht persönlich genommen, ich wollte nur aufzeigen, wie leicht man in eine Situation kommt, in der man sagt "bei mir klappts, sollen die anderen doch sehen...". Das kennen wir als "leidgeprüfte" Linux- und Mac-Benutzer doch oft genug von der anderen Seite und sollten das umgekehrt nicht wiederholen.
Witzig, das "wenn du verständnisprobleme bezüglich des verwendeten protokolls hast, dann frag mich" hätte ich dir gestern fast auch noch geschrieben... ;-)
Also sehen wir bald 3 wunderbar miteinander kommunizierende Programme... Fehlt uns nur noch die Hardware zum Testen (Zaunpfahl!!!).
Thomas |
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Mittwoch, 22. Mai 2002 - 12:58 Uhr: |
|
hallo thomas...
tja, das hört sich so an, als könnten wir loslegen? ;-))
wozu hardware? mach doch einfach ne schleife von com1 auf com2 und lausche dann an com2 was ankommt... ;-)))
ach ja, du sagtest "...sehen wir bald...", dass "bald" ist so ne sache... kann bei mir länger dauern... sieht im moment so aus, als hätte ich die nächsten wochen mal wieder stress... naja, mal sehen!
dann viel spass noch beim programmieren! ;-)
gruss
frozen |
kai
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Mittwoch, 22. Mai 2002 - 17:40 Uhr: |
|
Hi Frozen, hi Thomas,
na ihr beiden seit ja schon fleisssig am diskutieren :-)
Ich habe mit Frozen gestern mal telefoniert, weil ich doch ziemlich aufm Schlauch (Pipeline ***g) stand, was nun das Protokoll angeht. Das stellt sich ja nun dank der hier geposteten Infos als gar nicht so schwer dar, weil nur plain-Text übertragen wird.
Mein Problem ist ganz einfach: Ich habe bei NobraNet (NobraChat ist ja von Maria, nicht von mir) bequemerweise auf eine DLL zurückgegriffen, die alles von der Erstellung des Sockets bis zur Abwicklung der Kommunikation übernimmt, aber leider eben nicht transparent ist. Profan² kann soweit ich weiss nicht direkt auf winsock zugreifen, daher der Weg über DLL (eventuell gehts auch über die WinAPI, weiss aber nicht wie, IMHO wird aber erst ab Vers. 7.5 das FTP-Protokoll als erstes direkt unterstützt...)
C/C++ kann ich leider nicht, da muss ich mich komplett neu einfuchsen und dann gleich mit einer Client-/Server Geschichte... ich weiss ja nicht... :-) Insofern würde ich gern von Euch lernen und halte den Ansatz von Frozen für gut, das Ganze aufbauend auf den schon bekannten Informationen noch mal von Grund auf neu zu machen.
Als Basis dient, wenn ich es richtig kapiert habe, ein neu geschriebener, einheitlicher Chat-Client/Server in ANSI-C geschrieben, auf den dann jeweils eine GUI "aufgepflanzt" wird, die die Eigenheiten der 3 unterschiedlichen OS berücksichtigt? Gibts denn da wirklich für alle 3 OS diese Möglichkeit? Auf der QT-page war zwar vom MAC die Rede, aber ob das als Freeware erhältlich ist, war dort nicht zu lesen?
Ich sehe bei 3 einzelnen eigenständigen Programmen eben auch die Gefahr, dass bei Weiterentwicklungen erneut 3x "hingelangt" werden muss...
Die bisherige "Anmeldepraxis" über das Perl-Script kann ja beibehalten werden, ich denke nicht, dass tausende von Usern uns den Server sprengen :-) Welche Möglichkeit gäbe es denn sonst noch, zentral einen "Treffpunkt" zu gestalten, auch wenn es später auf eine 1:1 Kommunikation herausläuft, damit nicht 20 Leute gleichzeitig an einem Vibi spielen und der eine Hüh und der andere Hott sagt? ;-) Einen zentralen Server benötigen wir in jedem Falle um die User zusammenzuführen... Das mit IRC war auch nur so eine Idee, weil es hier schon entsprechende Strukturen gibt.
Nun schlagt mich bitte nicht, wenn ich als plattformübergreifende Sache auch noch mal JAVA erwähne :-) Huxi hatte da mal was angefangen und zumindest das Steuern der Vibis klappte damit schon, und die GUI sah auch vielversprechend aus (sogar in diversen Styles umschaltbar). Es konnte allerdings noch kein Text übetragen werden und die ToDo Liste war noch ganz schön lang. Huxi, liest Du hier noch mit, dann gib doch mal einen ping bitte ;-)
Viele Grüsse
Kai
|
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Mittwoch, 22. Mai 2002 - 23:33 Uhr: |
|
hallo kai!!!
tja... zu der "aufgesetzten" gui muss ich dir sagen, dass das nicht so einfach ist... ich würde mich erstmal hinsetzen und eine "normale" linuxversion mit qt basteln... qt ist auch unter mac os x nach aussage von trolltech frei! dieses programm müsste man dann unter allen systemen kompilieren können... natürlich sind kleine änderungen nötig... (com1 heisst unter linux zum beispiel /dev/ttyS0 und winsock braucht eine spezielle (3zeilige höchstens) initialisierung)... das ist aber alles "kleinkram"... wie gesagt, den mac kenne ich da nicht, dass müsstest du, thomas, einfach mal testen... ich denke, es kompiliert einfach so... die "aufsatzgui" erfordert einen ziemlichen aufwand... das wäre was für version 3.x oder so.. ;-))
von der java-variante halte ich nicht viel... aber das liegt an meiner persönlichen abneigung gegen java... das eigentliche problem ist aber sicher, dass ich java nicht kenne... auch ihr beide scheint java nicht zu kennen... darum würde ich sagen: schade, aber das wars... ;-)) wir kriegen das auch mit c/c++ hin!
viele grüsse
frozen |
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Donnerstag, 23. Mai 2002 - 13:04 Uhr: |
|
Hallo frozen,
eigentlich sollten wir in der Tat diese Diskussionen unter einem andern Punkt als "MacNobra" fortsetzen...
Leider stimmt es nicht, dass qt für mac osx frei ist. es gibt eine 30-tage demo-version, aber danach kostet die einfachste und billigste einzelplatz-lizenz 1550$ (http://www.trolltech.com/purchase/qtpricing.html). Wenn man sein Geld mit Crossplattform-Software verdient ist das sicher eine gute Investition, aber nicht für mich.
Ausserdem ist ein anderes Problem, dass qt nur für Mac OSX compiliert. Das ist aus der Sicht von qt verständlich, es ist sicher schon schwierig genug, die crossplatform-Eigenschaften für das momentan neuste OS hinzubekommen. Aber die alten MacOS-Versionen fallen damit weg. Und dabei geht es nur um ein paar Befehle an die serielle Schnittstelle und um einen einfachen Textaustausch via TCP/IP.
Fazit: Ich denke, man sieht dem qt-Compiler seine Geschichte an und er ist ganz offensichtlich für einen linux-Programmierer eine wunderbare Sache...
JAVA: Kenne ich von ein paar kleinen Programmen und habe eigentlich auch keine Abneigungen dagegen. Es ist inzwischen nicht mehr so "trendy" wie vor ein paar Jahren, aber warum eigentlich nicht. Ich weiss z.B. dass die TeX/LaTeX-Gemeinde ein Projekt gesponsort hat, um TeX auf JAVA zu portieren. Nur kann ich selbst die Probleme noch nicht so gut abschätzen, die da lauern, weil ich damit bisher noch keine hardware- und internetnahen sachen geschrieben habe.
Mein Vorschlag für den jetzigen Zustand wäre: Erst mal den bestehenden Chat möglichst schnell für alle Plattformen nutzbar zu machen. Das heisst, die Infos über den NobraChat-Server in einfache Programme für jede Plattform einzubauen. Dann gibt es keine "ausgeschlossenen" User mehr und wir lernen auch bestimmt viel darüber, welche Probleme es mit diesen "einfachen" Lösungen schon gibt. Im Hintergrund können wir uns dann überlegen, wie eine plattform-übergreifende Lösung aussehen könnte. Wollen wir das an IRC-dranhängen? Oder an einer eigenen Server-Lösung festhalten? Das eilt dann nicht so und wir finden vielleicht eine Möglichkeit, eine Sprache zu finden,
- die wir alle mögen und verstehen ;-)
- für die es gute und billige Compiler für alle Plattformen gibt
- die zukunftsfähig und auch wirklich leicht zu portieren ist
Vielleicht ist es eine gute Idee, sich mal Crossplatform-Software anzuschauen, und mit leuten zu sprechen, die solche Projekte schon erfolgreich abgeschlossen haben.
Bis bald
Thomas
|
hahase
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Donnerstag, 23. Mai 2002 - 15:44 Uhr: |
|
Hallo
Ich kenne mich etwas aus mit Crossplatform GUIs. Ich verwende SDL (Simple DirectMedia Layer http://www.libsdl.org ), eine OpenSource Multiplatform-Library für C/C++ um an die Grafik-Hardware zu kommen. Für die Widgets/Controls habe ich eigene C++ Klassen entwickelt, die dann via SDL auf allen Platformen mit gleichem Look and Feel laufen und. Ich könnte eine open-source Version für NobraControl/Chat machen. Allerdings weiss ich noch nicht genau, was alles auf das GUI soll. Ich denke mal ein Chat Fenster, User Liste, Eingabezeile und ein paar Sliders und Knöpfe für die Vibisteuerung sollten fürs erste mal genügen. Ein Intensitätskurvengenerator wäre dann eine Erweiterung.
Für den Chat Teil gibt es auch SDL_net, damit einfach auf die TCP/IP sockets zugegriffen werden kann. Diesen Teil kenne ich aber nicht genau. Den Common-Serverteil würde ich mal so lassen, dass auch die bestehende Clinet-Software weiter läuft.
Den Zugriff auf die serielle Schnittstelle gibts auch als Multiplatform Source:
http://sourceforge.net/projects/dzcomm/
Dieses Ding habe ich gerade gefunden und noch nicht angeschaut.
Ich entwickle auf Win32, darum müssten andere das Compilieren/Testen auf den anderene Platformen (linux, mac os9, mac osX, ... ) übernehmen. Auch habe ich (noch?) keine Hardware um das ganze live zu testen, aber die braucht man auch nicht unbedingt.
Schreibt doch, was unbedingt auf das GUI soll.
Ich denke eine Aufteilung des Projekts in GUI / Serial Port access / Chat access auf diverse Verantwortliche würde Sinn machen.
Bis bald
Hahase
|
kai
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Donnerstag, 23. Mai 2002 - 20:16 Uhr: |
|
Hallo alle, besonderer Gruss an Hahase, der sich obwohl neu, hier so prima einbringt!
Thomas 1: Ich finde Deinen ersten Ansatz OK, einfache kleine Programme zusätzlich für Linux und Mac zu machen, die dann mit dem schon vorhandenen WinProgramm NobraChat von Maria zusammenarbeiten können.
Was sollte das Programm können? Nicht mehr als NobraChat auch:
a) Textnachrichten austauschen
b) die Steuerbefehle Geschwindigkeit 0-15 übertragen können
c) sich ebenfalls als Teilnehmer beim nobrachat.pl Script anmelden können (User mit dem Nick XY online)
Alles weitere sehen wir in der Tat später und erst mal ist niemand mehr aufgrund des Betriebssystemes ausgeschlossen.
Thomas 2:Das mit IRC war nur so eine Idee, ich denke inzwischen, das wäre übertrieben, da es die Sache mit zusätzlichen Protokollen überfrachten würde. Wir wissen ja nun, dass es sich um eine einfache IP zu IP Verbindung handelt, auf der plain-text übertragen wird. Mehr ist für die Anwendung ja auch gar nicht notwendig, denn Steuerbefehle können im plain-text "maskiert" untergebracht werden (nicht mal das ist unbedingt nötig, denn was spricht dagegen, den Vibi ausser mit einem Regler auch mit einem #6 in der Texteingabezeile anzusprechen?).
Java: Da ich ohnehin eine neue Sprache lernen müsste, wäre es mir persönlich egal, welche es ist :-) Ich habe diese Sprache nur deshalb ins Spiel gebracht, weil eben Huxi damit schon was gemacht hat und hier eventuell schon ein Grundgerüst vorhanden wäre. Wir müssen aber kein Java nehmen, mir ist C/C++ ebenso recht, einarbeiten muss ich mich so oder so.
Alle: Ich habe mal nach freien Sources in C/C++ für Chats gesucht und da zumindest 2 Konsolen-/DOS-Eingabeaufforderungsvarianten (also ohne GUI) gefunden, die dem Gedanken von NobraChat offenbar schon nahekommen: 1:1 Chat und plaintext
Ich stelle das mal zum Download, wer will, kann sich das ja mal ansehen, die Sources sind dabei und frei:
http://www.erosoft.de/temp/SChat.zip (ca. 270kB Win und Linuxkompatibel)
http://www.erosoft.de/temp/TChat.zip (ca. 18kB Win)
Ihr versteht mehr von C als ich, ich habe mir gerade ein Einsteigerbuch gekauft um mich zunächst mal mit der Syntax zu beschäftigen (Konsolenorientiert ohne GUI).
Hahase: Tja, was sollte unbedingt auf die GUI? Wie Du schon selbst gesagt hast, mehr als es bei der NobraChat version ist, muss es zunächst nicht sein finde ich. Schieberegler für die Vibigeschwindigkeit, das Chattextfenster mit Eingabezeile und eine Liste, wer online ist. Spartanisch aber zunächst völlig ausreichend finde ich. Ich denke ohnehin, dass die meisten Chatgespräche im 1:1 Modus und nicht im öffentlichen Chat ablaufen (gäbe ja auch Chaos, wenn 20 Männer auf den Vibi der einzigen Dame zugreifen wollen *ggg), daher gefällt mir auch die Variante mit dem einzelnen Privatfenster je Teilnehmer so gut.
Es wäre natürlich super, wen Du so was hinbekommen würdest und dann die GUI mit diesem SDL (bitte nicht hauen weil ich es so flapsig dahinsage *ggg) für alle OS da drauf passt...
Zum Ausprobieren ohne Hardware: Eine Möglichkeit ist es auch, erst mal einen Portmonitorprogramm (z.B. Portmon) mitlaufen zu lassen, das anzeigt, ob etwas (und was) am COM-Port ankommt.
Was das Fortführen dieses Threads unter MACNobra angeht, macht mal einen Vorschlag, wie das weitergehen soll? Einen neuen Thread "Abstimmung Programmiergruppe" aufzumachen und die bisherigen Beiträge die nicht unmittelbar mit MACNobra sondern mit der Findungsphase zu tun haben dorthin zu schieben, das darf ich auch ;-) Andersherum können wir aber auch erst die Findungsphase unter welchem Label auch immer abschliessen und dann neue Threads aufmachen, wenn es sich ergibt...
So, das waren erst mal meine Gedanken dazu...
Viele Grüsse
Kai
|
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Donnerstag, 23. Mai 2002 - 22:38 Uhr: |
|
hallo leute!
erstmal: ich möchte dich, lieber hahase, auch nach mal freudig begrüssen! ;-)) toll, dass du dich so einbringst!!
nichts für ungut, aber den ansatz mit sdl finde ich persönlich nicht so besonders gut... wie kai schon mit irc sagte: das ist zuviel overhead... ich habe mir einen sehr kurzen überblick über sdl gegönnt und muss sagen, dass die fähigkeiten dieses produktes faszinierend sind! aber das ganze kann viel zu viel!
thomas, sorry... mir hat trolltech gesagt, wir könnten das ganze ohne lizenz betreiben, da wir es nicht kommerziell nutzen... ich werde das nochmal hinterfragen...
gegen java bin ich, weil ich mit der geschwindigkeit von java nicht zufrieden bin... bisher habe ich kein noch so kleines javaprogramm gefunden, dass mit c oder c++ auch nur ansatzweise mithalten kann... ich habe mal gelesen, dass java um ein vielfaches langsamer als c ist... ich erinnere mich nicht mehr genau, ich meine es war etwas um die 20 bis 65 %... nagelt mich aber nicht auf diese zahlen fest!
ich bin auch dafür, dass wir erstmal "irgendwas" kleines entwickeln, was die vorhandenen funktionen vom windoofsprogramm auch unter linux und mac nutzbar macht...
die zukunft des ganzen könnten wir dann in aller ruhe planen...
als programmiersprache würde ich auf c/c++ setzen... diese sprachen sind definitiv zukunftssicher, sie sind sehr ausgereift, schnell und vor allem auch (bei einhaltung der ansi / iso standards) gut portabel... ich hoffe, dass wir uns darauf einigen können, damit zu arbeiten... ;-)
die idee, andere leute zu fragen, die schon crossplatform programme entwickelt haben, ist sehr gut! ein konsolenbasiertes programm halte ich wie gesagt für unproblematisch... das problem was wir im moment haben ist die portabilität der gui... mac, windows und linux verfolgen da alle total andere ansätze... deshalb gibt es nicht sooo viele gui-toolkits die gleiche gui auf allen plattformen ermöglichen... qt gehört meines wissens zu den besseren, aber dank deiner einwände bezüglich mac os 9 ist diese variante wohl leider nicht möglich... wenn qt das nicht kann, dann kann es das halt nicht... sdl ist wie gesagt meiner meinung nach oversized bis zum geht nicht mehr...
hahase: das compilieren unter linux könnte ich sicher testen, kein problem!
die idee mit der aufteilung ist sicher nicht schlecht... aber es hat auch einen vorteil, wenn jeder alles von den programmen kennt... denn wenn einer vom projekt abspringt wären dann noch immer leute da, die seine aufgaben sofort weiterführen könnten.. müsste man mal drüber reden, welche variante besser ist...
die variante irc denke ich sollten wir aus den gründen, die kai aufgeführt hat, einfach mal vergessen...
kai, ich denke du solltest wirklich einen eigenen thread aufmachen... nenn ihn "nocbrachat progamm, planung für neue version" oder sowas... halte ich für eine sehr gute idee!
soviel dann erstmal von mir dazu,
viele grüsse
frozen |
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Donnerstag, 23. Mai 2002 - 22:39 Uhr: |
|
ups...
ersetzt in dem satz "aber es hat auch einen vorteil, wenn jeder alles von den programmen trennt... " bitte das "trennt" durch "kennt"...
sorry...
frozen
Anmerkung der Redaktion: Wurde geändert :-) Kai |
kai
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Donnerstag, 23. Mai 2002 - 23:35 Uhr: |
|
Hi Frozen,
wie Du sehen kannst, habe ich Deinen Tippfehler berichtigt, kein Problem, passiert eben schon mal...
Wegen des neuen Theads und dem Verschieben der Nachrichten dorthin schaue ich morgen mal, das geht nicht ganz so schnell und wir wollen ja möglichst auch keine Postings verlieren.
zu SDL: Du sagst es seie oversized und kann zuviel... Es muss ja nicht alles genutzt werden, was dieses SDL kann. Wenn man aus der Bilbliothek nur ein paar Bausteine für eine einheitliche GUI wie Fenster, Buttons, Schieberegler, Eingabefenster und Listbox (so heisst das in Profan²) braucht, dann kann man das doch quasi modular da raus nehmen, oder habe ich das flaschlraschl verstanden? Vielleicht kann Hahase uns ja mal kurz erklären, wie aufwendig das ist oder nicht?
Mit C/C++ kann ich wohl leben, nachdem, was ich heute in meinem neuen Buch gelesen habe ist es soooo kompliziert auch nicht (muss ich das Buch wenigstens nicht wieder wegbringen) *puuuh* :-)
So, nun aber Gute N8 allen
Kai |
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Donnerstag, 23. Mai 2002 - 23:48 Uhr: |
|
hallo kai!
danke wegen dem tippfehler! ;-)
in sachen sdl habe ich bei meinem SEHR kurzen überfliegen der doku gesehen, dass das ganze initialisiert werden muss... hahase, was meinst du?
ich würde das ganze am liebsten mit c machen... das kenne ich am besten... aber ich werde wohl c++ lernen müssen... ;-))
habe noch etwas interessantes gefunden:
http://www.wxwindows.org/
das könnte unser tool der wahl sein! schaut mal rein und sagt mir, was ihr davon haltet... gefällt mir ziemlich gut...
grüsse
frozen |
Hahase
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 24. Mai 2002 - 10:39 Uhr: |
|
Hallo zusammen
Ich habe WXwindows angeschaut und das scheint mir der Overkill zu sein. Die habe ja wirklich alles und jenes multiplatformfähig gemacht. Das ist sehr gut für jemand der Office portieren möchte.
Nun zu meinem Anstatz mit SDL:
Ich verwende nur einen Bruchteil davon. Zwar muss man die ganze Library (SDL.dll) mitliefern, aber die ist nur schlanke 220KB gross (bei Windows).
Ich verwende keine Buttons oder List-Controls, denn die gibt es gar nicht im SDL. Das einzige was von SDL kommt ist der Zugriff auf ein Fenster und dessen Zeichenfläche. Wenn ich an Punkt x/y ein Pixel mit der Farbe 0x00RRGGBB setzen kann, ist meim Small-GUI schon zufrieden und kann alles selber machen.
Das GUI selber zeichne ich mit Photoshop. Für die einzelnen Zustände der Buttons usw. gibt es dann verschiedene JPEG Bilder. Ein weiteres Bild definiert die Positionen als farbige Rechtecke. Mein Framework liest die Bilder ein und ersetzt dann beim Drücken eines Knopfes sein Bild durch den Ausschnitt des "gedrückten" GUI-Bildes.
Im Programm selber steht eine Liste, die die Control-Art ( Button/Switch/Edit field/usw. ) mit der Farbe des Positionsrechteckes verknüpft. Das Framework liest diese Daten ein und generiert so das GUI on the fly.
Der grosse Vorteil ist dann, dass das GUI pixelgenau auf allen Plattformen identisch ist. (Ausser beim Mac hat es vielleicht einen anderen Helligkeisverlauf (Gamma nicht genau identisch).
Die meisten Controls habe ich schon gemacht und auch Text ausgeben kann es schon perfekt, ohne Systemfonts oder andere Resourcen zu verwenden.
Ein Nachteil sehe ich noch: Da ich dieses Framework auch noch für andere Grafik-Anwendungen brauche, habe ich es bisher nur für 24 Bit Farbtiefe implementiert. Man könnte das ganze aber auch für 256 Index-Farben umbauen, damit auch Stonage-Compis das noch laufen lassen können.
Ich muss gerade los auf den Zug. Schreibe mehr später.
Gruss aus der Schweiz
Hahase
|
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 24. Mai 2002 - 11:18 Uhr: |
|
hallo hahase...
also ich weiss nicht... mich stört es etwas, dass du das ganze mehr oder weniger "zusammentrickst", indem du mit pixeln und bildern malst... das halte ich für ziemlich unpraktisch... wie implementierst du denn auf diese weise einen slider? sicher, das ganze ist ein ansatz... aber damit müssen wir auch jeden pixel genau einprogrammieren... ist auch aus dem aspekt "guianpassung" nicht so toll... wenn ich ein kde habe und ein schönes theme wähle, dann wäre es sicher toll, wenn mein programm das auch übernehmen würde... ich nehme mal an, das wxwindows das eher schafft... ach ja: wie kriegst du mit deiner sdl-lösung einen scrollbalken hin?
generell will ich uns diese option mit dem sdl nicht nehmen, bin aber eher nicht davon begeistert... ich nehme stark an, dass wxwindows und vergleichbare tools uns das ganze einfacher machen... dem sage ich wohl einfach: hey, da ist ein fenster in diesem fenster ist da ein button, dort ein multilinetextfeld, dort ein weiterer button und ausserdem hätten wir noch ein menü mit den einträgen soundso... deinem sdl müsste ich sagen: hey, da ist ein fenster mit einem button da und da, der normal mit dem bild x dargestellt wird, gedrückt mit dem bild y und inaktiv mit dem bild z, dann ist da noch ein multilinetextfeld da und da (wie geht das mit sdl?) und das menü stelle ich mir sehr tricky vor...
ich weiss es nicht... kai, was meinst du?
mfg
frozen |
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 24. Mai 2002 - 13:23 Uhr: |
|
Hallo,
Ja, wahrscheinlich ist C/C++ die beste Wahl für die Zukunft. Aber es ist doch eine ganz kreative Brainstorming-Phase, wenn wir so gemeinsam die Möglichkeiten durchspielen und die Vor- und Nachteile der einzelnen Lösungen diskutieren.
zu hahase: beim kurzen blick auf sdl war ich auch sehr beeindruckt und ich denke eigentlich, dass "viel können" kein nachteil ist, man muss ja nicht alles nutzen. im detail sieht es mit dem crossplatform-aspekt sicher auch komplizierter aus. die dzcomm-library gibt es z.B. nicht für den mac. das ist vielleicht kein beinbruch, weil man das auch selbst machen kann, aber da geht dann die einzelentwicklung auch schon wieder los.
nach deinem zweiten posting von dir bin ich ähnlich skeptisch wie frozen. das bild-basierte interface scheint mir doch recht ueberladen, und noch dazu unpraktisch, wenn es ein kraftakt ist, 256 farben "auch noch" zu bedienen. die bezeichnung der "Stonage-Compis" ist eine sichtweise, die mir ebenfalls nicht gefällt. sie erinnert mich an die "goldenen regeln für schlechtes html" (http://www.die-fundgrube.de/docs/extern/goldhtml.shtml). meine idealvorstellung ist eine software, die sich an die umgebung des jeweiligen computers anpasst, ohne dass der user das bemerkt. oder wollen wir uns am ende die peinlichkeit geben, den user aufzufordern, die farbe erst umzustellen, damit das programm richtig läuft? frozen hat recht, für diese controls und buttons gibt es gute andere wege.
zu frozen: falls es qt/mac doch umsonst gibt, warum nicht. wenn du die leute persönlich angesprochen hast, bekommst du vielleicht eine "bessere" antwort als ich es aus den internet-seiten entnommen habe. das problem mit macos 9,8,7 bleibt natürlich trotzdem bestehen.
zu irc: ich war ja auf die idee gekommen, weil nobras chat über ein irc-server läuft. generell denke ich nach wie vor, dass das vorteile hätte:
1. man muss sich nicht um den server kümmern
2. wie könnten in unsere software-versionen auch noch andere befehle versteckt unterbringen, falls wir das erweitern wollen
3. der overhead braucht uns nicht zu interessieren. wir bringen nur die befehle an die oberfläche, mit denen wir die vorhandenen user abfragen und nachrichten austauschen. dass das irc-protokoll noch mehr kann, braucht uns nicht zu interessieren.
aber natürlich kann man sich auch eine eigene serversoftware programmieren. bei mir siegt einfach oft die faulheit, wenn ich über sowas nachdenke... Warum selber machen, wenn schon jemand für mich die Arbeit gemacht hat?
Thomas |
kai
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 24. Mai 2002 - 14:45 Uhr: |
|
Hallo Leute,
ich habe noch mal überlegt und zusammengekramt, was schon an Ideen für die
Fernsteuerung vorhanden ist.
Einen ganz interessanten Ansatz, den Maria mit einem kleinen
vibremote-Programm gemacht hat, möchte ich Euch nicht vorenthalten.
Mit vibremote ist es möglich, das Steuergerät einfach über eine HTML-Seite
anzusprechen. Wir haben in den Versuchen dazu einfach ein Formular mit
Buttons gemacht, die die Informationen beim Anklicken per HTTP-GET an die IP
des laufenden vibremote Clients leiten. Dazu wird einfach der HTTP-Port 80
verwendet. Der vibremote-Client "lauscht" auf dem Anwenderrechner, setzt die
Informationen um und leitet sie an den eingestellten COM-Port weiter an dem
das Steuergerät hängt.
Auf dieser Idee aufbauend folgende Überlegung (siehe Grafik):
Ein OpenSource Chatsystem (Java Applet, Perl oder ähnliches) mit
Privat-Chatfunktion wird modifiziert und zwar so, dass das Privatfenster in
der Lage ist, per HTTP-GET die Informationen zum Steuern an die IP des
Partners weiterleiten kann. Die IP sollte ja zum Verbindungsaufbau ohnehin
bekannt sein. Im einfachsten Fall werden einfach bestimmte, in die
Eingabezeile eingegebenen Texte wie z.B. #0 bis #15 (denkbar auch #16 o.ä.
zum Starten der Sequenz im Steuergerät oder weitere Funktionen)
"ausgefiltert" und als Befehle interpretiert. Diese Befehle werden dann per
HTTP-GET auf Port 80 an den Partner übermittelt. Ist dieser einverstanden
mit dem Steuern, so hat er einen betriebssystemabhängigen Client gestartet,
welcher die Befehle annimmt und an den COM-Port umsetzt. Ist der Partner
nicht einverstanden, so ist der Client nicht gestartet (oder blockiert) und
die Befehle "versickern ungehört".
Eine "Luxus-version" könnte dann noch Buttons/Schieberegler zur
Befhelseingabe haben, obwohl das IMHO gar nicht so nötig ist, denn ein #3
ist schneller getippt, als die Maus angefasst und bewegt ist... aber das ist
erst mal egal...
Meiner Einschätzung nach hätte diese Vorgehensweise folgende Vorteile:
Es muss keine betriebssystemabhängige GUI für den Chat programmiert werden,
da die grafische Oberfläche vom Browser erstellt/gebildet wird (und damit
überall fast gleich aussieht). Das Client-Programm, welches
betriebssystemabhängig ist, würde nur eine minimale GUI benötigen (wenn
überhaupt), die das Ein-/Ausschalten (Annahme oder Verweigerung der Befehle)
und ggf. das Konfigurieren des COM-Ports ermöglicht. Wenn wir dann noch auf
ein gutes aber möglichst einfaches OpenSource Chatsystem zurückgreifen, so
ist auch hier "nur" noch der Teil zu ändern, der es ermöglicht, im private
mode HTTP-GET Befehle zu versenden.
Ob wir uns bei diesem OpenSource Chat an IRC anlehnen, oder auf zentrale
Server (nobra.de / erosoft.de usw.) zurückgreifen ist uns frei überlassen.
IRC würde hier natürlich völlig unabhängig von unseren eigenen Ressourcen
agieren können und auf jeden IRC Server als "Zentrale" zurückgreifen können, insofern ein Punkt für Thomas :-)
Das Programm vibremote kann ich Euch natürlich zukommen lassen zum
Ausprobieren, ich richte auch gern eine Testseite ein. Überhaupt kann ich
anbieten, auf meinem Homepageserver eine Art Archiv für uns Entwickler
anzulegen (passwortgeschützt per .htaccess) wo solche Proggis, Testseiten
etc. downloadbar bzw. ausprobierbar sind.
Ich würde dann jedem von Euch die Benutzerdaten per Mail senden. Wenn Maria
wieder Zeit hat, würde ich mich natürlich sehr freuen, wenn sie an dieser
Idee teilnimmt, denn die Grundzüge stammen von ihrer damaligen
Webcamfernsteuerung. Vielleicht mag sie ja auch mit dem ein oder anderen
Code-Schnipsel unterstützend eingreifen??? ;-)))
An Hahase: Ich kann mir ungefähr vorstellen, wie Du eine solche GUI aus Bitmaps zusammenbasteln willst. Als es bei Profan noch ekien Slider gab, habe ich so was auch mal mit einem Bitmap (rote Kugel auf Skala) gemacht, wo dann diese Kugel abhängig von der Mausposition "mitgeschleppt" wurde und über die Mausposition die Reglerposition und damit der "Wert" bestimmt wurde... war zeimlich aufwenidig und wenn ich dann noch an die unterschiedlichen Farbmodelle denke wirds wohl problematisch...
Aber wir sind ja erst in einer kreativen Denk- und Brainstormingphase, daher möchte ich keine "Vorverurteilung" der einen oder anderen Lösung machen, sondern erst mal eine Palette der in Frage kommenden Lösungsmöglichkeiten erörtern... Nach Abwägen der ganzen "Fürs" und "Widers" müssen wir uns latürnich irgendwann mal entscheiden :-)
Lasst mal hören, was ihr von der o.g. Idee haltet und ob ich bei den
Überlegungen den ein oder anderen Denkfehler gemacht habe.
Kai
(der sich gleich mal ans Nachrichtenschieben begeben wird) *ggg |
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 24. Mai 2002 - 16:26 Uhr: |
|
hallo kai,
ich hoffe, mein kommentar zu hahase kam nicht als "Vorverurteilung" rüber. wenn doch: sorry.
ich habe mir deine idee gerade angeschaut und sie gefällt mir gut. die lösung wirkt schön einfach und für die einzelnen clients muss nicht viel mehr gemacht werden als sowieso schon (serielle schnittstelle ansteuern).
all deine anderen ideen (testbereich etc.): toll!
Thomas |
Hahase
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 24. Mai 2002 - 16:50 Uhr: |
|
Hallo zusammen
Die Idee das ganze per Browser mit HTML zu machen ist sehr gut, wenn es denn einfach geht, denn ein Browser hat ja jeder auf dem System wenn er denn irgendwie ins Netz will.
Noch zu den Stone-Age Compis:
Da ich bisher Tools für Webdesigner und Grafiker gemacht habe, hatte ich nie Probleme wegen der Truecolor Bedingung, da diese Leute gute Grafik allem anderen vorziehen. So wie sicher jeder Musiker in seinem Compi eine gute Soundkarte hat.
Klar ist das bei dieser neuen Anwendung nicht der Fall und man möchte gerne einen alten, überzähligen Compi ins Schlafzimmer zum Spielen delegieren, das sehe ich schon ein und macht auch Sinn. Soll doch das Programm nicht den optischen Sinn ansprechen, sondern einen ganz anderen.
Zu 'Pixelgenau':
Um die Pixel braucht ihr euch nicht zu kümmern, das machen die fertigen Controls von alleine und das Erstellen von Sliders und Menüs ist genau so einfach wie bei anderen Guis. (Klasse erstellen, abfüllen und registrieren, fertig). Auch wem das Design nicht gefällt, könnte andere Skins laden, da diese nicht reincompiliert werden.
Ein Vorteil ist, dass ich SDL kenne und schon verwendet habe und ein Grossteil des Framework Codes schon vorhanden ist.
Oder wir suchen jemanden, der WXWindows kennt und weiss wie man es anwendet. Normalerweise ist die Einarbeitung in ein Framework gar nicht so einfach. Ich denke an die alte MFC Geschichte. Man hatte schnell eine Sample-App per Wizard erstellt, aber wenn es dann darum ging eine spezifische Funktionalität zu implementieren, dann ging die Sucherei und Testerei los.
Eigentlich wollte ich ja nur sagen, dass ich ein Multiplatform GUI für euch machen könnte, dann habt ihr diese Sorge mal vom Hals. Wir definieren die Bedingungen ( 256 Color ) und Interfaces (Vibi-Slider, Chatfenster etc.) und dann könnte ich bald mal ein Sample App (C++) machen. Danach fügt ihr die anderen Teile (COM-Access, Chat-Access) ein und kompilert das ganze auf den verschiedenen Zielplatformen.
Was meint ihr?
Grüsse Hahase
|
kai
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 24. Mai 2002 - 17:50 Uhr: |
|
Hi all :-),
das geht ja hier wie´s Brezelbacken mit dem Posten :-)
Thomas: Ich sprach von _mir_ mit dem Vorverurteilen, nicht von Dir, das bezog sich auf meinen vorherigen Abschnitt, in dem ich meine Bedenken gegenüber Hahase geschrieben habe. Ich wollte _meine_ Kritik nicht schon als "Urteil" verstanden haben. Also habe ich mich auch "mist"verständlich ausgedrückt :-)
Hahase: Ich finde es gut, wenn Du kein Problem darin siehst, eine "Multiplattform-GUI" zu entwerfen, wahrscheinlich kommen unsere Bedenken von der Unkenntnis dieses SDL.
256 Farben dürften völlig genügen, selbst wenn man das ein wenig "verzieren" will, denke ich... Was die "Bedienelemente" angeht, so habe ich ja schon gesagt, was ich für nötig und ausreichend halte.
Ich denke, wenn wir uns auf die grundsätzliche Vorgehensweise geeinigt haben, kannst Du loslegen, vorher loslegen hat das Risiko eventuell für die Tonne zu arbeiten und das ist ja auch nicht im Sinne der Erfinder :-)
An alle: Ich habe mal herumgesucht... Maria hat auf ihrer Homepage sowohl das kleine Programm vibremote.exe nebst Zubehör zum Download:
http://www.mysunrise.ch/users/cesco/dildonics/vibro.htm
Sogar für W2k ist was dabei wegen der Hardwarebeschränkungen des LPT ports...
Auch ein paar Sourcecodes von dem remotepenetrator-Programm sowie client und server sources in C habe ich noch bei ihr gefunden:
http://www.mysunrise.ch/users/cesco/altsource.htm
Vielleicht ist das ja auch schon eine Basis?
Viele Grüsse
Kai
|
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Samstag, 25. Mai 2002 - 17:06 Uhr: |
|
hallo leute!
sorry, mit dem code von maria kann man unter linux so gut wie nichts anfangen... :-(
mein vorschlag wäre: wir entwickeln jetzt erstmal einen client für linux und einen für mac, die sich in das bestehende system einklinken... wenn die fertig sind, dann setzen wir sie zum download auf www.erosoft.de oder so... wenn das ganze soweit läuft, dann überlegen wir uns, wie wir weiter verfahren...
die variante mit der html-seite ist gut... nur frage ich mich, wie ich jemand bestimmtes zulasse und andere bestimmte personen nicht... wenn ich dich richtig verstanden habe, bin ich entweder on oder nicht... wenn eine hübsche frau online geht mit dem nickname "meine_kleine_brauchts_jetzt", wie soll sie steuern, wer darf und wer nicht, wenn sich etwa 30 bis 40 mann auf sie stürzen? es wäre ja immerhin möglich, dass sie mit 5 davon erstmal privat reden möchte, ohne dass die ihren vibi steuern... ausserdem fiel mir auf, dass du von einem minimalgui programm sprichst, dass plattformspezifisch sein müsste... wenn minimalgui auch textbasiert sein kann, dann muss es das nicht! wie gesagt: ansi-c bzw. iso-c ist auf allen os gleich!
ich werde, wenn ich die zeit irgendwo finde, mal schauen, wie sich wxwindows so nutzen lässt... wenn ich das ganze als nicht besonders schwierig empfinde, dann könnte ich damit schon mal "irgendwas" basteln, was unter anderem auch ne steuerbox an einer seriellen schnittstelle steuert... einfach nur ein progrämmchen, dass keinen chat oder sowas beinhaltet... ganz simpel und klein... dann versucht ihr das ganze auch auf winblöd und mac os zu compilen... wenn das problemlos geht, dann würde ich sagen, nutzen wir das... wenn nicht, dann suchen wir weiter... was haltet ihr davon?
alles in allem sollten wir mal ganz langsam auf eine entscheidung hinsteuern.. ;-)) ich fände es noch immer optimal ein und den selben sourcecode auf allen plattformen einzusetzen... wenn ihr das nicht so wichtig findet, dann können wir uns auch noch ganz andere sachen einfallen lassen.. was mir noch so auffällt, wäre, dass wir die gui tatsächlich in html auslagern könnten... und zwar recht simpel... und jetzt kommts: dynamisch! unser programm läuft dann textbased und produziert konstant eine neue htmlseite die einen teil immer gleich hat: den refresher, der den browser anweist, alle 5 sekunden ein refresh zu machen... oder alle 2 sekunden oder so... das wäre vielleicht machbar, oder?
ich sehe jedenfalls, dass jeder von uns immer wieder neue ideen in den raum wirft und niemand irgendwelche ideen verwirft... ,-)) wir sollten vielleicht mal ein paar unserer ideen als "das machen wir nicht" aussieben... sonst müssen wir hier bald über etwa 20 ideen zugleich nachdenken...
viele grüsse
frozen |
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Montag, 27. Mai 2002 - 00:57 Uhr: |
|
hallo,
mal eine kleine "notbremse" meinerseits. aus meiner sicht gibt es keine notwendigkeit, uns schnell zu entscheiden. im gegenteil: ich vermute, dass ich selbst erst in der lage bin, eine gute entscheidung zu treffen, wenn ich
1. meinen Teil bei "MacNobra" fertig habe. Das GUI an sich (also die Buttons und Slider) ist dabei nach meiner Erfahrung nicht wirklich ein Problem. Es geht eher darum, wie das Programm zu bedienen ist, welche Möglichkeiten die User in die Hand bekommen sollen etc (s.u. dazu mehr). Und wir können uns dann auch bestimmt besser dasrüber unterhalten, wie man sich in einen bestehenden chat (NobraChat) "reinprogrammiert"... Gewöhnlich kommen einem die Ideen über einen guten Aufbau eines Programmes erst dann, wann man konkret daran arbeitet. Und sicher beeinflusst das, was wir mit dem Programm machen wollen auch, was denn nun die beste Lösung ist. Ich würde also sagen: "First things first".
2. von einer möglichen crossplatform-Lösung (wxwindow, sdl, qt etc.) irgendein bereits erfolgreich laufendes freeware-programm mit ähnlichen anforderungen (chat, serielle schnittstelle) habe laufen sehen. ich halte die bisherigen vorschläge für interessant, aber aus meiner mac-sicht gibt es bei 2 lösungen bereits einschränkungen (schnittstellen-library bei sdl, ältere os-versionen bei qt).
Tja, was soll das Programm können? Ich möchte Euch kurz erzählen, was mir beim Gestalten von MacNobra durch den Kopf gegangen ist.
1. Ich habe die Unterscheidung zwischen einer "festen Geschwindigkeit" und den "Interval"-Typen als künstlich empfunden. Es scheint mir einfacher, die feste Geschwindigkeit als einen Spezialfall des Interval-Betriebes zu verstehen. Keine wichtige Sache, aber naja.
2. Als ich darüber nachgedacht habe, wie die Befehle übers Internet eingebunden werden können, dann fand ich es naheliegend, dass die Internet-Befehle einfach die Funktion des Mausklicks des Benutzers ersetzen. Aber dann wird es schon interessant: Warum sollte die Fernsteuerung nur eine feste Geschwindigkeit einstellen und nicht auch einen Vibrations-Typ? Dafür wäre es gut, zusätzlich zu den <#1>-Befehlen auch sowas wie
INT typ=2,time=1s
übertragen zu können, also die Art der Vibration (zufällig oder wechsel zwischen min und max, oder...) und das Zeitintervall der Geschwindigkeitswechsel.
3. Diese Befehle soll man natürlich nicht im Chat "eintippen", sondern sie sollten genauso einfach eingegeben werden als würde man den eigenen Vibrator ansteuern.
4. Zwar liesse sich das auch mit HTML-Formularen und Buttons hinbekommen, aber intuitiver wäre das bestimmt, wenn die Benutzer das innerhalb der selben Software machen könnten.
5. Sollte bei so einem Ansatz auch die minimale und maximale Geschwindigkeit einstellbar sein? Ich finde es eigentlich nicht, zumindest nicht generell. Ich könnte mir vorstellen, dass die Stufe 15 für manche zu heftig ist. Der "empfangende" Teil des Chats stellt also Min- und Max selbst ein, damit alles im "grünen" Bereich bleibt. Die Fernsteueung bezieht sich dann immer auf diesen Bereich.
6. Noch ein Aspekt, der für ein Einbinden der Steuerung in die selbstgeschriebene Software spricht (und gegen eine reine HTML-Steuerung): Es besteht die Möglichkeit, zwei Vibratoren "gleichzuschalten". Eine Änderung des Typs wirkt sich nicht nur auf den ferngesteuerten Vib aus, sondern gleichzeitig auch auf den eigenen. Das mag besonders für meinen Lieblingstyp (Mausposition bestimmt die Geschwindigkeit) interessant sein.
7. Wenn wir schon beim "Abgleichen" von 2 Vibs sind: Warum sollte man seine Lieblings-Sequenz nicht via Chat an den anderen User schicken? Da hat man lange gebastelt an einer schönen Sequenz und mit einem einfachen Mausklick kann die Sequenz übertragen werden. Ich denke, das könnte mit einem Befehl der Art
SEQ time1=4,data1=5,time2=6,data2=15,...
oder noch kürzer
SEQ 4,5;6,15;...
übertragen werden.Auch dies sollte natürlich nicht eingetippt werden. Stattdessen soll eine aktuell ausgewählte Sequenz per Button losgeschickt werden.
Spätestens dann wird es nicht mehr möglich sein, diese Steuerung über HTML zu lösen, da der Browser die selbst gebastelten Sequenzen nicht kennt.
Ob wir dies alles wirklich wollen oder nicht, wir sollten uns solche Möglichkeiten offenhalten. Ich werde im Rahmen meiner MacNobra-Programmierung diese Sachen bestimmt mal ausprobieren.
Noch eine letzte Sache zum Schluss (sorry, es ist wieder sehr lang geworden...). Wir denken zur Zeit an Windows, Linux und Mac. aber es gibt natürlich noch andere Betriebssysteme. Nicht, dass wir an alles denken müssen. Aber es gibt da zum Beispiel noch die schönen kleinen "handhelds", die sich für den Einsatz im Schlafzimmer möglicherweise besser eignen als der "durchschnittliche PC" mit 19-zoll-Monitor. Ich selbst programmiere auch für "die Mutter aller Handhelds", den guten alten Newton und ich kann mirs bestimmt nicht verkneifen, auch ein Nobra-Programm für den Newton zu schreiben, auch wenn die Schnittmenge von Nobra- und Newtonbenutzern genau 1 User sein sollte. Das Teil ist Internet-fähig, hat eine serielle Schnittstelle und ist schön handlich. In Zukunft werde ich bestimmt auch für den Palm programmieren, der noch handlicher ist. Was will ich damit sagen: Lasst uns eine einfache Lösung finden, in die sich viele Systeme ohne grosse Probleme reinhängen können. Mir scheint das viel wichtiger als ein gemeinsamer Quellcode.
So, wie gesagt, ich würde meinerseits gerne eine Pause in der "crossplatform"-Diskussion einlegen, ohne was zu verpassen. Was meint ihr?
Gruss
Thomas |
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Montag, 27. Mai 2002 - 10:18 Uhr: |
|
hallo thomas...
mann, du hast mal wieder nen halben roman geschrieben! ;-))
also gut, ich kommentiere mal:
zu 1.: das ist sicher richtig... ich muss zugeben, dass ich mit der nobracontrol software noch nicht begonnen habe... ich konzentriere mich momentan noch stärker auf die chatgeschichte... linuxer wollen keine software für sich allein! ;-)) einigen wir uns jetzt darauf, das "normale" programm ohne internetfunktionalität vorzuziehen?
zu 2.: wir müssten uns also auf wxwindows einschiessen... das scheint mir die einzigste non-kommerzielle multiplattform-gui-geschichte zu sein... --- die idee mit den intervalltypen wäre vielleicht umsetzbar...
zu 3.: womit wir wieder bei gui im internet wären, und somit bei wxwindows...
zu 4.: siehe 3... ;-)
zu 5.: das wäre ein feature für version 1.2 oder so, denke ich, aber sicher sollten wir das nicht vergessen!
zu 6.: mmmhhh... joa, das wäre was für version 1.3... ;-)))
zu 7.: damit wären wir bei version 1.5 oder so... ;-)))
tja... handhelds... ich habe selber einen palm und muss ehrlich sagen, ich würde den nicht im schlafzimmer einsetzen wollen! für mich ist das ein reines arbeitstier... anbindung des palm ans internet ist via handy irre teuer und ne serielle schnittstelle habe ich auch noch nicht gefunden... ich denke mal, dass die verbreitung von handhelds auch nicht sooo besonders gross ist, wahrscheinlich noch viel kleiner als die der macs... somit würde ich vorschlagen, damit noch lange zu warten... erstmal die drei "grossen" betriebssysteme abfertigen... ;-))
ach ja, sorry, dass ich so viele deiner vorschläge auf zukünftige versionen verlege! aber ich denke wir sollten erstmal eine kleinste version erstellen... wenn die grundlagen laufen, dann können wir immer noch erweitern...
viele grüsse
frozen |
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Montag, 27. Mai 2002 - 11:24 Uhr: |
|
hallo frozen,
(fast) ganz kurz ;-)
zu 1: nein, im gegenteil. ich werde versuchen, diese ganzen chat-sachen in MacNobra mit dem bestehenden NobraChat-Server auszuprobieren. mir geht es darum, erfahrungen zu sammeln. die linuxer denken manchmal, sie wären was besonderes ... ;-)
zu 2: genau das möchte ich nicht: "einschiessen". und natürlich ist das mit den intervall-typen umsetzbar. soviel programmieren sollten wir hinkriegen, egal mit welchem system.
zu 3. & 4: das hat mit wxwindows nichts zu tun.
zu 5.-7.: oder bei MacNobra 0.95 ;-)
zu handhelds: von handy war keine rede. wenn ein "arbeitstier" ein modem und einen drucker ansteuern kann, warum dann nicht einen nobra? vielleicht hatte ich mich schlecht ausgedrückt: ich meine nicht, dass wir die handhelds jetzt "abfertigen" sollten, wir sollten sie nur nicht ausschliessen. das heisst vor allem: machen wir das ganze (vor allem den server) so einfach wie möglich - so schlank wie jetzt.
du brauchst dich nicht zu entschuldigen, dass du meine vorschläge auf zukünftige versionen verschiebst. erstens werde ich mich nicht zurückhalten, die dinge bereits jetzt auszuprobieren. und zweitens war sinn und zweck des postings, den schwerpunkt von diesen crossplatform aspekten zum herz der software zu verlagern: was soll die software können.
eine kleine analogie zum schluss: das "www" wäre wahrscheinlich nie so erfolgreich geworden, wenn es nicht so eine einfache sprache wie html gegeben hätte, die von jedem browser "vor ort" umgesetzt wird. eine crossplatform-entwicklung von browsern war dafür nicht so wichtig, hauptsache die verschiedenen browser wissen, was sie mit html anfangen müssen. entsprechend sollten uns die befehle wichtiger sein, die die user untereinander austauschen können.
bis bald
Thomas |
Hahase
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Dienstag, 28. Mai 2002 - 11:37 Uhr: |
|
Hallo zusammen
Ich habe heute wieder mal in das Projekt geschaut und habe einiges gelernt.
Zuerst habe ich mit Internet Protkollen ( TCP, UDP und Sockets ) etwas schlau gemacht. Eine gute Hilfe dazu siehe: http://www.ecst.csuchico.edu/~beej/guide/net/
Dann habe ich die bestehende Software ( NobraChat ) installiert und mit Telnet eine Verbindung (lokale) gemacht, damit man alles mal schön austesten kann. Sehr zu empfehlen. Ich denke, wir können das bestehene Protokoll weiter verwenden, das es so sehr gut funktioniert.
Kais Sample Code SChat ( http://www.erosoft.de/temp/SChat.zip (ca. 270kB Win und Linuxkompatibel) )
Könnte verwendet werden. Allerdings verwendet dieses UDP und NobraChat verwendet aber eine TCP Verbindung. Darum können diese momentan noch nicht zusammen schwatzen. Aber das kann man ja abändern. Dieser Code läuft schon unter Linux und sollte zumindest auch auf einem Mac OSX zum Laufen gebracht werden können. Dazu ist er noch sehr lesbar.
Der Code TChat taugt nicht viel für unser Projekt, da es nur für Windows gemacht wurde.
SDL_net habe ich nun auch angeschaut und ich versuche mal einen Console-Client/Server zu machen, der wie Telnet direkt einen TCP NobraChat Kanal aufmachen kann. Entweder mit SDL_net oder einer SChat-Modifikation.
Wenn das dann geht, werde ich das Ganze noch in ein portables GUI packen.
Dann fehlen nur noch die COM/TTY Zugriffe für die verschiedenen Platformen (Mac).
Gruss Hahase |
Hahase
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Mittwoch, 29. Mai 2002 - 10:40 Uhr: |
|
Hallo zusammen
Ich habe mal zwei Beispiele zusammengebaut um die TCP Sachen zu testen. Sie basieren auf dem Code von SChat und sollten auch unter UNIX/LINUX kompilierbar sein. Das konnte ich allerdings wegen fehlenden Platformen nicht testen. Aber da ist sicher jemand, der das machen kann.
Das erste Sample NobraTelnet ist ein Telnet ähnlicher Client, der mit NobraChat eine Verbindung aufnehmen kann.
Das zweite Sample NobraUserlist zeigt die Liste aller angemeldeter User auf dem NobraChat Server ( www.erosoft.de/cgi-bin/Nobrachat.pl ).
Beide Sample sind consolen-basiert und brauchen noch kein GUI.
Ach ja und hier noch der Code zum Downloaden:
http://hahase.netfirms.com/Code/NobraTelnet.zip (ca. 7 KB)
http://hahase.netfirms.com/Code/NobraUserlist.zip (ca. 7 KB)
Sie sind so einfach wie möglich gehalten, ganz ohne Schnörkel und sollen nur ein Beispiel sein.
Hahase |
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Mittwoch, 29. Mai 2002 - 19:07 Uhr: |
|
hallo hahase,
das ist schoen, dass du so gut vorankommst. dann hast du dein programm bestimmt bald fertig. auch wenn ich noch nicht in deinen sourcecode reinschauen konnte, scheint das doch zu bestaetigen, dass das "einklinken" in den bestehenden chat gut zu machen ist.
trotzdem hat sich an meiner einschätzung von neulich nichts geändert. auf den sdl-zug werde ich erst einmal sicher nicht aufspringen. wenn ich es recht sehe, würde ich CodeWarrior Pro 4 (500$) brauchen, um die library nutzen zu können. oder sollte ich uns allen raten auf codewarrior umzusteigen? immerhin machen das macromedia, adobe und microsoft auch, um ihre crossplatform-software zu entwickeln. ;-)
Thomas
|
kai
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Mittwoch, 29. Mai 2002 - 22:04 Uhr: |
|
Hallo alle,
sorry, hab gerade nicht soviel Zeit zum Schhreiben.
Hahase: Ich habe versucht, Dein Programm auf dem Linux-Rechner
mit gcc zu kompilieren und zum Laufen zu bringen.
Leider wirft gcc diese Fehlermeldung aus:
Ansonsten hätte ich es gern probiert... wo liegt der Fehler?
Ich halte diesen Ansatz für prima! Mit telnet konne ich inzwischen
auch auf das schon bestehende NobraChatprogramm zugreifen.
An alle: Nein, wir müssen hier nicht endlos diskutieren :-)
Eventuell kann ja auch erst mal jeder seine Ansätze als Muster
zeigen, so wie Hahase es jetzt gemacht hat.
Wenn das Konsolenchatprogramm gelaufen wäre, hätte ich mal versucht,
hier im Heimnetzwerk einen Windowsrechner mit dem NobraChat anzusprechen.
Bis demnäxt... etwas in Eile
Viele Grüsse
Kai
|
Hahase
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Donnerstag, 30. Mai 2002 - 08:48 Uhr: |
|
Hallo Kai, hallo Thomas
Noch kenne ich gcc nicht, aber laut Meldung findet er die Referenz auf die Klasse CComm nicht. Diese ist in der Source NobraTelnetComm.cpp und NobraTelnetComm.h definiert.
Laut Readme.txt vom original SChat muss man es wie folgt kompilieren:
For Linux compilation: gcc *.cpp -o udp -lpthread
Wegen Codewarrior:
Ein Kollege von mir hat SDL auf dem OsX kompiliert ohne Codewarrior, nur mit dem mitgelieferten Tool ( ProjectManager oder so ?? ). Ich werde mal nachfragen, ob das dann auch auf den Os9 usw. läuft.
Ich hatte noch eine weitere Idee und werde auch mal in diese Richtung etwas forschen, falls ich Zeit finde. Man könnte den Chat-Client auch mit Flash und ActionScript codieren. Dann läuft das auch auf allen und muss nicht mal neu kompiliert werden. Ob da allerdings COM/TTY Support dabei ist bezweifle ich.
Frage an alle: Kann man den gcc auch für Windows haben und wo bekommt man ihn? (Wenn das gerade jemand beantworten kann, so ist das gut, ansonsten finde ich es auch selber hinaus.)
Grüsse
Hahase |
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Donnerstag, 30. Mai 2002 - 15:51 Uhr: |
|
hallo leute!!!
also: ich habe es geschafft das programm nobratelnet von hahase unter linux zu compilieren und auszuführen! es funktioniert! zeigt aber ein sehr seltsames verhalten im zusammenhang mit dem hostname: ich darf keine ipadresse angeben, sondern MUSS einen dnsnamen angeben... und der empfang von nachrichten fehlt noch.. ;-)) aber ansonsten: kompliment hahase! gefällt mir sehr gut!!! ich werde dein programm vielleicht noch ein wenig erweitern, wenn du einverstanden bist...
kai: zum kompilieren kannst du KDevelop nehmen... erzeug einfach ein neues c++-projekt, entferne die datei main.cpp aus dem projekt und füg die von hahase gesendeten hinzu... dann noch flugs F7 gedrückt und unter linkeroptionen im feld "weitere bibliotheken" "-lpthread" ohne "" eingeben, fertig... ;-))
ich teste dann mal das andere programm für die userlist...
gruss
frozen
|
kai
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Donnerstag, 30. Mai 2002 - 19:39 Uhr: |
|
Hallo ihr alle,
ich habe unter Windows mit dem Visual C++ Autorensystem (also das mit dem Hinweisfenster) aus meinem Buch das Programm NobraTelnetMain kompiliert und zur exe gelinkt bekommen.
Es läuft prima und die Kommunikation klappt zumindest lokal auf meinem Rechner prima.
Neben Text, lässt sich auch durch händische Eingabe der Geschwindigkeitsbefehle (z.B. <$>d) der NobraChat ansprechen und das Steuergerät betätigen.
Auch der "Empfang" der Daten vom NobraChat klappt zumindest lokal einwandfrei, es wird wie im telnet alles im DOS-Fenster gezeigt...
Ich versuche nachher mal mit meinen ersten winzigen C++ Kenntnissen die von frozen geschriebene Routine zum Ansprechen der COM-Ports in das von hahase erstellte NobraTelnetMain einzubauen... mal sehen, ob mir das gelingt *auhauahauaha* :-)))
hahase: Ich weiss nicht, ob es ein gcc auch für Windows gibt, ich glaube aber nicht sehr daran...
Im übrigen klappt unter Linux das Kompilieren und Linken immer noch nicht, gleiche Fehlermeldung... mein Buch spricht davon, dass die mit Visual C++ erstellten Programme in Projekte eingebettet sind... liegt es da dran?
frozen: Woher bekomme ich KDevelop? Ist das in der SuSe 7.3 pro Edition irgendwo mit drin?
So, das wars erst mal in Kürze...
Kai |
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Donnerstag, 30. Mai 2002 - 20:15 Uhr: |
|
hallo kai!
ja, kdevelop ist dabei! ist aber fehlerhaft, lad es dir besser bei www.kdevelop.org in einer neueren version runter... ;-))
den gcc gibts unter windoofs... er ist zum beispiel bei cygwin dabei... http://www.cygwin.com/mirrors.html
ich hab leider momentan stress, sorry...
bis bald
frozen |
paula
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Donnerstag, 30. Mai 2002 - 21:00 Uhr: |
|
hi frozen, du weisst, dass ich von eurer programmiererei nichts vertstehe...aber nur kurz einen gruss gegen stress...:-)) |
Thomas
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 31. Mai 2002 - 03:06 Uhr: |
|
Hallo Hahase,
Ja klar, bei OSX ist ein Compiler dabei (http://developer.apple.com/tools/projectbuilder/index.html). Damit werden vor allem Programme für OSX geschrieben, durch den Einsatz der Carbon APIs lassen sich auch Programme übersetzen, die mit Hilfe der CarbonLib auch unter OS8.6 bis 9.2 laufen.
Aber ich finde das Einschränkung genug. Ich habe das schon mehrfach hier beschrieben: Die Anforderungen an das Programm sind so gering (Serielle Schnittstelle ansprechen, Text über IP-Verbindung senden und empfangen), dass es mir nicht einleuchten will, ältere OS-Versionen nicht noch mitzunehmen. Denn umgekehrt laufen Programme für OS7 und 8 problemlos unter den neueren Versionen.
Das spricht für mich für eine Entwicklungsumgebung, die alle Mac-OS-Versionen bedienen kann (Codewarrior, RealBasic). Ohne SDL koennte ich meine älteren Codewarrior-Versionen benutzen. Naja, ich mache jetzt erst einmal die angefangene Realbasic-Version fertig...
Bis bald
Thomas
|
kai
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Sonntag, 02. Juni 2002 - 19:41 Uhr: |
|
Hi all,
hier ein weiterer, kurzer Zwischenbericht:
Auch mit KDevelop klappt das Kompilieren/Linken irgendwie nicht...
KDevelop versucht da immer ein Programm mit GUI draus zu machen.
Unter Windows funktioniert es mit Visual C++ prima was das Kompilieren/Linken angeht.
Allerdings funktioniert der Austausch von Text bzw. Steuerbefehlen nur lokal auf einem Rechner.
Es klappt nur, wenn in desthost = "localhost"; steht, selbst mit einem
desthost = "127.0.0.1"; gehts schon nicht mehr... damit funktioniert natürlich auch ein
desthost = "192.168.1.4";(IP des eigenen Rechners in Homenet) ebenfalls nicht und auch die Aufnahme von Verbindungen zu 192.168.1.2 und 192.168.1.3 laufen nicht... (auf allen läuft Windows mit dem NobraChat).
Was das Einbinden der Schnittstellen angeht, so bin ich leider noch keinen Schritt weiter.
Viele Grüsse
Kai
|
Hahase
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Dienstag, 04. Juni 2002 - 08:54 Uhr: |
|
Hi all,
Also bei mir auf Win2K geht das (leider) alles.
desthost = "localhost";
desthost = "127.0.0.1"; (Localhost IP)
desthost = "10.0.0.6"; (Homenet Adr.)
Mit dem Debuger hab ich dann geschaut, ob das richtig durchkommt in der Funktion:
if ( atoi( desthost ) ) // Is the host passed in IP format ("127.0.0.1")
{
u_long ip = inet_addr( desthost ); // wandelt um nach 0x0100007F
hostdata = gethostbyaddr( ( char * ) &ip, sizeof( ip ), AF_INET );
}
else // otherwise, assume it's a name
{
hostdata = gethostbyname( desthost );
}
Das scheint soweit alles prima zu klappen.
Ich habe noch auf einem anderen Rechner Linux (Suse7.3) installiert. Konnte aber noch keine Netzwerkverbindung zum NT-System aufbauen, obwohl Samba installiert ist. Zudem ist es extreeeeeem langsam ( auf einem 650Mhz, 256MBRam System). Bin halt noch ein Linux Newbie.
Gruss an alle
Hahase |
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Mittwoch, 05. Juni 2002 - 00:09 Uhr: |
|
hallo leute!!
Kai: nach meiner anleitung von oben müsste es compilen... versuch es nochmal und sag mir, wo es dann klemmt?!
dieses problem mit dem desthost = "blabla" hatte ich auch, du musst nur anstelle von blabla einen (!!) DNS-Namen (!!)eingeben... KEINE ip... dann gings bei mir problemlos... das kannst du austricksen, indem du in der /etc/hosts einen eintrag in der form "x.x.x.x meinpc" ohne "" eingibst... unter windoofs ist die hosts entweder in c:\windows oder bei win2k oder nt unter c:\windows\system32\drivers\etc\hosts ... versuchs mal...
hahase: wieso samba? mount -t smbfs //x.x.x.x/freigabename /wohin , du musst nur x.x.x.x durch die ip des nt und /wohin durch einen existierenden mountpoint ersetzen... es bietet sich /mnt an... komplettes beispiel:
mount -t smbfs //10.0.0.6/c$ /mnt -o username administrator
(wenns so nicht geht lass mal den -o username administrator weg und ersetze c$ durch eine "normale" freigabe..)
schon hast du nach eingabe deines administratorkennworts vollzugriff auf deine C-Partition von windoofs... ;-))
dass der unter linux lahm ist, sollte eigentlich nicht sein... hast du vielleicht eine "einfach alles" installation gemacht?? hört sich jedenfalls so an, als würdest du tonnenweise rümpel mitstarten, den keiner braucht... ;-))
tut mir leid, dass ich mich in letzter zeit so selten melde, ich habe momentan mächtig stress... morgen mittag fahre ich nach karlsruhe, komme donnerstag nacht wieder und muss am freitag den ganzen tag nach düsseldorf... mein wochenende ist auch schon verplant, leider nicht für disco-, kneipen-, strand- oder ähnliche angenehme besuche... is nix mit freizeit! naja, was solls... ;-)) ich melde mich aber, sobald ich mal wieder zeit habe...
gruss
frozen |
Hahase
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Mittwoch, 05. Juni 2002 - 16:22 Uhr: |
|
Hallo Frozen
Das Mounten hat funktioniert, soweit sogut. Nur habe ich dann von W2k immer noch kein Zugriff auf Linux.
Aber der Speed kommt immer noch nicht hoch. Ich habe das ganze nochmals neu installiert (ohne Gerümpel) und das Starten des Konqueror ins Homeverzeichnis dauert immer noch satte 15 sec. Das gleiche mit W2K ( Explorer auf local files ) dauert auf einem fast identischen System nur 1 sec! Irgendwas sitzt mir da gehörig auf der Leitung. Ich konnte auch mit ps keine Backgroundtasks ausmachen die CPU time verschwenden.
Der Pfad der Hosts ist unter W2k übrigens:
c:\winnt\system32\drivers\etc\hosts
Gruss
Hahase
|
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Freitag, 07. Juni 2002 - 00:42 Uhr: |
|
hallo hahase!
ups... naja, ihr seht, ich mag windoof nicht soo sehr! ;-))
zugriff auf linux? wozu? halte ich für gefährlich, wenn du ein komplettes linux-dateisystem für windoofs öffnen willst... gibt sicher nur ärger! ich persönlich löse das über eine "shared" partition mit fat... da lege ich alles linuxzeugs rein, was ich unter windoof testen will und umgekehrt... beispielsweise mp3's... ;-)
warum deine kiste so unendlich lahm ist, kann ich von hier leider auch nicht beurteilen... wenn ich die zeit hätte, und du wolltest, dann könntest du mir mal ssh zugriff gewähren und dein rootkennwort kurzzeitig auf "test" ändern, damit ich mir das ansehen kann... idealerweise kurz nach der installation, damit du das unbesorgt tun kannst... aber:
leute, ich habe momentan total keine zeit... *seufz* ich bin gerade aus karlsruhe zurück und muss morgen nach düsseldorf... der abend ist verplant, und am wochenende werde ich auch wieder keine freizeit haben... ratet mal, was am montag und dienstag und die tage danach kommt? richtig! stress... naja... kann man nichts machen... wenigstens habe ich schonmal ein qt-buch... ;-))
bis dann!
gruss
frozen |
kai
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Montag, 08. Juli 2002 - 22:10 Uhr: |
|
Moin Leute,
na, was gibts Neues?
Schon erste Tests gefahren? ;-)
Viele Grüsse
Kai |
hahase
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Dienstag, 09. Juli 2002 - 08:41 Uhr: |
|
Hallo Zusammen
Ich bin zurück aus den Silicon-Valley (dem originalen in Californien ;-)) und deshalb total mit Arbeit überhäuft. Abgabetermine hängen dunkel über dem Firmament. Aber bald sollte es bessern und dann kann ich wieder anderes machen nebenbei.
Liebe Grüsse
Hahase |
frozen
Bewertung: -
Abstimmungen: 0 (Abstimmen!) |
| Veröffentlicht am Dienstag, 09. Juli 2002 - 22:56 Uhr: |
|
hallo zusammen...
leider muss ich mitteilen, dass ich gar nicht voran gekommen bin... :-((( stress ohne ende! aber ich habe es nicht vergessen... im gegenteil, ich bedauere sehr, keine zeit dafür zu haben... vielleicht kann mir jemand zur beschleunigung seinen code (sofern vorhanden) zukommen lassen? wäre nicht schlecht...
liebe grüsse
frozen, der sich jetzt wieder in die arbeit stürzt...
|
|
