From madore@news.ens.fr Wed Jan 5 16:03:11 2000 Article: 341 of ens.forum.informatique.x11 Path: eleves!not-for-mail From: madore@news.ens.fr (GroTeXdieck) Newsgroups: ens.forum.informatique.x11 Subject: Re: Configuration des ressources Date: 5 Jan 2000 15:03:11 GMT Lines: 96 Sender: madore@clipper.ens.fr Message-ID: <84vmff$5fq$1@clipper.ens.fr> References: <84vfg2$h5l$1@clipper.ens.fr> NNTP-Posting-Host: clipper.ens.fr Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: clipper.ens.fr 947084591 5626 129.199.129.1 (5 Jan 2000 15:03:11 GMT) X-Complaints-To: forum@clipper.ens.fr NNTP-Posting-Date: 5 Jan 2000 15:03:11 GMT X-Newsreader: Flrn (0.4.0 - 07/99) X-Wisdom-Of-The-Day: Without doubt, independence hasn't distracted from the essence of independence. X-Mark: BOG Xref: eleves ens.forum.informatique.x11:341 Bon, on va essayer de répondre de manière claire. (Et à une question un peu plus générale que celle que Nicolas posait, parce que je pense qu'il n'est pas le seul à être mystified par les ressources X.) Quand tu écris une ressource du genre foo.bar.baz.qux: false, les différentes composantes sont séparées par des points. Le premier terme, « foo », est le nom de l'application à laquelle la ressource s'applique, le dernier terme, « qux », est le nom de la ressource à définir, et tous les termes intermédiaires, ici « bar » et « baz » sont des noms de widgets dans la hiérarchie (en l'occurrence, tu mets à « false » la ressource « qux » du widget « baz » contenu directemetn dans un widget « bar » lui-même juste en-dessous du shell d'application de l'application « foo »). On peut aussi remplacer une succession de termes non précisées par le caractère « * ». C'est surtout utile entre l'application et le nom du widget (parce que, typiquement, on connaît le nom du widget mais pas sa hiérarchie d'ascendance, et du reste on s'en fout) ou directement entre l'application et le nom de la ressource (parce qu'on veut définir la ressource dans tous les widgets de l'application) ; ou encore pour ne pas donner le nom de l'application. On peut aussi omettre *un* élément précis de la hiérarche avec le wildcard « ? », mais c'est rarement utile. Ensuite, il y a la complication due aux majuscules. Normalement, les noms sous X sont studlycapsifiés commeCeNomDeWidget, et l'opération intéressante revient à mettre une majuscule sur la première lettre, avec éventuellement une exception lorsque la première lettre est « x » auquel cas on mettra les deux premières lettres en majuscules. En fait, ceci n'est pas un opération systématique : le nom de classe n'a pas de raison d'être obtenu de manière systématique à partir du nom d'instance. Bref, il y a trois niveaux où ça intervient : application, widget et ressource. Au niveau application, cela sert comme ceci : tout programme définit une classe que tu ne peux pas changer (par exemple, le programme xterm a la classe XTerm). Donc toutes les instances de ce programme auront le même nom de classe. Mais par ailleurs, chacun a un nom d'application, et, s'il y a une valeur par défaut, tu peux aussi changer avec l'option -name (suivie du nom d'application que tu veux donner). Donc, typiquement, dans ton .Xresources tu définiras les ressources avec des majuscules sur l'application (classe d'application) sauf pour certaines instances particulières, genre : XTerm*background: black funkyXTerm*background: hotPink Au niveau widget, la classe a un sens de classe comme dans la programmation orientée objet : les widgets sont des objets, et les classes sont leurs types. Donc si une application foobar a des boutons Athena nommés quitButton, pauseButton et frobnicateButton, tu peux régler la couleur de chaque bouton avec par exemple foobar*quitButton.foreground: hotPink ; mais tu peux aussi régler toute la classe avec foobar*Command.foreground: hotPink (sachant que les principaux types de boutons Athena sont Command et Toggle). Enfin, au niveau ressource, c'est de la tétratomie presque pure. Normalement, l'idée c'est que si tu as quarante ressources du genre importantWordsFont, unimportantWordsFont, locutorFont, zippyFont, et ainsi de suite, tu les mettras tous ensemble dans une classe Font, de sorte qu'on puisse les régler toutes d'un coup. En l'occurrence, cette feature n'est presque jamais utilisée, chaque ressource appartenant à sa propre classe. Il y a quand même quelques cas : par exemple, le widget VT100 de XTerm a deux ressources, geometry et tekGeometry, qui sont dans la même classe Geometry. Il y a une autre utilité de la distinction instance/classe, c'est pour ce qui est de la précédence des ressources. C'est un sujet très compliqué, parce que les ressources sont obtenues de huit endroits différents : (1) la ligne de commande, (2) le fichier $XENVIRONMENT ou .Xdefaults-`hostname`, (3) la propriété SCREEN_RESOURCES pour xrdb, (4) la propriété RESOURCE_MANAGER pour xrdb ou bien le fichier .Xresources, (5) les application-defaults par utilisateurs définies par $XUSERFILESEARCHPATH ou bien $XAPPLRESDIR/$LANG (ou bêtement dans le $HOME de l'utilisateur), (6) les application-defaults dans le $XFILESEARCHPATH, (7) les application-defaults standard dans /usr/lib/X11/$LANG/app-defaults/ (ou bien sans le $LANG si ça n'existe pas avec), (8) les ressources internes, fallback passées à XtAppInitialize() ou bien fallback du widget, ou bien fallback du type. Cela, par précédence décroissante. Mais il y a aussi une précédence décroissante, du particulier au général, suivant la manière dont la ressource a été spécifiée ; par exemple, *background a précédence sur *Background en cas de conflit. Ce n'est pas toujours facile de savoir ce qui a précédence sur quoi, par exemple *box*background a précédence sur *box.Background même si c'est un peu surprenant. Pour plus de précisions, voir le chapitre 10, « Resource Management and Type Conversion » du volume 4 « X Toolkit Intrinsics Programming Manual » des guides O'Reilly pour le système X. Ça doit aussi être expliqué dans les manuels de X lui-même, je suppose, mais je rappelle à toutes fins utiles que les pages de mân ne sont *pas* le Manuel de X. En tout cas, en pratique, je recommande d'utiliser des plutôt des minuscules pour le nom de ressource et des majuscules pour la classe d'application.