Tout à fait d'accord avec Chacha, je n'aime pas trop cette version non plus où les reflets occupent une place trop importante, la réflexion que je faisais (que Bru a retranscrite ici) tendrait plutôt à trouver sa solution dans un éclaircissement des reflets en leur octroyant une transparence moindre, pas en leur accordant plus de place?
dans 1141170816:
... En l'état actuel, je me suis surpris à attendre plusieurs minutes que les fenêtres se rapprochent de l'observateur. ...
ça c'est le but du jeu non?!
En tout cas, c'est cool que cela avance, c'est un projet vraiment sympa!
Alors ça c'est dingue ??? Hier soir, bizarrement, plusieurs fois, je me suis demandé comme notre grapheu et notre programmeu allaient ! Et le même soir, t'es reparti sur le projet ! On fait de la transmission de pensée ou quoiÂ
Alors déjà , le retour du dégradé gris m'a réconcilié avec lui ; parce qu'éffectivement ton astuce magique fait qu'on ne voit plus le probleme des lignes !!! Bravo. (Et pour ceux qui préfèrent le noir au gris, je pense qu'il sera très simple de faire une case à cocher dans les préférences de l'économiseur pour passer du gris au noir. Comme ça tout le monde sera content).
A propos de ton astuce magique, il semble que ça fasse que maintenant, il n'y ai plus de dégradé appliqué par dessus les reflets. Je me doute bien que tu as du chercher un compromis entre lignes grises moches sur les LCD, et dégradés sur les reflets. A toi de voir. A moins que l'explication de la disparition de ce dégradé soit tout autre ; j'ai peut-être raté quelque chose.
Pour ce qui est du passage de 1/3 à 1/2, je rejoins les avis ci-dessus, avec une petite nuance : donc oui, je trouve le 1/3 2/3 plus "photographique" (la fameuse règle des tiers quand on cadre). La nuance, c'est une idée : est ce que dans le calcul des reflets, il ne suffirait pas simplement de dire qu'ils descendent moins bas ? Je m'explique : en haut, imaginons que deux fenêtres A et B ont un écart vertical de x pixels. Leur reflets pourrait alors avoir un écart vertical de x/2 pixels ? Faut voir... il se peut très bien que ce soit très moche...
Pour le système de débug : bravo ! Ca va surement beaucoup te simplifier la vie ! C'est le genre de truc que personne ne voit, et qui est extrêment bon pour la survie du projet !Â
Pour tout le reste, ben comme je sais pas exactement ce que tu as tenté de corriger ou pas, je vais pas t'en refaire une liste de plus.
A très bientôt et encore <br /> PS : truc drôle : y'a une toute petite case blanche qui vient voler avec les fenêtres ??? Bref... pas très important... juste une FVNI !
Voila mon deuxième post dans ce forum : pour vous dire que je suis admiratif ! Vous avez sacrément travaillé : je vous suis depuis pas mal de temps dans l'ombre parce que j'y comprends que dalle à la programmation mais parce que le sujet me plaisait beaucoup.
Là , c'est carrément de la balle votre économiseur d'écran. Et puis, que vous ayez choisi d'utiliser QC me séduit pas mal aussi : ca permet à l'utilisateur lambda programmeur du dimanche de faire sa propre soupe avec vos ingrédients ! Bravo encore à ceux qui ont travaillé mais aussi à celui qui a lancé l'idée et en a parlé partout sur le net ;-) et qui va sans doute nous pondre une jolie page web pour ce projet !
Juste un petit message pour Boris : je crois que ça pourrait bien donner ton idée du fond qui recul tout droit à la "front row". T'as un peu avancé dans cette direction ?
Et toi bru ? comment ça roule ? t'as pu avancer un peu ?
Moi aussi j'ai hate de la beta... mais j'apprends à être patient
voilà j'ai fait un essais avec le fond qui recule, j'ai redécentré vers les 1/3 inférieur... baissé l'intensité des reflets. Il faudrait que je change ma facon de faire voler les fenetres parcequ'effectivement elles commence toutes en haut à droite.
Merci pour vos messages d'encouragement en tout cas ::)
voilà j'ai fait un essais avec le fond qui recule, j'ai redécentré vers les 1/3 inférieur... baissé l'intensité des reflets.
C'est super ! Quelques remarques, encore : -Pour le fond qui recule, je l'aurais bien vu reculer plus vite. -Le fond qui reste au fond, c'est bien parce que ça donne de la profondeur : il y a un reflet en permanence. Par contre, psychologiquement, j'aimerais bien que le fond "fasse quelque chose". Mais quoi ? Bon, ça c'est du chipotage. -À la limite, je me demande si les fenêtres ne devraient pas aller plus vite. Mais j'imagine que ce paramètre ce règlera. -Enfin, je ne sais absolument pas si c'est possible qvec QuartzComposer, mais peut-on activer un FullScreen Anti-Aliasing ? Parce que le bord des fenêtres fait très escalier.
Sinon, mille bravos, parce que ça progresse bien ! + Chacha
-Enfin, je ne sais absolument pas si c'est possible qvec QuartzComposer, mais peut-on activer un FullScreen Anti-Aliasing ?
On en a discuté un peu plus haut: il y moyen en modifiant les réglages FSAA de OpenGL, ce qui peut se faire avec ATI Controls si ton ordi a une carte de cette marque (on peut le faire par application), mais la perte de perf n'est pas négligeable.
à” yes ! T'as eu une idée géniale l'aut' jour avec ce truc du fond qui recule !!! Je suis fan !
Perso, je l'aurais fait partir deux fois plus loin (et donc, il partirai deux fois plus vite)... enfin, c'est juste pour voir (parce que j'aurai bien fait le test moi même, mais le débug mode ne semble pas marcher : en le cochant, il n'y avait aucune fenêtre)
Oui, pour l'animation où tout part à droite... ce serait cool de voir si tu peux y faire quelque chose... et par la même occasion, voir si tu peux y inclure les idées de faire sortir les fenêtres sur les cotés (et plus elle sont nombreuses, plus elles ont des chances de sortir... en gros, plus l'espace de vole est large)...
Et aussi voir comment ça se fait que certains changement de rotation dans leurs mouvement se fond brusquement : on dirait que les courbes douces n'agissent plus ?
Pour les reflets, ben oui, maintenant, avec le fond qui reste, ça asseoit bien le fait qu'il y ai des reflets... bref : c'est très beau !!! (même si j'ai une certaine nostalgie des reflets en dégradé...
Tous mes encouragement !!!
PS : je rêve ? ou t'as corrigé le problème du fond qui s'inversait verticalement pile poil à la fin du retour de tout le monde ?
PPS : ça fait toujours bizzare en début d'animation lorsque les fenêtres reculent de voir les reflets être anormalement haut derrière les fenêtres : à ce moment là , ça fait plus fenêtres fantômes que reflets... y aurait-il pas moyen de faire qu'en fonction de la valeur de recul, les reflets viennet d'en bas ? Je m'explique : - au tout tout début de l'animation, les reflets ne sont pas derrière les fenêtres, mais à une hauteur de l'écran plus bas. - au fur et à mesure que ça recul, cette valeur de décallage se réduit progréssivement jusqu'à ... - une fois au fond, c'est comme aujourd'hui, la valeur de décalage qui était d'une hauteur d'écran est revenue à zéro.
Ainsi, on ne vérrai plus ces reflets derrière les fenêtres elles-même au début ! Non ?
Actuellement, le screen-saver est dans une impasse. Le problème provient de "l'extinction" du SC. Elle se fait brutalement, sans laisser de temps pour l'animation du retour des fenêtres en position normale.
Pour éviter ça, j'ai biaisé le système en capturant tous les événements suceptibles de provoquer la fin du SC. Cette technique fonctionne. Après quoi, quand le retour des fenêtres est fait, je ré-émets l'événement au moteur du SC afin qu'il se termine. Et là , ça ne fonctionne pas correctement. Au mieux, le SC "disparait" de l'écran, mais reste actif (l'application tourne toujours), au pire, on a une impression de plantage (l'anim est stoppée, mais le système semble gelé).
Donc, je suis à la recherche d'une solution autre.
dans 1139059107:
une suggestion car j'ai tester avec 10.3 pour voir ce que ca fait, ben ca donne "Kernel Panic". manquerait il une ligne qui quiite le screen saver si l'on tente de le charger depuis une version incompatible d'OS (i.e pre -10.4) ?
Ce SC n'est pas compatible 10.3 car il utilise QC, qui n'est disponible qu'avec CoreImage, donc 10.4. Par contre, il ne fait pas planter le système. J'ai testé sur un 10.3. Le panneau de préférence affiche un message d'erreur comme quoi il n'a pas pu chargé le module, et le SC est remplacé par un simple écran noir. Les logs montrent par ailleurs que l'erreur provient de l'impossibilité de lier le framework QuartzComposer au module (normal, le framework n'existe que sous 10.4). Enfin, les modules SC tournent ou dans l'application PrefPanes.app, ou dans l'application ScreenSaverEngine.app. Ce ne sont donc que de simples applis qui, même si elle plantent, n'entrainent pas de kernel-panic. Le kernel-panic de Genose provient donc d'un autre problème, que seul les logs système peuvent éclairer.
Pour conclure, je me dirige donc vers une solution : mettre le SC comme une application normale (à l'image des premières betas que j'avais mis ici). La partie SC pure ne ferait que lancer cette appli, et lui envoyer des messages (comme démarrer l'anim ou la stopper). Cette aproche permettrait ainsi de laisser vivre le SC comme il doit vivre, tandis que l'application aurait toute lattitude pour faire ce que je veux.
Cool de te voir parmis nous ! Et merci de ces explications très claires !
dans 1141372892:
Pour conclure, je me dirige donc vers une solution : mettre le SC comme une application normale (à l'image des premières betas que j'avais mis ici). La partie SC pure ne ferait que lancer cette appli, et lui envoyer des messages (comme démarrer l'anim ou la stopper). Cette aproche permettrait ainsi de laisser vivre le SC comme il doit vivre, tandis que l'application aurait toute lattitude pour faire ce que je veux.
Ca a l'air d'être une très bonne idée ça ! Bon, bien sur, ça complique le futur processus d'installation... et ça installera deux éléments au lieu d'un. Mais s'il faut ça pour avoir un ensemble stable et conforme Quelques questions qui me viennent en me basant sur ton idée : - Est-ce qu'on pourrat malgré tout avoir le panneau des paramêtre directement dans le module des prefs système ? (je suppose que dans ce cas, l'appli irait lire un fichier plist...) - il n'y aura pas de prévisu dans le module des prefs... ou sinon, on y colera un tout petit module QC qui fera voler des minis fenêtre fictives juste pour faire joli ? - Question idiote... est-ce qu'on pourrait pas inclure l'application proprement dite dans le module du screensaver lui même vu qu'en réalité, c'est un dossier ? (comme ça, ça resimplifie le truc... tout le monde y voit qu'un module qui contient en fait une application dedans... et donc simplification et "normalisation" du processus d'installation ?...
Ca a l'air d'être une très bonne idée ça ! Bon, bien sur, ça complique le futur processus d'installation... et ça installera deux éléments au lieu d'un. Mais s'il faut ça pour avoir un ensemble stable et conforme
Faux. L'appli en question sera "packagée" (mise dans le bundle) du module SC lui-même. Donc pas de complication d'installation.
dans 1141373938:
- Est-ce qu'on pourrat malgré tout avoir le panneau des paramêtre directement dans le module des prefs système ? (je suppose que dans ce cas, l'appli irait lire un fichier plist...)
Oui. Les paramétrages du module se feront dans le panneau de préférence. Effectivement, les paramètres sont stockés dans un plist que la partie Appli va relire bien-entendu.
dans 1141373938:
- il n'y aura pas de prévisu dans le module des prefs... ou sinon, on y colera un tout petit module QC qui fera voler des minis fenêtre fictives juste pour faire joli ?
La version 62 que je n'ai pas encore livrée possède déjà une prévisu. La prévisu se base sur la fenêtre du panneau de préférence qui se met à danser... Cette fonctionnalité va rester. Sans entrer dans les détails techniques, le module SC et la partie Appli vont se partager le même code, c'est à dire, le code qui permet de créer les copies de fenêtre et de les agencer dans la vue du rendu QC. Donc ce que peut faire l'appli en plein écran, sera faisable par le module SC du panneau de préférence (pour la prévisu et pour le test).
dans 1141373938:
- Question idiote... est-ce qu'on pourrait pas inclure l'application proprement dite dans le module du screensaver lui même vu qu'en réalité, c'est un dossier ? (comme ça, ça resimplifie le truc... tout le monde y voit qu'un module qui contient en fait une application dedans... et donc simplification et "normalisation" du processus d'installation ?...
Ce SC n'est pas compatible 10.3 car il utilise QC, qui n'est disponible qu'avec CoreImage, donc 10.4.
QC n'est pas lié à CoreImage, ce n'est en fait que la version finale de Pixelshox (http://www.pol-online.net/pixelshox_technology/index.php) qui est disponible pour 10.3 aussi. Reste à voir si point de vue intégration, c'est facile à faire.
QC n'est pas lié à CoreImage, ce n'est en fait que la version finale de Pixelshox (http://www.pol-online.net/pixelshox_technology/index.php) qui est disponible pour 10.3 aussi. Reste à voir si point de vue intégration, c'est facile à faire.
Ah ah... POL c'est Paul-Olivier LATOUR... C'est un membre de l'équipe QC de Apple. Effectivement, peut-être est-il possible de faire tourner le framework QC sous 10.3...
Perso, je l'aurais fait partir deux fois plus loin (et donc, il partirai deux fois plus vite)... enfin, c'est juste pour voir
maintenant tu as une boite de réglage à la racine du qtz pour faire mumuse sur la profondeur tu peux meme brancher d'autres trucs pour le faire bouger dans le temps...
(parce que j'aurai bien fait le test moi même, mais le débug mode ne semble pas marcher : en le cochant, il n'y avait aucune fenêtre)
normal j'avais viré les images pour que ce soit + légé
Alors en gros j'ai nettoyé un peu et fait en sorte de commenter les patch pour que ce soit plus lisible (y compris par moi), pour savoir qui fait quoi. Pour les reflets ça me semble réglé, il n'y a plus le prb au moment du recul des fenetres, les reflets s'estomptent avec la distance par rapport à l'image. Les fenetres vont plus de part et d'autre de l'écran. Pour les fenetres qui ce regroupent en haut à droite j'ai pas encoer trouvé :-\\ en mode autonome ça semble fonctionner mais quand je passe en mode screensaver ça marche plus... fo encore que j'enquete...
Faut-il encore que je te félicite une fois de plus ? 8)
Bon, alors mesimpressions : - perso j'aime beaucoup que les fenêtres se ballades hors de l'écran à gauche et à droite ; et en plus tu sembles l'avoir super bien réglé ; ça me plait vraiement tel quel. - grace au réglage de profondeur que t'as mis à la racine, j'ai un peu fair joujou, et un bug apparaà®t (et confirme une impression que j'avais) : en le réglant à -30 par exemple, on voit que la modification d'éclairage que tu as fait dessus ne semble pas être la bonne : au lieu de s'assombrir, ça s'éclairci. - toujours sur ce réglage... et bien je doute. -5 j'aime bien même si ça fait un peu chargé quand on dépasse les 5 grandes fenêtres qui volent. -10 ça passe mieux quand y'a beaucoup de fenêtre... mais le fond semble un peu ridicul là bas au fond. Donc je sais pas... disons -7 pour l'instant ? A moins que tu imagines un réglage de profondeur automatique qui soit fonction du nombre de fenêtre ? et qui varie entre 5 et 10 selon qu'il y ai entre 1 et 15 fenêtres... - A propos du bug des reflets, je confirme, ça a l'air 100% réglé !!! Bravo !!! - Donc oui, il reste cette étrangeté qui fait que tout se barre à droite au début... et tu dis que ça ne le fait pas hors économiseur ? c'est quoi, c'est une valeur aléatoire qui détermine la direction de départ ?
Bon, on s'approche joliment d'une beta là au niveau de l'animation Je ne sais pas où t'en es bru de la partie programmation ? Elle marche finalement ta super méthode d'une application imbriquée dans l'économiseur ? (a propos, j'arrive à le planter au moins une fois par jour cet économiseur... il se fige, et je dois passer par alt pomme esc. surement pour les raison que tu nous as exposé plus haut.)
Je ne sais pas où t'en es bru de la partie programmation ? Elle marche finalement ta super méthode d'une application imbriquée dans l'économiseur ? (a propos, j'arrive à le planter au moins une fois par jour cet économiseur... il se fige, et je dois passer par alt pomme esc. surement pour les raison que tu nous as exposé plus haut.)
Ca avance, ça avance.
La partie application est terminée. Actuellement, je mets en place un protocole de communication entre la partie ScreenSaver et la partie Application afin que les 2 se puissent se causer.
Je pense être en mesure de vous livrer une beta en fin de semaine.
Bonsoir, voilà la nouvelle version. ?J'ai refait le module de gestion du fond, il n'y a plus d'éclairage dynamique avec des lampes, j'ai simulé ça avec une image de dégradé qui ce superpose. Du coup c'est plus facile à gérer, plus de problème de luminosité. ?J'ai introduit la variation de profondeur suivant de nombre de fenetres, ça va de -3 à -15. ?heu... pour les fenetres qui partent vers la droite je me garde ça pour demain 8)
Bon alors cool, ça ne s'éclaircit plus, mais par contre, je trouve que ça ne se fonce pas assez... il devrait s'assombrir un peu plus ce fond en reculant, non ? (bon, là , je sais, c'est du fignolage... )
Bien vu la petite phrase pour les crédits ! Je pense que ça devrait être présent tel que tu l'as faite par défaut, mais qu'on puisse completement l'enlever par une case à décocher dans les préférences. enfin je sais pas. Donne nous ton avis sur la question Bru. A moins qu'un paneau "credit" soit suffisant dans les préférences de l'économiseur... parlons en.
Pour les fenêtres qui se barrent à droite au début, je pense que j'ai trouvé pourquoi ça le fait pas en débug mode dans QC, alors que ça le fait dans l'économiseur : je suppose que t'as utilisé une valeur aléatoire ? à chaque démarrage de l'économiseur, les compteurs sont remis à zéro. Alors que dans QC, ils ne sont jamais remis à zéro tant que tu n'as pas quitté et relancé l'appli... ou quelque chose comme ça.
Alors je ne sais pas si ça va t'aider, mais ci-joint, j'ai fait un petit modul, sous forme d'une macro, qui permet d'obtenir une valeur absolument unique pour chaque fenêtre ! Tu y rentres sa taille en hauteur et largeur, ainsi que sa position en x et y, et il te sort une valeur comprise entre 0 et 1. C'est une sorte de générateur de valeur aléatoire. (C'est conçu de manière à contrer les cas particuliers... ça ne peut jamais sortir de valeurs négatives / ça fonctionne même si des entrées sont égales à zero...)
je viens rajouter un petit détail... je viens de montrer notre petite merveille ( :P ) à un pote : il m'a dit "mais le dégradé gris, c'est pas le même que celui de frontrow !..". Oui, il est très tatillon, pire que moi !
Alors je suis allé voir, et effectivement, le notre a deux peitits défauts : il n'est pas gris (il a une légère teinte), et il est pas assez clair... bref, celui de frontrow est un gris neutre à 33%. Alors voilà . J'ai fait le changement sur ma version... mais Boris, je te laisse faire la chose sur la version officielle.
A noté que chez moi, ce changement ne procure ni plus ni moins de lignes dues à nos écran LDC. Ca passe très très bien.
Euh, c'est normal que le fond ne bouge plus ou c'est juste chez moi? ???
oui maintenant le fond s'éloigne, et reste collé au sol, il ya juste la distance qui varie suivant le nombre de fenetres.
dans 1141826131:
Alors je suis allé voir, et effectivement, le notre a deux peitits défauts : il n'est pas gris (il a une légère teinte), et il est pas assez clair... bref, celui de frontrow est un gris neutre à 33%. Alors voilà . J'ai fait le changement sur ma version... mais Boris, je te laisse faire la chose sur la version officielle.
A noté que chez moi, ce changement ne procure ni plus ni moins de lignes dues à nos écran LDC. Ca passe très très bien.
hum...bah je pense pas qu'on soit obligé de coller à FrontRow, mais bon je veux bien. L'astuce que j'avais trouvé pour eviter l'effet de bandes sur le dégradé, c'était justement de donner une teinte. Si on fait un dégradé en niveau de gris on obtient une variation possible sur 84 valeurs ( (256*33)/100 ), alors quand variant sur les 3 canaux... Je regarde ça se soir, j'ai qu'un moche PC au boulot :-\\
Ah ok ! je comprends mieux pourquoi y'avait une toute légère teinte... mais alors franchement, chez moi, à y regarder de très prêt... je vois pas la différence entre un peu teinté ou pas au niveau de la dégradation en ligne. Je viens de revérifier : à l'oeil, c'est ni mieux ni moins bien.
La seule chose qui ai vraiment fait disparaitre les pires lignes, c'est d'avoir enlevé la surcouche en dégradé qui venait par dessus les reflets.
Quand à la question de coller à frontrow... pfff... je me dis juste que si mon pote a pu dire ça du premier coup d'oeil, je me dis qu'il ne sera pas le seul. Maintenant, le tout, c'est que ce soit beau !!! 8)
J'ai terminé le développement du screen-saver (SC) seconde mouture. Ca fonctionne plutôt bien, et pour le moment, aucune anomalie ne vient ternir le tableau. Rappelons que cette seconde mouture repose sur l'emploi conjoint d'un SC et d'une appli.
Le SC lui-même ne fait pas grand' chose. Il affiche sa fenêtre comme tout SC qui se respecte, mais elle est rendue transparente (afin de ne pas masquer le reste). Par contre, il lance une application qui, elle, sera chargée d'afficher l'animation des fenêtres volantes. Ensuite, il établit un canal de communication entre lui et cette appli. Dans ce canal, transiteront les réglages (quand il y en aura) du SC vers l'appli, ainsi qu'un message "stopper l'animation". Ce message est émis lorsque l'utilisateur "réveille" son mac par une action quelconque, juste avant que le SC se termine.
L'application ne fait que gérer l'affichage du rendu Quartz Composer en constituant la liste des fenêtres à faire danser, puis en lançant le rendu. De plus, elle va interroger le SC pour aller s'enquérir des réglages définis par l'utilisateur. Enfin, elle est dans l'attente de réception du message "stopper l'animation". Dès réception de ce dernier, elle enclanche le retour des fenêtres dans leur position d'origine, attend 0.8 seconde et enfin elle quitte.
Maintenant, j'aurai quelques souhaits à soumettre côté Quartz Composer.
1 : j'aimerai avoir la liste des tous les "inputs" que je dois utiliser, et pour chaque input, leur fonction.
2 : comment est gérée la taille de l'écran dans le rendu ? Je voudrais savoir, si via un "input" je peux envoyer une taille d'écran personnalisée. Ceci dans l'optique des écrans multiples de résolution différente.
3 : pouvez-vous (Boris ou Vinc) remettre en fonction l'"output" permettant de savoir quand les fenêtres sont revenues dans leur position initiale en fin d'anim. Les 1ers essais de Vinc n'étaient pas concluants. Mais peut-être que maintenant, expérience acquise aidant, cela sera possible de le faire.
Enfin, il est peut-être temps de voir ce qu'on peut mettre en réglage utilisateur, afin que je puisse concevoir la fenêtre de réglage idoine...
2 : comment est gérée la taille de l'écran dans le rendu ? Je voudrais savoir, si via un "input" je peux envoyer une taille d'écran personnalisée. Ceci dans l'optique des écrans multiples de résolution différente.
actuellement je peux te répondre qu'à ce point (je completerais ce soir). Le systeme de coordonnées est relatif, les valeurs ne sont pas en pixel mais varie de -1 à 1 sur l'axe X (-1 bord gauche, 0 centre de l'écran, 1 bord droit), pour le Y de -1 à 1 mais qui est divisé par l'aspect ratio de l'écran, en 4/3 on ce retrouve avec une valeur de -0.75 à 0.75. L'animation est donc identique pour le peu qu'on respecte l'aspect ratio. Actuellement la taille de rendu est donc celle de l'écran, par contre je sais pas comment ça ce passe sur écran multiple j'en ai pas...
Actuellement la taille de rendu est donc celle de l'écran, par contre je sais pas comment ça ce passe sur écran multiple j'en ai pas...
Donc, je vais présupposer que la taille du rendu est basée sur la taille de la vue qui affiche ce rendu (en l'occurence, la taille de l'écran actuellement).
Comme je maà®trise cette taille de vue, je peux donc m'adapter, pour chaque moniteur, à la résolution de ce dernier.
Oui, c'est comme ça que je le voyais : en fait, les cordonnées internes au rendu sont comme le dit Boris de -1 à +1, mais ça ne concerne que l'interrieur du rendu (et donc ça ne sert qu'aux calculs de l'animation)... mais vu de l'extérieur, donc vu de l'application, il n'y a pas de taille particulière : selon ce que j'en ai compris, si tu as deux écrans, l'un en 1024x760 et l'autre en 800x600, et bien il y a deux approches possible :
- lancer non pas un rendu, mais deux rendu (via deux fenêtres), un dans chaque écran, et leurs injecter à chacun leurs propres fenêtres et les coordonnées qui vont avec. La question que je me pose, c'est dans le cas d'une fenêtre qui est sur l'écran de droite : ses coordonnées sont-elles relatives à l'ensemble des deux écrans ? ou relative à l'écran de droite uniquement ? Parce que si c'est relatif à l'ensemble des deux écrans, ça risque d'être beaucoup plus compliquer pour faire positionner l'image d'une fenêtre au bon endroit : ça va supposer de faire une conversion de ses coordonnées "globales" en des coordonnées relative a sa propre fenêtre.
- Deuxième approche plus simple et plus globale : ouvrir une seule fenêtre de rendu qui recouvre l'ensemble de tous les écrans ! Ceci est tout à fait compatible avec le module QC : il n'a que faire de la taille de la fenêtre qui le contient : il a juste besoin de savoir a quel endroit afficher tel image de fenêtre : si elle doit être affiché à 1200 en x et à 300 en y, et bien elle sera sur le second écran (dans l'exemple décrit ci dessus). voilà tout. Enfin, seul défaut de cette méthode à fenêtre de rendu unique : si on a que deux écrans, le fond qui recul et ne bouge pas risque de se retrouver a cheval entre les deux écrans.
Bon, ceci dit, je vais répondre à ce que je peux, et Boris me corrigera ou complètera.
dans 1141893601:
j'aimerai avoir la liste des tous les "inputs" que je dois utiliser, et pour chaque input, leur fonction.
Voici ceux que je connais : - ReculAutoOnOff : FALSE > les fenêtres reviennent et restent à l'avant plan / TRUE > les fenêtres partent lentement et volent - ModeReculManuel : doit toujours être sur FALSE (c'est juste là pour facilité le développement du module QC par Boris) - ValeurReculManuel : peu importe (c'est juste là pour facilité le développement du module QC par Boris) - DureeAller : le temps en seconde que mettront les fenêtres pour aller au fond : actuellement est à 8 secondes (ça pourrait être un réglage utilisateur... entre 2 et 20 secondes ?) - DureeRetour : le temps en seconde que mettrons les fenêtres pour revenir au prmier plan : actuellement est à 0.5 secondes (ça pourrait aussi être réglable entre 0.2 et 2 secondes ?) - NombreDeFenetres : a toi d'y mettre le nombre exacte, fond compris. - image_0 à image_14 : les images : _0 est le fond d'écran - structureXY : là , je te laisse vérifier avec Boris...
pouvez-vous (Boris ou Vinc) remettre en fonction l'"output" permettant de savoir quand les fenêtres sont revenues dans leur position initiale en fin d'anim. Les 1ers essais de Vinc n'étaient pas concluants. Mais peut-être que maintenant, expérience acquise aidant, cela sera possible de le faire.
Cette fonction n'a jamais été retirée : cet output s'appelle ValeurReculReelle. C'est une valeur qui varie entre "0" (fenêtres en position d'origine) et "1" (fenêtres en train de voler). Il suffit de la surveiller, et quand elle revient strictement égale à 0, c'est que les fenêtres sont revenues !
Enfin, il est peut-être temps de voir ce qu'on peut mettre en réglage utilisateur, afin que je puisse concevoir la fenêtre de réglage idoine...
Au dela des durées d'aller et retour, je laisse la parole à Boris qui saura mieux ou qui aura + d'idées sur ce qui est rendable "modifiable par l'utilisateur" ou non.
Personnellement, à propos du choix possible de faire voler le fond ou non, j'ai pas dutout envie de le voir voler ; je trouve ça beaucoup plus parlant de simplement le voir reculer. Après, prenons-nous en compte le fait que certains vourdont voir tout voler, fond y compris ?... J'en sais rien.
Pour info, ce soir je suis dispo à partir de 20h30 21h pour une discussion sur iChat si vous le souhaitez : on pourrait discuter à trois des options utilisateurs ? Comme vous voulez.
Réponses
Tout à fait d'accord avec Chacha, je n'aime pas trop cette version non plus où les reflets occupent une place trop importante, la réflexion que je faisais (que Bru a retranscrite ici) tendrait plutôt à trouver sa solution dans un éclaircissement des reflets en leur octroyant une transparence moindre, pas en leur accordant plus de place?
ça c'est le but du jeu non?!
En tout cas, c'est cool que cela avance, c'est un projet vraiment sympa!
Alors déjà , le retour du dégradé gris m'a réconcilié avec lui ; parce qu'éffectivement ton astuce magique fait qu'on ne voit plus le probleme des lignes !!! Bravo. (Et pour ceux qui préfèrent le noir au gris, je pense qu'il sera très simple de faire une case à cocher dans les préférences de l'économiseur pour passer du gris au noir. Comme ça tout le monde sera content).
A propos de ton astuce magique, il semble que ça fasse que maintenant, il n'y ai plus de dégradé appliqué par dessus les reflets. Je me doute bien que tu as du chercher un compromis entre lignes grises moches sur les LCD, et dégradés sur les reflets. A toi de voir. A moins que l'explication de la disparition de ce dégradé soit tout autre ; j'ai peut-être raté quelque chose.
Pour ce qui est du passage de 1/3 à 1/2, je rejoins les avis ci-dessus, avec une petite nuance : donc oui, je trouve le 1/3 2/3 plus "photographique" (la fameuse règle des tiers quand on cadre). La nuance, c'est une idée : est ce que dans le calcul des reflets, il ne suffirait pas simplement de dire qu'ils descendent moins bas ? Je m'explique : en haut, imaginons que deux fenêtres A et B ont un écart vertical de x pixels. Leur reflets pourrait alors avoir un écart vertical de x/2 pixels ? Faut voir... il se peut très bien que ce soit très moche...
Pour le système de débug : bravo ! Ca va surement beaucoup te simplifier la vie ! C'est le genre de truc que personne ne voit, et qui est extrêment bon pour la survie du projet !Â
Pour tout le reste, ben comme je sais pas exactement ce que tu as tenté de corriger ou pas, je vais pas t'en refaire une liste de plus.
A très bientôt et encoreÂ
PS : truc drôle : y'a une toute petite case blanche qui vient voler avec les fenêtres ??? Bref... pas très important... juste une FVNI !
Voila mon deuxième post dans ce forum : pour vous dire que je suis admiratif !
Vous avez sacrément travaillé : je vous suis depuis pas mal de temps dans l'ombre parce que j'y comprends que dalle à la programmation mais parce que le sujet me plaisait beaucoup.
Là , c'est carrément de la balle votre économiseur d'écran. Et puis, que vous ayez choisi d'utiliser QC me séduit pas mal aussi : ca permet à l'utilisateur lambda programmeur du dimanche de faire sa propre soupe avec vos ingrédients !
Bravo encore à ceux qui ont travaillé mais aussi à celui qui a lancé l'idée et en a parlé partout sur le net ;-) et qui va sans doute nous pondre une jolie page web pour ce projet !
c'est quand la :)beta: ?!
Juste un petit message pour Boris : je crois que ça pourrait bien donner ton idée du fond qui recul tout droit à la "front row". T'as un peu avancé dans cette direction ?
Et toi bru ? comment ça roule ? t'as pu avancer un peu ?
Moi aussi j'ai hate de la beta... mais j'apprends à être patient
baissé l'intensité des reflets.
Il faudrait que je change ma facon de faire voler les fenetres parcequ'effectivement elles commence toutes en haut à droite.
Merci pour vos messages d'encouragement en tout cas ::)
[Fichier joint supprimé par l'administrateur]
C'est super ! Quelques remarques, encore :
-Pour le fond qui recule, je l'aurais bien vu reculer plus vite.
-Le fond qui reste au fond, c'est bien parce que ça donne de la profondeur : il y a un reflet en permanence. Par contre, psychologiquement, j'aimerais bien que le fond "fasse quelque chose". Mais quoi ? Bon, ça c'est du chipotage.
-À la limite, je me demande si les fenêtres ne devraient pas aller plus vite. Mais j'imagine que ce paramètre ce règlera.
-Enfin, je ne sais absolument pas si c'est possible qvec QuartzComposer, mais peut-on activer un FullScreen Anti-Aliasing ? Parce que le bord des fenêtres fait très escalier.
Sinon, mille bravos, parce que ça progresse bien !
+
Chacha
On en a discuté un peu plus haut: il y moyen en modifiant les réglages FSAA de OpenGL, ce qui peut se faire avec ATI Controls si ton ordi a une carte de cette marque (on peut le faire par application), mais la perte de perf n'est pas négligeable.
Perso, je l'aurais fait partir deux fois plus loin (et donc, il partirai deux fois plus vite)... enfin, c'est juste pour voir (parce que j'aurai bien fait le test moi même, mais le débug mode ne semble pas marcher : en le cochant, il n'y avait aucune fenêtre)
Oui, pour l'animation où tout part à droite... ce serait cool de voir si tu peux y faire quelque chose... et par la même occasion, voir si tu peux y inclure les idées de faire sortir les fenêtres sur les cotés (et plus elle sont nombreuses, plus elles ont des chances de sortir... en gros, plus l'espace de vole est large)...
Et aussi voir comment ça se fait que certains changement de rotation dans leurs mouvement se fond brusquement : on dirait que les courbes douces n'agissent plus ?
Pour les reflets, ben oui, maintenant, avec le fond qui reste, ça asseoit bien le fait qu'il y ai des reflets... bref : c'est très beau !!! (même si j'ai une certaine nostalgie des reflets en dégradé...
Tous mes encouragement !!!
PS : je rêve ? ou t'as corrigé le problème du fond qui s'inversait verticalement pile poil à la fin du retour de tout le monde ?
PPS : ça fait toujours bizzare en début d'animation lorsque les fenêtres reculent de voir les reflets être anormalement haut derrière les fenêtres : à ce moment là , ça fait plus fenêtres fantômes que reflets... y aurait-il pas moyen de faire qu'en fonction de la valeur de recul, les reflets viennet d'en bas ? Je m'explique :
- au tout tout début de l'animation, les reflets ne sont pas derrière les fenêtres, mais à une hauteur de l'écran plus bas.
- au fur et à mesure que ça recul, cette valeur de décallage se réduit progréssivement jusqu'à ...
- une fois au fond, c'est comme aujourd'hui, la valeur de décalage qui était d'une hauteur d'écran est revenue à zéro.
Ainsi, on ne vérrai plus ces reflets derrière les fenêtres elles-même au début ! Non ?
Actuellement, le screen-saver est dans une impasse. Le problème provient de "l'extinction" du SC. Elle se fait brutalement, sans laisser de temps pour l'animation du retour des fenêtres en position normale.
Pour éviter ça, j'ai biaisé le système en capturant tous les événements suceptibles de provoquer la fin du SC. Cette technique fonctionne. Après quoi, quand le retour des fenêtres est fait, je ré-émets l'événement au moteur du SC afin qu'il se termine. Et là , ça ne fonctionne pas correctement.
Au mieux, le SC "disparait" de l'écran, mais reste actif (l'application tourne toujours), au pire, on a une impression de plantage (l'anim est stoppée, mais le système semble gelé).
Donc, je suis à la recherche d'une solution autre.
Ce SC n'est pas compatible 10.3 car il utilise QC, qui n'est disponible qu'avec CoreImage, donc 10.4.
Par contre, il ne fait pas planter le système. J'ai testé sur un 10.3. Le panneau de préférence affiche un message d'erreur comme quoi il n'a pas pu chargé le module, et le SC est remplacé par un simple écran noir. Les logs montrent par ailleurs que l'erreur provient de l'impossibilité de lier le framework QuartzComposer au module (normal, le framework n'existe que sous 10.4).
Enfin, les modules SC tournent ou dans l'application PrefPanes.app, ou dans l'application ScreenSaverEngine.app. Ce ne sont donc que de simples applis qui, même si elle plantent, n'entrainent pas de kernel-panic.
Le kernel-panic de Genose provient donc d'un autre problème, que seul les logs système peuvent éclairer.
Pour conclure, je me dirige donc vers une solution : mettre le SC comme une application normale (à l'image des premières betas que j'avais mis ici).
La partie SC pure ne ferait que lancer cette appli, et lui envoyer des messages (comme démarrer l'anim ou la stopper). Cette aproche permettrait ainsi de laisser vivre le SC comme il doit vivre, tandis que l'application aurait toute lattitude pour faire ce que je veux.
.
Ca a l'air d'être une très bonne idée ça ! Bon, bien sur, ça complique le futur processus d'installation... et ça installera deux éléments au lieu d'un. Mais s'il faut ça pour avoir un ensemble stable et conforme
Quelques questions qui me viennent en me basant sur ton idée :
- Est-ce qu'on pourrat malgré tout avoir le panneau des paramêtre directement dans le module des prefs système ? (je suppose que dans ce cas, l'appli irait lire un fichier plist...)
- il n'y aura pas de prévisu dans le module des prefs... ou sinon, on y colera un tout petit module QC qui fera voler des minis fenêtre fictives juste pour faire joli ?
- Question idiote... est-ce qu'on pourrait pas inclure l'application proprement dite dans le module du screensaver lui même vu qu'en réalité, c'est un dossier ? (comme ça, ça resimplifie le truc... tout le monde y voit qu'un module qui contient en fait une application dedans... et donc simplification et "normalisation" du processus d'installation ?...
Faux. L'appli en question sera "packagée" (mise dans le bundle) du module SC lui-même. Donc pas de complication d'installation.
Oui. Les paramétrages du module se feront dans le panneau de préférence. Effectivement, les paramètres sont stockés dans un plist que la partie Appli va relire bien-entendu.
La version 62 que je n'ai pas encore livrée possède déjà une prévisu. La prévisu se base sur la fenêtre du panneau de préférence qui se met à danser...
Cette fonctionnalité va rester.
Sans entrer dans les détails techniques, le module SC et la partie Appli vont se partager le même code, c'est à dire, le code qui permet de créer les copies de fenêtre et de les agencer dans la vue du rendu QC.
Donc ce que peut faire l'appli en plein écran, sera faisable par le module SC du panneau de préférence (pour la prévisu et pour le test).
Voir réponse ci-dessus.
.
QC n'est pas lié à CoreImage, ce n'est en fait que la version finale de Pixelshox (http://www.pol-online.net/pixelshox_technology/index.php) qui est disponible pour 10.3 aussi. Reste à voir si point de vue intégration, c'est facile à faire.
Ah ah... POL c'est Paul-Olivier LATOUR... C'est un membre de l'équipe QC de Apple.
Effectivement, peut-être est-il possible de faire tourner le framework QC sous 10.3...
Je ferais le test.
.
maintenant tu as une boite de réglage à la racine du qtz pour faire mumuse sur la profondeur
normal j'avais viré les images pour que ce soit + légé
Alors en gros j'ai nettoyé un peu et fait en sorte de commenter les patch pour que ce soit plus lisible (y compris par moi), pour savoir qui fait quoi. Pour les reflets ça me semble réglé, il n'y a plus le prb au moment du recul des fenetres, les reflets s'estomptent avec la distance par rapport à l'image. Les fenetres vont plus de part et d'autre de l'écran.
Pour les fenetres qui ce regroupent en haut à droite j'ai pas encoer trouvé :-\\
en mode autonome ça semble fonctionner mais quand je passe en mode screensaver ça marche plus... fo encore que j'enquete...
[Fichier joint supprimé par l'administrateur]
Bon, alors mesimpressions :
- perso j'aime beaucoup que les fenêtres se ballades hors de l'écran à gauche et à droite ; et en plus tu sembles l'avoir super bien réglé ; ça me plait vraiement tel quel.
- grace au réglage de profondeur que t'as mis à la racine, j'ai un peu fair joujou, et un bug apparaà®t (et confirme une impression que j'avais) : en le réglant à -30 par exemple, on voit que la modification d'éclairage que tu as fait dessus ne semble pas être la bonne : au lieu de s'assombrir, ça s'éclairci.
- toujours sur ce réglage... et bien je doute. -5 j'aime bien même si ça fait un peu chargé quand on dépasse les 5 grandes fenêtres qui volent. -10 ça passe mieux quand y'a beaucoup de fenêtre... mais le fond semble un peu ridicul là bas au fond. Donc je sais pas... disons -7 pour l'instant ? A moins que tu imagines un réglage de profondeur automatique qui soit fonction du nombre de fenêtre ? et qui varie entre 5 et 10 selon qu'il y ai entre 1 et 15 fenêtres...
- A propos du bug des reflets, je confirme, ça a l'air 100% réglé !!! Bravo !!!
- Donc oui, il reste cette étrangeté qui fait que tout se barre à droite au début... et tu dis que ça ne le fait pas hors économiseur ? c'est quoi, c'est une valeur aléatoire qui détermine la direction de départ ?
Bon, on s'approche joliment d'une beta là au niveau de l'animation
Je ne sais pas où t'en es bru de la partie programmation ? Elle marche finalement ta super méthode d'une application imbriquée dans l'économiseur ? (a propos, j'arrive à le planter au moins une fois par jour cet économiseur... il se fige, et je dois passer par alt pomme esc. surement pour les raison que tu nous as exposé plus haut.)
Ca avance, ça avance.
La partie application est terminée.
Actuellement, je mets en place un protocole de communication entre la partie ScreenSaver et la partie Application afin que les 2 se puissent se causer.
Je pense être en mesure de vous livrer une beta en fin de semaine.
.
voilà la nouvelle version.
?J'ai refait le module de gestion du fond, il n'y a plus d'éclairage dynamique avec des lampes, j'ai simulé ça avec une image de dégradé qui ce superpose. Du coup c'est plus facile à gérer, plus de problème de luminosité.
?J'ai introduit la variation de profondeur suivant de nombre de fenetres, ça va de -3 à -15.
?heu... pour les fenetres qui partent vers la droite je me garde ça pour demain 8)
[Fichier joint supprimé par l'administrateur]
Bien vu la petite phrase pour les crédits ! Je pense que ça devrait être présent tel que tu l'as faite par défaut, mais qu'on puisse completement l'enlever par une case à décocher dans les préférences. enfin je sais pas. Donne nous ton avis sur la question Bru. A moins qu'un paneau "credit" soit suffisant dans les préférences de l'économiseur... parlons en.
Pour les fenêtres qui se barrent à droite au début, je pense que j'ai trouvé pourquoi ça le fait pas en débug mode dans QC, alors que ça le fait dans l'économiseur : je suppose que t'as utilisé une valeur aléatoire ? à chaque démarrage de l'économiseur, les compteurs sont remis à zéro. Alors que dans QC, ils ne sont jamais remis à zéro tant que tu n'as pas quitté et relancé l'appli... ou quelque chose comme ça.
Alors je ne sais pas si ça va t'aider, mais ci-joint, j'ai fait un petit modul, sous forme d'une macro, qui permet d'obtenir une valeur absolument unique pour chaque fenêtre ! Tu y rentres sa taille en hauteur et largeur, ainsi que sa position en x et y, et il te sort une valeur comprise entre 0 et 1. C'est une sorte de générateur de valeur aléatoire. (C'est conçu de manière à contrer les cas particuliers... ça ne peut jamais sortir de valeurs négatives / ça fonctionne même si des entrées sont égales à zero...)
En espérant que ça puisse t'aider
[Fichier joint supprimé par l'administrateur]
Alors je suis allé voir, et effectivement, le notre a deux peitits défauts : il n'est pas gris (il a une légère teinte), et il est pas assez clair... bref, celui de frontrow est un gris neutre à 33%. Alors voilà . J'ai fait le changement sur ma version... mais Boris, je te laisse faire la chose sur la version officielle.
A noté que chez moi, ce changement ne procure ni plus ni moins de lignes dues à nos écran LDC. Ca passe très très bien.
oui maintenant le fond s'éloigne, et reste collé au sol, il ya juste la distance qui varie suivant le nombre de fenetres.
hum...bah je pense pas qu'on soit obligé de coller à FrontRow, mais bon je veux bien. L'astuce que j'avais trouvé pour eviter l'effet de bandes sur le dégradé, c'était justement de donner une teinte. Si on fait un dégradé en niveau de gris on obtient une variation possible sur 84 valeurs ( (256*33)/100 ), alors quand variant sur les 3 canaux...
Je regarde ça se soir, j'ai qu'un moche PC au boulot :-\\
Ah ok ! je comprends mieux pourquoi y'avait une toute légère teinte... mais alors franchement, chez moi, à y regarder de très prêt... je vois pas la différence entre un peu teinté ou pas au niveau de la dégradation en ligne. Je viens de revérifier : à l'oeil, c'est ni mieux ni moins bien.
La seule chose qui ai vraiment fait disparaitre les pires lignes, c'est d'avoir enlevé la surcouche en dégradé qui venait par dessus les reflets.
Quand à la question de coller à frontrow... pfff... je me dis juste que si mon pote a pu dire ça du premier coup d'oeil, je me dis qu'il ne sera pas le seul. Maintenant, le tout, c'est que ce soit beau !!! 8)
A ce soir
J'ai terminé le développement du screen-saver (SC) seconde mouture.
Ca fonctionne plutôt bien, et pour le moment, aucune anomalie ne vient ternir le tableau.
Rappelons que cette seconde mouture repose sur l'emploi conjoint d'un SC et d'une appli.
Le SC lui-même ne fait pas grand' chose.
Il affiche sa fenêtre comme tout SC qui se respecte, mais elle est rendue transparente (afin de ne pas masquer le reste).
Par contre, il lance une application qui, elle, sera chargée d'afficher l'animation des fenêtres volantes.
Ensuite, il établit un canal de communication entre lui et cette appli. Dans ce canal, transiteront les réglages (quand il y en aura) du SC vers l'appli, ainsi qu'un message "stopper l'animation".
Ce message est émis lorsque l'utilisateur "réveille" son mac par une action quelconque, juste avant que le SC se termine.
L'application ne fait que gérer l'affichage du rendu Quartz Composer en constituant la liste des fenêtres à faire danser, puis en lançant le rendu.
De plus, elle va interroger le SC pour aller s'enquérir des réglages définis par l'utilisateur.
Enfin, elle est dans l'attente de réception du message "stopper l'animation".
Dès réception de ce dernier, elle enclanche le retour des fenêtres dans leur position d'origine, attend 0.8 seconde et enfin elle quitte.
Maintenant, j'aurai quelques souhaits à soumettre côté Quartz Composer.
Enfin, il est peut-être temps de voir ce qu'on peut mettre en réglage utilisateur, afin que je puisse concevoir la fenêtre de réglage idoine...
A vous la parole !
.
Attention car lorsque tu actives la demande d'un mot de passe pour sortir de veille un second fond de protection est noir...
actuellement je peux te répondre qu'à ce point (je completerais ce soir). Le systeme de coordonnées est relatif, les valeurs ne sont pas en pixel mais varie de -1 à 1 sur l'axe X (-1 bord gauche, 0 centre de l'écran, 1 bord droit), pour le Y de -1 à 1 mais qui est divisé par l'aspect ratio de l'écran, en 4/3 on ce retrouve avec une valeur de -0.75 à 0.75. L'animation est donc identique pour le peu qu'on respecte l'aspect ratio.
Actuellement la taille de rendu est donc celle de l'écran, par contre je sais pas comment ça ce passe sur écran multiple j'en ai pas...
Donc, je vais présupposer que la taille du rendu est basée sur la taille de la vue qui affiche ce rendu (en l'occurence, la taille de l'écran actuellement).
Comme je maà®trise cette taille de vue, je peux donc m'adapter, pour chaque moniteur, à la résolution de ce dernier.
.
- lancer non pas un rendu, mais deux rendu (via deux fenêtres), un dans chaque écran, et leurs injecter à chacun leurs propres fenêtres et les coordonnées qui vont avec. La question que je me pose, c'est dans le cas d'une fenêtre qui est sur l'écran de droite : ses coordonnées sont-elles relatives à l'ensemble des deux écrans ? ou relative à l'écran de droite uniquement ? Parce que si c'est relatif à l'ensemble des deux écrans, ça risque d'être beaucoup plus compliquer pour faire positionner l'image d'une fenêtre au bon endroit : ça va supposer de faire une conversion de ses coordonnées "globales" en des coordonnées relative a sa propre fenêtre.
- Deuxième approche plus simple et plus globale : ouvrir une seule fenêtre de rendu qui recouvre l'ensemble de tous les écrans ! Ceci est tout à fait compatible avec le module QC : il n'a que faire de la taille de la fenêtre qui le contient : il a juste besoin de savoir a quel endroit afficher tel image de fenêtre : si elle doit être affiché à 1200 en x et à 300 en y, et bien elle sera sur le second écran (dans l'exemple décrit ci dessus). voilà tout. Enfin, seul défaut de cette méthode à fenêtre de rendu unique : si on a que deux écrans, le fond qui recul et ne bouge pas risque de se retrouver a cheval entre les deux écrans.
Vous me comprenez ???Â
Suite page suivante...
Voici ceux que je connais :
- ReculAutoOnOff : FALSE > les fenêtres reviennent et restent à l'avant plan / TRUE > les fenêtres partent lentement et volent
- ModeReculManuel : doit toujours être sur FALSE (c'est juste là pour facilité le développement du module QC par Boris)
- ValeurReculManuel : peu importe (c'est juste là pour facilité le développement du module QC par Boris)
- DureeAller : le temps en seconde que mettront les fenêtres pour aller au fond : actuellement est à 8 secondes (ça pourrait être un réglage utilisateur... entre 2 et 20 secondes ?)
- DureeRetour : le temps en seconde que mettrons les fenêtres pour revenir au prmier plan : actuellement est à 0.5 secondes (ça pourrait aussi être réglable entre 0.2 et 2 secondes ?)
- NombreDeFenetres : a toi d'y mettre le nombre exacte, fond compris.
- image_0 à image_14 : les images : _0 est le fond d'écran
- structureXY : là , je te laisse vérifier avec Boris...
Cette fonction n'a jamais été retirée : cet output s'appelle ValeurReculReelle. C'est une valeur qui varie entre "0" (fenêtres en position d'origine) et "1" (fenêtres en train de voler). Il suffit de la surveiller, et quand elle revient strictement égale à 0, c'est que les fenêtres sont revenues !
Au dela des durées d'aller et retour, je laisse la parole à Boris qui saura mieux ou qui aura + d'idées sur ce qui est rendable "modifiable par l'utilisateur" ou non.
Personnellement, à propos du choix possible de faire voler le fond ou non, j'ai pas dutout envie de le voir voler ; je trouve ça beaucoup plus parlant de simplement le voir reculer. Après, prenons-nous en compte le fait que certains vourdont voir tout voler, fond y compris ?... J'en sais rien.
Pour info, ce soir je suis dispo à partir de 20h30 21h pour une discussion sur iChat si vous le souhaitez : on pourrait discuter à trois des options utilisateurs ? Comme vous voulez.