Aktivitäten Implementierung 18.01.2013

Eure Lieblingsimplementiergruppe sitzt gerade zusammen und ist unheimlich produktiv...



Rein zur Kenntnisnahme:
Wir versuchen uns weiter am DataBinding und sind dabei, das MockUp soweit umzusetzen, wie es jetzt gestaltet ist.
Allerdings taucht jetzt die Kritik von Herrn Walter mit berechtigten Einwänden an dem rechten Fenster zu EM&PP auf. Stellt sich die Frage, ob jetzt wieder alles umgeworfen wird?
Wir haben euch leider bei der Besprechung aller Subgruppen zu diesem Thema nicht belauscht und keine Ahnung, wie fest das ganze gesetzt ist.
Der besseren Ansicht halber speisen wir das ganze wohl vorerst mal ein.

Immer her mit akuten Einwänden/Ideen/Verbesserungen!

Ich weiß nicht genau.... da anscheinend doch vom konzept her ein paar sachen geändert werden müssen, vor allem die bedienungsideen (Stichwort kreativität) wäre es vllt sinnvoller das ganze zu unterbrechen, bis da neuigkeiten da sind.... nichts destotrotz kann die generelle maske ja erstellt werden: also grids, tabs/denke die bleiben größtenteils so, button zum löschen.... und ich hoffe zum editieren der dialoge/charaktere macht noch wer was, so wie ich im facebook drum gebeten habe, dann kann das auch schon angebunden werden... achja, generell auch das texteingabefeld ür die dialogzeilen kann angepasst werden: line /textbox/ as answer und die labels für /from/to/ und die aktuelle line....

tolles bild

in der b-note gibt das auf jeden fall volle punktzahl für uns.

was genau schwebte euch da eigentlich bzgl. der dialogzeilen im kopf? irgendwie sind wir gerade nicht auf der höhe, was "as answer" bewirken sollte? oder die offensichtlich editierbare "line"?

das steht schon in nem anderne thread aber bin zu faul den link zu suchen^^

im grunde haben wir gedacht wir "bündeln" die optionen unter einer gemeinsamen haupt ID als wir hätten dann Zeilen:
ID Text
1.1 Zeile 1, Option 1
1.2 Zeile 1, Option 2
1.3 Zeile 1, Option 3
2.1 Zeile 2, Option 1
2.2 Zeile 2, Option 2
3.1 Zeile 3, Option 1
4.1 Zeile 4, Option 1
4.2 Zeile 4, Option 2

so ca... wenn das jetz so gut rüberkommt.

Mein Task diese Woche (den ich bisher nich machen konnte aus zeitmangel, aber hoffe heute vollständig zuendezubringen) is das backend dahingehend anzupassen dass wir MainIDs und SubIDs haben. Außerdem sind ja (glaube ich) addAnswer und addOption schon getrennt auf zwei funktionen gesetzt die nur zufällig das gleiche tun, wenn nich stell ich die aber auch bereit. AddAnswer wird dann eine neue Zeile einfügen (neue HauptID, SubID=1), AddOption wird einfach eine neue Option einfügen (Gleiche HauptID, SubID=SubID+1)... gleiche einsortierlogik wie bisher... ich sag euch falls von euch aus noch was daran zu tun is, und was. Bin zuversichtlich dass ich das heut hinkrieg wenn ich Ruhe, Süßkram, ne Flasche Energydrink und genug Zigarretten hab

Edit: Ausblick auf Später (Polishing oder sonstwas): Die Darstellung könnte dieses Systems bezüglich natürlich auch wieder variieren, zB könnte man ne LISTCEPTION machen:P also die liste zeigt listen an, sprich liste von hauptzeilen, die hauptzeilen sind dann hauptzeilen-zeile und ne liste der optionen (oder so ähnlich is jetz nur dahingesponnen)... Wenn jemand Zeit hat, wäre das vllt interessant auszuarbeiten für die Zukunft (oder eben das Polishing...)

Was Line as bewirken soll:

wenn 2 optionen zur gleichen antwort führen sollen, wollen wir natürlich nicht die gleiche antwort 2 mal eingeben, also geben wir sie einmal an, sie bekommt ne neue hauptID und bei line /textbox/ as answer kann man dann die bereits vorhandene antwortID angeben.

stimmt das hab ich vergessen:) gibts eigentlich was neues bezüglich des combobox binding?

grob verstanden, vollständig vorstellbar noch nicht.

wie unterscheiden sich antworten und alternativen denn visuell? ich bin mir immer noch nicht darüber einig, wie wir das riesiges chaos an zeilen bewältigen wollen, wenn sich der alternativen/antwort-baum immer weiter verzweigt.



edit: die combobox der hölle macht tobi zu schaffen. keine der recherchierten Lösungen können ihrer arbeitsverweigerung was anhaben.

