[Featurewunsch] Visu-Widget

[fisch3009]

Nach dem ich mich ein bisschen (oder ein bisschen mehr) mit der Visu beschäftigt habe hätte ich einen, zugegebenermaßen umfangreichen Featurewunsch für die Visu.
Ich denke der würde vielen die nach ähnlichem hier schon gefragt haben helfen und würde sich imho gut in das EDOMI Konzept integrieren.
Ich nenne es einfach mal ein Visu-Widet:
Vom editieren und der Gestaltung würde sich das genauso verhalten wie ein Popup oder eine Seite mit dem Unterschied, dass man es mit einem "neuen" Visuelement auf einer Seite oder einem PopUp platzieren kann.
Als Besonderheit kann man im Visu-Widget KOs angeben, die quasi nach Außen gehen (ich nenne sie mal Widget-KOs).
Beim Platzieren des Widgets auf einer Seite oder auf einem Popup, kann man dann im Eigenschaften Dialog diesen Widget-KOs eine richtige KO zuweisen. (Klicken und Größe und Aussehen gibts ja nichts mehr zu ändern).
Man kann dann einmal z.B. so etwas wie einen Heizungseinsteller (siehe z.B. Screenshot) als Widget erstellen und kann diesen dann beliebig oft auf Visu-Seiten Popups platzieren und muss nur noch die entsprechenden KOs (einmal, im Beispiel brauche ich z.B. viermal Soll, zweimal Ist usw) reinschreiben.

Ich hoffe das war verständlich soweit?!

Ich denke, dass würde vieles vereinfachen und auch die Pflege einer Visu leichter machen.



Verstehe das bitte nicht als Kritik, ich bin schon sehr begeistert, was man alles mit EDOMI machen kann, ist alles extrem flexibel. Aber das wäre halt nochmal ein Krönchen :-)

Heizung.PNG

[gaert]

Also kurz gesagt quasi ein individuelles Visuelement, dass seinerseits aus vielen Visuelementen besteht? Eine Art "Visuelement-Ordner"?

Möglich ist alles - ist ja nur Software. Ich möchte auch nicht behaupten, dass die Anzahl der aktuellen Visuelemente in Stein gemeißelt sind... Allerdings ist gerade das Erstellen von Visuelementen äußerst viel Arbeit - der RGB/HSV-Dimmer z.B. hat viele Haare gekostet. Du musst dabei immer bedenken, dass alle Visuelemente vollkommen frei skalierbar sind - das ist nicht immer so einfach zu erreichen mit ein bisschen HTML und CSS.

Kurzum: Mal eben einen "Visuelement-Designer" auf die Beine zu stellen ist nicht trivial! Klar, schön wär's - aber aktuell gibt es durchaus wichtigere Dinge. Solange kann man allerdings fast alles mit den vorhandenen Elementen umsetzen, denn diese lassen sich präzise "stapeln", dynamisch verschieben/skalieren/drehen etc... Ist zwar viel Arbeit, aber machbar.

PS: Wenn ich an die Visuelemente vom HS denke...

[fisch3009]

Ja, Visuelement-Ordner könnte man das auch nennen. Im Prinzip wäre es so, als wenn man ein PopUp irgendwie auf einer Visu-Seite platzieren könnte, skalierbar muss das ganze ja nicht mehr sein, das ist ja schon durch die Größe definiert und dann halt interne "Visuelement-Ordner" KOs.
Das das nicht mal eben implentiert ist, war mir fast klar, wie tief das ins System geht, kann ich ganz schlecht beurteilen... (Visu-Elemente vom HS kenn ich nicht).

[SeatSLF]

skalierbar wäre schon gut, denk doch daran man die FullHD Visu nicht unbedingt
sinnvoll auf einem Handy bedienen kann.
Und somit durchaus auf eine andere Auflösung ausweicht

[gaert]

Mit "skalierbar" meinte ich die Visuelemente an sich - nicht die Visu. Die wird niemals skalierbar sein - das Thema hatten wir ja schon...

Ich mache mir schon länger Gedanken zur Gruppierung von Visuelementen, d.h. man erstellt ein Visuelement aus vielen Einzelteilen und gruppiert diese dann zu 1 Element. Auf diese Weise könnte man sich beliebig komplexe "Gesamtkunstwerke" basteln, die man dann entsprechend wiederverwerten kann.

