Wie wird ein MouseOut-Event implementiert?
-
Hi,
ich frage mich, wie ein MouseOut-Event implementiert wird. Zum Beispiel gibt es ja in jedem Desktop (KDE/Gnome/Windows) z. B. bei Fenstern dieses Event, das aufgerufen wird, wenn die Maus aus einem bestimmten Control "geht".
Wie könnte so etwas implementiert sein? Bei einem MouseIn müsste man ja nur prüfen, ob die Mausposition sich innerhalb eines Bereichs des Fensters befindet, das von nichts anderem überlappt wird. Ist es dann bei MouseOut genau anders rum? Man prüft also während der Mausbewegung, ob sich die Maus noch in einem sichtbaren Bereich des Fensters befindet? Allerdings würde das nicht genügen, weil man zum Beispiel auch darauf reagieren muss, dass sich einfach ein neues Fenster öffnet, ohne dass ich die Maus bewege, und dieses dann den Bereich unter der Maus verdeckt. Das wäre ja auch ein MouseOut, weil die Maus nicht mehr im ursprünglichen Fenster ist. Das würde bedeuten, dass man jedes Event, das dafür sorgen könnte, dass die Maus nicht mehr im betreffenden Fenster ist, abfragen müsste, was einer Blacklist entspräche.
Gibt es eine bessere Möglichkeit? Mich interessiert bloß der technische Hintergrund, ich habe nicht vor, so etwas zu implementieren.
-
Ohne zu wissen, wie es wirklich gemacht wird, ist es doch sehr einfach, auf folgende Methode zu kommen: Wenn das aktuelle Fenster ein anderes ist als das vorherige, dann wird das vorherige benachrichtigt. Die Prüfung findet in regelmäßigen Abständen statt, die für einen Menschen flüssig aussehen, aber für einen Computer laaaaaang auseinander liegen.
-
SeppJ schrieb:
Ohne zu wissen, wie es wirklich gemacht wird, ist es doch sehr einfach, auf folgende Methode zu kommen: Wenn das aktuelle Fenster ein anderes ist als das vorherige, dann wird das vorherige benachrichtigt. Die Prüfung findet in regelmäßigen Abständen statt, die für einen Menschen flüssig aussehen, aber für einen Computer laaaaaang auseinander liegen.
Meinste wirklich, dass das per Polling gemacht wird?
-
Einfach wenn ein MouseIn generiert wird, ein MouseOut zum vorherigen schicken?!
Wenn Fenster erstellt wird, kriegt es ja auch direkt ein MouseIn...
-
Der Window-Manager bestimmt bei jeder Mausbewegung welches Fenster gerade unter der Maus ist. Zumindest mal das top level Window.
(Möglicherweise auch runter bis zu den Controls, weiss ich aber nicht, müsste ich raten.)
Und zwar weil er das sowieso muss, weil er nämlich üblicherweise nur das Fenster benachrichtigt welches gerade unter der Maus "ist".Und wenn er schlau ist, und wenn er das möchte, kann der Window-Manager diesen Check auch bei jeder Änderung an irgend einem Fenster machen. Dann könnte er die von dir erwähnten "neues Fenster überdeckt aktuelles" Fall korrekt behandeln. Wobei ich eher erwarten würde dass dieser Fall nicht korrekt behandelt wird. Zumindest deckt sich das mit meinen Erfahrungen zu ähnlichen Dingen.
z.B. "checken" viele Programme nicht wenn man ein Element mit dem Keyboard unter dem Cursor wegscrollt ohne die Maus dabei zu bewegen. Die popup help/balloon help zu dem Element wird dann weiterhin angezeigt. So lange bis man die Maus bewegt. Oder ein Programm dafür sorgt dass ein "null-Pixel Mousemove" gesendet wird.
(Task Manager unter Windows 7 macht das z.B. jede Sekunde wenn man die "Processes" Liste offen hat -- keine Ahnung warum.)
-
Meinungserfrager schrieb:
Meinste wirklich, dass das per Polling gemacht wird?
Nein. Ich bin mir sogar ziemlich sicher, dass nicht. Aber wenn der TE sich gar nicht vorstellen kann, wie so etwas überhaupt gehen könnte, dann fängt man mit der einfachsten Erklärung an.
-
Nathan schrieb:
Einfach wenn ein MouseIn generiert wird, ein MouseOut zum vorherigen schicken?!
Wenn Fenster erstellt wird, kriegt es ja auch direkt ein MouseIn...Ist das denn in jedem Fall zuverlässig? Zugegeben, mir fällt gerade kein Fall ein, der bei einem Desktop auftritt, bei dem diese Logik nicht ausreichen würde. Aber mir erscheint das so, als wäre es nicht genug.
hustbaer schrieb:
...
Mir fehlt bei deiner Beschreibung der Teil, der beschreibt, wann dann ein MouseOut zustande kommt. Könntest du das bitte noch erklären?
SeppJ schrieb:
Meinungserfrager schrieb:
Meinste wirklich, dass das per Polling gemacht wird?
Nein. Ich bin mir sogar ziemlich sicher, dass nicht. Aber wenn der TE sich gar nicht vorstellen kann, wie so etwas überhaupt gehen könnte, dann fängt man mit der einfachsten Erklärung an.
Der TE, ich, wollte gerne wissen, wie es in der Realität gemacht wird. Dass es mit Polling, auf eine unzuverlässige Art und Weise, geht, ist mir schon klar. Aber wie du schon sagst: So wird es ja kein vernünftiger Entwickler machen.
-
Genauwissenwoller schrieb:
Ist das denn in jedem Fall zuverlässig? Zugegeben, mir fällt gerade kein Fall ein, der bei einem Desktop auftritt, bei dem diese Logik nicht ausreichen würde. Aber mir erscheint das so, als wäre es nicht genug.
Wann soll es denn nicht zuverlässig sein? Falls man in solchen Fällen noch nachpatchen muss, kann man das ja machen. Zb. ein Extra-Check beim Workspace-Wechsel oä. (Wobei selbst da Mouse-Ins auslösen würden.)
Dass es mit Polling, auf eine unzuverlässige Art und Weise, geht, ist mir schon klar.
Polling ist keineswegs unzuverlässig; viel zuverlässiger geht es wohl kaum wenn man hinreichend oft pollt. Nur performancetechnisch ist das natürlich nicht optimal.
-
Genauwissenwoller schrieb:
hustbaer schrieb:
...
Mir fehlt bei deiner Beschreibung der Teil, der beschreibt, wann dann ein MouseOut zustande kommt. Könntest du das bitte noch erklären?
Na wenn der Window-Manager merkt dass jetzt ein anderes Fenster unter der Maus liegt als beim letzten mal wo er nachgesehen hat.
Dann schickt er an das alte Fenster nen "MouseOut".
-
Das BS wird halt bei jeder Mausbewegung prüfen, wo sich diese grad befindet und die entsprechenden Benachrichtigungen an die Applikation schicken. Von einen Polling kann da keine Rede sein, eher von Interupts.
Bei Windows kommt es übrigens auch vor, das ein "Maus Leave" event nicht ausgelöst wird, wenn man die Maus zu schnell aus dem App- Fenster rausbewegt.
