Hallo zusammen, Ich habe mal eine Frage, und zwar schreibe ich häufiger mal kleine Programme, die meisten sind nur kleine Terminal/Konsolen Programme und daher brauche ich eigentlich keine GUI. Aber wenn ich doch eine brauche nehme ich meistens QT (schreibe hauptsächlich für Linux-Systeme und da ich nur kleinere Sachen mache stelle ich die unter GPL bereit -> keine Lizenzprobleme). Jedoch ist QT etwas aufwändig und auch wenn es QT auch für Windows gibt, so bedeutet das für Windows Nutzer immer mehr Arbeit. Ich habe aber immer wieder mal Programme gesehen, die man über den Browser steuern kann, ein Beispiel, dass mir gerade ein fällt ist Gutenprint für Linux. Daher meine Frage, wie wird so was gemacht? Vielleicht hat auch jemand einen Link oder kann mir sagen wie das abläuft, also wie das System funktioniert (HTML Dateien sicher für den Browser, aber wie verarbeitet das Programm die Antworten, also läuft da ein lokaler PHP Server?) Ich konnte nämlich leider bei Google nichts nützliches finden. MfG und schon mal Danke, Fer. T.
Fer T. schrieb: > also läuft da > ein lokaler PHP Server Es läuft ein Webserver... ob dieser die Seiten mit PHP Aufbereitet ist nochmal eine andere Geschichte. Im einfachstem Falle ein Socket welcher von einem kleinen HTTP Stack bedient wird und einfach nur HTML Seiten ausliefert und die Anfragen/Daten entgegen nimmt.
Ein weiteres Stichwort wäre CGI bzw. FastCGI. Dahinter kann sich alles Mögliche verbergen, z. B. Perl-Skripte oder auch ausführbare Programme (z. B. mit C zusammengestrickt). Es wird ein HTTP-Server benötigt, der die CGI-Skripte (-Programme) entsprechend aufruft. Programmierbeispiel in C habe ich gerade keines zur Hand, hatte aber vor Jahren so Einiges im Internet gefunden.
Fer T. schrieb: > schreibe hauptsächlich für Linux-Systeme und da > ich nur kleinere Sachen mache stelle ich die unter GPL bereit -> keine > Lizenzprobleme QT ist seit Ewigkeiten unter der LGPL. d.H. du brauchst noch nichtmal das, sondern kannst auch kostenfrei ohne Lizenzprobleme Kommerz-Software (dynamisch) gegen die QT linken, vorrausgesetzt du änderst die QT selber nicht. Aber bleib bei der GPL für deine Software, ist eh besser so ;)
Das wikisystem moinmoin-Wiki (http://www.moinmo.in) hat auch einen Modus mit einem standalone-Webserver für lokale Verwendung, es benutzt dabei Python (ist in Python geschrieben, und in der Standardbibiliothek ist bereits ein einfacher Webserver). Auch externe CGI-Module einbinden (die dann ja in C oder so sein könnten) ist glaube nicht so schwer in Python.
Danke, also heißt das ich muss einen Webserver laufen haben (localhost) der dann als Brück zwischen Browser und meinem Programm (als CGI) dient? Also z.B. den Boa mit rein packen (Boa Server, soll angeblich pattformunabhängig sein und ist nur 200 Kb groß, die anderen wie Cherokee sind mit 5Mb+ alle etwas groß). Edit: Bez. ich habe das hier gefunden: http://www.c-plusplus.de/forum/169861-full Wenn ich das richtig verstehe (hab gerade kaum Zeit, hab nur drüber geguckt) dann steht da wie man Sockets mit dem HTTP Protokoll verbindet, also das was Läubi gesagt hat, via Sockets Antworten annehmen und selber Antworten in Form von HTML ausgeben... Ok gucke mal weiter. MFG
So, wenn jemand auf dieses Thread stoßen sollte, hier ein Tipp, welcher einem echt helfen kann: http://sourceforge.net/projects/tinyhttpd/ Das ist ein kleiner Webserver in einer Source Datei (geschrieben in C), werde mich damit jetzt auch mal auseinander setzen :D
Was für Programme sind das denn? Kannst du sie vielleicht gleich in JavaScript schreiben? Das wäre am einfachsten.
Ja das wäre einfacher, aber kann man denn mit JavaScript die Ports des PCs ansprechen? Also RS232. Wenn das ginge könnte ich das machen.
Fer T. schrieb: > Also RS232. Grad da wäre ein Webserver recht unangenehm.. der verarbeitet einzelne HTTP-Requests, die mehr oder weniger voneinander unabhängig sind, und auch zu mehreren gleichzeitig auftreten können. Das mit nur einer RS232-Verbindung zu koppeln, die immer nur von einem Prozess gleichzeitig verwendet werden sollte, ist immer etwas "tricky". => am einfachsten mit einem Application-Server, der evtl. gleich den HTTPD-Teil mit enthält. Lässt sich z.B. auch mit der QT schreiben (brauchst ja den GUI-Teil davon nicht nehmen) such mal in der QT-Doku nach "simple HTTP Server", da gibts ein Beispiel.
Also was noch eine Möglichkeit wäre ist Java. Ein Webinterface macht Sinn bei Embedded-Anwendungen bzw. Serveranwendungen und MMIs für Netzwerkgeräte. Für eine Standalone-Anwendung ein Web-GUI zu machen ist eine echte Krücke. Angesichts deiner Frage, gehe ich nicht davon aus dass Du viel Erfahrung mit HTML PHP Perl / CGI hast. Aufgrund dessen könntest Du Dir die Einarbeitungszeit sparen und die Anwendung lieber in Java schreiben. Die Umstellung von c / c++ ist nicht wirklich eine Herausforderung. RS232 sollte über Java Communications API gehen. Wenn Du hardwarenahe Sachen machen willst dann wird natürlich mit Java wieder eng. Ich persönlich bin eher ein Fan davon für jedes Projekt die beste Umgebung (die mit den wenigsten Kompromissen) zu wählen als immer mit "meiner" Umgebung das gewünschte Ergebnis "hinzubiegen". CGI war schon immer eine Notlösung und wird eine Krücke bleiben (auch FastCGI), deshalb verwenden die meisten heute direkt Module die in den Webserver geladen werden (python,php,perl etc.). Abgesehen davon dürfte eine PHP/Python/Server-Umgebung Qt vom Umfang her deutlich sprengen. Damit bloatest Du deine Anwendung wirklich und Du schlägst Dich noch mit User-Firewallproblemen, Sicherheitslücken und den Userrechten rum. Also im Ernst, ich glaube der Qt-Overhead ist deutlich kleiner als das Webinterface. Und wenn Du Java nicht magst, die Java-Runtime nicht auf dem Zielsystem verfügbar ist und es Dir dann zu bloated wird oder aus Anforderungen heraus nicht verwenden kannst (Hardwarenah, Performance, Assembler etc.) würde ich bei Qt bleiben. Jetzt kommt noch dazu, dass wenn Du keine Ahnung von CSS,JavaScript und HTML hast Du sehr viel Lernzeit brauchen wirst um wirklich ansprechende und mit allen Browsern kompatiblen Interfaces zu machen. Und selbst wenn Du Dich an alle Standards hältst, wird Dir die nächste Browserversion garantiert einen Strich durch die Rechnung machen. Genau genommen machst Du dich wesentlich Plattformabhängiger als ohne, denn Du wirst für fast jede IE-Version ein eigenes CSS brauchen wenn Du die Maßstäbe wie an eine Qt-/Swing-GUI setzt. Es gibt IMHO genügend dieser Anwendungen (so Ende der Neunziger war es "in" sich in seine Anwendung ein Browser-Fenster zu embedden) die sich mit "Notnagel-HTML" und einem CGI-Call das leben selbst schwer machen und wir brauchen IMHO nicht noch mehr davon. Keine Standalone-Anwendungen mit Webinterface, das ist Quark (und natürlich nur eine subjektive Meinung). Vllt. wenn man im Webbereich mal den Standardisierungsgrad und vor allem auch die Bindewirkung eines Standards erreicht hat wie in anderen Bereichen. Webentwicklung ist heutzutage eine echte Krücke. Ich bin echt mal auf die neuen Win8-HTML5 Apps gespannt. Das wird echt Freude machen... ;)
Danke alle zusammen :D @ Ernst: Ich möchte das ja nicht auf einem Server laufen lassen, und nicht über "Websprachen" ansprechen, sondern der Webserver, welcher lokal läuft, soll ja einfach nur die GUI-Brücke darstellen, das Programm selber ist ja in C / C++ geschrieben. @ Mrx: Also HTML und CSS sind keine Probleme, ich würde mal behaupten, dass ich mich da ganz gut auskenne, muss zwar bei einigen Sachen in der Referenz nach gucken, aber ist an sich kein Problem. Auch PHP ist kein Problem, solange es um Standard-Sachen geht. Ich wollte das über den Browser machen, weil ich dachte so könnte ich schneller eine GUI erstellen (und einfacher) als wenn ich es per QT programmiere, vor allem weil ich beim Browser ja nur ein Layout machen muss und dann einfach die C Dateien als CGI einbinde (Umgebungsvariable als Input und gut ist). So gesehen war mein Beweggrund der, dass ich für all die kleinen Programme nicht unbedingt immer die GUI in QT schreiben wollte/will weil das sehr Zeitaufwendig ist, bez. aufwendiger als eine einfache HTML Seite. MfG Fer
Fer T. schrieb: > Ich möchte das ja nicht auf einem Server laufen lassen, und nicht über > "Websprachen" ansprechen, Ob der Webserver lokal oder sonstwo läuft, ist dem erstmal wurscht. Und dir eigentlich auch, die Programmierung bleibt die gleiche. und um die "Websprachen" HTTP, HTML, CSS kommst du nicht herum, wenn du einen Web-Browser zum Anzeigen verwenden willst. Der kann nämlich nix anderes. > sondern der Webserver, welcher lokal läuft, soll ja einfach nur die GUI- > Brücke darstellen, das Programm selber ist > ja in C / C++ geschrieben. d.H. du brauchst jetzt drei Programme wo vorher eins nötig war. 1) Einmal dein C / C++ Programm, mit der RS232-Schnittstelle. 2) Einmal den Webserver + CGIs/PHP-Scripte/Sonstwas, die sich per IPC mit deinem Programm verbinden. 3) Einmal den Webbrowser, der sich mit HTTP an den Webserver verbindet. Wenigstens 1 und 2 kann man zusammenfassen, wenn man den HTTP-Server direkt in dein Programm integriert. Das war mein Vorschlag mit der QT. QT einfach weil du sie schon kennst, und RS232, HTTP sowie Multithreading damit unproblematisch sind. 3 kannst du auch integrieren, QT hat nen WebBrowser-Widget, dann lässt sich auch der Netzwerk-Teil dazwischen einsparen ;)
Εrnst B✶ schrieb: > und um die "Websprachen" HTTP, HTML, CSS kommst du nicht herum, wenn du > einen Web-Browser zum Anzeigen verwenden willst. Der kann nämlich nix > anderes. Das ist mir ja auch bewusst, ich meinte, das ich Sprachen wie PHP jetzt nicht extra benutzten will (was übrigens ein installiertes PHP benötigt, das wäre ja wieder mehr Ballast). > d.H. du brauchst jetzt drei Programme wo vorher eins nötig war. > 1) Einmal dein C / C++ Programm, mit der RS232-Schnittstelle. > 2) Einmal den Webserver + CGIs/PHP-Scripte/Sonstwas, die sich per IPC > mit deinem Programm verbinden. > 3) Einmal den Webbrowser, der sich mit HTTP an den Webserver verbindet. > > Wenigstens 1 und 2 kann man zusammenfassen, wenn man den HTTP-Server > direkt in dein Programm integriert. Das war mein Vorschlag mit der QT. > QT einfach weil du sie schon kennst, und RS232, HTTP sowie > Multithreading damit unproblematisch sind. 1 und 2 würde ich ja dann auch zusammenfügen, aber 3 würde ich extra lassen, sollte ja überall drauf sein. Mir ging es ja hauptsächlich darum Arbeit zu sparen, da ich mich mit QT nicht so gut auskenne wie mit HTML, CSS (und "normalen" C/C++). Ich will ja keine High-End Programme mit der GUI schreiben, sonder nur für kleinere benutzen, da wo sich QT vom Zeitaufwand nicht lohnt. [1]Wenn ich QT benutze, dann würde ich ja auch nicht diese Web-GUI benutzen, sonder richtig mit QT eine schreiben. Und nebenbei brauche ich dann keine extra Bibiliotheken (QT) für diese "Mini-Programme", da ich nur den Server integrieren muss (einzelnt compiliert ist der als Binär Datei dann 12 Kb groß.). > > 3 kannst du auch integrieren, QT hat nen WebBrowser-Widget, dann lässt > sich auch der Netzwerk-Teil dazwischen einsparen ;) siehe [1] Trotzdem danke. Evtl. brauch ich das ja auch nicht immer so zu machen, dazu müsste ich einfach nur schneller QT GUIs schreiben ;-) MfG
Fer T. schrieb: > Danke alle zusammen :D > @ Mrx: > > Also HTML und CSS sind keine Probleme, ich würde mal behaupten, dass ich > ... > Okay, dann fällt der Aufwand ja schonmal weg. > Ich wollte das über den Browser machen, weil ich dachte so könnte ich > schneller eine GUI erstellen (und einfacher) als wenn ich es per QT > programmiere, vor allem weil ich beim Browser ja nur ein Layout machen > muss und dann einfach die C Dateien als CGI einbinde (Umgebungsvariable > als Input und gut ist). > So gesehen war mein Beweggrund der, dass ich für all die kleinen > Programme nicht unbedingt immer die GUI in QT schreiben wollte/will weil > das sehr Zeitaufwendig ist, bez. aufwendiger als eine einfache HTML > Seite. Naja, musst letzten Endes Du entscheiden. Aber wenn Du es halbwegs ordentlich machen willst, musst Du vermutlich wesentlich mehr Zeit investieren. Ich schätze den reinen Erstellungsaufwand der GUI als ähnlich hoch ein wenn ein Entwickler beides gleich gut beherrscht, desto komplexer die GUI desto höher wird der Aufwand für das Web-GUI. Viele Dinge sind schlichtweg garnicht realisierbar. Solltest Du des Weiteren z.B. PHP verwenden, musst Du Dich auch noch mit der Webserver- und PHP-Konfiguration ausseinandersetzen. Sonst installierst Du dem Enduser einen Webserver der auch noch im Netz lauscht und Anfragen beantwortet die Du überhaupt nicht beantworten willst. Jetzt stell Dir vor, das macht jeder Entwickler so. Dann hat jeder User nacher 10 Webserver auf dem Rechner die vermutlich noch alle auf dem Standardport lauschen wollen und nichts funktioniert mehr. Ich halte das einfach für keine gute Praxis. Und jeden einzelnen kannst Du dann anfangen separat zu patchen, denn PHP-Security-Fixes gibt es alle paar Tage. Und das alles für ein "kleines Tool"? Ich will Dich nicht daran hindern deine Erfahrungen zu machen, aber bedenke was Du dir und dem User wirklich damit aufbürdest.
> Ich wollte das über den Browser machen, weil ich dachte so könnte > ich schneller eine GUI erstellen (und einfacher) Ich habs einmal probiert und das Ergebnis war ernüchternd. Nicht nur hab ich 10 mal solange gebraucht, bis die Formulare und alles sonstige so einigermassen ausgesehen haben, wie ich wollte. Auch die Interaktion von einzelnen Controls die sich gegenseitig beeinflussen war einfach nur ein Horror. Da bist du mit jedem Resource Designer um Längen schneller. Zumindest ist es mir so ergangen. Wenn man dann ein wenig Übung hat, ist so ein Resource Designer (oder eben mit dem Resource Studio von DevStudio, bin ein MFC Mensch) schneller hochgefahren als du Papp sagen kannst. Ganz zu scheigen von den vielen Dingen die dann auch noch schief gehen können, wenn mehrere Programme wie Browser, Server etc. zusammenarbeiten müssen. Wir haben in der Firma gerade ein neues Zeiterfassungssystem gekriegt :-) basierend auf einer HTML Oberfläche. Gut. Man kann von jedem Arbeitsplatz auf das Kästchen neben der Tür zugreifen, aber ansonsten würd ich das Teil liebend gerne beim Fenster rauswerfen. Lahm bis zum geht nicht mehr, die Oberfläche ist hauptsächlich bunt, scheusliche Bedienung.
Ok, Ich muss da mal gucken... Auf jeden fall sehe ich es auch ein, dass es ziemlich bekloppt wäre wenn es so kommen würde wie mrx gesagt hat (wenn jeder es so machen würde...)... Naja wie gesagt gucke mal ob es so klappt wie gedacht, sonst, bez. so oder so, muss ich mal näher mit QT auseinander setzten, evtl. schaffe ich dann GUIs auch damit schneller... Nicht hauen: Zu meiner Windows Zeit fand ich aus dem Grund VB sehr gut, was mir jetzt auch in diesen Situationen verlockend vor kommt, auch wenn es vom sich aus recht ?!*'+ ist... Bin dann mal QT Guids lesen... MFG
Fer T. schrieb: > Nicht hauen: > Zu meiner Windows Zeit fand ich aus dem Grund VB sehr gut, was mir jetzt > auch in diesen Situationen verlockend vor kommt, auch wenn es vom sich > aus recht ?!*'+ ist... Warum soll man dich dafür hauen? VB war immer schon dafür bekannt, dass man damit oberflächenlastige Appliktionen schnell und einfach zusammenklopfen kann. Heute hat C# diesen Part übernommen oder zumindest möchte MS das wohl so haben. Und das muss man neidlos anerkennen: Es geht wirklich verdammt flott und komfortabel, da eine GUI zusammenzustricken. Wenn man nicht immer dieses Riesen-.Net Zeugs mitschleppen müsste :-)
Ja, NET ist nicht gerade "schlank"... hatte damals ein Spiel geschrieben, da brauchte jeder Nutzer leider die NET Bibliothek... wie viel sind das? 100MB? 200MB? Naja hatte mich auch mal mit KBasic beschäftigt (wie VB), plattformunabhänig -> Kann auch für Mac und Windows kompiliert werden, kostete glaube ich 20€ Linux war kostenlos... War ganz nett, da jeder Programm in C++ übersetzt wurde... dafür wurden auch immer "nur" 6,8 MB mitgeschleppt. Aber ist auch nicht das wahre. Ne ich hatte das Prinzip halt öfters gesehen (früher die Software der T-Com, jetzt in letzter Zeit der Gutenprint Treiber...)... Hab mich jetzt dazu entschieden erst mal wenn es passt doch lieber in QT zu investieren (Zeit), da es doch Vorteile hat. MFG
Hallo, ich denke Qt ist die richtige Wahl. Wenn du was neues und hippes machen willst, kannst du dir auch node.js ansehen. Da kannst du in javascript programmieren, eine GUI machen und auf serielle Ports zugreifen: http://nodejs.org/ https://github.com/creationix/topcube https://github.com/voodootikigod/node-serialport
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.