Beágyazott Linux app-hoz milyen GUI-t?

Grafika: GUI, OpenGL

Sziasztok!
Raspberry Pi 3, vagy hasonló képességű HW-re Linux alá kéne fejleszteni egy egyszerű kis alkalmazást, aminek lenne egy nem túl bonyolult GUI-ja is. Az egészet ti miben csinálnátok? Bármilyen divatos programnyelv, vagy framework használható, csak fusson beágyazott Linux-on is.
Gyors keresés után azt találtam, hogy a python-tkinter a legnépszerűbb, és sokan használnak PyQt-t is. Ti melyiket választanátok? Illetve ismertek vajon ezeknél jobb és/vagy egyszerűbb platformot?

Köszi a tippeket!

  • 2197 megtekintés

Csak 4 éve EOL

Cserébe minden sajátossága ismert, dokumentált, ha máshol nem, fórumokon és bug ticketekben. Az EOL™ pedig csak a Red Hat (IBM) által túszul ejtett FreeDesktop részéről igaz, egyes disztrók maintainerei továbbra is karbantartják, akiknek a patcheit át lehet venni szükség esetén.

mi baj lehet

Nem kell párévente újravásárolni alatta a hardvert, meg havonta foltozgatni a GUI implementációt az API-törések miatt. Ez valakiknek, akik jól élnek a Linux-világ felforgatásából, biztos baj™, de aki a keveset változó, stabil, kiszámítható rendszereket preferálja, annak éppenhogy előny.

Debian bookwormben már nincs is benne. Végülis lefordíthatod az adott rendszerre és szállíthatod az appoddal együtt akár statikusan is, vadászhatod a patcheket hozzá, de pár év múlva majd a libjeit, illetve az XWaylandet is szállítanod kell. Lehet, hogy megéri, de azért én átgondolnám mit is lehet vele nyerni.

>pár év múlva majd a libjeit, illetve az XWaylendet is szállítanod kell.

Mernék fogadni rá, hogy össze fogják rakni a Wayland portot is. Lehet, hogy már van is.

Szerk.: valami van, nem néztem meg mi ez: https://github.com/Distrotech/gtk2/blob/master/gdk/wayland/gdkdisplay-w…

( asch v | 2024. 03. 14., cs – 15:41 )

RPI3 egy atomerőmű azokhoz képest, ahová valóban beágyazottra optimalizált technológia kell. Én bevallom csináltam egy ilyesmit mostanában, és konkrétan web technológiával csináltam meg, ami alá egy fullscreen kiosk módú böngészőt indít a rendszer. Azt kell ügyesen megoldani, hogy mire a böngi elindul, addigra a port is elérhető legyen, ezt úgy csináltam okosan meg, hogy az a program indítja a böngészőt, amiben a beágyazott webszerver is van, és akkor indítja el amikor már nyitva van a port.

1920X1080 felbontású touch screent tettem rá, OOB működött minden.

Nem mondom, hogy így _kell_ megcsinálni, de a RPI3 bőven elég erős ahhoz, hogy egyszerű GUI esetén bőven natív érzetű legyen a sebessége.

Van egy saját minimalista libem, azzal készült: https://github.com/qgears/quickjs

Javába beágyazott Jetty szerveren fut, a böngésző websocketen kapcsolódik a szerverhez, és utána Javában úgy lehet a GUI elemeit kezelni, mint egy bármilyen GUI keretrendszerben, de a HTML-t kézzel írod template-be, és bármikor írhatsz kézzel JS-t is szintén template-be. Villámgyors, localhoston vagy helyi hálón nem látszik rajta, hogy böngészős technika. Egy rebuild és újraindítás 1-2 másodperc, úgyhogy kényelmes használni.

"Kicsit" pilótavizsgás, mert saját keretrendszer és nem dokumentáltam túl, játszani csináltam eredetileg, aztán mégis lett benne 1-2 kicsit komolyabb dolog is írva a játszósprojektjeimen kívül is. Az első verzió bénaságain okulva elkezdtem az újat, ami még jobb, de még nem biztos, hogy minden működik benne: https://github.com/qgears/quickjs/tree/feature/nextgen

