Replacement Interface

[parag0n]

DaveC:

I fully agree with the making a standard XML format usable across all the different menus, something like that can only be good ^_^

 

[DijiTao]

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.

​

eh.. I still don't say it gives us much. A massive amount of what's in the freedesktop spec just doesn't apply - but all the same, it's not that different. Sure ditch what I said for menu.xml and just use their spec - I don't think it makes that much of a difference. What I'm puposing is a bit bigger then just how the menu file is constructed. But yes, I'll agree that there isn't a good reason to not follow the spec, other than it's a bit larger then what we need.

 

[DijiTao]

DaveC:

I fully agree with the making a standard XML format usable across all the different menus, something like that can only be good ^_^

​

Looking at that I don't see anything that couldn't be described by what I said in my purposal, I'm thinking that's a good thing.

 

[Nickmon]

Can some one buiild it please !

 

[Flavor]

Looking at that I don't see anything that couldn't be described by what I said in my purposal, I'm thinking that's a good thing.

Yup. There's an obvious split in ideas here.

Some people here seem to be stuck on how it should look and work to the user.

Others are concerned about how it will actually work.

Mockups are nice, but if you're making something skinnable with XML or whatever, then you're just saying "here's how one guy could skin it."

 

[parag0n]

Well, the original post gave us a screenshot of a possable menu, and

It shall be replaced, but what should it look like and how should it work?

I'm posting on the how it should look angle, and there are bits of how i think it should work interspersed throughout my posts


--addition--

Maybe we should put a post on the wiki about the spec on the "how it works" angle, that way we can add and remove things as needed, and the spec is easily and fully available to people building frontends and working on the backend.

 

[DaveC]

DaveC:

I fully agree with the making a standard XML format usable across all the different menus, something like that can only be good ^_^

​

Yeah that is good. I would probably put that status bar on the bottom, and make the catagory icons smaller so that you could get more on screen. Nitpick though not that important.

This layout is a good compromise between the cross bar layout and mine . It works similar and makes good use of the screen area.

Don't forget, you can have sub levels (folders) appear in the icon panel with executable if you wanted (see my original example). So in music for example, when you select the music catagory in the icon panel you could have folders with albums in each folder, or folders that contain songs by artist etc.

Hey Paragon could you send me all of the separate icons and backgrounds?
I would like to mess around with different layouts and post results.

Thanks.

 

[Series-8]

Wow, this thread has exploded with ideas; I'm not going to pretend I read all of them...

I like DaveC's ideas (not the icons or colours mind you) the concept can work.
(move the crossbar to a horizontal position again... :huh: )

We should be mostly thinking about HOW the buttons react with the interface.

The GP2X usually does NOT have: a keyboard, mouse, or any other meathod of input beyond the joystick, buttons.

I think the Top L R buttons should scroll the 'category' icons (games, system settings, media, file browser, program settings)

and the joystick should select an icon, (no mouse just a selection box)

'A' - Universal Selects/Runs/executes
'X' - Properties/Options of that item
'B' - Universal Cancel action

There should also be a 'snap' menu to change settings of the GUI itself quickly, SELECT or whatever would do. this menu would simply appear over the main screen.

If a certain file type can be run by multiple programs the user should get a choice:

Say a MP3 can be used by the GPH Media player, Oldplay, Mplayer, ect.

A second set of icons appear arranged around the file to be played, in a circular pattern and one is selected by moving the joystick up/left/right/ect. (there are little icons that show what app is selected by what button-combo if there are many options)

Each file should have an .autoexec script (ran before program) and perhaps a .endprog script (ran on exit) in addition to the script that runs the program itself.

The GUI may also benefit from a mini-integrated audio player, (one of the command line players would do fine) just for 'ambiance'.

Also the whole thing is logically arranged by directories:

/FancyGUI_root/basic_categorys/sub_category/program_scripts

No executable files need be stored in that arrangement, just the scripts and icons.

 

[DijiTao]

I think the focus should be on what tools do designers need in terms of widgets, and then we design a spec with the flexibility to do whatever is needed.

 

