Bon, j'arrive a obtenir la liste de tout les numéros de fenêtres, mais j'ai beau chercher je ne trouve pas comment obtenir les pointeurs windowRefs a partir des numéros...:crackboom:- Voici mon code : [tt] Â Â OSStatus retVal; int windowCount=-1; Â Â int currentWorkspace=-1; int i; NSMutableData *windowList; Â Â CGSConnection connection=_CGSDefaultConnection(); Â Â Â Â CGSGetWorkspace(connection, ¤tWorkspace);
NSLog(@Count:%i,windowCount); for (i=0;i<windowCount;i++) { NSLog(@Fenêtre numéro %i:%i,i,((int*)[windowList mutableBytes])); } [/tt]
J'ai aussi essayé avec les fonctions suivantes :
[tt]// Get on-screen window counts and lists. extern OSStatus CGSGetWindowCount(const CGSConnection cid, CGSConnection targetCID, int* outCount); extern OSStatus CGSGetWindowList(const CGSConnection cid, CGSConnection targetCID, Â int count, int* list, int* outCount);
// Get on-screen window counts and lists. extern OSStatus CGSGetOnScreenWindowCount(const CGSConnection cid, CGSConnection targetCID, int* outCount); extern OSStatus CGSGetOnScreenWindowList(const CGSConnection cid, CGSConnection targetCID, Â int count, int* list, int* outCount); [/tt]
Déjà je ne comprend pas quelle est leur différence, et ensuite comment régler le paramètre "CGSConnection targetCID". J'ai mis le même que pour "CGSConnection cid", mais ça me donne un nombre incorrect de fenêtres. C'est en essayant avec CGSGetWorkspaceWindowCount et CGSGetWorkspaceWindowList que j'obtiens pour le moment les meilleurs résultats, seulement c'est un mystère pour obtenir les windowRefs a partir des windowNumbers...???
Moi, j'ai utilisé [tt]CGSGetOnScreenWindowCount[/tt] et [tt]CGSGetWindowList[/tt] et ça marche très bien. Je peux par exemple récupérer tous les titres de toutes les fenêtres à l'écran.
Là , j'étudie le "code injection" afin de greffer mon programme au dock, ce qui me permet de contrôler les fenêtres de toutes les applis...
Mais la technique du "code injection" est relativement complexe, alors patience...
T'es vraiment obligé de passer par le "code injection" afin de prendre le contrôle Bru ? Quand j'ai vu ça, je me suis dit quelle usine à gaz, est-ce vraiment nécessaire ? ??? Car si oui, ça complique un tantinet les choses, pas facile à comprendre cette technique de "code injection" !
Là , j'étudie le "code injection" afin de greffer mon programme au dock, ce qui me permet de contrôler les fenêtres de toutes les applis...
Mais la technique du "code injection" est relativement complexe, alors patience...
T'es vraiment obligé de passer par le "code injection" afin de prendre le contrôle Bru ? Quand j'ai vu ça, je me suis dit quelle usine à gaz, est-ce vraiment nécessaire ? ??? Car si oui, ça complique un tantinet les choses, pas facile à comprendre cette technique de "code injection" !
Non, c'est assez simple en fait.
Le but du jeu est de pouvoir exécuter du code dans un thread qui tourne dans la partition de l'appli Dock.app. Ce code aurait donc les mêmes droits que le Dock pour la manipulation des fenêtres (voir ce qu'il peut faire lors de la miniaturisation des fenêtres).
Le programme principal (ou plutôt l'économisateur d'écran) se contenterait d'envoyer des messages à ce thread qui exécuterait les routines CG... permettant de faire des affineTransfrom sur chaque fenêtre visible à l'écran.
Pour le moment, je planche sur la façon d'envoyer ces messages (j'ai plusieurs solutions).
Le but du jeu est de pouvoir exécuter du code dans un thread qui tourne dans la partition de l'appli Dock.app. Ce code aurait donc les mêmes droits que le Dock pour la manipulation des fenêtres (voir ce qu'il peut faire lors de la miniaturisation des fenêtres).
Le programme principal (ou plutôt l'économisateur d'écran) se contenterait d'envoyer des messages à ce thread qui exécuterait les routines CG... permettant de faire des affineTransfrom sur chaque fenêtre visible à l'écran.
Pour le moment, je planche sur la façon d'envoyer ces messages (j'ai plusieurs solutions).
Oui j'ai vu qu'il fallait se servir des routines "mach_inject", qui se chargent alors de tout pour injecter le code. Tu veux donc te servir de ces fameuses AffineTransform...Ca peut être sympa comme effet.
Tu veux donc te servir de ces fameuses AffineTransform...Ca peut être sympa comme effet.
Oui, et pour 2 raisons :
1 - gérer la transformation de la fenêtre me semble plus simple que de créer une photo de la fenêtre puis de gérer les transformations de l'image de cette photo.
2 - ça permet d'avoir des fenêtres à jour en temps réèl (au lieu d'être figé au moment du déclenchement de l'économisateur).
Par contre, je suis une brelle au niveau graphisme, et surtout au sujet des affineTransfrom...
Par contre, je suis une brelle au niveau graphisme, et surtout au sujet des affineTransfrom...
Je te donnerais un coup de main pour les transformations si tu veux. Normalement ça doit fonctionner comme pour la classe NSAffineTransform, mais à l'échelle de la fenêtre.
Pour ma part, en ce moment je suis trés occupé à avancer sur un de mes projets, des que j'aurais un peu de temps j'essaierais d'avancer là -dedans, mais c'est pas du gâteau...:crackboom:-
Voici une petite appli de démo (ce n'est pas un screen-saver, mais juste une appli normale).
Cette démo ne fait que disparaitre (avec un effet de fondu-transparence) TOUTES les fenêtres présentes à l'écran, puis les fait ré-apparaitre.
L'utilisation est simple : il faut cliquer sur INSTALLER (le patch du dock), puis ensuite appuyer sur TESTER (réalise la démo sur la fenêtre de l'appli) ou TESTER2 pour toutes les fenêtres.
Maintenant, ne reste plus qu'à utiliser les affineTransform à la place de la tranparence pour faire ce que l'on veut des fenêtres. Mais ça, c'est Eddy qui s'y collera.
La démo est assez surprenante : on peut voir que OS X utilise des fenêtres pour un tas de choses...
Note : j'utilise la technique du patch du dock (voir sur SourceForge) pour contrôler les fenêtres. Le patch se présente sous la forme d'un thread supplémentaire dans le process Dock.app. Il ne gène pas, mais si vous voulez le supprimer, relancez le Dock, ou cliquez sur ENLEVER.
C'est du beau boulot Bru ! En effet, très surprenant l'effet, les fenêtres qui disparaissent, puis le dock et les icônes....ça ouvre la voie à pas mal de choses. <br />Tu m'envoies le projet quand tu veux, mais franchement là tu as fait le plus dur je trouve.
Et donc, là , en gros... il reste plus qu'à les faire voler en l'air ? Et même les icones vont voler donc dans tous les sens ?
Oui. Dans la démo, j'utilise la fonction de transparence des fenêtres pour contrôler leur disparition/réapparition. Mais je peux aussi utiliser la fonction affineTransform. C'est celle ci qui contrôle la forme de la fenêtre (on peut les déformer). Enfin, je peux aussi utiliser la fonction de déplacement pour les déplacer à l'écran. C'est la combinaison déplacement/deéformation qui va faire danser les fenêtres.
Dans la démo, on peut voir beaucoup de fenêtres qui n'en sont pas (icônes du finder sur le bureau, barre des menus, fond d'écran) : je pense qu'il ne faudra pas les faire danser, mais juste disparaitre... Mais ça on verra après.
Je ne suis pas du tout ni graphiste, ni matheux. L'utilisation des affineTransform me rebute donc, et ça me gave grave de devoir apprendre à les créer, alors que d'autres (Eddy) peuvent le faire pour moi. La prochaine démo (en fonction de nos disponibilités) fera danser les fenêtres.
dans 1112770594:
PS : et sous tiger... ça marchera pareil ?
Je pense que oui. J'utilise des apis (groupes de fonctions) non documentées. Mais ce sont les mêmes qu'Apple utilise pour Exposé (réduction/déplacement des fenêtres), et pour le Dock (effet Genius lors de la miniaturisation).
Ici, nous avons quelques gars qui font partie des beta-testeurs de Tiger. Ils peuvent tester la démo.
Tu m'envoies le projet quand tu veux, mais franchement là tu as fait le plus dur je trouve.
Y'a pas vraiment de projet pour le moment (en fait, ya un projet pour le patch du dock, et l'autre qui est l'appli test-screensaver).
En fait, j'ai implémenté dans le patch du dock ce qu'il faut pour transmettre des structures CGAffineTransform et CGPoint via un appleEvent pour pouvoir utiliser les fonctions CGSMoveWindow et CGSSetWindowTransform. Mais je n'ai pas pu tester, faute de connaissances suffisantes.
Peux tu me donner rapidement quelques structures CGAffineTransform (6 float je crois) qui, enchainées les unes après les autres, feront un effet de danse ?
Qui sont les plus forts ? MacGénération, Macbidouille ou Objective-cocoa ?
Tu connais ma réponse
Par contre, je viens de m'apperczvoir d'un petit probleme : une fois que toutes les fenêtres ont disparues, il ne reste non pas un fond noir, mais un fond bleu. Ce qui signifie que si on fait voler la fenêtre "bureau", et bien derrière, ce sera bleu... et j'imagine qu'Apple n'a pas prévu de pouvoir placer une couche de noir entre ce truc bleu, et le bureau...
Peux tu me donner rapidement quelques structures CGAffineTransform (6 float je crois) qui, enchainées les unes après les autres, feront un effet de danse ?
Le temps de faire les tests nécessaires et je t'envoie ça.
Par contre, je viens de m'apperczvoir d'un petit probleme : une fois que toutes les fenêtres ont disparues, il ne reste non pas un fond noir, mais un fond bleu. Ce qui signifie que si on fait voler la fenêtre "bureau", et bien derrière, ce sera bleu... et j'imagine qu'Apple n'a pas prévu de pouvoir placer une couche de noir entre ce truc bleu, et le bureau...
Z'en dites quoi ?
Le fond noir peut se bricoler, par exemple, en mettant une fenêtre factice en arrière plan, remplie de noir...enfin c'est à tester
Je trouve l'idée très sympa et j'ai hate de tester la prochaine version ! Je trouve le fond bleu plutot sympa, même si c'etait pas l'idée de départ. Pourquoi pas le mettre en option ? J'ai eu un bug etrange, apres avoir lancé et arreté, j'avais plus la fonction "Bureau" d'exposé. Sinon tout a marché nickel Je bidouille un peu cocoa alors je peux peut-etre vous aider dans mon temps libre.
Salut Obi, comment ca wan (oui, je sais, elle est nulle) ? Bienvenue sur OC !!!
Ca wan bien, merci ! Je vais essayer de participer au forum dès que j'aurais un peu plus de temps.
Pour le bug, j'arrive à le reproduire : -test des fonctions d'exposé : nickel -lancement de l'appli -"installer" le patch -test des fonctions d'exposé : nickel -"enlever" le patch -plus de fonction "bureau" d'exposé ???
J'utilise Panther 10.3.8, sans modif du systeme ou du dock, si ca peut aider à reproduire chez quelqu'un...
Sinon j'ai testé un truc con pour en etre sûr : j'ai créer une fenêtre qui est "insensible" à exposé et elle disparait bien comme les autres. Vu que ce sont les mêmes API qui sont utilisés par exposé et le dock, je me posais la question...
En ce qui concerne le bug dont tu parles, en étant sous la même version système, je n'arrive pas à le reproduire, tout fonctionne bien chez moi...
@Bru : Tu dois normalement avoir un projet d'essai dans ton OC mail. En compilant le projet, tu vas voir un rect, simulant une fenêtre, faire un schéma d'animation test. Cette anim utilise les trois transformations, et comporte 6 étapes. Je fais mes essais avec CGContext, mais en bas du fichier FlyView.m, tu trouveras la méthode de tracé, avec les transforms utilisées, adaptées aux CGAffineTransform. Celles-ci sont encadrées par un CGSGetWindowTransform() et un CGSSetWindowTransform(). Donc normalement, si tout va bien, les "danses" devraient êtres identiques en simulation et en situation réelle. Si tu as des questions sur le projet, n'hésites pas. J'ai pensé que ce projet test pourrait ensuite être amélioré pour faire un éventuel éditeur de chemins d'animations...mais tout d'abord faut tester ce premier schéma.
Réponses
Voici mon code :
[tt]
  OSStatus retVal;
