FVWM (Italiano)

From ArchWiki
Revision as of 23:16, 16 April 2010 by Morbin (Talk | contribs) (External Links)

Jump to: navigation, search

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 – فارسی

Tango-preferences-desktop-locale.pngThis article or section needs to be translated.Tango-preferences-desktop-locale.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:FVWM (Italiano)#)
Note: La pagina è attualmente in traduzione. Temporaneamente, fare riferimento a quella inglese

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://fvwm.lair.be

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 forums, che via IRC, etc.) e sembra bisognerà ridefinire le funzionalità esistenti per non altri motivi se non (me ne rendo conto) l'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 files di configurazione personali.

Essendo una di quelle persone che usa una configurazione di files spezzettati attraverso una serie di comandi "read", si è 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 versus StartFunction versus RestartFunction

Unless you're someone as foolish as I am, and are still using FVWM 2.4.19, FVWM 1.24 and FVWM 2.2.5, this is going to be of consideration to you. OK, I joke. This is really only of importance to the small minority of people running FVWM stable (2.4.19). For the rest of you running 2.5.X (at the time I writing I would hope 2.5.16) then you need to be made aware of the following:

You don't need to use InitFunction

Gasp! It's true. In FVWM 2.4.X, you do need to use it because the Test command does not include tests for Init, Reboot, etc. However for FVWM 2.5.X, forget InitFunction, and incorporate it into your StartFunction. Here's an example:

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

Put the two together, and from within your StartFunction you can define what's in InitFunction via the use of the following:

+ I Test (Init) ...

Hence:

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

And that's it. There you have it. You now have a StartFuction which FVWM reads at Init, Reboot and Exit. The same logic applies for RestartFunction:

You don't need to use RestartFunction

What is even more perplexing about this is I have seen a lot of configs which define the following:

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

Now, guess what this does. That's right, when you reboot FVWM you get two copies of the same xterm running. That's because, again, StartFunction is read by FVWM at initialisation and reboots. FVWM hence re-reads RestartFunction and StartFunction and does the same thing twice. How do you get around this. Easy: remove the definition for RestartFunction entirely. If that application is only intended to be started during a restart (slightly odd scenario) then use:

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

3. Exec exec and the dreaded FvwmCommand versus PipeRead.

This one baffles me profoundly. The classic observation of this is with some of the many different incantations of Thumbnail functions that exist. Here's a snippet:

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

ARGH! What the hell is that all about? For the love of God, learn how to use PipeRead. Please? It's not that hard. Consider what's happening with the above. Exec forces a shell, some idiotic processing goes on (probably running convert a few times) and then FvwmCommand forces FVWM to be told instructions via FIFO. How dull, when all this time PipeRead would have saved you all of the superluousness of it all.

PipeRead forces a shell, but more importantly one is then able to "echo" commands back to FVWM. Not only does this synchronise things (especially if the PipeRead command exists within a function) but it means you don't have to worry about sending commands back indirectly via FvwmCommand. FvwmCommand is only useful if you're calling some external script that doesn't rely on directly ending with FVWM (or where you don't want it to block with PipeRead).

If you ever find yourself writing:

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

You want 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 raltà 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 guardare attraversando le cartelle elencate in ImagePath.

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

Links esterni

Links usati in questo tutorial: