[Freevo-devel] Re: skin and gui interaction
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
[Freevo-devel] Re: skin and gui interaction
Gustavo Sverzut Barbieri wrote: --- Dirk Meyer [EMAIL PROTECTED] escreveu: Ho That's a nice idea, and I tried that. But there are some problems: if we draw overlapping transparent rectangles for blue_round1, we don't want the color to overlapp. I didn't understant that. Look at blue1_round1 and go into the movie/mp3/image menu (the normal one). You see a transparent background for the listing and one for the view area. These backgrounds overlap (you can see that when you select an item without image. If you draw these background on different layers and blit them together, the second rectangle will darken everything which is below it. Below means the background _and_ the other rectangle and the space they share gets darken than the rest. But the most important problem: it's too slow. We would redraw most of the screen all the time (areas can overlap) and blitting something is slow, blitting an alpha surface into a surface is very slow. And one very important problem: the areas depend on each other, one has to be redrawn when another changes. Why? I don't understand. What I meant with OPAQUE maybe wasn't very clear. It was clear. I tried something similar to your proposal. It worked fine until I got to the view area. A Window could be opaque but have transparent areas. The OPAQUE thing means we just don't care with things are under this window: we don't redraw them. We can't do that, beacuse ... IE: the info area has rounded corners and transparent BG. ... the round corders are part of the background. The small space at the corners where the round is has to be the original background. And if the background below that transparent background changes, we have to redraw the transparent part, too. However we know that the screen BG never change. So we can make Info.OPAQUE=TRUE. Wrong. For Aubins new skin the background changes on the main menu for each item. The background can also change for different folders. The same with View and Listing. The same? View and Listing change, for the view area the background changes based on the size of the image. But the real slow part for us, Menus, will become really fast. Have you tried my new skin? It's much faster than before. Because every area is aware of all the others I can redraw only the parts I want to change. 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. What I have done (with Robs help): the skin is _no_ GUIObject. The skin is only a set of drawing functions. The menuwidget is a GUIObject which fills the hole screen. The menuwidget can be drawn, shown, hiden like all other GUIObjects. It uses the skin functions to draw itself. Since the menuwidget is one GUIObject, background, listing, view, info and title area aren't GUIObjects, they are only part of one GUIObject. With this design I can redraw the changed parts of the skin very fast, it would be much slower (you will notice that even on a fast computer) with separate GUIObjects for each area. As i said before, I see no reason for that. I hope you understand now. I tried, it didn't work out. But I don't see way we should have different GUIObjects for each area. The menu is one big GUIObject, it's fast and why should everything be an extra GUIObject? Dischi -- On-line, adj.: The idea that a human being should always be accessible to a computer. --- 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
[Freevo-devel] Re: skin and gui interaction
Rob Shortt wrote: Here are some things I think we need from the skin: [snip] Tak a look at GetPopupStyle in skin_dischi1, this should be everything you need. for child in menuw.childeren: if child.is_visible(): child_area = child.get_rect() # a tupple of left,top,width,height OK, that's easy. But I also need to know if the last children went to visible=FALSE. Some event or call a draw function in the menuw, whatever. Dischi -- According to Kentucky state law, every person must take a bath at least once a year. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
