Difference between revisions of "FVWM (Italiano)"

From ArchWiki
Jump to: navigation, search
(Installing FVWM)
(Starting FVWM)
Line 23: Line 23:
Fare attenzione a non confondersi o mischiare fvwm window manager con il progetto FVWM-Crystal, che è anch'esso disponibile sui repositories di Arch.
Fare attenzione a non confondersi o mischiare fvwm window manager con il progetto FVWM-Crystal, che è anch'esso disponibile sui repositories di Arch.
=Starting FVWM=
=Avviare FVWM=
fvwm will automatically be listed in kdm/gdm in the sessions menu. Otherwise, add
fvwm verrà automaticamente aggiunto nella lista delle sessioni dei menu di kdm/gdm. Altrimenti aggiungere
  exec fvwm2  
  exec fvwm2  
  exec fvwm
  exec fvwm
to your user's .xinitrc.
al proprio .xinitrc.
Users should check out [[SLiM]] tutorial for multiple environments with .xinitrc .
Gli utenti interessati dovrebbero controllare il tutorial [[SLiM]] per maggiori dettagli su ambienti multipli in .xinitrc .
For example mine .xinitrc is as follows:
Un esempio di .xinitrc:

Revision as of 19:02, 16 April 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 – فارسی

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 


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:


case $1 in
        exec ck-launch-session fvwm
        exec ck-launch-session awesome
        exec ck-launch-session $DEFAULT_SESSION

Make your FVWM better

When you start fvwm, you will get into the blank configuration. However, when you left-click on the desktop, you will be able to select to configure FVWM. chose wanted modules and you are ready to go. Check out the configs in the http://www.box-look.org. One should also consider checking FVWM forums at http://fvwm.lair.be

SLiM is very good login manager, that does not have many dependencies and acts well with FVWM. SLiM can also be used with multiple environments as well so it makes it very appealing if one need several environments, but want to have a real control of the process. Useful applications are similar to those suggested for Openbox or Fluxbox.

Since fvwm comes pretty blank in the beginning, you need to create your desktop from scratch... or almost. So here are some tips, gathered from the internet.

fvwm beginners guide by Jaimos F Skriletz

Although it is quite outdated, it helps to understand how FVWM functions and how to build your basic setup. FVWM beginners guide

Thomas Adam tips for FVWM2

Here are some tips by Thomas Adam written in http://fvwm.lair.be forum (Google cached copy of it). 
Currently it is unreachable due to some reason (I just copied and formatted everything).

I am not too good at these things, so bear with me. I've been seeing more and more configs (both in terms of answering questions on these forums, and via IRC, with ad-hoc email, etc.) that seem to be redefining existing functionality for no good reason other than (I assume) ignorance.

So here's a few things to bear in mind (in no particular order):

1. SetEnv.

Ah yes. SetEnv. I would never had imagined how such an insignificant command would annoy me so much, especially through its apparent mis-use. It seems more and more people are defining things like this:

SetEnv fvwm_home $[HOME]/.fvwm

Which is innocent enough, and indeed works. Except for the fact that it's completely unnecessary. FVWM defines for you (which you yourself can change) the environment variable FVWM_USERDIR which by default will point to ~/.fvwm -- so why in hell people seem to think setting "fvwm_home" is doing themselves any good is beyond me.

Now consider for the moment the implications of doing so. By and large it's fine, because you presumably wrote the configuration, right? Well, yes, but what happens when you decide to share your all singing all dancing, brand-new complex function you spent the past two days trying to write? What if it contains a reference to "fvwm_home"? The person deciding to try that function is going to come unstuck because he or she may not have "fvwm_home" defined. You should always rely on using "FVWM_USERDIR" where you need to reference a likely and pre-defined location for personal configuration files.

If you're one of these people whom uses a split configuration file via a series of Read commands, and hence had relied on something like:

Read $[fvwm_home]$[some_other_location]/file1

Read understands (and expands) the variable "$." relative to a path -- so you can use that as well to further increase neutrality.

Not to mention that it leaves endless environment variables defined which might only ever get used once.

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) ...


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. I'm too good to use ImagePath.

This one always makes me laugh, and it comes back to point 1, with SetEnv. Again, most people delight in doing something like this:

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

When actually all you need to do is this:

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

Then you can do stuff like this:

Style some_app Icon icon.png

And FVWM will know where to look by traversing the directories listed in the ImagePath.

If I think of any more, I'll let you know.

External Links

Links used in this tutorial: