kotschak/qelectrotech-source-mirror
0
0
Fork 0
mirror of https://github.com/qelectrotech/qelectrotech-source-mirror.git synced 2026-09-20 07:14:13 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity
Page: contributing DE
Pages
Home DE Home FR Home SOURCE HISTORY INFO TIER1 RESEARCH TIER2 RESEARCH TIER3 RESEARCH TIER4 RESEARCH api_reference DE api_reference FR api_reference autonumbering DE autonumbering FR autonumbering building DE building FR building cable_catalogue DE cable_catalogue FR cable_catalogue cli_reference DE cli_reference FR cli_reference collection_browser DE collection_browser FR collection_browser community DE community FR community conductors DE conductors FR conductors contributing DE contributing FR contributing contributor_to_wiki_guidelines development_roadmap DE development_roadmap FR development_roadmap downloads DE downloads FR downloads dxf DE dxf FR dxf edz_import DE edz_import FR edz_import element_editor DE element_editor FR element_editor element_linking DE element_linking FR element_linking faq DE faq FR faq features DE features FR features folio_links DE folio_links FR folio_links history DE history FR history keyboard_control languages license DE license FR license mouse_modifiers DE mouse_modifiers FR mouse_modifiers nomenclature_query DE nomenclature_query FR nomenclature_query plc_modules preferences DE preferences FR preferences printing_and_export DE printing_and_export FR printing_and_export project_database DE project_database FR project_database quick_start_guide DE quick_start_guide FR quick_start_guide scripting search_and_replace DE search_and_replace FR search_and_replace templates DE templates FR templates terminal_strips DE terminal_strips FR terminal_strips tips_and_tricks DE tips_and_tricks FR tips_and_tricks title_blocks DE title_blocks FR title_blocks tools user_manual DE user_manual FR user_manual variables DE variables FR variables vision
Clone
1
contributing DE
ispyisail edited this page 2026-09-09 16:04:49 +12:00
Table of Contents

Zu QElectroTech Beitragen

Vielen Dank für Ihr Interesse, zu QElectroTech beizutragen ! Dieser Leitfaden erklärt, wie Sie sich einbringen können, von Fehlermeldungen bis zum Schreiben von Code.

Schnelllinks :

Wege zum Beitragen

Bugs Melden

Sie haben ein Problem gefunden? Helfen Sie uns, es zu beheben:

  1. Suchen Sie nach vorhandenen Problemen um Duplikate zu vermeiden
  2. Erstellen Sie ein Problem mit :
    • Klare Problembeschreibung
    • Schritte zum Reproduzieren
    • Erwartetes vs. tatsächliches Verhalten
    • Ihre QET-Version und Betriebssystem
    • Screenshots falls hilfreich

Funktionen Vorschlagen

Haben Sie eine Idee ? Teilen Sie sie :

  1. Suchen Sie nach Diskussionen um zu sehen, ob sie bereits diskutiert wurde
  2. Öffnen Sie eine Diskussion und erklären :
    • Was Sie tun möchten
    • Warum es nützlich wäre
    • Beliebige alternative Ansätze

Dokumentation Schreiben

Helfen Sie, dieses Wiki und andere Dokumentationen zu verbessern :

  1. Siehe Zum Wiki Beitragen
  2. Hilf bei der Übersetzung der Dokumentation
  3. Erstellen Sie Tutorials oder Guides für häufige Workflows

Benutzerdefinierte Elemente Erstellen

Teilen Sie Ihre Element-Bibliotheken mit der Gemeinschaft :

  1. Erfahren Sie, wie Sie Elemente erstellen
  2. Veröffentlichen Sie auf dem Elements-Repository
  3. Treten Sie dem Elements-Wartungs-Team bei

Code Beitragen

Bereit zu codieren? Folgen Sie diesen Schritten :

Erste Schritte mit Code-Beiträgen

Voraussetzungen

Sie benötigen :

Programmierfähigkeiten :

  • C++ — QET ist in modernem C++ geschrieben (C++11 und später)
  • Qt-Framework — Qt 5.x (aktuell stabil), Qt 6.x (aktiv in Entwicklung)
  • Git — Versionskontrolle ; essentiell für Zusammenarbeit

Werkzeuge und Wissen :

  • QET aus Quelle erstellen — Das Projekt kompilieren können
  • CMake — Von QET verwendetes Build-System
  • Verständnis von :
    • Qt-Framework-Grundlagen (Signale/Slots, Widgets, Modelle)
    • XML-Verarbeitung (QET verwendet XML für Dateien)
    • Die Codebase-Struktur

Empfohlen :

  • Gewisse Vertrautheit mit Stromlaufplänen (hilft, die Domäne zu verstehen)
  • Erfahrung mit Open-Source-Beitrags-Workflows

Schlüsseltechnologien

Komponente Technologie Verwendung
GUI-Framework Qt 5.x / Qt 6.x Benutzeroberfläche, plattformübergreifend
Sprache C++ Logik der Kern-Anwendung
Build-System CMake Konfiguration und Kompilierung
Tests Catch2, googletest Unit-Test-Framework
Dokumentation Doxygen API-Dokumentations-Generierung
Übersetzungen Qt Linguist Internationalisierung (i18n)
Dateiformate XML Projekte (.qet), Elemente (.elmt), Titelblöcke
VCS Git Versionskontrolle (GitHub)

Konfigurieren Sie Ihre Entwicklungsumgebung

  1. Forken Sie das Repository auf GitHub :

  2. Klonen Sie Ihren Fork lokal (mit Submodulen) :

    git clone --recursive https://github.com/IHR_BENUTZERNAME/qelectrotech-source-mirror.git
cd qelectrotech-source-mirror

  3. Fügen Sie Remote-Upstream hinzu um das Haupt-Repository zu verfolgen :

    git remote add upstream https://github.com/qelectrotech/qelectrotech-source-mirror.git

  4. Erstellen Sie einen Feature-Branch für Ihre Arbeit :

    git checkout -b fix/issue-123
# oder
git checkout -b feature/mein-feature
# Branch-Benennung : fix/*, feature/*, docs/*, refactor/*, etc.

  5. Konfigurieren Sie Git-Benutzer (falls noch nicht geschehen) :

    git config user.name "Ihr Name"
git config user.email "ihre.email@beispiel.com"

  6. Aus Quelle erstellen um sicherzustellen, dass die Umgebung funktioniert :

    mkdir build && cd build
cmake ..
cmake --build . --config Release

Änderungen Anbringen

  1. Problem/Funktion verstehen :

    • GitHub-Problem gründlich lesen
    • Kommentar posten falls unklar ("Ich möchte daran arbeiten")
    • Ansatz mit Verantwortlichen für größere Änderungen besprechen

  2. Sauberen, wartbaren Code schreiben :

    • Code-Formatierung befolgen : clang-format verwenden (Konfiguration enthalten)
    • Eine logische Änderung pro Commit — keine unzusammenhängenden Fixes mischen
    • Aussagekräftige Commit-Nachrichten — WARUM erklären, nicht nur WAS
    • Sparsam kommentieren : Nur komplexe Logik benötigt Kommentare
    • Funktionen konzentriert und klein halten

  3. Code-Stil-Richtlinien :

    • Benennung : camelCase für Variablen/Funktionen, PascalCase für Klassen
    • Formatierung : Konfiguriert über .clang-format-Datei (vor dem Commit ausführen)
    • Qt-Konventionen : Qt/KDE-Kodierungsstandards befolgen
    • Modernes C++ : C++11/14/17-Funktionen angemessen verwenden

  4. Tests für neue Funktionalität hinzufügen :

    • Test-Framework : Catch2 oder googletest
    • Unit-Tests schreiben, die Ihre Änderungen verifizieren
    • Sicherstellen, dass vorhandene Tests immer noch bestanden werden : ctest
    • Ausführen : cmake --build . && ctest

  5. Lokal erstellen und testen :

    cd build
cmake --build . --config Release
ctest  # Tests ausführen
./qelectrotech  # App manuell testen

  6. Halten Sie Ihren Branch mit Upstream aktuell :

    git fetch upstream
git rebase upstream/main
# oder zusammenführen, wenn Sie bevorzugen : git merge upstream/main

Reichen Sie Ihren Beitrag ein

  1. Pushen Sie Ihren Branch zu Ihrem Fork :

    git push origin fix/issue-123

  2. Erstellen Sie einen Pull Request (PR) auf GitHub :

    • Gehen Sie zu Ihrem Fork → "Pull Request erstellen"-Schaltfläche
    • Titel : Kurz, beschreibend (z. B. "NaN-Koordinatenvalidierung beim Element-Laden beheben")
    • Beschreibung : Einschließen :
      • Welches Problem löst dies?
      • Wie funktioniert Ihre Lösung?
      • Screenshots für UI-Änderungen
      • Hinzugefügte Tests
      • Verwandte Probleme : "Fixes #781" oder "Closes #782"
    • Base : Auf den main-Branch setzen
    • Draft PR : Als Entwurf markieren, falls noch in Bearbeitung

  3. Reagieren Sie auf Feedback :

    • Betreuer werden Ihren Code überprüfen
    • Kommentare und Vorschläge adressieren
    • Zusätzliche Commits zum gleichen Branch pushen (aktualisiert PR automatisch)
    • Seien Sie geduldig und zusammenarbeitend

  4. Halten Sie PR aktuell, falls sich der Main-Branch ändert :

    git fetch upstream
git rebase upstream/main
git push --force-with-lease origin fix/issue-123

  5. Feiern Sie ! 🎉 Einmal genehmigt und zusammengeführt, ist Ihr Beitrag Teil von QET

Code-Qualität und Normen

Code-Formatierung

QET verwendet clang-format für konsistenten Code-Stil :

# Formatieren Sie Ihre Dateien vor dem Commit
clang-format -i src/meine_datei.cpp
# oder formattieren Sie alle geänderten Dateien
git diff --name-only | xargs clang-format -i

Dokumentation

  • Inline-Kommentare : Nur für nicht offensichtliche Logik
  • Funktions-Dokumentation : Doxygen-Stil für öffentliche APIs verwenden
  • Commit-Nachrichten : Klar, beschreibend, erklären warum nicht nur was

Tests

  • Unit-Tests : Tests für neue Funktionalität schreiben
  • Vorhandene Tests ausführen : Sicherstellen, dass Sie nichts kaputt machen
  • Test-Abdeckung : Mehr Tests = besseres Vertrauen

Commit-Nachrichten-Richtlinien

Gute Commit-Nachrichten-Struktur :

Knappe Zusammenfassung in einer Zeile (50 Zeichen oder weniger)

Längere Erklärung der Änderung. Erklären Sie das Problem,
Ihre Lösung und alle Kompromisse oder Überlegungen.
Halten Sie sich an eine Linienbreite von 72 Zeichen.

Fixes #123

Beispiele :

  • ✅ "NaN-Koordinaten-Validierung beim Element-Laden beheben"
  • ✅ "Leiter-Streifen-Generator-Funktion mit Tests hinzufügen"
  • ❌ "Bug beheben"
  • ❌ "Code aktualisieren"

Code-Überprüfung

  • Betreuer werden Ihren Code überprüfen
  • Kommentare zielen auf Verbesserung, nicht auf persönliche Kritik ab
  • Seien Sie offen für Vorschläge
  • Fragen Sie um Klarstellung, falls etwas unklar ist

Ressourcen und Hilfe

Wo Sie Hilfe Finden

Kommunikation

  • Seien Sie respektvoll — Wir sind alle hier um QET zu verbessern
  • Seien Sie klar — Erklären Sie, was Sie erreichen möchten
  • Fragen Sie um Hilfe — Keine Angst vor Fragen
  • Würdigen Sie Beiträge — Anerkennen Sie die Arbeit anderer

Danke dass Sie Beitragen ! 🎉

Ihre Beiträge helfen QElectroTech ein besseres Werkzeug für alle zu werden. Sei es ein Bug-Fix, eine neue Funktion, Dokumentation oder eine Übersetzung, Ihre Arbeit wird geschätzt !

Fragen ? Treten Sie dem Forum bei oder stellen Sie eine Frage auf GitHub-Diskussionen.

🌐 Sprache wählen — English · Français · Deutsch

Getting Started

Home

🌐 Languages — English · Français · Deutsch

Downloads

Quick Start Guide

User Manual

FAQ

Tips & Tricks

Guides

Conductors — wire properties, what feeds which export, and cables

Wire & cable catalogue — cable types, IEC 60757 core colours, assigning a core to a conductor

Printing and exporting — paper, PDF, images, and what each path does differently

Linking elements — master, slave, terminal

PLC modules — I/O tables and linking a wire to a specific point

Using the element editor — drawing tools, saving, checks

Preferences reference — what each settings page does

Keyboard-only control — mouseless QET, and the one real gap

Mouse modifiers — what Shift, Ctrl and Alt change while you drag

Managing collections — folders, writability, building your own shortlist

Templates — reusable multi-element blocks, and why clicking one does nothing

Search & Replace — bulk property changes

Building a nomenclature query — the BOM/summary table builder

Linking wires across pages — folio reports

Variables & formulas — %f, %{label}, sequences

Auto-numbering — schemes, sequences, freezing

Terminal strips — strips, levels, bridges

Title block templates — the .titleblock format

Importing EPLAN parts (.edz) — EPLAN Data Portal

DXF import & export — two unrelated features, one format

The project database — the in-memory SQLite cache

File formats
Elements XML
Project XML
Development

Building from Source

Contributing Code

Automating QET — CLI, XML formats, external tools

CLI Reference — command line usage

JavaScript Scripting — --run, geometry editing, undo

Development Roadmap

Vision — proposal, under discussion

Developer Tools

About

Features

History

Community

License

Contributing to this Wiki

Home tools

qelectrotech