Gmenu2x


ryosaeba

Certified Guru
Joined
May 19, 2006
Messages
421
Age
41
Location
Como (Italy)
Website
mtorromeo.github.com
Hi, this is my first contribution to the gp2x community.

GMenu2X is an alternative frontend for the gp2x.
It is designed to be easy and fast to use, and good looking.

Many features are not yet implemented (it's v0.1) but it's already fully useable.
I installed it on the gp2x of a couple of friends and they find it more useable than the official one (this is its purpose).

Launching.png


Here's the link to the website where you find the downloads and the documentation: http://gmenu2x.sourceforge.net.

I'd like to know what you guys think of it. I dont fear constructive criticism ;)
 
Looks ok but it really doesn't make good use of space. There are still only 6 things on screen to choose from and it is too linear. This means alot of scrolling to get to what you want. It looks PSP ish. Just because the PSP does it like that doesn't make it the best solution though.

A more practical grid like system where you could have multiple icons that can be selected by moving up,down, left, rght would make getting to things faster than alot of scrolling in 2 directions. Plus catagories on the top bar allow you to filter the things that you are looking for. You can also see alot more of what you want on screen with this matrix than just having a strip of 6 items that you have to scroll through and then having a large dead area on most of the screen. Use the space we have to make displaying your stuff and selecting. With the method below you can see 28 items instead of only 6. This way you can see all of your stuff and don't have to scroll alot to see what you want. What you have is just different but doesn't really give any more functionality or show much more items on screen than the default launcher.

There was a discussion about this and the style below was found to make much better use of screen space.

gp2xmenu4.png
 
This screenshot looks nice and includes some elements that I had planned to implement in the future.

In my case there is only one vertical line for links because I needed the space in the middle for a big screenshot but it may not be that useful...

I'll seriously consider of changing the interface to be more like the screenshot you posted.
 
Looks like a very good start.
I'm not into custom menus, so I probably won't try it now. But if someone would manage it to make one like in the pic posted above, and you could easily adjust all the parameters at the bottom I'd put it on the sd now.

So Good luck with this!
 
Ryo posted on Aug 7 2006 at 07:13 AM said:
Hi at this is my first contribution to the gp2x community.
Hi and thanks! I'm glad to see progress on a menu replacement. There was a lot of talk a few months ago but I'm not sure that anything ever came of it. A couple of comments/questions

1. How does this coexist with the current "gp2xmenu" program? The standard code snip at the end of every program restarts gp2xmenu explicitly on program exit. Whether that's a good design is debatable but the fact is that this is how it works. How do you sort all that out?

2. A large fraction of my gp2x activity involves downloading files off the archive and trying them out. If I have to edit configuration files to try each thing I'll never use this menu because it makes my normal use a lot more difficult. If there was a 'scan' command (automatic would be even better but it might not be possible) that can populate a category with all the gpe/gpu files not otherwise specified in a configuration file that would be great. That 'scan' command should jump you right to the list of stuff that was found after the scan finishes. Also nice would be to look for the icon (same-named png file) that would appear in the GPH menu and use that automatically if found. Another nifty feature from that would be to have a way to copy a shortcut (link) from the scan area to the more permanent config files (so when I download something I want to keep I can get it into the config file without editing anything manually)

3. I agree with DaveC that using screen space for more icons (though not necessarily packed 50 to a screen) is a better use of space than the big screenshot.
 
Last edited by a moderator:
Played around with it a little, and I like what I see so far.

I think a auto_script script would be useful. You know something that could be run on the gp2x to build/rebuild the links in apps and games. Shouldn't be too hard to implement.

I agree with daveC that more options on the screen would be great, but I also think the screen shot idea is snazy. Maybe a compromize can be reached between the two.

EDIT:Damn-it Dzz you beat me to it :) acctually we almost have the same Ideas... strange
 
1. I don't like the idea of touching the internal files of the gp2x so I use the autorun method.
It works always for me. autorun.gpu looks like this:
Code:
#!/bin/sh
cd /mnt/sd/gmenu2x
exec ./gmenu2x
You just have to enable autorun on the official frontend.

2. I thought of that too, and even if I not yet decided anything for this matter, I know that it's critical... Your idea seems to make sense to me, if anyone else as a better proposal I'm all ears.

3. Ok, you convinced me :) I'll work on that.
 
Aimless_E posted on Aug 7 2006 at 05:08 PM said:
I think a auto_script script would be useful. You know something that could be run on the gp2x to build/rebuild the links in apps and games. Shouldn't be too hard to implement.
I don't know how that should work, most of the games just run these commands inside of the executable, and after it's compiled you can't do too much. At least I don't know how that would have to be changed.

