LibreOffice 4.0.5 / Impress inutilisable

fr-users
#21

Bonjour,

[...]

En tous cas, je trouve que tout cela va trop vite. Une version est à
peine stabilisée, qu'on vous dit qu'il faut en changer, pour se taper
les bugs de la nouvelle.

Il y a une version nouvelle tous les six mois. Entre deux versions ce ne
sont que des bugfix sans introduction de nouveautés fonctionnelles.

Oui, mais la durée pendant laquelle la version est dite recommandée,
n'est que d’un ou deux mois. Lorsque la 4.0.6 sera publiée et finalisée,
les bugs découverts ne seront corrigés que sur la branche 4.1 et dans un
mois on nous dira que c'est celle-là qu'il faut installer.

Il devrait y a voir des versions à vie longues
pour ceux qui sont très prudents et qui veulent quelque chose de très
stable. par exemple, il faudrait peut être continuer la 3.6 et proposer
une version 3.6.8 et 3.6.9. puis faire de même avec la 4.1

Il faut choisir entre avoir des développeurs bénévoles nombreux et
entretenir une version LTS. Entretenir une version LTS suppose que les
développeurs passent une plus grande partie de leur temps à corriger des
bugs. Et ce n'est pas avec ça qu'un développeur se fait plaisir dans un
projet de développement logiciel. Et si les développeurs ne se font pas
plaisir, il n'y a plus de développeurs, sauf ceux qui sont payés
suffisamment cher pour compenser l'ennui.

Bonne journée
JBF

Oui, je comprends bien. Mais, des utilisateurs qui désertent le
logiciel, c'est aussi du travail pour rien au niveau des développeurs.

Il manque actuellement une chaîne entre les développeurs et les
utilisateurs, ce sont les testeurs. Plus de 1000 bugs non triés, des
versions beta et rc que nous sommes trop peu à tester et aussi tôt que
tu le fais par exemple avec la 4.2. Tant que nous n'aurons pas résolu ce
point, cela sera frustrant pour tout le monde, et je dis bien tout le
monde. Nous essayons de simplifier l'assistant de rapport de bug, de le
traduire, de mettre des versions compilées à disposition, des moyens de
traquer les régressions, de relancer les tests manuels, etc... mais cela
vient petit à petit et cet effort doit viser à faire s'investir plus de
monde.

Je ne dis pas que toutes les versions doivent avoir une vie longue, je
dis que quelques versions doivent avoir une vie plus longue que les
autres. par exemple, la 3.6 pour ceux qui ne veulent pas passer à la 4

ou la 4.1, car la 4.0 me semble une version un peu incomplète (sentiment
subjectif)

Je ne demande pas non plus que des bugs spécifiques à ces versions
soient recherchés et développés, mais que les correctifs des versions en
cours de développement soient 'backportés' (drôle de mot, retro-intégrés
?) sur ces seules versions. Ce ne pas zéro au niveau travail, mais le
gros du boulot a été fait en résolvant le bug.

Quand c'est possible, les développeurs le font, mais quand c'est un
risque trop important, que c'est trop invasif dans le code et pourrait
avoir des effets collatéraux sur d'autres parties, ils ne prennent pas
ce risque.

Concrètement, actuellement, dans l'état de la 4.0.6, je me demande quoi
faire. Je travaille beaucoup avec impress avec mes élèves . Je mets
cette version et je leur explique comment changer leurs habitudes de
travail sur ce logiciel ou je passe à la 4.1.? Quitte a découvrir
quelques surprises indésirables (elle a les mêmes problèmes avec
impress, des fonctions en plus et des surprises aussi). Sans parler
l'instabilité de cette version (4.0.6) en travaillant avec les tableaux.
Où alors, je reste sur la 3.6.

La 4.0.6 est encore en RC1, il faut donc pour le moment la laisser en RC
et corriger ce que tu as remonté. Si la 4.1, dans ton usage, est plus
stable, c'est celle sans doute que tu dois utiliser.

par ailleurs, mon document met 35 secondes à s'ouvrir avec la dernière
4.2 en développement, contre 5 secondes environ avec la 4.0.6 (SSD)

Merci pour tes retours et tes tests, je n'ai pas l'environnement
correspondant pour confirmer, mais d'autres pourront peut être sur la
liste qa@fr.

