UX: Essai CardView + FamilyTreeView

International Français (French)
, ,
1

:uk: English below

:clipperton_island:
Il y a quelques jours j’essayais FamilyTreeView de @ztlxltl en faisant une petite vidéo de cet essai [fr], aujourd’hui je me suis demandé si je pouvais profiter à la fois du monde graphique et du monde plus standard en mode fiche grâce à CardView de @cdhorn.

Voici donc la seconde vidéo [fr] qui résulte de cet essai. Gramps à l’air de souffrir de ces actions alors que mon PC est relativement neuf (un an) et performant (la version Gramps V6 améliorera t’elle ce genre de comportement ?)

Idée: Il manque peut-être du coté de FamilyTreeView d’un mode Lock de la configuration établie afin de pas avoir à la refaire à chaque rafraichissement des données des personnes qui sont affichées. Ce mode Lock devrait toute fois permettre de rafraîchir les données des personnes affichées tout en conservant intacte la disposition de l’affichage

Idée #2: ce serait pratique que toutes les vues de Gramps puissent être détachables comme les vues de CardView afin de pouvoir voir une vue d’un type alors qu’on est dans une autre d’un autre type

Conclusion: avec de tels outils, Gramps n’est pas un logiciel nocode responsive mais presque !

:uk:
A few days ago I was trying FamilyTreeView from @ztlxltl by making a short video of this test [fr], today I wondered if I could enjoy both the graphical world and the more standard world in card mode thanks to CardView from @cdhorn.

Here is the second video [fr] that results from this test. Gramps seems to suffer from these actions while my PC is relatively new (one year) and powerful (will Gramps V6 improve this kind of behavior?)

Idea: FamilyTreeView may lack a Lock mode of the established configuration so as not to have to redo it each time the data of the people who are displayed is refreshed. This Lock mode should still allow to refresh the data of the people displayed while keeping the layout of the display intact

Idea #2: It would be handy if all Gramps views could be detachable like CardView views so you could see a view of one type while in another of another type

Conclusion: with such tools, Gramps is not a responsive nocode software but almost!

2

:fr:

[Note : la version française est traduite automatiquement.]

@PLegoux
Merci d’avoir enregistré les vidéos. Même si je ne vous comprends pas, j’ai une meilleure impression de la façon dont d’autres personnes utilisent FamilyTreeView, en particulier en combinaison avec d’autres modules complémentaires.
Je ne sais pas pourquoi l’arbre prend autant de temps à se charger dans votre vidéo avec les deux modules complémentaires. Je dois absolument améliorer les performances. Cela a probablement empiré lors des dernières mises à jour (par exemple, depuis la prise en charge des filtres, j’ai dû prendre en charge un autre callback qui semble être appelé en même temps qu’une autre méthode et je pense que cela fait que l’arbre est construit deux fois avant d’être affiché). Je dois essayer de contourner ces problèmes.
Ce que je vois dans vos vidéos, c’est que les expanseurs de la fratrie pourraient aussi être placés au-dessus de la personne, et pas seulement sous les parents, pour être plus faciles à atteindre.
Comme je ne vous comprends pas, il serait bon que vous (ou quelqu’un d’autre) dressiez la liste des principaux problèmes/confusions abordés dans les vidéos.
Si vous ne le faites pas dans la vidéo (je ne comprends pas le français !), lorsque vous partagez la vidéo, veuillez mentionner que l’addon est encore en cours de développement et ne doit pas être considéré comme stable.

Quant à vos idées :
Idée 1 : Réinitialiser l’arbre moins souvent est également sur ma liste de choses à faire.
Idée 2 : C’est raisonnable. Tant qu’il n’y a pas d’option à partir de Gramps lui-même, je peux regarder comment supporter le détachement de FamilyTreeView. Cela vous aiderait-il ?

:gb:

[Note that the French version is automatically translated.]

Thanks for recording the videos. Even though I don’t understand you, I get a better impression of how other people use FamilyTreeView, especially in combination with other addons.
I’m not sure why the tree takes so long to load in your video with both addons. I definitely need to improve the performance. It probably got worse in the last updates (e.g. since the filter support I had to support another callback which seems to be called together with another method and I think this causes the tree to be built twice before being shown). I need to try to work around these issues.
What I see is that the sibling expanders could also be placed above the person, not just below the parents, to be easier to reach.
Since I don’t understand you, it would be great if you (or someone else) could list the main problems/confusions discussed in the videos.
If you don’t do it in the video (I don’t understand French!), when you share the video, please mention that the addon is still under development and should not be considered stable.

