WebGang/CityGang

https://gitlab.com/stockpi/stockpilib/-/wikis/Directory-structure

Locatie van bestanden
Aansluitend op 12/12 vroeg ik me nog af wat eigenlijk de “normale” plaats is om bv gewiste foto’s onder te brengen.

Het gaat over foto’s die je in Stockpi niet meer nodig hebt, en wil wissen, maar met een tussenstap, een soort “vuilbakje” waar ze nog even blijven zitten.

Het is altijd mooi om dingen op de Linux/unixachtige manier te doen, dus hoe werkt het “vuilbakje” op de desktop?

Die vraag bracht me bij de definitie van het vuilbakje; die ligt blijkbaar vast in een systeemvariabele die van overal oproepbaar is met $XDG_DATA_HOME/Trash en de standaardwaarde is: ~/.local/share/Trash/files
(in files zitten de verwijderde bestanden, er kunnen ook andere bestanden en directories zijn voor het “management” van de vuilbak, ik zie bv bestand “directorysizes” en de map “info”)
Zie ook http://linuxuser.copyleft.be/liglog/?p=11369

Toegepast op stockpi nemen we “Trash” mee en wordt dat dan:

~/.local/share/myStockpiApplication/Trash/files

en volgens dezelfde logica wordt wat wij in ~/Data deden, dan ~/.local/Share en dus de data directory van de databank (zie DIRKEYPicDb in MStockpiData):

~/.local/share/myStockpiApplication/PicturesDb/

Met “myStockpiApplication” bedoel ik de “naam” van de toepassing, of de combinatie van de naam van de toepassing en de naam van de datacontext; bv : stockpiapp/default of stockpiapp/development of stockpiapp/audioparts

Er zal wat vrijheid nodig zijn om zowel met stockpiapp als stockpicli wel dezelfde verzameling te kunnen gebruiken, de “naam van de toepassing” moet dus niet te vast zijn (bv zelfde verzameling vanuit stockpicli en -app).

~/.local/share/stockpiapp/default/DbPictures/

(in plaats van ~/Data/mystockpiapplication/.dbpictures/); dat wordt aangepast in de code van de settings.
Nu blijft het de vraag of we die ~/Data houden voor de (zichtbare) in- en output.

Hulpmiddelen
Er is een “DataContext voor directories” t geïntegreerd in stockpilib; in CDataContext:

1) suggereren van de boven beschreven (onzichtbare) directory als keuze voor
- voor de beelden van de database
- voor de “deleted” beelden/archief
suggestHiddenDataDir(sFunction As String, sContextName As String, Optional sOtherAppName As String, Optional bTrash As Boolean) As String

2) suggereren van de boven beschreven directory als keuze voor
- de “in” beelden (camera, import, download..)
- de “export” van data (html, csv, txt, ..)
suggestVisibleDataDir(sFunction As String, sContextName As String, Optional sOtherAppName As String, Optional bTrash As Boolean) As String

3) maken van directories van een path:
makePath(sNewPath As String, Optional iDepth As Integer) As Boolean

Maken van de subdirectories (vaste namen?)
De namen liggen vast in constanten in MStockpiData:
Const DIRKEYPicCam, DIRKEYPicIn, DIRKEYPicDownload, ,, enz..

MStockpilib makeInvisibleSubdirs maakt de subdirectories op basis van de DIRKEY constanten.

Uitzending 12/12 vragen we ons af hoe Kunstmatige Intelligentie onze Stockpi programmeerproblemen zou oplossen: Waar de foto bewaren die je maakt met de (ingebouwde/picam) camera?

Standaard was dat /home/pi/Pictures in een beginversie.
Maar daar werkt de raspberry pi, en alle applicaties voor gewoon fotobeheer mee, en we willen de gegevens van onze applicatie echt apart houden, we zien het als “Data“.
Maar ook in een /home/pi/Data directory kunnen meer toepassingen hun data bewaren, dus we plakken er onze applicatienaam of een andere vrij te kiezen naam nog achter:

Dus bv: /home/pi/Data/mystockpiapplication

Nu opteren we voor een “in” directory,
/home/pi/Data/mystockpiapplication/In,
waar verschillende manieren mogelijk zijn om foto’s aan te leveren aan stockpi:

• Camera
• Import
• Download
• …

Elke manier heeft zijn eigen subdirectory, dus de bron blijkt uit de directorynaam.