À bientôt
Sophie

#22

Bonjour,

[...]

En tous cas, je trouve que tout cela va trop vite. Une version est à
peine stabilisée, qu'on vous dit qu'il faut en changer, pour se taper
les bugs de la nouvelle.

Il y a une version nouvelle tous les six mois. Entre deux versions ce ne
sont que des bugfix sans introduction de nouveautés fonctionnelles.

Oui, mais la durée pendant laquelle la version est dite recommandée,
n'est que d’un ou deux mois. Lorsque la 4.0.6 sera publiée et finalisée,
les bugs découverts ne seront corrigés que sur la branche 4.1 et dans un
mois on nous dira que c'est celle-là qu'il faut installer.

Il devrait y a voir des versions à vie longues
pour ceux qui sont très prudents et qui veulent quelque chose de très
stable. par exemple, il faudrait peut être continuer la 3.6 et proposer
une version 3.6.8 et 3.6.9. puis faire de même avec la 4.1

Il faut choisir entre avoir des développeurs bénévoles nombreux et
entretenir une version LTS. Entretenir une version LTS suppose que les
développeurs passent une plus grande partie de leur temps à corriger des
bugs. Et ce n'est pas avec ça qu'un développeur se fait plaisir dans un
projet de développement logiciel. Et si les développeurs ne se font pas
plaisir, il n'y a plus de développeurs, sauf ceux qui sont payés
suffisamment cher pour compenser l'ennui.

Bonne journée
JBF

Oui, je comprends bien. Mais, des utilisateurs qui désertent le
logiciel, c'est aussi du travail pour rien au niveau des développeurs.

Il manque actuellement une chaîne entre les développeurs et les
utilisateurs, ce sont les testeurs. Plus de 1000 bugs non triés, des
versions beta et rc que nous sommes trop peu à tester et aussi tôt que
tu le fais par exemple avec la 4.2. Tant que nous n'aurons pas résolu ce
point, cela sera frustrant pour tout le monde, et je dis bien tout le
monde. Nous essayons de simplifier l'assistant de rapport de bug, de le
traduire, de mettre des versions compilées à disposition, des moyens de
traquer les régressions, de relancer les tests manuels, etc... mais cela
vient petit à petit et cet effort doit viser à faire s'investir plus de
monde.

Je ne dis pas que toutes les versions doivent avoir une vie longue, je
dis que quelques versions doivent avoir une vie plus longue que les
autres. par exemple, la 3.6 pour ceux qui ne veulent pas passer à la 4

ou la 4.1, car la 4.0 me semble une version un peu incomplète (sentiment
subjectif)

Je ne demande pas non plus que des bugs spécifiques à ces versions
soient recherchés et développés, mais que les correctifs des versions en
cours de développement soient 'backportés' (drôle de mot, retro-intégrés
?) sur ces seules versions. Ce ne pas zéro au niveau travail, mais le
gros du boulot a été fait en résolvant le bug.

Quand c'est possible, les développeurs le font, mais quand c'est un
risque trop important, que c'est trop invasif dans le code et pourrait
avoir des effets collatéraux sur d'autres parties, ils ne prennent pas
ce risque.

C’est quelque chose que je comprends parfaitement, mais ce n'est pas ce qui est fait (enfin, si, c'est fait, les patchs sont intégrés, mais il n'y a pas de publication de version alors que 95% du boulot est fait) c'est donc qu'il y a une volonté politique d'avancer à marche forcée.

Concrètement, actuellement, dans l'état de la 4.0.6, je me demande quoi
faire. Je travaille beaucoup avec impress avec mes élèves . Je mets
cette version et je leur explique comment changer leurs habitudes de
travail sur ce logiciel ou je passe à la 4.1.? Quitte a découvrir
quelques surprises indésirables (elle a les mêmes problèmes avec
impress, des fonctions en plus et des surprises aussi). Sans parler
l'instabilité de cette version (4.0.6) en travaillant avec les tableaux.
Où alors, je reste sur la 3.6.

La 4.0.6 est encore en RC1, il faut donc pour le moment la laisser en RC
et corriger ce que tu as remonté. Si la 4.1, dans ton usage, est plus
stable, c'est celle sans doute que tu dois utiliser.