As for your ideas:
Idea 1: Resetting the tree less often is also on my todo list.
Idea 2: This is reasonable. As long as there is no option from Gramps itself, I can look into how to support detaching FamilyTreeView, if that would help.

1 Like
3

:clipperton_island:Merci, je vais vous fournir les quelques problèmes rencontrés, il faut que je revois ma vidéo / :uk:Thank you, I will provide you with the few problems encountered, I need to watch my video again

1 Like
4

:fr: Est-il possible de mettre la vidéo sur YouTube ? Il y a des options pour générer automatiquement des sous-titres… et la traduction des sous-titres.

:uk: Is it possible to put the video up on YouTube? It has options to auto-generate close captioning… and to translate that close captioning.

5

@PLegoux
:fr: Bien que vous soyez libre de faire ce que vous voulez avec vos vidéos, je vous demande instamment de ne pas faire trop de publicité pour la version bêta.
Je pense que vous pouvez également marquer une vidéo YouTube comme non répertoriée afin qu’elle ne soit accessible que par un lien que vous partagez. Mais je ne suis pas sûr que les sous-titres et la traduction fonctionneront dans ce cas.

:gb: While you are free to do whatever you want with your videos, I strongly ask you not to advertise the beta version too much.
I think you can also mark a youtube video as unlisted so that it can only be accessed through a link you share. But I’m not sure if the subtitles and translation will work in that case.

1 Like
6

:fr: Cela ressemble à une bonne expérience vidéo en une seule phrase !

:gb: Sounds like that would be a good single-sentence video experiment!

7

:fr:
J’ai regardé de plus près le temps de chargement et les retards dans votre vidéo et j’ai essayé de reconstruire votre configuration avec FamilyTreeView et CardView. Pour une raison quelconque, je n’obtiens pas ces délais importants. Mais ce que j’ai remarqué dans votre vidéo :

  • FTV n’affiche qu’un petit arbre (seulement 32 personnes) lorsque vous l’ouvrez pour la première fois (à 0:45) et il faut environ 2 secondes à l’addon pour construire l’arbre.
  • Si vous éditez l’événement et cliquez sur « Valider » (à 2:29), il faut environ 18 secondes pour fermer la fenêtre d’édition, puis environ 1 seconde pour construire l’arbre, toujours avec seulement 32 personnes.
  • Lorsque FTV commence à construire l’arbre, il change le curseur de la souris en une icône d’attente (cela ne fonctionne pas sur Ubuntu dans mes tests, mais sur Windows). La prochaine fois que vous confirmez la fenêtre d’édition de l’événement (à 3:42), le curseur de la souris se transforme en cercle d’attente uniquement lorsque Windows détecte que la fenêtre d’édition ne répond pas à 3:48, pas avant. FTV n’a donc probablement pas encore reçu le signal de reconstruire l’arbre (si c’était le cas, l’icône d’attente de la souris apparaîtrait plus tôt ou toutes les fenêtres de Gramps s’afficheraient comme ne répondant pas) et le retard est causé par la fenêtre d’édition ou CardView qui traite la fermeture de la fenêtre d’édition. De plus, l’état « ne pas répondre » prend fin lorsque FTV reconstruit l’arbre, et Gramps redevient « ne pas répondre » une fois que FTV a terminé et que la fenêtre d’édition doit encore se fermer et que la liste d’événements CardView doit être mise à jour.

Bien sûr, il ne s’agit que d’observations et d’indications tirées de votre vidéo, mais j’ai l’impression que le retard n’est pas causé par FamilyTreeView.

Pourriez-vous essayer le même processus (même personne, même événement, mêmes clics) que dans la vidéo, mais avec une vue différente/non liée en arrière-plan, par exemple la liste des images dans votre base de données (idéalement redémarrez Gramps et n’ouvrez pas FamilyTreeView avant de faire le test). Je pense qu’il y aura également de tels retards.