[SeatSLF]

Mit "skalierbar" meinte ich die Visuelemente an sich - nicht die Visu. Die wird niemals skalierbar sein - das Thema hatten wir ja schon...

Ich mache mir schon länger Gedanken zur Gruppierung von Visuelementen, d.h. man erstellt ein Visuelement aus vielen Einzelteilen und gruppiert diese dann zu 1 Element. Auf diese Weise könnte man sich beliebig komplexe "Gesamtkunstwerke" basteln, die man dann entsprechend wiederverwerten kann.

War ja auf das Element bezogen...

[gaert]

Ah, ok. Wie gesagt: Ich mache mir schon länger Gedanken darüber - also abwarten Die lästige Wartezeit könnte man ja z.B. mit einem Update auf die 1.16 überbrücken - so nicht schon geschehen...

[fisch3009]

Genau so eine Gruppierung meine ich. Kombiniert mit der Möglichkeit quasi gruppeninterne KOs zu verwenden, die man von "außen" bestücken kann, ist das genau das was ich meine.
Ich bin halt nicht von Gruppierung ausgegangen sondern von "Seiten" aber macht ja letztendlich keinen Unterschied, außer: bei meiner Variante hat man quasi eine zentrale Vorlage, wenn sich an dieser was ändert, sind alle Elemente geändert, bei deiner Gruppierung vermutlich nicht?

[gaert]

Meine Pläne zielen in diese Richtung (da "einfacher" zu implementieren):

Es soll ein neues "Visuelement" geben, dass nix kann - außer andere Visuelemente "aufzunehmen". Also quasi eine Art Ordner. Dieses Visuelement ist skalierbar, d.h. alle enthaltenen Elemente skalieren entsprechend mit. KOs und alle anderen Eigenschaften bleiben aber Sache der entsprechenden Elemente in diesem "Ordner" - sonst wird's zu kompliziert.

[saegefisch]

Interessant, seit letzter Nacht denke ich auch bereits über einen "Visuelement-Ordner" nach... Ein eigener Typ ist schon einen andere Nummer, aber was mir gestern in den Sinn kam, als ich ansprechende Visu-Elemente ausschließlich mit CSS3-Mitteln erstellt habe (Buttons, Slider mit einer klaren, aber dezent-plastischen Anmutung durch gradienten). Dafür braucht es mindestens 2 Universalelemente, wenn man es etwas plastischer haben mag (Sicken, umlaufende Fase, angedeutete Vertiefungen), kann es auch ein ganzer Sack werden. Für ein Schalter. Schön, aber nicht wirklich praktikabel bei der Zahl an Aktoren bei mir im Haus. Oder Rolläden. Oder...

