J'ai installé l'ancien programme xsnow
avec Apt. Ce programme est censé faire apparaître la neige ( le type de précipitation ) sur le bureau. Cependant, l'exécution du programme ne fait rien d'autre que renvoyer le code suivant:
Xsnow-1.42resizeable, December 14th 2001 by Rick Jansen ([email protected])
WWW: http://www.euronet.nl/~rja/Xsnow/
En effet, le programme est conçu pour dessiner la neige sur la fenêtre racine X , comme indiqué sur le site Web:
Foire aux questions: je démarre Xsnow mais je ne vois pas de neige? Réponse: Xsnow fait neige sur la fenêtre "racine" de la fenêtre X. Cette fenêtre racine est souvent masquée par les gestionnaires de bureau, pour afficher des icônes et des outils. Donc, Xsnow fonctionne bien, vous ne pouvez tout simplement pas voir la neige! Voir le LISEZMOI pour les détails et les solutions possibles.
Je l'ai essayé dans une machine virtuelle Ubuntu 13.10, Kubuntu 13.10 et 14.04 et une Lubuntu Trusty Live USB. Cela fonctionne dans Xubuntu, car dans Xfce, nous voyons la fenêtre racine X par défaut. Dans le chat, quelqu'un a signalé qu'il fonctionnait dans Ubuntu 12.04, mais dans ma machine virtuelle Ubuntu 13.10, je ne vois pas de neige.
Le problème est que, comme je l'ai mentionné, ne xsnow
s'appuie que sur la racine X Window. La fenêtre racine X est le "parent" de toutes les autres fenêtres X et est donc également invisible, car les environnements de bureau modernes tels que KDE et Unity masquent généralement la fenêtre racine X avec un compositeur d'effets de bureau. Il xsnow
attire donc toujours la neige (vous pouvez en obtenir des bribes lors de la connexion et de la déconnexion en raison de la fragmentation des graphiques), ce n'est tout simplement pas visible. Sur des postes de travail plus simples comme Openbox et XFCE, la fenêtre X (et donc la neige) est complètement visible.
Existe-t-il un moyen de visualiser l'activité de la fenêtre racine X et ainsi voir la neige?
Réponses:
En utilisant KDE, vous pouvez utiliser le package kwin-snow-effect .
Comment installer:
Ensuite, dans KDE, vous pouvez configurer l'effet à partir de
System Settings
->Desktop Effects
->All Effects
et activer la neige.Vous pouvez également utiliser le plugin Compiz Snow , vérifiez son fonctionnement sur cette vidéo Youtube
J'ai trouvé xwinwrap, qui vous permet de coller n'importe quelle application comme arrière-plan de votre bureau. Cliquez ici pour le télécharger , ou ici pour lire la note de sortie du codeur
Il ne vous donne pas accès à la fenêtre racine (ce qui semble difficile dans la plupart des environnements de bureau). Et celui-ci ne fonctionne pas avec xsnow mais il fonctionnera avec beaucoup d'autres applications ...
la source
Je viens de faire plus de tests le 12.04 (ce n'est probablement pas la réponse pour le 13.10, mais pour ceux qui le veulent le 12.04)
Si dans gnome-tweak-tool, sous Bureau, je coche Demander au gestionnaire de fichiers de gérer le bureau. Puis à la fois dans Unity et dans les
xsnow
œuvres Unity-2D . Bien que dans l'unité-2d, la neige dans l'air est invisible, seuls les morts sont visibles, mais c'est à cause de ma carte graphique et de son pilote. Dans Unity, cela fonctionne parfaitement.Si dans gnome-tweak-tool je décoche Demander au gestionnaire de fichiers de gérer le bureau , il
xsnow
ne démarre même pas et lance une erreur à la fois dans Unity et Unity-2Dla source
Je suis un utilisateur de l' environnement Precise with Unity et j'ai eu le même problème jusqu'à l'exécution de cette commande:
Voici un extrait des notes de la page de manuel xsnow :
SGI Irix 5.x
Les utilisateurs de Silicon Graphics et Irix 5.x peuvent ne pas voir de neige ou de Père Noël du tout, tant que les icônes du bureau sont visibles. Pour contourner ce problème, exécutez cette commande:
Les icônes disparaîtront et Xsnow fonctionnera parfaitement. Pour redémarrer le bureau, il suffit de démarrer
ou sélectionnez Desk-top -> Home Directory dans le toolchest.
Il est même possible d'avoir les deux - des icônes de bureau et xsnow (et même plusieurs bureaux). Vous devez modifier le fichier de ressources du gestionnaire de fenêtres 4DWm , le fichier ~
hostname
/ .desktop- / 4DWm . Exemple:Global.backgroundDescription: -execute /etc/killall -TERM xsnow ; /usr/local/bin/xsnow
Desk 1.backgroundDescription: -execute /etc/killall -TERM xsnow ; /usr/local/bin/xsnow
Desk 2.backgroundDescription: -execute /etc/killall -TERM xsnow ; /usr/local/bin/xsnow
Redémarrez le gestionnaire de fenêtres (4Dwm) à partir du toolchest et Xsnow devrait apparaître. Cela arrête le Xsnow en cours d'exécution et en démarre un nouveau lorsque vous passez à un autre bureau.
la source
bash: /usr/lib/desktop/telldesktop: No such file or directory
. Merci d'avoir mentionné cette partie du README.gksu nautilus
(puis Je ne connaissais pas le commutateur --no-desktop, qui plus tard n'a pas aidé non plus ... .. cette commande a également root root! Mais quelque chose a mal tourné .. terriblement .. (Maintenant, je ne peux pas faire fonctionner compiz .. J'ai essayé de réinitialiser, de réinstaller, et tout .. Donc je ne peux pas conseiller d'essayer ça ..)Pour gnome, vous pouvez simplement lui dire de ne pas gérer le bureau
J'avais également rencontré une mention de l'utilisation de shantz-xwinwrap pour For Unity Compiz, cependant, il ne semble pas possible de l'utiliser avec la version 13.10 de l'unité sans un contrôle plus précis de xsnow.
Cela dit, si vous voulez l'essayer dans un terminal, exécutez:
Une fois installé, l'exécution possible de xwinwrap sans anibg pourrait ressembler à:
la source
/usr/lib/xscreensaver/plasma: No such file or directory /usr/lib/xscreensaver/plasma died, exit status 2
--root
et--windows-id
ne sont pas pris en charge par xsnow. Ces arguments proviennent d'un exemple d'utilisation de xwinwrap avec glmatrix qui accepte--root
et--window-id
comme arguments:xwinwrap -ov -fs -- /usr/lib/xscreensaver/glmatrix -root -window-id WID
par exemple fonctionnera bienSur une installation standard 12.04.3 64 bits, connectez-vous, ne disposez que d'une fenêtre de terminal près du bas de l'écran et démarrez xsnow, qui fonctionne. Semble être une connaissance restante de l'endroit où se trouvaient les fenêtres au démarrage de xsnow, et la coupure de neige se produit toujours après le déplacement ou l'icône de la fenêtre. Des problèmes se produisent lorsqu'une fenêtre se trouve en haut de l'écran. Déconnexion / in efface les anciennes positions de Windows, alors essayez une nouvelle connexion (ou peut-être un redémarrage de X). Le délai par défaut de 20 est assez proche du minimum pour moi, ce qui peut augmenter la neige.
Les options de xsnow sont décrites dans les pages de manuel ou avec le commutateur -h. -delay 30 fera un délai de 30 millisecondes entre les mises à jour, au lieu de la valeur par défaut qui est de 20. Je trouve que les choses deviennent floconneuses à 18, et pas de neige à 15, donc sur un système qui fonctionne autrement, un délai trop court casse les choses. Pour la version 13.10, il y a certainement une différence dans la façon dont les fenêtres "root" sont empilées. Le système d'unité 12.04 a une racine, un enfant, un petit-enfant, un bureau, un arrière-arrière-petit-enfant qui est mis à jour avec la neige et fonctionne. (voir sortie de
Le système d'unité 13.10 met à jour la fenêtre racine et le bureau n'a même pas d'enfant plein écran. Avec un débogueur, changer la fenêtre en cours de mise à jour sur le bureau fait apparaître des images, mais elles effacent l'arrière-plan, donc ce n'est pas une bonne solution. Aucune autre fenêtre recevant les mises à jour ne montre quoi que ce soit, donc je suppose que c'est un conflit avec le mécanisme d'unité, qui semble avoir besoin de quelques modifications pour que cela fonctionne (car l'idéal n'est pas de devoir changer autre chose que le programme xsnow).
Mise à jour pour 14.04 exécutant Unity Pour voir le Père Noël, abandonnez le bureau Unity et créez simplement un autre écran X sans lui. Basculez d'avant en arrière selon vos besoins, ou même exécutez des programmes avec -display: 1 pour apparaître sur le nouvel écran.
Autorisez d'abord quiconque à exécuter un serveur X
et définissez l'accès X à tout le monde Oui, vous pouvez exécuter avec sudo, mais vous aurez alors laissé des fichiers appartenant à root sur votre bureau et vous ne pourrez plus vous connecter avec l'interface graphique (utilisez un terminal virtuel pour supprimer la racine si vous le faites).
Avez-vous un autre gestionnaire de fenêtres installé pour pouvoir déplacer les fenêtres sur votre nouvel affichage (uniquement si vous voulez y exécuter d'autres programmes, ne vous embêtez pas si tout ce que vous voulez faire est de voir le Père Noël. Même un simple comme twm fera l'affaire , choisissez celle qui laisse la fenêtre racine exposée.
Exécutez ci-dessous sur un vt pour obtenir un xsnow plein écran.
Revenez à l'affichage d'origine sur vt7 avec Crtl-Alt-F7 et revenez à xsnow avec Ctrl-Alt-F8
Créer des xterms à partir de vt7 (serveur X d'origine activé: 0)
démarrez votre gestionnaire de fenêtres sur le nouvel écran à partir du nouveau xterm par exemple
Mise à jour 16.04: Beaucoup de choses se sont cassées depuis le 14.04 (voir bug # 1562219), mais vous pouvez toujours exécuter xsnow:
Joyeux Noël à tous
la source
Il existe une nouvelle version de xsnow , fonctionnant sur gnome, kde, fvwm, lcde et même raspbian: https://www.ratrabbit.nl/ratrabbit/content/xsnow/introduction
Il est prévu de pousser cette version dans le dépôt Debian.
La nouvelle version est également disponible sur sourceforge .
Depuis le site Web:
la source
Si vous regardez les instructions de compilation, vous obtenez:
Ils semblent avoir retiré vroot.h de la compilation car il était inclus pour KDE. Cependant, l'en-tête est toujours livré avec la dernière version:
et le déballer. Ouvrez
xsnow.c
et ajoutez une nouvelle ligne après 250 (il y a eu des problèmes lorsque je l'ai commentée là où elle était.)Ensuite , la construction (nécessite
xutils-dev
,xorg-dev
etlibxpm-dev
) avec:puis (en supposant qu'aucune erreur)
Est-ce que ça marche? La version compilée fonctionne ici mais je suis à Gnome, le 12.04, et non sur une machine virtuelle.
la source