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.
o The image viewer is ported to the new gui code.
So what is possible right now with the current layout: You can output
Freevo on sdl like before, you can also use bmovl. It is possible to
display boxes on any output device. So showing boxes in mplayer is
possible. The image viewer has a small animation demo: hit the DISPLAY
key to see a moving in osd.
The big difference is the way gui objects are handled: nothing should
ever call a clearscreen. Everyone should clean up it's own mess. What
does this mean: you could draw the idlebar inside the image viewer,
inside mplayer or wherever you want. But this only works when no
functions clears the screen without the idlebar knowing of this. You
only add objects the the screen. They will be there on each redraw or
whatever until you remove them again later.
This brings up the first questions: when we start the image viewer,
the idlebar should hide itself. How does the bar know that? When
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?
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.
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.
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.
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?
Now I need some ideas for future development:
o How should the problems above should be handled?
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?
o The fxd files can change the settings. How to notify new boxes and
the plugins like idlebar about that?
o How to integrate mplayervis again? It depends on pygame.
And some help:
o If you like, you can create a new backend. There is a README in the
backends subdir.
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.
- 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,
Dischi
--
My operat~1 system unders~1 long filena~1 , does yours?
-------------------------------------------------------
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
