Se supone que estar atado a una vista o un modelo QUndoCommands?

Question

En Qt de deshacer marco , que puede tener una pila de casos QUndoCommand . Cada uno de éstos una acción en la interfaz de usuario. En nuestra aplicación, tenemos un conjunto de vistas que trabajan en un conjunto de modelos, algunos en combinación, y que a menudo tienen más de una vista de trabajo en el mismo conjunto de modelos. Ahora estoy mirando la posibilidad de deshacer las acciones sobre la base de este marco.

Ahora, estoy familiarizado con el patrón general de tener clases de comando para describir las acciones de interfaz de usuario, sino que son éstos supone que representa un cambio de estado de elementos de la interfaz, o un cambio en el modelo de datos subyacente (s)? La cantidad de datos y estado es una clase de comando supone que contienen?

Un ejemplo para ilustrar mi punto: suponga que tiene un QStandardItemModel como modelo base, y una serie de modelos de proxy que se sienta encima de este. Cada modelo de proxy hará una transformación de tipo, como el filtrado por la aparición de un cierto valor. Entonces, si se crea una clase de comando a un valor concreto alter en uno de estos modelos de proxy, y el cambio de las condiciones del filtro, el estado de esa clase de comandos no es válida. Así que tengo que incluir el estado del filtro también, o una asignación al último modelo, subyacente. Otra opción es añadir comandos para todos los cambios de estado en la interfaz de usuario (los que causan la condición de filtro con el cambio, por ejemplo) también, pero la desventaja de esto parece ser que la lista de comandos para deshacer convierte en algo grande.

¿Cuáles son las mejores prácticas aquí?

Answer 1

Depende un poco de su aplicación y cómo se utiliza, pero aquí están las directrices generales que he usado en el pasado para los comandos de deshacer:

• ¿Es parte de los datos? Si es así, el usuario debe ser capaz de deshacerlo.
• Is se guarda alguna manera (recordado entre sesiones de aplicación)? Si es así, el usuario debe probablemente será capaz de deshacerlo.
• ¿Está relacionado con el propósito principal del programa? Si es así, puede deshacer.
• ¿Es una parte a menudo hecho del flujo de trabajo? Si es así, probablemente se puede deshacer.
• ¿Se desencadenó basa en algo más cambiante? Si es así, se debe deshacer cuando el otro elemento cambia, no por sí mismo.
• ¿Se restablece cada vez que * X * que pasa? Usted puede ser capaz de salirse con la suya no estar en la pila de deshacer.
• ¿Se puede deshacer fácilmente a través del mismo movimiento (ocultar / mostrar información adicional, por ejemplo)? Es probable que no lo quiere en la pila de deshacer.

En base a esto y lo que has escrito, probablemente me ato la información de deshacer para tanto el modelo (datos) y la vista, si el filtrado es algo que sucede a menudo y / o no se puede cambiar fácilmente de nuevo. Si el filtrado es simple (subcadena básica filtrando como buscar sus líneas de asunto de correo electrónico), entonces probablemente no necesita ser parte del estado de deshacer, y luego los comandos de deshacer simplemente estaría ligado a los datos.