2012-07-18 12 views
7

En nuestra aplicación, tenemos un número variable de dockwidgets porque algunos de ellos se agregan mediante complementos que se cargan en tiempo de ejecución. No todos los dockwidgets deben ser necesariamente visibles al mismo tiempo. Esto depende en gran medida de en qué está trabajando el usuario y qué complementos están activos.¿Cómo evitar superposición fea con demasiados dockwidgets en QMainWindow?

Sin embargo, si demasiados dockwidgets se agregan mediante programación con addDockWidget(...), comienzan a superponerse entre sí (no en términos de pestañas, sino en términos de contenido de uno pintado en el área de otro diferente, lo que obviamente se ve roto)

Overlapping dockwidgets

El usuario puede mover los dockwidgets a dockareas que aún tienen espacio a la izquierda, pero el/ventana principal de diseño evita con éxito (untabbed) re-Además de la dockarea "lleno".

Hacemos permiten muelles con pestañas para permitir al usuario organizar los dockwidgets un requeridas, pero no queremos que permita QMainWindow::ForceTabbedDocks ya que esto limitaría el número de dockwidgets simultáneamente visibles demasiado (una por cada zona del muelle).

¿Cómo puedo evitar esto o controlar mejor cómo se agregan los dockwidgets?

Respuesta

5

No responde su pregunta directamente, pero valdría la pena olvidar realmente Qt y realmente pensar en cómo debería funcionar toda la interacción. ¿Cuáles son las expectativas del usuario? ¿Qué debería pasar realmente si se activan 10 plugins diferentes? ¿Deben estar acoplados o deberían estar flotando o deberían convertirse en ventanas acoplables con estado inicial como un pequeño botón en los bordes de MainWindow? Creo que una vez que haces ese trabajo preliminar y creas maquetas de la interfaz de usuario, puedes comenzar a buscar Qt y descubrir si Qt proporciona una manera directa de desarrollar esa interfaz y, si no, qué componentes adicionales necesitarás desarrollar para conseguir que esa interfaz funcione.

Según mi propia experiencia, desarrollé una interfaz similar desde hace mucho tiempo pero en MFC. La forma en que lo hicimos fue que se consideró que algunas de las ventanas acopladas debían tener y aparecerían como atracadas.Luego había un conjunto de ventanas que no necesitaban ser visibles siempre pero que deberían estar rápidamente disponibles y su estado inicial era como una ventana de anclaje escondida, lo que significaba que surgían como botones en el borde de MainWindow. Finalmente, había un tercer conjunto que el usuario no requería siempre y que podía ser llamado desde Archivo-> Ver menú. Una vez que el usuario lo hizo visible, el usuario típicamente lo asignaría a uno de los primeros dos grupos o lo mantendría a flote. Toda esta configuración se guardó en un archivo de configuración y a partir de ahí cada vez que se cargaba/activaba el complemento, se utilizaba el último estado utilizado de la ventana de acoplamiento asociada. Sin embargo, implicó un poco de trabajo extra, pero el resultado final fue para la satisfacción de todos los usuarios.

+1

Gracias. Creo que este es un buen consejo. Este podría ser un buen ejemplo de que siempre es una buena idea dar un paso atrás y replantearse el diseño general y la imagen completa cuando se pierde en detalles técnicos. –

2

¿Has probado setDockOptions(QMainWindow::AllowNestedDocks)? No puedo probarlo ahora pero puede ser útil. Por defecto, QMainWindow::dockOptions se establece en AnimatedDocks | AllowTabbedDocks por lo que usted quiere algo así como

setDockOptions(QMainWindow::AllowNestedDocks | QMainWindow::AnimatedDocks | QMainWindow::AllowTabbedDocks) 

EDIT: Si tiene demasiados problemas, es posible que va de este por el camino equivocado. En lugar de usar muelles, es posible que desee intentar usar QMdiArea con QMdiWindow. Esto puede no funcionar para su programa, pero es algo en lo que pensar.

+0

Voy a intentar esto, aunque no estoy seguro de si me gusta 'AllowNestedDocks'. Tal como está ahora, a veces puede ser bastante molesto que los dockwidgets comiencen a "ajustar" * a las diferentes áreas, cuando solo quieres mover un widget flotante. Habilitar la anidación incluso aumentará la cantidad de áreas de muelle posibles, ¿no es así? –

+0

Sí lo hará. La documentación de qt indica que es bueno para muchos muelles, pero que puede ser molesto. –

+0

Es aún peor. Primero que nada, no funciona. Con un solo "nivel" de dockwidgets, es lo mismo que antes. Pero si anilo en dockwidgets uno al lado del otro y luego programáticamente agrego otro dockwidget a esa área, simplemente se superpone a ** both ** dockwidgets anidados:/ –

1

Ésta es la solución Traté:

  1. he creado en QtCreator un proyecto vacío con una ventana, un menú minimalista con la etiqueta "Nuevo Muelle" y un DockWidget nombrado dockWidget

  2. Ésta es la triggered() controlador para mi elemento de menú:

    void MainWindow::on_actionNew_Dock_triggered() 
    {  
        QDockWidget* w = new QDockWidget("Demo", ui->dockWidget); 
        this->addDockWidget(Qt::LeftDockWidgetArea,w); 
        this->tabifyDockWidget(ui->dockWidget,w); 
    } 
    

tabifyDockWidget(QDockWidget* first, QDockWidget* second) es un método QMainWindow que apila el segundo dockwidget sobre el primero. Espero que ayude ...

+0

Sin embargo, entonces tendría que comprobar primero si ya hay un widget dock en ese lado ymm, si hay varios, decida cuál tabular. Pero incluso eso no resolvería el problema, supongo: supongamos que hay dos dockwidgets en 'LeftDockWidgetArea'. W.r.t su MinimumSize, ocupan todo el espacio disponible. Uno es pequeño, uno es grande. Agrego un dockwidget bastante grande. Si ahora elijo la pequeña para ser tabulada con mi nueva dockwidget, me temo que tendré exactamente los mismos problemas (dos dockwidgets uno al lado del otro, ambos demasiado grandes para que Qt anule el mínimo tamaño y cause la fea superposición. –

+0

O am ¿Me falta algo? Quizás tengamos que redefinir todo el "proceso" de cuándo, cómo y dónde se pueden agregar los acopladores. –

+0

Podría implementar políticas de tabulación/acoplamiento a nivel de complemento. Supongo, sin embargo, que sus complementos derivan de 'QWidget' y establecerse como el widget principal de' QDockWindow'. Si este es el caso, el antecesor del plugin común podría diseñar una política básica de acoplamiento/posicionamiento, que puede ser modificada por sus descendientes. –

Cuestiones relacionadas