Bármilyen keretrendszerben lehet kiosk alkalmazást írni persze, localhoston azért legtöbb dolog nem lassú. Szerintem akkor érdemes így nekiállni, ha ismersz valami webes technológiát, vagy amúgy is hasznosnak találod ebbe az irányba fejleszteni magad. Egyébként standalone alkalmazást írnék én is.

A vicc az, hogy melóban több alkalommal is volt olyan, hogy kiosk módú webalkalmazást álmodtak meg először a projekt tervezői, és rengeteget kísérletezve többször egymás után az lett a konklúzió, hogy a technika nem érett meg rá. Mostanra viszont (jópár éve) szerintem megérett, simán elketyeg egy böngészős beágyazott alkalmazás napokig hiba és leak nélkül.

Én egyébként abszolút JavaScript hater voltam, most sem szeretem, azért írom meg Javában a logikát. De ha szereted a JavaScriptet, vagy a TypeScriptet, akkor kliens technológiával is lehet alkalmazást írni. Ennek előnye, hogy a szervert elég minimálisan terhelni csak azzal ami rá tartozik. Az Angular2-t kipróbáltam egyszer, egész szimpatikus volt, de azért nem olyan jó mint a Java.

Általában a böngészős megoldásoknak előnye, hogy a munkaverziókat könnyű megosztani a megrendelővel például, csak felpattintod egy szerverre és már látja is hol tart a fejlesztés. Beágyazott esetben persze kell hozzá valami szimulátor a környezethez, de ezt többnyire úgyis meg kell csinálni.

( Raynes v | 2024. 03. 14., cs – 17:21 )

C és Gtk4. Ámbár ha nagyon egyszerű program, pl. egy pár soros shell vagy Python script, akkor a yad, zenity, KDialog, Gtkdialog, PyDialog is használható a PyQt helyett. Ha elég a TUI is GUI helyett, akkor ncurses, notcurses, dialog, tvision, stb. is alternatíva. Illetve ott van még a WebUI is, ha nem zavar egy kis extra overhead, hogy kell webszerver is alá, akkor az se nehéz bármilyen nyelv + cgi kombóval.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( bzt | 2024. 03. 14., cs – 17:29 )

Az egészet ti miben csinálnátok?

Ez így túl tág meghatározás. Mik a főbb szempontok? Én rengetegféleképp megoldottam már.

Pl.
a) kiosk módú böngésző, nginx + sima mezei php alkalmazás - itt az volt az elvárás, hogy ugyanaz fusson rajta, mint az interaneten lévő weblap, hogy céges átlagfejlesztők is hozzá tudjanak nyúlni
b) függőségmentes, egyetlen init process, natív fbdev eléréssel - ennél meg az volt az igény, hogy minnél több erőforrást sajtoljon ki azáltal, hogy egyetlen processz fut csak, semmi más. Nem használ ui libet, saját komponenseket írtam hozzá.

A feltételek pontos ismerete nélkül én azt mondanám egyébként, libSDL. Ez natívan (X11 és Wayland nélkül) képes használni a VC-t (2D, 3D gyorsítás is támogatott), nagyon kiforrott és bőven dokumentált, és szinte nem is létezik olyan programozási nyelv, ami alól ne lehetne használni. Az meg már csak hab a tortán, hogy tele van a net tutorialakkol hozzá, ami csak kell.

Az egyetlen hátulütője és egyben legnagyobb előnye, hogy magában csak egy framebuffert ad (kb. mint a direkt fbdev elérés), szóval ha csili-vili kulcsrakész widgeteket akarsz, akkor azokat vagy megírod, vagy kell egy magas szintű widget könyvtár (pl. nuklear vagy raygui). Itt megint az a kérdés, hogy mit is értesz "egyszerű kis alkalmazás" alatt, mert ha tényleg csak pár gomb kell, akkor azt kb. 5 perc SDL-ben megcsinálni, de ha ki-be nyitogatható és szkrollozható könyvtárfát akarsz megjeleníteni, akkor érdemes másfele keresgetni.

