Sollen QUndoCommands auf eine Ansicht oder ein Modell gebunden werden?

Question

In Qt Undo Rahmen , können Sie einen Stapel von QUndoCommand Instanzen . Jede dieser beschreibt eine Aktion in der Benutzeroberfläche. In unserer Anwendung haben wir eine Reihe von Ansichten über eine Reihe von Modellen, einig in Kombination arbeiten, und wir haben oft mehr als eine Ansicht auf dem gleichen Satz von Modellen arbeiten. Ich bin jetzt auf der Fähigkeit der Suche Aktionen auf diesem Rahmen rückgängig zu machen basiert.

Nun, ich bin vertraut mit der allgemeinen Muster von Befehlsklassen mit der UI-Aktionen zu beschreiben, sondern diese soll eine Zustandsänderung in UI-Elemente repräsentieren, oder eine Datenveränderung des Basismodells (s)? Wie viele Daten und Staat ist eine Befehlsklasse sollte enthalten?

Ein Beispiel meinen Standpunkt zu verdeutlichen: Angenommen, Sie eine QStandardItemModel als Basismodell haben, und eine Reihe von Proxy-Modelle auf dieser Sitzung. Jedes Proxy-Modell eine Transformation der Art, wie Filtern durch das Auftreten eines bestimmten Wertes tun wird. Dann, wenn ich speziell alter ein Wert in einem dieser Proxy-Modelle, und die Filterbedingungen ändern eine Befehlsklasse erstellen, der Zustand dieses Befehls Klasse ungültig wird. Also muss ich auch den Zustand des Filters umfassen, oder eine Zuordnung zu dem ultimativen, zugrunde liegenden Modells. Eine weitere Option ist, Befehle für alle Zustandsänderungen in der Benutzeroberfläche hinzufügen (diejenigen, wodurch die Filterbedingung zu ändern, zum Beispiel) als gut, aber die Kehrseite der Medaille zu sein scheint, dass die Liste der Befehle rückgängig zu machen wird ziemlich groß.

Was die besten Praktiken sind hier?

Answer 1

Es hängt etwas von Ihrer Anwendung und wie es verwendet wird, aber hier sind die allgemeinen Richtlinien, die ich in der Vergangenheit für Undo-Befehle verwendet habe:

• Ist es ein Teil der Daten? Wenn ja, sollte der Benutzer in der Lage sein, es rückgängig zu machen.
• Sie wird gespeichert irgendwie (erinnerte zwischen Anwendungs-Sessions)? Wenn ja, sollte der Benutzer wahrscheinlich in der Lage sein, es rückgängig zu machen.
• Ist es auf den Hauptzweck des Programms zu tun? Wenn ja, rückgängig gemacht werden.
• Ist es ein oft getan Teil des Workflows? Wenn ja, wahrscheinlich rückgängig gemacht werden.
• ausgelöst basiert sie auf etwas anderes zu ändern? Wenn ja, sollte es rückgängig zu machen, wenn das andere Element wieder ändert, nicht von selbst aus.
• Ist zurückgesetzt es jedes Mal * X * passiert? Sie könnten in der Lage sein, weg mit ihm nicht in dem Rückgängig-Stapel ist.
• Ist es über die gleiche Bewegung (versteckt / zeigt zusätzliche Informationen, zum Beispiel) leicht rückgängig gemacht? Sie wahrscheinlich wollen es nicht in dem Rückgängig-Stapel.

Auf dieser Grundlage und was du geschrieben hast, würde ich wahrscheinlich die Undo-Informationen sowohl binde das Modell (Daten) und die Ansicht, wenn die Filterung ist etwas, das oft geschieht, und / oder kann nicht einfach geändert zurück werden. Wenn die Filterung einfach (Grund Teilzeichenfolge Filterung wie Ihre E-Mail-Betreffzeilen suchen), dann ist es wahrscheinlich nicht brauchen Teil des Undo Zustand zu sein, und dann Undo-Befehle würden nur an die Daten gebunden werden.