Hallo Lukardo,
hast Du Deine Anpassungen ausschließlich in der
_custom_configuration.scss vorgenommen?
Wenn ja, dann gibt bitte ihren jetzigen Inhalt in der
Pastebin ein oder füge dirt die komplette Datei ein und verlinke das dann hier, damit ich ihn mir mal anschauen kann - es hängt bei diesen Style auch etwas davon ab, was wo geändert und wie es gemacht wurde
Vielleicht kurz eine Info zum Unterschied in der Funktion zwischen der
_custom_configuration.scss und der
_custom.scss, am besten vielleicht am Beispiel der Farbgebung:
Es sind aktuell 4 Farbschemata vorbereitet, für die jeweis ein "Basisfarbwert" vorgegeben ist: für das Schema "blue" wäre dies zum Beispiel der Farbcode
#0B2958.
Dieser Basiswert wird dann einer Variablen (hier:
$col_base) zugewisen, die dann als "Ausgangswert" diverser Berechnungen genommen wird, in denen die weiteren Farbwerte ermittelt werden, die innerhalb eines Schemas für die einzelnen Elemente zum Einsatz kommen sollen.
Es werden dabei auch keine "fixen" Farbcodes ausgeworfen, sondern die so berechneten Werte weiteren, sekundären, Variablen zugewiesen. Erst diese werden dann im eigentlichen CSS anstelle fester Farbcodes eingesetzt und beim Kompilieren durch den berechneten Farbcode ersetzt.
Alle im CSS des Styles verwendeten Variablen und SASS-Funktionen, die grundlegenden Berechnungen vornehmen, sind in der
_style_configuration.scss angelegt und definiert. Diese Datei stellt somit eine Art "funktionale Steuerzentrale" dar, weswegen an ihr auch nichts geändert werden sollte.
Um jetzt die Vorgabewerte der Basisvariablen anzupassen (Bsp.: um auf das Schema "red" umzuschalten), ohne in die
_style_configuration.scss einzugreifen => hierfür ist die Datei
_custom_configuration.scss vorgesehen.
Du fügst dort bei Bedarf, wie in den bereits enthaltenen Beispieldaten angezeigt, die für die jeweilige Variable alternativ vorgesehenen optionalen Werte ein.
Hier also: statt
blue dann
red.
Dies sorgt jetzt dafür, dass in den Berechnungsfunktionen für die sekundären Farbwerte der Farbcode für "red" (#48100C) als Ausgangswert verwendet wird statt, wie bisher der für "blue".
Solltest Du eigene SASS-Funktionen erstellen woillen, also welche, die bisher noch nicht im Style vorhanden sind, dann machst Du dies ebenfalls in dieser Datei.
Der Hintergrund für diese, auf den ersten Blick vielleicht umständlich aussehende, Vorgangsweise ist, dass somit eine klare, auf Dateiebene stattfindende Trennung zwischen "Basiscode" des Styles und den eigenen Codeanpassungen gewährleistet wird.
Wenn Du jetzt aber gezielt
einzelne Klassen des CSS oder bei einzelne Klassen die Werte bestimmter Eigenschaften anpassen willst (= die vorgegebenen oder berechneten Werte überschreiben), dann machst Du dies in der
_custom.scss.
Es ist das gleiche Vorgehen wie in anderen, "klassisch" aufgebauten Styles auch, nur eben in einer gesonderten Datei, die explizit hierfür vorgesehen ist.
[Da somit alle eigenen = "custom" CSS-Anpassungen in zwei
_custom*.scss Dateien zusammengefasst sind, reicht es, diese bei einem Styleupdate
nicht zu überschreiben, um alle diese eigenen Anpassungen zu erhalten - es entfällt also das manuelle Nachtragen der eigenen Änderungen
]
-----------------
@Joyce&Luna
Joyce&Luna hat geschrieben:Dies ist eine Alpha Version
Stimmt, er ist ja auch noch nicht fertig entwickelt: einige Features fehlen noch, andere sind zwar in den Grundzügen fertig, müssen aber noch "feingetunt" werden - und andere können sich nochmals ändern.
Die Sache mit den Farbschemata funktioniert, nur die Ausarbeitung
ins Detail hat noch nicht stattgefunden: es fehlen noch diverse Berechnungen für weitere sekundäre Variablen.
Momentan bin ich auch am überlegen, dieses Konzept nochmals zu überarbeiten, um es schlanker zu machen.
Auf eigene Anpassungen dürfte dies aber kaum Auswirkungen haben, da die anpassbaren Basisvariablen erhalten bleiben werden.
Joyce&Luna hat geschrieben:und so noch gar nicht für das Liveboard zu gebrauchen.
Dies würde ich jetzt aber anders formulieren: da er sich noch in Entwicklung befindet und sich noch einiges ändern kann, da noch Features fehlen bzw. einige noch nicht vollständig (= "final") umgesetzt sind, kann das natürlich optische Auswirkungen beim Einsatz in einem Live-Board haben, wenn eine neue Revision aufgespielt wird.
Dessen sollte man sich dann auch bewusst sein - nur: "nicht zu gebrauchen" passt da nicht so richtig. Er ist "nicht zu empfehlen", wenn man nach einem Style sucht, an dem man, einmal auf die eigenen Bedürfnisse angepasst, keine Änderungen mehr vornehmen will und der "fertig" und ohne Ecken und Kanten ist.
Joyce&Luna hat geschrieben:Da muss du entweder selber Hand anlegen oder halt warten bis Melmac soweit ist.
Was aber bei jedem Style der Fall ist, auch validierten.
Joyce&Luna hat geschrieben:Jetzt speziell hier für jeden einzelnen zu diesem Style Support zu leisten, wäre ein Fass ohne Boden.
Es bist ja auch nicht Du, der im Ernstfall den Support leisten muss; und was ein "Fass ohne Boden" ist, darfst Du daher ruhig mir selbst überlassen
Was wäre, wenn ich dies als Chance sehe, hier feed back zu erhalten, auf Fehler, Ungereimtheiten oder nicht berücksichtigte Funktionen hingewiesen zu werden?
Der Style ist noch in Entwicklung, stimmt, mit Sicherheit auch nicht fehlerfrei und in einigen Bereichen noch "lückenhaft umgesetzt" - aber gerade deswegen ist es absolut okay, sogar wichtig (!), dass hier solche Fragen gestellt werden!
Ich mache dies hier ja nicht, um mich irgendwie als toll bestätigt zu sehen: letztendlich, neben dem Lerneffekt, der dabei auch für mich anfällt, soll es ein Style werden, der ein paar Möglichkeiten mehr bietet und dennoch in grundlegenden Dingen, die immer wieder nachgefragt werden, im Rahmen des sinnvoll machbaren möglichst einfach anzupassen ist.
Dazu braucht es aber die Perspektive des Anwenders, der letztendlich mit diesem Style arbeiten will/muss: ich bin jedem dankbar, der ihn testet und mir feed back gibt.
![[ externes Bild ]](https://img1.picload.org/image/rwdogapw/screenshot.png){kind=link}