On Tuesday 27 July 2004 16:19, Dirk Meyer wrote:
> I'm open the better ideas. What it does: eventhandler.append(self)
> adds self to the eventhandler list, setting the focus to self. If you
> remove self again, the focus will go to the app above.
I think this is fine, maybe "push" and "pop" would be suitable names, since
this is some kind of stacking/layering.
> >> This brings up the first questions: when we start the image viewer,
> >> the idlebar should hide itself. How does the bar know that? When
I think of this as the classical windowed vs. _fullscreen_ mode. Just let the
app set some osd mode flag to "fullscreen", post a mode-changed event and let
the plugin hide because of that.
> >> mplayer video starts, also hide, for audio, don't hide. When mplayer
> >> starts and the screen switches from sdl to bmovl, how does the osd
> >> plugin know, that his text needs to be redrawn on mplayer?
> >
> > [...]
>
> That would be an idea. On every screen (backend) change, send an
> event.
I would also propose that.
> >> Brainstorming: How does a plugin know
> >>
> >> o were it should draw itself? This is plugin specific and can be coded
> >> inside the plugin. E.g. idlebar: menu / audio, tiny_osd: everytime.
> >
> > It could be also in the main config (i.e. if the user prefers to have
> > the idlebar at the bottom of the screen).
>
> OK
However, this would still be in the plugin, so your original idea "coded
inside the plugin" would still be right - the plugin would obviously manage
that configuration then.
> >> o if drawing is possible? It is possible to draw on the screen and on
> >> mplayer. But not on xine or tvtime. Idea would be to switch the
> >> current screen to None when not possible, else use the screen we
> >> have.
Exactly. Again, the plugin would be told with an event when the screen
changes to None / back.
The only advantage of your current approach of an intermediate layer is to
prevent applications from having to do a lot of decisions about whether to
display something (right?). Since I can't see a disadvantage, this seems
even better then.
> >> o what is the screen showing? Sounds simple, but when the idlebar
> >> should hide itself on viewing an image, it must get notified
> >> _before_ the next screen draw takes place. When the viewer stops, it
> >> must know that the menu is back and it should draw itself again. We
> >> could interface the eventhandler context, but when it switches to an
> >> input box, is it a box on a menu or on mplayer/image?
> >
> > The virtual display could know all this. It could contain a stack of all
> > displayed elements, the one on the top being the one currently
> > displayed. If there are overlapping elements, the visible parts of the
> > underlying ones should be visible (like overlapping windows). This way,
> > the idlebar could be on top of the main menu. When mplayer starts, its
> > window goes on top of all this, and hides everything. When the user
> > wants to display the idlebar over the movie, the idlebar plugin puts
> > itself on the top of the stack, and displays itself over the movie in
> > mplayer.
>
> No. This makes it much too complicated. Mplayer as object inside the
> virtual screen...no, better avoid this. But still, it doesn't solve
> the problem, that the idlebar needs to know' something is above it and
> needs to change the position.
What do you mean with "above it"? In terms of mplayer, I would think more of
the abovementioned fullscreen mode, which just indicates that the user wants
to remove all non-vital information from screen in order to maximize the
space for some image/video/game display. But that's just a point of view, of
course (hidden/away vs. hidden/below).
> >> 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..
> > 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.
> > Calling the container's redraw/hide function could redraw/hide all the
> > elements inside it.
Another good point.
> > Besides, it is imho clearer to be able to put things
> > inside a window, with coordinates which are relative to the window
> > instead of the screen.
I think so too. Makes moving windows much easier (i.e. moving an OSD between
screen corners, animation in the menus, ...?).
> > From what I have understood from above, all
> > coordinates are absolute coordinates :(
>
> I could create a windows add function, changing the coordinates from
> window relative to absolute when added.
I am not sure whether I understand this? Do you mean coordinate conversion
functions (I guess not)? These are needed in any case (to get from screen
coordinates to local window ones - maybe for later mouse/touchscreen support,
and in the other direction when actually painting).
Ciao, / / .o.
/--/ ..o
/ / ANS ooo
-------------------------------------------------------
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_id=4721&alloc_id=10040&op=click
_______________________________________________
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
