On Tue 27.07.2004 at 04:47:53PM +0200, Hans Meine wrote: > On Tuesday 27 July 2004 16:19, Dirk Meyer wrote: > > >> Now I need some ideas for future development: > > >> > > >> o I moved the eventhandling into eventhandler.py. Fine, but now we > > >> have a module eventhandler and most classes have a member function > > >> with the same name. Better ideas? > > > > > > Rewrite all the classes so that they register event handling functions > > > to the main Eventhandler class for different kinds of events. The > > > Evenhandler can thus pass the event to all classes that have registered > > > for that particular event and which have the focus at this time. > Matthieu, did you realize you're contradicting your statement from above: > "There can be only one application that has the focus at a time". ;-) > OK, this is about objects, not applications..
I'm not :) First, when I say "all", I don't mean that all apps should react on this event. If the event is focus-related, then only the app that has the focus will use the event :) Second, focus and event handler must not be confused: an app can still receive events even if it doesn't have the focus (e.g. "redisplay yourselves" or "hide, all of you"). I don't know if it would be useful in Freevo, but in X-window there are such "broadcast events", iirc. Besides, if we have two apps running at the same time (e.g. mplayer for the music and the image viewer, or mplayer for video and the menu displaing inside mplayer), both app must have an eventhandler, but only one (the image viewer) has the focus. My idea was that when the app is instantiated, it registers its event handler to the Eventhandler object, and will not unregister it until the app is destroyed. The "instantiation" might be when a plugin is loaded. Thus, starting e.g. mplayer could be done by posting an event about playing a given movie (the event must have parameters of course, maybe even a complex structure, it is not just a string or a number), which is received by the eventhandler of the mplayer plugin. This one in turn will acquire the focus, spawn a thread and run the mplayer program. If an event is irrelevant (e.g. run mplayer while mplayer is already running), it is ignored. When the user stops playing the movie (such an event comes from the keyboard or the remote control and is received by mplayer), the mplayer plugin stops the mplayer program, closes the thread, and posts an event indicating that the movie stopped. This event in turn is received by the menu which acquires the focus and redisplays itself. So even the menu could be a plugin, with its own eventhandler, the remote control can be a plugin (rather posting events that receiving events, actually). This could be one architecture of freevo: Main loop: waits on filehandlers with the "select" system call. Each plugin dealing with sockets/pipes registers a data handler to the main loop, and when data is available on one of those (e.g. select wakes up), the data handler of the plugin is called in order to process the data. Such plugins can be: - remote control (reading from the Lirc socket) - mplayer (reading from mplayer's stdout/stderr) - xine/tvtime? How does freevo communicate with them? - cdrecord (if it is not inside its own server) - keyboard (for this one I don't know how to make it work) Every minute/second/tick, select could return on timeout and tell the clock of the idlebar to update itself, or tell other idlebar plugins to update themselves if necessary), tell the check_media plugin to check if there is a disk in the removable disk drives, and do whatever other task must be done at a regular time interval. Eventhandler: holds the event queue, provides a "post event" function and dispatches the new events to whatever plugins could be interested in the events. Remote control, keyboard: they have one data handler that receives key presses from the user, and then post events to the event queue. Other plugins: they have one event handler (that the Eventhandler calls to pass an event to the plugin) and one data handler (that the main loop calls when data is available for that plugin) This architecture also removes the "sleep" from the main loop, which was much discussed about some time ago. > > > The "eventhandler" method for each class can be reuesd almost > > > as-is (just remove the part at the end that passes the event to > > > other eventhandlers, since it is the Eventhandler class that will > > > take care of that). > > > > I had the same idea, but I'm not sure how this works with passing > > event to parents and such things. Should a event go to more than one > > item? That won't be done in the next weeks. > I think so. I would prefer windows having parents again, coordinates being > relative again and events to be propagated. That would also allow for global > event handling. This is a mystery for me: in what case should an event be passed to the parent of an app? Matthieu -- (~._.~) Matthieu Weber - Universit� de Jyv�skyl� (~._.~) ( ? ) email : [EMAIL PROTECTED] ( ? ) ()- -() public key id : 452AE0AD ()- -() (_)-(_) "Humor ist, wenn man trotzdem lacht (Germain Muller)" (_)-(_) ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
