-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idea for your new “per display” layout parameters #436
Comments
Hi, I agree with Progets. This would be an excellent addition. |
FYI - I wondered why the end of my post was in italic. I can now see that my use of the asterisk before ".nut" and after "/layouts/" in the last line of the post was the cause. Does an asterisk need to be escaped somehow? |
Sorry, I removed my latest post and tried to contact you via PM instead but I was too late. This discussion would be more fit for the forum or using PM. |
OK, I thought it was a pm sent somehow and replied using e-mail. I removed my previous reply. |
Ok I think I've got this one, it should be fairly straight forward to implement, but might have to work a bit differently in the UI due to the limitations of the config menu system, I'll see what I can do I think I've finally got the per_display parameters ready to go so they should be checked in soon and I will look at having the layout file configurable. |
…ayout config - if a layout has multiple layout*.nut files, the user can now set which one to use from the layout configuration menu - this provides another way to switch the layout file (previously you could only change using the 'toggle layout' control) - also a small fix when configuring key controls for layout-specific inputs. When user presses the 'back' button the control will now be cleared as intended
I see that you mention "when i get some time i’m going to look at implementing “per display” layout parameters" here #432. I assume that you mean that each display listed in the attract.cfg will be able to store the layout options separately vs. all layouts with the same name using the settings typically appended to the end of the file. I think it's a great idea and a way to prevent needing multiple layout folders to accomplish the same thing.
My idea works into this concept and would include an option to choose the specific .nut in the layout directory. This function exists today but only using a key/button to cycle through the .nut files and I don't think you can actually see which .nut file is being used anywhere (this can be confusing). By having an option to choose the .nut file per display in the menu will allow complete layouts to have different .nut files for a Displays Menu vs. an Arcade Menu vs. Console Systems, etc. while all using one layout folder (and one set of art assets) with little confusion.
I think this could work the same way that choosing a layout from the Display Menu does today. It would be an option directly underneath the Display Menu layout option and it would cycle through .nut files like the the layout option cycles through /layouts/.
The text was updated successfully, but these errors were encountered: