On Tue 27.07.2004 at 02:00:46PM +0200, Dirk Meyer wrote: > Hi, > > as you know, I started moving around the gui code and made many > changes the last days. Here a list what I have done so far: > > o skin, osd and animation are inside the gui subdir. This dir has the > following structure: > > gui/__init__.py: Interface to the gui for all other parts of Freevo > gui/animation: Animation code (deactivated right now) > gui/widgets: Stuff you can draw. This includes basic objects > like Text, Rectangle and Image (the skin uses > this), but also high level objects like button, > label and progress bar. The boxes like PopupBox are > also inside this dir > gui/areas: The old skin code. Areas are something like boxes > for drawing objects. This needs some cleanup. > gui/backends: The different backends to draw stuff. Right now, > there are two backends: sdl and bmovl. > > 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. > 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. > 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. > 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). > 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. > 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. > 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. > 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). > 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). > 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 :( > - Layout is done inside the boxes. If someone wants to re-add the > LayoutManager, please do so, but don't add hundrets of attributes > to the objects please, 'style' should be enough. > > - It's simpler now: before the change, a button was a container with > a border and a label. A label itself was something with text. Now > a label _is_ a text, a button _is_ a label (only with a different > drawing function). > Request for Comments, Hoped to be a bit helpful... I haven't taken a look at the GUI code since last christmas, so if I'm thousands miles away from what you meant, just ignore my comments :) 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
