Was prinzipiell auch schön wäre, wäre eine Java-Anwendung die auf allen üblichen Plattformen funktioniert. Man muss sich allerdings schon verdeutlichen, dass so eine Anwendung sehr viel Aufwand erfordert. Und man mal genau evaluieren müsste wie die HID Kommunikation in Java bei den verschiedenen Plattformen aussieht.



Gruß Max Payne

Java läuft zwar prinzipiell überall, aber man braucht für jede Plattform trotzdem eigene Treiber.

Eine WebBasierte Lösung würde mir persönlich am besten gefallen. Sprich neben der eigentlichen AE5 Elektronik noch ein minimal SOC mit auf dem (ähnlich wie auf einem Router oder einem Kabelmodem) ein mini-WebServer läuft. Mit AJAX sieht das dann idR. auch recht schick aus und funktioniert in Echtzeit. Damit hat man viele Fliegen auf einem Schlag erwischt: Das AE funktioniert auf jeder erdenklichen Plattform, selbst übers Smartphone bekomme ich zugriff darauf aber auch für Umbauten auf Basis aktueller Konsolen wären fürs AE auf einmal interessant, das AE kann auch als StandAlone Gerät verwendet werden und dedizierte Projekte ließen sich besser verwirklichen.

ABER das ist wohl oder übel eine Utopie. Zum einem wäre das nicht zu bezahlen, schon gar nicht da das AE made in Germany ist und zum anderen ist das auch eine beträchtliche Neuentwicklung. Da die ASuite auch schon keine all zu einfache Software ist stellt man so ein System auch nur ungern nochmal von Grund auf um.

Sören

das kan passieren wenn ein übertragusgsfehler über den USB kommt. Das kann man so leider nicht verhindern. Also eventuell vorher mal die aquasuite zu machen.

Zitat von »Man_In_Blue«

Java läuft zwar prinzipiell überall, aber man braucht für jede Plattform trotzdem eigene Treiber.

Ja und nein, es gibt schon Ansätze die genau dieses Problem umgehen. Prinzipiell juckt es mich schon lange für das aquaero 4/5 mal eine Java-Version zu coden die die rudimentären Funktionen beinhaltet, insbesondere weil Java die Sprache ist, mit der ich auch schon größere Dinge als ne aquasuite umgesetzt hab.

Wenn man sich auf ne praktikable GUI (z.B. Qt) einigen kann, die auch auf allen üblichen Plattformen verfügbar ist, kann man schon mal so ein Projekt anfangen, und den Code auf GITHub stellen.


Gruß Max Payne

Wenn de Java willst, wär das Toolkit dann vermutlich Swing, wenn du auf der anderen Seite Qt willst wäre die Sprache C++. Ich hätte bei beidem keine Skrupel mein scherflein Code beizutragen, und auch wenn ich es bin der das sagt, ich bin ein ganz brauchbarer Codedesigner. Die HID-Seite ist wie du hier siehst: http://code.google.com/p/javahidapi/ in Java nicht das Problem, problematischer wird es schon, die Wartezeit zu überbrücken bis AC endlich die Schnittstellendefinition rausrückt... Im Ernst Jungs, ihr könntet erst mal das Grundlegende rausrücken was sich nicht mehr ändert, ich warte seit nem Gottverdammten JAHR drauf, anfangen zu können!!!

Zitat von »drdeath«

Wenn de Java willst, wär das Toolkit dann vermutlich Swing, wenn du auf der anderen Seite Qt willst wäre die Sprache C++.

Kurz gesagt nein, Java geht auch mit Qt.

--> http://qt-jambi.org/

Allerdings würde man sicherlich auch mit Swing eine adäquate Oberfläche hin bekommen, ist immer nur die Frage, was man als schick erachtet. Da ist nun mal Microsoft mit C# in Verbindung Visual Studio eine andere Hausnummer.

Auch die javahidapi hab ich mir schon angeschaut, allerdings ist das auch noch nicht die goldene Lösung. Zum einen ist das halt ne frickel API die dann im realen Einsatz erst mal fehlerfrei funktionieren muss, und zum anderen kann ich mir nicht vorstellen, dass man ohne "Weiche" unter allen drei (Linux, Windows, Mac OS) das sauber zum laufen bekommt. Das geht schon los, dass man laut der Readme die Teil wohl pro Betriebssystem builden muss.

Prinzipiell könnte man das ja mal mit dem aquaero 4 testen, und schauen, ob man da vernünftig Daten aus dem Gerät auslesen kann. Wenn das schon mal geht, kann man ja mal anfangen ne gui u basteln. Ich werd das mal mit dem aquaero 4 testen, allerdings nicht die nächsten 8 Wochen.


Gruß Max Payne

Ok, Qt mit Java, das ist schon fast unzüchtig... Na ich schau's mir mal an, dafür mag ich Qt einfach viel zu gern und im Vergleich zu dem Gepfriemel mit dem Swing-Toolkit ist es schlicht himmlisch.

Die bisherigen Aquaero4, etc-implementationen für Linux hab ich quasi alle ausgecheckt, aber ich konnte mich bisher mit keiner so richtig anfreunden, hatte allerdings auch nicht so wirklich viel Zeit mich damit zu befassen.

Auf der anderen Seite, aus meiner Erfahrung als Designer sag ich mal dass bei so nem Projekt wie diesem Rapid Prototyping nicht so wirklich geeignet ist, das liefe hinaus auf "Wir baun mal ne Oberfläche und schaun dann ob wir sie mit Leben füllen können" - das gefällt mir spontan nicht, das hab ich auch schon viel zu oft scheitern gesehen um da noch einen Cent drauf zu wetten.

Was die Bling-Bling-Oberflächen angeht: Wer die haben zu müssen glaubt, für die gibt es eine Lösung namens Windows(TM). Ich hätte spontan eher eine rein funktionale Oberfläche ohne Schnörkel und Spinnereien vorgeschlagen, ähnlich der alten Aquasuite. Das spart Zeit und konzentriert den Entwicklungsaufwand da wo er hingehört: in der Funktionalität.

Wenn sonst alles ohne Probleme in der VM geht, also die Namen der Sensoren immer richtig ausgelesen werden sprich nichts dagegen, zumal man das Gerät je nicht richtig kaputtflashen kann.

Zitat von »sebastian«

Wenn sonst alles ohne Probleme in der VM geht, also die Namen der Sensoren immer richtig ausgelesen werden sprich nichts dagegen, zumal man das Gerät je nicht richtig kaputtflashen kann.

War das eine Herausforderung?

@ Java UI:

Ich habe gerade bei einer größeren Evaluations-assistenssoftware eine Oberfläche mit Swing gebaut. (Pro Objekt werden bis zu 1200 Eingabgefelder gebnötigt die Teils dynamisch generiert werden müssen)
Und DAS mach ich bestimmt nie wieder. Katastrophale Fehlentscheidung, hat das Projekt bestimmt um 1/3 aufgebläht.

Sören

@Flashen in VM: Empfehle VirtualBox, damit geht es einwandfrei. Was bleibt mir auch anderes übrig???

@JavaUI: Das Grauen von Swing lern ich auch grade kennen. Ich kam von JSF und Qt her zur Swing-Entwicklung und dachte mir erst mal: Wozu zum Teufel brauch ich nen Toolkit, wenn ich doch alles selbt machen muss??? Allein die Frage: Wann brauche ich wo einen SwingWorker und wo ein invokeLater und wann nicht hat mich einiges an Nerven gekostet. Und finde mal ne brauchbare Lösung für eine GlassPane die MouseEvents blockiert...