So here are my findings from the latest version:
1) Layout
a) I tried all skins from the current CFW and most of them have a link height of 65. We shouldn't use link height from the skin config in the new design as most existing skins look odd with more than 40. Making this configurable must have been a workaround, so that longer link names are still shown in the old layout. The link height should be calculated like this: max(icon height, height of two lines of text) + 8 for padding. For normal font sizes this should always give 32+8=40, so that you can fit 6 items in 240 pixels. This would make all skins working without changes.
For now I'll change the property from linkHeight to linkItemHeight. Not the best solution, but this allows quick compatibility with current skins and if someone want to go back to old GMenu2X, won't need to change every skin.conf again.
I'm still trying to find a good way to position 2 lines of text on the right side of the icon. Different fonts have different "anchors", then when trying to position aligned to top, middle or bottom, some will look good, others will behave strangely.
Still a WIP.
b) When using skins that do not have listBg set (all existing skins atm), there is a default value set for listBg (light grey). This breaks the design of most skins as everything gets too bright and white. I'd rather use a default of #ffffff00 so that the look of every skin is similar to the old layout. If people want to get the exact emulation station design with dark and light grey they need a new skin anyway (wip!).
Done.
c) To get that emulation station design with a dark grey area on the left and a light grey area on the right we really need a second font color. Using the outline to keep all existing skins compatible is a good thing, but there should be an optional second font color supported (light grey or white text on dark background).
No solution yet, but it is in my to-do list.
d) At least in the extended selector, we should leave out the file icons and only show the folder icons. Its redundant and uses precious horizontal space.
I like the symetrics with file icons, but I understand your point.
e) Probaby too complicated to solve and it's there since the beginning of gmenu2x, but anyways: Changing skins results in overlapping main menu items (2 items drawn at the same position). Restarting gmenu solves this issue. Like if some skin settings (linkHeight) are only applied when gmenu is started.
Will investigate. But no fix expected soon.
e) Minor layout issues:
- position of the battery or sd icon is a little bit off
Fixed. (see image attached with spacings)
- description of the app in the extended selector overlaps the list
App description should be smaller.
Does it needs to have "Emulator" after every description?
I'll add a clip rectangle in that area. Text will be clipped, as there's no way to fix this.
2) Main menu navigation
Since all items are listed vertically now, we need something like next/prev page like R/L in the selector (emulators list is quite long). As R/L are already used for sections, we could use dpad r/l for that or even change sections to be changed with dpad r/l.
This is already in my to-do list. Code is almost done. Will page up/down with left/right.
3) Previews
a) Most images are not shown, only 1 or 2 out of 20 in my test. Even a image that was shown a few seconds ago doesn't show up when I go up again in the selector. The only image that showed up in my lynx folder was transparent. This means that there could be a bug in the code for the fade-in effect so that images just stop at 0% alpha.
This is one of drawbacks of coding to a device I don't own. Code is working fine in my dev setup. I'll investigate and will need help to test it and try to isolate the problem.
b) Setting 'selector screenshots' in the link settings to '.' and having the preview images in the roms folder works. Shouldn't it be possible to set a path like './previews/'? Other than an absolute path this would still allow multiple rom folders for one emulator (gb/gbc or md/bin/gg).
I don't like the idea of having a hardcoded path, but I think allowing relative paths in selector screenshots is a good idea. There are some limitations, but I'll see what can be done.
Thanks for your feedback. All points have been noted.
