Archlinux.fr [Forums]

Hohoho !

La concurrence fait rage pour les scripts permettant de lancer xsnow dans un environnement Openbox + PcmanFM, voilà donc le mien.

Il y a 4 arguments possibles
- on pour lancer
- off pour éteindre
- toggle pour permuter l'état.
- restore pour restaurer l'état précédent (à mettre dans l'autostart.sh d'Openbox pour avoir son père noël qui vient rendre une petite visite dès le démarrage de la session).
Hors de question de modifier des fichiers de configuration à grands coups de sed.

Ça me fait penser: est-ce que quelqu'un saurait faire tourner xsnow/xpenguins sous Kde4... ça je dois dire que c'est *le* truc qui me fait haïr Kde4 (non, sans rire).

Kde4 inclue par défaut un effet reproduisant xsnow, il faut l'activer dans la configuration puis avec le raccourcie clavier le lancer

Oui mais non. Avec xsnow, tu as la neige, le vent, les sapins, petit papa noël...

Tiens, en plus, j'ai l'impression que l'effet neige a été retiré de Kde, je ne le retrouve pas et j'avais déjà un raccourci clavier en théorie.

Foolecho : xsnow se lance-t-il si tu le démarres depuis konsole ?

Oui ... mais rien ne s'affiche.

En fait, je crois que c'est parce que xsnow travaille directement sur X alors que Kde le recouvre (pourtant ça fonctionnait encore sous kde 3 si je me rappelle bien). C'est expliqué sur http://dropmix.xs4all.nl/rick/Xsnow/ . J'ai testé sous gnome, ça fait pareil. Rien.

Je me suis dit l'an dernier qu'il faudrait que j'y jette un oeil... mais bon, moi et le c... sans compter les problématiques X...

Pour les fêtes, je vais repasser sous Xfce... ou simplement lancer un autre affichage dédié à xsnow, mais bon, c'est pas pareil.


EDIT: à l'aide de xorg-server-xnest, un contournement du type: (ça force le respect quand même, une application qui, 10 ans après, fonctionne encore )

Salut,

J'ai installé openbox (+openbox-menu, feh et tint2) sur une distro avec KDE4, lancé une session Openbox depuis KDM (avec "openbox-session-kde" ou chose comme ça ça ne marchait pas), une personnalisation dans le script de mimas pour avoir un fond d'écran géré par feh : ça marche !

xsnow n'est pas ok avec les gestionnaires de bureau, et il est ok avec feh.

Je suppose que c'est du kde sans plasma dans ce cas ?