De camera bewaart standaard dan in
/home/pi/Data/mystockpiapplication/In/Camera

Als je met een script een hoop beelden importeert (bv van een andere stockpi) kan dat naar
/home/pi/Data/mystockpiapplication/In/Import

En als je zelf van een website foto’s afhaalt zet je die zelf in
/home/pi/Data/mystockpiapplication/In/Download

Op die manier is het altijd duidelijk dat dit de data is van het stockpiprogramma, en dat dit de inkomende beelden zijn. Bij het kiezen van een beeld moet je dan wel ook de map kiezen (een andere mogelijkheid is alles zonder subdirectories in de In directory te doen, we zullen zien wat beter blijkt).

Eens een beeld uitgekozen wordt, wordt de naam in het veld bewaard en het beeld verplaatst/gekopieerd naar de database-beelden directory.

De werkelijk gebruikte beelden komen bv in een verborgen directory: (*)
/home/pi/Data/mystockpiapplication/.dbpictures/
(*) zie update https://webgang.radiocentraal.be/?p=16743

Normaal staat die niet zichtbaar, dus je kan minder gemakkelijk per vergissing iets wissen hier (wat een probleem zou zijn want dan wordt de foto die in de database ingevuld is niet gevonden).

Op onze Stockpi wishlist voor de Sint:

• Export naar html
• Export naar .txt of .csv
• Export naar XML…

Html
Export naar html zou fijn zijn, omdat je daarbij ook de beelden kunt opnemen in de gegevens.
Als je met een browser (Firefox) naar de index.html pagina gaat van de export-html map, dan kan je daarmee rondbladeren in de collectie..;
Een eenvoudige ruwe export naar simpele html is genoeg als aanzet, gebruikers kunnen zelf hun uitbreiding, CCS,… maken.

BCP-2 is terug
Met een gecontroleerde update van tumbleweed en een check de avond voor de uitzending is het vertrouwen terug groot genoeg om de BCP2 mee te brengen, en de oude vervang BCP1 thuis te laten.

StockPi blijft splitten
Het was een tijdje stil rond ons StockPi project, maar dat betekent niet dat er niets gebeurde. Integendeel, het project heeft er nog een paar takken bijgekregen: StockPiLegacy en StockPiDesktop. Dat naast de betaande StockPiApp, de desktop applicatie voor op de Raspberry Pi, en de StockPiCLI, de commandolijn versie, waar je dus zelfs geen desktop voor nodig hebt, en die je in een terminal of over ssh kan gebruiken.

StockPiDesktop
- Door de software te ontwikkelen op een desktop of een laptop, ontstond de neiging om meer gebruik te maken van mogelijkheden van de (KDE) desktop, die iets verfijnder is dan op de Raspberry Pi, en bv een groter scherm heeft of een hogere resolutie. Niet alles wat in die StockPiDesktop versie wordt gemaakt, hoeft te worden ingevoerd in de normale StockPiApp.

StockPiLegacy
Maar daaruit groeide het besef dat de beperkingen van de Raspberry Pi versie ook te maken hadden met de wat verouderde software op dat bord. Ook de Gambas versie is er ouder en kan niet alles draaien wat we op een recentere versie kunnen programmeren. Dus misschien is die oude Raspberry Pi het probleem, en moeten we eerder overwegen of we die nog wel als standaard nemen voor ons project. Omdat we het ding toch aan de praat wilden houden, maakten we een afsplitsing van de App en noemden die StockPiLegacy. De

We zitten met een vraag rond de workflow van stockpi.

De versie die draait op een oude raspberry pi met oud systeem, moet altijd een beetje aangepast worden, bepaalde parameters werken niet in die oude versie van gambas, omdat die toen nog niet bestonden. Maar in de nieuwe versie worden die standaard ingevuld met een waarde, de oude versie herkent dat niet en “crasht” erop.

Eigenlijk zouden we nog een extra versie kunnen maken, StockPi-”obsolete”, -”legacy” of zo, maar we vragen ons af of er geen betere oplossing is. Een aparte branche misschien? Branche “legacy”, “Os9Gb3-9-1″ (laatste geeft ineens weer voor welk systeem compatible).

Het probleem is dat je elke keer dat je een merge doet uit de development code, allerlei dingen moet gaan verwijderen, die niet van toepassing zijn. Dan moet je telkens schakelen tussen de development branch en de “lecacy” branch.

