Closed Baxxy13 closed 2 years ago
Bei mir ist es andersrum. Bei mir sind eher die Namen kurz und der Inhalt (manchmal) länger. Daher hatte ich die Aufteilung gewählt.
Was mir eh nicht gefällt ist, dass es mit Zeilenumbruch gleich sehr unübersichtlich wird.
Wie wäre es mit trennenden Strichen oder wechselndem Hintergrund?
Also Trennstriche wären vermutlich nicht so meins. Aber so ne hell/dunkel Abstimmung wie an anderen Stellen könnte ich mir gut vorstellen. Müsste man mal sehen.
Bei mir sind eher die Namen kurz und der Inhalt (manchmal) länger.
Dito. Wobei mich da noch nie gestört hat, wenn der Inhalt umgebrochen wird.
Also hell/dunkel sähe so aus. Mit dem Nachteil, das der Trennstrich auch ein "Schatten" hat und ich den nicht wegbekomme, es sei denn ich gebe dem Element direkt im Quellcode eine Eigenschaft mit. Aber über CSS-Selektoren bekomme ich ihn nicht gepackt. Oder hat da noch einer eine Idee um diese Zeile eine bestimmte Eigenschaft zu verpassen:
<tr style="height:0.5em;">
Ansonsten reicht nämlich ein einfaches
.startPageInfo tr:not([name]):not([id]):nth-child(even) {
background-color: #f0f0f0;
}
EDIT: #f0f0f0 als background passt besser
Ich glaube, ich habs. Ich würde aber dem rechten Rand noch etwas Luft geben
Sieht ja ganz gut aus.
Nur RaspMatic-Update bleibt weiß? Wegen dem farbigen Link?
Sind das jetzt 50% linke Spalte?
vertical-align: middle
mal testen?
Nur RaspMatic-Update bleibt weiß? Wegen dem farbigen Link?
Mist, das hatte ich noch gar nicht sehen. Nein, die haben eine ID...Die muss ich dann noch extra behandeln. Mal schauen
Width habe ich nun 48% eingestellt - ach, Jens wollte ja keine krummen Werte. Gut, nehmen wir 50%
Middle probiere ich gleich auch nochmal aus
Mit valign middle, padding rechts und links und eingefärbtem Update Hinweis. Ich denke so gehts. Wenn es den Segen des Chefs bekommt, könnte ich einen PR machen. Da brauche ich aber nochmal Unterstützung. Jens hat mich da nochmal zum nachsitzen geschickt.
Also mir gefällts. Müssen dann bloß noch gucken ob die (nicht immer sichtbare) "Geräte-Update" auch korrekt behandelt wird.
Ja, das habe ich schon berücksichtigt
Wenn es den Segen des Chefs bekommt, könnte ich einen PR machen.
Noch bin ich von der Änderung/Anpassung noch nicht so überzeugt. So ganz gefällt mir das noch nicht mit den wechselnden Hintergrundfarben. Mach aber gerne schon einmal den PR und dann kann man das ich selbst das schon einmal testen.
Mir persönlich gefällt die Even/Odd Farbmarkierung auch nicht so recht. (Hell)grau steht für mich in der WebUI immer für irgendwas "deaktiviertes".
Von den Abständen her ist es aber top
Meine Startseite sieht rechts so aus:
Meine Startseite sieht rechts so aus:
Das sieht IMHO sehe gut aus. Kannst gerne mal ein PR dazu machen oder das diff hier zeigen, dann kann man darauf basierend sicherlich das Eine oder Andere einarbeiten.
@jens-maus Hmm, mit der neuen create_patches.sh
werden 43 Patche bei mir nicht erzeugt (z.B. 0099, 0100, 0101).
Bis einschließlich 0098 werden sie erzeugt. #1498
Sehr schöne Idee mit der "Komprimierung" der Standard-Informationen. Die Abgrenzung durch eine Linie gefällt mir auch gut.
Da frage ich mich doch glatt ob es "gut" wäre die DC/CS Balken in den "festen Informationsbereich", also oberhalb der eigenen SysVars zu legen. Diesen "festen Informationsbereich" könnte man dann vielleicht fixiert machen und nur den unteren Teil (ab der Trennlinie) scrollbar. Aktuell wird ja die ganze rechte Seite gescrollt wenn genügend eigene SysVars angepinnt sind, so dass DC/CS erst nach dem runterscrollen zu sehen sind.
Diesen "festen Informationsbereich" könnte man dann vielleicht fixiert machen und nur den unteren Teil (ab der Trennlinie) scrollbar. Aktuell wird ja die ganze rechte Seite gescrollt wenn genügend eigene SysVars angepinnt sind, so dass DC/CS erst nach dem runterscrollen zu sehen sind.
Klingt auch interessant. Jedoch wird es Leute geben, die möchten lieber alle SVen sehen statt der DC/CS-Bars. Mir persönlich sind die Balken im normalen Betrieb auch relativ egal. Gegenvorschlag wäre statt einer max. Box-Größe für die SVen eine "Zuklapp"-Möglichkeit. Aber was solche Wünsche betrifft halte ich mich eher zurück, das ist wieder Design/Style, da bin ich sowas von raus -.- Ich kann nur "function first". :D
Alles Gute Ideen. DC/CS würde ich aber auch "unten" lassen. Im Normalfall benötigt man die Anzeigen nciht. Womit ich aber weiter hadere ist die Unübersichtlichkeit, die entsteht wenn SV-Name oder Inhalt umgebrochen wird. Für solche Fälle sind eben Linien oder wechselnde Hintergründe üblich. Linien würden vermutlich zuviel Unruhe rein bringen und man müsste der jeweiligen Zeile mehr Platz geben (sonst sieht es aus wie jetzt im Systemprotokoll). Daher bleibt eigentlich nur die farbliche Markierung. Das eine farbliche Unterlegung in der WebUI für "deaktiviert" steht, sehe ich nicht so. Zumindest ist mir das noch nciht aufgefallen.
Zum PR: Jens schrieb:
keine PR basierend auf dem "master" branch einreichen. Jeder neue PR braucht einen neuen/frischen/separaten Branch
Bedeutet ich lege in meinem Fork einen neuen Brach an? Gibt es da noch was zu beachten? Namensgebung oder so?
nicht einfach ein *.diff irgendwo ablegen im Repository. Das war prinzipiell nicht richtig. Schau dir an wie Die WebUI Patches aufgebaut sind von der Directorystruktur
Da komme ich nciht klar. Wo muss ich was hinlegen? Ich finde in den Commits Pfade wie buildroot-external/patches/occu/ occu/WebUI/www/... Das Prinzip ist mir aber noch nichts 100% klar. Und wie kriege ich die Dateien (welche) da hin, wo sie hin gehören?
und dann musst du create_patches.sh nutzen um das *.patch file automatisch generieren zu lassen.
Was ist das und wie bedient man das?
Meine Startseite sieht rechts so aus:
Es geht sogar noch kompakter:
Der feste kompaktere Informationsteil sieht gut aus.
Aber mir ging es primär um die Ansicht der eigens hinzugefügten SysVars! Diese ist ja weiterhin unverändert. Was ich so herausgelesen habe ist, das die linke Spaltenbreite (SysVar-Namen) dann doch mehr als 30% sein dürfte (40 -50% ?). Außerdem sieht meiner Ansicht nach die "Tabelle" mit vertikal zentrierten Werten ruhiger aus.
Hier nochmal 2 aktualisierte Screenshots:
Idealerweise wird das Ticket wieder geöffnet.
Ich würde gerne hierfür einen PR erstellen:
vorher
nachher
@Baxxy13 kannst Du mich dabei unterstützen?
Der Vollständigkeit halber... kurz mit Michael telefonisch das Thema besprochen und festgestellt das wir mal eine "Schulung von einem Meister" brauchen.
Also ich gebe es auf. Ich muss nun irgendwelche Konflikte resolven um überhaupt den Fork zu aktualisieren. Ich wollte doch nur ein bisschen helfen. Also hier das Diff, mögen damit Eingeweihte tun was immer notwendig ist.
Also ich gebe es auf. Ich muss nun irgendwelche Konflikte resolven um überhaupt den Fork zu aktualisieren.
Das kommt daher das du Git falsch bedient hast bzw. deinen letzten PR basierend auf deinem master branch eingereicht hast. Wie ich schon gesagt hatte: master/main branch nutzt man nur für das aktualisierung mit upstream (d.h. dem repo von dem man den fork gemacht hat). Das beste ist also du löscht deinen fork wieder, legst ihn neu an und fasst in zukunft den master branch nicht mehr mit eigenen änderungen an, sondern nutzt den nur um änderungen von RaspberryMatic zu mergen, dann wieder nen branch zu machen auf dem du PR basieren lässt. Sowas ist eigentlich common-sense in der Softwareentwicklung und ich kann dir nur empfehlen dich mal in das Thema Git einzuarbeiten.
Der Vollständigkeit halber... kurz mit Michael telefonisch das Thema besprochen und festgestellt das wir mal eine "Schulung von einem Meister" brauchen.
Das einzige was ich anbieten kann ist, die Methode wie man WebUI Patches generiert ausführlicher zu dokumentieren in der Entwicklungsdokumentation zu RaspberryMatic. Eine git Schulung wird es dazu aber nicht geben, denn das muss sich bitte jeder der hier mitarbeiten will schon selbst als basiswissen aneignen wie man git bedient und was ein fork, branch, pullrequest ist und was da technologisch aus passiert und dahintersteckt und auch wie man GitHub bedient.
die Methode wie man WebUI Patches generiert ausführlicher zu dokumentieren in der Entwicklungsdokumentation zu RaspberryMatic
Das wäre sehr hilfreich, genau da hapert's bei mir besonders.
Der eigentliche "Umgang" mit GitHub ist ja nicht so schwer, da findet man ja auch genug "Schulungsmaterial".
Das kommt daher das du Git falsch bedient hast bzw. deinen letzten PR basierend auf deinem master branch eingereicht hast.
Ich habe mich genaustens an deine Anweisungen gehalten... Naja, Sender <=> Empfänger. Du hast halt keine Details erwähnt, sondern setzt immer alles als bekannt vorraus. Dann kommt bei Eigenintiative halt schon mal was komisches bei raus.
Den Fork zu löschen, war mir auch schon eingefallen. Nur gibt es nirgends einen Delete Button. EDIT: nach der 4. Seite die erklärte wie einfach es ist einen Fork zu löschen, habe ich eine gefunden die offensichtlich auch die aktuelle UI von GitHub beschreibt. Weg isses
Das einzige was ich anbieten kann ist, die Methode wie man WebUI Patches generiert ausführlicher zu dokumentieren in der Entwicklungsdokumentation zu RaspberryMatic.
Das wäre schon ein Riesenschritt nach vorne.
Also ich bin etwas weiter. Vielleicht kann einer der "Sehenden" mal in den Draft reinschauen. Ich denke ich habe jetzt schon mal die Anforderung "neuer Branch" geschafft. Aber ich kann kein neues Verzeichnis anlegen um dort eine Dateistruktur aufzubauen. Es gibt neu "Add file" aber kein "Add Dir".
Aber ich kann kein neues Verzeichnis anlegen um dort eine Dateistruktur aufzubauen. Es gibt neu "Add file" aber kein "Add Dir".
Hmm, GitHub ist doch nur eine Weboberfläche für ein Git Repository und klar kannst (und sollst du auch nicht) alles mit dem Webbrowser machen! Du legst nur via GitHub WebUI den Fork an und dann nimmst du den Git Klienten deiner Wahl (ich mache alles von der Kommandozeile) und dann checkst du das repository aus und arbeitest in Git natürlich weiter und auch am besten innerhalb einer Unix/Linux-Umgebung damit du dann auch create_patches.sh
aufrufen kannst usw. usw.
@jp112sdl kannst Du eine fertig eingerichtete VM zur Arbeit mit GitHub zur Verfügung stellen, die man in VirtualBox starten kann? Wenn ich mich jetzt noch in die Auswahl einer Linux Distribution, Installation und Konfiguration von Linux, etc. einarbeiten muss, dann verschiebe ich die Beteiligung an RM lieber bis zur Rente. Ich kann nicht ganze Tage/Nächte für sowas aufwenden, da leidet etwas das Familienleben drunter.
Ich kann nicht ganze Tage/Nächte für sowas aufwenden, da leidet etwas das Familienleben drunter.
Was soll ich da bitte sagen mit drei Kindern? ;-)
@MichaelN0815 So, hab nun die IMHO relevanten Dinge aus deinem PR Draft kurzerhand mal übernommen (siehe https://github.com/jens-maus/RaspberryMatic/commit/4e07535f8ec270068204ed0c1ad1aa6c8772a4eb). Das sollte so nun passen bzw. erscheint mir nun sich besser zu integrieren. Das vertical-align: middle
hab ich explizit weggelassen bzw. nun top genommen, das padding noch angepasst und auch das veränderte width weggelassen weil es mir so besser erscheint. Hoffe du kannst damit so leben.
Ist viel versprechend. Ich schau mir das morgen an. Danke!
@MichaelN0815 Ich werd hier grad erstmal keine große Hilfe sein können aufgrund unschöner privater Ereignisse. Sorry :/
Das hört sich nicht gut an. Ich wünsche Dir auf jeden Fall ganz viel Kraft das zu bewältigen.
Is your feature request related to a problem? Please describe. Obwohl die auf der Startseite angepinnten SysVars inzwischen wieder ansehnlich sind, sehe ich noch "Verschönerungspotenzial". Mir ist klar das vermutlich jeder eine andere Sicht auf die Dinge hat und auch das das Anzeige-Ergebnis stark abhängig von der eigenen Monitor-Auflösung ist. Aktuell (Nightly 3.61.4.20211103) ist die linke Hälfte (SysVar-Namen) auf max 30% limitiert. Die Frage die ich mir stellte... was braucht eigentlich mehr Platz, der Name oder der Wert? Also mal in mein Live-System geschaut und festgestellt das meine Benamung (so gut wie) immer länger ist als der zugehörige Wert. Was natürlich primär daran liegt das ich mir hauptsächlich Zahlenwerte und Logikvariablen (mit meist kurzem Logik-Bezeichner) anzeigen lasse. Texte als Werte kommen hier so gut wie nicht vor. Trotzdem enthalten die folgenden Screenshots längere Texte damit man die Gesamtansicht besser erfassen kann. Auch wenn so lange Bezeichner/Texte wohl recht unrealistisch sind. Die Screenshots sind im Vollbild auf einem 1080p Monitor mit Nightly 3.61.4.20211103 und Firefox 94.0 erstellt.
Ausgangslage:
Describe the solution you'd like
Namensspalte max 45%:
Namensspalte max 45% + vertical-align: middle
Describe alternatives you've considered ...
Additional context Für mich sieht der letzte Screenshot "am ruhigsten" und übersichtligsten aus. Da ich das nur über die Broser-Dev-Tools angepasst habe kann ich leider kein diff bereitstellen.