Gustavo Sverzut Barbieri wrote: >> It can look like blue1_big, blue1_small, >> blue_round1 and aubin_round1 (called blue_round2 in the new >> skin). Everything is located in skins/dischi1. Also working: mp3 >> player and the beginning of the extended view (press DISPLAY inside >> the audio menu to take a look, only in blue1_big). > > Great, I'll start looking at your code and try to help you with the > extended menus...
Maybe it's better to help with ideas than with the code itself. There are some undocumented things right now which aren't easy to unterstand. > IMHO we should get the "extended" off the name. Since all menus are > these type now. Agreed, but I haven't found a better name yet -- maybe we don't need one, we'll see. > I think we might change betweens various options of > menu layouts, using DISPLAY to toggle between: > VIEW=ON/OFF > INFO=ON/OFF (also resize if VIEW is ON/OFF) > LISTING=ON/OFF (also resize if VIEW,INFO are OFF) DISPLAY should toggle between all these combinations? I think it's too much. > Really, DISPLAY should be a method array, calling each one: > display[0]=View.toggle_visibility() > display[1]=Info.toggle_visibility() > (more?) How much? Do we need the combination Info without View? Do we need a menu without listing area? It's no problem with the current skin, but do we really need this? > and then call resize, based on other screen items... (how to do that in > a clean way?) That's the problem: how to do that in a clean way? Right now you toggle between different types of menus. Look at blue1_big in skins/dischi1. There are two menus for the audio menu and we toggle between them. >> Second we have an info area. The tv menu toggles between a large >> listing and a smaller one with an info area. We can also have an info >> area for the movie/audio/image/games menu. Should DISPLAY toggle >> between with and without info area? >> > No, we should toggle between various layouts. as explained above. OK, we have various layouts. Let's call them menu_layout, because in my skin a layout is something different. The skin designer could define different layouts, e.g. text without info, image with info, ... DISPLAY would toggle between them. So if we want to have a text with info fallback if they all have the same cover, we need to define this, too. But should it be visible with the toggle, too. > The problem will be how to tell the screen objects on how they should > resize themselves... before (2 state menu) it was easy, but we should > think about many layouts mode. No resizing please, it's a mess and it wouldn't look like the skin designer wants it. Proposal: <menu type="audio"> <!-- definition of audio menus --> <use image="my image" text="my text menu with info"/> <use image="" text="my text menu"/> </menu> I don't like the name "use", but I already use "layout". This menu set defines that DISPLAY should toggle between these two "use" types (I _really_ don't like "use"). The first one (default) has an image version and a text version. Normally "my image" will be taken, if all covers look the same, "my text menu with info" is displayed. If you press DISPLAY you toggle. There is no image version, so it's text mode only and "my text menu" will be used. Idea: maybe "variant" is better than "use" After that, we need to define "my image" and all the other menus. This looks like the normal <menu>s in my skin now, only the name is now menu_layout: <menu_layout name="my image"> <screen .../> <listing .../> <info .../> <view .../> <title .../> </menu_layout> The skin designer can define as much different menus to toggle as he likes. Comments? Dischi -- "Today Is A Good Day For Someone Else To Die!" -- (Terry Pratchett, Feet of Clay) ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel