Difference between revisions of "FVWM (Italiano)"

From ArchWiki
Jump to: navigation, search
m (Migliorare FVWM)
(Links esterni)
Line 186: Line 186:
 
* [http://fvwm.org/documentation/manpages/unstable/ FVWM man pages]
 
* [http://fvwm.org/documentation/manpages/unstable/ FVWM man pages]
 
* [http://www.box-look.org/ Box-Look]
 
* [http://www.box-look.org/ Box-Look]
* [http://fvwm.lair.be FVWM Forums]
+
* [http://www.fvwmforums.org FVWM Forums]

Revision as of 19:15, 23 September 2010

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Sommario help replacing me
Una panoramica sul gestore delle finestre FVWM
Articoli correlati
CWM - Evilwm - Fluxbox - IceWM - JWM - Openbox - Pawm - Twm - PekWM - Window Maker - Awesome3

FVWM è un potente window manager, basato su standard ICCCM e con supporto a multipli desktop virtuali per il sistema X Window. In continuo sviluppo, il supporto è eccellente. FVWM significa F? Virtual Window Manager, per chi si fosse incuriosito dal nome.

Il wiki purtroppo non è completissimo, quindi se qualcuno aggiungesse le proprie esperienze sarebbe fantastico. Penso non sia consigliabile copiare le pagine del manuale di FVWM, bensì differenti informazioni e trucchi riguardo le potenzialità ed usabilità di fvwm. Altre informazioni sono disponibili sui forum di Arch qui.

Installazione di FVWM

Ci sono tre versioni di FVWM disponibili per Archlinux. Sono chiamate stable, unstable e patched releases. Stable è la versione 2.4.20 (rilasciata 6-Dec-2006) ed è solida e stabile, anche se priva di alcune funzionalità, se la si confronta con la versione unstable. Installare stable fvwm con il seguente comando:

# pacman -S fvwm 

Il rilascio Unstable è la versione 2.5.28, che è stata resa pubblica abbastanza recentemente (20-Sep-2009). Anche se denominata instabile non sono stati osservati particolari problemi nel contesto generale. Per installarla:

# pacman -S fvwm-devel

I comandi sopra sono riferiti all'installazione delle versioni ufficiali di the WM. Se però si desiderano, o si ha bisogno di particolari funzionalità, è sempre possibile installare la "patched version" da archlinuxfr (vedere Unofficial user repositories) o AUR. Per installare da AUR:

$ yaourt -S fvwm-patched

o se si ha aggiunto archlinuxfr a pacman.conf, dare questo comando da root:

# pacman -S fvwm-patched

Fare attenzione a non confondersi o mischiare fvwm window manager con il progetto FVWM-Crystal, che è anch'esso disponibile sui repositories di Arch.

Avviare FVWM

fvwm verrà automaticamente aggiunto nella lista delle sessioni dei menu di kdm/gdm. Altrimenti aggiungere

exec fvwm2 

o

exec fvwm

al proprio .xinitrc.

Gli utenti interessati dovrebbero controllare il tutorial SLiM per maggiori dettagli su ambienti multipli in .xinitrc .

Un esempio di .xinitrc:

DEFAULT_SESSION=fvwm

case $1 in
fvwm*)
        exec ck-launch-session fvwm
        ;;
awesome)
        exec ck-launch-session awesome
        ;;
*)
        exec ck-launch-session $DEFAULT_SESSION
        ;;
esac

Migliorare FVWM

Al primo avvio di fvwm, ci si troverà con una configurazione inesistente, un desktop nero. Con un click sinistro sul desktop si potrà accedere alla configurazione di FVWM. Scegliere i moduli desiderati e procedere. Dare un'occhiata alle configurazioni su http://www.box-look.org. Si potrebbero anche consultare i forums di FVWM su http://www.fvwmforums.org

SLiM è un ottimo gestore delle sessioni, non ha molte dipendenze ed interagisce bene con FVWM. Lo si può usare anche in ambienti desktop multipli e si integra molto bene con ambienti di vario tipo, dei quali riuscirà ad avere un totale controllo nella gestione. Le applicazioni utili sono le stesse suggerite per i vari Openbox o Fluxbox.

Dal momento che appena installato sarà un ambiente vuoto e privo di tutto, sarà necessario configurare il tutto da zero... o quasi. Quelli che seguono sono suggerimenti e trucchi ottenuti da varie fonti su internet.

Guida fvwm per il principiante di Jaimos F Skriletz

Anche se non molto aggiornata, aiuta a capire le funzioni fondamentali di FVWM e a come creare la propria configurazione di base. FVWM beginners guide

Consigli di Thomas Adam per FVWM2

Ecco alcuni suggerimenti di Thomas Adam pubblicati su http://fvwm.lair.be forum (Google cache copiata). 
Attualmente non disponibile (Copiato e formattato tutto).

Non sono troppo abile per questo tipo di cose, siate quindi benevoli con me. Ho preso in esame molti tipi di configurazioni (sia in termini di domande e risposte su questi forum, che via IRC, etc.) che sembrano voler ridefinire le funzionalità esistenti senza una ragione valida se non (suppongo) per ignoranza.

Alcune cose da prendere in considerazione (in ordine sparso):

1. SetEnv.

SetEnv. Non avevo mai immaginato come un comando così insignificante potesse infastidirmi così tanto, specialmente a causa della sua poca importanza. Molti utenti lo definiscono così:

SetEnv fvwm_home $[HOME]/.fvwm

Cosa ben fatta e che in effetti funziona. Eccetto per il fatto che è completamente inutile. FVWM definisce per voi (ma questo lo potete anche cambiare) la variabile d'ambiente FVWM_USERDIR che di default punta a ~/.fvwm -- quindi, perchè tanti utenti pensano che configurando "fvwm_home" sia molto meglio?.

Pensiamo per un momento alle implicazioni che questo comporta. Nell'insieme non è male, perchè presumibilmente si sarà scritta la configurazione, giusto? Bene, ma cosa succederà quando si decide di mettere in condivisione l'intero nuovo sistema configurato dopo aver passato gli ultimi due giorni per scriverlo? Cosa succederà se contiene il riferimento a "fvwm_home"? Chi decide di provare quella funzione sta mettendosi nei guai perchè non ha definito "fvwm_home". Bisognerebbe sempre fidarsi usando "FVWM_USERDIR", dove sarebbe necessario un qualcosa come un luogo predefinito per i file di configurazione personali.

Se capita una di quelle persone che usa una configurazione di file spezzettati attraverso una serie di comandi "read", e ha invocato qualcosa di questo tipo:

Read $[fvwm_home]$[some_other_location]/file1

Read capisce (ed espande) la variabile "$." relativa al percorso -- così la si può usare come un ulteriore incremento alla neutralità. Inutile menzionare che lascia definite interminabili variabili d'ambiente che avrebbero solo potuto essere usate prima.

2. InitFunction contro StartFunction contro RestartFunction

Per quelli che usano la versione 2.5.X (sperando esca presto la versione 2.5.16, al momento in cui scrivo) prestare attenzione a quanto segue:

Non è necessario usare InitFunction

In FVWM 2.4.X, non è necessario usarlo perchè il comando Test non include test per Init, Reboot, etc. Tutt'al più per FVWM 2.5.X, ignorare InitFunction, e incorporarlo in StartFunction. Ecco un esempio:

DestroyFunc InitFunction
AddToFunc   InitFunction
+ I Exec exec xsetroot -solid pink
+ I Exec exec xconsole
DestroyFunc  StartFunction
AddToFunc    StartFunction
+ I Module FvwmProxy
+ I Module FvwmButtons myBar

Metterle insieme e dal proprio StartFunction si può stabilire cosa va in InitFunction usando i seguenti:

+ I Test (Init) ...

Quindi:

DestroyFunc  StartFunction
AddToFunc    StartFunction
+ I Module FvwmProxy
+ I Module FvwmButtons myBar
+ I Test (Init) Exec exec xsetroot -solid pink
+ I Test (Init) Exec exec xconsole

E questo è tutto. Ora si ha StartFuction che porta FVWM a leggere Init, Reboot e Exit. La stessa logica è applicata per RestartFunction:

Non è necessario usare RestartFunction

Quello che lascia ancora più perplessi è l'aver visto molte configurazioni definite come segue:

DestroyFunc  StartFunction
AddToFunc    StartFunction
+ I Exec exec xterm -T Wooo -ls
DestroyFunc   RestartFunction
AddToFunc     RestartFunction
+ I Exec exec xterm -T Woo -ls

Quando si riavvia FVWM si ottengono due copie di xterm in esecuzione. Questo perchè, ancora, StartFunction è letto da FVWM all'avvio e al riavvio. FVWM quindi rilegge RestartFunction e StartFunction, e rifà lo stesso due volte. Quindi la soluzione è rimuovere interamente la definizione di RestartFunction. Se l'applicazione è usata solo per il riavvio usare:

DestroyFunc  StartFunction
AddToFunc    StartFunction
+ I Test (Restart) Exec exec xterm -T Woo -ls

3. Exec exec e il temuto FvwmCommand contro PipeRead.

Ecco qui una cosa che mi irrita profondamente:

DestroyFunc Thumbnail
AddToFunc   Thumbnail
+ I Exec nice 19...; some_other_shell_commands; FvwmCommand 'WindowStyle foo, bar'

Sarà molto meglio imparare a scrivere PipeRead. Consideriamo cosa succede nell'esempio sopra. Exec forza una shell e qualche assurdo processo va in esecuzione (il che potrebbe durare un po'), poi FvwmCommand forza FVWM ad essere istruito da FIFO. Quanto di questo tempo, avrebbe potuto far risparmiare PipeRead!

PipeRead forza una shell, ma la cosa più importante è che abilita i comandi "echo" a FVWM. Non lo fa solo sincronizzando le cose (specialmente se il comando PipeRead esiste senza una funzione) ma significa che non bisogna preoccuparsi dei comandi inviati indirettamente via FvwmCommand. FvwmCommand è utile solo se si richiama qualche script esterno che non si fida di una finalizzazione diretta con FVWM (o dove non si vuole bloccarlo con PipeRead).

infine...se ci si trova a scrivere:

+ I Exec ...; FvwmCommand '....'

significa che si vuole PipeRead.

4. Sono troppo bravo per usare ImagePath.

Questo mi fa sempre sorridere, e si ricollega al punto 1, con SetEnv. Ancora una volta, molti si deliziano con qualcosa del genere:

SetEnv fvwm_home $[HOME]/.fvwm
SetEnv fvwm_images $[HOME]/.images
SetEnv fvwm_icons $[fvwm_home]/.icons
Style some_app Icon $[fvwm_icons]/icon.png

Quando in realtà l'unica cosa da fare è questa:

# Remove all those damn SetEnv commands
ImagePath $[FVWM_USERDIR]/.icons:+

Poi si potrà fare una cosa del genere:

Style some_app Icon icon.png


E FVWM saprà dove puntare, attraverso le cartelle elencate in ImagePath.

Se mi viene in mente qualche altra cosa, vi farò sapere.

Links esterni

Links usati in questo tutorial: