Gustavo Sverzut Barbieri wrote:
> You can make this one work making the overlap area transparent on one
> layer. Or in this case, have the view and listing to be the same
> object.
I've done that by having one background, one alpha and one content
layer. Making view and listing one object isn't an option, if you
start combining objects you can't re-use them. Right now I use the
same view area code for the menu and for the mp3 player.
> As I said, we can make OPAQUE=true and have some transparent parts in
> the window IF we are sure that everything that's under our window will
> not change (or will not affect our window)
Since aubin_round1 changes the background, we couldn't use any
transparent objects -- not an option.
>> The same? View and Listing change, for the view area the background
>> changes based on the size of the image.
>
> Huh? Are you talking that it changes when I change from Images->Movies
> or it changes from inside the movie, when you select another item?
aubin_round1 has different backgrounds for movie, audio, image and
games. It's also possible that the user wants a folder specific
background.
> No I haven't. I'm in my parents house and I have no Linux here :(
> Friday I'm home, so I'll test. Also, are you and Rob writing about your
> changes/innovations? As I'm out for few days I "lost sync" with your
> things :)
I'm documenting my skin and the xml files will follow.
>> > About the OPAQUE, I think all the windows could be opaque for now.
>>
>> That's too easy, it's not the case with the current skins.
>>
>
> Yes it is. We will only use OPAQUE=false when we have transparent
> popups or something like that. Actually when we want to have a popup
> shown AND the background changing. IMHO this will be used only with
> Applets and if we want these applets over the menu or something.
You're free to try. I have five areas in my skin (screen, title,
listing, view and info). Each area class inherits from a parent class
in area.py and only does content specific stuff. These higher classes
don't even use osd.drawXXX and call a function in area. By changing
area.py you can change all areas.
But I doubt that your area.py will be faster than mine. I made some
ugly enhancements to speed up things.
> Making them all a monolitic GUIObject is ugly, maybe various
> GUIObjects put together with a Container is the best solution) and
> draw things like you do now, I see no problem too.
I don't thing it's ugly. I see no reason why they all should be one
GUIObject. And I don't really draw each area after another. I only
save want they want to draw. After that, I check whats new and draw
them at the same time. It's fast and I don't see one single reason why
I should change it. Think about it that way: each area (== separate
object) is a part of the whole screen (menuw == GUIObject). Calling it
GUIObject and Container makes no difference.
> The point is we need a WM to handle focus and windows redrawing.
Do you want to set a focus from listing to view area? The screen,
info, view and title area don't need a focus, the whole menu needs
one. That is done by making the menuw a GUIObject.
Dischi
--
The good thing about standards is that there are so many to choose from.
-- Andrew S. Tanenbaum
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