• Sehr geil, welche Möglichkeiten sich mit Standard CSS3 in Kombination mit Deiner {#}-Mimik möglich sind! Tolles Konzept, was mich immer wieder begeistert!
• Eine Gruppierung der Objekte sollte möglich sein (technisch wohl ein DIV), am besten links in der Elementliste auf/zuklappbar. Ich freue mich, dass es dazu bereits konzeptionell weiter geht..
• Besser wäre eine Instanzierbarkeit der Gruppe.
  • Einschränkung der möglichen Kinder auf wenige Typen, vor allem wohl Universalelement.
  • Vereinfachung: Nichts übergeordnetes (wäre auch fein), doch es wäre schon gut, wenn pro Visuseite die "Mutter" nur 1x definiert werden müsste. Seitenübergreifend z.B. je Visu wäre natürlich optimal.
  • Dann baut man nur z.B. einen "Mutter-"Schalter aus beliebig vielen Kindern.
  • Schön wäre, wenn die Gruppe auf/zuklappbar wäre links in der Elementliste
  • Neben den Grundparametern braucht es nur ein KO. Das KO wird 1:1 an die Kinder durchgereicht und die relative Skalierung
  • Die Gruppe kann beliebig oft auf der selben Seite verwendet werden. Die KO der Kinder wählt man als "aus Gruppe" oder ähnliches
  • Die x Instanzen sind in der Elementsicht nur noch als ein Objekt sichtbar und brauchen nur je mit dem korrekten KO parametrisiert zu werden (neben Grundparametern Größe, Position, Z-Index, Name)

Grundsätzlich - auch wenn das irgendwo bei V1.08 schon mal besprochen wurde - wäre ein _optionales_ zusätzliches Namensfeld für jedes Element hilfreich: Der Name dient nur der Strukturierung (und wieder finden!) in der Elementliste links. Der Name wird dort als Prefix vor der Bezeichnung stehen. Die Liste sollte dann alphabetisch, nicht mehr nach DB-Index sortiert sein. Denn: Eine ansprechende Visu-Seite hat am Ende doch einen ganze Menge Elemente und so könnte man erheblich zielsicherer darin selektieren und arbeiten.

Vielleicht helfen meine Gedanken bei der Konzeption...

saegefisch

[gaert]

Schön, dass Du Dir Gedanken machst!

Mir ist dies alles (und noch viel mehr) durchaus bewusst - ich benutze ja auch hin und wieder normale Programme, wo Gruppieren mit allem Schnickschnack vollkommen normal ist. Aber dies kann man nicht mal eben so in einer Webanwendung abbilden - das ist sehr komplex. Mit einem "Mutter-DIV" ist's nicht getan... Die Datenbankstruktur muss auch damit klarkommen, und die GUI ebenso.

Die Anzahl der Visuelemente auf einer Visuseite ist übrigens relativ egal (in der eigentlichen Visualisierung zumindest). Ich habe schon mit tausenden(!) Elementen auf einer Seite experimentiert - hat den Browser kaum gejuckt. Das ist eben der Vorteil meines "einfachen" Grundkonzeptes! Wenn man die üblichen Webtechniken nutzt (jQuery, GUI-Libraries, JSON-Format, etc.) knickt am Ende die Performance im Browser stark ein. Und ich wollte eine Visu erschaffen, die auch auf schwächeren Clients flüssig und latenzarm funktioniert. Je mehr "Gedöhns" ich also in EDOMI reinpacke, umso mehr wird dieses Grundkonzept ad absurdum geführt... Am Ende haben wir dann Windows XP mit 1000 Zusatztools und Addons...

[saegefisch]

Das mit den tausenden Elementen ahne ich, daher versuche ich auch gerade alles nativ mit CSS3 zu machen und ohne die früheren Lösungen mit "noch ein Hintergrund-PNG" und hier noch und da noch. Soll ja schön werden und zeitgemäß... mich musst da nicht überzeugen, denn Dein Konzept ist überzeugend! Technisch schreckt mich das alles nicht, aber mein Hirn findet nichts mehr wieder auf einer Seite mit 1000 Elementen. Ach, wenn die menschliche Unzulänglichkeit nicht wäre... Wie einfach könnten UI sein... Daher wäre mein Vorschlag, doch noch mal über ein zusätzliches optionales Namensfeld nachzudenken als Prefix in der dann alphabetischen Liste. Wäre schon ein großer Fortschritt in meinen Augen.

Zur Instantiierung: Yepp, das ist nicht einfach, aber der Gedanke war: Alles bleibt, wie es ist. Ausnahmen in Codings sind mir auch ein Graus. Daher muss das einfach der adjustierte Standard werden: Die Gruppe stellt den Nullpunkt als Ausgangsbasis für ein Objekt dar. Hat es keine Gruppe, ist der Nullpunkt wie bisher (0,0,0) und Skalierung 1. Nur sobald es ein Gruppenobjekt gibt, muss das Kind KO und Skalierung und Position und z-Index relativ dazu physikalisch ausprägen. Damit ist das wieder die Norm. Beim KO ist es schwieriger. Aber eigentlich kann man auch hier zum Zeitpunkt der Codegenerierung immer gleich vorgehen: Das Gruppenelement findet keinen Niederschlag. Ein Element in Gruppe ist zusätzlich zu erzeugen (ist ja auf der Visu-Seite nie tatsächlich angelegt worden) mit der entsprechenden Transformation von KO, Position,... (siehe oben). Ein Element ohne Gruppe genau so, nur das die Basis eben (0,0,0) und Faktor 1 ist.
In der DB wird es schwieriger - für einen konstruktiven Vorschlag fehlt mir da der Einblick in Deine Logik...

Es ist mir klar, dass das nicht einfach ist, aber mir erscheint es denkbar im Konzept, was ich bisher sehe - ohne Konzeptbruch und Gefahr von Windows XP...

[gaert]

Recht hast Du - keine Frage! Ein Namensfeld steht schon lange auf meiner Liste (die inzwischen umfangreicher ist als so manche Diplomarbeit). Wenn ich unendlich viel Kapazitäten hätte, würde ich schon morgen ALLES implementiert haben... Zur Erinnerung: Ich arbeite vollkommen alleine!

Dein CSS-Ansatz ist genau der richtige - das ist exakt das Visu-Konzept in EDOMI. Daher werden Bilder ja auch recht "zaghaft" unterstützt... Was wiederum dazu führt, dass die Icon-Liebhaber mit Wünschen Schlange stehen...

Eine Instanzierung ist sehr komplex - und es gibt dabei viiiiiel zu beachten. In C++, Java, etc. wäre das alles viel einfacher: Objektorientiert, Klassen - fertig. (am Besten noch eine objektorientiere DB). In PHP/JS/HTML/CSS sieht das etwas anders aus... Ich muss ja quasi in 4 Sprachen gleichzeitig programmieren und alles muss nahtlos ineinander greifen. Bedenke: Das Ganze ist eine Client/Server-Anwendung, kein lokales Programm a la Word. Schlimmer noch: Die Möglichkeiten sind stark begrenzt... In VB.NET "malt" man mal eben ne GUI - und alle Objekte führen ganz von selbst ein Eigenleben...

[saegefisch]

Hey Christian, ich denke Du weißt aus meinen anderen Beiträgen: Ich bin tief beeindruckt. Und habe keinerlei Zweifel, dass Du sehr gut weißt, was wann sinnvoll ist und was geht. Das Thema ist ja "Featurewunsch"... und wie ich meinen Kindern beim Wunschzettel-Schreiben immer sage: Ein Wunschzettel ist kein Bestellzettel... Kein Druck daher von meiner Seite.

Eine saubere Instanziierungslösung ist IMMER eine konzeptionelle Herausforderung (oft unterschätzt). Aber, hey! Wär' ja sonst auch langweilig und könnte jeder... Ohne Zweifel kompliziert. Und es ist gut und konzeptionell überzeugend, dass es ein Client/Server-Konstrukt ist. (Ich wäre vermutlich sonst nicht hier bei edomi fasziniert hängen geblieben). Aber im Prinzip sind die gesamten Kinder aus den Instanzen in der Welt "hinter der Visu-Erstellung" alle da, als wären sie manuell angelegt worden, also für DB, Logik-Backend, etc. Da sollte alles wie immer sein - mit dezenten Änderungen in der Logik, da die zusätzliche Eben der Ausgangsbasis/Nullpunkt eingeführt werden muss, die entweder initial ist oder aus der Gruppe kommt (KO, Position, Skalierungsfaktor) und dem Attribut "Teil der Gruppe x". Die skizzierte Logik macht das alles "wie bei allen" und fast wie bisher. "Nur" nach vorne in der Visu werden sie maskiert bzw. müssen bei einer neuen Instanz "hinten" erzeugt werden; oder gelöscht mit der Gruppe.

Aber genug von mir dazu, ich will ja nicht nerven: Ich bin gespannt, ob, wann und wie Dir eine Lösung dazu kommt, die Deinen Ansprüchen genügen wird. In 1.17 rechne ich ziemlich sicher nicht damit... Wenn Du irgendwann Lust auf weitere Diskurse und Ideensammlungen zum Thema Gruppierung brauchst, stehe ich Dir zur Verfügung. Bis dahin gehe ich wieder freudig in die CSS3-Küche...

Beste Grüße auf die Kanaren.

[gaert]

Bestellungen nehme ich aktuell auch nicht entgegen

Nee nee - ich verstehe Dich absolut und wollte auch nicht irgendwie einen anderen Eindruck erwecken Das "Problem" ist weniger das Backend in Sachen Gruppieren etc., sondern das Frontend (GUI). "Problem" ist das falsche Wort - eher "die sehr arbeitsintensive Herausforderung" Bei Webanwendungen dieser Art muss ich jede Kleinigkeit zu Fuss implementieren - selbst ein schlichtes Kontextmenü ist eine eigene Implementierung. Will sagen: Ich denke über eine möglichst einfache, intuitive und dennoch flexible Lösung nach. Kompliziert und reich an Features kann jeder - aber EDOMI soll ja irgendwann auch von Laien bedient und verstanden(!) werden sollen. Aber keine Sorge: Ich bin dran...