Il sistema di gestione Menu di Debian <author>Joost Witteveen <email/joostje@debian.org/ <author>Joey Hess <email/joeyh@debian.org/ <author>Christian Schwarz <email/schwarz@debian.org/ <author>Bill Allombert <email/ballombe@debian.org/ <version>versione 1.4, <date> <abstract> Il pacchetto <tt/menu/, era ispirato al programma <tt/install-fvwm2-menu/ dal vecchio pacchetto <prgn/fvwm2/. Comunque <tt/menu/ cerca di fornire un'interfaccia più generica per la formazione di menu. Con il comando <prgn/update-menus/ da questo pacchetto, non è necessario modificare nessun altro pacchetto per ciascun window manager di X, in quanto fornisce un'interfaccia unificata per la gestione dei menu sia per programmi in modalità testo che grafica (sotto X). </abstract> <copyright>Copyright ©1997 Joost Witteveen, Joey Hess, Christian Schwarz. ©2002-2003 Bill Allombert. This manual is free software; you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. This is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details. A copy of the GNU General Public License is available as <tt>/usr/share/common-licenses/GPL</tt> in the Debian GNU/Linux distribution or on the World Wide Web at <tt>http://www.gnu.org/copyleft/gpl.html</tt>. You can also obtain it by writing to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. <toc sect> <chapt>Introduzione Prima dell'avvento di <tt/update-menus/, quando un amministratore installava un pacchetto in un sistema Debian, aveva la necessità di editare vari file di configurazione dei window manager per far sì che un nuovo programma venisse mostrato, per esempio, nei menu di <tt/fvwm/. I menu potevano facilmente diventare desincronizzati con i programmi al momento disponibili, con alcuni elementi di menu che non funzionavano ed altri programmi che erano sprovvisti di una voce di menu. update-menus e menu, il pacchetto di gestione dei menu di Debian, ha l'obiettivo di risolvere questi problemi. <tt/update-menus/ genera automaticamente i menu dei programmi installati per i window manager ed altri programmi a menu. Dovrebbe essere eseguito ogni volta che un file di menu o un "metodo di menu" viene modificato. <tt/update-menus/ verrà eseguito automaticamente quando un pacchetto Debian, che contiene dei file di menu viene installato o rimosso dal sistema. Ogni utente può, da solo, aggiungere/eliminare elementi di menu, e dovrebbe eseguire <tt/update-menus/ come utente, in modo da creare i file di avvio del window manager che sono usati al posto di quelli di sistema. Un problema che si verificava con menu-1.x (e precedenti versioni) era che il numero di elementi in un sotto-menu poteva variare di molto: sul mio sistema ci sono solo 2 elementi in /Apps/Editors, mentre sono sicuro che altre persone ne hanno più di 20. Molte persone si lamentano di quanto siano pieni alcuni sotto-menu, citando studi scientifici o esperienze personali per spiegare come un sovradimensionamento od un sottodimensionamento dei sotto-menu sia una cosa da evitare. Per ovviare a questo, menu-2.0 può ottimizzare i menu automaticamente, suddividendo per esempio l'albero /Apps/Editors in, Editors/Principianti, Editors/Esperti, o rimuovendo del tutto /Apps/Editors in un sistema in cui vi siano pochi editor installati. Per poter fare questo, menu segue le informazioni fornite con le variabili `hints` (guardare il paragrafo qui di seguito, o il capitolo relativo ad hints). Ciascun pacchetto che necessiti di un elemento nell'albero dei menu, include un file di menu <tt>/usr/lib/menu/nome-pacchetto</tt>. In questo file, si avrà una riga per elemento, come la seguente (presa da <tt>/usr/lib/menu/xbase</tt>): <example> ?package(xbase):command="/usr/bin/X11/xedit" needs="X11" \ section="Apps/Editors" title="Xedit" \ hints="Beginner,Small" </example> Questo descrive il tipo di interfaccia necessaria a Xedit (X11), la sezione di menu nel quale l'elemento dovrebbe essere inserito, il testo del menu, il comando che dovrebbe essere eseguito. Inoltre, comunica al menu che, se /Apps/Editors è troppo pieno, può mettere Xedit nelle sotto-sezioni Apps/Editors/Beginner o Apps/Editors/Small. Quando <tt/root/ esegue <prgn/update-menus/, questo controllerà tutti i file di menu contenuti in <tt>/etc/menu/</tt> e <tt>/usr/lib/menu</tt>, ed eseguirà gli script di installazione che i window manager, come <prgn/fvwm2/, dovrebbero fornire in <tt>/etc/menu-methods/</tt>. Il pacchetto menu, già fornisce alcuni file di menu predefiniti, fornendo così un'idea alle persone che lo utilizzano, e per velocizzare un pochino le cose. (Questi file dovrebbero essere incorporati nel pacchetto). Si noti che sono state fatte modifiche sostanziali ed incompatibili con il rilascio di menu-1.0, mentre sostanziali funzionalità sono state aggiunte a partire dal rilascio di menu-2.0. Questo documento descrive menu-2.0. Menu-2.0 non accetta i menu-method scritti per menu-0.x, ma per la maggior parte dei window manager che hanno ancora i vecchi menu-method, ne ho messi di nuovi, col nuovo stile, in /usr/share/doc/menu/examples. Tutto ciò che è stato scritto per menu-1.0 funziona con menu-2.0. La maggior parte dei cambiamenti più importanti, avvenuti tra menu-0.x e menu-1.x, sono elencati nel file README.changes nel pacchetto menu, le funzionalità aggiunte, a partire da menu-2.0, possono essere qui riassunte: hints ed il modo "compact" di menu-2. (dove le righe. <chapt> Menu dal punto di vista dell'utente <sect> Come e quando i file di avvio del window manager vengono creati? Sostanzialmente, come utente, non si ha la necessità di conoscere come e quando i file di avvio di un window manger vengono creati, ma comunque, potrebbe essere interessante. Quando un pacchetto, che dovrebbe aggiungere qualcosa all'albero dei menu, viene installato, eseguirà <tt/update-menus/ nel suo script <tt/postinst/. Update-menus legge quindi tutti i file di menu in <tt>/etc/menu/</tt>, <tt>/usr/lib/menu</tt> e <tt>/usr/share/menu/default</tt>, e memorizza gli elementi di menu di tutti i pacchetti installati in memoria. Una volta effettuata questa operazione, eseguirà i menu-method, contenuti in <tt>/etc/menu-methods/*</tt>, e reindirizzerà tutte le informazioni riguardanti gli elementi di menu su stdout, così che i menu-method possano leggerle. Ciascun window manager, o altro programma che voglia gestire i menu Debian, fornirà uno script menu-method in <tt>/etc/menu-methods/</tt>. Questo menu-method saprà come generare i file di avvio del window manager. Per facilitare questo compito ai manutentori del window-manager, menu fornisce un programma: <tt>install-menu</tt>. Questo programna può generare i file di avvio per tutti i window manager. <sect> Ottimizzazione dei file di avvio generati dei window manager In via di principio questo è un argomento che dipende molto da ogni specifico window manager, ma per tutti i window manager (e altri), si applica quanto segue: Il file da cui iniziare è menu-method in <tt>/etc/menu-methods/$wm</tt>, dove per <tt/$wm/ si intende il nome del window manager. Comunque se questo menu-method <tt/!include/-s il file <tt/menu.h/ (come dovrebbe essere), si può modificare anche quel file, affinchè le modifiche apportate si riflettano su tutti i window manager installati. Se il file menu-method del window manager <tt/!include/ il file <tt/menu.h/, e fa uso appropriato delle definizioni, allora si può guardare ai commenti nel file <tt/menu.h/ per vedere come sia possibile fare dei piccoli aggiustamenti all'aspetto dei menu nel window manager. Per cambiare in generale l'albero dei menu, fare riferimento alla prossima sezione. <sect> Ottimizzazione dell'albero dei menu: hints Se <tt/hint_optimize=true/ è stato impostato nello script menu-method (in realtà quella definizione dovrebbe apparire nel file <tt/menu.h/ richiamato con <tt/!include/), allora install-menu proverà a modificare l'albero dei menu, per fare in modo che tutti i sotto-menu abbiano all'incirca un numero ottimale di elementi. (come specificato da <tt/hints_nentry=.../). Lo farà rimuovendo sotto-menu sottodimensionati (solo se il loro 'genitore' non sia già pieno), e possibilmente creando nuovi sotto-menu, usando hints. Si noti comunque che l'ottimizzazione dell'albero porta via molto tempo, quindi menu velocizza il processo, al costo di, occasionalmente, non trovare l'albero migliore. Quindi, l'alberatura che viene presentata, potrebbe non essere ottimale. Per le variabili di ottimizzazione, fare riferimento alle variabili hints_* nell'ultimo capitolo. <chapt> I file di menu <sect> Posizione I file di menu forniti dai pacchetti dovrebbero risiedere in <file>/usr/lib/menu/</file>. I file di menu di sistema dovrebbero risiedere in <file>/etc/menu/</file>. I file di menu specifici per l'utente dovrebbero risiedere in <file>~/.menu/</file>. <sect> Sintassi Il formato è <example> ?package(pacchetto[,pacchetto,...]): \ campo1="valore1"\ campo2="valore2"\ </example> Un esempio per descrivere la sintassi di questi tipi di file: <example> ?package(gnumeric):\ specifica quali pacchetti debbano essere installati, requisiti multipli dovrebbero essere separati da virgole needs="X11"\ che tipo di ambiente si aspetta il comando section="Apps/Math"\ in quale sezione l'elemento deve essere collocato title="Gnumeric"\ il titolo del menu command="gnumeric" \ il comando da eseguire hints="Gnome,Spreadsheets" \ qualche suggerimento per il posizionamento icon="/usr/share/pixmaps/gnumeric.xpm" Il percorso per l'icona da utilizzare </example> Il carattere "#" può essere utilizzato per aggiungere commenti. Un elemento deve terminare con un carattere di nuova riga, comunque si può usare \ come escape. I valori devono essere racchiusi da caratteri ", ed i meta-caratteri (", \, nuova riga) devono essere fatti precedere da \. Si possono includere più entità nello stesso file. Il file deve usare una codifica ASCII 7bit. Questo per soddisfare i window manager che non supportino l'8bit. La codifica delle traduzioni non è limitata. <tt/?package(...)/ contiene la lista dei pacchetti che devono essere installati, separati da virgole, affinchè l'elemento di menu sia visualizzato. Dovrebbe contenere il pacchetto che contiene il file di menu e qualsiasi altro pacchetto, non incluso nelle dipendenze del primo o nei pacchetti essenziali, necessario affinchè il comando possa essere eseguito. L'utente può utilizzare il pseudo-pacchetto col nome che comincia con <tt/local./ che si assume sia sempre installato. I campi <tt/needs/, <tt/section/, <tt/title/ e <tt/command/ sono obbligatori. Gli altri sono opzionali. Campi personalizzati sono supportati, quindi si possono aggiungere nuovi campi per propri scopi. Se un campo è specificato più volte nello stesso elemento di menu, l'ultima occorrenza verrà utilizzata. <sect> Il campo <tt/title/ Il campo <tt/title/ deve rispettare i seguenti requisiti: <enumlist> <item> Deve essere corto. C'è un campo opzionale, <tt/longtitle/, per l'utente che vuole un titolo lungo. <item> Deve essere scritto in maiuscolo dove occorra. Usare <em/Emacs/ e non <em/emacs/. <item> Deve essere unico. Due elementi non possono avere lo stesso titolo. </enumlist> <sect> Il campo <tt/needs/ I seguenti <tt/needs/ sono documentati per l'utilizzo in un sistema Debian. <enumlist> <item> <tt/X11/: se il programma viene eseguito sotto X11. <item> <tt/text/: se il programma viene eseguito in un terminale. I window manager di X11 utilizzeranno l'X terminal emulator. <item> <tt/vc/: se viene eseguito sotto la console linux ma non sotto terminale virtuale. <item> <tt/wm/: se è un window manager di X11, il window manager attuale, eseguirà tramite exec(2), questo programma per fare in modo che non venga generato l'errore "Another window manager is running". </enumlist> Un gestore di menu può usare uno speciale <tt/needs/, che prende il nome dal pacchetto per le voci di menu che devono essere mostrate solamente in questo gestore di menu. Esempi includono i moduli <tt/fvwm/, le voci di menu <tt/dwww/. Un programma come gnumeric, che può essere eseguito sia con X11 che in terminale, <em/non/ dovrebbe usare un campo extra come <tt/needs=X11/ in quanto sarebbe quasi impossibile configurare il window manager per usare <prgn/rxvt/ al posto del predefinito <prgn/xterm/. D'altro canto, se un programma (come <prgn/emacs/) può essere eseguito come una vera applicazione di X, esattamente come in terminale, due elementi dovrebbero essere inclusi, altrimenti il programma verrà eseguito sempre in <prgn/xterm/ (o <prgn/rxvt/). Bisogna ricordarsi comunque, che non sono ammessi due elementi con lo stesso titolo. Il titolo deve essere univoco. <sect> Il campo <tt/section/ Il campo <tt/section/ contiene una lista di sezioni gerarchiche separate da /. La struttura dei menu Debian/ <em/ufficiale/ è mantenuta nel documento di sub-policy del Debian Menu, che è parte del pacchetto Debian Policy. La struttura di menu qui di seguito, è inclusa solo per comodità e non è quella ufficiale. Se non segue la struttura descritta in Debian Menu sub-policy, per favore mandare un "wishlist bug" al pacchetto <tt/menu/. Per favore <em/non/ mettete i vostri pacchetti in altre sezioni. <example> Applicazioni - applicazioni normali Database - database interattivi Editor - editor di testo, word processors Apprendimento - scolastici, istruttivi Emulatori - dosemu, etc. Grafica - manipolazione di immagini Radioamatismo - qualunque cosa relativa alle radioamatismo. Matematica - maxima, octave, oleo, etc. Rete - mail, news, web, irc, etc. Programmazione - debuggers, etc. Scienza - programmi scientifici Strumenti - altri strumenti: xclock, xmag, xman, etc. Tecnici - materiale tecnico. Testo - materiale di lavorazione testo oltre agli editor. Shell - bash, ksh, zsh, etc. Suono - riproduttori ed editor di suoni. Visualizzatori - visualizzatori di immagini Sistema - amministrazione e monitoraggio di sistema. Giochi - giochi e divertimento. Avventura - avventure per mondi virtuali, zork, MOO's, etc Arcade - dove contano i riflessi Da tavolo - come gnuchess, pente, gnugo Carte - solitario, etc Rompicapi - materiale come xpuzzles, ... Simulaizone Sport - Giochi derivati da sport reali. Strategia - giochi che implicano abilità strategiche a lungo termine Tetris ed affini - giochi riguardanti blocchi cadenti Gingilli - oneko, xeyes, etc. Aiuto - documentazione utente Schermo - programmi che coinvolgono l'intero schermo Blocca - xlock, etc. Salva schermo - salvaschermo Sfondo - ci� che coinvolge la root window Window manager - X window managers Moduli - moduli per window manager Terminali per X - shell (like xterm, rxvt, ...) </example> Per utenti che desiderino accedere a dei menu velocemente, si possono mettere degli elementi a partire dalla radice dei menu. Questo viene ottenuto usando section="/". Le voci di menu fornite all'interno di pacchetti non devono mai utilizzare questa opzione. <sect> Il campo <tt/command/ Il campo <tt/command/ contiene il programma che deve essere eseguito quando l'elemento viene selezionato. Verrà eseguito con <prgn/sh -c/ usando: <example> execl("/bin/sh","sh","-c",command) </example> o equivalenti. <sect> Il campo <tt/icon/ Assicurarsi che l'icona specificata, sia sempre disponibile sul sistema. Quindi, se si desidera un'icona per l'elemento di menu, il metodo migliore è di fornire l'icona con il pacchetto. Per evitare inoltre che le icone distribuite si sparpaglino per il file system, mettere i file delle icone nella directory <tt>/usr/share/pixmaps</tt>. I manutentori dei pacchetti Debian, dovrebbero assicurarsi che ciascun'icona inclusa per l'uso con i menu Debian, aderisca alle seguenti specifiche: <enumlist> <item>Le icone dovrebbero essere nel formato xpm. <item>Le icone non dovrebbero essere pi� grandi di 32x32 pixel, dimensioni minori sono accettate. <item>Lo sfondo di un'icona dovrebbe essere trasparente, se possibile. </enumlist> Si possono fornire icone nei formati 16x16 e 32x32 usando come nomi icon16x16 ed icon32x32 di modo che utente possa configurarsi il menu per scegliere quella che preferisce. Se come amministratore di sistema, non si preferiscono le icone nei menu, basta cambiare semplicemente la funzione <tt/icon()/ nel file <tt>/etc/menu-methods/menu.h</tt>, ed eseguire <prgn/update-menus/. <sect> Il campo <tt/hints/ Hints è utilizzato per aiutare menu a strutturare i menu generati nel modo migliore possibile. Per esempio: <example> ?package(emacs20):\ needs="x11"\ hints="Big,Expert,Featureful" \ section="Apps/Editors"\ title="Emacs 20"\ command="/usr/bin/emacs20"\ icon=/usr/share/emacs/20.3/etc/emacs.xbm </example> L'hints qui sopra, farà considerare a <tt/menu/ l'ipotesi di raggruppare <tt/emacs/ assieme ad altri editor che sono contrassegnati nella stessa maniera. Per esempio, <tt/vi/ nel proprio sistema ha la definizione hints="Small,Expert" e ci sono troppi elementi in /Apps/Editors, menu considerà di creare un sotto-menu /Apps/Editors/Expert e mettervi entrambi <tt/vi/ ed <tt/emacs/ (naturalmente solo se si ha <tt/hint_optimes=true/ nel file /etc/menu-methods/menu.h). <sect>La taskbar e la barra del titolo di fvwm Se 1500 pacchetti Debian registrassero ciascun bottone, i bottoni riempirebbero presto tutto lo schermo, rendendo il tutto inutilizzabile. Le poche applicazioni che sono considerate importanti abbastanza da essere incluse nella taskbar generalmente variano di molto da sistema a sistema, rendendo impossibile selezionare una lista di applicazioni fortunate che possono risiedervi in ogni sistema Debian. Se, essendo amministratore del sistema, si desidera che <prgn/fvwm2/ abbia alcuni bottoni, si possono installare i file di quei pacchetti in <tt>/menu/$package</>, contenenti un elemento di menu come il seguente: <example> ?Package(xmball):needs=button\ section=Games/Puzzles\ icon=path-to-pixmap.xpm\ title="Xmball"\ command=/usr/games/xmball </example> e si faccia come segue: <example> cd /etc/menu-methods/ cp fvwm2 fvwm2button vi fvwm2button </example> e si rimuovano tutti gli elementi, aggiungedone uno come quello qui di seguito. Per il resto, lasciare tutto invariato. <example> supported button="+ Style \"" $title "\" TitleIcon" $icon " Exec " $command "\n" endsupported startmenu: "AddToTitlebar \n" endmenu: "\n" submenutitle:"" mainmenu: genmenu: "buttondefs.hook" </example> (Ovviamente un utente normale (non amministratore) può specificare i suoi 'buttonfile' nella sua directory ~/.menu/). <chapt>Cosa dovrebbe fare un pacchetto contenente delle applicazioni <sect> Fornire un file di menu Un pacchetto dovrebbe fornire un file di menu <tt>/usr/lib/menu/<nome-pacchetto></tt> che contenga le informazioni riguardo ciascun programma che voglia rendere disponibile attraverso i menu. <sect> Aggiungere un hook a dpkg nei propri pacchetti Si dovrebbe aggiungere una riga come questa al proprio script <tt/postinst/ <example> if test -x /usr/bin/update-menus; then update-menus; fi </example> e lo script <tt/postrm/ dovrebbe avere <example> if test -x /usr/bin/update-menus; then update-menus; fi </example> (che è la stessa riga sia nello script postinst che nel postrm). <chapt>Cosa dovrebbe fare un pacchetto con un gestore di menu Ciascun pacchetto contenente un <em/gestore di menu/ (cioè programmi che visualizzino menu) dovrebbe fornire uno script o programma in <tt>/etc/menu-methods/</tt> che possa leggere i file di menu. Questo script verrà eseguito da <prgn/update-menus/, che comunicherà allo script gli elementi di menu che devono essere installati tramite lo standard input (stdin) Gli script in <tt>/etc/menu-methods/</> dovrebbero essere file di configurazione, quindi l'utente può ottimizzare il comportamento dello script, e questi devono sempre includere il file <tt>/etc/menu-methods/menu.h</> all'inizio con il comando <tt>!include menu.h</> Per la stessa ragione, agli script in <tt>/etc/menu-methods/</> è richiesto di usare le seguenti funzioni configurabili: <tt/title()/ per il titolo (al posto di <tt/$title/), <tt/icon()/ per l'icona (al posto di <tt/$icon/), <tt/term()/ per eseguire il comando <tt/text/ sotto <tt/X11/. <tt/sections_translations()/ per la lista di traduzioni dei nomi di sezione disponibili. Quest'ultima è disponibile solo se si <tt>!include lang.h</tt> Esempi di script per quasi tutti i window manager per Debian sono inclusi nel pacchetto <tt/menu/ in <tt>/usr/share/doc/menu/examples</tt>. Se si lavora su degli script propri, si possono usare i trucchi descritti in "The internals of the menu package", alla sezione "The update-menus program", per eseguire solo i propri script, invece di far eseguire tutti gli script di update-menus (si può risparmiare parecchio tempo). Lo script non dovrebbe essere eseguibile all'interno del pacchetto. Invece è <tt/postinst/ che dovrebbe aggiungere il bit di esecuzione e poi eseguire <prgn/update-menus/ (se è eseguibile). Similmente lo script <tt/postrm/, quando richiamato con l'opzione "remove", dovrebbe rimuovere il bit di esecuzione ed eseguire <prgn/update-menus/ (se è eseguibile). Ecco un esempio di uno script <tt/postrm/ usando <prgn/sh/: <example> #!/bin/sh set -e inst=/etc/menu-methods/#PACKAGE# case "$1" in remove) if [ -f $inst ]; then chmod a-x $inst if [ -x /usr/bin/update-menus ]; then update-menus ; fi fi ; purge) #remove the files that install-menu creates: (cd /etc/X11/twm/; rm system.twmrc menus.dat menudefs.hook) ; upgrade); *) echo "postrm called with unknown argument \`$1'" >&2 exit 0 ; esac </example> Ed anche un buon esempio di <tt/postinst/: <example> #!/bin/sh set -e inst=/etc/menu-methods/#PACKAGE# if [ -f $inst ]; then chmod a+x $inst if [ -x /usr/bin/update-menus ]; then update-menus fi fi </example> <var>Nota:</var> <var>Precedenti versioni di menu, inserivano lo script <tt>/usr/sbin/wm-menu-config</tt>. C'era un errore: lo script era disponibile solo quando era installato menu e quindi lo script menu-method non era eseguibile se menu era installato in un secondo tempo. </var> <var>E' considerato ormai deprecato, evitare di usarlo ancora.</var> Evitare di far sì che il proprio pacchetto <em/dipenda/ dal pacchetto menu! Il modo migliore per dire a dpkg che il pacchetto può coooperare con menu è: <example> Suggests: menu </example> Si consideri l'uso di "depends" solo se si ritiene che sarebbe veramente difficile fornire una ragionevole configurazione predefinita per i sistemi in cui menu non è installato. <chapt>Come un utente può "aggirare" menu <sect>Configurare i menu Un utente può specificare le proprie voci di menu nella directory <tt>~/.menu</tt>. I file possono avere nomi arbitrari fintanto che viene usata la nuova sintassi per le voci di menu. Dovrebbero cominciare con: <example> ?package(pacchetto-installato): </example> o <example> ?package(local.cose_mie): </example> se è un pacchetto non installato ufficialmente da Debian. (Qualsiasi pacchetto che cominci con <tt/local/ è considerato installato). Se un utente vuole avere i propri "menu method", dovrebbe creare una directory <tt>~/.menu-methods</> e mettervi dentro tutti gli script che desidera vengano eseguiti. (Se esiste <tt>~/.menu-methods</>, allora quando verrà eseguito <prgn/update-menus/ non verrà cercato <tt>/etc/menu-methods</>). Un amministratore che intendesse aggiungere degli elementi di menu a livello di sistema, dovrebbe metterli in <tt>/etc/menu</tt> e non in <tt>/usr/lib/menu/package</> in quanto potrebbero essere sovrascritti da un aggiornamento di pacchetto. <sect>Fare in modo che un elemento di menu non sia visualizzato Se un utente vuole rimuovere un elemento preso dal menu di sistema (in <tt>/etc/menu</>)), allora potrà usare questo trucchetto: <example> echo -n > ~/.menu/package </example> Un file vuoto comunicherà ad <prgn/update-menus/ che il pacchetto corrispondente non deve avere nessun elemento di menu visualizzato. <sect> Includere altri file <var>Commento storico di Joost:</var> <var> Soltanto per curiosità ho di recente letto la mailing list di KDE. Vi ho trovato delle discussioni su quanto fosse buono il sistema di menu di Debian (whow, grazie, ragazzi!), ma una persona diceva che mancava una funzionalità: non poteva includere altri file all'interno dei menu a livello utente. Beh, in verità era possibile già allora ma non ben documentata. </var> Per includere il contenuto del file /usr/lib/menu/somefile, aggiungere questo al proprio file di menu: <example> !include /usr/lib/menu/somefile </example> A parte quello, è possibile rendere il file della voce di menu eseguibile (<tt>chmod a+x ~/.menu/pacchetto</>), e fare una cosa del tipo: <example> #!/bin/sh cat /usr/lib/menu/somefile sed -e "/unwanted_entry/s/?package(/?package(notinstalled./" \ /usr/lib/menu/someotherfile </example> per ottenere lo stesso effetto, con l'aggiunta della flessibiltà di eliminare le righe indesiderate. <chapt>Il pacchetto menu in dettaglio <sect>Il programma update-menus All'avvio, update-menus controlla il file <tt>/var/run/update-menus.pid</> e l'id di processo al suo interno. Se c'è un processo di <prgn/update-menus/ con quell'identificativo esegue un kill su di esso. Se esiste <tt>/var/lib/dpkg/lock</>, fa un fork in background e restituisce il controllo a dpkg. Il processo in background testa <tt>/var/lib/dpkg/lock</> più o meno ogni secondo finchè il file non viene eliminato. Dopo questo, <prgn/update-menus/ legge i file delle voci di menu nelle seguenti directory: <tt> /etc/menu /usr/lib/menu /usr/share/menu/default </> (se un utente esegue <prgn/update-menus/, questo metterà ~/.menu in cima alla sua lista). Per ciascun riga rappresentante un elemento di menu in ciascun file, viene controllato se il pacchetto corrispondente è installato (lavora sui file per la vecchia sintassi delle voci di menu). Gli elementi di menu per tutti i pacchetti installati, sono aggiunti assieme in un buffer mantenuto in memoria (ad eccezione di quelli eseguibili i quali vengono eseguiti e lo standard output viene messo nel buffer). Una volta terminata la lettura dei file di menu, <prgn/update-menus/ procede con l'esecuzione degli script in /etc/menu-methods/, questi gestiscono il buffer precedentemente creato attraverso lo stdin. (Se <prgn/update-menus/ viene eseguito da un utente, cercherà di eseguire gli script all'interno di ~/.menu-methods, e se non esiste la directory allora eseguirà quelli in /etc/menu-methods). Come aiuto per il debugging si può usare <example> update-menus --stdout > /tmp/menu-stdin </example> dopodichè visualizzare il file /tmp/menu-stdin per vedere cosa è stato dato in input ad <tt/update-menus/ per i menu-methods Questo può essere utile anche per chi scrive degli script di /etc/menu-method. Eseguire <prgn/update-menus/ ogni volta che si cambia qualcosa, comporta un consumo di tempo non indifferente. Quindi potrebbe essere comodo eseguire <prgn/update-menus --stdout/ una volta e dopo eseguire : <example> /etc/menu-methods/mymethod < /tmp/menu-stdin </example> (se porta via comunque molto tempo, basta provare modificando /tmp/menu-stdin e rimuovendo il 90% più o meno degli elementi) <sect>Il programma install-menu I file <tt>/etc/menu-methods/$wm</> sono file eseguibili che cominciano con la linea: <example> #!/usr/sbin/install-menu </example> e così esegue il programma, nascondendolo nel file di configurazione del window mangaer specifico nel primo argomento della linea di comando. Questo file di configurazione consiste in: <enumlist> <item>la versione di compatibilità ("menu-1" or "menu-2"). <item>dove i file debbano essere letti/memorizzati. <item>che "needs" è supportato, e che file di wrapper dovrebbe essere utilizzato per ciascuno "tipo". </enumlist> Fare riferimento a <tt>/usr/share/doc/menu/examples/</> del pacchetto menu per maggiori dettagli. Opzioni di <prgn/install-menu/: <example> -v (verbose) fornisce informazioni dettagliate -d (debugging) fornisce informazioni per il debugging </example> Alcuni window manager non supportano direttive quali "include" all'interno dei loro file <tt/system.*rc/ (quali <prgn/m4/ o <prgn/cpp/ preprocessing), non possono leggere i file <tt/menudefs.hook/ generati da install-menu in base ai loro file di configurazione <tt/system.*rc/. Per essere ancora in grado di usarli, <prgn/install-menu/ copia il file <tt>$path/$examplercfile</tt> come <tt>$path/$rcfile</tt> (avendo <tt/$examplercfile/ e <tt/$rcfile/ definiti nel file di configurazione di <prgn/install-menu/ e <tt/$path/, anche <tt/$rootprefix/ o <tt>${HOME}/userprefix</tt>, in base che sia root o un utente ad eseguire il file), e rimpiazza tutte le occorrenze di "install-menu-defs" con il file <tt/$genmenu/ appena generato. Come esempio, si consideri quanto segue: <tt>examplercfile=system.foo-wm-example</tt>, <tt>rcfile=system.foo-wm</tt>, <tt>genmenu=menudefs.hook</tt> e <tt>rootprefix=/etc/X11/foo-wm</tt>. Ora, se <prgn/install-menu/, viene messo in esecuzione, per prima cosa genererà il file <tt>/etc/X11/foo-wm/menudefs.hook</tt>. In seguito, leggerà il file <tt>/etc/X11/foo-wm/system.foo-wm-example</tt> riga-per-riga e ne copierà il contenuto in <tt>/etc/X11/foo-wm/system.foo-wm</tt>, sostituendo ciascuna occorrenza di <tt>install-menu-defs</tt> con il contenuto del file <tt>/etc/X11/foo-wm/menudefs.hook</tt>. Per attivare questo modo di copiare il file, basta definire le variabili <tt/$examplercfile/ e <tt/$rcfile/ nel file di configurazione <prgn/install-menu/ (per esempio, <tt>/etc/menu-methods/fvwm</tt>), ed assicurarsi che esista <tt>$path/$examplercfile</> (<tt>$path</> può essere sia <tt/$rootprefix/, che <tt/$userprefix/). Se si è alle prese con un "menu method", si può usare quanto segue per effettuare un debug in maniera semplice: <enumlist> <item>usare <tt>update-menus --stdout > /tmp/menu-stdin </tt> per creare la lista degli elementi di menu in <tt>/tmp/menu-stdin</tt> dopo di che <item>si può eseguire il menu-method in questione con (se è stato chiamato wm): <example> ./wm -v < /tmp/menu-stdin </example> (Si usi <tt/-v/ per la prolissità, <tt/-d/ per il debugging e si otterrà una discreta quantità di dati in output!) </enumlist> <sect>Struttura dello script di configurazione install-menu I menu-method presenti in <tt>/etc/menu-methods/*</> sono principalmente composti di molte definizioni "campo=valore", che comunicano ad <prgn/install-menu/ come generare lo script <tt/system.$wmrc/. In questo modo è possibile ottimizzare i file <tt/system.$wmrc/ generati in base alle proprie esigenze. Una riga come quella che segue <example> treewalk="c(m)" </example> indica che la variabile treewalk per impostazione predefinita ha il valore "c(m)". Per un esempio di questi script si può guardare <tt>/usr/share/doc/menu/examples/*</>. <taglist> <tag><tt/compat="menu-1"/ <item> Due valori sono possibili: <taglist> <tag><tt/"menu-1"/ <item> le direttive di menu sono terminate con un carattere di fine-riga.</item> <tag><tt/"menu-2"/ <item> le direttive di menu sono terminate da un "punto e virgola"</item> </taglist> Deve essere scritto appena dopo la direttiva <tt>!include "menu.h"</tt> di modo che <file>menu.h</file> possa usare il suo metodo di terminazione delle righe. <tag><tt/outputencoding="UTF-8"/ <item> Imposta il tipo di codifica per i file di output. Si usi <tt/iconv --list/ per avere al lista delle codifiche supportate. Dei valori utili sono "UTF-8" e "ISO-8859-1". Se non viene specificato nessun valore, viene presa in considerazione l'impostazione del sistema. <tag><tt/supported/ <tag><tt/endsupported/ <item> Racchiuso tra i tag <tt/supported/ ed <tt/endsupported/ si definisce quale tipo di "needs" sia supportato dal window manager. Qui di seguito l'esempio di un window manager che supporta sia needs=x11 che needs=text: <example> supported x11 =" ShowEntry(\"" title() "\", \"" $command "\")" text=" ShowEntry(\"" title() "\", \"" term() "\")" endsupported </example> Per la sostituzione di variabili (e le funzioni non mostrate fino ad ora), si faccia riferimento al prossimo paragrafo. Nell'esempio precedente si nota come per le voci di menu che hanno "needs=text", un istanza di xterm sia generata per eseguire il comando. Se è supportato solo x11, ed un pacchetto fornisce sia "needs=x11" che "needs=text", l'elemento di menu che verrà installato sarà quello con "needs=x11". Si possono spezzare le righe di codice su più righe, facendo terminare ogni singola riga (tranne l'ultima) con il carattere \. Assicurarsi che non vi siano spazi dopo il carattere \. <tag><tt/startmenu=""/ <tag><tt/endmenu=""/ <tag><tt/submenutitle=""/ <item> Definiscono come visualizzare a video l'inizio/fine di un menu e come scrivere un elemento di menu che si espande in un altro menu. Vengono sostituiti allo stesso modo in cui lo è il materiale "supportato" (riferirsi al prossimo paragrafo). <tag><tt/treewalk="c(m)"/ <item> Questa stringa definisce in quale ordine fare il dump di <tt/$startmenu/, <tt/$endmenu/, e <tt/$submenutitle/ (ed i suoi derivati). Ciascun carattere nella stringa si riferisce a: <example> c : fa il dump dei sotto menu m : fa il dump del $submenutitles del corrente menu ( : fa il dump di $startmenu ) : fa il dump di $endmenu M : fa il dump di tutti i $submenutitles del menu corrente e tutti i suoi derivati </example> L'impostazione predefinita è "c(m)". Per olvm, si necessita di: "(M)". <tag><tt/genmenu=""/ <item> Il file di menu da generare (in genere qualcosa del tipo <tt>system."$wm"rc</>). Il file potrebbe dipendere dal livello o titilo sul quale si sta lavorando, per esempio: <example> genmenu="/subdir/" replacewith($section," ","_") "/rc.menu" </example> (La sostituzione funziona come tutto il resto del materiale, vedere poco sopra). Si noti che i file generati in questo modo, sono terminati prima dell'apertura, quindi se si ha un getmenu come l'esempio di poc'anzi, si avrà che <tt/endmenu=/ sovrascriverà ciò che riguarda startmenu (ma probabilmente è necessario solo uno dei due modi comunque) <tag><tt>rootsection="/Debian"</> <item> il prefisso che assume ciascuna variabile <tt/$section/ <tag><tt/prerun=""/ <tag><tt/postrun=""/ <item> Il comando da eseguire prima di "resp." e dopo la generazione del file <tt/$section/ (genmenu). I comandi verranno eseguiti da <prgn/sh/. Esempio: <example> prerun="rm -rf " prefix() "/*" postrun="killall -USR1 fvwm2" </example> (La sostituzione funziona come in tutto il materiale "supportato", vedi più sotto). <tag><tt/preruntest=""/ <item> Come prerun, ma se il codice di ritorno del comando è un numero diverso da 0, menu si interromperà <tag><tt/also_run=""/ <item> Se ha un valore diverso da zero, install-menus, dopo aver generato i file di output, caricherà anche il file also_run, e lo userà i suoi valori per assegnarli a treewalk, genmenu, ecc di modo da generare del nuovo output. In questa seconda esecuzione, le variabili come <tt/prerun/ verranno ignorate. Si nota che NON è come <tt/prerun/ ecc: <tt/prerun/ ecc eseguono un comando con /bin/sh, <tt/also_run/ non esegue alcun comando, comunica semplicemente ad install-menu di caricare un altro binario, e generare del nuovo output. <tag><tt/onlyrunasroot=false/ <tag><tt/onlyrunasuser=false/ <item> Se onlyrunasroot ha valore true, menu uscirà senza nessun messaggio di errore nel caso venga eseguito come utente. Similmente si comporta per onlyrunasuser. <var>E' deprecato in quanto è più semplice utilizzare <tt/userprefix/ (o <tt/rootprefix/). </var> <tag><tt>preoutput="#Automatically generated file. Do not edit (see /usr/share/doc/menu/html)\n\n"</tt> <tag><tt>postoutput=""</tt> <item> Testo da porre all'inizio o alla fine del file generato ($genmenu). <tag><tt/command=""/ <item> Un comando da eseguire al posto di <prgn/install-menus/. Questo comando viene usato per risolvere problemi di compatibilità. In questo caso la compatibilità con versioni precedenti a menu-2 non è possibile. Esempio <example> command="cat > /tmp/menu-stdin" </example> <tag><tt/hotkeyexclude=""/ <item> Tasti da non usare come hotkey. Si possono usare le stesse variabili e funzioni come da esempio. Esempio: <example> hotkeyexclude="q" $section </example> <tag><tt/hotkeycase="insensitive"/ <item> Può assumere i valori "insensitive" o "sensitive". Determina se le hotkets devono gestire le maiuscole in maniera diversa dalle minuscole allo stesso modo (<tt/fvwm2/ gestisce le hotkey case-insensitive, <tt/pdmenu/ case-sensitive). Nel caso dei titoli "Xa" e "xb", con hotkeycase=insensitive verranno generati "X" e "b", mentre nel caso di case-sensitive verranno generate "X" ed "x" <tag><tt/sort=$sort ":" $title/ <item> Gli elementi di un menu verranno alfabeticamente ordinati in base a quali informazioni restituisce sort. Quindi se si ha <tt/sort=ifelse($command, "1", "0"):$title/, allora tutti i sottomenu appariranno sopra al comando. (Un sottomenu ha sempre un <tt/$command=""/). O, come Joey Hess scrisse: <example> Si può aggiungere un altro campo all'elemento di menu, con qualunque nome piaccia, per esempio lo si chiami "priority". Si aggiunga questa riga a /etc/menu-methods/*:: sort=ifelse($priority, $priority, "9") Questo avrà il risultato di ordinare le voci con la priorità più bassa in cima, e quelle senza priority che per impostazione predefinita assume valore 9, in fondo. (Si noti che confronta i valori alfabeticamente e non numericamente) </example> <tag><tt/rcfile=""/ <item> Se il window manager non supporta istruzioni come "include filename" o "read(filename)" all'interno del suo file di configurazione, si può rinominare suddetto file in <tt>system."$wm"rc-menu</> ed inserirvi un riga con "install-menu-defs" (senza apici, spazi bianchi attigui e deve essere l'unica istruzione della riga). Questi verrà dopo sostituito dal file <tt/$genmenu/ appena creato (si veda anche <tt/$examplercfile/). <tag><tt/examplercfile=""/ <item> Al bisogno (si veda <tt/rcfile/), questo rappresenta il file <tt/system.rc"$wm"-menu/, nel qual caso, usare una sintassi tipo <tt/rcfile=system.rc"$wm"/. <tag><tt/rootprefix=""/ <item> Il prefisso da utlizzare quando viene eseguito da root (si applica a $genmenu, $rcfile, $examplercfile ed altri vecchi file di cache). Se non è definito, il menu-method non verrà contato quanto eseguito da root. <tag><tt/userprefix=""/ <item> Si veda <tt/rootprefix/, ma quando viene eseguito da utente normale. <tag><tt/outputlanguage=""/ <item> Se impostato a "C" la traduzione automatica verrà disabilitata. Si noti che si può ancora usare translate() per forzare una traduzione. <tag><tt/hint_optimize=false/ <item> Se impostato a true, menu cercherà di generare un albero "ottimale", usando le variabili qui di seguito. Se invece ha il valore di false, manterrà la sezione come specificata nei file di elementi di menu (ed ignorerà gli "hint") <tag><tt/hint_nentry=6/ <item> Il numero ottimale di voci in un sottomenu. E' un numero a virgola mobile, quindi si può impostare anche 5.5 se non si riesce a decidere tra 5 e 6. Valori minori di 3 probabilmente non funzionano bene al momento. <tag><tt/hint_topnentry=5/ <item> Come hint_nentry ma riferito al più alto livello di menu. Spesso qui le voci aggiunte dai window manager (come Exit, Xterm, o altro) dei quali menu non è a conoscenza, quindi si vuole istruirlo per far inserire meno elementi in questo livello. <tag><tt/hint_mixedpenalty=15.0/ <item> Penalità per i menu "misti" (mixed). I menu misti sono quelli che hanno sia sottomenu che comandi diretti. <tag><tt/hint_minhintfreq=0.1/ <item> Frequenza minima relativa per le hint prima che vengano considerate. Una variabile interna per incrementare la velocità del processo di generazione dell'albero. Se si trova menu lento, si può provare ad aumentare questo valore (per esempio 0.2, 0.3). <tag><tt/hint_mlpenalty=2000/ <item> "max local penalty" (penalità massima locale), mentre determina gli alberi possibili, menu da delle penalità per i sottomenu che non contengono il numero desiderato di voci. La penalità corrisponde a sqrt(n_entry_opt-n_entry) (radice quadrata di n_entry_opt meno n_entry) ed eventualmente verrà calcolata come la somma di tutti i nodi. Per velocizzare il processo, menu scarterà le possibilità in cui ciascun nodo abbia una "penalità locale" maggiore di hint_mlpenalty. Si aumenti questo valore se si pensa che menu abbia escluso il proprio albero favorito (anche diminuire minhitfreq), si diminuisca questo valore se si pensa che menu sprechi troppo tempo. A causa di hint_max_ntry, l'infulenza di questa variabile sulle prestazioni è pressochè zero. <tag><tt/hint_max_ntry=4/ <item> Menu proverà, ricorsivamente per ciascun nodo, un numero di divisioni di menu pari al valore di hint_max_ntry. <tag><tt/hints_max_iter_hint=5/ <item> La ricerca di quale hints usare in un menu è dispendiosa. Grazie a come sono ordinati, menu sembra sempre trovate il modo migliore nel primo 2% di iterazioni. Così, un modo per velocizzare le cose è semplicemente quello di interrompere le ricerche di emnu dopo un "tot" di iterazioni. Questo valore controlla questa funzionalità limitando il numero di iterazione a 5+hint_max_iter_hint*number_of_possible_hints. Si imposti il valore di questa variabile ad un numero negativo per disabilitarne la funzionalità <tag><tt/hint_debug=false/ <item> La si imposti a true se si vogliono vedere righe e righe di debug sull'output. </taglist> <sect> Hints, ottimizzazione dell'albero Attualmente hints lavora in un modo alquanto strano: quando <tt/hint_optimize=true/ allora tutti gli elementi <tt/$section/ sono aggiunti alla specifica variabile <tt/$hints/ e l'ordine (/Apps/Editors o /Editors/Apps) dei risultanti hints è completamente ignorato. Dopo di che, gli hint di ciascuna voce di menu vengono gestiti dalla routine di ottimizzazione che calcolerà un albero ragionevole per quegli hint. Dato albero, deve aderire a quanto segue: Quando un utente cerca un programma "Program" con, hints "Good, Bulky, Heaven", mentre scorre attraverso gli alberi dovrebbe essere chiaro all'utente, per ogni nodo visitato, che sottomenu selezionare (o il menu dovrebbe avere "Program" direttamente in esso). Quindi il menu, al livello più alto dovrebbe apparire come : <example> Good Hell Microsoft </example> affinchè una persona che cercasse per una voce di menu con hints "Good, Bulky, Heaven" saprà che deve selezionare il sottomenu "Good". Il livello più alto non dovrebbe apparire come <example> Good Hell Heaven </example> in quanto non sarebbe chiaro se andare a vedere il menu Good o quello Heaven. Queste regole si applicano ad alberi differenti, ed il compito dell'ottimizzazione è di selezionare, in un arco di tempo finito, l'albero che meglio si addice alle esigenze dell'utente riguardo al numero ottimale di elementi di menu. <chapt>Variabili e funzioni degli script install-menu Le variabili "needs", "startmenu=", "endmenu=" e "submenutitle?" sono interpretati in questo modo: <sect> Costanti stringhe Qualsiasi cosa racchiusa tra doppi apici ("") è interpretata come una stringa e viene scritta così come è nel file di uscita. Caratteri quali \n, \t, ... verranno sostituiti come le espansioni del C (non \0xx, al momento). <sect> Variabili Qualsiasi cosa che sia composto da $[a-z,A-Z,_]* viene interpretata come una variabile e la corrispondente definizione dalla voce di menu viene sostituita. <sect1> Variabili speciali Le seguenti variabili sono gestite in un modo speciale da install-menus, sia perchè sono usate per altri scopi, che per il fatto che vengono modificate da install-menus (quelle contrassegnate da un "!" sono modificate da install-menus). <taglist> <tag> needs: <item> Usato per determinare quando un window manager supporti questa voce. <tag> command: <item> Se non è definita, la voce di menu verrà presa come un punto di ingresso per un sottomenu (in questo modo si possono specificare icone per i sottomenu). <tag> title!: <item> Usato per l'ordinamento (si veda la sezione). Per le voci di sottomenu (quelle con il "command" vuoto), è inizializzata nell'ultima parte della sezione. Si mantenga il titolo corto (2 parole al massimo). Il titolo è per le persone che già sanno quale programma usare. Si veda "longtitle" e "description" più sotto per descrizioni più lunghe. <tag> sort: <item> Usato per l'ordinamento (si veda la relativa sezione). Per far si che l'elemento sia all'inizio, si usi qualcosa con un valore ASCII basso, come "$". Per far mettere la voce in fondo alla lista invece usare "|". <tag> section!: <item> Usato per determinare la sezione della voce di menu. Gli elementi di menu che hanno un $command vuoto, come quelli che definiscono sottomenu, aggiungono $title alla fine di $section . I menu che non hanno un $command vuoto, hanno il loro $section modificato in $section/$title, o $section/$sort:$title, se $sort è definito. Le voci di menu con un sottomenu sono ordinate seguendo $section. Se si vuole recuperare il vero nome della sezione, si veda la variabile $basesection. <tag> basesection!: <item> Usato per contenere il vero nome della sezione. Ciò è utile in quanto $section verrà sostituito con $section/$title in casi speciali (si veda più sopra). Questo causerebbe dei problemi nel momento in cui si cerchi di eseguire un parent($section) poichè non si riuscirebbe a risalire alla sezione di livello superiore. Al posto si può usare $basesection che non conterrà mai $title. <tag> hotkey!: <item> Modificato per riflettere ciò che install-menus pensa sia la miglior hotkey per la voce di menu in questione. L'hotkey= nel file dell'elemento di menu, è preso come suggerimento che potrebbe essere sovrascritto se esiste un'altra voce con la medesima hotkey=. Per fornire due possibili hotkey per un elemento di menu si usi hotkey="ab", con "a" che sarà l'hotkey principale. </taglist> <sect1> Variabili privilegiate Quanto segue non è strettamente relativo ad install-menus, ma è buona cosa (si legga: essenziale) per usare le stesse variabili per le stesse cose. Quindi, si danno qui ulteriori consigli. Se si vuole inventarne di nuovi, lo sifaccia e si spediscano via mail al sottoscritto così che possa includerle. <taglist> <tag> icon: <item> La locazione dell'icona per la voce di menu. Se non si ha un'icona, non si inserisca icon= nell'elemento di menu. <tag> icon32x32: <item> Dove si trova il file di icona nel formato 32x32. <tag> icon16x16: <item> Dove si trova l'icona nel formato 16x16, di modo da permettere all'utente di scegliere tra i formati 16x16 o 32x32. <tag> longtitle: <item> Per coloro a cui piacciono titoli descrittivi (una riga circa). E' probabilmente meglio includerlo all'interno della voce di menu, mentre i window manager non (implicitamente) non lo mettono dei menu. In questo modo, coloro che vogliano titoli descrittivi posono azionare questa opzione. <tag> description: <item> Una descrzione ancora più lunga (circa 5 righe). Per esempio, una descrizione di una documentazione dentro delle pagine html generate da dwww </taglist> <sect1> Variabili suggerite Queste variabili non dovrebbero apparire spesso (o non apparire del tutto) nei file di menu forniti dai pacchetti. Sono pensate per essere usate dagli amministratori. Tuttavia si è avvisati che tutto il sistema Debian usa i seguenti nomi di variabile: <taglist> <tag> visible <item> Qualche applicazione aggiunge ad utmp il file utmp, cosicchè "chi" ed i suoi amici sappiano che sono in esecuzione (ciò specialmente per xterm ecc). Se $visible è impostato ad un valore diverso da "" o "none", xterm ecc non manderanno informazioni di logging ad utmp. (potrebbe non funzionare con tutti i window managers). <tag> geometry <item> Per le applicazioni che girano sotto X, questo dirà la dimensione della finestra (principale) che verrà creata (caratteri o pixel a seconda che sia un terminale o grafico). Se come manutentore di pacchetto si vuole utilizzare questo, si dovrebbe pernsare di impostare questa viariabile altrove in un file Xresources. </taglist> <sect> Funzioni Qualsiasi cosa composta da caratteri [a-z,A-Z,_] viene interpretato come una funzione (un errore è generato se la funzione non esiste). Gli argomenti di una funzione possono essere altre funzioni, stringhe o variabili. <taglist> <tag> prefix() <item> restituisce il prefisso di directory corrente: sia $rootprefix o $HOME/$userprefix, a seconda di chi esegue install-menu <tag> ifroot($rootarg, $userarg) <item> if(getuid()==0) print $rootarg, else print $userarg <tag> print($arg) <item> Come $arg da solo; se $arg è vuoto, genera un errore. <tag> nstring($n, $string) <item> scrive $string per $n volte. Quindi nstring(3,"Aa"= scriverà "AaAaAa". (utile usato in combinazione con level()). <tag> esc($arg1,$arg2) <item> Scrive $arg1 ma gestisce come "escape" tutte le occorrenze dei caratteri in $arg2 con un '\' (quindi, se arg1="hello", arg2="lo", scriverà "he\l\l\o"). <tag> escwith($arg1, $arg2, $arg3) <item> Come esc ma usa $arg3 come sequenza di escape. <tag> escfirst($arg1, $arg2, $arg3) <item> Come escwith, ma fa l'escape solo della prima occorrenza di $arg2. <tag> cppesc($arg1) <item> Sostituisce qualuque cosa non sia una lettera, numero o _ con $<codice-ascii-esadecinale>. Quindi, un '-', viene sostituito con '$2D'. In questo modo, $arg1 può essere utilizzato come #define in cpp. <tag> tolower($arg) <tag> toupper($arg) <item> Ritorna l'argomento convertito tutto in minuscole (lower) o maiuscole (upper). <tag> replacewith($s, $replace, $with) <item> Cerca $s per le occorrenze di caratteri della stringa $replace, e le sostituisce con il corrispondente carattere in $with. Esempio: replacewith("hello $world, %dir", "$% ", "123") ritorna: "hello31world,32dir" <tag> replace($s, $replace, $with) <item> Cerca $s per le occorrenze di $replace e le sostituisce con $with. Si noti che il comportamento di questa funzione è lievemente differente da quello di replacewith(). <tag> ifempty($arg1, $arg2) <item> Se $arg1 è vuoto, prende il valore di $arg2, altrimenti non comunica niente. Per compatibilità, $arg1="none" è interpretato come vuoto. <tag> ifnempty($arg1, $arg2) <item> Se $arg1 non è vuoto, viene preso $arg2. Per compatibilità, la stringa "none" è vista come vuoto. <tag> ifelse($arg1,$arg2,$arg3) <item> Se $arg1 non è vuoto, comunica $arg2, altrimenti ritorna $arg3. Per compatibilità, la stringa "none" è vista come vuoto. <tag> ifeq($arg1, $arg2, $arg3) <item> If ($arg1==$arg2) then print $arg3 <tag> ifneq($arg1, $arg2, $arg3) <item> If ($arg1!=$arg2) then print $arg3 <tag> ifeqelse($arg1, $arg2, $arg3, $arg4) <item> If ($arg1==$arg2) then print $arg3 else print $arg4 <tag> cond_surr($arg1, $arg2, $arg3) <item> Se $arg1 non è vuoto, ritorna $arg2$arg1$arg3, altrimenti non ritorna niente. Per compatibiltà la stringa "none" è vista come vuoto. <tag> iffile($arg1, $arg2) <item> Se il file $arg1 esiste e può essere aperto in lettura da chi sta eseguendo il processo, ritorna $arg2, altrimenti non torna niente. <tag> ifelsefile($arg1, $arg2, $arg3) <item> Se il file $arg1 esiste e può essere aperto in lettura da chi sta eseguendo il processo, torna $arg2, altrimenti ritorna $arg3. <tag> catfile($arg1) <item> Ritorna il contenuto del file $arg1. <tag> shell($arg1) <item> Ritorna l'output del comando $arg1 lanciato in shell. <tag> forall($array, "var", $exec) <item> Per ciascun elemento dell'array $array i cui elementi sono separati da virgole, imposta $var al valore dell'elemento, e stampa $exec. Esempio: <example> !include lang.h forall(sections_translations(), "lang", \ " section[" $lang "]=" translate($lang, title()) "\n") </example> <tag> parent($arg) <item> Si assuma $arg una direcotry, ritorna la directory di livello subito superiore: parent("/Debian/Apps/Editors") = "/Debian/Apps". <tag> basename($arg) <item> ritorna l'ultima parte della directory genitrice: basename("/Debian/Apps/Editors") = "Apps". <tag> stripdir($arg) <item> Tutto ciò che si trova dopo l'ultima barra (slash), per esempio basename() dovrebbe essere restituita: stripdir("/Debian/Apps/Editors") = "Editors". <tag> entrycount() <item> Il numero di elementi del menu. <tag> entryindex() <item> ritorna la posizione relativa della corrente voce, Comincia con 0 e l'ultima voce è entrycount() -1. BUG: se sort= qualsiasi altra cosa chce non sia $title, in questo caso entryindex() restituirà un valore errato. <tag> firstentry($arg) <item> restituisce $arg se è il primo elemento del menu (che � entryindex() = 0). Altrimenti non restituisce niente. <tag> lastentry() <item> Ritorna $arg se è l'ultima voce del menu (che è entryindex() = entrycount() -1). Altrimenti non ritorna niente. <tag> level() <item> restituisce il livello di annidamento del menu corrente rispetto a tutto l'albero di menu. <tag> add($arg1,$arg2) <tag> sub($arg1,$arg2) <tag> mult($arg1,$arg2) <tag> div($arg1,$arg2) <item> restituisce la somma, differenza, prodotto, divisione di $arg1 e $arg2. Si noti che gli argomenti sono stringhe che vengono convertite interi. Esempio: mult("24", entryindex()) <tag> rcfile() <tag> examplercfile() <tag> mainmenutitle() <tag> rootsection() <tag> rootprefix() <tag> userprefix() <tag> treewalk() <tag> postoutput() <tag> preoutput() <item> Queste funzioni restituiscono qualunque cosa per cui sono state definite dento il file menu-method. <tag> translate($lang, $text) <item> Traduce $text nella lingua $lang facendo uso di gettext, si veda <tt/forall/ per un esempio. Si noti che la lingua corrente deve essere impostata a "C". Se $lang è una stringa vuota, $text sarà tradotto nella lingua di sistema. Si veda sections_translations() per una lista di traduzioni disponibili. <tag> Concatenazione implicita <item> Le costanti di tipo stringa, le variabili e funzioni possono essre concatenate mettendole l'una dopo l'altra separate da uno spazio, come: "hello" ifelse($comma, $comma, " sorry" $period " comma not defined") " world" </taglist> </book>