Ha nem riadsz el a C++-tól és az egyszerűség meg a könnyen karbantarthatóság a cél, akkor mindenképp a Circle-t javaslom. Ez egy operációs rendszer nélküli alacsony szintű könyvtár, ami annyit tud, hogy egy tetszőleges applikációt futtat bármilyen Raspberry-n. Ezzel egyszerre lehet magas szintű (C++) UI libeket használni, meg kisajtolni a maximális performanciát (a widgeteket az uGUI lib adja, ami az addons mappában található).

Úgy van, ez sem derült ki egyértelműen, hogy magának írja, saját cégének házon belülre, vagy terméknek szánja megrendelésre, és ha ez a legutóbbi, akkor milyen feltételekkel.

A jelenlegi ismeretek alapján szerintem még mindig a libSDL a legjobb:
- Qt-val, GTK-val stb. ellentétben nem kell hozzá X11,
- Python alatt hivatalosan is támogatott és
- zlib licenszű (proprietary kódba is beilleszthető).

Az egyetlen kérdés csupán csak az, hogy az "egyszerű kis alkalmazás, aminek lenne egy nem túl bonyolult GUI-ja" alatt mire gondolt a költő, mert az SDL önmagában nem ad összetett widgeteket.

Technikailag igen, jogilag nem. Ha jól értem a Qt licenszfeltételeit, akkor (ahogy azt korábban bocs is jelezte) az már a fizetős embedded kategória. Még ha Te úgy is gondolod, hogy nem az, simán előfordulhat, hogy a Qt jogi osztálya egyszer csak úgy dönt, de bizony az, és kaphatsz egy jó kis pert a nyakadba. Azt, hogy megsértetted-e a licenszük feltételeit önhatalmúlag ők döntik el, nem Te.

SDL esetén nincs ilyen veszély, az felhasználástól függetlenül mindig zlib licenszű.

Szerintem nem

Mint arra külön felhívtam a figyelmedet, nem számít, hogy Te mit gondolsz.

A végső szó az övék, mert az ő IP-jük; ha kijelentik bíróság előtt, hogy megszegted a licenszfeltételeiket és olyan tevékenységre használtad, amihez vásárolnod kellett volna külön commercial licenszt, akkor megszívtad. Nem fog számítani, hogy ez valójában igaz-e, és nem fogsz tudni versenyezni sem a jogi osztályukkal, sem a sztárügyvédeikkel.

A Qt oldalán, kimondottan az RPi fejlesztési példához van odaírva az a nagybetűs figyelmeztetés, hogy  "Qt for Device Creation requires a license".

Szóval RPi fejlesztéshez szinte 100%, hogy Embedded Licensz kell.

https://doc.qt.io/Boot2Qt/b2qt-qsg-raspberry.html

( r3flow | 2024. 03. 14., cs – 17:34 )

Szerkesztve: 2024. 03. 14., cs – 21:12

Qt-n és a teljes képernyős böngészőn kívül lehet akár Flutter is.

Ha "gyors" boot is kell akkor praktikusan ablakkezelő nélkül. A teljes képernyős böngészős megoldást össze lehet rakni Qt-ben is webengine-el, a Qt fordítható EGLFS backenddel akkor nem kell ablakkezelő. Flutter szintén megoldható ablakkezelő nélkül is.

A Qt körül állandan FUD van, de a "community edition" bőven jó, ha nem akarsz szupportot (mert megoldod a problémákat magad: ott a forráskód), és az LGPL licenszű komponensek elegendőek. Lásd: https://www.qt.io/licensing

Az LGPL ugye azt követeli meg, hogy a proprietary cuccot dinamikusan linkeld hozzá, ne statikusan. És ha a komponenst módosítod, akkor a fixedet tedd közzé. És még a credits-be be kell írni, hogy milyen libet használtál a megvalósításhoz. Tehát teljesen vállalható egy beágyazott rendszer esetén is. (Ez nem minősül jogi tanácsnak :-) )