En zo ontdekken we de oplossing die in git zelf ingebakken zit: git worktree.

En nu maar hopen dat dat in die oude systeem-versie werkt ….

De branch thing2 wordt onderhouden op de stockpi met een oud bord+distro.
Die wil ik tegelijk kunnen zien/bewerken met een recente development branch als dev-hq.

Upd: ik heb een branch bijgemaakt …legacyapp die ik in mijn workflow in worktree “stockpilegacy” houd.

Git worktree

Zie git worktree

Kennismaking met de Raspberry Pi 5 vs Raspberry Pi 2/3

Uitpakken met de 5
We pakken uit:
- eenvoudig kartonnen doosje met Raspberry Pi 5 bord, en een briefje met blabla.
- een originele voeding 5.1 V, 5A (?!?!)
- Real Time Clock batterij (met klein stekkertje)
- SD kaart met origineel Raspberry Pi OS.
- Officiële 2-kleurige behuizing met ingebouwde ventilator, en een eenvoudige zwarte behuizing met enkel ventilator-opening, en wat afgerondere hoeken.

We spoelen even vooruit voorbij …
starten, configureren (nvdr: zie foto’s) wat allemaal eenvoudig verloopt.

Stekker in het stopcontact..
Systeemversie : Raspberry Pi OS (dec 20223) + updates draaien
Opstarttijd: zo’n 20 seconden, veel en veel sneller dan onze oude uit de 3-reeks
Voeding (verbruik?): usb-C, zwaardere voeding (27 watt!). Ook uitgeschakeld blijft hij stroom verbruiken (en blijft ook een beetje warm). Ingeschakeld moet je de behuizing openen als het een type gesloten kast is.
Temperatuur? Gaat al snel naar 40 °C, wat meer programma’s 60°C, en een spelletje: 80°C!!
Om de temperatuur op te vragen, tik:
vcgencmd measure_temp

Opensuse op Pi5?
Nog te vroeg?

Programmeren
- De vaste waarden zijn aanwezig: Scratch (2 en 3), Thonno, …
- Programmeer-omgeving toevoegen:
Voorkeuren, add/remove software: gambas3: Complete Visual Development Environment gekozen, installeert, icoon onder development, maar start niet.
Vanop de commandolijn zie je de foutmelding:

webgang@raspberrypi:~ $ gambas3