La 4.1 est plus stable, encore que ce n'est pas avec cette version que j'ai travaillé sur mon diaporama, je ne sais donc pas ce que cela donne, mais les problèmes de sélection de cadres texte sont plus présents
c'est pour cela que je suis revenu sur la 4.0. mes automatismes sont fortement ancrés et je n'en change pas facilement. Et puis, c'est plus long. faire echap avant de sélectionner le cadre, c'est une étape de plus. Rester longtemps appuyé sur le clic c'est plus long et ça ne fonctionne pas toujours.

#23

Bonjour,

[...]

En tous cas, je trouve que tout cela va trop vite. Une version est à
peine stabilisée, qu'on vous dit qu'il faut en changer, pour se taper
les bugs de la nouvelle.

Il y a une version nouvelle tous les six mois. Entre deux versions ce ne
sont que des bugfix sans introduction de nouveautés fonctionnelles.

Oui, mais la durée pendant laquelle la version est dite recommandée,
n'est que d’un ou deux mois. Lorsque la 4.0.6 sera publiée et finalisée,
les bugs découverts ne seront corrigés que sur la branche 4.1 et dans un
mois on nous dira que c'est celle-là qu'il faut installer.

Il devrait y a voir des versions à vie longues
pour ceux qui sont très prudents et qui veulent quelque chose de très
stable. par exemple, il faudrait peut être continuer la 3.6 et proposer
une version 3.6.8 et 3.6.9. puis faire de même avec la 4.1

Il faut choisir entre avoir des développeurs bénévoles nombreux et
entretenir une version LTS. Entretenir une version LTS suppose que les
développeurs passent une plus grande partie de leur temps à corriger des
bugs. Et ce n'est pas avec ça qu'un développeur se fait plaisir dans un
projet de développement logiciel. Et si les développeurs ne se font pas
plaisir, il n'y a plus de développeurs, sauf ceux qui sont payés
suffisamment cher pour compenser l'ennui.

Bonne journée
JBF

Oui, je comprends bien. Mais, des utilisateurs qui désertent le
logiciel, c'est aussi du travail pour rien au niveau des développeurs.

Il manque actuellement une chaîne entre les développeurs et les
utilisateurs, ce sont les testeurs. Plus de 1000 bugs non triés, des
versions beta et rc que nous sommes trop peu à tester et aussi tôt que
tu le fais par exemple avec la 4.2. Tant que nous n'aurons pas résolu ce
point, cela sera frustrant pour tout le monde, et je dis bien tout le
monde. Nous essayons de simplifier l'assistant de rapport de bug, de le
traduire, de mettre des versions compilées à disposition, des moyens de
traquer les régressions, de relancer les tests manuels, etc... mais cela
vient petit à petit et cet effort doit viser à faire s'investir plus de
monde.

Je ne dis pas que toutes les versions doivent avoir une vie longue, je
dis que quelques versions doivent avoir une vie plus longue que les
autres. par exemple, la 3.6 pour ceux qui ne veulent pas passer à la 4

ou la 4.1, car la 4.0 me semble une version un peu incomplète (sentiment
subjectif)

Je ne demande pas non plus que des bugs spécifiques à ces versions
soient recherchés et développés, mais que les correctifs des versions en
cours de développement soient 'backportés' (drôle de mot, retro-intégrés
?) sur ces seules versions. Ce ne pas zéro au niveau travail, mais le
gros du boulot a été fait en résolvant le bug.

Quand c'est possible, les développeurs le font, mais quand c'est un
risque trop important, que c'est trop invasif dans le code et pourrait
avoir des effets collatéraux sur d'autres parties, ils ne prennent pas
ce risque.

C’est quelque chose que je comprends parfaitement, mais ce n'est pas ce qui est fait (enfin, si, c'est fait, les patchs sont intégrés, mais il n'y a pas de publication de version alors que 95% du boulot est fait) c'est donc qu'il y a une volonté politique d'avancer à marche forcée.

Par exemple, sur la 3.5, après la 3.5.7, ce sont près de 80 patchs qui ont été intégrés à cette branche. Il manquait combien d'heures de travail pour publier une 3.5.8 ?

#24

Bonjour,

[...]