Viszont közben a cég aki csinálja folyamatosan csinálja a FUD-ot, hogy fizessenek érte a userek. Ezért félnek tőle sokan. Én is voltam olyan projektben, ahol emiatt ki lett zárva egyből.

Szerintem ez a gyakorlat végtelenül káros a FOSS megítélésére nézve, hogy ilyen FUD-ot csináltak köré. Ha LGPL, akkor abban nem lehet korlátozni, hogy mire telepíted. Az lehet, hogy a framebuffer device GPL licenszű, de ha megvalósítod magadnak az illesztőt, akkor a többi LGPL libet használhatod.

Ezt kellene, hogy jelentse az LGPL, erről szól, annó elolvastam a köré írt magyarázatot, hogy mire gondoltak amikor tervezték.

A Qt meg csinál köré egy FUD-ot, és az ember nem tudhajta biztosan, hogy akkor mi van, mit lehet betartatni az LGPL-ből és be tudja-e húzni a csőbe a Qt a használókat? A legtöbben simán nem mernek termékfejlesztésbe fogni vele. Még ha lenne is pénz rá, akkor sem lehet tudni, hogy nem emelnek-e hirtelen árat, vagy mittudomén? Aki az LGPL köré FUD felhőt fúj, attól minden kitellik.

Amikor pár éve a Qt elkezdett bohóckodni a licenc változtatással meg a telepítő megszüntetésével azóta nem kötvetem a Qt-t, akkor elkezdtem migrálni Flutterre. Azóta RPI-n (vagyis CM4-en) már Yocto+Flutterre migráltam. Azóta mindenhez azt használom, nem csak desktopon de ESP32-be is Flutter (web) UI-t pakolok, minden egyes fájlt eleve gzipelve littlefs-en, így mindössze 1.5MB a komplett UI. WiFi-n már elsőre is tűrhető idő alatt betöltődik azt követően meg már jön browser cache-ből zéró idő alatt, akár "offline" is.

( Nyosigomboc v | 2024. 03. 14., cs – 21:28 )

Nekem tobb projectem volt mar Python3+PyQt5-tel. Nagyon kenyelmesen hasznalhato. Mondjuk a vegen mindegyik PC-n futott, de a nagy resze valamilyen kutyut vezerelt, ennyiben volt koze a beagyazott reszhez is.

Egyszer egy tk-s projectbe is bele kellett nyulnom (LinuxCNC egyik GUIja), na az messze van a kenyelmestol. Mukodni mondjuk mukodott.

A strange game. The only winning move is not to play. How about a nice game of chess?

( YleGreg | 2024. 03. 14., cs – 22:18 )

Attol fugg, hogy milyen bonyolultsagu program kell, milyen vezerlok kellenek bele.

Hazi keszitesu tanusitvany generalas szog egyszeru menutendszerrel meg nehany kiegeszito funkcioval (dokumentacio generalas) sima bash es whiptail, nem volt ok bonyolitani.

VPN csatlakozas / AD user login debbuggolasra, ami tobb fele input alapjan tobb gepen tobb log filebol heurisztikazza ossze az infot, Python es tkinter. Ez utobbinak most mar ugy allnek neki, hogy egy AI -val legeneraltatnam a UI elemeket, es csak beleirnam a command fuggvenyekbe a lenyegi kodot.

( eff | 2024. 03. 15., p – 00:11 )

Ne haragudj meg, de a kerdesed nagyjabol ehhez hasonlo: "Szeretnek laptopot venni, mit ajanlotok? melyik a legjobb/legkonnyebben kezelheto?"

 

Milyen HW-en fut, mit kell kiszolgalnia, milyen teljesitmennyel, milyen surun fog valtozni, mennyire bonyolult a mogttes dolog? Ezek mind befolyasolo tenyezok. ha napi/heti szinten modositgatni kell, akkor nem biztos, hogy valami beegetett dologban csinalnam. Csereben ha alig valtozik, akkor valami faek egyszeerusegu dologban csinalnam, nem kell class es tarsai. ugyanigy ha kis hw-en nagy forgalmat general, akkor mast erdemes alatenni, mint ha nagy hw-en kis forgalmat. stb. stb.

laptop analogi: nem mindegy, hogy mekkora, meddig birja, van-e GPU, milyen periferiak vannak benne, stb. ha uzleti hurcolos gep kell, akkor valoszinuleg nem 17"-os 5kg-os gamer laptopot kell venni, bar lesz, aki azt fog :)

+1 a 17" 5kg -os hurcolós gépre, az előző laposom ilyen volt, csak 19" collos, imádtam hurcolni, mert így egyben a napi edzés is megvolt egy füst alatt. Bírom akik miután kinyafogták magukat, hogy két kilós a laptop az asztalon, lemennek az edzőterembe súlyok emelésével elb4szni az idejüket. :-)

Nekem sincs bajom a batár gaming/workstation laptopokkal, nem érdekel a súlya sem. Az is igaz, hogy nem hurcolom sokat, de ha hurcolnám is, akkor se érdekelne. Csak az, hogy ha nehéz, akkor teljesítményben, kijelzőben, billentyűzetben kompenzálja. Megértem azt is, akinek csak alap igényei vannak, levelezés, alap szövegszerkesztést tol csak le a laptopján, hogy az nem akar ilyen sok kilós tankokat hurcibálni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Raspberry Pi3 szintű HW. Azaz legalább 64-bites, több magos CPU + legföljebb 1GB RAM. Lehet, hogy végül nem RPi lesz, hanem valami hasonló erejű SOM.
A kevés memória miatt kicsit félek a böngésző alapú GUI-któl, de ha valaki azt mondaná, hogy fog az menni, akkor arrafelé mennék, mert az tűnik a leggyorsabbnak.

Simán belefér 1GB-ba. A "szerver" amit írtam, az bekorlátozható 64MB-ba, és vannak sokkal karcsúbb technológiák is. Egy Firefox 1 tabbal az about:memory szerint nálam most 292MB. Persze szemmel látható foglalás ez az 1GB-ból, de azért van a RAM, hogy használjuk!

De nem akarlak rábeszélni a webre, nem akarom, hogy az én lelkemen száradjon: ipari környezetbe én is vonakodva merném betenni. Ha az kell, hogy 0-24-ben működjön úgy, hogy hetekig, esetleg évekig újra se indítják a gépet, akkor nem böngészővel csinálnám. Én hobbiprojektet csináltam vele - modellvonat vezérlőt -, arra tökéletes.

Régen (10+ éve) teszteltünk olyat, hogy a tervezett webes technológiával indítottunk egy oldalt és napokig próbáltuk futtatni és mindenféle hibákkal leállt a legtöbször 1 napon belül. Mostanában nem futtattam újra ilyen teszteket, mert nem volt szükség rá, a hobbis oldal egyszer sem hibázott eddig. Hobbira teljesen jó, ipari környezetbe mérni kellene előbb, de zsigerből inkább kerülném.

Hogy ne indulna el? Ha van a boardodhoz Linux disztró, akkor pillanatok alatt ki lehet próbálni.

Két megfontolandó dolog:

 * A userek képesek furcsán működni. Volt olyan programom, amit hónapokig nem indítottak újra, ott volt a műhelyben a gép és sosem nem állították le. Pedig nem használták minden nap (logok alapján). Nem erre terveztem a programot és egy listener leak miatt el is halálozott. Azóta tettem bele egy figyelmeztetőt, ami naponta kéri, hogy indítsák újra: de továbbra se indítják újra :-)

 * Egy dolog, hogy valami általában megbízhatóan működik és egy másik ezt kimérni és bizonyítani. Neked kell tudni, hogy mi az igény.

