Hey Leute, Gerade versuche ich, meinen Raspberry per SPI mit einem Microcontroller zu verbinden, damit mir der Raspberry die vom MC gesammelten Infos anzeigen kann. Das läuft auch soweit alles in der Konsole. Nun wollte ich für das Ganze ein GUI bauen, der etwas schöner als Ncurses aussieht und ohne einen window manager (also im kiosk mode) läuft und bin dabei an drei Optionen gestoßen: -Qt: Die IDE ist einfach zu nutzen, ein Demonstrationsprototyp läuft schon aufm Desktop. Allerdings kann ich keine Anleitung finden, um das Programm statisch zu verlinken und gleichzeitig zu cross-kompilieren. Alle Tutorials zu letzterem fangen an mit "Installieren Sie Qt auf dem Raspberry", was ich ja mit statischer Verlinkung vermeiden will. Außerdem keine Info, wie es mit dem kiosk mode aussieht. Kann mich jemand in die richtige Richtung weisen? -GTK: Davon wurde ich schon ein paar Mal abgeschreckt, weil ein Fenster mit einem Knopf schon einige Seiten an Quellcode füllt. Ja, Kommentare sind mehr als 60% davon, aber trotzdem. Heute hab ich es geschafft, in ein paar Stunden ein Fenster mit einem Button zu erstellen. Yay. Die Frage hier wäre: Wie bekommt man das Fenster auf fullscreen? Kein window manager heißt, dass die in der Doku vorgesehene Funktion window_fullscreen nichts bewirkt (hab ich ausprobiert). Momentan ist die Displaygröße fest angegeben, das würde ich aber gern vermeiden. Wie bekommt man das Programm dazu, alle verfügbare Displayfläche zu nutzen? Und noch was: hätte jemand ein Tutorial fürs Designen mit GTK ohne Glade? Ich finde nur Tutorials mit Glade, was dann halt die Probleme aufwirft, die ich mit Qt habe, ohne die Vorteile des Qt zu bieten. -Web-basierte Darstellung: Da bin ich ein Noob vom Feinsten, sodass ich nicht mal ein gescheites Googeln hinbekomme - mir fehlen die Begrifflichkeiten. Hätte jemand ein Link zu einem Tutorial, wo erklärt wird, wie man Informationen aus der Peripherie des CPU in eine auf dem Raspberry gehostete Webseite einpflegt und diese anderen Geräten zugänglich macht? Wäre für jede Hilfe sehr dankbar! MfG, Coldlogic
Qt statisch linken ist ein bisschen was für Liebhaber, das kriegt man ohne weiteres nicht hin. Unter anderem deshalb, weil es die Lizenz für nicht-OSS effektiv verbietet (LGPL verlangt, dass man die shared libs austauschen kannst, was bei statischem Linken relativ schwer zu erreichen ist). Vermutlich u.a. deshalb gibt's auch keine pre-built binaries. Du kannst aber stattdessen einfach die shared arm-libs mit kopieren ...
:
Bearbeitet durch User
Hmmm, das mit dem statisch verlinken ist schade. Qt ist doch komplexer, als ich es mir gedacht hab. Dann wird es wohl doch eine der anderen Alternativen - GTK ist da weitaus leichter zu verstehen
Ich verstehe immer noch nicht ganz das Problem daran einfach die shared libraries zusammen mit der Anwendung zu kopieren, statt statisch zu linken. Macht unter Windows auch jeder so.
Sven B. schrieb: > Ich verstehe immer noch nicht ganz das Problem daran einfach die shared > libraries zusammen mit der Anwendung zu kopieren, statt statisch zu > linken. Macht unter Windows auch jeder so. Geht mir genauso. Dynamisch linken, und die Bibliotheken einfach mit apt-get install qt5-default nachinstallieren. Oder die benötigeten libQt5*.so mit dabei legen. Warum das statisch gelinkt sein soll, verstehe ich nicht.
Ich versteh schon, dass static linking für das deployment interessant ist, aber wie schon beschrieben ist das nicht so einfach umsetzbar. Dafür gibt's mit linuxdeployqt (https://github.com/probonopd/linuxdeployqt/) eine Alternative. Damit kannst du ein appimage "archiv" machen. Da stecken dann alle dependencies drinnen. 73
Viktor B. schrieb: > -Qt: Die IDE ist einfach zu nutzen, ein Demonstrationsprototyp läuft > schon aufm Desktop. Allerdings kann ich keine Anleitung finden, um das > Programm statisch zu verlinken und gleichzeitig zu cross-kompilieren. Warum muss es denn statisch gelinkt werden? > Alle Tutorials zu letzterem fangen an mit "Installieren Sie Qt auf dem > Raspberry", was ich ja mit statischer Verlinkung vermeiden will. Auch hier: Warum? > Außerdem keine Info, wie es mit dem kiosk mode aussieht. Kann mich > jemand in die richtige Richtung weisen? Wenn nur dein Programm laufen soll, brauchst du eigentlich gar keinen Window-Manager. Aber es reicht, wenn du dein Programm als Fullscreen-Anwendung schreibst, die man nicht beenden kann, sofern keine Tastatur verwendet wird. Welche Art von GUI willst du denn machen? Qt enthält im Prinzip zwei GUI-Frameworks, nämlich die klassischen Widgets und Qt Quick, das eher für Touch-Anwendungen, schön animitere UIs und ähnliches gedacht ist. Zu GTK und Web-UIs kann ich nicht mehr sagen als das, was du schon selber weißt. Sven B. schrieb: > Du kannst aber stattdessen einfach die shared arm-libs mit kopieren ... Allerdings muss man auch schauen, dass die nötigen Plug-ins auch vorhanden sind und gefunden werden. Inzwischen gibt's da ziemlich viele davon. LD_PRELOAD schrieb: > Kennste LD_PRELOAD? Also ich kenne es und hab keinerlei Idee, was das mit der ganzen Geschichte zu tun haben könnte. Meintest du vielleicht den LD_LIBRARY_PATH?
> Web-basierte Darstellung Für Chrome/Firefox brauchst du mindestens 2GB Hauptspeicher. Im Midori Browser funktionieren die Javascript-Frameworks nicht. > cross-kompilieren Möglicherweise kommst du im Summe am besten bei weg, wenn du dir für das SPI einen Hintergrundprozess schreibst, den die Oberfläche über TCP anspricht. Dann entwickelst du die Oberfläche auf einem grossen PC und kompilierst nur einmal auf dem Raspi.
Noch eine Meinung schrieb: >> Web-basierte Darstellung > > Für Chrome/Firefox brauchst du mindestens 2GB Hauptspeicher. Nein, das geht auch problemlos mit einem GB. Aber: wenn man die Daten mit einer Javascript-Library wie jqPlot, Flot, plotly.js oder jQWidgets plotten will, scheinen alle mir bekannten Javascript-Engines Memory Leaks zu haben. Das heißt, man muß seinen X-Client (halt kein Windowmanager, sondern gleich ein Webbrowser im Kiosk-Mode) bzw. der Einfachheit halber den X-Server in regelmäßigen Abständen (täglich?) neustarten, um den Speicher aufzuräumen. Dagegen hilft mehr Speicher übrigens auch nichts, es dauert dann nur länger bis der Speicher voll ist, und die Anwendung neu gestartet werden muß. Das kann mit Qt, wxWidgets oder GTK vermieden werden, mit JS habe ich (bislang) leider noch keinen Weg gefunden. Dafür hat JS jedoch den Vorteil, daß der Webserver natürlich im (lokalen) Netz verfügbar gemacht und die Daten dann auch mit Tablet, Handy oder Laptop angesehen werden können -- und hier sind dynamische JS-Libraries klar im Vorteil gegenüber generierten Grafiken... >> cross-kompilieren > > Möglicherweise kommst du im Summe am besten bei weg, wenn du dir für das > SPI einen Hintergrundprozess schreibst, den die Oberfläche über TCP > anspricht. Dann entwickelst du die Oberfläche auf einem grossen PC und > kompilierst nur einmal auf dem Raspi. Ja, unbedingt. Und das ist das mit dem statischen Linken auch kein Thema mehr, sowas machen eh nur Verrückte, die bei jedem Sicherheitsproblem der statisch gelinkten Library ein neues Binary erzeugen und deployen wollen. ;-)
Das Herunterladen und dynamisches Verlinken von Qt-Libs will ich vermeiten, weil es schon beim Installieren auf dem Desktop schon recht lange gedauert hat. Dann hat man noch Konstrukte wie Makefiles, Qmake, zwei Editoren etc. Ich könnte mich dadurch arbeiten, aber GTK ist da viel einfacher. Wegen GTK: Damit komme ich einigermaßen voran dank der Doku und den Tutorials von GNOME: https://developer.gnome.org/gtk-tutorial/stable Die Frage mit der Displayfläche ist allerdings immer noch aktuell, und eine neue ist hinzugekommen: wie nutzt man "gint g_timeout_add (guint32 interval, GtkFunction function, gpointer data);" dazu, um mehr als ein Widget zu updaten? In allen Tutorials gibt man das zu aktualisierende Widget mit gpointer weiter, ich bräuchte aber mindestens sechs. Vielleicht, wenn man das Fenster übergibt (weil es ja Parent für alles andere ist), aber wie sieht die Syntax aus? Ansonsten liegt ja alles außerhalb des Sichtbarkeitsbereichs der aufgerufenen Funktion..? Für jedes Widget einen timeot zu verwenden ist auch eine Verschwendung der Ressourcen.
Viktor B. schrieb: > Das Herunterladen und dynamisches Verlinken von Qt-Libs will ich > vermeiten, weil es schon beim Installieren auf dem Desktop schon recht > lange gedauert hat. Dann hat man noch Konstrukte wie Makefiles, Qmake, > zwei Editoren etc. Ich könnte mich dadurch arbeiten, aber GTK ist da > viel einfacher. Ich glaube dir ist da einiges unklar. Die Libs brauchst du bei quasi jedem Framework so oder so und du musst sie natürlich nicht mit dem SDK-Installer auf dem Zielsystem installieren. Du kannst sie zu deinem Executable dazupacken. Ich habe hier eine mittelgroße Qt-Windows-Anwendung der fast das komplette Qt-Zeug beigepackt ist, der Installer ist irgendwie 12 MB groß und braucht < 5s zum installieren der Anwendung. Ein Build-System (wie Makefiles) wirst du für eine GTK-Anwendung selbstverständlich auch brauchen.
:
Bearbeitet durch User
Nur 12 Mb? Oh, da hab ich mich um einundhalb Größenordnungen verschätzt. Egal, jetzt das zur Hälfte fertige Programm auf Qt umzustellen wäre zu viel Aufwand. Sven B. schrieb: > Ein Build-System (wie Makefiles) wirst du für eine GTK-Anwendung > selbstverständlich auch brauchen. Da kann ich tatsächlich nur mit #include und Linkerargumenten arbeiten, wie ich das schon früher bei CLI-Anwendungen gemacht hab. Funktioniert einwandfrei.
Viktor B. schrieb: > -Web-basierte Darstellung: Da bin ich ein Noob vom Feinsten Wenn Du von Null-Komma-Null anfängst, ist das echt ein Problem, da bist Du erstmal gut beschäftigt. Bis Du durchdrungen hast wie das alles zusammenhängt, NodeJS, npm, babel, webpack, vue, react, etc., bis Du Dein Build-Setup so hast wie Du willst, je nachdem wieviel Zeit Du täglich aufbringst, rechne besser mal in der Einheit Wochen, bis das alles flutscht. Das ist schon ein Brocken. Auf der Habenseite steht Dir ein ganzen Universum offen, mit wirklich tollen Libs und Technologien, da kommt halt nix anderes mehr ran. Dieser Zug ist komplett abgefahren und nicht mehr einholbar. Ich kenne Deine Anwendung nicht, aber ein HTTP-Server auf dem Raspi und sich mit einem Tablet/Handy oder auch PC per Browser auf so ein System zu verbinden und eine geleckte Web-Oberfläche zu haben, ist heißer shice.
Viktor B. schrieb: > Sven B. schrieb: >> Ein Build-System (wie Makefiles) wirst du für eine GTK-Anwendung >> selbstverständlich auch brauchen. > > Da kann ich tatsächlich nur mit #include und Linkerargumenten arbeiten, > wie ich das schon früher bei CLI-Anwendungen gemacht hab. Funktioniert > einwandfrei. Kann ich für die Qt-Anwendung auch, nervt halt auf Dauer ;P
Javascript-Lehrling schrieb: > Ich kenne Deine Anwendung nicht, aber ein HTTP-Server auf dem Raspi und > sich mit einem Tablet/Handy oder auch PC per Browser auf so ein System > zu verbinden und eine geleckte Web-Oberfläche zu haben, ist heißer > shice. Früher war ich mal ein Verfechter von hardwarenahen Lösungen. Ein Programm in C ist super, ein in Assembly noch besser, und eingebettet in VHDL wär so das Non-plus-ultra-Zeug. Natürlich um jeden kB vom Ram gekämpft. Aber wenn man sieht, was man mit einem Frontend in Python und einem Browser schaffen kann... Stark die dunkle Seite der Macht ist :)
Sven B. schrieb: > Kann ich für die Qt-Anwendung auch, nervt halt auf Dauer ;P In der Konsole dreimal auf "Pfeil-nach-oben" und einmal auf "Eingabe" drücken ist jetzt nicht soo anstrengend
Sven B. schrieb: >> Da kann ich tatsächlich nur mit #include und Linkerargumenten arbeiten, >> wie ich das schon früher bei CLI-Anwendungen gemacht hab. Funktioniert >> einwandfrei. > > Kann ich für die Qt-Anwendung auch, nervt halt auf Dauer ;P Bzw. man nimmt qmake oder cmake. Da schreibt man ein paar Variablen in ein File und fertig, schon kann man das problemlos auf der Konsole bauen. Mache ich immer so.
Viktor B. schrieb: > -GTK: Davon wurde ich schon ein paar Mal abgeschreckt, weil ein Fenster > mit einem Knopf schon einige Seiten an Quellcode füllt. Na ganz so schlimm es nicht:
1 | # nim c button.nim |
2 | import gintro/[gtk, glib, gobject, gio] |
3 | |
4 | proc buttonClicked (button: Button) = |
5 | button.label = utf8Strreverse(button.label, -1) |
6 | |
7 | proc appActivate (app: Application) = |
8 | let window = newApplicationWindow(app) |
9 | window.title = "GNOME Button" |
10 | window.defaultSize = (250, 50) |
11 | let button = newButton("Click Me")
|
12 | window.add(button) |
13 | button.connect("clicked", buttonClicked)
|
14 | window.showAll |
15 | |
16 | proc main = |
17 | let app = newApplication("org.gtk.example")
|
18 | connect(app, "activate", appActivate) |
19 | discard app.run |
20 | |
21 | main() |
Falls die maximale Fenstergröße noch ein Thema ist: hier funktioniert es, umständlich, aber dafür mit oder ohne Window-Manager gleich gut. Das angehängte Programm hat mal ein Mini-Fenster für die Task-Leiste angezeigt, ich hab's nur etwas umgebaut, deshalb sieht es etwas seltsam aus. Aber für die grobe Richtung, wo du weiter suchen kannst, hilft es vielleicht.
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.