En tous cas, je trouve que tout cela va trop vite. Une version est à
peine stabilisée, qu'on vous dit qu'il faut en changer, pour se taper
les bugs de la nouvelle.

Il y a une version nouvelle tous les six mois. Entre deux versions ce ne
sont que des bugfix sans introduction de nouveautés fonctionnelles.

Oui, mais la durée pendant laquelle la version est dite recommandée,
n'est que d’un ou deux mois. Lorsque la 4.0.6 sera publiée et finalisée,
les bugs découverts ne seront corrigés que sur la branche 4.1 et dans un
mois on nous dira que c'est celle-là qu'il faut installer.

Il devrait y a voir des versions à vie longues
pour ceux qui sont très prudents et qui veulent quelque chose de très
stable. par exemple, il faudrait peut être continuer la 3.6 et proposer
une version 3.6.8 et 3.6.9. puis faire de même avec la 4.1

Il faut choisir entre avoir des développeurs bénévoles nombreux et
entretenir une version LTS. Entretenir une version LTS suppose que les
développeurs passent une plus grande partie de leur temps à corriger des
bugs. Et ce n'est pas avec ça qu'un développeur se fait plaisir dans un
projet de développement logiciel. Et si les développeurs ne se font pas
plaisir, il n'y a plus de développeurs, sauf ceux qui sont payés
suffisamment cher pour compenser l'ennui.

Bonne journée
JBF

Oui, je comprends bien. Mais, des utilisateurs qui désertent le
logiciel, c'est aussi du travail pour rien au niveau des développeurs.

Il manque actuellement une chaîne entre les développeurs et les
utilisateurs, ce sont les testeurs. Plus de 1000 bugs non triés, des
versions beta et rc que nous sommes trop peu à tester et aussi tôt que
tu le fais par exemple avec la 4.2. Tant que nous n'aurons pas résolu ce
point, cela sera frustrant pour tout le monde, et je dis bien tout le
monde. Nous essayons de simplifier l'assistant de rapport de bug, de le
traduire, de mettre des versions compilées à disposition, des moyens de
traquer les régressions, de relancer les tests manuels, etc... mais cela
vient petit à petit et cet effort doit viser à faire s'investir plus de
monde.

Je ne dis pas que toutes les versions doivent avoir une vie longue, je
dis que quelques versions doivent avoir une vie plus longue que les
autres. par exemple, la 3.6 pour ceux qui ne veulent pas passer à la 4

ou la 4.1, car la 4.0 me semble une version un peu incomplète (sentiment
subjectif)

Je ne demande pas non plus que des bugs spécifiques à ces versions
soient recherchés et développés, mais que les correctifs des versions en
cours de développement soient 'backportés' (drôle de mot, retro-intégrés
?) sur ces seules versions. Ce ne pas zéro au niveau travail, mais le
gros du boulot a été fait en résolvant le bug.

Quand c'est possible, les développeurs le font, mais quand c'est un
risque trop important, que c'est trop invasif dans le code et pourrait
avoir des effets collatéraux sur d'autres parties, ils ne prennent pas
ce risque.

C’est quelque chose que je comprends parfaitement, mais ce n'est pas ce qui est fait (enfin, si, c'est fait, les patchs sont intégrés, mais il n'y a pas de publication de version alors que 95% du boulot est fait) c'est donc qu'il y a une volonté politique d'avancer à marche forcée.

Boulette, je me suis emmêlé dans les n° de version, il y a moins de vingt patchs publiés après la version 3.5.7

#25

Bonjour Pierre,

Oui, si je clique pour la déplacer, ça marche, c'est-à-dire que je reste sur mon clic pour la déplacer. Par contre, si je veux la redimensionner, je dois cliquer une fois dessus pour obtenir le cadre de l'image et les points de modification de son aspect. Et là , ça ne fonctionne pas. Le cadre apparaît puis disparaît. Il reste présent si je reste longtemps appuyé sur mon clic.

C'est vrai qu'il faut cliquer une seconde fois pour obtenir le cadre et les points de déformation et je dirais même que, sans appuyer longtemps, il faut pour le moins appuyer "fermementé :slight_smile: sur le bouton gauche de la souris.