:gb:
I took a closer look at the loading time and delays in your video and I tried to reconstruct your setup with FamilyTreeView and CardView. For some reason, I don’t get those big delays. But what I noticed from your video:

  • FTV only shows a small tree (only 32 people) when you first open it (at 0:45) and it takes about 2 seconds for the addon to build the tree.
  • If you edit the event and click “Valider” / OK (at 2:29), it takes about 18 seconds to close the edit window and then about 1 second to build the tree, again with only 32 people.
  • When FTV starts building the tree, it changes the mouse cursor to a wait icon (this doesn’t work on Ubuntu in my tests, but on Windows). The next time you confirm the edit window of the event (at 3:42), the mouse cursor changes to the wait circle only when Windows detects the edit window as not responding (Ne réspond pas) at 3:48, not before. So FTV has probably not yet received the signal to rebuild the tree (if this were the case, the wait mouse icon would appear earlier or all Gramps windows would show as not responding) and the delay is caused by the edit window or CardView processing the close of the edit window. Also, the “not responding” state ends when FTV rebuilds the tree, and Gramps gets “not responding” again after FTV is finished and the edit window still needs to close and the CardView event list needs to update.

Of course, these are just observations and indications from your video, but my feeling is that the delay is not caused by FamilyTreeView.

Could you try the same process (same person, same event, same clicks) as in the video, but with a different/unrelated view in the background, e.g. the list of images in your database (ideally restart Gramps and don’t open FamilyTreeView before you do the test). My guess is that there will be such delays as well.

8

Je ne pense pas non plus que les retards proviennent de FTV, pas non plus de CV, mais plutôt du fait d’éditer une personne en utilisant les 2 en même temps. Et non, je n’ai pas ce genre de retard si j’utilise ces outils ou d’autres individuellement

I also don’t think the delays are from FTV, nor from CV, but rather from editing a person using both at the same time. And no, I don’t have this kind of delay if I use these tools or others individually

1 Like
9

@PLegoux
:fr: Je pense que vous avez été un peu dérangé par l’ouverture de la « minimap » après chaque clic. Depuis FTV v0.1.69, le bug provoquant la réapparition de la minimap est corrigé.

:uk: I think you were a bit disturbed by the minimap opening at after each click. Since FTV v0.1.69 the bug causing the minimap to reappear is fixed.

2 Likes
10

@PLegoux
:france:
Dans votre vidéo, il y a de longs délais lorsque l’on travaille en parallèle avec FTV et CardView. Auparavant, j’ai supposé que cela n’était pas dû au FTV. Au cours des dernières semaines, j’ai découvert quelques problèmes de performance et j’ai mis en place des correctifs, non pas tant au niveau de la construction de l’arbre FTV, mais au niveau du moment et de la fréquence de reconstruction de l’arbre. Entre autres choses, Gramps ne devrait plus se bloquer (du moins pas à cause du FTV) et l’arbre ne devrait plus être rechargé plusieurs fois dans certains cas.

Je vous demande de répéter votre expérience avec la dernière version de FTV. Vous n’avez pas vraiment besoin d’enregistrer une autre vidéo, mais veuillez nous indiquer si les performances se sont améliorées ou non, en particulier dans le cas où vous mettez à jour un événement par le biais de CardView avec FTV en arrière-plan. Comme je l’ai écrit précédemment, je n’ai pas été en mesure de reproduire le problème dans votre vidéo avec la version de FTV que vous avez utilisée dans la vidéo, je ne peux donc pas vérifier si le problème est résolu avec une version plus récente de FTV.

PS : S’il y a toujours un retard et que cela prend plus d’une seconde, envisagez d’activer l’option expérimentale FTV « Afficher le dialogue de progression ». Une boîte de dialogue s’affichera si la construction de l’arbre prend plus d’une seconde.

:united_kingdom:
In your video, there are long delays when working with FTV and CardView in parallel. Previously, I assumed that this was not due to FTV. In the last few weeks I’ve found some performance issues and implemented fixes for them, not so much in building the FTV tree, but in when/how often it rebuilds the tree. Among other things, Gramps should no longer freeze (at least not caused by FTV) and the tree should no longer reload multiple times in some cases.

I kindly ask you to repeat your experiment with the latest version of FTV. You don’t really need to record another video, but please report back whether the performance has improved or not, especially in the case where you update an event through CardView with FTV in the background. As I wrote earlier, I was not able to reproduce the problem in your video with the version of FTV you used in the video, so I cannot check if the problem is fixed with a newer version of FTV.

PS: If there is still a delay and it takes more than about 1 second, consider enabling the experimental FTV option “Display progress dialog”. A dialog will appear if the tree takes longer than about 1 second to build.

1 Like