mikrocontroller.net

Forum: PC-Programmierung Raspberry GUI - Qt, GTK & web-basierte Darstellung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Viktor B. (coldlogic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven B. (scummos)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Viktor B. (coldlogic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: LD_PRELOAD (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kennste LD_PRELOAD?

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Noch eine Meinung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Karl Käfer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Viktor B. (coldlogic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Viktor B. (coldlogic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Javascript-Lehrling (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Viktor B. (coldlogic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Viktor B. (coldlogic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
# nim c button.nim
import gintro/[gtk, glib, gobject, gio]

proc buttonClicked (button: Button) =
  button.label = utf8Strreverse(button.label, -1)

proc appActivate (app: Application) =
  let window = newApplicationWindow(app)
  window.title = "GNOME Button"
  window.defaultSize = (250, 50)
  let button = newButton("Click Me")
  window.add(button)
  button.connect("clicked",  buttonClicked)
  window.showAll

proc main =
  let app = newApplication("org.gtk.example")
  connect(app, "activate", appActivate)
  discard app.run

main()

Autor: Bauform B. (bauformb)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.