Author Topic: gmenu2x file browser changes  (Read 9470 times)

Nebuleon

  • Guest
gmenu2x file browser changes
« on: June 20, 2014, 02:31:26 pm »
Because fceux recently moved (#123) to using gmenu2x's file browser (negating all the work done on fceux's browser, but hey, redoing the same work over and over for different emulators is a chore), and I want to move PocketSNES to it soon, I have a few questions and a preview OPK for you guys to test.

a) Would you say that PocketSNES's file browser for ROMs moves too fast, too slow, or just right?

b) Would you say that gmenu2x's file browser moves too fast, too slow, or just right?

c) PocketSNES can currently display game previews in the background as you select your game. Is this important to you?

In line with questions a and b, I have this OPK for you guys to test. Its button repeat rate, after the first repetition, is closer to PocketSNES's. FCEUX has a slower repeat rate, but it's edit: faster than gmenu2x as released in the 2014-05-05 firmware.

OPK: https://dl.dropboxusercontent.com/u/106475413/temp/gmenu2x.opk

There is a manual describing the test. On your GCW Zero, after getting to /Applications/gmenu2x, press Select and choose Show manual.
« Last Edit: June 20, 2014, 05:40:32 pm by Nebuleon »

Aeter

  • Posts: 328
Re: gmenu2x file browser changes
« Reply #1 on: June 20, 2014, 04:13:08 pm »
PocketSNES' file browser has the right speed, g2x is very slow especially if you have whole romsets on your msd.
I wonder if the amount of roms in a folder also decides the loading speed of the emulators that start out in the rom folder.
Since I use whole romsets I think some emulators start up a lot slower because of the amount of roms that are in the rom folder.
~cucullus non facit monachum~

Nebuleon

  • Guest
Re: gmenu2x file browser changes
« Reply #2 on: June 20, 2014, 05:51:46 pm »
PocketSNES' file browser has the right speed, g2x is very slow especially if you have whole romsets on your msd.
-> I wonder if the amount of roms in a folder also decides the loading speed of the emulators that start out in the rom folder.
Since I use whole romsets I think some emulators start up a lot slower because of the amount of roms that are in the rom folder.
Yes. The time spent enumerating a directory grows according to the directory's contents linearly [O(n)], then the time spent sorting the file names grows as O(n log n).

On FAT filesystems (FAT16 and FAT32), deleted files contribute to the time spent enumerating a directory. It is less efficient for FAT filesystems to delete files than to move them elsewhere, recreate the directory and move files back to it.

On FAT filesystems, looking up a single file by name grows according to the directory's contents linearly [O(n)], exiting fast if it's found. If a file is not found, the entire directory was enumerated to determine this.

If you're using an external microSD formatted as FAT, you will see those two last things happen. The internal memory (/media/data) is formatted as ext4 by default.

mth

  • Posts: 317
Re: gmenu2x file browser changes
« Reply #3 on: June 21, 2014, 01:16:12 pm »
How many files and how much of a delay are we talking about here? The things Nebuleon mentions do make FAT slower than more modern file systems, but unless you have a huge number of files the slowdown due to file system overhead should not be excessive; inefficient application code is another possible cause.

Aeter

  • Posts: 328
Re: gmenu2x file browser changes
« Reply #4 on: June 23, 2014, 07:38:17 pm »
I use full romsets so I kind of expected the delay.
It's been while since I have seen the big O notation put to good use again. Takes me back to those hard but interesting algorithmics course a couple of years ago.

I wonder if it would help a bit if I formatted my msd, which contains all my roms, to an ext4 partition.
Otherwise I might just create alphabetic maps and put the roms in there.
~cucullus non facit monachum~

Nebuleon

  • Guest
Re: gmenu2x file browser changes
« Reply #5 on: July 16, 2014, 03:43:34 am »
Alright, I sidestepped the issue entirely. I have made it so that the button repeat rate is a setting that is available if you press the Start button. The following commits implement this functionality on Nebuleon/gmenu2x-gcw0/master:

commit 5116fca: Fix setting default values for configuration entries.
commit e096f0e: Make the button repeat rate (after the first repetition) a user setting.

The version in the opening post is updated.

howie_k

  • Posts: 157
Re: gmenu2x file browser changes
« Reply #6 on: July 16, 2014, 11:50:59 am »
Excellent - will download tonight.  I think this will really help, as reGBA uses the file browser and takes an age to scroll through the many roms.

Aeter

  • Posts: 328
Re: gmenu2x file browser changes
« Reply #7 on: July 16, 2014, 05:56:11 pm »
Does it also have the same map loading speed as the PocketSNES file browse?
Because the PocketSNES file browser is a lot faster than the gmenu2x one.
~cucullus non facit monachum~

Nebuleon

  • Guest
Re: gmenu2x file browser changes
« Reply #8 on: July 16, 2014, 09:15:07 pm »
Does it also have the same map loading speed as the PocketSNES file browse?
Because the PocketSNES file browser is a lot faster than the gmenu2x one.
You can get 20 repetitions per second max. That's only after the first repetition, fixed at 250 milliseconds, so that you can't get lost straight after pressing a button.

This maximum is maybe 10% slower than the speed of PocketSNES's file browser.

howie_k

  • Posts: 157
Re: gmenu2x file browser changes
« Reply #9 on: July 23, 2014, 10:18:56 pm »
Many thanks for doing this, 20 repetitions a second is very nice - makes paging through roms in reGBA much less painful!

raygan

  • Posts: 158
    • I'm on Twitter and stuff...
Re: gmenu2x file browser changes
« Reply #10 on: August 21, 2014, 10:42:48 pm »
I think the addition of preview images and scroll speed adjustments make the gmenu2x selector browser 98% as functional as the best in-app file browser. Good work, I'm pleased to see this sort of attention paid to little features that can improve the entire OpenDingux experience.

