04:54:47 Magister joined the channel
05:42:10 Schrompf joined the channel
05:49:50 Schrompf: mjöin
06:18:49 IceMichael: jmöin
06:19:22 IceMichael: ich frage mich, ob es Landsleute gibt, die "jmöin" ohne Zungenbruch aussprechen können
06:19:50 IceMichael: es geht, wenn man das m halb verschluckt, dann wird's einigermaßen smooth, aber das ist dann eben kein richtiges m mehr
06:21:55 Schrompf: ich lebe eh nur noch in der virtuellen welt, da ist jmoin kein thema
06:22:12 IceMichael: echt? ich versuch das automatisch auszusprechen
06:22:37 Schrompf: nur im Kopf, und da merk ich nicht, wenn ich nuschel
06:28:17 IceMichael: hm, im Kopf hab ich aber ne innere Zunge
06:49:49 IceMichael: joggel, ja, definitiv in MVC wrappen. Qt bringt das nicht mit, musst du schon selbst basteln, aber würde ich definitiv tun
06:51:45 IceMichael: wenn es simpel ist, ist NodeGraph einfach das Model und NodeGraph und 3D-Editor kriegen die Results und stellen sie dar. Falls lustige Qt-Views involviert sind, braucht man QAbstractItemModel (oder ein Derivat) als Adapter (Qt-Models sind keine Models sondern eher komplexe ViewController)
06:52:16 IceMichael: "NodeGraph und 3D-Editor" -> "GUI-Elemente und 3D-Editor"
06:52:34 IceMichael: "stellen sie dar" -> "operieren auf dem NodeGraph"
06:53:09 IceMichael: NodeGraph-Changes könnten dann Signals emittieren und GUI-Elemente und 3D-View sind dran geslottet und updaten brav
06:54:15 IceMichael: da man dann Endlos-Change-Loop hat, muss irgendwo noch ein Check rein, ob sich wirklich was geändert hat ODER das GUI sollte "silent" geupdated werden, wenn sich von außen was ändert
07:02:56 xq: moinchen
07:06:05 VeggieMoon: jmöinchen
07:08:01 Schrompf: jö grüzi
08:00:52 Hannes joined the channel
08:01:16 Hannes: Helöh
08:01:33 Schrompf: Hell Oh!
08:02:07 Hannes: Ferien sind vorbei
08:02:26 Hannes: ich such mir ein neues projekt
08:03:57 xq: oha?
08:04:25 Schrompf: oha? warum? was ist mit dem dungeon?
08:06:33 Hannes: ich wollte mir unity ansehen und mit etwas ganz kleinem anfangen
08:06:58 Schrompf: nuja, klar, warum nicht. hast du keine lust mehr auf den dungeon?
08:08:14 Hannes: da wurden die ideen immer größer, aber ich will keine eigene engine bauen
08:08:46 Hannes: deshalb benutze ich eine bekannte
08:09:10 Schrompf: hm, find ich schade, aber das verstehe ich. für ein echtes spiel hättest du da noch einiges an technik nachbauen müssen
08:10:05 Schrompf: soll's wieder ein dungeon werden? oder hast du eher lust auf was anderes? :)
08:10:16 IceMichael: hm ja, hab viel Gutes über Unity gehört, ein Freund von mir hat da jetzt einen richtig fetten Coaster gebaut und vielleicht sogar einen Investor an Land gezogen. Das wird superspannend (und das macht auch echt richtig Spaß)
08:10:32 Schrompf: was ist ein coaster?
08:10:41 Hannes: roller coaster?
08:10:46 Schrompf: ne achterbahn?
08:11:28 IceMichael: genau
08:11:51 IceMichael: so ein Aufbauspiel eben, wo man Attraktionen und Achterbahnen bauen muss und Leute sollen reinkommen
08:11:58 Schrompf: ah, ne management sim
08:12:00 IceMichael: die haben sogar einen echt guten Editor gebaut, allerdings wollen die meisten Spieler nicht so kreativ sein
08:12:32 IceMichael: http://realcoaster.raventurn.com
08:13:36 IceMichael: sind halt zwei Coder, Assets haben die dann bei Bedarf gekauft oder beauftragt, hielt sich finanziell aber wohl alles im Rahmen
08:43:25 joeydee joined the channel
08:47:03 Schrompf: jo ey!
08:48:52 xq: heyaaaa
08:48:56 xq: richtig voll hier :O
08:49:13 VeggieMoon: Ich bin immer voll
08:49:42 Hannes: vollmond
08:50:03 VeggieMoon: ;)
08:58:54 IceMichael: stark
08:59:20 IceMichael: haben wir denn genug qm? Nicht, dass wir Covidbedingungen verletzen
08:59:53 Hannes: ich bin geimpft
09:00:31 joeydee: moin
09:00:58 Hannes: m j d
09:00:58 IceMichael: prahl nur, prahl nur
09:04:45 joeydee: ich bin übermorgen voll gepimpt. Dann noch 14 Tage Reifezeit, dann kann man mich ernten.
09:07:59 IceMichael: super
09:08:13 IceMichael: dann noch ein paar Monate gären und dann gibt's leckeren joeydee-Wein
09:13:19 joeydee: nach ein paar Jahren dann Joey Deeniels Whiskey
09:13:44 IceMichael: :)
09:13:57 IceMichael: aber bitte nur single malt, keine Lust den guten Tropfen zu mixen
09:18:25 joeydee: Du glaubst doch nicht, dass bei mir sowas wie guter Geschmack existiert?
09:33:01 IceMichael: das will ich doch jetzt mal sehr hoffen und stark annehmen!!
09:33:20 xq: also der joeydee hatte scho immer so a gschmäckle
09:56:02 Schrompf: <3 @ Joey Deeniels Whiskey
10:28:21 Hannes: hab mich für ein Genre entschieden: 2D Autorennen und ich nenne es "Schnell & Rasend"
10:32:36 xq: guter titel
10:35:07 Schrompf: oder auch "Hurtig & Hasserfüllt"
10:35:25 Schrompf: Fix & Fies
10:36:00 Schrompf: Sowohl Eilig Als Auch Eingeschnappt
10:39:11 xq: "Hurtig & Hasserfüllt" ist nice
11:15:41 xq: m
11:15:42 xq: hmm
11:15:48 xq: error handling pattern mit C++:
11:15:55 xq: if(auto err = doSomething()) return err;
11:19:51 IceMichael: Schnellen und Dellen
11:20:39 IceMichael: ne, obiges war schon besser
11:35:42 Schrompf: seit c++17 "if( auto err = doSomething; err != ALLES_MIST ) return err;"
11:48:44 xq: Schrompf: leider nur 11
11:55:31 Schrompf: mein beileid
11:59:42 xq: tja
12:01:52 xq: ich mach mir grade die welt schöner
12:02:04 xq: C++11 ist schon nich so painful
12:02:23 xq: und ich schreib mir halt grade ne eigene kleine stdlib für io/error handling/memory stuff
12:02:32 xq: statt dem C++Builder Kack
12:04:08 Schrompf: klar, warum auch nicht. du kannst es dem arbeitgeber wahrscheinlich sogar noch gut verkaufen, irgendwas mit "nachhaltig" und "wartungsarm" und "vermeidung technischer schuld"
12:11:12 xq: "ich investier jetzt mal die 4 tage, die ich mit der letzten debug session verbracht habe in weniger zukünftige debug sessions"
12:14:09 xq: ich bau das Projekt jetzt mit der Zig toolchain + vscode
12:14:16 xq: und compiliere den kram mit c++builder, wenn ich ihn brauche
12:14:26 xq: ergo => besserer compiler, keine dependencies
12:16:01 xq: und ich hab mit clang12 nen compiler, der definitiv weniger komische bugs hat als der C++Builder von Embarcadero :D
12:19:32 joeydee: Ich hab jetzt seit Sonntag die 2. ToDo-Zeile zur ersten in meinem Code ergänzt. Ich glaube das reicht dann auch für heute.
12:25:39 Schrompf: wow, alle hier machen fette fortschritte. und ich update die doku und mach dadurch anscheinend, dass zwei scheiternde tests magisch repariert werden. jetzt hab ich angst
12:30:58 Schrompf: Magister hat sich für seinen Progress heute anscheinend geschämnt...
12:33:55 xq: https://bpa.st/JM7Q
12:33:57 xq: Schrompf: was meinste?
12:34:31 Schrompf: sieht ganz vernünftig aus
12:34:45 xq: tut tasächlich auch :)
12:35:07 xq: wo ich mir noch nicht sicher bin, ist "write()"
12:35:32 xq: eigentlich sollte das ja auch "Error write(size_t & sent, void const * buf, size_t len)" sein
12:38:08 joeydee: Console.WriteLine("no error 'til here.");
12:39:59 Schrompf: der profi am werk.
12:40:05 Schrompf: printf-debugging
12:44:09 Magister joined the channel
13:34:00 IceMichael: ja, mittlerweile log ich auch einfach nur alles zu tode
13:37:47 xq: code lesen, dann {printf/gdb}, dann verzweifeln
13:40:45 xq: https://twitter.com/slimsag/status/1422452859065405440
13:41:04 joggel joined the channel
13:41:13 joggel: ahoi
13:43:53 joggel: IceMichael: @MVC ah, okay. Danke dir. Hab mich gestern auch für MVC entschieden
13:44:24 IceMichael: hi joggel
13:44:28 IceMichael: es gibt natürlich Varianten. MVVC zB
13:44:41 joggel: ja, das weiß ich
13:44:55 joggel: aber ich denke ein simples MVC langt da
13:44:58 IceMichael: Übrigens würde ich bei einem neuen Projekt (ich nutze keine ui files) mittlerweile View und ViewController im klassischen Sinne trennen
13:45:06 IceMichael: d.h. wirklich eine File, die einfach nur das UI aufsetzt mit Layouts usw.
13:45:16 IceMichael: und Signal/Slot-Verbindung dann in einer anderen (die könnte theoretisch davon sogar erben)
13:45:40 IceMichael: tatsächlich einfach nur zur Übersicht, man nutzt fast nie für einen ausführlichen View mehrere VCs
13:45:54 joggel: ok
13:46:07 IceMichael: ist schrecklich wie wenig gutes Material es dazu gibt :/ man findet nur Müll online
13:46:17 IceMichael: also wenn man es mit Qt kombiniert
13:46:25 joggel: ja, hab ich gestern auch gemerkt
13:47:35 joggel: ich habe jetzt etwas, was halt ganz von Qt getrennt ist. Also quasi mein eigenes MVC. Das Widget bzw 3DView muss dann nur von der View-Klasse erben
13:47:42 IceMichael: schlimm ist auch, dass Models Darstellungsdaten enthalten... könnt ich ausrasten
13:48:04 IceMichael: hm, klingt okay, musst nur aufpassen, dass du nicht mehrfach von QObject erbst
13:48:18 IceMichael: was erreichst du damit?
13:48:29 joggel: mit meinem Ansatz?
13:48:31 IceMichael: ja
13:48:39 IceMichael: bin normalerweise kein Freund davon mehr Vererbung hinzuzufügen :)
13:49:24 joggel: naja... halt MVC-Ansatz. Widgets sind vom DatenModel getrennt. Alle Views werden immer bei Änderung benachrichtig...
13:49:43 joggel: achso, Du meinst weil meine Widgets dann von meiner View-Klasse erben
13:49:46 joggel: lol
13:49:56 joggel: mmhh... ich halte das für einen guten Ansatz
13:50:28 joggel: wenn Du willst, kannst du dir mal den Ansatz Anschauen. Habe ihn erstmal in eine TXT mit pseudoCode verfasst
13:51:01 joggel: Wobei der Pseudocode schon ziemlich nah dran am realen C++ ist^^
13:51:38 IceMichael: klar, immer gern
13:51:59 IceMichael: wobei wie gesagt, was genau erreihst du damit? (aber vll sieht man das am Code)
13:52:17 IceMichael: ich verstehe ja die Idee noch nicht, daher kann ich auch nicht sagen, ob der Ansatz gut ist mMn :D
13:52:59 joggel: schau dir erstmal an. Vlt habe ich da totalen Murks gemacht.^^
13:53:13 joggel: Aber nicht gleich hauen wenns nicht richtig ist :D
13:53:24 joggel: https://bpa.st/TTNA
13:54:07 joggel: okay. Das sind quasi 2 Ansätze. Einmal werden die DataModelItem direkt durch gereicht
13:55:06 joggel: Der andere Ansatz "updateWithCommand" ist mit DataModelItem-ID. Ich wollte das gleich mit Möglichkeit von Undo-Redo verbinden^^
13:56:51 joggel: Mit den Kommentaren macht es vlt etwas unübersichtlich...
13:58:35 Schrompf: "Eine Schnecklich Nette Familie"
13:58:49 Schrompf: oder auch "Das Wurmloch"
14:00:24 joggel: Wie meinen, Schrompf ?
14:00:36 joggel: bzgl meines Codes?
14:01:48 Schrompf: nein, komplett unrelated
14:02:15 joggel: achso
14:03:29 Schrompf: Build NGN-BR-268-8 - 4 minutes longer than usual.
14:03:41 Schrompf: es schlangt mir!
14:04:02 Schrompf: wurmöglich hab ich was kaputt gemacht
14:04:26 Schrompf: gleich kommt jemand um die schnecke und erzählt mir, wo bei cmake ich hingreifen muss, um das zu reparieren
14:08:34 joggel: ziemlich durcheinander der Code. Ich hätte den Ansatz mit dem std::shared_ptr
14:08:51 joggel: Also konzentriere dirch vlt nur auf die Sachen mot dem Command
14:08:57 joggel: *mit
14:10:11 Schrompf: don't overdrive it with the design, wie der gebildete Brite spräche
14:10:47 Schrompf: MVC und Konsorten sind bei Graphen echt schwierig umzusetzen und bringen meiner Meinung nach keinen Vorteil gebenüber "ich render erstmal ganz dumpf, was ich sehe"
14:10:54 joggel: meinst du das ist etwas zu much of godness?
14:11:13 Schrompf: meiner Meinung ja, allerdings ohne konkrete Ahnung Deines aktuellen Standes
14:12:38 joggel: "ich rendere erstmal ganz dumpf" habe ich ja schon. Nur wird es eben dann kompliziert, wenn ich im RenderFenster die Geometrie anfasse und ändere. Dann müssen die RotationsWidget und co auch benachricgtift werden. Der NodeGraph muss auch benachrichtigt werden, denn der muss dann wieder CSGen
14:13:12 joggel: "Geometrie anfasse und ändere" => ich verschiebe ein Modell, oder rotiere es
14:19:46 xq: oh, apropos designed und shared_ptr: ich muss da gleich mal ne design-idee ansprechen
14:21:51 Schrompf: So möge er sprechen oder für immer schweigen
14:21:58 joggel: Schrompf: Hast du eine Idee die deiner Meineung nach weniger "overDesigned" wäre?
14:22:23 Schrompf: irgendwas ohne model
14:22:32 joggel: mmhh... ok^^
14:23:10 Schrompf: du hast deinen graphen. und du hast boxen, und nen kontextmenü "neue box". jede aktion macht die gui und gleichzeitig den graphen, kein rückpfad
14:24:37 joggel: was ist wenn ich 3D-View etwas ändern will?
14:24:52 joggel: *ich im 3D-View
14:25:00 joggel: Also bspw: eine Box verschieben
14:25:11 Schrompf: hö? dann tust du das
14:25:32 Schrompf: ich meine mit "box" das rechteck mit den parametern in der gui
14:25:37 joggel: aso
14:25:45 Schrompf: die kannst du verschieben, das ändert ja nix am graphen
14:25:53 joggel: Doch, leider
14:26:46 joggel: Der NodeGraph muss benachrichtig werden. Denn dann muss der gesamte NodeGraph wieder mit der geänderten Geometrie durchlaufen und geCSGet werden
14:27:12 joggel: Der NodeGraph hält auch die Logik für den CSG-Algo
14:27:29 Schrompf: erneut "hö?". warum ist das für den graphen relevant, wo in der gui die box gerendert wird?
14:28:05 Schrompf: wenn du nen parameter mit dem schieberegler in einer box änderst, dann musst du natürlich den graphen updaten und neu auswerten. klar. aber das ist ja ein nobrainer mit qt signal
14:28:15 joggel: Wenn ich zB zwei Boxen mit Union-Boolean verheiraten will
14:28:33 joggel: mh!!
14:28:37 joggel: ok
14:29:32 joggel: ich denke ich vwersuch den MVC-Ansatz
14:29:53 joggel: das finde ich (aus rein ästhetischen Gründen) sauberer
14:30:21 Schrompf: klar, mach ruhig. ist dann schön sauberes design und so
14:30:42 joggel: eben. Bekomme ich so ein angenehmes kribbeln im Bauch :D
14:31:00 Schrompf: und das ist doch auch was wert
14:31:15 joggel: die kleinen Sachen im Leben und so... ;)
14:31:44 Schrompf: klein ist das nicht, so ein design macht ne menge coderarbeit, die's meiner meinung nach nicht braucht
14:32:11 joggel: Hobbyprojekt: Da kann ich mir das leisten
14:32:27 Schrompf: richtig, mach ruhig
14:40:23 joggel: IceMichael sagt auch nix mehr :D
14:40:44 joggel: naja... ich probiere das mal. Ich denke das sieht ok und funktional aus
15:35:51 IceMichael: oh sorry
15:36:01 IceMichael: im Zweifel mehr highlighten :D
15:36:11 IceMichael: ok, war vor ner stunde, ja, die Arbeit hat plötzlich gerufen
15:37:28 IceMichael: joggel, hmmmm, also der Code ist für mich definitiv von der Sorte: erklär erstmal deine Idee
15:37:54 IceMichael: ich meine, MVC kann ja wirklich nur heißen, das Model sendet ein Update und jeder, der drauf geslotted ist, rendert alles neu
15:37:57 IceMichael: das kann in manchen Fällen reichen
15:38:10 IceMichael: zB wenn du im TreeView änderst aber nicht im 3D-Modell selbst
15:38:43 IceMichael: klar, falls du da was änderst, und es im GUI-Treeview an der richtigen Stelle updaten soll und nicht alles wieder collapsen soll, ist das keine Option, dann muss es ausgefeilt sein
15:38:55 IceMichael: aber mich würde nochmal in Worten interessieren, wieso du von einfachem MVC weggehst oder was du hier machst/planst
15:40:11 IceMichael: Schrompf, wenn zwei verschiedene Ansichten auf Daten da was an Teilen ändern können und man auf der anderen Seite ein Update will, kommt man um ein Model kaum herum. Wie willst du das denn sonst lösen?
15:41:32 IceMichael: Für Undo/Redo hat man ja immer zwei Möglichkeiten. Mir persönlich war Command-Pattern auch zu nervig, ich habe stattdessen einfach komplette Snapshots erstellt, aber fürs komprimierte Speichern zwischen Snapshots Deltaabgleiche gemacht
15:42:29 IceMichael: na ja, aber hier so abstrakte Klassen herzunehmen mit virtuellen Methoden finde ich auch overengineered bzw einfach nicht so richtig schön
15:42:46 IceMichael: weil es gibt immer Kleinigkeiten, die dann doch anders sind. Und für Benachrichtigungen sind signals/slots schon ziemlich clean, find ich
15:43:45 joggel: "aber mich würde nochmal in Worten interessieren, wieso du von einfachem MVC weggehst oder was du hier machst/planst": ich glaube, ich habe den Ansatz dann falsch verstanden. Ich war der Meinung, das ist die Implementation eines MVC (bzw Model-View-Adapter).
15:46:33 IceMichael: also Adapter in Qt (was die Model nennen) wäre für mich nötig, wenn du eben Qts Treeview usw. nutzen willst
15:46:45 IceMichael: ansonsten wäre mein Ansatz, die ganze Nodestruktur eben als UI-unabhängige Nodestruktur zu halten erstmal
15:46:53 joggel: oh ja
15:46:58 IceMichael: alles, was an Daten geupdated werden muss, würde ich darüber laufen lassen
15:47:00 joggel: das war auch mein Ansatz... aber!!!
15:47:27 IceMichael: brauchst andre Strukturen je nach Sicht?
15:48:02 joggel: Ich verwende ja diese NodeEditor-Framework. Und das ist ja extra für DataFlow-Programming designed. Also dachte ich mir: dann verwende ich es auch so
15:48:39 joggel: wie gesagt: mein Ansatz war am Anfang GUI und Logik bzw Daten zu trennen.... sogar in 2 separate Projekte^^
15:49:29 joggel: ich hoffe wir reden nicht aneinander vorbei^^
15:49:42 IceMichael: och, bestimmt (aneinander vorbei reden :D )
15:49:43 joggel: ist schwierig hier über chat
15:49:48 joggel: hehe... okay
15:49:59 IceMichael: ja, von dem Framework habe ich jetzt keine Ahnung, das ist nur für Datenmodellierung oder für Darstellung oder...?
15:50:28 joggel: Darstellung *und* DataFlow-Verarbeitung
15:50:30 IceMichael: GUI von Daten zu trennen macht immer Sinn, ob für kleine oder große Projekte
15:50:36 joggel: sehe ich auch so
15:50:40 IceMichael: da kommt sonst nur Müll raus
15:50:45 joggel: jopp
15:50:57 joggel: habe ich schon erfahrung gemacht^^
15:51:06 IceMichael: hat jeder FullStack-Dev gemacht
15:51:16 joggel: schlimm wenn nicht
15:51:19 joggel: aber wart
15:51:28 IceMichael: also für Spiele kommt es halt drauf an. Wenn GUI fast nichts ausmacht, dann hat man das Datenmodell natürlich für direkte Zugriffe optimiert, aber das widerspricht sich ja nicht
15:51:51 joggel: ich verwende das Framework: https://github.com/paceholder/nodeeditor
15:51:58 joggel: ich schaue mal nach Beispielen
15:52:37 IceMichael: also ich diskutier gern über die architektur, aber wenn dafür jetzt framework-Wissen nötig ist, bin ich raus :D
15:52:47 joggel: wollte es gerade schreiben
15:53:07 joggel: wollte gerade sagen: Ja... ist vlt jetzt etwas zu viel sich da die Examples anzuschauen
15:53:08 joggel: :D
15:53:26 IceMichael: ok, aber verstehe die Grundidee von dem Teil, es greift eben auf M und auf V
15:53:46 joggel: Aber zu meinem MVC-Entwurf: gibt es da erstmal grundlegendes dagegen zusprechen?
15:53:53 IceMichael: ich versteh dein Design nicht
15:53:55 joggel: "ok, aber verstehe die Grundidee von dem Teil, es greift eben auf M und auf V": GENAU!!
15:53:59 joggel: wuat oO
15:54:04 joggel: ok
15:54:15 joggel: das überrascht mich jetzt
15:54:24 IceMichael: wie gesagt: dein Code ist auf dem Level von "ich will die Grundidee erstmal prosarisch verstehen, bevor ich mich da reinwühle"
15:54:48 IceMichael: sprich: wenn du mir erstmal deine Idee erklärst, geht es schneller als mit dem Code
15:56:39 IceMichael: ich hab den nur ca. 10s angeschaut, weil ich effizienzgetrieben bin :D
15:57:22 joggel: Es gibt Views. Diese diese registrieren sich beim Adapter. Der Adapter kennt das DataModel. Möchte ein View einen DataModelItem ändern, benachrichtigt er den Adapter in Form eines Commands. Der Adapter leitet das an das DataModel (DataModelContainer) weiter und benachrichtigt alle anderen, bei ihm registrierten, Views
15:57:54 IceMichael: okay, das macht ja soweit Sinn
15:58:08 IceMichael: wobei Views normalerweise passiv sind und registriert werden
15:58:13 joggel: ich merke gerade, das mein Pseudocode die registrierung der Views gar nicht hat
15:58:20 joggel: ok
15:58:24 joggel: ok
15:58:56 IceMichael: dein Adapter dient also dazu die Commands mitzuschreiben, ist also eigentlich nur ein Proxy?
15:59:19 joggel: uff.. frag mich nicht was ein Proxy ist :D ... aber anscheinend ist es das
15:59:28 joggel: also ja(?)
16:00:10 IceMichael: mit Proxy meine ich hier nur einen man-in-the-middle. Ohne Commands könnte ja dein View auch direkt ein signal emittieren (das und das hab ich geändert) und der Controller kriegt es mir und schreibt es ins Model
16:00:15 IceMichael: ok, aber eigentlich ist dein Adapter dann ja der Controller
16:00:16 joggel: ich sollte den Code noch mal überarbeiten.
16:00:18 IceMichael: je nachdem, was das Dings sonst macht
16:00:59 joggel: Naja. Der Adapter benachrichtigt doch auch alle anderen Views. Also nicht eher kein Controller
16:01:09 joggel: -eher
16:01:09 IceMichael: machen die Controller bei mir auch
16:01:24 joggel: Du stößt dich an dem Wort "Adapter"?
16:01:33 IceMichael: vermutlich, ja
16:01:43 IceMichael: Adapter dienen ja dazu eine Sprache X in eine Sprache Y zu konvertieren
16:01:44 joggel: ok
16:01:46 IceMichael: oder Datenstrukturen
16:01:57 joggel: mh... habe das nur gestern gelesen
16:02:09 IceMichael: ja ich mein, kann man ja nennen, wie man will
16:02:17 IceMichael: Adapter hat für mich auch immer 1:1 Charakter, was hier ja nicht so ist
16:02:25 joggel: https://stefanoborini.com/book-modelviewcontroller/02-mvc-variations/05-variations-on-the-triad/01-model-view-adapter.html
16:02:34 joggel: okay... welchen Namen würdest Du da vorschlagen?
16:02:47 IceMichael: ah ok...
16:03:06 IceMichael: hm wie in dem Artikel einfach Controller vermutlich :)
16:03:13 joggel: ok
16:03:20 joggel: Ja, stimmt
16:03:52 IceMichael: der Artikel ist aber auch etwas komisch, es klingt nicht so, als sollte es nach denen controller heißen... na ja, egal
16:04:18 IceMichael: gut, aber MVA ist bei dir dann schon etwas anders als ich das so mache
16:04:32 joggel: ja, habe gestern auch noch einen anderen Artikel zu MVA gefunden. Und das klingt für mich nach MVC.
16:04:50 IceMichael: bei MVC kommunizieren V und M halt durchaus direkt
16:04:57 joggel: aha
16:04:58 IceMichael: bei mir ist das ganz einfach in der Regel
16:05:20 IceMichael: hmmm, na ja
16:05:33 joggel: ich werde den Code mal ändern/aufräumen
16:05:48 joggel: dann zeige ich den nochmal. wenn interesse
16:06:08 IceMichael: also meine Views, die von Qt sind, kriegen halt direkt die dataChanged-Signale vom Model verbunden und updaten daraufhin auch brav
16:06:08 joggel: Ansonsten glaube ich, dass das Konzept taugt
16:06:16 joggel: ja, verstehe
16:06:18 IceMichael: d.h. die Views kennen das Model nicht, kriegen aber über die Signals alles mögliche mit
16:06:26 joggel: ok
16:06:51 IceMichael: wenn man im View was klickt, dann kriegt das mein Controller (auch über Signals) mit und der macht daraufhin was im Model, wenn nötig
16:07:10 IceMichael: man kann jetzt auch noch andere lustige Views anschließen, die werden auch alle brav direkt durchs Model geupdated
16:07:25 joggel: nice
16:07:32 IceMichael: da die natürlich andere controls haben können (wenn sie nicht eh read-only sind), muss der controller das dann wieder managen
16:07:40 IceMichael: das hat den Nachteil, dass der Controller sich gern mal aufblähen kann
16:08:09 IceMichael: das könnte man aber lösen, indem man für jede View-Art einen eigenen Controller schreibt
16:08:18 IceMichael: und dann einen Super-Controller, der eben die einzelenen Controller aggregiert zB
16:08:48 IceMichael: den Zwischenschritt mach ich bei mir aber gerade nicht. Denn der Supercontroller muss die Infos von den Controllern dann eh wieder verbinden. Also ich splitte das nur, wenn die Controllerklasse zu fett wird, also über 1k Zeilen oder so
16:09:16 joggel: mmh... müsste ich mal per Code sehen. Verstehe ich besser :P
16:09:48 joggel: Aber okay. Danke dir erstmal
16:09:51 IceMichael: hmmm, na ja, es kommt noch history drumherum und ich habe kollektiv alle meine Models in nem so genannten MainModelController und die ViewController aggregiert in nem MainViewController
16:10:00 IceMichael: hat also noch ne gewisse Hierarchie
16:10:32 IceMichael: aber dein Design scheint dann doch zu passen. Also wie gesagt, ich verstehe nicht, wieso du ne eigene Vererbung da reinziehst und was die hilft
16:10:46 IceMichael: Vererbung macht's immer kompliziert
16:11:00 joggel: Ja.. wenn Du jetzt so fragst: ich dachte eben das wäre der gängige weg^^
16:11:07 IceMichael: für mich ist jetzt schon nicht klar, was ne Rotation bei dir ist zB?
16:11:31 joggel: na... eben eine Rotation eines Model^^
16:11:40 joggel: :/
16:11:44 IceMichael: aber ne Rotation ist für mich eigentlich kein View?
16:11:48 IceMichael: also wieso ist das bei dir ein Widget
16:11:50 joggel: Achso
16:11:56 joggel: wart
16:12:05 IceMichael: für mich ist das ne Transformation, die man eben irgendwo draufwerfen kann
16:12:51 joggel: mh... da müsstest ich dir jetzt das GUI zeigen. Es ist eigentlich ein Widget mit 3 Slider. Jeder Slider definiert die Rotation um eine Achse (X,Y,Z)
16:13:06 IceMichael: ok, das ist ja dann so weit klar
16:13:25 IceMichael: und dann stellt das Widget dann die Rotation anhand von nem Würfel oder so was dar?
16:13:36 joggel: genau
16:14:03 IceMichael: ah ok
16:14:55 IceMichael: ok, dann versteh ich nicht, wieso man auf nen View ein Command werfen kann
16:15:04 IceMichael: für mich ändert ein Command ein Model
16:15:07 IceMichael: und der View zeigt es einfach an
16:15:20 joggel: mmhh... hast du recht
16:15:22 joggel: Aber
16:16:43 joggel: Das Command enthält ja die Rotations-Informationen. Wenn ich das Command in den DataModelContainer werfe, wird das Command auf die Daten/Geometrie ausgeführt. Werfe ich das ins View, wird das GUI geändert. Das Command enthält ja die Informationen über die Rotation
16:17:15 joggel: Also im View frage ich das Command nur nach den Daten
16:17:42 joggel: Im DataModelContainer frage ich das Command nach den Daten *UND* wende das auf die Daten (Geometrie) gleich an
16:18:45 IceMichael: hmmmm
16:18:54 joggel: Im View ändere ich halt noch das GUI bezüglich der Daten
16:19:05 joggel: ich finde das nen nettes Design
16:19:16 IceMichael: okay, d.h. du hast quasi zwei Layer? Du kannst mit nem Command Daten ändern ODER einfach nur eine spezielle Ansicht?
16:19:25 joggel: jopp
16:19:43 IceMichael: puh, aber ich finde immer noch, das Command sollte auf nem View nichts tun
16:19:57 joggel: ok
16:20:00 joggel: verstehe
16:20:04 IceMichael: für mich wäre das eher so, dass man eine "Sicht" (ok, auch wieder view, aber ich meine was andres) auf die Daten hat und es vll darauf anwenden kann
16:20:13 IceMichael: aber ob Daten selbst oder Sicht: ich würde beides genau gleich behandeln
16:20:28 IceMichael: und der View kann sich dann da rausziehen, was er möchte
16:20:42 joggel: Naja... der View müsste dann die Daten kennen
16:20:42 IceMichael: gut, jetzt gibt's halt das Problem, dass du die Rotation auch anzeigen möchtest hm
16:20:49 IceMichael: also die Koordinaten
16:21:02 joggel: jo
16:21:18 IceMichael: ok, ist dann an der Stelle für mich aber kein Command
16:22:05 IceMichael: also na ja, kommt drauf an. Commands haben ja undo/redo-Charakter, willst du ne auf den Rotationsview applizierte Rotation auch rückgängig machen können?
16:22:10 joggel: verstehe. Weil Command für etwas an den Daten ändert?
16:22:21 IceMichael: ja
16:22:26 joggel: Ja, will es rückgängig machen
16:22:31 IceMichael: ja gut
16:23:01 IceMichael: dann braucht das Rotationsview aber ein Model
16:23:14 joggel: mmhh...
16:23:17 IceMichael: entweder, du nimmst dein normales Datenmodell, das eben eine "Haupttransformation" besitzen kann, dann kann man die auch zneigen
16:23:22 IceMichael: oder du hast ein separates Model
16:23:53 joggel: ja, so war mein erster gedanke (std::shared_ptr
16:24:08 IceMichael: welcher von beiden? :)
16:24:11 joggel: lol
16:24:17 joggel: wart
16:24:18 IceMichael: also separates Model oder eins?
16:24:27 IceMichael: hm, was ist denn DataModelItem?
16:24:28 joggel: Referenz auf original
16:24:45 joggel: DataModelItem => Model aus dem NodeGraph
16:25:12 joggel: Model ist hier halt ein Mesh :P
16:25:20 joggel: aber egal
16:25:32 IceMichael: puh, ok
16:25:37 IceMichael: kommt das Naming vom Framework?
16:25:44 IceMichael: weil DataModelItem klingt für mich wie ein Teil vom Model
16:26:05 joggel: Das kommt von mir. Wollte beim erstellen abstrakkte Namen geben...
16:26:16 joggel: also beim Entwurf
16:26:29 joggel: mit dem Hintergedanken es jemanden (dir) zu zeigen :P
16:26:50 IceMichael: also am abstraktesten und einfachsten ist einfach "Model" :D
16:26:56 joggel: Ok^^
16:27:06 joggel: Naaaja....
16:27:08 IceMichael: kann jetzt wieder ineffizient zu sein, das ganze Model reinzuwerfen
16:27:33 IceMichael: ok, aber vll erklärst mal noc mehr, was du mit der Referenz auf das Model meinst?
16:27:41 IceMichael: achso, referenz im technischen sinne einfach, ja ok
16:27:46 joggel: ja, genau
16:27:59 joggel: shared_ptr oder Raw-Pointer
16:28:02 IceMichael: ok, also dein Model hat nen Mesh und ne Transformation?
16:28:12 joggel: Hey... aber ich muss erstmal wech
16:28:17 IceMichael: stimmt, schon spät
16:28:22 joggel: Ja... Mesh hat TransformationsINfos
16:28:46 joggel: Also: ja: Mein Model hat Mesh und TransInfos
16:28:48 IceMichael: ok, verstehe dann nicht, wieso der View irgendwie ne eigene Transformation kriegen muss und nicht einfach die Transformation global im Model liegt
16:29:16 IceMichael: also was bringt es, wenn man in dem View lokal ne Transformation = Rotation hat, die das Model gar nicht betrifft?
16:29:44 IceMichael: ich würd das ins Model reingießen, der View zeigt nur einen subset vom Model an (eben die Rotation) und Änderungen ändern das im Model halt
16:30:03 joggel: mmhh... ich denk mal drüber nach
16:30:05 IceMichael: falls es jetzt ne Rotation von nem einzelnen Node ist, dann sollte der View eben auf nem Teilbereich des Models agieren
16:30:24 IceMichael: trotzdem gehört die Rotationsinfo für mich ins Model und der View zeigt das (und die Rotationsparameter) nur stupide an
16:30:39 IceMichael: ja, überleg mal, hast ja wesentlich mehr Domänenwissen
16:31:01 IceMichael: definitiv ein cooles Projekt, um vernünftiges Design zu üben :)
16:31:31 joggel: hehe.. ja. Vorallem, wird das auch nötig sein. Man kann echt ne Menge mit dem NodeGraph da machen
16:31:48 joggel: zig Nodes die alle etwas anderes machen
16:31:53 joggel: naja... egal :P
16:31:56 joggel: Bin erstmal weg
16:31:58 joggel: bis dennse
16:32:00 joggel: n
16:32:22 IceMichael: joggel, halt mich auf dem laufenden, bin gespannt, wo du da landest :)
17:13:24 Schrompf joined the channel
17:42:46 Magister joined the channel