Les nouveaux blocs dans le page à page sont effectivement plus simples à déplacer ou à tourner.
Par contre c’est tellement simple à tourner qu’on a du mal à remettre un bloc à l’horizontal si on l’a tourné.
Est-qu’il serait possible de mettre des « crans » sur les angles de rotation ? Par exemple pour les remettre bien à l’horizontal sans trop se casser la tête.
Edit : Je viens de jeter un oeil sur tldraw ( https://www.tldraw.com/ ) qui est en cours d’intégration à BBB pour voir comment ça marchait : ça passe par un raccourci clavier, je peux tourner librement un bloc mais si je maintiens Maj enfoncée, la rotation n’est pas continue mais avec des « crans »
Le menu des bloc de texte prend beaucoup de place. Ça n’est pas gênant sur un grand bloc de texte mais assez complexe sur des petits blocs, surtout si on en a plusieurs ouvert.
Est qu’on ne pourrait pas avoir qu’un seul menu pour la page et qui ne soit pas DANS le bloc mais à l’extérieur ?
Oui, il faudrait que ça marche aussi en mobile et smartphone (donc pas que le raccourci « maj », qui devra être explicité aussi d’ailleurs) !
Est-ce que je reprend le système d’arrondi ? Entre -5 et 5 degrés de rotation, ça amène à 0 et pareil pour 90, 180 et 270 degrés ?
Je vais aussi remettre le panneau qui indique clairement les valeurs : position, taille et rotation (qui manquait sur dodoc 9). Ça permettra de régler finement si besoin.
Oui ça paraît nécessaire Le plus simple en terme de dev serait que l’édition de texte se fasse dans une fenêtre modale, mais ça veut dire qu’on voit plus le texte « en place ». Pas génial mais bcp plus simple à gérer que de « déplacer » la barre d’édition ailleurs. Qu’en penses-tu ?
(merci pour la simulation, ça fait avancer le schmilblick !)
Quant tu parles d’une fenêtre modale, c’est comme dans Inkscape ? On tape son texte dans une autre fenêtre qui est liée à l’outil texte et au bloc de texte dans son document et on actualise en cliquant sur « appliquer », c’est bien ça ?
Exact oui ! c’est ça.
D’ailleurs si y a la place je peux essayer de la mettre à côté pour qu’on continue de voir la page. Je vais tester, c’est quand meme pas idéal…
OK, j’avais oublié le tactile. Donc oui pour un cran juste pour la position horizontale et verticale comme dans la V9.
Et pour la barre d’édition, ce que je trouve gênant c’est surtout que le texte n’est plus lisible si la barre est dans le bloc.
La version 9 était plus pratique avec la barre au dessus du bloc. Si la barre s’active uniquement sur UN seul bloc actif ça pourrait simplifier non ?
Les options qui s’ouvrent en haut sur le côté par exemple ça fonctionne bien
En place ! Il est de 5 degrés dans chaque direction (de 85 à 95 degrés → 90 degrés, etc.). On pourra le contourner avec le réglage par la valeur dans le panneau qui récapitule les informations d’un média, à venir.
Il faut que je fasse des tests oui Il y a pas mal de soucis à l’afficher au-dessus :
si le bloc est très peu large, elle le sera aussi
si le bloc est tout en haut de la page, elle n’est pas accessible
sur un téléphone c’est franchement pas pratique
L’édition dans une modale résout complètement ces problèmes, mais n’est pas très agréable/intuitive quand l’écran est suffisamment large (disons, au-dessus de 900 pixels CSS de large – tablette en paysage, portable 13 pouces et +, etc.).
Gros taf ! Garde ça sous le coude mais ça sera probablement plutôt pour la v10.1
Je suis en train de tester la publication page à page.
Voici la liste des bugs / remarques que j’ai repérés.
Pour info je suis sur Chromium 88.0.4324.0
Une fois la publication crée je ne peux plus l’ouvrir. Erreur dans la console : « TypeError: this.publimodule.$path.split(…).at is not a function »
J’ai un bug d’affichage dans l’édition des textes avec ce message d’erreur dans la console : « TypeError: this.publimodule.$path.split(…).at is not a function »
En double page quand on zoom beaucoup on ne peut pas scroller et atteindre horizontalement et atteindre toutes les zones de la page de gauche notamment
En double page on ne peut passer directement de l’édition la page de gauche à la page de droite, on peut seulement aller à la double page précédente ou suivante
Il faudrait trouver un moyen de pouvoir mettre une image ou un texte à cheval sur les deux pages. Je pense que la technique la plus simple (non la moins lourde) et de cloner l’élément pour donner l’illusion qu’il est sur les deux pages à la fois.
Sinon le reste est top !
Hâte des prochaines étapes.
Ok, c’est logique : y a pas Array.at avant Chromium 92. Chromium 88 date de janvier 2021.
La liste des navigateurs pris en charge :
> 1%
last 2 versions
not dead
not ie 11
Ce qui donne concrètement les navigateurs suivants : Browserslist
Sur dodoc 9 le fichier JS compilé l’était pour un maximum de navigateur, ce qui l’alourdissait beaucoup (3,38mo de JS non-gzippé à télécharger pour ouvrir dodoc).
Sur dodoc 10, tout le système a été revu pour être beaucoup plus léger (environ 600ko de JS gzippé pour le JS principal et quelques centaines pour chaque page ou modules principaux). Donc IE 11 n’est plus pris en charge, ainsi que des navigateurs pas à jour depuis un moment. Mais c’est visiblement trop restrictif, 1 an et demi c’est pas énorme non plus.
À court terme je peux ne pas utiliser Array.at très facilement (c’est juste plus élégant pour récupérer le dernier élément d’un tableau : .at(-1); ).
Mais à voir si on ajoute un last 3 years à la config pour avoir toujours un JS compatible avec des navigateurs de moins de 3 ans par exemple. T’en penses quoi ?
Je viens de tester, la différence en terme de poids est négligeable :
actuellement :
et avec last 3 years en plus :
Je change la config et tu me confirmes si ça passe sur Chromium 88 ? Par contre ça veut dire que t’as 1 an pour mettre à jour ton Chromium, les maj de dodoc 10 à partir de février 2024 ne seraient plus compatibles Chromium 88 de Janvier 2023
Ouai, en fait je me demande si c’est bien utile de pouvoir zoomer au-dessus de 1 (100%). J’ai un facteur de conversion CM → PX de 30, je peux l’augmenter un peu et limiter le zoom à 1 et ça évitera ce soucis. Ou alors intégrer un système de nav en 2 dimensions, pour abandonner le scroll natif pas forcément adapté à ça. Tu proposes quoi ?
Soucis de CSS je regarderai.
Toi-même tu sais que c’est hyper délicat
Une possibilité : exporter chaque planche comme une image, puis couper en deux chaque image au milieu, et faire un PDF avec cette suite d’images (voir faire une imposition sur cette base là). Gros taf, faisable et je ne sais pas si c’est très robuste. Et ça fait des PDF à base d’image (pas grave pour l’impression).
Sinon dupliquer l’élément, le glisser sur la page mitoyenne, et ajuster le cadrage (pas encore possible). Pas simple non plus mais ça demande pas de revoir tout le système d’export !
Je viens de tester en vitesse la version actuelle. J’apprécie la possibilité de changer la taille et la position des images dans un récit. ça manquait dans la version 9. Sinon, je ne sais pas si quelqu’un a remarqué, mais sous Safari, les icônes du menu d’édition de texte restent blanches, vides. ça marche normalement sous Chrome, par contre. Comme on utilise des iPads, en classe, en plus des ordis sous Linux, ça risque de coincer!
Un petit détail :
Pour le time-lapse on peut mettre un nombre négatif.
Il faudrait bloquer le minimum à 1 comme le retardateur.
Et si le nombre de secondes est à 3 chiffres et + on ne voit pas tout. Pour des time-lapse long ça peut-être utile de dépasser les 99 s et donc d’avoir une fenêtre qui s’agrandit plus le nombre est grand.
D’après ce que j’observe la date indiquée dans « Dernière modification » d’un projet ne s’actualise que si on modifie les métadonnées du projet.
Est-ce que ça ne serait pas plus intéressant que cette date s’actualise à chaque ajout ou modification DANS le projet (capture / collecte / remix / publication) ?
Ça permettrait de savoir si quelqu’un a travaillé récemment dans le projet et par la suite de pouvoir trier les projets par cette date de « dernière modification »