Je note quand même ce qui me semble être une bizarrerie : lorsque je clique sur l'image le pointeur se transforme en croix de déplacement mais le pointeur-croix disparait si je le bouge, et réapparait si je clique gauche sur l'image pour la déplacer.

Aparemment il n'y a pas de fond (?) sur les diapos mais je ne sais pas comment on fait pour en ajouter un pour tester, je ne suis pas familier d'Impress:-)

Ah bon ? Ça peut expliquer la différence. le problème n'est présent que s'il y a un fond

la diapo dit ressembler à ceci : https://www.dropbox.com/s/t6mmfk0fv2p8l0e/diapo7.jpg

et non à cela : https://www.dropbox.com/s/gfao8kdgcla9b33/diapo7blanc.jpg

La diapo ressemble à la première (https://www.dropbox.com/s/t6mmfk0fv2p8l0e/diapo7.jp)
Quand tu parles de fond tu veux dire "arrière-plan" ? C'est ce que je n'avais pas compris. Donc, effectivement, j'ai bien l'arrière-plan.

J'ai aussi essayé un copier-coller d'un tableau dans une nouvelle diapo, sans plantage.

Moi, aussi, je ne peux pas reproduire systématiquement les plantages par contre, en utilisation sur les tableaux, pour créer ce diaporama, j'ai eu droit à des plantages (une dizaine) toute la journée. depuis que je ne travaille plus les tableaux, plus de plantage

Bernatd

#26

C'est vrai qu'il faut cliquer une seconde fois pour obtenir le cadre et les points de déformation et je dirais même que, sans appuyer longtemps, il faut pour le moins appuyer "fermementé :slight_smile: sur le bouton gauche de la souris.

Pour compléter ma réponse : j'ai vérifié avec LO 3.6.7, il suffit de cliquer une seule fois, "normalement" (ni longtemps, ni pression excessive) pour obtenir le cadre et les points de déformation.

#27

ou alors, il faut supprimer l'arrière-plan et là, le comportement redevient 'normal' ou habituel

Pierre

#28

Bonjour
>possibilité de tuer le process. Après l'avoir relancé, il propose de
>récupérer le ou les fichiers .odp qui étaient ouverts. Mais si on acquiesce,
>il n'aboutit jamais et se bloque à nouveau. Seule solution pour reprendre la
>main : redémarrer l'ordinateur. Mais les mêmes problèmes reviendront...
(...) Je reprends pas toute la discussion

Quelle version de java as-tu. Je me demande si je n'avais pas eu les mêmes déboires en l'absence de java !
Nicolas

#29

possibilité de tuer le process. Après l'avoir relancé, il propose de
récupérer le ou les fichiers .odp qui étaient ouverts. Mais si on

acquiesce,

il n'aboutit jamais et se bloque à nouveau. Seule solution pour reprendre

la

main : redémarrer l'ordinateur. Mais les mêmes problèmes reviendront...

(...) Je reprends pas toute la discussion

Quelle version de java as-tu. Je me demande si je n'avais pas eu les
mêmes déboires en l'absence de java !
Nicolas

Pas de Java effectivement (/trop de trous de sécurité/).
Mais la v4.0.4 (ou v4.0.3) de LibO qui ne pose pas les problèmes que j'ai
signalé, est également sans Java.
Et j'imagine que LibO gère l'absence de JRE en ne permettant pas les
fonctions qui en auraient besoin.

Tristan

#30

En tous cas, les problèmes de sélection des images et des cadres de texte persistent dans la 4.1.3.1 et je suppose qu'ils ne seront pas résolus pour la 4.0.6.2

Pierre

#31

Pour les tableaux. Je viens de faire les essais suivants : (avec la 4.1.3.1)

Nouveau diaporama, page maitresse Inspiration (j'ai l'impression que ce sont les pages maitresses qui posent problème), insertion tableau avec les options par défaut.

Je remplis rapidement quelques cases au hasard avec des lettres au hasard elles aussi -> Crash en moins de deux secondes..

Je refais l'essai dans les mêmes conditions deux fois (sauf que je ne remplis pas les mêmes cases avec les mêmes lettres --> deux crashs en quelques secondes.

Je fais un essai sans page maitresse --> tout roule

Super, je me dis que j'ai une piste

Je reviens donc sur mes trois premiers essais pour confirmer tout cela.

Trois essais sans obtenir le moindre crash.

Notez que l'utilisation d'impress pendant des heures sur le même ordinateur ne pose pas de problème du tout, sauf quand je touche aux tableaux

Grrr

Pierre

#32

Il faut rester sur la 3.6

J'ai installé LibreOffice sur 40 PC entreprise, et je n'ai que des problèmes
depuis la 4.

Actuellement plus possible de sélectionner les images, comme déjà évoqué.

Il faut créer des versions LTS, car c'est le ras le bol de tous les
utilisateurs.

#33

Bonjour,

Il faut rester sur la 3.6

J'ai installé LibreOffice sur 40 PC entreprise, et je n'ai que des problèmes
depuis la 4.

Ça ne prouve pas que le problème est coté LibreOffice. Pour le savoir il
faut soumettre des rapports de bug.

Actuellement plus possible de sélectionner les images, comme déjà évoqué.

Et c'est maintenant que tu viens le dire alors que la branche 4.0 est en
fin de vie et qu'on est passé à la 4.1 depuis un moment déjà ?

Il faut créer des versions LTS, car c'est le ras le bol de tous les
utilisateurs.

Pour avoir une version LTS, il te suffit de passer un marché de support
avec une entreprise qui fait du support de niveau 3.

Bonne journée
JBF

#34

Ça sert à quoi de remplir des bugs ?

Gel d'impress : https://bugs.freedesktop.org/show_bug.cgi?id=72178

pas de nouvelles depuis que le bug est confirmé

Craches fréquent en éditant les tableaux sous Impress https://bugs.freedesktop.org/show_bug.cgi?id=71423

pas de nouvelles depuis que le bug est confirmé, même s'il est dans les MAB de là 4.1

Difficultés à sélectionner un cadre ou une image : https://bugs.freedesktop.org/show_bug.cgi?id=68923

Pareil

je redis qu'il est devenu bien compliqué de travailler avec Impress. ça va quand on a un fond blanc et qu'on n'a pas de tableau, c'est l'enfer quand on a une page maitresse et des tableaux à remplir

Toutes les versions actuelles de LO sont touchées par ces bugs (4.0.6 ; 4.1.4 ; 4.2 beta)

Pierre

#35

Bonsoir Pierre,
[...]

Ça sert à quoi de remplir des bugs ?

À faire en sorte que l'on sache que ça marche pas :slight_smile: à question...

Gel d'impress : https://bugs.freedesktop.org/show_bug.cgi?id=72178

pas de nouvelles depuis que le bug est confirmé

tu l'as rempli le 30/11, faut peut être pas exagérer non plus, on n'est
pas des robots ni une usine.

Craches fréquent en éditant les tableaux sous Impress
https://bugs.freedesktop.org/show_bug.cgi?id=71423

pas de nouvelles depuis que le bug est confirmé, même s'il est dans les
MAB de là 4.1

idem, confirmé le 30/11

Difficultés à sélectionner un cadre ou une image :
https://bugs.freedesktop.org/show_bug.cgi?id=68923

Pareil

ok, celui-ci a été confirmé en septembre, en fait on s'est dit que
quelques uns étaient plus importants que celui-ci.

je redis qu'il est devenu bien compliqué de travailler avec Impress. ça
va quand on a un fond blanc et qu'on n'a pas de tableau, c'est l'enfer
quand on a une page maitresse et des tableaux à remplir

Je ne reproduis pas

Toutes les versions actuelles de LO sont touchées par ces bugs (4.0.6 ;
4.1.4 ; 4.2 beta)

ben, oui, logique tant que les bugs sont pas corrigés, ils passent tous
les échelons jusqu'à ce que quelqu'un veuille bien fournir un patch.

À bientôt
Sophie

#36

Bonsoir Pierre,
[...]

Ça sert à quoi de remplir des bugs ?

À faire en sorte que l'on sache que ça marche pas :slight_smile: à question...

Gel d'impress : https://bugs.freedesktop.org/show_bug.cgi?id=72178

pas de nouvelles depuis que le bug est confirmé

tu l'as rempli le 30/11, faut peut être pas exagérer non plus, on n'est
pas des robots ni une usine.

Craches fréquent en éditant les tableaux sous Impress
https://bugs.freedesktop.org/show_bug.cgi?id=71423

pas de nouvelles depuis que le bug est confirmé, même s'il est dans les
MAB de là 4.1

idem, confirmé le 30/11

Difficultés à sélectionner un cadre ou une image :
https://bugs.freedesktop.org/show_bug.cgi?id=68923

Pareil

ok, celui-ci a été confirmé en septembre, en fait on s'est dit que
quelques uns étaient plus importants que celui-ci.

je redis qu'il est devenu bien compliqué de travailler avec Impress. ça
va quand on a un fond blanc et qu'on n'a pas de tableau, c'est l'enfer
quand on a une page maitresse et des tableaux à remplir

Je ne reproduis pas

C’est pourtant ce que donne l'ensemble de ces bugs confirmés.

On travaille avec des tableaux et puis ça plante au bout de ? on ne sait pas trop. Dès fois on dit que ça y est ça plantera plus, et puis si, ça le fait, etc.. plantage aléatoire, mais qui arrive quand on fait mumuse avec des tableaux

si on met des cadres, des images et que l'on veut agencer tout cela, on s'énerve vite avec les difficultés à sélectionner les cadres et images

et puis, il y aussi celui-là : https://bugs.freedesktop.org/show_bug.cgi?id=72412 (bon, il est confirmé et marqué comme major)

mais oui, qu'est-ce qu'il m'a pris de vouloir changer le fond des mes diaporamas avec du texte, des tableaux, des images

j'ai aussi des comportements tordus sur les styles dans les tableaux (on change toutes les polices d'un tableau, on ferme LO, on rouvre et une partie du tableau retrouve ses anciennes polices)