The one thing I do miss from the PocketSNES file browser is the way it returned to your most recent rom as the scroll position when you returned to an emulator. For example, if the last game I played was playing U.N. Squadron, it's a good bet that I'll be returning to that game the next time I launch PocketSNES, and it saved me a lot of scrolling to have it jump right back to that spot. I hope someone can incorporate this into the gmenu2x selector browser.

CSX

  • Posts: 59
Re: gmenu2x file browser changes
« Reply #11 on: August 21, 2014, 11:02:52 pm »
Is it possible to create link in global menu to some exact ROM, so that click on that link would start this game in corresponding emulator?

If it's not (yet?), maybe there is a possibility to create "bundle" opk with emulator and ROM in it?

raygan

  • Posts: 158
    • I'm on Twitter and stuff...
Re: gmenu2x file browser changes
« Reply #12 on: August 22, 2014, 04:01:56 pm »
Is it possible to create link in global menu to some exact ROM, so that click on that link would start this game in corresponding emulator?

I experimented with that a bit and found a simple solution which I describe here:

http://boards.dingoonity.org/gcw-general/adding-rom-shortcuts-to-the-homescreen/

So far I have only been successful with SNES games. NES games dont work with this method, though perhaps someone can have a look and give me a recommendation as to how to fix it. I have not tested with any other emulators.

yonif

  • Posts: 25
Re: gmenu2x file browser changes
« Reply #13 on: October 13, 2014, 09:12:26 pm »
Hi.

Thanks Nebuleon for this great initiative.

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.

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)

In any case, it is important for the system to keep in memory the last item selected.
 
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 put the preview folder 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.
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.)

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.

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)


This is all I see for the moment, but of course I will add some ideas if they come.
Thanks again Nebuleon and all the others developers involved in this wonderful project.
 
« Last Edit: October 13, 2014, 09:43:51 pm by yonif »

Nebuleon

  • Guest
Re: gmenu2x file browser changes
« Reply #14 on: October 13, 2014, 10:39:12 pm »
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

- - - - - - - - -

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.



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? :)

This is all I see for the moment, but of course I will add some ideas if they come.
Thanks again Nebuleon and all the others developers involved in this wonderful project.

Hey, you're welcome!
« Last Edit: October 14, 2014, 12:35:54 am by Nebuleon »

yonif

  • Posts: 25
Re: gmenu2x file browser changes
« Reply #15 on: October 14, 2014, 11:12:09 am »
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? :)


- 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;

This is the best scenario in my opinion. And I think this is better also for the life span of the L/R triggers buttons.

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.


Well I think, in any case, we may have errors in some situations (adding or removing roms in the folders, renaming games, etc.). We are not talking about a table with primary keys here so it cannot work everytime.
I think the best is to use the more simple solution (integer ?) and manage the exceptions (adding a trigger if something is changed in a folder in order to remove/reinitialize the corresponding index, Catch all exceptions when they occur and in then select the first element of the list, etc.).



 
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 (!!).


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.



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) ??


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 ?


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? :)

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.
« Last Edit: October 14, 2014, 11:25:07 am by yonif »

Nebuleon

  • Guest
Re: gmenu2x file browser changes
« Reply #16 on: October 15, 2014, 02:11:41 am »
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.

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.

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.

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.

yonif

  • Posts: 25
Re: gmenu2x file browser changes
« Reply #17 on: October 15, 2014, 10:36:33 am »
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.


I see your point. I did not even think about the fact that we cannot create this kind of name in windows.
So you are right, exclusive hidden folder is not possible.
In that case, having this as a secondary option sounds the good scenario unless you can add an option to not display the preview folder in the list it it exists.


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 agree. Screenshots have to be resized in the right dimensions (320x240) to look good. I also organized my screenshots for ReGBA (so they contain the square box) and I was not so much bothered by what we see around; it looks good.
But again, I agree with you but I think this is really a matter of taste here. That's why I was saying that you should give the user the choice about the kind of display he wants in the settings.


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


I see. I have a question though. I understand that today gmenu2x is using DejaVuSansCondensed-Bold.ttf.
Would it be possible to add fonts (ttf files) in the corresponding font folder and let us the choice of the font we want to use (in the gmenu settings menu) ?


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.


You are right. I did not even think of this issue.
In that case, I would vote for the second solution you proposed:

Quote
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);


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.


Totally agree with this.
« Last Edit: October 15, 2014, 10:57:57 am by yonif »

Nebuleon

  • Guest
Re: gmenu2x file browser changes
« Reply #18 on: October 15, 2014, 09:11:16 pm »
I see. I have a question though. I understand that today gmenu2x is using DejaVuSansCondensed-Bold.ttf.
Would it be possible to add fonts (ttf files) in the corresponding font folder and let us the choice of the font we want to use (in the gmenu settings menu) ?

The GCW skin declares its use of the bold font by using its file name, and is currently the only skin to do so. That's an advanced customisation option; currently it is undocumented, but available to edit in the skin's skin.conf ($HOME/.gmenu2x/skins/NAME/skin.conf) and it must be edited while gmenu2x is stopped (so you can launch the Terminal or something, edit it, and press Start).

You cannot add new fonts to /usr/share/fonts/truetype because /usr is in the rootfs. But, editing the skin.conf directly with a path starting with 'skin:', you can already have skin-relative font files. Edit the GCW skin's skin.conf for an example.

Seph817

  • Posts: 127
Re: gmenu2x file browser changes
« Reply #19 on: October 16, 2014, 03:30:27 am »
If you put a dot before and after the name of a folder in Windows, it works. Does this help?

 

Post a new topic
Post a new topic