Pour rester un peu dans le sujet (... que j'ai sournoisement détourné ), mes pérégrinations m'ont conduit vers xpenguins-kde4, un fork de xpenguins qui fonctionne même sous KDE4 ! (avec des petits bugs d'affichage, si comme moi, vous faites tourner automatiquement vos fonds d'écran, mais rien de bien méchant). Là où c'est intéressant c'est que xsnow avait pompé son code de détection de X dessus ... Du coup, j'ai injecté cette partie dans xsnow et... ça ne marche pas parfaitement, cela aurait été trop beau (avec xsnow les dessins ne s'effacent pas au fur et à mesure, ça tartine vite l'écran (*) ). Cependant, j'arrive quand même à avoir l'affichage sur le bureau, ce qui est déjà un bon point !
Je pense qu'il faut remanier le code de xsnow pour bénéficier des améliorations de dessins de xpenguins... mais c'est du C et donc pas franchement ma tasse de thé ... ah, si c'était de l'objet... Malgré tout, je vais essayer voir si je peux arriver à redessiner en me basant sur xpenguins (mais je ne promets rien).

EDIT:
(*) d'ailleurs, je viens de voir que même le xsnow de base produit cet effet avec openbox + composite...

Oui, utiliser xcompmgr + Xsnow n'est pas jouable. Si tu parviens à quelque chose avec le code de Xsnow, tiens-moi au courant ?

Je vais essayer mais honnêtement, ça risque d'être très dur, voire impossible, pour moi. Le C n'est vraiment pas ma tasse de thé (imbuvable l'un comme l'autre d'ailleurs ).
Alors, en trifouillant simplement (comprendre: en décommentant une ligne de code existante ), ce qui autorise à lancer xsnow sur un fond complétement uni, plus de barbouillage... Mais il resterait encore le problème de détection des fenêtres/bureau qui est totalement foireuse (xsnow se comporte comme si tous les bureaux virtuels de kde étaient superposés... et ne tient pas compte non plus des déplacements).
J'ai un esprit plutôt synthétique (... heu, j'suis pas une machine) donc je pense avoir compris dans les grandes lignes comment xpenguins fait (mais je n'en serai sûr que lorsque j'aurais réussi à pondre quelque chose... et en dépit du code commenté, j'suis obligé de foncer dans le code ) et je voudrais calquer xsnow dessus puisque xpenguins paraît gèrer toutes ces histoires au poil ou presque (kde, composition, déplacement fenêtres), mais après ça rentre dans du C pur et là, franchement, rien qu'à initiatiser les variables j'ai mal au crâne (d'autant que xpenguins fait une gestion par thème, donc il va lire dans des fichiers la config)...

Mon objectif, déjà ambitieux, sera(it, plutôt) d'arriver à dessiner et d'animer quelque chose à la mode xpenguins... Ne serait-ce que pour voir si le comportement d'affichage et de détection des fenêtres colle bien.
(le problème actuel est que xsnow fait à la fois le dessin, les animations et les événements au niveau de X... Y aurait donc l'option de «juste chopper» les différences à modifier... mais d'une part, ça fait redondance de code, et ça serait encore pire à comprendre puisque double de code, etc.. en tant que développeur objet, je m'y refuse ... et tant que haineux du C, ça n'est pas dans mes cordes).

Clairement ça sera peut-être pour le Noël de l'année prochaine... .... au mieux...
Pour ce Noël si, j'vais y aller mollo, si j'arrive à animer quelque chose, je serai déjà heureux...

Pour la petite histoire, j'ai vu du côté de Kde qu'ils avaient effectivement retiré le plugin "neige" (de toutes manières, il était moche, très loin du charme de xsnow ^^), que personne ne bosse dessus actuellement et c'est rigolo de voir comme des utilisateurs veulent du xsnow.

Pour info, étant totalement incapable d'initialiser correctement la mécanique, ma démarche de développeur-orienté-langages-haut-niveau-objet-etc., (le C est une plaie pour moi ) qui-n'a-pas-que-ça-à-foutre, qui-déteste-être-coincé-sur-des-conneries (et qui c'est cassé le cul 2 jours là-dessus) et surtout-qui-veut-son-petit-papa-Noël-et-pas-dans-Xnest-ou-dans-un-autre-environnement, a été de partir d'un pseudo-thème santa-xsnow pour xpenguins (comme ça, hop, quasi-réglée la question de récupérer les infos).
... car j'ai dans l'idée maintenant d'adapter le comportement de ce petit monde xpenguins à l'aide du code du xsnow original et c'est déjà plus simple quand on dispose des "objets". J'ai déjà commencé, ça avance un peu mieux comme ça...

D'ailleurs autant vous montrer: j'ai réussi à faire l'animation du santa de la gauche vers la droite de l'écran avec son petit effet de haut en bas, voir capture suivante, réalisée sous Kde4 sans trucage !


«Il ne reste plus qu'à» ajouter les sapins... la neige, à l'animer comme l'original (la grosse difficulté va être d'adapter la question de l'empilement, je pense) et les effets météos (ça devrait le faire aussi, je sais faire accélérer/décélérer le traineau ), les options... et nettoyer ce foutoir...
Petit à petit, à mes heures perdues, je pense que je devrais y arriver grâce aux développements précédents.

L'avantage de cette mouture est qu'elle devrait bien tourner avec tout type d'environnement (y a un des petites sautes d'images comme avec xpenguin-kde4 du reste, mais bon...), composition ou pas (le gars qui évite le hors-sujet limite).

Déjà, ça va mieux, j'arrive à rentrer dans le code et à faire des trucs que je comprends à peu près.

Noyeux Joël !

(faut que j'arrête d'abuser sur ce très-limite-presque-hors-sujet ... si je finis par sortir un xsnow2, je ferai une petite annonce promis )



EDIT: Maintenant le bémol... Xsnow est sous copyright... si j'avance suffisamment, j'essaierais de voir avec l'auteur... 10 ans après...

J'étais loin d'imaginer qu'on en arriverait là en postant ce script.

C'était la bonne période pour en parler. En ce qui me concerne, sans les développements apportés par xpenguins, je ne me serais pas aventuré là-dedans (dommage que rajouter seulement la détection de kde4 n'ait pas été suffisant... je regarderai encore un peu de temps en temps, mais le code de xsnow est trop dense pour moi pour voir ce qu'il pourrait suffire de modifier... sachant que les fenêtres ne sont pas bien détectés sur l'original ).

Sinon, toujours sans trucage kde4: +sapins, +chute de neige (pas en continu pour le moment et pas encore avec les mêmes mouvements que l'original, mais ça ne devrait pas poser de problèmes):


Ceci dit, ayant codé à l'arrache pour l'instant, si je colle trop de flocons > erreur de segmentation au bout d'un moment... les joies du C... (vu que je n'ai pas trop regardé comment les tableaux étaient alloués, c'est déjà beau que ça fonctionne quand même pas si mal )

Tout ça pour montrer que ça fonctionne au moins sur le principe... maintenant y a plus qu'à ajouter les trucs qui manquent (neige tombant en continu, empilement... ... déneigement... du code).
Bémol: en fait avec openbox + xcompmgr, ces modifications ne fonctionnent pas, pas plus que xpenguins en fait (vous n'avez qu'à lancer xpenguins, vous comprendrez l'effet de barbouillage dont je parlais avec xsnow légèrement modifié sous kde4) ... bon après, on sait que xcompmgr n'est plus développé. Il faudrait faire un petit tour des gestionnaires de fenêtres et de composition en général (si certains peuvent me dire si le xsnow officiel ainsi que xpenguins ou xpenguins-kde4 fonctionnent correctement sous tel ou tel gestionnaire de fenêtres/composite, ça... m'éviterait d'avoir à vérifier ).

> en fait avec openbox + xcompmgr, ces modifications ne fonctionnent pas, pas plus que xpenguins en fait.

Ça fonctionne correctement si on utilise xcompmgr -a. J'ai vu ces barbouillages dont tu parles, il s'agit de l'image du bureau qui n'est pas restaurée version sans sprites avant d'être redessinée, au final on se retrouve avec un bureau qui conserve toutes les traces des sprites.

Il doit y avoir un conflit lors de l'obtention de l'image du bureau, soit l'un, soit l'autre se retrouve à dessiner sur une mauvaise image. Pourquoi ? Je n'en sais rien, Xlib m'est totalement obXcure.