Kritische Würdigung, Versuch einer Vereinheitlichung
Halllo zusammen,
ich bin seit 22 Jahren mit (open)SuSE unterwegs und freue mich sehr, als ich Myrlyn vor einiger Zeit entdeckt habe.
VIELEN DANK und LOB an Stefan für das tolle Programm!
YaST wird leider sterben (müssen), aber Myrlyn als Fortsetzung ist eine würdige Ausnahme. Es läuft super performant und ist sehr anpassbar. Darauf möchte ich anspielen. Da ich privat und beruflich mit Oberflächen und Icons zu tun habe, habe ich einige Verbesserungsvorschläge erarbeitet, damit das Tool richtig ins Rampenlicht treten kann.
Es geht mir in erster Linie nicht um das Logo oder das Anwendungs-Icon in einem oder anderen System. Ich meine vor allem die Benutzeroberfläche und die Benutzerfreundlichkeit.
Ausgehend von dem Ist-Zustand möchte ich Folgendes festhalten:
Myrlyn’s Icons (und ihre Farben) sind eine Mischung aus den Projektsymbolen (wrench, package-supported, hamburger, empty-40x22.png) und Fall-back-Themen-Icons („die restlichen Icons“). Wird im aktiven systemseitigen Icon-Thema ein referenziertes Icon aufgerufen, wird dieses bevorzugt angezeigt. Wird keines im Thema gefunden, gibt es einen Fall-back auf das Projekt-Ikon. Somit endet die Aufgabe des Entwicklers. So weit so gut.
Das Problem: kommt das Programm zum Einsatz in unterschiedlicher Umgebung, gibt es Design-Fehler bis hin zur Unmöglichkeit, eine Funktion zu nutzen, da sie nur schwer oder gar nicht gefunden werden kann. Das schreckt potenzielle neue Benutzer ab. Auch der hohe Konfigurationsaufwand ist nicht zu unterschätzen (z.B. Desktop-Umgebung für den Benutzer root – wenn man Myrlyn so nutzt, versteht sich).
Ich möchte einige Design-Fehler zeigen (die eigentlich nicht dem Entwickler selbst zu “verdanken” sind, sondern sich aus der Konstellation des Systems ergeben.
Ich habe einige Umgebungen “getestet”, vor allem KDE Plasma mit SuSE Tumleweed und XFCE (wie der Entwickler selbst, um den Fehlern auf die Schliche zu kommen)
Ich möchte hier nicht explizit auf eine “Lösung” der einzelnen Fehler hinarbeiten, denn die gibt es in dieser Konstellation nicht…
1. Verweise auf Theme-Icons
Das Ergebnis ist mit Paketen-Status ist ziemlich verwirrend.
Myrlyn “out-the-box” als Benutzer und Root.
- “Fehler” im Icon-Design - Breeze-Leute würden sagen, das ist ein Feature.
Die coden die Icons mit blauen Emblems wie folgt
<?xml version="1.0" encoding="UTF-8"?>
<svg height="16" width="16" xmlns="http://www.w3.org/2000/svg">
<style type="text/css" id="current-color-scheme">.ColorScheme-Accent { color: #3daee9; } .ColorScheme-Text { color: #fcfcfc; } </style>
<rect style="fill:currentColor;fill-opacity:1;stroke:none" class="ColorScheme-Accent" height="16" rx="2" width="16"/>
<path style="fill:currentColor;fill-opacity:0.6;stroke:none" class="ColorScheme-Text" d="M2 0C.892 0 0 .892 0 2v12c0 1.108.892 2 2 2h12c1.108 0 2-.892 2-2V2c0-1.108-.892-2-2-2zm0 1h12c.554 0 1 .446 1 1v12c0 .554-.446 1-1 1H2c-.554 0-1-.446-1-1V2c0-.554.446-1 1-1z"/>
<path d="M7 2v5H2v2h5v5h2V9h5V7H9V2z" fill="#fff"/>
</svg>
Das ist absoluter Quatsch, denn class=“ColorScheme-Accent” für “Blau” bedeutet, dass alle Icons mit der blauen Zugabe mit der Benutzer-Highlight-Farbe gefüllt werden. Habe ich also auf meinem Desktop “mein Grün” als Akzentfarbe gesetzt, werden meine blauen Emblems grün. Und da ich als root die Akzentfarbe “Rot” gewählt habe, werden die System-Icons plötzlich rot. Das ist mir erst bei Myrlyn so bewusst geworden, was die da machen. Ich habe es im alten guten YaST nachgeschaut, die haben (vermute ich) im YaST die Farbe abgefangen und machen es einheitlich grau, warum wohl? 
Man hat hier nur die einzige Möglichkeit, in User-Verzeichnissen ~/.local/icons/breeze(-dark) das zu korrigieren. Aber dies ist bei anderen Icons auch so… Die Designer unterscheiden nicht metaphysisch, dass Farbe nicht nur Design, sondern auch Inhalt ist.
Also es hilft nur bei den Betroffenen Icons (eigentlich bei ALLEN Pakage-Icons) die Farben zu persistieren. Orange und Grün ändert sich eigentlich auch, welches Thema man nimmt. Das wäre, als wenn man Ampel-Farben designen würde.
Man muss die Klassen so wegkodieren, zu (bei Blau)
fill="#3daee9"
korrigiert sieht es dann so aus:
Der Code beim Status “package-installed” ist fehlerhaft, oder Breeze-Thema ist fehlerhaft, denn es gibt im Thema kein Icon namens “package-installed” , sondern “package-installed-updated”. Diesmal haben die Jungs von SuSE gut aufgepasst, und den Namen so benutzt. Sogar es steht so im Myrlin (status-filter-view.ui Zeile 203) und wird im Designer nicht angezeigt, weil im Code auf den neuen Namen “package-installed” (welcher natürlich logischer ist) verwiesen wird.
- Eigene Icons des Projekts, die im Thema gar nicht vorhanden sind.
→ wrench, hamburger, package-supported, download-done, download-ongoing sind zwar auf der Maske, aber unsichtbar und nicht veränderbar von dem Benutzer, denn diese sind aus der Thema-Prüfung ausgeschlossen. Dazu kommt der png-Platzhalter in Weiss. Ich habe an dieser Stelle ein Uhr-Icon platziert.
Prinzipiell sind die Icons 40x22 fehl am Platz, die sind zu einem unsichtbar, zum zweiten falsch skaliert. Ich habe hier 32x32 verwendet.
Ich will hier auf weitere Details nicht eingehen, ich mache einen kurzen Film mit dem kompletten “Dark Plasma Breeze Design”.
ZUSAMMENFASSUNG
Man kann die “Design-Fehler” nicht beheben, ohne zu definieren, wie die Oberfläche konfigurierbar sein soll. Es muss auch der Code angepasst werden.
Es gibt folgende Ansätze, die zu diskutieren sind und ich mache meine Einschätzung.
- Welche Umgebung supporten wir?
- Wie viel am Design soll der gemeine User schrauben dürfen?
- Wie viel Aufwand wollen wir bei der Entwicklung treiben?
- Wer macht das, welche Ressourcen haben wir zur Verfügung?
zu 1.
Es soll möglich sein, die Icons in KDE (Breeze), GNOME/XFCE (Adwaita) und “DEFAULT” korrekt darzustellen. Mit Default meine ich “altes YaST”
zu 2.
Theme (dark,light) im System → das soll (“auto” sein wie jetzt), zusätzlich soll er ein Icon-Thema wählen. Wenn es geht, soll er auch Theme über Myrlyn-Oberfläche für Myrlin auswählen.
zu 3.
das kann ich nicht einschätzen, bin kein Entwickler im engen Sinne.
zu 4.
Design-technisch ist es relativ einfach, ich kann die Themensets für jedes Design vorbereiten.
- also 3 Themen-Sets: Breeze/Adwaita/Default
- für jeden Set brauchen wir 2 Varianten (dark/light)
Warum? Es ist nicht möglich, gleichzeitig 2 unterschiedliche Klassen für dasselbe Element zu codieren.
In Breeze geht es z.B. über Color-Scheme-Text,
<style type="text/css" id="current-color-scheme">.ColorScheme-Text { color: #fcfcfc; } </style>
Über die Klasse kann das Design verändert werden. Ob es in Adwaita und XFCE mit festem “fill=xxxxx” geht, dark/light umzukehren, weiss ich nicht.