j'utilise souvent Impress, je m'en sers sur trois ordinateurs différents et c'est devenu pénible

Pierre

#37

Bonsoir Pierre,
[...]

Ça sert à quoi de remplir des bugs ?

À faire en sorte que l'on sache que ça marche pas :slight_smile: à question...

Gel d'impress : https://bugs.freedesktop.org/show_bug.cgi?id=72178

pas de nouvelles depuis que le bug est confirmé

tu l'as rempli le 30/11, faut peut être pas exagérer non plus, on n'est
pas des robots ni une usine.

OK, admettons :

Celui-là : https://bugs.freedesktop.org/show_bug.cgi?id=47662

Il y a dans l'enseignement, depuis peu, une mode qui consiste à évaluer nos étudiants avec des feuilles de calcul et des curseurs. on place le curseur entre pas bien et très bien pour chaque item et la feuille nous donne la note

ce bug empêche d'utiliser ce système de notation avec calc et lorsque l'on me demande MS Excel pour ces évaluations, je suis incapable d’opposer le moindre argument pour proposer une solution libre et simple

voilà qui résume ma pensée (commentaire 4):

@Rainer Bielefeld: Auto-addition of "$" is in my opinion the wrong approach. This issue is a true bug and a real time waster for users!

et voir le commentaire n°2