MIt dem Baum hat uns denke ich nicht weiter zu interessieren, wir haben eindeutige ids, die vergeben werden, da unser konzept keine grafische darstellung vorsieht, brauchen wir uns darüber keine gedanken machen denke ich, sondern setzen einzig und allein auf den durchblick des autors alternativ: man kann bei line (also da wo die id der zeile angezeigt wird auch angeben, ob es sich um eine answer/option/alternative handelt..

ok ich hab grad meienn senf zu persönlichkeit/emotion gegeben nu schlag ich hier nochmal zu:

nach unserem jetzigen aufbau unterscheiden sich answer/option nicht so direkt. Alle Zeilen sind gleichwertig mit ihren IDs, auch das ID/subID konzept ist da noch keine direkte hilfe. Textzeilen haben eine hauptID und eine subID, aber im grunde wäre eine Antwort=Alle optionen die die gleiche hauptID haben (ich hoffe das is klar formuliert)

Was ich jetz tun würde: Ich würd an der darstellung erstmal nichts ändern, sondern erstma gucken dass das system grob klappt. nicht zu viele Baustellen aufreißen. Was ich für Später an Gedanken festhalten möchte:

Eine HauptID, viele SubIDs, da bietet sich etwas "baumartiges" durchaus an (obwohl ich da jetz keinen baum für aufmachen würde...) Was ich denke ist da ist eine Zeile (gewissermaßen "Antwort", und darunter die zu dieser Antwort gehörenden optionen. Die "HauptZeile" könnte alle gemeinsamen informationen halten (wie zB der sprechende Charakter. Wenn man mal darüber nachdenkt, macht es nur sinn dass alle optionen mit der gleichen hauptID auch den selben sprecher haben...) die einzelnen subzeilen halten dann text und alles zeilenspezifische...

das alles macht vermutlich verdammt viel sinn, aber ich will heute erstmal das id/subid system einbauen und dann mal schauen wie es aussieht.

und damit mach ich mich jetz wirklich an die arbeit sonst wird das heute nix mehr

Ok ich habe jetzt das System auf MainID/SubID umgestellt. Allerdings habe ich das Verhalten etwas geändert (der vorübergehenden einfachheit halber)

Eine geaddete Answer steht jetzt immer am Ende der Liste (das spart später aktualisierungsbedarf von sich ändernden IDs) und eine geaddete Option wird automatisch am ende ihrer co-optionen eingefügt (das erspart ebenfalls aktualisierungsbedarf bei sich ändernden SubIDs)...

Ist nicht unbedingt meine Lieblingsverhaltensweise, den rest möchte ich jetzt aber ungern auf spekulation machen. Ich würde sagen wir probieren aus ob das MainID/SubID system sich gut macht, oder ob wir am ende doch wieder auf den Originalentwurf nach steffen zurückswitchen müssen.

Wenn ihr einen konkreten Wunsch habt wie es sich dann entgültig verhalten soll, sagt bescheid dann können wir darüber reden wie umsetzbar das wird. Vorher würde ich aber gerne die ganze From/To geschichte in trockenen Tüchern wissen, damit wir die ergebnisse sehen.


Kurzum: TextLineVMs haben jetzt MainID, SubID und (viel wichtiger) ID.
alles als properties und ID ist dann automatisch die korrekt zusammengefasste gesamt ID. Wenn ihr die für die textlines binden und testen könntet, wäre super dann wüssten wir sicher dass das ID system funktioniert. Alle varianten mit Datenkorrektur durch in-der-Mitte-Einfügen können wir danach besser beurteilen.

Froms und Tos werden gerade noch nicht mit gespeichert/gesetzt, da ich noch nicht ganz sicher bin in welchem Format ihr die zum Binden benötigt. Wenn ihr das absehen könnt, sagt bescheid dann kann ich das danach entsprechend umsetzen.

glaube das klappt aber kann ich grad nicht hochladen weil jemand anders an der main rumbastelt.

mein visual studio funktioniert mittlerweile wieder, sagt bescheid wenns drin is, dann guck ichs mir morgen an (spätestens abends)

soll AddNote eigentlich noch implementiert werden? Und wenn ja, wie? Blicke da grad nicht ganz durch

also auf unserer seite ist alles bereit für addnote (sollte zumindest)... ich bin nich sicher, aber ich glaub da sollte jetz einfach ne gelbe textbox neben jede zeile...

Ich hab gerade gesehen dass ein neuer Checkin von euch drin ist mit den aktualisierten Emo/PP elementen auf der Rechten seite. Zwei fragen/anmerkungen:

1. die Stammemotionsliste im Dialog Editbereich fehlt noch
2. Sollte der gesamte Rechte bereich nicht Bestandteil des Texteditors (tab in der mitte) sein? außerhalb dessen macht das ja keinen Sinn und wäre von der Datenhierarchie her auch am sinnvollsten, denn dann können wir die bestandteile einfach an die bestandteile der ausgewählten textline binden...

Äh ja, werden wir morgen ändern. Danke.
Frage: an welche ViewModel Klasse binden wir denn das ganze Emotionszeugs?

Die existieren leider noch nicht. Wollte damit gestern eigentlich anfangen nachdem wir endlich den doofen bug gefixt hatten aber hatte probleme mitm rechner. Wenn meine progger reagieren fangen die aber heute mit der planung und umsetzung der vms an. Sonst schiebt sich das binding noch n paar tage...

Ich wäre erst heut abend für ein Weilchen wieder aktiv, hab gleich meine Lerngruppe wieder da.
Was mir grad persönlich auffiel...bitte "Save" statt "Safe" bei den neuen Buttons . Bei dem Personality-Tab fällt mir grad auf, dass die Abstände zu den Buttons hin etwas knapp bemessen sind vllt, ist aber nur 'ne Kleinigkeit.
Bei den InvolvedCharacters-Panel steht ja neben jedem nun noch eine Dropdown-Liste.
Nur meine Meinung, aber wären da ein paar freie Pixel neben Namen und Liste und dem gesamten Panel zur Scrollbar möglich? Hab's grad auf 'nem 15" in Vollbild ^^.

1. rechtschreibfehler und pixelabstände sind minor issues...
2. InvolvedCharacters liste in der DialogueVM hat jetz direkt comboboxen drin? Wie soll das dann funktionieren? jeder charakter kann eine stammemotion haben und nur die ausgewählten werden gewertet? bitte einmal stellungname UI Design...

Ich habe grad übrigens die Buttons auf der linken Seite aus der ScrollView genommen, sodass sie jetzt immer sichbar sind. Allerdings dürfen diese bei einem nicht ausgewähltem Objekt nicht zur Auswahl stehen. ich weiß nur nicht, wo dies genau passieren soll und wie das mit den Bindings verbunden sein muss. Wäre also gut, wenn jemand hilft, da es sonst zu einem Fehler kommt, wenn noch kein Objekt existiert und man aus "save" klickt.
Außerdem habe ich noch die neuen Icons hinzugefügt und die Styles etwas abgeändert. Wenn ihr das Programm nun startet kommt eine Fehlermeldung, weil die Icons nur im Ordner liegen, aber nicht wirklich hinzugefügt sind. Also nicht wundern;)

Falls jemand da jetz dran arbeiten möchte:

Im moment wird die Scrollview per Trigger auf "Hidden" gesetzt (in xaml)

Die beiden Buttons sollten mit der Scrollview zusammen in einem seperaten Grid sitzen, und die Trigger auf das Grid übertragen werden. (Grid enthält scrollview + buttons -> Grid hidden <=> Scrollview+buttons hidden)

Das Binding der Buttons müsste jetzt vermutlich nicht mehr relativ sein, sondern müsste direkt auf "{Binding cmdSaveChanges}" und "{Binding cmdClearSelection}" gesetzt werden können. bin nicht 100% sicher, müsste man mal ausprobieren...

Arne: Zur Funktionalität involved Characters: An sich würde ich sagen, nur ausgewählten Chars sollte die Stammemotion zugewiesen werden können.

Anmerkung zu rechter Seite:

Die Listboxes bei Conditions müssen weg. Stattdessen gehört dort ein Label hin, das den aktuell sprechenden Char nennt.

Zur funktionalität involved Characters:
Wenn nur ausgewählte Characters die Stammoption kriegen können hätten wir zwei varianten mit unterschiedlicher herangehensweise:

A: Comboboxen werden für unausgewählte charaktere nicht angezeigt, für ausgewählte schon (in der selben zeile in der man sie auswählt)
-> Trigger gedöns, möglicherweise unklar oder schwer zu handlen...

B: Zusätzliche Listbox, die dann automatisch alle ausgewählten Charaktere anzeigt (und keine anderen) und dann die Comboboxen dazu bereitstellt
-> Viel Listbox gedöns drin, zwei listboxes könnten verwirren (gerade in einem scroll-lastigen bedienumfeld), dafür kann man sich nicht so leicht verklicken und damit charaktere wieder deselektieren...

Your call

Nebenbei: Wann genau is eigentlich unsere deadline? muss das zeug morgen stehn? oder rechnen wir den rest der woche mit ein? oder sagen wir aufgrund von verzögerungen schieben wir um ne woche und machen das fertig?

wenn ich die beiden alternativen sehe, würde ich sagen vorerst lassen wir es so....

zur deadline: ich bin davon ausgegegangen, dass jeder morgen als deadline annimmt... ich denke Herr Walter geht auch davon aus.

Leider war die letzte Woche, was den Arbeitsfluss angeht alles andere als optimal.

Wie schätzt du die Lage ein, ob das morgen läuft? Wäre schon toll, dann hätten ab morgen alle pause und ein großer brocken wäre geschafft.