# xtree

Bla blu moo!

...

## Build

```
git clone https://gitea.sourceworx.org/chris/xtree.git
cd xtree/src
qmake xtree.pro
make
```

## Verzeichnisstruktur

|  |
|--------|
| `deprecated/` | Reste & Fehlversuche
| `doc/` | Quellcode-Dokumentation
| `qml/` | QML Quellcode
| `src/` | c++ -Quellcode
| `xml/` | XML modeldefinition & Demodaten

## keys

 - Widgetset für XML Daten
 - experimenteller qml support
 - docs erzeugen
 - 
 
 experimenelle

## Also, noch mal von vorn:

- Es geht um das Editieren von XML Daten in einer baumartigen Darstellung am Bildschirm.
- Es handelt sich vorwiegend um technische Daten: Strom, Spannung, unterschiedliche Betriebsparameter und sowas.
- Die Qt Viewerklassen arbeiten feldbasiert, die Datenfelder heissen 'Items', die Basisklasse zu einem Datenfeld heisst bei uns ```XQItem```
- Unser Darstellung der  Datenfelder ist im Prinzip erstmal tabellenartig, bla blu

- Die QtLib unterscheidet zwischen 'rendering' und 'editing'
- bla blub

Also: itemtypes werden einfach beschrieben, mit properties, wie die properties intern implementiert werden, ist erstmal
egal: ein type sheet

pattern: model-view-controller
qt: model-view
wir: modelhub _only_

-- 

ein ItemType aggregiert gemeinsame Eigenschaften von Items, z.b. UnitType, EditorType, RenderTypezusammen, die ein Gruppe von Items gemeinsam


# Old stuff:

## Getting started

Das working directory muss aufs source directory zeigen, da liegen unter  xml/ 
die Testfiles.

## Wo ich hinwill

- [ ] Alle models, menus etc. sollen in XML beschrieben werden, siehe xml/modelsheet.xml 
- [ ] Es gibt nur eine Modelklasse: XQModel (ist ein QStandardItemModel)
- [ ] Datenlogik und Anwendungslogik sollen getrennt sein
- [ ] Dazu werden die Datenknoten (composites) in einen Wrapper verpackt und in den Items 'versteckt'
- [ ] Für jede Editorklasse XyzEditor.cpp gibt es eine Klasse XyzHub.cpp
- [ ] Im XyzHub wird die Anwendungslogik implementiert, d.h. die SIGNALs der UI werden mit Operationen auf das Model verbunden
- [ ] Operationen auf Datenknoten werden für die Anwendung transparent von der Datenschicht ausgeführt
- [ ] Die genaue Implementierung dafür ist mir noch unklar:
- [ ] ```ZQNode::nodeManager.applyCommand( ZQCommand( ZQ::PasteNode, ZQNode& ) )``` ???

## Basisklassen

- [ ] ```znode::zbasic_node<string_type>``` Knotenabstraction, vgl. ```std::basic_string<char_t>```
- [ ] ```ZQNode``` template-Instanziierung von zbasic_node mit QString
- [ ] ```XQModel``` ein QStandardItemModel mit ZQItems
- [ ] ```XQItem``` ein QStandardItem mit einem XQNodeWrapper 
- [ ] (Sauberer wäre ein eigenes Model aus einem QAbstractItemModel, aber das ist dann wirklich Arbeit ...) 
- [ ] ```XQNodeWrapper``` verpackt einen ZQNode* und vermittelt dessen Attributes an die ViewItems
- [ ] ```XQNodeManager``` operations on nodes, gibts noch nicht.
- [ ] Eigentlich  ```znode::znode_manager<zbasic_node<string_type>...> ...``` für alle Anwendungsfälle
- [ ] ```XQModelReader``` erzeugt QModels aus XML, siehe XML/modelsheet.xml
- [ ] ```XQModelHub``` Datenmanager-Klasse, hier läuft alles zusammen
- [ ] ```class XQModelHub : public XQModel, public XQModelReader```: etwas fragwürdig, spart aber leidige Verpointerungen


# libPiGPIO

libPiGPIO: Eine C++ Softwarebibliothek für den Pi4 zur Einbindung elektronischer Steuerelemente

## Getting started

To make it easy for you to get started with GitLab, here's a list of recommended next steps.

Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!

## Add your files

- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
- [ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:

```
mkdir existing_repo
git remote add origin http://sourceworx.org:9099/opensource/libpigpio.git
git branch -M main
git push -uf origin main
```

## Integrate with your tools

- [ ] [Set up project integrations](http://sourceworx.org:9099/opensource/libpigpio/-/settings/integrations)

## Collaborate with your team

- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
- [ ] [Automatically merge when pipeline succeeds](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html)

## Test and Deploy

Use the built-in continuous integration in GitLab.

- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing(SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)

***

# Editing this README

When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!).  Thank you to [makeareadme.com](https://www.makeareadme.com/) for this template.

## Suggestions for a good README
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.