il y a aussi celui-là :

https://bugs.freedesktop.org/show_bug.cgi?id=51756

qui rend hasardeux toute impression d'une feuille d'évaluation

Ces deux bugs ont un an, un an et demi. et sincèrement, je ne crois pas qu'ils soient résolus un jour

Pierre

#38

Je suis bien en 4.1.3 et je suis passé par la 4.1.2

#39

Bonjour,

[...]
Ces deux bugs ont un an, un an et demi. et sincèrement, je ne crois pas
qu'ils soient résolus un jour

Je vois au moins 3 pistes de solutions :

1/ faire du buzz pour essayer de donner envie à un développeur de s'en
occuper. Mais bien sûr sans mettre quiconque en accusation.

2/ demander à MIMO si ces bugs peuvent être pris en charge par l'un des
marchés de support logiciel libre de l'administration française.

3/ contourner le problème ; par exemple pour fdo#47662 (copie de
contrôles) en créant un modèle équipé d'une macro permettant de générer
les contrôles avec les bons liens.

Bonne journée
JBF

#40

j'utilise la solution 3. c'est une solution que je ne peux pas imposer à ceux qui voudraient faire leur grille d'évaluation avec ce système

la solution 1. j'essaye

pour la 2, c'est hors de mes compétences

Pierre