--- Dirk Meyer <[EMAIL PROTECTED]> escreveu: > 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. >
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. > >> 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. > 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) > > 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. > See my other email, "WindowManager", there I said that in that case we can make the MainMenuListing a GUIObject and the MainMenuIcon another, being MainMenuListing OPAQUE=false > > 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. > 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? > > 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. > 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 :) > > 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. > > > >> 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? > I think having multiple windows with GUIObjects inside are easy. in my mind it should work like Mandrake installation: it is a bunch of windows placed right on the screen, the look is like a one window with widgets placed, but it's easy to control (make appear/disappear) the windows that appear/disappear widgets, and in our case (that we don't have a full-featured GUIObjects toolkit, it's easiest). However, if you want to make Listing+View+Info one window(I said window. 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. But if we have the windows redrawing optimized for the WM, I see why not use the WM instead of one for each window. The point is we need a WM to handle focus and windows redrawing. Gustavo _______________________________________________________________________ Busca Yahoo! O serviço de busca mais completo da Internet. O que você pensar o Yahoo! encontra. http://br.busca.yahoo.com/ ------------------------------------------------------- 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
