Le Thu, 16 Apr 2015 14:18:02 +0200 "Sylvain L. Sauvage" <sylvain.l.sauv...@free.fr> a écrit:
> Le mercredi 15 avril 2015, 22:36:59 Gaëtan PERRIER a écrit : > >[…] > > Doit y avoir un truc qui m'échappe parce que je ne vois > > toujours pas en quoi ça serait à l'appli de gérer ça. > > Quand on passe en mode tablette pour moi c'est au système à > > mettre ce qu'il faut à disposition pour que l'on puisse > > saisir des données. > > 1. Soit le clavier physique reste : comment sait-on que > l’utilisateur veut utiliser un clavier virtuel ? > → C’est à l’utilisateur de le lancer/montrer/cacher. > > 2. (Je pense que c’est le cas ici.) Soit il n’y a plus de > clavier physique (on l’enlève). > > Alors : > a. Qui lance un clavier virtuel ? > > b. Et doit-il rester en place (et bouffer de l’espace pour > rien dans 90% des cas) ou apparaître seulement quand on en a > besoin ? > > c. Et s’il doit apparaître seulement quand on en a besoin (on > touche un champ textuel p.ex.), qui le fait > apparaître/disparaître ? > > > D’après toi, à chaque fois (?), la réponse serait : le > « système ». De prime abord je dirai que oui. > Mais c’est qui/quoi ce « système » ? Ce qui n'est pas l'appli ;) > > > Sur une tablette Android (p.ex., mais c’est pareil sur toutes > les plates-formes embarquées ou contraignantes), toutes les > applications utilisent la même base, l’API fournie, celle qui > cause à la pile applicative qui n’a qu’un seul tronc (noyau → > système graphique → bibliothèques android). Donc, effectivement, > c’est android (le « système ») qui fait le boulot puisque tout > est fourni et obligatoire. > > Sur un PC plus polyvalent, la pile est multi-branche : une > application peut attaquer le matériel (pour savoir si oui ou non > il y a un clavier ou pour afficher des trucs à l’écran) plus ou > moins directement, via le noyau, la libc, et diverses autres > bibliothèques et services. Elle n’est pas obligée de passer par > une unique API. > Donc qui a le niveau de connaissance suffisante pour prendre > les responsabilités ? > > … pour a. (qui lance le clavier virtuel ?) X11 gère les > claviers donc sait s’il y en a un réel ou pas mais ce n’est pas > à lui de gérer la session de l’utilisateur, donc ce serait > plutôt au gestionnaire de fenêtre ou de bureau de le faire. > > … pour c. (qui le montre/cache suivant le focus ?) Là, il faut > que ce soit l’application parce que c’est la seule à savoir > lequel de ses composants a le focus et si ce composant a besoin > d’un clavier (le gestionnaire de fenêtres ne sait que quelle > application/fenêtre a le focus et X11 ne sait pas grand-chose). > Bien sûr, des bibliothèques peuvent aider à gérer tout ça (Qt, > GTK…) et pourraient même utiliser des protocoles standard (dbus > / Freedesktop.org¹) pour savoir quelle application lancer, s’il > y a déjà un clavier ou pas, ou pour le cacher/montrer. Pour moi ce n'est pas l'appli mais l'utilisateur qui décide dans ce cas et donc c'est le "système" qui lui offre cette possibilité. Imagine un simple programme genre "hello world" qui te demande d'entrer ton nom pour afficher "hello _nom_". Si c'est à cette appli de gérer les différents claviers possible leur affichage, etc. elle risque de devenir dramatiquement compliquée, non ? Gaëtan -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150416215118.5ab19485fedb4e2164b38...@neuf.fr