Úgy vagyok vele, hogy karcsúbb technológia választását még sosem bántam meg. Ha valami miatt crash-el a UI, akkor mennél kisebb az állat, annál több esélyed van megtalálni, hogy mi az oka.

A natív alkalmazások GUI-ját is át lehet lőni netre, például VNC klienst lehet a böngésző ablakba is tenni, vagy ilyesmit. Kérdés az is, hogy csak a fejlesztés során segít, vagy élesben is szükség lesz-e rá? Ha csak a fejlesztéshez kell, akkor bármilyen összetákolt technika megteszi. Ha élesben is kell, akkor még mindig meg lehet fontolni, hogy kétszer is lefejlesztjük a UI-t egyszer beágyazottan, egyszer pedig webre: kis pluszmunka, de amikor nem kell böngészőt debuggolni, hogy miért törik el hetente, akkor mégis megéri.

> A natív alkalmazások GUI-ját is át lehet lőni netre, például VNC klienst lehet a böngésző ablakba is tenni, v

 

Hat vagy a nativ gui is kliens/szerver alapu. Van erre millio pelda. Talan a legismerted a torrent kliensek. De rendszeresen bele lehet futni.

Viszont akkor a guit 2x kell megcsinalni ...

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A böngészőnek nem kell a Pi-on futnia. Elég egy soványabb webszervert futtatnia, pl. lighttpd, thttpd, ezek nem esznek sokat, nem muszáj bloatabb Apache-vel rámenni. A böngésző az a kliensen fut, ami csatlakozik a Pi-hoz.

A WebUI akkor jó ötlet, ha van valami webes tudásod máris, vagy valami nagyon platformfüggetlen megoldás kell.p

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ezeknek egy részére válaszolt már, de tényleg hagyott ki fontos dolgokat. Pl. a legfontosabb, hogy milyen nyelvet fog használni, mert az erősen szűkítheti a kört. A másik lényeges, hogy milyen bonyolult, pl. hány kódsoros lesz a vezérlő, és milyen kompexitású GUI kell hozzá, hány menü, kattintható elem, gomb, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A nyelv az majdnem mindegy. Typescript-ben még egyikünk sem kódolt korábban, de most épp a REACT-tal kísérletezgetünk. Python jobb lenne, de a GUI összerakással több időt lehet elcseszni, mint a typescript megtanulásával. .)
A GUI nem lesz túl bonyolult, de fontos, hogy szép legyen, és touch-os. Azaz pl. tkinter, jawa+swing kilőve.

( hyperborg | 2024. 03. 15., p – 09:03 )

A házvezérlésemet több PI szolgálja ki, rajta full Qt házvezérlő klienssel. 
Mi a feladat?

( Botond | 2024. 03. 17., v – 12:25 )

PyQt biztosan elmegy a vason, tehát egyelőre az a nyerő.
Szóba került még a JetBrains compose. Esetleg azzal van valiknek tapasztalata? Raspberry 3-on jól fut?

( zsolt | 2024. 03. 18., h – 15:43 )

U++

Ez egy teljes platform-független C++ IDE és osztálykönyvtár.

Nagyon egyszerű vele GUI alkalmazásokat csinálni.

Modern C++ elvek alapján tudsz vele dolgozni, nem az oldschool new operátoros memória-managementen alapul.

Licenc: BSD, tehát írhatsz vele zárt kódú programot és nem kell licencdíjat fizetni.

( martonmiklos v | 2024. 03. 18., h – 16:48 )

Ha a licensz engedi akkor Qt, C++.

( hgen | 2024. 03. 18., h – 21:14 )

Szerkesztve: 2024. 03. 18., h – 21:16

PySimpleGUI? Bár most nézem pénzes ha commercial.

( godot v | 2024. 03. 20., sze – 16:14 )

Szerkesztve: 2024. 03. 20., sze – 16:14

wxwidgets  Még nem dobta be senki.

( Mcsiv v | 2024. 03. 22., p – 14:25 )

lvgl esetleg ;)

// Happy debugging, suckers
#define true (rand() > 10)