›

Suite à  "AEv-Utility"

tabliertablier Membre
octobre 2009 modifié dans API AppKit #1
@schlum, suite au post "AEv-Utility"

Je pense effectivement que le Finder, même seul en course, reçoit les évenements par l'intermédiaire d'Apple Events.
Voici quelques extraits de la doc qui m'amènent à  penser cela:
(Xcode 3.1.3)
Apple Events Programming Guide
Introduction to  Apple Events Programming Guide
.... An Apple event is a type of interprocess message that can specify complex operations and data. Apple events allow you to gather all the data necessary to accomplish a high level task into a single package that can be passed across process boundaries, evaluated, and returned with results. The Mac OS uses Apple events to communicate with applications.  ....

(Xcode 3.1.3)
Apple Events Programming Guide
About AppleEvents
..... Note: ..... Mac OS X offers other mechanisms, including distributed objects, notifications, sockets, ports, streams, shared memory, and Mach messaging. These mechanisms are described in “Interprocess Communication” in System-Level Technologies in Mac OS X Technology Overview.

Maheureusement, le paragraphe cité est absent de la doc d'Xcode 3.1.3! Je l'avais résumé ICI. il existe dans la doc d'Xcode 2.5. Extrait:
(Xcode 2.5)
System-Level Technologies
Interprocess Communication
Apple Events
.... Apple events are the primary technology used for scripting and interapplication communication in Mac OS X. ......
(Xcode 3.1.3)
I/O kit fundamental
Before you begin.
Also, device drivers are not the same thing as applications because, being kernel-resident, they must abide by more restrictive rules. Knowledge of kernel programming is therefore very useful.
et enfin:
(Xcode 3.1.3)
NSEvent Class reference
Overview
An NSEvent object, or simply an event, contains information about an input action such as a mouse click or a key down. The Application Kit associates each such user action with a window, reporting the event to the application that created the window. The NSEvent object contains pertinent information about each event, such as where the cursor was located or which character was typed. As the application receives events, it temporarily places them in a buffer called the event queue. When the application is ready to process an event, it takes one from the queue.

Pour résumer:
Les drivers font parti du noyau de Mac OS. Mac OS est construit par couche! Les applications (normalement) ne s'adressent pas directement au noyau. Mac OS s'adresse aux applications par l'intermédiaire d'Events envoyés à  l'Application Kit qui va créer une boucle d'évènements pour l'application. Comme il est dit que les Apple Events sont la première technologie de communication entre processus, je pense que l'Application Kit reçoit des Apple Events. Le Finder est une application il rentre dans le cadre général des applications.
Je peux avoir tout faux. Et si quelqu'un a des lumières sur ce sujet, qu'il nous éclaire! merci d'avance.

Réponses

  • schlumschlum Membre
    20:00 modifié #2
    Un driver ouvre des fichiers spéciaux (dans /dev) et pour s'y " connecter ", les applications les ouvrent et communiquent avec le driver par ce biais.
    Je doute fortement que ça passe par des Apple Events  ;)
    D'après moi, à  chaque passage de la runloop, l'appKit demande directement aux drivers s'il y a un événement à  transmettre (au driver clavier et au driver souris), et crée le NSEvent à  ce moment. Je ne vois pas quel serait l'intérêt d'une couche supplémentaire à  ce niveau  ???
  • tabliertablier Membre
    20:00 modifié #3
    Eh bien, je veux bien te croire, même si ce n'est pas ce que j'ai compris en lisant la doc.
    Ou puis-je trouvé l'explication sur la manière dont un évènement est transmis du clavier à  l'application par exemple? Quelle est la doc qui explique cela?
  • schlumschlum Membre
    20:00 modifié #4
    Je ne sais pas s'il y a une doc qui explique la gestion bas-niveau des événements...

    par contre, la doc de NSEvent ne parle pas d'AE.

    Overview

    An NSEvent object, or simply an event, contains information about an input action such as a mouse click or a key down. The Application Kit associates each such user action with a window, reporting the event to the application that created the window. The NSEvent object contains pertinent information about each event, such as where the cursor was located or which character was typed. As the application receives events, it temporarily places them in a buffer called the event queue. When the application is ready to process an event, it takes one from the queue.

    Beginning with Mac OS X version 10.4, NSEvent objects can represent tablet-pointing and tablet-proximity events. A tablet-proximity event is generated when a pointing device enters or leaves proximity of its tablet; such event objects have a type of NSTypeProximity or a mouse subtype of NSTabletProximityEventSubtype. A tablet-pointing event is generated when a pointing device changes state, such as location, pressure, or tilt; such event objects have a type of NSTypePoint or a mouse subtype of NSTabletPointEventSubtype. The Application Kit reports all pure tablet events to responder objects through the NSResponder methods tabletPoint: and tabletProximity:. Mouse events can also contain tablet data (as event subtypes), so you can handle these events by overriding the NSResponder methods mouseDown:, mouseDragged:, and mouseUp:.


    Par ailleurs, quand on met un breakpoint sur la réception d'un NSEvent, on voit que ça ne passe pas par le NSAppleEventManager.
Connectez-vous ou Inscrivez-vous pour répondre.