Dingoonity.org

We were discussing this also among developers, but your post has some very specific problems and their possible solutions that we will definitely look at.

Note that I've done some behind-the-scenes work about some things already, which is awaiting inclusion upstream (on qi-hardware). After this discussion, I will probably make some more code adjustments, and a second preview version as an OPK. Here's some of the user-visible changes in my work:

commit c649e24: Merge code from Selector into BrowseDialog (has a much longer description than this)
commit ee482ae: Get rid of the action on D-pad Left in BrowseDialog
commit 914b415: Use the last file name selected for a LinkApp as a hint in Selector
commit d0b54bb: Initially select the current wallpaper in WallpaperDialog

- - - - - - - - -

I will definitely have a look on this. This looks like very professional

Now that that's presented, I'll reply to your post. Because separate quotes would extend the height of the post a lot, I'll reply inline in pink, and your post is in the default color.

I would like to share some ideas about gmenu2x.
I will try to give my feedback from a user experience perspective only.
How I see this to be more user friendly, more intuitive.
Also, I would like to apology by advance because my english is not the best.
I am from France and you know how bad english speakers we are here.

Browsing roms
I think use of triggers is not convenient or confortable.
It is simple in my opinion to use only the dpad to navigate : up and down, right and left to navigate by blocks + a ".." item at the top to go to the top folder.
At the same time, I can understand that it can also be painful to go at the top of very huge list in order to get back to the upper folder.
So let's say we use up and down + the triggers R and L buttons.
OK. why not? So today how the left and right buttons are used ?
I notice left is used to go the upper folder, very good, it looks like on a windows explorer.
So I expect the right button to let me enter into the folder.
But no, it does not do anything. This is annoying, left and right are not working as an opposite action.

Yeah, I also noticed that inconsistency. In my work up there, you can see that I removed the action on D-pad Left, freeing it up for an action more consistent with a new use for D-pad Left/Right.

So what I think, we have two possibilities :
- only the dpad to navigate, very convenient but forcing the user to go at the top of the list to go the upper folder
- use the current way of working but enter into a folder when pushing right on it (like file explorer on windows and mac)

What I was thinking, was either:
- have D-pad Left/Right do page scrolling, and have L/R be used for horizontal scrolling of cut-off names;
- have D-pad Left/Right do page scrolling, have automatic horizontal scrolling of cut-off names (with a setting for how fast that is) and have L/R unassigned;
- have D-pad Left/Right do horizontal scrolling of cut-off names, and leave L/R assigned to page scrolling.

But I think page scrolling needs to be held for more time than name scrolling usually, so maybe having the d-pad do page scrolling would be best. Opinions please?

In any case, it is important for the system to keep in memory the last item selected.

Yep. And because keeping only the "index" into the list of files is pretty crashy and bad for other reasons, I made it keep the file name as a hint for later. See even more of my reasoning in commit 914b415: Use the last file name selected for a LinkApp as a hint in Selector.

 
Preview screenshots:
This is a very nice feature. I can imagine that we will soon find Game titles set for each system (for goodgen and no intro formats).
The first issue I can see is that we must the folder preview in the folder that contains the roms.
Unless it is possible to put this preview folder as hidden (.preview), - I did not test this - we can see the folder in the list so the preview folder is quite "polluating" the list.

That's a very good idea, and I didn't even think of that. There's already a way to do it (previews/NAME.png), so I'd avoid breaking that needlessly. But introducing a dot-directory would hide things by default in FTP managers too, so it'd be confusing to those who just made a .previews directory and see it disappear (!), or can't get back into it later (!!).

