Matthieu Weber wrote:
> On Tue 27.07.2004 at 02:00:46PM +0200, Dirk Meyer wrote:
>> o The event stuff is deleted inside rc.py. There is a new file
>> eventhandler.py with functions to post an event and to get the
>> focus. Boxes from widgets also use the same way of getting the focus
>> as other applications do. So no rc.app(self) and rc.app(None)
>> anymore. Use eventhandler.append and eventhandler.remove to get the
>> focus.
>
> Just nit-picking on the names: append and remove what? the focus? an
> event handling function? There can be only one application that has the
> focus at a time, so there is nothing to be appended, imho.
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.
>> This brings up the first questions: when we start the image viewer,
>> the idlebar should hide itself. How does the bar know that? When
>
> The idlebar doesn't know it, but something is stacked on top of it and
> hides it. Whatever function handling the screen should be able to know
> what is hidden and what is not, and display what is visible.
I'm not sure it works. If you always keep the stuff on the screen, it
would blow up the screen itself. To much objects. And if the image
viewer only shows a small image not filling the screen?
>> 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?
>
> Because it receives an event (posted by the mplayer plugin) that
> indicates the change of display backend.
That would be an idea. On every screen (backend) change, send an
event.
>> 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
>> 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.
>
> The plugin should call the OSD and ask if the operation is possible. The
> actual implementation may vary, but that's the idea: provide a request
> function from the OSD that tells what are the capabilities of the
> current backend.
So None is the way to go. Give me the screen, I want to draw. If None,
drawing is not possible (like tvtime).
>> o if the screen changes? Maybe it doesn't have to know. On screen
>> change the gui could could move all objects to the new screen. But
>> this only works when the resolution is the same, software scaling is
>> a must for using bmovl then.
>
> There could be an intermediate "virtual display" layer (the OSD ?) that
> holds handlers on all the displayed elements. The virtual display knows
> what is the real display implementation (i.e. backend), accept any
> display requests from the plugins, but not display anything if there is
> no backend at this time), and redisplay each element to the new backend
> if needed.
More or less, it is the same I wrote. On screen change, the gui code
moves the objects to the new screen. We only need a dummy backend,
active when no backend is working right now. This could also remove my
'None' problem from above.
>> 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.
>> 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. 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.
>> o The fxd files can change the settings. How to notify new boxes and
>> the plugins like idlebar about that?
>
> By having one central configuration object that holds in real-time all
> configuration, including local (i.e. per-directory) config. The plugins
> should request the configuration object for each action which is
> config- and location-dependant, specifying its current location when
> making the request (a dictionary of dictionaries should do the trick).
Yes, something like that. Not sure how.
>
>> And some help:
>>
>> o Fix some boxes: The new code only works for PopupBox, AlertBox,
>> ConfirmBox and ProgressBox. If someone wants to fix the other boxes,
>> please do so (and drop me a note). The design is different now:
>>
>> - A window is only something that draws on the screen. The label
>> inside it has nothing to do with the window. So x/y coordiates are
>> based to the screen values, not the parent once (there is no
>> parent).
>>
>> - There is no container support, I'm still thinking how and if we
>> need it.
>
> Calling the container's redraw/hide function could redraw/hide all the
> elements inside it. 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. 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.
Dischi
--
A black cat crossing your path signifies that the animal is going somewhere.
-- Groucho Marx
-------------------------------------------------------
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
