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
