pdulvp.fr

Menu d'ouverture : les adversaires avant la table, et au même bord has been fixed.

See more details at : https://github.com/pdulvp/pdcartes-rami/issues/7

  • le menu se lit désormais « la partie, les adversaires, la table » : tout ce

qui se choisit est au-dessus des tuiles, qui lancent la partie et ferment
donc la page

  • la grille des six prend la largeur exacte de la rangée des cinq tuiles

(kBlockWidth, déduit de kTableTile) au lieu de s'étirer jusqu'au bord de
la fenêtre : les deux sections partagent un bord droit

  • le pied de page passe sous les tuiles, ses trois gestes retournés pour que

celui de la table soit le plus proche d'elles

  • seuil de défilement inchangé (~735 px de haut), mais ce qui passe sous le

pli sur une fenêtre rapetissée est maintenant la rangée des tables

Les adversaires avant la table

<sub>2026-10-24-0925-les-adversaires-avant-la-table.md — 2026-10-24 09:25</sub>

Le menu d'ouverture se lit « la partie, la table, les adversaires ». Or presser
une table est ce qui lance la partie : la règle que la page énonce elle-même --
ce qui se choisit avant se lit avant -- est tenue par la longueur et rompue par
les adversaires, qui se choisissent et sont pourtant sous le déclencheur.

Les deux sections s'échangent. La page se lit alors comme une phrase : combien
de temps, contre qui, à quelle table -- et la dernière chose de la page est
celle qui part.

Décisions

  • La hauteur ne s'y oppose pas. La grille des six fait 2x78 + 10 = 166

pixels, la rangée des tuiles 170 : l'échange ne déplace rien sous le pli, et
les tables restent atteignables sans molette.

  • Une seule ligne en bas, et ses membres retournés. Le pied de page se

retrouve sous les tuiles ; ses trois gestes passent dans l'ordre de ce qu'ils
expliquent, le dernier étant celui de la table, qui est alors juste au-dessus.
Deux lignes -- une sous la grille, une sous les tuiles -- coûteraient à la
page sa sobriété pour gagner peu.

  • Les commentaires suivent. Ceux qui disent l'ordre -- l'en-tête de

TablePicker.h, celui du pied de page -- sont faux après l'échange, et un
commentaire faux est pire qu'aucun.

Étapes

  1. [x] src/TablePicker.cpp -- la section des six remonte avant celle des

tables ; les écarts suivent (kSectionGap sous la grille, les 12
pixels sous les tuiles).

  1. [x] src/TablePicker.cpp -- le pied de page : membres retournés, et son

commentaire qui dit désormais sous quoi il se tient.

  1. [x] src/TablePicker.h -- l'en-tête de classe : « ce qui répond à

"contre qui" » n'est plus en dessous.

  1. [x] Bâtir en série, et regarder la page.

Vérifié

Le menu rendu hors écran, à la taille d'ouverture 1220x850 : la page se lit
« LA PARTIE / LES ADVERSAIRES / LA TABLE », les cinq tuiles en dernier, le pied
de page sous elles avec ses membres retournés. Tout tient sans défilement.

Le seuil mesuré : la page entière tient jusqu'à 735 pixels de haut environ, en
deçà la barre de défilement paraît. Ce seuil n'a pas bougé -- les deux sections
font la même hauteur -- mais ce qui passe sous le pli, si : c'étaient les six,
ce sont maintenant les tuiles, c'est-à-dire le bouton de départ. À 1220x620 il
faut donc une molette pour partir, là où il en fallait une pour inviter. La
fenêtre s'ouvre à 850 et aucune taille minimale n'est posée.

À voir si ça gêne

Si le défilement pour atteindre les tables ennuie sur une fenêtre rapetissée,
le remède n'est pas de revenir en arrière mais de poser une hauteur minimale à
la fenêtre, qui n'en a aucune aujourd'hui (MainWindow.cpp:162 ne fait que
resize).

La grille des six à la largeur des cinq

<sub>2026-10-24-0935-la-grille-des-six-a-la-largeur-des-cinq.md — 2026-10-24 09:35</sub>

Suite de [[les-adversaires-avant-la-table]] : maintenant que les six sont
juste au-dessus des cinq, on voit que leur grille s'étire sur toute la largeur
de la fenêtre pendant que la rangée des tuiles garde la sienne. Les deux
sections ne partagent plus de bord, et une carte de 373 pixels pour un nom et
une barre d'expérience est surtout du vide.

La grille prend la largeur exacte de la rangée des tuiles : 5 x 188 + 4 x 10 =
980 pixels, soit 320 par carte sur trois colonnes.

Décisions

  • La largeur se calcule, elle ne s'écrit pas. Elle sort de kTableTile et

de l'écart commun aux deux sections : changer la taille d'une tuile doit
déplacer les cartes avec elle, sans que personne ait à y penser.

  • L'écart de 10 devient un nom. Il est écrit deux fois en littéral, une

fois pour les tuiles et une fois pour la grille, et c'est justement lui qui
fait que les deux largeurs tombent juste.

  • Des cartes à largeur fixe, et un ressort à droite -- comme les tuiles :

sur une fenêtre étroite, les deux sections débordent ensemble et la même
barre horizontale les rattrape, au lieu que l'une rétrécisse et l'autre non.

Étapes

  1. [x] src/TablePicker.cpp -- kFeltGap, la largeur de la rangée des

tuiles, et celle d'une carte qui s'en déduit.

  1. [x] src/TablePicker.cpp -- les cartes à cette largeur, ressort en

quatrième colonne, et le commentaire qui dit pourquoi.

  1. [x] Bâtir en série, et regarder la page large et étroite.

Vérifié

Rendu hors écran à 1220x850 et à 1600x850 : la grille des six fait 980 pixels
dans les deux cas, et son bord droit tombe sur celui de la cinquième tuile.
Les filets des titres de section, eux, continuent jusqu'au bord de la page --
ils appartiennent à la page et non au bloc.

Le détail qui a coincé

kTableTile était un const QSize, pas un constexpr, et la largeur du bloc
ne pouvait donc pas s'en déduire à la compilation. Corrigé à la source plutôt
que contourné par un littéral répété.

<sub>Filed by prel from the completed plans at commit time.</sub>