On the other way, a small utility that replaces the standard menu on the nand ( better said on the gp2x, not on the nand ) with your one and backups the old one. Within the utility could be a option to copy the old one back. And also that will be better for the user than changing all the games/apps on the gp2x. If there's a failure, the user just would have to replace gp2xmenu, else he would have to replace all his games/apps.

And until there's a way to easily add files ( like dzz mentioned ) a custom menu won't be too useful. A scanner shouldn't be too hard actually.
 
Last edited by a moderator:
DaveN posted on Aug 7 2006 at 10:24 AM said:
Aimless_E posted on Aug 7 2006 at 05:08 PM said:
I think a auto_script script would be useful. You know something that could be run on the gp2x to build/rebuild the links in apps and games. Shouldn't be too hard to implement.
I don't know how that should work, most of the games just run these commands inside of the executable, and after it's compiled you can't do too much. At least I don't know how that would have to be changed.

On the other way, a small utility that replaces the standard menu on the nand ( better said on the gp2x, not on the nand ) with your one and backups the old one. Within the utility could be a option to copy the old one back. And also that will be better for the user than changing all the games/apps on the gp2x. If there's a failure, the user just would have to replace gp2xmenu, else he would have to replace all his games/apps.

And until there's a way to easily add files ( like dzz mentioned ) a custom menu won't be too useful. A scanner shouldn't be too hard actually.

Sorry to confuse but I suck at naming things. Dzz's scanner idea and my auto_script idea are the same (in concept) just didn't want to go into explaining it if I didn't have to :).

Ohh and Ryo calls them links instead of scripts. So I change my "auto_script script" idea to "auto_link script" :)
 
Last edited by a moderator:
Would it be possible to write a script that called the speed tweeker program and then returned to this menu program and there for not having to write an over clock script for every program?
 
Someone make a pacroms-like file browser. That is perfect because I can put the fxe files in whatever folder I want and then I just have to put the game's/program's data files in the GPMM folder. I think menus would be better if they were not restricted by catagory or if they are in one huge list.
 
It's actually one of the many features that I have in mind, but I have to set priorities and I gave precedence to other things.

I would like to implement it inside gmenu2x without having to rely on external script but I will consider it better when the time comes...
 
Russ Meyer posted on Aug 7 2006 at 05:17 PM said:
Would it be possible to write a script that called the speed tweeker program and then returned to this menu program and there for not having to write an over clock script for every program?
If I understood it correctly, DaveC's mock-up gives the ability to set the clock speed (and volume, by the looks of it) of the next app to run.
This seems to be an excellent idea, as there's no need for the menu to be at 266MHz ;)
 
Last edited by a moderator:
This is really great so far. It's already a major improvement just in design. Keep up the good work! I too would like one with the ability to display a large number of icons as the amount off applications I have on there grows everyday, so I hope you go down that route :D
 
i like it. perhaps an option in some kind of config screen to put the bar at the top or the side, that way you please everyone.
 
Ryo posted on Aug 7 2006 at 02:25 PM said:
This screenshot looks nice and includes some elements that I had planned to implement in the future.

In my case there is only one vertical line for links because I needed the space in the middle for a big screenshot but it may not be that useful...

I'll seriously consider of changing the interface to be more like the screenshot you posted.


You have to remember that this will be used over and over to launch apps.

The big screenshot may be nice the first few times you see it but after awhile after you get used to it and tired of it and you will just want to see more apps and not some big screenshot taking up most of the screen like a pop-up ad. I think after you load a NES emu a few times you will know what it is without seeing a huge picture of it ;)

The more apps that you see on screen (within reason, 100 would be too much, 28 like my example seems to be a good balance, not too many, not too few) will mean that you don't have to scroll around to see what is on your card and where it is. It is also easier to get to because a grid system is more "random access" and much less serial. This means you can get to the row and column by simply moving the stick in that direction. If you implement scroll wrap it further reduces the number of "moves" needed to get to your app.
 
Last edited by a moderator:
how do i get it to work? it ran, and theres just the vektar icon all along the sidebar and i cant move the bar or anything..
 
@Paradox: you have to create the links for your games, there are samples already with the package and vektar is probably the only one working for you. Check the documentation on the project homepage for info on how to create the links.

@DaveC: I'm already redesigning the interface and it may be difficult to let the title of the link fit in 40/50px like in your mockup. Any ideas?
 
Ryo posted on Aug 7 2006 at 05:52 PM said:
@Paradox: you have to create the links for your games, there are samples already with the package and vektar is probably the only one working for you. Check the documentation on the project homepage for info on how to create the links.

@DaveC: I'm already redesigning the interface and it may be difficult to let the title of the link fit in 40/50px like in your mockup. Any ideas?


If you need such a long title you could have it pop up along the bottom of he screen instead of the CPU speed, battery, memory etc are when you select a certain icon in the matrix. Those things at the bottom now in the example really aren't needed. Short names would be used for the icons like the example.
 
Last edited by a moderator:
Back
Top