Discussion :

[Klaim]

Dans le cadre de mon projet open source Art Of Sequence (http://artofsequence.org) je développe un outil de montage de "séquence digitale". L'outil s'appelle AOS Designer. (tout un programme).

En gros j'ai une fenetre principale et des document qui sont en fait des "vues" de données, enfin peu importe.

Mon souci ici est de mettre en place un système simple pour me permettre d'avoir de fenetres qui peuvent passer de l'intérieur de la fenetre principale à l'extérieur. J'apelle le principe "FreeWindows" et j'ai fait une implémentation partielle dans un clone du repository de mon projet. Je prends comme exemple les fenetres de Visual Studio 201x mais je n'ai pas besoin de faire aussi "balaise", quelque chose de simple suffira.

Ca se résume à 2 classes, FreeWindowsManager et FreeWindows qui permettent la dite fonctionalité MAIS il manque unchose : j'ai des QAction qui permettent de faire sortir la fenetre et de la faire rerentrer mais je ne trouve pas de moyen générique de permettre à l'utilisateur d'avoir l'action visuelle pour revenir dans l'écran.
En gros, dans la fenetre interne (QMdiSubWindow), j'ai ajouté une action dans le menu contextuel si on click droit sur la barre de la fenetre, "Float Window" pour faire sortir la fenetre.
En revanche pour la fenetre externe (QWidget) je ne trouve pas de manière de fournir l'action "Dock Window" visuellement à l'utilisateur, de manière générique et le moins intrusif possible.

Comme il y a des experts Qt peut être qu'ils pourraient vérifier mon code et me faire des suggestions?
C'est un peu expérimental alors je n'ai pas vraiment commenté mais c'est je pense assez simple à comprendre :

http://code.google.com/r/mjklaim-fre...dowManager.hpp
http://code.google.com/r/mjklaim-fre...dowManager.cpp
http://code.google.com/r/mjklaim-fre...FreeWindow.hpp
http://code.google.com/r/mjklaim-fre...FreeWindow.cpp

Théoriquement vous n'avez pas besoin de lire tout le code du projet, juste ces fichiers ci qui devraient être réutilisables (hors macros d'assertions et de log)

Postez ici pour les commentaires ou bien utiliser le système de reviews de Google.

Note à part : Vous pouvez aussi, si ça vous interesse et que vous avez le temps, vous pouvez m'aider en jettant un oeil au code de l'ensemble du projet là : http://dev.artofsequence.org (le système de code review est totalement activé)
C'est peut être encore un peu tot mais j'avoue qu'avec le peu d'expérience que j'ai avec Qt j'ai encore du mal à bien organiser tout ça... Et puis c'est la première fois que je fais un éditeur (je suis plus habitué au code de jeux vidéos et projets similaires).
Donc les retours sont toujours bienvenus.

[gbdivers]

Quelques remarques en vrac :
- ça manque de const (paramètres et fonction)
- passage des QWidget par référence ? (alors que ce sont des objets polyhmorphiques et que map contient bien un pointeur)
- un manager... bouh
- FreeWindow qui n'est pas un QWidget mais qui en contient 2, c'est bizarre

