Hans Meine wrote:
> 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.
No, it's not that easy. The audio player is as fullscreen as the image
viewer. But the idlebar should be visible in audio, not image. And
still, we need some sort of event "SCREEN_CHANGE" arg='image viewer'.
>> >> 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.
Event may not be possible (at least not the easy way): the image
viewer comes to the background. Wenn it sends the event, it will be
delivered to the plugins after the image viewer is done. Too late.
>> >> 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).
The fullscreen vs. windows doesn't help. When a popup box shows up on
mplayer, are we fullscreen or windowed? That doesn't work.
>> 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.
OK, internal they have still parents. Also for event handling. Use
your eventhandler and send to parent if not handled.
>> > 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).
What I mean: you draw (add) objects to the screen. When you show a
PopupBox, you add the box and the text to the screen. So the text
needs to have absolute coordinates or the screen object can't draw
it. Idea: create is relative, add the object to the window, and this
add functions makes absolute coordinates and adds it to the screen.
Dischi
--
It's the same old story; boy meets beer, boy drinks beer... boy gets
another beer.
-- Cheers
-------------------------------------------------------
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
