Ankündigung

Einklappen
Keine Ankündigung bisher.

Farben

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Farben

    Ich dachte ich hätte hier schon mal was gelesen, aber über due Suche habe ich es nicht gefunden - naja war vielleicht in einem anderen Bereich.
    Warum gibt es in Edomi eine Trennung der Farben in Vorder und Hintergrund ? Würde es nicht genügen ein Verzeichnis "Farben" mit Ordner egal ob Hinter- oder Vordergrundfarbe.
    Ich habe mir ein Set von Farben erzeugt (Vordergrund) und wollte zum testen diese auch für den Hintergrund verwenden , leider muss ich diese nun nochmal anlegen da ja das kopieren aktuell auch nicht geht (Ordner Vordergrundfarbe -> Hintergrundfarbe).
    Zuletzt geändert von HappyJack; 15.06.2017, 15:03.
    ------------
    Dieter

    #2
    Habe ich mich auch schon öfters gefragt. Vlt. gibt's eine Möglichkeit, das einfach in der Datenbank rüber zu kopieren.

    Kommentar


      #3
      CSS unterscheidet zw. Vorder- und Hintergrundfarben (je nach Einsatzzweck). So kann man einem Font z.B. keinen Farbverlauf zuweisen (Hintergrundfarbe), etc...
      EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)

      Kommentar


        #4
        Ich verstehe den technischen Hintergrund. Aber die meisten Farben werden vermutlich rein als einfache Farbwerte erfasst. Diese Farben wären ja dann sowohl für Vorder- UND Hintergrund verwendbar.
        Man könnte ja z.B. die Farben zusammenfassen und mit einem zusätzlichen Flag als "Generisch, Vordergrund, Hintergrund" kennzeichnen. Beim Typ generisch könnte man ausschliesslich normale Farbwerte eingeben, keine weiteren CSS-Befehle wie Farbverlauf etc.
        Beim Zuweisen einer Farbe wird entsprechend dem Zielelement dann nur die Farben angezeigt, welche dafür auch passt. (Die anderen wären dann ausgegraut)
        Somit wird gewährleistet, dass man nicht falsche CSS-Werte zuweisen kann, aber gleichzeitig bleiben die Farben an einem Ort. Und eine einfache Farbe (z.B. rot, generisch) würde nur einmal erfasst werden müssen.
        Hätte dann auch den Vorteil, dass man die einfachen Farben nur an einem Ort ändern müsste, um es für alle zugewiesenen Element gültig zu machen. Wenn ich z.B. die Rot-Farbe etwas dünkler definiere, gilt dies für alle Elemente, die diese Farbe zugewiesen haben (also auch Vorder- und Hintergrund). Ansonsten müsste ich an zwei Orten die Rot-Farbe ändern.
        Klar, ist für dich mit etwas Aufwand verbunden. Aber wäre für die Zukunft sicher eine sinnvolle Verbesserung. (Prio low)

        Kommentar


          #5
          Mal im Ernst, wie viele Farben verwendet ihr denn, dass dieser (einmalige!!!) Kopieraufwand schon zu viel ist...?

          Kommentar


            #6
            Kopieren geht nicht!
            ------------
            Dieter

            Kommentar


              #7
              Na er meint natürlich kopieren des Farbwertes in ein neues Element...
              Kind regards,
              Yves

              Kommentar


                #8
                Zitat von MrMirror Beitrag anzeigen
                Mal im Ernst, wie viele Farben verwendet ihr denn, dass dieser (einmalige!!!) Kopieraufwand schon zu viel ist...?
                Mir gehts prinzipiell mehr um die (unnötige) Redundanz. An zwei verschiedenen Orten ein #FF0000 zu führen, ist nicht tragisch, aber müsste nicht sein. Zudem ist es immer fehleranfällig (in diesem Fall rein optisch), weil du an zwei Orten eine Farbe mit z.B. dem Namen "Rot" definiert hast. Willst du dann das reine rot doch mal etwas ändern, z.B. auf #FF5A5A, dann musst du das an zwei Orten machen. (Und dies gilt dann für alle anderen Farben auch.)

                Christian hat ja Edomi zuerst für sich programmiert und somit ist das aktuelle Farben-Management rein aus technischen Gründen so realisiert worden. Was ja funktioniert und für ihn und vielen anderen auch reicht.
                Aber rein aus Sicht der Benutzerfreundlichkeit (UI-Führung) gibt es sicher eine bessere Umsetzung. Mir ist das beim Benutzen schon mehrfach aufgefallen. Nicht wirklich störend, eher zur Kategorie "das wäre schön, wenn..." gehörend.

                Meiner Meinung nach sollte eine Software zuallererst technisch einwandfrei funktionieren. Erst danach kommt dann die Benutzerführung, die das Bedienen soweit als möglich erleichtert und Redundanzen, Fehleranfälligkeiten und repetive Schritte vermindern sollte. Dies gilt auch für Software, die eher von technisch orientierten Leuten bedient werden soll. Auch diese sind bequem und sind froh um jede Erleichterung.

                Ich weiss, dass Christian das manchmal etwas anders sieht, und natürlich auch der Entwicklungsaufwand/Nutzen einbezogen werden muss. Dennoch bin ich immer froh, wenn Christian wieder was tolles einbaut, das uns die Arbeit erleichtert. Es ist ja nicht so, dass er überhaupt nicht auf uns hört. ;-)

                Ich habe es in diesem Sinn gemeint. Nicht mehr und nicht weniger. Deshalb betrachte ich es auch als low Priority. Wie schreibt Christian immer wieder? "Es gibt wichtigeres zu tun." Was in diesem Fall vermutlich zutrifft, auch wenn ich es trotzdem toll fände, wenns mal irgendwann verbessert würde. Damit schliesse ich jetzt dieses Thema.

                Kommentar


                  #9
                  @startwarsfan
                  das war aber nicht die ursprüngliche Frage - aber egel - es ist wie es ist
                  ------------
                  Dieter

                  Kommentar

                  Lädt...
                  X