int windowCount=-1;
  int currentWorkspace=-1;
int i;
NSMutableData *windowList;
  CGSConnection connection=_CGSDefaultConnection();
 Â
  CGSGetWorkspace(connection, ¤tWorkspace);
retVal=CGSGetWorkspaceWindowCount(connection, currentWorkspace, &windowCount);
windowList=[NSMutableData dataWithCapacity:windowCount*sizeof(int)];
retVal=CGSGetWorkspaceWindowList(connection, currentWorkspace, windowCount,
[windowList mutableBytes], &windowCount);
NSLog(@Count:%i,windowCount);
for (i=0;i<windowCount;i++)
{
NSLog(@Fenêtre numéro %i:%i,i,((int*)[windowList mutableBytes]));
}
[/tt]
J'ai aussi essayé avec les fonctions suivantes :
[tt]// Get on-screen window counts and lists.
extern OSStatus CGSGetWindowCount(const CGSConnection cid, CGSConnection targetCID, int* outCount);
extern OSStatus CGSGetWindowList(const CGSConnection cid, CGSConnection targetCID,
 int count, int* list, int* outCount);
// Get on-screen window counts and lists.
extern OSStatus CGSGetOnScreenWindowCount(const CGSConnection cid, CGSConnection targetCID, int* outCount);
extern OSStatus CGSGetOnScreenWindowList(const CGSConnection cid, CGSConnection targetCID,
 int count, int* list, int* outCount);
