https://bugs.documentfoundation.org/show_bug.cgi?id=165474
--- Comment #29 from ocleyr2lalune <[email protected]> --- I have read all the new comments since last time and would like to add the following: I am probably more on the side of the end user or user assistant. I find arbitrary remarks unacceptable such as “it's enough,” “it's not a problem,” or “it's only a problem for users with a particular VCL” (and yet gtk3 is not particularly anecdotal; knowing how to switch VCLs considerably reduces the population) . They just have to change. That pretty much ends the debate. And I thank Eyal Rozenberg for his search for an acceptable compromise. Yes, I should share my general comments on this change in the initial bug report. But that's the bug I found in the first place. Still, I'll do it. I repeat what I have already stated: it is not acceptable for the end user, who has no visibility of the development process, for such a change to be applied without warning, without information in the release notes, and without first being placed in the experimental features. Once again, the strategy adopted for the meta bar should be followed here. It allows us to accept the “draft” nature of a gradual implementation. It allows us to avoid upsetting the user. The adoption of the meta bar took time, years, and is still not the default setting? Very well, it is up to the user to make the choice for their needs. Not the developers, not the designers. The user benefits from and appreciates the investment made by developers and designers to offer them new, more suitable features (or at least features that attempt to be more suitable). As soon as LibreOffice imposes and does not give a choice, LibreOffice loses some of the freedom it offers. I haven't forgotten that the subject of this bug is the appearance of the vertical menu bar (new appearance) which, according to the dialog box, causes the menu to be displayed incompletely. V Stuart Foote considers that there is nothing to review or improve, the overflow is fine. Period, end of discussion. I would like to emphasize several points (already mentioned) - beyond muscle memory, this requires remembering which features are present for which the tab is no longer displayed (not just muscle memory, so once again, let's be inclusive and think of those who won't remember) - Knowledge of the features offered by the interface. Will we be able to identify that there are “menus” to scroll through? Can we make some of the settings “invisible”? How can we ensure this? - Let's not believe that offering different functions depending on the dialog boxes is a possible or coherent solution. Users won't understand it and won't know what to do. - Let's not rush through the issue of different languages, as the impact can be much more disruptive from one language to another. Once again, this argues in favor of making it an experimental feature. This would satisfy the most impatient users, who would be tolerant of the initial rough edges, and would allow time to offer something more polished to everyone later on. One last point after reading the comments: A display similar to what is offered in Tools > Options would indeed be quite interesting. It removes a number of obstacles. In the same vein, the search box would then be invaluable for finding the parameter you want to change, without having to scroll through a menu to find the right tab/item where it is located. Of course, this is an improvement “in addition to” and not “instead of.” Thank you on behalf of the users :-) ************ Original French Version ************ J'ai lu tous les nouveaux commentaires depuis la dernière fois et j'ajoute les éléments suivants : Je me situe probablement plus du côté de l'utilisateur final ou de l'assistant utilisateur. Je trouve inacceptable des remarques arbitraires du type "c'est suffisant", cela ne pose pas de problème, cela ne pose un problème que pour les utilisateurs avec un VCL particulier (et pourtant gtk3 n'est pas particulièrement anecdotique, de là à savoir switcher de VCL, on réduit considérablement la population), ils n'ont qu'à changer. Cela ferme plutôt tout débat. Et je remercie Eyal Rozenberg pour sa recherche d'un compromis acceptable. Oui je devrais faire part de mes remarques générales sur cette évolution dans le bug initial. Seulement c'est bien ce bug que j'ai trouvé au départ. Mais je vais le faire. Je renouvelle ce que j'ai déjà précisé, il n'est pas acceptable pour l'utilisateur final qui n'a aucune visibilité du processus d'évolution qu'un tel changement soit appliqué sans prévenir, sans informations dans les notes de version, sans être placé dans un premier temps dans les fonctions expérimentales. Encore une fois, la stratégie adoptée pour la méta-barre devrait être suivie ici. Elle permet d'accepter le caractère "brouillon" d'une mise en place progressive. Elle permet de ne pas brusquer l'utilisateur. L'adoption de la méta-barre a pris du temps, des années, et n'est toujours pas le réglage par défaut ? Trés bien c'est à l'utilisateur d'en faire le choix pour son besoin. Pas aux developpeurs, pas aux designers.L'utilisateur profite et apprécie l'investissement des développeurs, et des designers pour lui proposer de nouvelles fonctionnalités, plus adaptées (enfin qui tentent de l'être). Dès que LibreOffice impose et ne donne pas le choix, LibreOffice perd un peu de la liberté qu'il offre. Je n'ai pas oublié que le sujet de ce bug est l'apparence de la barre verticale de menu (nouvelle apparence) qui induit, selon la boite de dialogue un affichage incomplet du menu. V Stuart Foote considère qu'il n'y a rien à revoir ou améliorer, le débordement gère. Point, fermez la discussion. Je voudrais insister sur plusieurs points (déjà évoqués) - au delà de la mémoire musculaire, cela exige de retenir quelles sont les fonctionnalités présentes, pour lesquelles l'onglet n'est plus affiché (pas que musculaire la mémoire donc, encore une fois, restons inclusifs, pensons à ceux qui ne retiendront pas) - la connaissance des fonctionnalités offertes par l'interface. Va-t-on bien identifier qu'il y a des "menus" à faire défiler ? Est-ce que l'on n'arrive pas à rendre "invisible" une partie des réglages proposés ? Comment s'en assurer -ne croyons pas que proposer des fonctionnements différents selon les boites de dialogue est une solution possible ou cohérente. L'utilisateur n'y comprend rien, il ne sait pas sur quel pied danser. -ne passons pas trop vite la question des différents langages proposés, l'impact peut être bien plus gênant d'un langage à un autre. Encore une fois cela plaide pour un passage en fonctionnalité expérimentale. Cela permettrait de contenter les plus impatients, qui serait tolérant devant le coté brouillon de départ, et laisserait le temps de proposer quelque chose d'abouti à tous, plus tard. Un dernier point à la lecture des commmentaires : Un affichage similaire à ce que propose Outils > Options serait effectivement assez intéressant. Cela retire un certain nombre de frein. Dans cette même logique, la zone de recherche serait alors précieuse pour trouver le paramètre que l'on veut modifier, sans avoir à faire défiler un menu pour trouver le bon onglet/item où il est présent. Bien sûr il s'agît d'une amélioration "en plus de" et pas d'un "à la place de" Merci pour les utilisateurs :-) -- You are receiving this mail because: You are the assignee for the bug.