So instead, how about allowing both previews/ and .previews/ and look up a file in either of those two? (For completeness, if a preview is in both previews/ and .previews/, the one in previews/ has precedence, because it's the most clearly visible directory.)

The screenshot when it is there is not automatically resized to fullfill the screen. So it is not very nice looking.
Perhaps, it could be nice to offer this option in the gmenu2x for resizing previews files (fullscreen, original size, zoom, etc.)

hi-ban instead had another idea. Because showing a preview as the background of gmenu2x is bad, he wanted to show a separate preview-pane. Maybe you'd like that better.

Showing the preview as a background was a stop-gap measure. It's bad because either you have a super busy preview as your background which prevents you from reading the text, or you blend the preview with the wallpaper and people complain that it's not clear enough (but then it'd be too busy for them to read the text).

Compare these screenshots with partial and full alpha. Below is the preview-pane idea, mocked up by hi-ban.

My favourite one is the first one (colourful and sexy) but I think this one could be improved by using a bold fond.
I understand people who tell that this it is not readable enough but I guess this is really a matter of contrast.
The background image should as transparent and clear as possible but at the same time should be identified instantaneously.

Hi-ban made a great job with his mock-up but I think, again this is my opinion only, this scenario is not ok for the GCW.
This is perfect for a big screen like a tv (hyperspin front end, etc) but not a small screen like the one for the GCW.
Why? Because of 2 reasons:
- You lose the half of the available space for the list of rom names, so you will always have to make the name scroll to see the end of it (except if the left and right button are used to move an horizontal scrollbar).
- You have only half of the screen for displaying the preview (like the box art) and it is very small.

Of course, someone else will not agree with the way I see things so why should not you propose some options (in the settings menu) to choose the way the previews are displayed ? We could for instance change the font used for the list of names, choose to display it in bold or not ? etc.
For me, what happens sounds similar to the Steve Jobs Calculator construction set story  Instead of trying to find the perfect solution, that will fit the expectations of all of us (good luck ), give us the tools to build what we want !

Gmenu2x Theme:
When I run an emulator, the gmenu2x file explorer is called and displayed. This is nice, but it should nicer if the gmenu file explorer could have a "skin" to match with the emulator front end UI.
It should have for instance this background image which was used in the previous file explorer (the red and black SNES artwork) displayed for all the files with no preview file in the preview folder.
As it is now, I always feel that I enter and leave from the emulator and this is not pleasant.

I really don't know about that one. Either:

a) each application is updated to have a background for its own gmenu2x file browser (which is a bit bad because it ties applications with a specific resolution - which will be odd when HDMI is available); -or-
b) you have a new dot-directory in your internal memory and you associate backgrounds with applications by name matching (but because I update PocketSNES with date-stamped versions, and some other developers also do that, you'd have to rename your file once in a while);
c) why not just leave it like it is now, and have the wallpaper the user chose there? he or she likely chose it specifically for how not busy it is;
d) ??

Long filenames:
About the very long names, I do not know how it works now but I hope when we select a very long name and we wait with this item selected, the file explorer display the end of the name (with a scrolling or a popup)

I wanted to clean up code before implementing name scrolling. gmenu2x had different code for the Application Explorer/File Dialog/Wallpaper Dialog/Icon Dialog and the file selector brought up for applications. Now name scrolling can be implemented just once and apply to all of them, but I still don't know if we should have automatic name scrolling at 60 FPS with the ghosting we have on our screen, or lower FPS, or manual name scrolling (and with what button). Opinions please?

Quote from: yonif on October 14, 2014, 11:12:09 am

Quote from: Nebuleon on October 13, 2014, 10:39:12 pm

That's a very good idea, and I didn't even think of that. There's already a way to do it (previews/NAME.png), so I'd avoid breaking that needlessly. But introducing a dot-directory would hide things by default in FTP managers too, so it'd be confusing to those who just made a .previews directory and see it disappear (!), or can't get back into it later (!!).

My opinion is to keep a hidden folder only. I understand your point regarding the FTP tools but they usually provide an option to display the hidden folders and files.
I think we need to educate the users with those concepts and learn them how to use the tools the right way.
The wiki page could be the right place for this.

I will disagree.

There has already been a release where previews/ was accepted, and it was even in the release notes. If that is taken away, it will be considered a regression (with its fair share of "but I carefully organised my previews, why it not works any longer?").

As for external microSD card setups, you cannot create a directory or file starting with a dot in Windows. Right-click a folder somewhere on C:, go to "New" and "Folder" (or "Text Document"), and try to name it ".previews". Windows Explorer will complain that "You must enter a file name".

I see the exclusive use of .previews/ as unworkable. I would agree to having it as a secondary option.

Quote from: yonif on October 14, 2014, 11:12:09 am

Quote from: Nebuleon on October 13, 2014, 10:39:12 pm

The screenshot when it is there is not automatically resized to fullfill the screen. So it is not very nice looking.
Perhaps, it could be nice to offer this option in the gmenu2x for resizing previews files (fullscreen, original size, zoom, etc.)

hi-ban instead had another idea. Because showing a preview as the background of gmenu2x is bad, he wanted to show a separate preview-pane. Maybe you'd like that better.

