J'ai testé les différentes solutions proposées, notamment par gnumdk.
Aucune ne me satisfait totalement, mais si j'ai bien compris, c'est à cause d'une limite du protocole.
Je m'explique. Ce que je recherche, c'est un gain de pixels pour afficher l'application en elle-même, mais sans perte d'ergonomie.
Avoir le menu dans un panneau plasma en haut de l'écran (comme MacOSX), c'est bien. Mieux que le menu dans la barre de titre, vu que ça permet justement de ne pas avoir de barre de titre pour les applis maximisées, gros gain de place (en tout cas dans mon cas, vu que le panneau plasma contient du coup le menu K, les icônes de la icon only task manager, les boutons minimiser/maximiser/fermer de la fenêtre courante, la systray et l'horloge, le tout sur une seule ligne).
Mais cette solution est bien seulement pour l'application maximisée sur le même écran que ce panneau, sinon le contexte est trop lointain et je ne sais jamais sans y réfléchir au moins quelques secondes si c'est bien le menu de la fenêtre que je veux qui est actuellement affiché.
Bref, il faudrait que je puisse avoir au moins une zone de menu par écran (réservée aux fenêtres du même écran).
Pour faire mieux, pour les fenêtres non-maximisées devraient, elles, avoir leur menu dans leur barre de titre (ou à défaut, une barre de menus classique), parce que le lien entre un panneau sur un bord de l'écran et une fenêtre flottante n'est pas direct (change en fonction du contexte). Notez au passage que je ne cherche pas à gagner des pixels sur les fenêtres flottantes… si j'avais voulu plus d'espace dans une fenêtre, je l'aurais maximisée.
Pour résumer, il faudrait qu'on puisse faire tourner en parallèle tous les "réceptacles" à menus (actuellement, quand un réceptacle s'enregistre sur DBus, il désactive tous les autres), et que le choix du réceptacle à menus de chaque fenêtre puisse dépendre de règles paramétrables (pas forcément directement par l'utilisateur via un clicodrome surchargé et incompréhensible, mais au moins grâce à une collection de profils types).
Sinon, quelques souhaits précis :
- j'aimerais bien pouvoir avoir, dans la barre de titre, tous les menus directement visibles à l'horizontale, sans avoir besoin d'ouvrir d'abord le menu "global".
- j'aimerais bien pouvoir, depuis l'application faire Alt+Lettre_du_menu pour ouvrir directement le menu que je veux (pour l'instant on ne peut que définir un unique raccourci global pour l'ensemble des menus). Mieux, la touche Alt toute seule devrait pouvoir sélectionner le premier menu (et faire apparaître la barre de menus si elle était masquée, comme dans Firefox pour Windows).
# Ça manque encore de souplesse et de cohérence !
Posté par Aldoo . En réponse au journal Menu déporté dans KDE (des nouvelles). Évalué à 4. Dernière modification le 15 mars 2012 à 17:13.
Bonjour,
J'ai testé les différentes solutions proposées, notamment par gnumdk.
Aucune ne me satisfait totalement, mais si j'ai bien compris, c'est à cause d'une limite du protocole.
Je m'explique. Ce que je recherche, c'est un gain de pixels pour afficher l'application en elle-même, mais sans perte d'ergonomie.
Avoir le menu dans un panneau plasma en haut de l'écran (comme MacOSX), c'est bien. Mieux que le menu dans la barre de titre, vu que ça permet justement de ne pas avoir de barre de titre pour les applis maximisées, gros gain de place (en tout cas dans mon cas, vu que le panneau plasma contient du coup le menu K, les icônes de la icon only task manager, les boutons minimiser/maximiser/fermer de la fenêtre courante, la systray et l'horloge, le tout sur une seule ligne).
Mais cette solution est bien seulement pour l'application maximisée sur le même écran que ce panneau, sinon le contexte est trop lointain et je ne sais jamais sans y réfléchir au moins quelques secondes si c'est bien le menu de la fenêtre que je veux qui est actuellement affiché.
Bref, il faudrait que je puisse avoir au moins une zone de menu par écran (réservée aux fenêtres du même écran).
Pour faire mieux, pour les fenêtres non-maximisées devraient, elles, avoir leur menu dans leur barre de titre (ou à défaut, une barre de menus classique), parce que le lien entre un panneau sur un bord de l'écran et une fenêtre flottante n'est pas direct (change en fonction du contexte). Notez au passage que je ne cherche pas à gagner des pixels sur les fenêtres flottantes… si j'avais voulu plus d'espace dans une fenêtre, je l'aurais maximisée.
Pour résumer, il faudrait qu'on puisse faire tourner en parallèle tous les "réceptacles" à menus (actuellement, quand un réceptacle s'enregistre sur DBus, il désactive tous les autres), et que le choix du réceptacle à menus de chaque fenêtre puisse dépendre de règles paramétrables (pas forcément directement par l'utilisateur via un clicodrome surchargé et incompréhensible, mais au moins grâce à une collection de profils types).
Sinon, quelques souhaits précis :
- j'aimerais bien pouvoir avoir, dans la barre de titre, tous les menus directement visibles à l'horizontale, sans avoir besoin d'ouvrir d'abord le menu "global".
- j'aimerais bien pouvoir, depuis l'application faire Alt+Lettre_du_menu pour ouvrir directement le menu que je veux (pour l'instant on ne peut que définir un unique raccourci global pour l'ensemble des menus). Mieux, la touche Alt toute seule devrait pouvoir sélectionner le premier menu (et faire apparaître la barre de menus si elle était masquée, comme dans Firefox pour Windows).