D'ailleurs à ce propos, tu ajoutes toujours une nouvelle vue dans ta fenêtre, mais si tu ne mets jamais plus d'un objet dans ta fenêtre tu peux toujours utiliser la content view.
Oui, j'ai dû d'ailleurs le faire sur la contentView dans les premières pages du site. Sur les exemples de la doc que j'ai vu, c'est fait avec un étage complémentaire, alors je fais pareil : peut-être plus de souplesse pour une évolution ultérieure.
Oui, j'ai dû d'ailleurs le faire sur la contentView dans les premières pages du site. Sur les exemples de la doc que j'ai vu, c'est fait avec un étage complémentaire, alors je fais pareil : peut-être plus de souplesse pour une évolution ultérieure.
C'est parce qu'une fenêtre ne peut contenir qu'une seule vue, alors qu'une vue peut en contenir plusieurs.
Non, moi je te suggère de simplement t'ajouter à la suite de la fenêtre et de gérer tous les événements que tu veux à ce niveau :
Oui, ton explication était très claire , mais il me semblait que la fenêtre n'était pas le dernier responder de la chaà®ne : par exemple NSApplication est lui aussi un NSResponder.
Mais NSResponder * windowNextResponder=[[[self view] window] nextResponder]; NSLog(@%@",windowNextResponder); fournit bien (null)
Oui, ton explication était très claire , mais il me semblait que la fenêtre n'était pas le dernier responder de la chaà®ne : par exemple NSApplication est lui aussi un NSResponder.
Mais NSResponder * windowNextResponder=[[[self view] window] nextResponder]; NSLog(@%@",windowNextResponder); fournit bien (null)
Non, la fenêtre n'est pas le dernier responder, mais la méthode -setNextResponder: de NSWindow, contrairement à celle de NSView, mets son ancien ancien next responder comme next responder de son futur responder. Donc la chaà®ne ne s'arrête pas...
Oui en effet j'avais pas essayé ça :crackboom:- Je viens de relire la doc... En fait la chaà®ne de répondeur s'arrête bien à la fenêtre active... C'est pour ça qu'il n'est pas dangereux d'ajouter un répondeur à la suite d'une fenêtre (pratique préférable). En fait, après la fenêtre et uniquement dans le cas des actions messages, s'il n'y a pas de responder, le prochain appelé c'est le délégué de la fenêtre, ensuite c'est NSApp et ensuite c'est le délégué de NSApp et après la chaà®ne est définitivement rompue. Dans le cas des événements, la chaà®ne s'arrête définitivement après la fenêtre, sauf si on ajoute des responder après.
Donc à mon avis, fais simple, tu ajoutes ton répondeur à la fenêtre directement, tu récupéreras tous les événements qui ne sont pas gérés avant, donc tu pourras implémenter uniquement ceux que tu veux, et pour les événements de souris qui ont plusieurs solutions (hors de la vue ou dans la vue) tu utilises la méthode que je t'ai montré juste au-dessus... Soit le point et dans le rectangle soit tu laisses l'implémentation par défaut bosser. C'est la technique la plus propre.
D'ailleurs, je vais me corriger (et répondre à un de tes messages par la même occasion), -setNextResponder: de NSWindow ne fait rien de plus que celle de NSView, et ce n'est donc pas un "insertResponderAbove", ça insert bien à la suite... Mais les implémentations de NSResponder doivent être écrites comme ça je pense :
Ouaip, tu peux aussi créer des modèles de cibles ou de fichiers, et ajouter des macros pour la complétion du code. Tout se trouve dans Developer/Library/Xcode/ J'ai créé un sujet pour montrer comment créer un modèle de projet.
essai pour fluidifier : ajuster au mieux la taille de l'image (resize sur une CGImage) C'est mieux sur le mouvement dans une fenêtre de petite taille, mais cela ne résout pas le problème des fenêtres de grande taille.
Pour les fenêtres de grande taille, je n'ai pour l'instant que l'abandon de l'ombrage pour fluidifier, et là c'est bien.
Un grand merci à¡ toi Philippe49 pour ces pages sur CoreAnimation. C'est très instructif. A quand un regroupement sous forme de PDF ? Pour moi ce serait l'idéal.
Suis en train de me plonger dans CoreAnimation (pour iPhone) donc j'en profite pour lire tes tutos (sympas, merc ), pour voir si j'ai compris la même chose que toi suite à ma lecture de la doc CA et mes tests ^^ et surtout capter les quelques principes qui restent obscures.
Je viens de voir dans la page CATextLayer que tu avais rajouté une macro pour écrire les infos d'un rectangle. Pour info, il existe déjà tout plein de macros pour ça fournies par Apple, en particulier les NSStringFromXXX.
NSStringFromRect(rect) va ainsi te composer une NSString du genre @{{x,y},{w,h}} avec les bonnes valeurs de ton rectangle, qu'il suffit d'utiliser dans un NSLog ou un fprintf par exemple ensuite.
Je viens de voir dans la page CATextLayer que tu avais rajouté une macro pour écrire les infos d'un rectangle. Pour info, il existe déjà tout plein de macros pour ça fournies par Apple, en particulier les NSStringFromXXX.
Oui, j'ai vu depuis, mais ils empêche un format lisible %.2f alors je reviens au copier-coller de cette macro et de quelques autres du même tonneau qui ma foi est fort utile. Merci.
Tu auras sûrement des améliorations à me faire faire sur ces pages, Psycho m'avait suivi sur les premières pages, mais les autres ont reçues peu de commentaires. Je les ai faites d'un seul jet en découvrant au fur et à mesure, cela mérite sans doute reliftage et compléments ...
Mes contributions si elles arrivent un jour seront certainement sous la forme de projets pour iPhone et non pour OSX... remarque c'est pas plus mal, ça fournirait un autre point de vue.
Sinon ta macro t'aurais qd mm pu l'appeller PRStringFromRect du coup ^^ ou PRLogRect si elle inclus le [tt]fprintf(stderr,...)[/tt] ^^:)
Réponses
Oui, j'ai dû d'ailleurs le faire sur la contentView dans les premières pages du site.
Sur les exemples de la doc que j'ai vu, c'est fait avec un étage complémentaire, alors je fais pareil : peut-être plus de souplesse pour une évolution ultérieure.
Non, moi je te suggère de simplement t'ajouter à la suite de la fenêtre et de gérer tous les événements que tu veux à ce niveau :
C'est à mon avis plus simple et moins risqué, d'ailleurs tu peux utiliser une méthode en plus pour pouvoir le faire dans différentes méthodes :
C'est parce qu'une fenêtre ne peut contenir qu'une seule vue, alors qu'une vue peut en contenir plusieurs.
Oui, ton explication était très claire , mais il me semblait que la fenêtre n'était pas le dernier responder de la chaà®ne : par exemple NSApplication est lui aussi un NSResponder.
Mais
NSResponder * windowNextResponder=[[[self view] window] nextResponder];
NSLog(@%@",windowNextResponder);
fournit bien (null)
Oui, rajouter des boutons, d'autres vues, ...
Non, la fenêtre n'est pas le dernier responder, mais la méthode -setNextResponder: de NSWindow, contrairement à celle de NSView, mets son ancien ancien next responder comme next responder de son futur responder. Donc la chaà®ne ne s'arrête pas...
Mets ça comme code dans ton -awakeFromNib :
Tu verras au démarrage de l'application qu'un YES s'affichera.
et alors on ferait
- (void)mouseDown:(NSEvent *)theEvent
{
NSPoint location = [theEvent locationInWindow];
if(NSPointInRect(location, [[self view] frame]))
{
// code si on clique dans la vue
[glow=red,2,300] } else {
[[self nextResponder] mouseDown:theEvent];
} [/glow]
}
fournit (null) dans les deux cas.
La fenêtre semble bien être en bout de chaà®ne.
Euh, non je ne ferais pas ça comme méthode, il faudrait plutôt faire ça :
Pour utilise l'implémentation par défaut si on ne gère pas l'événement.
Oui en effet j'avais pas essayé ça
Je viens de relire la doc... En fait la chaà®ne de répondeur s'arrête bien à la fenêtre active... C'est pour ça qu'il n'est pas dangereux d'ajouter un répondeur à la suite d'une fenêtre (pratique préférable).
En fait, après la fenêtre et uniquement dans le cas des actions messages, s'il n'y a pas de responder, le prochain appelé c'est le délégué de la fenêtre, ensuite c'est NSApp et ensuite c'est le délégué de NSApp et après la chaà®ne est définitivement rompue.
Dans le cas des événements, la chaà®ne s'arrête définitivement après la fenêtre, sauf si on ajoute des responder après.
Donc à mon avis, fais simple, tu ajoutes ton répondeur à la fenêtre directement, tu récupéreras tous les événements qui ne sont pas gérés avant, donc tu pourras implémenter uniquement ceux que tu veux, et pour les événements de souris qui ont plusieurs solutions (hors de la vue ou dans la vue) tu utilises la méthode que je t'ai montré juste au-dessus... Soit le point et dans le rectangle soit tu laisses l'implémentation par défaut bosser. C'est la technique la plus propre.
D'ailleurs, je vais me corriger (et répondre à un de tes messages par la même occasion), -setNextResponder: de NSWindow ne fait rien de plus que celle de NSView, et ce n'est donc pas un "insertResponderAbove", ça insert bien à la suite...
Mais les implémentations de NSResponder doivent être écrites comme ça je pense :
Quelques approches Core Graphics.
Cela s'anime (enfin)
On crée son projet que l'on copie dans le répertoire des templates de XCode ?
Tout se trouve dans Developer/Library/Xcode/
J'ai créé un sujet pour montrer comment créer un modèle de projet.
Ceci dit, la fluidité n'est pas au rendez-vous, surtout quand on augmente la taille de la fenêtre.
Le problème de fluidité pour des grandes fenêtres n'est pas résolu.
essai pour fluidifier : ajuster au mieux la taille de l'image (resize sur une CGImage)
C'est mieux sur le mouvement dans une fenêtre de petite taille, mais cela ne résout pas le problème des fenêtres de grande taille.
Pour les fenêtres de grande taille, je n'ai pour l'instant que l'abandon de l'ombrage pour fluidifier, et là c'est bien.
Animation d'un filtre CIPerspectiveTile.
Plein écran et mouseDown
mouseDragged sur un layer
Quelques Filtres de transition : barsSwipeTransition, RippleTransition, pageCurlTransition, ModTransition
A quand un regroupement sous forme de PDF ? Pour moi ce serait l'idéal.
Par contre quand le site sera fini, je mettrais un site.zip téléchargeable en page d'accueil.
Suis en train de me plonger dans CoreAnimation (pour iPhone) donc j'en profite pour lire tes tutos (sympas, merc
Je viens de voir dans la page CATextLayer que tu avais rajouté une macro pour écrire les infos d'un rectangle. Pour info, il existe déjà tout plein de macros pour ça fournies par Apple, en particulier les NSStringFromXXX.
NSStringFromRect(rect) va ainsi te composer une NSString du genre @{{x,y},{w,h}} avec les bonnes valeurs de ton rectangle, qu'il suffit d'utiliser dans un NSLog ou un fprintf par exemple ensuite.
Oui, j'ai vu depuis, mais ils empêche un format lisible %.2f alors je reviens au copier-coller de cette macro et de quelques autres du même tonneau qui ma foi est fort utile. Merci.
Tu auras sûrement des améliorations à me faire faire sur ces pages, Psycho m'avait suivi sur les premières pages, mais les autres ont reçues peu de commentaires. Je les ai faites d'un seul jet en découvrant au fur et à mesure, cela mérite sans doute reliftage et compléments ...
Sinon ta macro t'aurais qd mm pu l'appeller PRStringFromRect du coup ^^ ou PRLogRect si elle inclus le [tt]fprintf(stderr,...)[/tt] ^^:)