Replacement Interface

[DaveC]

Actually your idea ( actually I think it was Sony's idea from the PSP) in operation is very similar. 

​

Stop putting me down, I have never ever seen a PSP other than on the internet.
Anyway I don't want to argue about this, yes I admit you can only see a strip of 5 items. This was of course a clever arrangement in order that I could have other stuff on the screen and to not confuse the user with an overload of buttons. :lol:
At the end of the day it is not really our choice whether parag0n creates yours or my interface so lets not argue.

​

It really wasn't meant as a put down, sorry. I just assumed you got it from the PSP as that is how it does it. I have a PSP and I really don't like that menu system, because of the reasons given before.

If it is any consolation "my" idea is really just a buffed up GP32 BLU firmware. I basically only combined the best PSP and GP32 BLU ideas into one.

 

[Squidge]

Don't forget the idle people - some people who don't have a great lot of programs on there SD card will probably want to throw everything into one category for ease of use. If they are forced to use categories and each category only has two items in, then it's going to get very irritating very quickly.

Also, where are the categories, text and icons going to come from? Are we going to assume that everyone will be distributing ".info" files (or whatever) with there emu's etc, and cluttering up the sd card? What if these files are not copied over, will the menu simply ignore them?

Next, when will the icons be loaded, is the menu going to take 10 minutes to load every time due to the amount of data needed? Or are you going to end up with a row of blank icons when switching between categories due to the data having to be loaded when the category is visible? This is one of the things I hated on the PSP - the icon only loaded when it was visible, so if you scrolled too quickly, you had to repeatedly keep stopping and waiting for the icons to be drawn to see if it was what you wanted.

 

[DaveC]

You're nto understanding

joystick up / down controls the left hand bar moving up and down (scrolls through the catagories

joystick left / right moves the bottom bar one block to the left or right

L and R move the bottom bar 5 spaces (one screen) to the left or right

​

That is fine. Duh, it is early I get the controls now :rolleyes: I still am not sold on it though. I would like at least to see how mine looks using your L337 Photo shop skillz. Mine looks kind of ugly compared to yours right now and I think that may put people off.

If you don't have time I may take your image and cut and paste later tonight.

 

[parag0n]

i'll do it in an hour or so, i'm at work at the moment. i'll use the same icons etc for the same things, so it'll be a very similar theme.

 

[Hanz™]

Don't forget the idle people - some people who don't have a great lot of programs on there SD card will probably want to throw everything into one category for ease of use. If they are forced to use categories and each category only has two items in, then it's going to get very irritating very quickly.

Also, where are the categories, text and icons going to come from? Are we going to assume that everyone will be distributing ".info" files (or whatever) with there emu's etc, and cluttering up the sd card? What if these files are not copied over, will the menu simply ignore them?

Next, when will the icons be loaded, is the menu going to take 10 minutes to load every time due to the amount of data needed? Or are you going to end up with a row of blank icons when switching between categories due to the data having to be loaded when the category is visible? This is one of the things I hated on the PSP - the icon only loaded when it was visible, so if you scrolled too quickly, you had to repeatedly keep stopping and waiting for the icons to be drawn to see if it was what you wanted.

​

I thought about that, and since it would only take a minute or so I wouldn't have a problem with supplying stuff like that.

 

[Flavor]

This isn't a very interesting skin, and I think it's fairly old, too, but here's a video of XBMC in action just for those of you who haven't seen it.

I can only assume that nobody takes new screenshots/videos of XBMC, because the product just sells itself. Oh, maybe I should mention that the source code and skins are all freely available. I'm not advocating a port of XBMC, but it's a nice system that a lot of people are happy with using for a similar purpose and with very similar controls.

http://dwl.xbox-scene.com/~xbox/xbox-scene.../XBMC_SMALL.wmv

 

[DaveC]

Don't forget the idle people - some people who don't have a great lot of programs on there SD card will probably want to throw everything into one category for ease of use. If they are forced to use categories and each category only has two items in, then it's going to get very irritating very quickly.

Also, where are the categories, text and icons going to come from? Are we going to assume that everyone will be distributing ".info" files (or whatever) with there emu's etc, and cluttering up the sd card? What if these files are not copied over, will the menu simply ignore them?

​

You can make a catagory called "Apps" and dump everything there. With mine it would be configurable, so the only catagories at the top would be the ones you want. You could theoretically only have a couple of catagories at the top.

As far as icon images it would work as it does now. If there is no .PNG it would give the name and the default icon image above it.

 

[deepmenace]

Is good discussion going on here. My two cents worth is that i'd like size of icons to be configurable, i'd rather get shed-loads of stuff on one screen. Big kiddie icons have no place on the gp2x.

What ever we have we need shortcuts to oft used items that should be sensitive to shoulder buttons presses.

i.e.
hold L ( screen changes to show how holding L has affected button presses) and press A = straight thru to DrMd

hold R ( screen changes to show how holding L has affected button presses) and press A = media player

 

[parag0n]

Don't forget the idle people - some people who don't have a great lot of programs on there SD card will probably want to throw everything into one category for ease of use. If they are forced to use categories and each category only has two items in, then it's going to get very irritating very quickly.

Also, where are the categories, text and icons going to come from? Are we going to assume that everyone will be distributing ".info" files (or whatever) with there emu's etc, and cluttering up the sd card? What if these files are not copied over, will the menu simply ignore them?

Next, when will the icons be loaded, is the menu going to take 10 minutes to load every time due to the amount of data needed? Or are you going to end up with a row of blank icons when switching between categories due to the data having to be loaded when the category is visible? This is one of the things I hated on the PSP - the icon only loaded when it was visible, so if you scrolled too quickly, you had to repeatedly keep stopping and waiting for the icons to be drawn to see if it was what you wanted.

​

By default the menu file will be a hidden file stored on the SD.
To build the menu, there'll be an automated tool that runs through the SD and finds all the .info files with the same names as .gpes (maybe, not too sure on the details yet), and it'll add them to the stored menu file.

Any .gpe or .gpu files without an info file will be automatically added to an "Uncatagorised" section, so the people with only a few things will only have to delete the .info files when they copy stuff across.

The menu / icon loading i'm not too sure on yet, i'd probably cache the previous page & next page of icons in the bottom bar, and the next icons up and down on the left hand bar.

 

[Hanz™]

Is good discussion going on here. My two cents worth is that i'd like size of icons to be configurable, i'd rather get shed-loads of stuff on one screen. Big kiddie icons have no place on the gp2x.

I agree completely. Can't stand kiddy looking GUIs.
DaveC: Same for the interface I mentioned earlier.
BTW i am making up my own example of how I would like it to look.

 

[DaveC]

Is good discussion going on here. My two cents worth is that i'd like size of icons to be configurable, i'd rather get shed-loads of stuff on one screen. Big kiddie icons have no place on the gp2x.

I agree completely. Can't stand kiddy looking GUIs.
DaveC: Same for the interface I mentioned earlier.
BTW i am making up my own example of how I would like it to look.

​

Yeah the icons in mine are too big and kind of kiddy. The reason was explained before(came from GP32 concept). That can easily be changed, and should be . I just didn't have time to mess around with it much. With smaller icons you will really get alot of stuff on screen. Plus it would be skinnable.

I have been thinking your first idea about my interface would be good. Put the catagories vertically on the side and have the icon panel to the right.

Maybe Paragon could try that out?

 

[DijiTao]

I think everybody is going about this all wrong with mock-ups, the current problems with the menu are not because it doesn’t have icons and a background, it’s screwed up because it’s not extensible, it acts as file browser when launching applications and it's controls are awful. So with that in mind - however less sexy – here is something that is in my opinion something far more useful, requirements.

The program shall have 5 XML formatted configuration files; menu.xml, sounds.xml, music.xml, backgrounds.xml, layout.xml

Menu.xml:
It Shall store the hieratical information of the menu structure, metadata for the menu’s programs to be launched and the categories the programs are organized into
It Shall have two types of nodes; program & group
Program nodes shall store:

• A display name for the program to be launched
• The path to the program to be launch
• The clock speed at which the processor will be set to run the program at
• The path to a png icon of the program 48x48px in size
• The path to a png icon of the program 48x48px in size to be used when the program is selected
• The path to a png preview of the program 160*120px in size
• The name of the author of the program
• A short text description of the program

Group nodes shall store:

• The name of the group
• The path to a png icon of the group 48x48px in size
• The path to a png icon of the group 48x48px in size to be used when the group is selected
• The path to a png preview of the group 160*120px in size
• A short text description of the group

The hieratical structure of the XML file shall provide the parent to child relationship between nodes. Program nodes may not have child nodes, Program nodes must have a parent node that is a group node. The root node of the xml file shall be a group node with a display name of “Main Menu”.

sounds.xml:
Shall provide a list of events and the path to an ogg formatted sound files to be played when these events occur:
The events shall include

• Menu Startup
• Application Launched
• Returned to Menu
• Low Battery
• Cursor Moved
• Category Selected

sounds.xml shall also provide a volume level at which the sounds are played

music.xml
It Shall provide a path to a to a directory containing sound files to be used for background music, as well as options for how the music is played
Options shall include

• Play Order (alphabetical, reverse alphabetical, shuffle)
• Volume
• Fade in length (number of seconds the music should take to transition from silence to the desired volume)
• Persist Song location (yes/no option – if yes when the menu is exited to launch an application the location the song is at is saved, and resumed when the menu is next entered)

backgrounds.xml
Each node in this file shall represent a possible random background image that can be used by the program. The node shall store the path to the image as well as information about how the image is displayed. Options for how the image can be displayed shall include:

• display-type (tiled, or centered)
• display-effect (scroll-left, scroll-right, scroll-up, scroll-down, scroll-up-left, scroll-up-right, scroll-down-left, scroll-down-right, rotate-left, rotate-right)

layout.xml
This file shall describe where or if the various elements stored in menu.xml are displayed. Additionally it will define an overlay png file that will be displayed on top of the background. This png file should use the alpha channel to define lighter and darker areas of the screen. The following elements will be represented by nodes with the nodes attributes describing the elements position and if the element is selectable, and how scrolling should be implemented if the area is not large enough for it’s contents (vertical or horizontal).

• Parent Icon Area
• Current Icon Area
• Selected Items Display Name
• Selected Items Description
• Selected Items Author
• Selected Items Preview

The file shall also describe the location of “widgets” that display that status of the GP2X. These widgets shall include:

• Battery Status
• TV Status
• CPU Status
• Volume Status
• SD Card Status

Navigation:
The program shall select the nearest selectable item in the direction pushed on the stick, and will scroll any scrollable areas to accomplish this. When a button is pressed the application associated with the selected item is launched, or if a category is selected the current Icon Area contents are moved to the Parent Icon Area and the new icons are displayed in the Current Icon Area.

Putting it all together:
By writing a program that can read in these configuration files and appropriately render the result, a menu system is generated that extremely flexible. This system could render a menu that looks like the current menu, looks like parag0n mock-up, or something completely different such as just displaying the program’s large preview image centered on the screen and scrolling left or right to select other programs. The organization of the menu itself would also be completely up to the user. By keeping each of the configuration files completely separate users would be able to trade, mix and match these pieces to produce a unique creation.

 

[Cyclops]

http://standards.freedesktop.org/menu-spec...u-spec-0.9.html

Why not keep to an existing standard. Its better thought out, by people who know what they are doing. Over Months, by many people etc etc

 

[DijiTao]

Once the menu program itself is written, then programs to edit it’s xml files could be written. Editing menu.xml, sounds.xml, music.xml, and backgrounds.xml could all be done on a program written natively for the gp2x. However, I think layout.xml would require a desktop computer. Ideally the layout tool could be written in a language like java, so it would be easy to run it on any computer.

 

[DijiTao]

http://standards.freedesktop.org/menu-spec...u-spec-0.9.html

Why not keep to an existing standard. Its better thought out, by people who know what they are doing. Over Months, by many people etc etc

​

Because it's not a desktop.

 

[parag0n]

http://standards.freedesktop.org/menu-spec...u-spec-0.9.html

Why not keep to an existing standard. Its better thought out, by people who know what they are doing. Over Months, by many people etc etc

​

Because thats a desktop spec, and the gp2x isnt a desktop?


This thing is a handheld. the menu is there to run software. it doesnt haave to deal with all the crap a normal desktop has to deal with, all it has to do is run a file, and exit.

 

[Cyclops]

Because thats a desktop spec, and the gp2x isnt a desktop?

LOL the more I read your comment the funnier it is.

This thing is a handheld. the menu is there to run software. it doesnt haave to deal with all the crap a normal desktop has to deal with, all it has to do is run a file, and exit.

​

Read the spec, Identify the differences. Whatever menu you look at here they are the same as your windows start menu. Would I suggest a complete implimentation no, but then your crackers if you think I did.(Although I suspect one could just be grabbed from somewhere)

i.e catagory/ menu item.

hence why not just follow a current standard. I have more programs on my GP2X than I will ever have in my computer menu's

 

[DijiTao]

If all your suggesting is using their catagories that's all well and good.

I didn't address the issue of how the catagories should be made at all in my post. I think using the "Registered Categories" in the spec you linked would be a good idea. But, the actual format of their menu file doesn't help one bit.

 

[DynaMight]

If anyone makes a replacement interface even half as good as XBMC I will be happy.

XBMC is well and truely awesome, it makes Microsofts efforts on Windows Media Center look like something a 3 year old coded.

 

[Cyclops]

If all your suggesting is using their catagories that's all well and good - but that's about the only think that does make sense.

​

read it again look at the example with the exception clock speed. Its almost the same as what you suggest in menu.xml look at the example.

The only difference I can see is clock speed. Its of my opinion, and its only an opinion because I'm not sure and I could be missing something, it shouldn't be there. The only instance I can think of Why it might be there is to create a *universal* front end to command line emulators. Which I think might be a good idea, but its a different implimentation, to any suggested here, and would require some proper thought.

read your suggestion and the example.