[Cocoa]Problème d'évènements.

[Céroce]

Tout sera beaucoup plus clair quand tu auras lu le bouquin.
Par exemple, pourquoi pour intercepter les événements, on hérite de NSView et pas de NSWindow. Tu verras que les autorelease pools ne sont pas des ramasse-miettes (la gestion mémoire est expliquée au début du livre).

Tu verras aussi à quel point Swing est inférieur à Cocoa, bien qu'il soit plus accessible.

 

[Askerat]

Et si on hérite de NSView, comment on met en pratique notre sous classe ? ^^ ( le livre ne sera probablement pas arrivé avant vendredi ).

edit: Peut-on voir les notifications de Cocoa comme les signaux / flots de Qt ? L'utilitée est un peu identique non ?

 

[tatouille]

[[self myvar] message];
[self.myvar message];

obj->member
my struct {

}

ici tu pointes sur les membres des structs
c'est comme une var member en C++ tu ne pointes pas dessus

 

[Céroce]

Et si on hérite de NSView, comment on met en pratique notre sous classe ? ^^ ( le livre ne sera probablement pas arrivé avant vendredi ).

Il va falloir être patient, ça ne s'explique malheureusement pas sur un coin de forum.
En pratique, on supplante bien la méthode -[NSView keyDown], mais tu as une notion de "focus" — c'est à dire la vue actuelle qui reçoit les événements — qui est subtile.

Je ne connais pas Qt , mais j'imagine que ça correspond plutôt au système des targets/actions.
Les notifications s'utilisent plutôt dans des cas bien particuliers, par exemple, obliger l'utilisateur à ne saisir que des caractères minuscules dans un champ de texte. Ce n'est qu'un exemple.

 

[tatouille]

Il va falloir être patient, ça ne s'explique malheureusement pas sur un coin de forum.
En pratique, on supplante bien la méthode -[NSView keyDown], mais tu as une notion de "focus" — c'est à dire la vue actuelle qui reçoit les événements — qui est subtile.

Je ne connais pas Qt , mais j'imagine que ça correspond plutôt au système des targets/actions.
Les notifications s'utilisent plutôt dans des cas bien particuliers, par exemple, obliger l'utilisateur à ne saisir que des caractères minuscules dans un champ de texte. Ce n'est qu'un exemple.

je ne suis pas d'accord les notifications s'utilisent dans tout key value change model
un event envoie des notifications pour avertir tout object dependant de lui que quelque choses vient de se passer, swing n'est que base sur ca comme tous les framework ou on a besoin de communiquer entre differents objects

en cocoa il faut en faire un usage extensif surtout dans des applis multi-threaded c'est la solution geniale
pour pas se taper des pointeurs sur parent.parent.parent et de plus ca permet de communiquer entre des threads
etranges, par ailleurs si tu trifouilles cocoa a l'interieur tu peux voir que les inges d'Apple ne se privent pas
si tu colles iterate le spool du defaultcenter tu pourras etre etonne de la queue

pour un exemple plus large

http://www.freedesktop.org/wiki/Software/dbus