Showing the preview as a background was a stop-gap measure. It's bad because either you have a super busy preview as your background which prevents you from reading the text, or you blend the preview with the wallpaper and people complain that it's not clear enough (but then it'd be too busy for them to read the text).

Compare these screenshots with partial and full alpha. Below is the preview-pane idea, mocked up by hi-ban.

My favourite one is the first one (colourful and sexy) but I think this one could be improved by using a bold fond.
I understand people who tell that this it is not readable enough but I guess this is really a matter of contrast.
The background image should as transparent and clear as possible but at the same time should be identified instantaneously.

Hi-ban made a great job with his mock-up but I think, again this is my opinion only, this scenario is not ok for the GCW.
This is perfect for a big screen like a tv (hyperspin front end, etc) but not a small screen like the one for the GCW.
Why? Because of 2 reasons:
- You lose the half of the available space for the list of rom names, so you will always have to make the name scroll to see the end of it (except if the left and right button are used to move an horizontal scrollbar).
- You have only half of the screen for displaying the preview (like the box art) and it is very small.

Of course, someone else will not agree with the way I see things so why should not you propose some options (in the settings menu) to choose the way the previews are displayed ? We could for instance change the font used for the list of names, choose to display it in bold or not ? etc.
For me, what happens sounds similar to the Steve Jobs Calculator construction set story  Instead of trying to find the perfect solution, that will fit the expectations of all of us (good luck ), give us the tools to build what we want !

I will agree with the loss of available screen space, and for the increased need for name-scrolling due to having fewer pixels of width to show a part of names.

However,

• The appeal of hi-ban's proposed interface as in the third screenshot is to look good with a wide range of box art ratios. Full-screen previews as in the first screenshot "look colourful and sexy" as long as they're full-screen 4:3. Have a full-screen preview for any other system than the SNES, and everything looks ugly again. You'd have a partial wallpaper showing around games for the Game Boy, Game Boy Color, Game Boy Advance (square box), NES, Genesis/Megadrive (tall box), and any CD-based system including the Playstation (square box).
  

• I believe it is the best solution to avoid the mixing of a user-chosen background (for which, if it's too busy to read text, it's the user's fault) and an arbitrary preview (for which, if it's too busy to read text, it's not the user's fault) over the text of the file names and the button hints at the bottom of the screen.
  

As for allowing bold and stuff, gmenu2x doesn't even have a concept of a bold font, only a font file which happens to be bold (the GCW skin declares its use of DejaVuSansCondensed-Bold.ttf directly). Desktop systems have fontconfig and X font servers, which can give hints as to which font file is a variant of which font face, but we don't have that. I'll let another developer elaborate on this, though.

Quote from: yonif on October 14, 2014, 11:12:09 am

Gmenu2x Theme:
When I run an emulator, the gmenu2x file explorer is called and displayed. This is nice, but it should nicer if the gmenu file explorer could have a "skin" to match with the emulator front end UI.
It should have for instance this background image which was used in the previous file explorer (the red and black SNES artwork) displayed for all the files with no preview file in the preview folder.
As it is now, I always feel that I enter and leave from the emulator and this is not pleasant.

[...]

And why do not use a default preview file (default.png ?) in the same preview folder which would be displayed if no preview file is found for a game ?

Because once you leave the directory containing default.png (or leave the parent directory of a previews/ folder containing default.png) you've lost the styling you wanted to apply to the selector to make it look, for some reason, as if you were still in that emulator.

b) you have a new dot-directory in your internal memory and you associate backgrounds with applications by name matching (but because I update PocketSNES with date-stamped versions, and some other developers also do that, you'd have to rename your file once in a while);

Quote from: yonif on October 14, 2014, 11:12:09 am

Automatic scrolling with option to choose the speed but also and more important how many miliseconds before the scrolling starts is the best in my opinion. No use of L/R buttons for navigation.

Long names are simply cut off right now. And I'd rather not implement a popup, because while you see one full name, you don't see anything else. Having agreed with name scrolling above, I'd rather implement that than a popup, also because:

• your eyes are already at the end of the name, vs. having a popup that shows the ending of each file at a different place due to word wrapping (see Spritz fast reading for example); and
• you can choose a new file more quickly if it's the wrong one: you can just use the d-pad, vs. having to remember which button is for the name popup instead of selecting the file, then pressing that, then exiting the popup.

Having a setting for the scrolling speed and automatic scrolling delay, like we have right now for button repeat delays, would be good. Having another setting for automatic versus manual name scrolling would be good too. That would accommodate fast and slow readers, the ~10 millisecond ghosting we have on the LCD, and those who want to see the end of titles without having to use buttons other than D-pad Up/Down.