En fait, j'ai l'impression que les fonctions de FreeWindowsManager sont identiques à celle QMdiArea (avec find_window en plus, donc pas besoin de cette classe ; au pire, une classe QMdiSubWindow qui permet d'avoir le menu contextuel) et FreeWindow utilise 2 QWidget (mais je vois pas pourquoi ; pourquoi ne pas avoir 1 QWidget et le détacher ou non du parent ?)

En revanche pour la fenetre externe (QWidget) je ne trouve pas de manière de fournir l'action "Dock Window" visuellement à l'utilisateur, de manière générique et le moins intrusif possible.

Un simple glissé-déposé de la fenêtre libre sur la fenêtre principale (ou une zone spécifique de la fenêtre principale, par exemple un onglet "+" en fin de liste des onglets)

[Klaim]

Quelques remarques en vrac :
- ça manque de const (paramètres et fonction)

Ok!... mais où? Je ne vois pas où ajouter du const dans ces classes ci...
En particulier par ceque le code utilisateur a besoin d'avoir accès aux QWidgets.

- passage des QWidget par référence ? (alors que ce sont des objets polyhmorphiques et que map contient bien un pointeur)

Oui parceque c'est plus un helper qu'autre chose, il n'est pas censé détenir les widgets. Notemment, ce système n'a pas le droit de détruire les widgets qu'on lui file, juste de les mettre dans une fenetre automatiquement.

En fait j'ai tendance à utiliser les références pour indiquer au développeur que les objets ont interets à rester vivant le temps de la manipulation. A priori c'est pas une mauvaise façon de voir...?

- un manager... bouh

Je veux bien un meilleur nom, d'habitude j'evite les "manager" mais là je trouve pas d'autre nom. C'est plus ou moins un "helper" mais c'est aussi vague je trouve.

- FreeWindow qui n'est pas un QWidget mais qui en contient 2, c'est bizarre

Ca dépends ce que tu entends par "c'est bizarre"?
Le role de ce système est de faire des manipulations, pas de remplacer les widgets eux même.
J'ai essayé avant de passer par de l'héritage mais ça m'est apparu inadéquate et surtout super intrusif alors que ça ne devrait pas l'être (parceque c'est une façon d'organiser des fenetres, pas vraiment du visuel).

Il se peut que l'utilsation semble obscure tel quel...
(hésitez pas a commenter ce que je suis en train de dire hein)

En gros l'idée c'est de fournir un QMdiArea qui va contenir les fenetres internes. Ensuite, peu importe comment on organise ses widgets, si on veut les afficher dans une fenetre, on les enregisre dans FreeWindowManager.
Dans mon cas je l'utilise comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
class MainWindow : public QMainWindow
{
public:
    //....
    MainWindow();
 
   void add_window( std::unique_ptr<QWidget> window );  // ici ont prends l'ownership du widget à mettre dans une fenetre
 
    // généralement on aurait aussi un 
 
private:
 
    QMdiArea m_mdi_area;
    FreeWindowManager m_window_manager; // le système de fenetre ne sait pas comment c'est à l'extérieur, isolation totale (a priori)
 
 
    std::vector< std::unique_ptr<QWidget> > m_windows; // on garde les widgets vivants jusquà ce qu'on en ai plus besoin (ou autre raison)
 
};
 
 
// ....
 
MainWindow::MainWindow() : m_window_manager( m_mdi_area ){} // hop système près
 
 
MainWindow::add_window( std::unique_ptr<QWidget> window )
{
     m_window_manager.add_window( *window ); // hop une fenetre est visible
     m_windows.push_back( std::move( window ) ); // on le garde en vie
}
 
 // et le remove est le symétrique

J'ai volontairement isolé FreeWindows de l'organisation externe, mais si c'est pas une bonne idée avec Qt, j'aimerai qu'on m'explique svp (j'ai pas d'assurance avec Qt...)

En fait, j'ai l'impression que les fonctions de FreeWindowsManager sont identiques à celle QMdiArea (avec find_window en plus, donc pas besoin de cette classe ; au pire, une classe QMdiSubWindow qui permet d'avoir le menu contextuel) et FreeWindow utilise 2 QWidget (mais je vois pas pourquoi ; pourquoi ne pas avoir 1 QWidget et le détacher ou non du parent ?)

Heu en fait pas du tout... QMdiArea gère des fenetres qui sont internes à elle même et qui ne peuvent (apparamment) pas être affichées autrement. Donc seul QMdiArea ne me permet pas de faire ce que je veux. Ou alors j'ai raté un truc?

Le second widget est en fait celui qu'on veut afficher, et on le met dans un QMdiSubWindow pour être dans la fenetre principale jusqu'à ce qu'on sorte le widget de là et qu'on l'affiche "seul" pour queça fasse une fenetre volante indépendante.

En fait j'ai d'abord utilise QMdiArea et j'ai vite vu les limites. Je n'ai fait qu'extraire les fonctionalités de mon code qui gérent les fenetres.

Je suis tout ouïe si tu as une manière plus simple d'organiser le passage en fenetre interne/externe? Ca m'apparait étrange que ce soit si pas terrible avec Qt...

Edit: Pour être clair (parceque j'ai l'impression de pas l'être), FreeWindowManager vise à aménager les fenetres, à jongler entre les fenetres, ce n'est pas un conteneur visuel, plus une sorte d'organiseur. Ah tiens ptete que c'est un meileur non?

Un simple glissé-déposé de la fenêtre libre sur la fenêtre principale (ou une zone spécifique de la fenêtre principale, par exemple un onglet "+" en fin de liste des onglets)

J'ai bien pensé à la zone de drop mais soit je dois gérer le trop sur tout le QMdiArea fournis - et alors là les fenetres très sont difficiles à manipuler sans les droper tout le temps... - , soit j'ai une zone de trop précise, comme dans VS2010, mais dans ce cas ça deviens intrusif et en plus ça suppose que je dois hériter de QMdiArea, donc c'est une galère qui me semble trop chère pour ce que c'est.

Pour les onglets ou le boutton, le souci c'est qu'il n'y a apparamment aucun moyen d'ajouter un boutton à la barre d'un QWidget, seulement celui d'un QDockWidget.
J'ai dailleurs implémenté le tout avec des QDockWidget d'abord mais ça ne marchait pas correctement en tant que fenetre externe -je ne me souviens plus exactement de la raison d'ailleurs...


Je n'arrive pas à une solution simple, ça m'étonne vraiment...