[/tt]
Déjà je ne comprend pas quelle est leur différence, et ensuite comment régler le paramètre "CGSConnection targetCID". J'ai mis le même que pour "CGSConnection cid", mais ça me donne un nombre incorrect de fenêtres.
C'est en essayant avec CGSGetWorkspaceWindowCount et CGSGetWorkspaceWindowList que j'obtiens pour le moment les meilleurs résultats, seulement c'est un mystère pour obtenir les windowRefs a partir des windowNumbers...???
.
C'est au millieu (The Perturbed Desktop)de la page :
http://www.kernelthread.com/software/ams/
Si y'a quelqu'un qui se sent de suffisament bien parler anglais pour lui demander comment il a fait pour agir à ce point sur les fenêtres...
Regardez ça aussi... http://www.kernelthread.com/software/ams/download/StableWindow.dmg
On en parle ici :
http://www.objective-cocoa.org/forum/index.php?topic=674.0
Je vois que plein de choses sont possibles... MAIS J'Y CONNAIS RIEN !
Là , j'étudie le "code injection" afin de greffer mon programme au dock, ce qui me permet de contrôler les fenêtres de toutes les applis...
Mais la technique du "code injection" est relativement complexe, alors patience...
.
T'es vraiment obligé de passer par le "code injection" afin de prendre le contrôle Bru ?
Quand j'ai vu ça, je me suis dit quelle usine à gaz, est-ce vraiment nécessaire ? ??? Car si oui, ça complique un tantinet les choses, pas facile à comprendre cette technique de "code injection" !
Non, c'est assez simple en fait.
Le but du jeu est de pouvoir exécuter du code dans un thread qui tourne dans la partition de l'appli Dock.app. Ce code aurait donc les mêmes droits que le Dock pour la manipulation des fenêtres (voir ce qu'il peut faire lors de la miniaturisation des fenêtres).
Le programme principal (ou plutôt l'économisateur d'écran) se contenterait d'envoyer des messages à ce thread qui exécuterait les routines CG... permettant de faire des affineTransfrom sur chaque fenêtre visible à l'écran.
Pour le moment, je planche sur la façon d'envoyer ces messages (j'ai plusieurs solutions).
.
Oui j'ai vu qu'il fallait se servir des routines "mach_inject", qui se chargent alors de tout pour injecter le code.
Tu veux donc te servir de ces fameuses AffineTransform...Ca peut être sympa comme effet.
Oui, et pour 2 raisons :
1 - gérer la transformation de la fenêtre me semble plus simple que de créer une photo de la fenêtre puis de gérer les transformations de l'image de cette photo.
2 - ça permet d'avoir des fenêtres à jour en temps réèl (au lieu d'être figé au moment du déclenchement de l'économisateur).
Par contre, je suis une brelle au niveau graphisme, et surtout au sujet des affineTransfrom...
.
"2 - ça permet d'avoir des fenêtres à jour en temps réèl (au lieu d'être figé au moment du déclenchement de l'économisateur)."
J'adooooore !!!!!!
Je te donnerais un coup de main pour les transformations si tu veux. Normalement ça doit fonctionner comme pour la classe NSAffineTransform, mais à l'échelle de la fenêtre.
Alors comment ça va ? Zavez réussi à avancer un peu ? Parce que jusqu'ici, vous sembliez alors de sacrées bonnes pistes !
AAAAA-LORS !!!???
Pour ma part, en ce moment je suis trés occupé à avancer sur un de mes projets, des que j'aurais un peu de temps j'essaierais d'avancer là -dedans, mais c'est pas du gâteau...:crackboom:-
J'ai lutté, j'ai bataillé, mais j'ai vaincu.
Voici une petite appli de démo (ce n'est pas un screen-saver, mais juste une appli normale).
Cette démo ne fait que disparaitre (avec un effet de fondu-transparence) TOUTES les fenêtres présentes à l'écran, puis les fait ré-apparaitre.
L'utilisation est simple : il faut cliquer sur INSTALLER (le patch du dock), puis ensuite appuyer sur TESTER (réalise la démo sur la fenêtre de l'appli) ou TESTER2 pour toutes les fenêtres.
Maintenant, ne reste plus qu'à utiliser les affineTransform à la place de la tranparence pour faire ce que l'on veut des fenêtres. Mais ça, c'est Eddy qui s'y collera.
La démo est assez surprenante : on peut voir que OS X utilise des fenêtres pour un tas de choses...
Note : j'utilise la technique du patch du dock (voir sur SourceForge) pour contrôler les fenêtres. Le patch se présente sous la forme d'un thread supplémentaire dans le process Dock.app. Il ne gène pas, mais si vous voulez le supprimer, relancez le Dock, ou cliquez sur ENLEVER.
.
[Fichier joint supprimé par l'administrateur]
En effet, très surprenant l'effet, les fenêtres qui disparaissent, puis le dock et les icônes....ça ouvre la voie à pas mal de choses.
Pfiou ! Je suis bleufé de chez bleufé !
Et donc, là , en gros... il reste plus qu'à les faire voler en l'air ? Et même les icones vont voler donc dans tous les sens ?
J'A-DORE !
PS : et sous tiger... ça marchera pareil ?
Oui. Dans la démo, j'utilise la fonction de transparence des fenêtres pour contrôler leur disparition/réapparition. Mais je peux aussi utiliser la fonction affineTransform. C'est celle ci qui contrôle la forme de la fenêtre (on peut les déformer). Enfin, je peux aussi utiliser la fonction de déplacement pour les déplacer à l'écran. C'est la combinaison déplacement/deéformation qui va faire danser les fenêtres.
Dans la démo, on peut voir beaucoup de fenêtres qui n'en sont pas (icônes du finder sur le bureau, barre des menus, fond d'écran) : je pense qu'il ne faudra pas les faire danser, mais juste disparaitre... Mais ça on verra après.
Je ne suis pas du tout ni graphiste, ni matheux. L'utilisation des affineTransform me rebute donc, et ça me gave grave de devoir apprendre à les créer, alors que d'autres (Eddy) peuvent le faire pour moi. La prochaine démo (en fonction de nos disponibilités) fera danser les fenêtres.
Je pense que oui. J'utilise des apis (groupes de fonctions) non documentées. Mais ce sont les mêmes qu'Apple utilise pour Exposé (réduction/déplacement des fenêtres), et pour le Dock (effet Genius lors de la miniaturisation).
Ici, nous avons quelques gars qui font partie des beta-testeurs de Tiger. Ils peuvent tester la démo.
.
Ayé ! je recommence à imaginer ce fameux économiseur incroyable qui fait tout simplement voler les fenêtres à l'écran !
Pfiou !
Y'a pas vraiment de projet pour le moment (en fait, ya un projet pour le patch du dock, et l'autre qui est l'appli test-screensaver).
En fait, j'ai implémenté dans le patch du dock ce qu'il faut pour transmettre des structures CGAffineTransform et CGPoint via un appleEvent pour pouvoir utiliser les fonctions CGSMoveWindow et CGSSetWindowTransform. Mais je n'ai pas pu tester, faute de connaissances suffisantes.
Peux tu me donner rapidement quelques structures CGAffineTransform (6 float je crois) qui, enchainées les unes après les autres, feront un effet de danse ?
.
Qui sont les plus forts ? MacGénération, Macbidouille ou Objective-cocoa ?
.
Tu connais ma réponse
Par contre, je viens de m'apperczvoir d'un petit probleme : une fois que toutes les fenêtres ont disparues, il ne reste non pas un fond noir, mais un fond bleu. Ce qui signifie que si on fait voler la fenêtre "bureau", et bien derrière, ce sera bleu... et j'imagine qu'Apple n'a pas prévu de pouvoir placer une couche de noir entre ce truc bleu, et le bureau...
Z'en dites quoi ?
Le temps de faire les tests nécessaires et je t'envoie ça.
Le fond noir peut se bricoler, par exemple, en mettant une fenêtre factice en arrière plan, remplie de noir...enfin c'est à tester
Je trouve l'idée très sympa et j'ai hate de tester la prochaine version !
Je trouve le fond bleu plutot sympa, même si c'etait pas l'idée de départ. Pourquoi pas le mettre en option ?
J'ai eu un bug etrange, apres avoir lancé et arreté, j'avais plus la fonction "Bureau" d'exposé. Sinon tout a marché nickel
Je bidouille un peu cocoa alors je peux peut-etre vous aider dans mon temps libre.
Ce truc est vraiment super.
1- Je n'ai pas eu le bogue signalé par obi
2- Comment se fait-il que les icones du bureau disparraissent ? Ce ne sont pas des fenêtres, je me trompe ?
Encore bravo Bru
Ca wan bien, merci !
Pour le bug, j'arrive à le reproduire :
-test des fonctions d'exposé : nickel
-lancement de l'appli
-"installer" le patch
-test des fonctions d'exposé : nickel
-"enlever" le patch
-plus de fonction "bureau" d'exposé
???
J'utilise Panther 10.3.8, sans modif du systeme ou du dock, si ca peut aider à reproduire chez quelqu'un...
Sinon j'ai testé un truc con pour en etre sûr : j'ai créer une fenêtre qui est "insensible" à exposé et elle disparait bien comme les autres. Vu que ce sont les mêmes API qui sont utilisés par exposé et le dock, je me posais la question...
En ce qui concerne le bug dont tu parles, en étant sous la même version système, je n'arrive pas à le reproduire, tout fonctionne bien chez moi...
@Bru : Tu dois normalement avoir un projet d'essai dans ton OC mail. En compilant le projet, tu vas voir un rect, simulant une fenêtre, faire un schéma d'animation test. Cette anim utilise les trois transformations, et comporte 6 étapes. Je fais mes essais avec CGContext, mais en bas du fichier FlyView.m, tu trouveras la méthode de tracé, avec les transforms utilisées, adaptées aux CGAffineTransform. Celles-ci sont encadrées par un CGSGetWindowTransform() et un CGSSetWindowTransform(). Donc normalement, si tout va bien, les "danses" devraient êtres identiques en simulation et en situation réelle. Si tu as des questions sur le projet, n'hésites pas. J'ai pensé que ce projet test pourrait ensuite être amélioré pour faire un éventuel éditeur de chemins d'animations...mais tout d'abord faut tester ce premier schéma.