[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.

​

eh.. I still don't say it gives us much. A massive amount of what's in the freedesktop spec just doesn't apply - but all the same, it's not that different. Sure ditch what I said for menu.xml and just use their spec - I don't think it makes that much of a difference. What I'm puposing is a bit bigger then just how the menu file is constructed. But yes, I'll agree that there isn't a good reason to not follow the spec, other than it's a bit larger then what we need.

​

See post further up. Already answered. I think a full implimentation is dumb, but basics which I suspect you have already outlined. In a standard form. Although again I suspect this can be grabbed from somewhere. Is it overkill yes it is, but it does allow a certain level of future-proofing and if anyone wants to move to a WIMP interface(take your pick). Using many standards is a bad idea, and again one thought up in 5 minutes will never be well thought out at that of freedesktop(or even if the two of us went at it all year)

 

[Cyclops]

I think the focus should be on what tools do designers need in terms of widgets, and then we design a spec with the flexibility to do whatever is needed.

​

LOL EH? you mean pictures. Judging by the Most of the skins currently in question most use gnome/kde themes. Why not just make it possible to use those, or are you refering to what file formats SDL can handle.

 

[DijiTao]

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.

​

eh.. I still don't say it gives us much. A massive amount of what's in the freedesktop spec just doesn't apply - but all the same, it's not that different. Sure ditch what I said for menu.xml and just use their spec - I don't think it makes that much of a difference. What I'm puposing is a bit bigger then just how the menu file is constructed. But yes, I'll agree that there isn't a good reason to not follow the spec, other than it's a bit larger then what we need.

​

See post further up. Already answered. I think a full implimentation is dumb, but basics which I suspect you have already outlined. In a standard form. Although again I suspect this can be grabbed from somewhere. Is it overkill yes it is, but it does allow a certain level of future-proofing and if anyone wants to move to a WIMP interface(take your pick). Using many standards is a bad idea, and again one thought up in 5 minutes will never be well thought out at that of freedesktop(or even if the two of us went at it all year)

​

bah.. it took more then 5 minutes to come up with that post... I just hope your understanding that the freedesktop spec only solves a small part of the problem, but yes I agree that following the spec is a good idea, as it will allow for different menu programs to all read the same file for how the menu is structured. So what about the other 4 files I'm recommending?

 

[hackgrid]

just for fun, my ideal menu:

​

I love that menu

 

[DijiTao]

I think the focus should be on what tools do designers need in terms of widgets, and then we design a spec with the flexibility to do whatever is needed.

​

LOL EH? you mean pictures. Judging by the Most of the skins currently in question most use gnome/kde themes. Why not just make it possible to use those, or are you refering to what file formats SDL can handle.

​

A KDE or Gnome theme won't do anything when it comes to defining layout - and layout needs to be flexible.

Both of these themes should be possible with a properly designed menu program:

 

[DijiTao]

just for fun, my ideal menu:

​

I love that menu

​

That's a good one too, should also be possible to create something like that.

 

[DaveC]

One thing to remember here too. This launcher should be fairly lean. If it gets too overly complex with oodles of effects, pictures, music, and big code it will take that much longer to boot. I know if I just want a quick blast of MAME I am not going to want to sit and wait while it loads all kinds of large pictures, and feature code, etc just to get to my favorite program. K.I.S.S rule really important here. We need to keep perspective. This is a game and media player, not a PC or PDA.

 

[DijiTao]

One thing I didn’t think through enough when I was making my first suggestion was that all icons should be defined by the in the menu file. I think upon further thought, that it would be best if there was also a icon-theme.xml file that acted as an override to what is in the menu file. This would allow users to independently switch icon themes without touching their menu. If the icon-theme file did not define an icon for a particular program then the icon defined in the menu file would be used.

The point I can’t hammer in hard enough is that everything must be separate and modular. Users should be able to keep there current menu structure, and add to it the icon’s from one theme, the background from another, and the layout from yet another.

 

[DijiTao]

One thing to remember here too. This launcher should be fairly lean. If it gets too overly complex with oodles of effects, pictures, music, and big code it will take that much longer to boot. I know if I just want a quick blast of MAME I am not going to want to sit and wait while it loads all kinds of large pictures, and feature code, etc just to get to my favorite program. K.I.S.S rule really important here. We need to keep perspective. This is a game and media player, not a PC or PDA.

​

I think something as “simple” as DrMD’s scrolling background adds a ton of sparkle, and while I personally wouldn’t want sound effects, or background music, I think the capability needs to be there. The important thing is to design the system in such away that user such as yourself could disable the features you don’t want and shave off a second or two on boot, but somebody who wants maximum eye-candy at the expensive of a efficiency has that option as well.

 

[Vimacs]

i would like something simple like pacrom, but with the option to direckt launch supported formats (txt, audio, video, maybe roms)

 

[Flavor]

This is a game and media player, not a PC or PDA.

I was under the impression that it ran Linux.

We're talking about making a menu that launches other apps, not a firmware for the GP32, right?

The menu should just launch other apps that will actually do the work. If it's coded right, then users can choose to have a minimal skin or go as far as to have animations in the background and animated icons.