From 79334eeb0ecfb6e7add53bd85bd5def0edc0eda9 Mon Sep 17 00:00:00 2001 From: UMTS at Teleco Date: Tue, 9 Dec 2025 10:08:53 +0100 Subject: Gewähltes Projekt geändert MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Abgaben/Beepzone-Stack-Projektplanung.md | 25 ++++++++++ Abgaben/SwiftEdging-Projektplanung.md | 56 ---------------------- .../Projektplanungen/SwiftEdging-Projektplanung.md | 56 ++++++++++++++++++++++ JOURNAL.md | 13 +++-- README.md | 2 +- 5 files changed, 91 insertions(+), 61 deletions(-) create mode 100644 Abgaben/Beepzone-Stack-Projektplanung.md delete mode 100644 Abgaben/SwiftEdging-Projektplanung.md create mode 100644 Archiv/Projektplanungen/SwiftEdging-Projektplanung.md diff --git a/Abgaben/Beepzone-Stack-Projektplanung.md b/Abgaben/Beepzone-Stack-Projektplanung.md new file mode 100644 index 0000000..e520ddf --- /dev/null +++ b/Abgaben/Beepzone-Stack-Projektplanung.md @@ -0,0 +1,25 @@ +# BeepZone-Stack Initiale Finalisierung +> Eine sehr Effiziente, Funktionsreiche als auch Integrierbare Inventarisierungslösung geschrieben in Rust +###### *T.Bachmann (aka. crt oder umts) - 2025-12-09* + +## Kurzplanung + +### Ausgangslage +- BeepZone-Backend (MySQL Schema und Sekel-Proxy) : Läuft stabil, benötigt jedoch diverse Aufräumarbeiten und Dokumentation. +- BeepZone-eGUI (Desktop Client) deckt die Grundfunktionalität ab, es fehlen aber diverse Features (zB. richtiges RBAC, Admin Panel View) und es gibt noch diverse Lücken im Bereich Tests und Dokuemntation. + +### Hauptproblem +Ohne den Finalisierten Stack kann das Inventarsystem nicht im Betrieb umgesetzt/angewendet werden. + +### Projektziel (Soll) +BeepZone-Stack produktion bereit machen und publizieren sowie für internen Einsatz fertigstellen. + +### Teilziele +- Fehlende im UI Angezeigte Funktionen implementieren +- Fehlende Funktionen bezüglich Admin Panel und RBAC implementieren +- Tests aller Funktionen und Feinschliff +- Code aufräumen und Dokumentation und Setup Anleitung fertig Stellen. + +### Nutzen +- Intern: Schliesst die aktuelle Lücke im Bereich Inventarisierung, reduziert unbemerkter Diebstahl, und erleichtert Audits von Zimmern und deren Zugewiesenen Objekte +- Extern: Vorzeigbares OpenSource Projekt das von anderen Verwendet werden kann bzw. erweitert und Verbessert werden kann. \ No newline at end of file diff --git a/Abgaben/SwiftEdging-Projektplanung.md b/Abgaben/SwiftEdging-Projektplanung.md deleted file mode 100644 index 7663834..0000000 --- a/Abgaben/SwiftEdging-Projektplanung.md +++ /dev/null @@ -1,56 +0,0 @@ -# SwiftEdging -> Ein MacOS "Ammonia Tweak" welcher in Kombination mit aspauldingcode's "apple-sharpener" rundungen von SwiftUI Fensterelementen wieder einheitlich Aussehen lässt (auf MacOS 26 - Tahoe, ist aber auch rückwärts anwendbar) -###### *T.Bachmann (aka. crt oder umts) - 2025-12-02 - -## Projektbeschreib - -### Ausgangslage bzw. Ist-Zustand - -Apple hat mit dem "Liquid Glass" Design (intern "Solarium" genannt) eine komplette Design Änderung ihrer Betriebssysteme eingeführt. -Diese Änderung brachte jedoch diverse Inkonsistenzen mit sich, welche sich besonders auf macOS zeigen. - -#### Hauptproblem -Inkonsistente Rundungen von Fensterrahmen und UI Elementen innerhalb dieser. - -#### Bisherige Lösungsversuche mit Ammonia* -*macOS dylib "Tweak" Injektions Tool - - -##### Versuch 1 : Rückfall auf altes Design - -- Tools: Ammonia + bedtime's "BrokenGlass" Tweak -- Funktion : Deaktiviert das gesamte "Solarium Theme" durch dylib Injektion -- Ergebnis : Einheitliche Fensterrahmen Rundungen / UI Elemente durch verwenden des alten einheitlichen Designs jedoch mit SwiftUI Material Resolution Problemen -- Probleme : - - "Material Resolution" Probleme : - - Rechte MenuBar Elemente entweder nicht Sichtbar oder deren Pop-Over Transparent und durchklickbar - - Benachrichtigungs Relevante Element Hintergründe werden transparent und unlesbar - - Instabilität des Systems bei verwendung von Apps welche MenuBar Elemente erstellen oder diese anpassen -- Aussicht auf Problemlösung: Um das Problem zu beheben wäre (meines Wissen nachs) extrem komplexes Reverse Engineering auf SwiftUI ABI Basis erforderlich, sowohl Erfolgschancen als auch Kompetenzen sind dafür nicht gegeben, somit für mich nicht lösbar. - -##### Versuch 2 : Reparattur des neuen Designs - -- Tools: Ammonia + "apple-sharpener" Tweak -- Funktionsweise : Hijacking des macOS Window Managers durch dylib injektion und Swizzling -- Ergebnis : Fensterrahmen werden korrigiert, aber Inkonsistenzen innerhalb der Fenster werden nicht behoben bzw. sogar verschlimmert -- Probleme : - - Nur Fensterrahmen Rundungen werden korrigiert - - Neue Inkonsistenzen werden hinzugefügt - - Warnungs Pop Ups sehen seltsam aus -- Aussicht auf Problemlösung : Um das Problem zu beheben wäre ein weiterer Tweak erforderlich welcher gezielt die UI Elemente innerhalb Fenster repariert. Dies ist sehr gut machbar da Rundungs Anpassungen via Swizzling möglich und somit für mich lösbar sind, nicht so wie Material Resolution Probleme welche (meines Wissen nachs) auf tieferer Ebene gemacht werden müssten. - -### Zielsetzung bzw. Soll-Zustand -Entwicklung eines macOS Tweaks der die Rundungswerte betroffener UI Elemente gezielt und flexibel anpassen kann und mindestens mit "apple-sharpener" kompatibel ist. - -#### Kernfunktion -- Regelbasiertes System : Definition von Rulesets welche gezielt Anpassung von Apps und individuellen UI Elementen erlauben -- JSON basierte Konfiguration : Strukturierte Verwaltung der Anwendungs und Anpassungsregeln - -#### Benutzeroberfläche -- MenuBar App : Grafische Oberfläche für Steuerung -- Funktionen : - - Aktivieren / Deaktivieren von Rulesets für spezifische Fenster - - Verwaltung von App spezifischen Ausnahmen/Inklusionen - - Dynamische Anpassungen ohne manuelle JSON Bearbeitung -- Zweck : Fehlerbehandlung bei Inkompatibilitäten Apps sowie anwendung auf noch nicht in JSON inklusierten App whitelist - diff --git a/Archiv/Projektplanungen/SwiftEdging-Projektplanung.md b/Archiv/Projektplanungen/SwiftEdging-Projektplanung.md new file mode 100644 index 0000000..7663834 --- /dev/null +++ b/Archiv/Projektplanungen/SwiftEdging-Projektplanung.md @@ -0,0 +1,56 @@ +# SwiftEdging +> Ein MacOS "Ammonia Tweak" welcher in Kombination mit aspauldingcode's "apple-sharpener" rundungen von SwiftUI Fensterelementen wieder einheitlich Aussehen lässt (auf MacOS 26 - Tahoe, ist aber auch rückwärts anwendbar) +###### *T.Bachmann (aka. crt oder umts) - 2025-12-02 + +## Projektbeschreib + +### Ausgangslage bzw. Ist-Zustand + +Apple hat mit dem "Liquid Glass" Design (intern "Solarium" genannt) eine komplette Design Änderung ihrer Betriebssysteme eingeführt. +Diese Änderung brachte jedoch diverse Inkonsistenzen mit sich, welche sich besonders auf macOS zeigen. + +#### Hauptproblem +Inkonsistente Rundungen von Fensterrahmen und UI Elementen innerhalb dieser. + +#### Bisherige Lösungsversuche mit Ammonia* +*macOS dylib "Tweak" Injektions Tool + + +##### Versuch 1 : Rückfall auf altes Design + +- Tools: Ammonia + bedtime's "BrokenGlass" Tweak +- Funktion : Deaktiviert das gesamte "Solarium Theme" durch dylib Injektion +- Ergebnis : Einheitliche Fensterrahmen Rundungen / UI Elemente durch verwenden des alten einheitlichen Designs jedoch mit SwiftUI Material Resolution Problemen +- Probleme : + - "Material Resolution" Probleme : + - Rechte MenuBar Elemente entweder nicht Sichtbar oder deren Pop-Over Transparent und durchklickbar + - Benachrichtigungs Relevante Element Hintergründe werden transparent und unlesbar + - Instabilität des Systems bei verwendung von Apps welche MenuBar Elemente erstellen oder diese anpassen +- Aussicht auf Problemlösung: Um das Problem zu beheben wäre (meines Wissen nachs) extrem komplexes Reverse Engineering auf SwiftUI ABI Basis erforderlich, sowohl Erfolgschancen als auch Kompetenzen sind dafür nicht gegeben, somit für mich nicht lösbar. + +##### Versuch 2 : Reparattur des neuen Designs + +- Tools: Ammonia + "apple-sharpener" Tweak +- Funktionsweise : Hijacking des macOS Window Managers durch dylib injektion und Swizzling +- Ergebnis : Fensterrahmen werden korrigiert, aber Inkonsistenzen innerhalb der Fenster werden nicht behoben bzw. sogar verschlimmert +- Probleme : + - Nur Fensterrahmen Rundungen werden korrigiert + - Neue Inkonsistenzen werden hinzugefügt + - Warnungs Pop Ups sehen seltsam aus +- Aussicht auf Problemlösung : Um das Problem zu beheben wäre ein weiterer Tweak erforderlich welcher gezielt die UI Elemente innerhalb Fenster repariert. Dies ist sehr gut machbar da Rundungs Anpassungen via Swizzling möglich und somit für mich lösbar sind, nicht so wie Material Resolution Probleme welche (meines Wissen nachs) auf tieferer Ebene gemacht werden müssten. + +### Zielsetzung bzw. Soll-Zustand +Entwicklung eines macOS Tweaks der die Rundungswerte betroffener UI Elemente gezielt und flexibel anpassen kann und mindestens mit "apple-sharpener" kompatibel ist. + +#### Kernfunktion +- Regelbasiertes System : Definition von Rulesets welche gezielt Anpassung von Apps und individuellen UI Elementen erlauben +- JSON basierte Konfiguration : Strukturierte Verwaltung der Anwendungs und Anpassungsregeln + +#### Benutzeroberfläche +- MenuBar App : Grafische Oberfläche für Steuerung +- Funktionen : + - Aktivieren / Deaktivieren von Rulesets für spezifische Fenster + - Verwaltung von App spezifischen Ausnahmen/Inklusionen + - Dynamische Anpassungen ohne manuelle JSON Bearbeitung +- Zweck : Fehlerbehandlung bei Inkompatibilitäten Apps sowie anwendung auf noch nicht in JSON inklusierten App whitelist + diff --git a/JOURNAL.md b/JOURNAL.md index 86ab3ee..73e77f9 100644 --- a/JOURNAL.md +++ b/JOURNAL.md @@ -1,3 +1,5 @@ +[Zurück zu README.md](README.md) + # Moduljournal - Enthählt - Tägliche Notizen zu getätigten Arbeiten, Gedanken Prozessen sowie Gelerntem währen Wiederhulung von Modul 306 - Kleinprojekte im eigenen Berufsumfeld abwickeln, ungefiltert @@ -18,11 +20,11 @@ Okeh zu erst mal muss ich was auswählen als "Projekt" Vorschläge? : Abwägung : (Einschätzung: 1-5, 1 = Garnicht geignet, 5=Perfekt geignet) -- BeepZone : Mag ich zwar sehr aber ist sehr sehr grosses Projekt welchem noch mehr als nur ein bisschen feinschliff an Core Componenten benötigt deswegen last prio - - Einschätzung: 2 +- BeepZone-Stack : Nach analyze eines der mir am nähsten liegenden Projekten welches wenig Risiken mit sich bringt da ein grossteil der Kenntnisse schon vorhanden sind und grossteil der Grundbausteine schon stehen, Zudem ist dies nicht nur ein Persönlich Motiviertes Projekt sondern wird zudom noch dringend im Berufsumfeld benötigt. + - Einschätzung: 5 - SwiftEdging : So halb wichtig brauch ich weil ich sonst wahnsinig werde aber ist Objective-C, kenn ich somit nicht so gut. Wäre gut für mein lieblings Tool namens Wekan. - Einschätzung: 3 -- Sigma-Mini-IP-Button : Relativ wichtig im Berufsumfeld und dringenst notwendig, Ist jedoch sehr abhängig von nicht finalisiertem Sigma-Mini-Repeater Projekt, Würde sich jedoch als guter Kandidat stellen da so mehr Projekt einteilungs Objekte möglich sind. +- Sigma-Mini-IP-Button : Relativ wichtig im Berufsumfeld und auch zeitnahe notwendig, Ist jedoch sehr nahe daran schon Finalisiert zu sein. - Einschätzung: 4 Definition Phase Notizen : @@ -61,7 +63,7 @@ Muss mich endlich entscheiden was ich als Projekt nehme, auch wenn meine Vorlieb - Machbarskeitanalyze -- - PSP ++ -### Projektentscheid +### Initialer Projektentscheid Es wurde SwiftEdging als Projekt gewählt da es theoretisch ein guter Kandidat für mein geliebtes Wekan darstellen würde, Grossteil des Codes schon existiert und via Privater Git Commits nachvollziehbar gebaut wurde. Zudem bringt es auf persönlicher Ebene viel Enthusiasmus und Interesse als Motivator bei der später kommenden Umsetzung mit sich was sich auch auf die Planung abwälzt. ### Projektbeschreib Initialisierung @@ -69,5 +71,8 @@ Vorerst müssen laut LP die Basics aufgenommen werden mit der Perspektive davon - [X] Aufschreiben Ziel des Projektes (Ausgangsituation, Ist und Soll) - [] Aufschreiben Diskrepanz / Was ist jetzt zu tun. (So in etwa das Ziel, "Was musst gemacht werden und so" "Alle Elemente sollen Einheitlich aussehen") +## 2025-12-09 +### Abänderung Projektentscheid +Nach analyze Machbarkeit wurde sich umentschieden den Beepzone-Stack zu Finalisiern (Mein Inventar System), dies darauf das SwiftEdging nicht zuverlässig/sinnvoll machbar wäre und im nächsten MacOS update höchstwahrscheinlich nicht mehr anwendbar wäre (beta release von MacOS 26.2 macht umsetzung momentan unmöglich), Die zuvor geschrieben SwiftEdging-Projektplanung in Abgaben wurde in den Ordner Archiv/Projektplanungen/ verschoben und es wird eine neue erstellt im Abgaben Ordner diff --git a/README.md b/README.md index b3d389c..a551b9e 100644 --- a/README.md +++ b/README.md @@ -13,7 +13,7 @@ Ungefilterte datierte Notizen welche während des Modules aufgeschrieben wurden: Markdown, Drawio und Exportierte PDF Datein welche Teil der Abgabe sind (sowie ggf. weitere ressroucen wie zB. Word Datein) können im [Ordern Abgaben](Abgaben/) gefunden werden. #### Projektplanung : -- Markdown (Work In Progress): [Abgaben/SwiftEdging-Projektplanung.md](Abgaben/SwiftEdging-Projektplanung.md) +- Markdown (Work In Progress): [Abgaben/SwiftEdging-Projektplanung.md](Abgaben/BeepZone-eGUI-Projektplanung.md) - PDF : (Finale Version welche vor Abgabe erstellt wird) ## Eigenständigkeitserklärung -- cgit v1.2.3-70-g09d2