**
** OOPS! INTERNAL ERROR. Program aborting, sorry! :-(
** Cannot find interface of library ‘gb.gtk3.wayland’
**
** ERROR: #27: Cannot load component ‘gb.gtk3.wayland’: cannot find component
**
** Please send a bug report to the gambas bugtracker [1] or to the gambas mailing-list [2].
** [1] http://gambaswiki.org/bugtracker
** [2] https://lists.gambas-basic.org/listinfo/user
**

Software management, zoek naar die gb.gtk.wayland, aanvinken, bevestigen.

Ok! Als je scherm wat doorgestreept wordt, zet het venster van Gambas3 dan kleiner.

Stockp project
- fouten op alle onderdelen, de StockpApp en de StockpiDesktop, StockpiCLI (die in principe geen gtk conflict kan hebben want enkel command line) en ook de library (die zelfs geen user interface heeft).
Foutmelding bv:

Kan project bestand niet openen:
/home/webgang/dev/gb3prj/stockpi/stockpilib
Read-only array
[gb.gui.base].^^Desktop.GetDesktop.58 [gb.gui.base].^^Desktop.Types_Read.72 [gb.gui.base].^^Desktop.Is.79 VersionControl.GetTextEditor.56 VersionControl.Refresh.99 Project.Open.688 FWelcome.btnOpen_Click.186 CCoolButton.Panel_MouseUp.149 ?

Omdat er mogelijk stukjes gambas3 mankeren (niet alles wordt altijd mee geïnstalleerd), herhaal ik het installatie-commando met een * voor alle pakketten:

sudo apt install gambas3*

Er worden een aantal bijkomende gambas3 paketten geïnstalleerd.

Versie: 3.18.0 (vgl op onze opensuse desktop : 3.19.0)

Raspberry Pi updaten:
- eerst de “package list” updaten:
sudo apt update
dan de software zelf / het systeem :
sudo apt full-upgrade

Als je een snelle internetverbinding hebt (glasvezel), gaat dit allemaal razendsnel.

De Pi5 start ook veel sneller op dan zijn oudere familie op, een reboot duurt nauwelijks een goede 20 seconden.

Maar de fout blijft:

Kan project bestand niet openen:
/home/webgang/dev/gb3prj/stockpi/stockpilib
Read-only array
[gb.gui.base].^^Desktop.GetDesktop.58 [gb.gui.base].^^Desktop.Types_Read.72 [gb.gui.base].^^Desktop.Is.79 VersionControl.GetTextEditor.56 VersionControl.Refresh.99 Project.Open.688 FMain.OpenProject.164 FMain.Action_Activate.1667 [gb.gui.base].^Action.Raise.238 ?

Zie onderaan de systeeminformatie van Gambas3.

Database
Hopelijk komt de fout niet doordat we nog geen database geïnstalleerd hebben …

sudo apt install mariadb-server
Of uitgebreider Engelstalig hier op hackernoon bv
Nederlandstalig vind je hier wel wat met een zoek op “mariadb”

Upd:
- ik kan de Gambas3 projecten, die bewaard worden als tar.gz wel downoaden, uitpakken en openen in de Gambas3 IDE. Voor de Library stockpilib betekent dat bv dat je ze kan compilen (let op waar de lib terechtkomt …)

Details…
Read the rest of this entry »

Stockpi Desktop Remote
Mijn eerste uitvoering van de combinatie StockPi – (~) – StockPiDesktop

Aan mijn linkerzijde: Stockpi uitvoering zoals vroeger voorgesteld in de studio.
Software:
- stockpilib + stockpiapp
- mysql, gambas3, Raspbian Linux 9
Deze pi hangt aan het netwerk.

Aan mijn rechterzijde: StockpiDesktop (inderdaad op de desktop van mijn pc).
Software:
- stockpilib + stockpidesktop
- Linux KDE/Plasma (openSuse 15.5)

Stockpi Desktop voorbereiding en instellingen:
- kopieer de images van de raspberry pi naar je desktop computer (bv met scp of fish).
- in het instellingen scherm de directory van de images instellen op je lokale kopie
ps hierbij bug gevonden in bewaren van de directory met de foto’s, aangepast in app, desktop en lib
- een andere optie is de images te bewaren op een Nextcloud server, en die zowel vanop de raspberry pi als de desktop te gebruiken. Je kan zelfs op de Nextcloud de rechten van de desktop beperken als die alleen de foto’s mag bekijken.

Het hele stockpi project:

Stockpi project
Met een paar handelingen kan je meedoen met ons stockpi project; waarschijnlijk heb je de eerste stap(pen) ooit al gezet, dus begin waar je past:
- installeer Linux
- installeer git (client)
- installeer gamba3

Installeer stockpi
We beginnen als je gambas geïnstalleerd hebt:
- kies voor jezelf uit waar je je gambas software projecten wil hebben, maak die map, bv ~/gambas3/pjr. Maak daarin een map stockpi, waarin je de verschillende onderdelen gaat zetten.
- ga naar gitlab.com/stockpi, kies daar eerst de lib, die heb je voor alles nodig. Klik in die pagina op de knop “Code”, en kies bv de https versie: “Clone with HTTPS”. Klik op het symbool om de URL te kopieren: https://gitlab.com/stockpi/stockpilib.git.
- Ga in een terminal in je projecten map staan cd ~/gambas3/prj/stockpi, en haal daar de software af met git clone en de voorheen naar het klembord gekopieerde link: git clone https://gitlab.com/stockpi/stockpilib.git
De software wordt mooi klaargezet in een mapje stockpilib

Gambas
- Start gambas3, kies Bestand, project openen, ga naar je projectmap en selecteer de stockpilib.
- In de linkse kolom zie je de onderdelen, broncode en klassen van deze library. Check bij menu Project, Properties, dat het Project Type op Library staat (en cancel). Nu kan je in het menu Project, Make, Executable kiezen. Dat compileert de library, en zet die op een plek waar ze kan gekozen worden om te gebruiken in andere projecten, in ons geval stockpiCLI of stockpiapp. Let er op dat je de executable niet in de eigen projectmap zet, kiesn een plek voor uitvoerbare programma’s, maak bv de map ~/gambas3/run, en kies die als plaats om stockpilib.gambas te maken. ps: Zet bij de opties “increment version” af.

Programma’s
Doe wat betreft het afhalen en openen hetzelfde voor stockpicli en/of stockpiapp.

Bij het openen moet je het project vertellen de stockpilib als library te gebruiken. Dat doe je onder Project, Properties, Libraries: in mijn geval staat daar automatisch “webgang / stockpilib 0.1.5“, zoniet doe je “Add….” en kies je uit de Libraries “webgang/stockplib”.

Bij eerste gebruik zijn de databasegegevens nog niet ingevuld, en zal er niet veel te zien zijn, behalven een startscherm met File, Settings, Help..

(wordt vervolgd; volgende keer: de databank en de instellingen)

We gebruiken Git(Lab) voor ons stockpi project

Dit is een voorbeeld van hoe een workflow kan zijn. Verschillende takken zijn van de main afgetakt door verschillende gebruikers. Die werken aan een bepaald stukje software, bv de Setup procedure van het programma. Git laat toe dat verschillende mensen tegelijk aan het project werken (hier bv rood, blauw en groen), en helpt om die stukjes nadien in elkaar te puzzelen.

Die ontwikkeling gebeurt “lokaal” op de computer van die ontwikkelaar. De ontwikkelaar haalt eerst een kopie af van de “main”, wat clonen genoemd wordt, en geeft die een naam; bv dev-hq=development headquarter, een naam die de developer op het hoofdkwartier van Webgang gekozen heeft.

Hij maakt een “tak” of branch voor het werk waaraan hij bezig is, en geeft die ook een naam, waaraan je kan zien waar hij aan werkt, hier bv de setup procedure in Dev01Setup.

Als dat stuk klaar is wordt het met commit + push online gebracht en is het al af te halen/in te zien door anderen. Denkt de ontwikkelaar dat het ver genoeg klaar is brengt hij het naar de “test” branch, onderaan op de afbeelding.

In de test branch worden alle ontwikkelingen samen gebracht, en in ons programma “testen” we die uit; enerzijds de lib compileren en anderzijds de cli en de app die de lib gebruiken uitproberen. Als een programam crasht proberen we dat te documenteren. Anders: We noteren opmerkingen en correcties.

Goedgekeurd? Als de combinatie goed werkt gaat alles naar de “main”.

Het toeval (enigzins geholpen door Marthe) wil dat we een professionele developer in de studio hebben, Claes, en we toetsen onze workflow bij hem af.

Hij veegt de oranje testbranch op het witbord hierboven weg, en vult aan:
- de eigen tak van de ontwikkelaar wordt “feature branch” genoemd (omdat een bepaalde “nieuwe functie” wordt bijgemaakt – kan uit een tickeet komen).
- tijdens de otnwikkeling kan een programmeur al collega’s raadplegen
- peer review: een collega-programmeur die enigzins op de hoogte is van het onderwerp, gaat je code nakijken om denkfouten eruit te halen enz.
- Hij kan een soort “ok” geven (merge request) waardoor het programma klaar wordt gezet om in de main branch opgenomen te worden.
- Voor het integreren van die tak in de main helpt het platform; je kan “merge request” aanvinken, er commentaar bij ingeven, en het systeem documenteert en zet een knop klaar om dat te aanvaarden door de beheerder van de main branch; dat kan een ontwikkelaar zijn, of een coördinator, binnen het platform kunnen rollen verdeeld worden met bijhorende rechten.
- automatisch testen: in het gitlab (of ander git-) platform kan je een aantal voorgeprogrammeerde testen laten lopen; die kunnen semantisch zijn (bv spellingscontrole bij documentatie), of functioneel: compileert het programma, kan het programma gestart worden, en zelfs het gebruik van het programma kan getest worden.
- Als een nieuwe main gemaakt is, wordt die ook nog eens uitvoerig getest (met de automatische procedures).
- de “feature branch” wordt verwijderd.

Ook op voorhand wordt er bepaald wat er allemaal moet geprogrammeerd worden, je kan daarvoor een ticketing systeem gebruiken (“type feature request”) dat op het gitlab (of ander) platform voorhanden is. Dat is hetzelfde principe van wat wij zouden doen, maar natuurlijk verloopt het daar gestructureerder. De tickets kunnen afgevinkt worden, gekoppeld aan een “merge” in de main, gekoppeld aan andere systemen enz.