-(void) keyDown:(NSEvent*)event{
    if(self->m_displayMem == nil)
        self->m_displayMem = [[Memory alloc] init];
    if(self->m_outMem == nil)
        self->m_outMem = [[Memory alloc] init];
    if(self->m_proc == nil)
        self->m_proc = [[Processor alloc] init];
    
    NSString *tmp = [event characters];
    [tmp retain];
    if([tmp isEqualToString:@"0"])
        [self didNumberButtonPushed:tmp];
    else if([tmp isEqualToString:@"1"])
        [self didNumberButtonPushed:tmp];
    else if([tmp isEqualToString:@"2"])
        [self didNumberButtonPushed:tmp];
    else if([tmp isEqualToString:@"3"])
        [self didNumberButtonPushed:tmp];
    else if([tmp isEqualToString:@"4"])
        [self didNumberButtonPushed:tmp];
    else if([tmp isEqualToString:@"5"])
        [self didNumberButtonPushed:tmp];
    else if([tmp isEqualToString:@"6"])
        [self didNumberButtonPushed:tmp];
    else if([tmp isEqualToString:@"7"])
        [self didNumberButtonPushed:tmp];
    else if([tmp isEqualToString:@"8"])
        [self didNumberButtonPushed:tmp];
    else if([tmp isEqualToString:@"9"])
        [self didNumberButtonPushed:tmp];
    else if([tmp isEqualToString:@"+"])
        [self didOperatorButtonPushed:tmp];
    else if([tmp isEqualToString:@"-"])
        [self didOperatorButtonPushed:tmp];
    else if([tmp isEqualToString:@"/"])
        [self didOperatorButtonPushed:tmp];
    else if([tmp isEqualToString:@"*"])
        [self didOperatorButtonPushed:tmp];
    else if([tmp isEqualToString:@"="])
        [self didEqualButtonPushed];
}

ici ca me semble necessaire...

 

[Askerat]

Je suis sur le point de finaliser une refonte totale de cette petite calculatrice basique. Dans celle ci j'ai ( hormis les classes Processor et Memory ) une classe Controller et une sous classe de NSWindow, dans les keyDown, j'envoie des notifications à mon controller, qui ensuite sait quoi faire. Donc au final, un clique ou un keyDown finit au même message, ce qui parait plutot cohérent, si jamais vous vous sentez l'âme de relire ça, j'ai fait un peu plus attention à la mémoire, notament sur mes getters/setters.

 

[Céroce]

je ne suis pas d'accord les notifications s'utilisent dans tout key value change model

Tu donnes un sens très large à "Notification". Évidemment, les systèmes de Target/actions et Key-Value observing notifient également l'observateur d'un changement.

Mais dans la terminologie Cocoa, les notifications correspondent à quelque chose de précis, qui dépend de la classe NSNotification. Je pense que c'est ce à quoi Askerat faisait référence.

 

[Askerat]

Oui tout à fait. Et, encore une question, dans la documentation, à quel endroit peut on savoir quel constructeur est appellé par le NIB ? Car là j'ai le même problème que j'avais pour le NSWindow, j'ai sous classé NSOpenGLView, pour gérer l'initialisation etc, j'ai redéfinit le constructeur, mais celui ci n'est jamais visité, donc ça doit être un constructeur parent de NSOpenGLView qui est appellé j'imagine. Mais dans la documentation, à aucun endroit est indiqué quel constructeur est appellé.

Autre question, de manière généralle dans ce cas ci, vaut mieux utiliser awakeFromNib, ou bien le constructeur ( message init quoi ) pour initialiser notre instance ? Le constructeur ça me parait plus propre, et plus logique, je ne vois pas awakeFromNib pour cet usage ci.

 

[tatouille]

pour une
initWithNibName

pour une window

initWithWindowNibName

mais tu ne devrais/dois pas les surcharger quand tu choisis d'utiliser un xib
c'est pour reduire le code par pour merdifier
utilises les delegates

- (void)windowDidLoad
- (void)awakeFromNib

c'est fou ce que t'es curieux

http://code.google.com/p/archimade/source/browse/trunk/Classes/ArchimadeProgressWindowController.m

 

[Askerat]

Je tente d'apprendre à utiliser le framework donc forcément, je me pose des questions ^^.

 

[Céroce]

Mais dans la documentation, à aucun endroit est indiqué quel constructeur est appellé.

La méthode d'init appelée est celle pour laquelle la doc dit "This method is the designated initializer for the [classe] class". Il faut le savoir.
Donc, a priori, ce serait plutôt -[NSView initWithFrame:] qui faudrait surcharger.
La doc dit que spécifier le pixelFormat se fait dans les réglages de la NSOpenGLView sous Interface Builder.