[wyrm]

Garbear,

Both the games menu and the settings menu look like a context menu, so why not just use that. And yes, I'm with Hitcher on the game saves dialog, just use the bookmarks dialog.

Now a thank you for at least asking this time around on skin issues. PVR was just a dogs breakfast because we had a pile of new windows and dialogs dumped on us and no way to see what the screens looked like unless we had a live PVR system to run on. This is the reason why even today support for PVR among skins is patchy, as coding these screens is just a massive PITA and quit often done blind.

Once again I would say the same as Hitcher, if there is a existing window or dialog that looks close to what you need to display, use it. Every time you come up with a 'New' screen its another screen we need to squeeze into our existing look and feel. And also if you really must come up with a new screen, please, please provide dummy files that we can install to show us what we need to be dealing with. Oh, BTW if you use a custom window file from estuary it's basically the same as saying here is a new window file to code, please try to avoid.

Wyrm (AppTV)

[wyrm]

Garbear,

just noticed another thing about the games menu. While it is not a major issue but a stylistic one, there probably is no reason to show the key codes for some of your options in this menu. I mean you are in the menu anyway, so just scroll to the appropriate item and select it. If you don't want to see the menu, you as a user can just use the appropriate key code to bypass showing the menu.

Wyrm (AppTV)

[jurialmunkey]

Yes, once again, +100 on adapting existing dialog windows. Most dialogs would be able to accommodate a few additional controls if need be -- just make them have conditional visibility -- How DialogConfirm handles this for the OK, Yes/No and Progress dialogs works well (it also has dummy window names for each of its variations so skinners still have the choice to have slightly different layouts for each if they wish).

[Gade]

The "Settings" button opens the `Custom_1101_SettingsList.xml` dialog with a new set of buttons.

I agree with wyrm: using a custom window from Estuary, would mean creating a new dialog for all other skins.

Why not simply add Video Settings / Audio Settings / Input Settings / Cheats buttons to the Game Menu instead of the Settings button?
That would minimize clicks - which is something I'm always trying to do.

[garbear]

just noticed another thing about the games menu. While it is not a major issue but a stylistic one, there probably is no reason to show the key codes for some of your options in this menu.

There is a very good reason to show the button combos for the basic options. It tells the user what the combos are, so that they can avoid bringing up the menu in the future. Not telling the user how to control Kodi with a game controller leads to confused users.

I agree with wyrm: using a custom window from Estuary, would mean creating a new dialog for all other skins.

But if I reuse the select dialog, this forces all skins to have a select list for an in-game menu, right? I was just thinking that a skin might want a totally custom OSD for games, but if this freedom isn't worth the hassle of a new window I'm OK forcing the select dialog.

Why not simply add Video Settings / Audio Settings / Input Settings / Cheats buttons to the Game Menu instead of the Settings button?
That would minimize clicks - which is something I'm always trying to do.

Why not add Achievements, Social, Disk control, Debug overlay, and all additional feature bloat to the Game Menu? At some point, we're going to need nesting. And I figured the settings-related stuff was less common that it could warrant a second menu.

[Hitcher]

I agree with wyrm: using a custom window from Estuary, would mean creating a new dialog for all other skins.

But if I reuse the select dialog, this forces all skins to have a select list for an in-game menu, right? I was just thinking that a skin might want a totally custom OSD for games, but if this freedom isn't worth the hassle of a new window I'm OK forcing the select dialog.

This isn't a problem as we can simply use conditional includes to have different layouts for that dialog depending on where it's loaded.

[Gade]

I agree with wyrm: using a custom window from Estuary, would mean creating a new dialog for all other skins.

But if I reuse the select dialog, this forces all skins to have a select list for an in-game menu, right? I was just thinking that a skin might want a totally custom OSD for games, but if this freedom isn't worth the hassle of a new window I'm OK forcing the select dialog.

Well, you might be right.

Will all functions/controls be totally customizable by skins - like VideoOSD.xml and MusicOSD.xml?
Because then I'd absolutely prefer a new GameOSD.xml window.

I kinda like your DialogSelect.xml looking approach though:

[garbear]

I agree with wyrm: using a custom window from Estuary, would mean creating a new dialog for all other skins.

But if I reuse the select dialog, this forces all skins to have a select list for an in-game menu, right? I was just thinking that a skin might want a totally custom OSD for games, but if this freedom isn't worth the hassle of a new window I'm OK forcing the select dialog.

This isn't a problem as we can simply use conditional includes to have different layouts for that dialog depending on where it's loaded.

OK, I'm still learning these skinning tricks. Most of what I need in the near future can be handled by the select dialog. The video filter manager will need some thought. We need a window that can handle a pipeline of filters.

[garbear]

Will all functions/controls be totally customizable by skins - like VideoOSD.xml and MusicOSD.xml?
Because then I'd absolutely prefer a new GameOSD.xml window.

That was my thinking behind GameOSD.xml. Do the bare minimum in code and give skinners complete control. I'm not sure where we should fall on this scale though...

[Gade]

Will all functions/controls be totally customizable by skins - like VideoOSD.xml and MusicOSD.xml?
Because then I'd absolutely prefer a new GameOSD.xml window.

That was my thinking behind GameOSD.xml. Do the bare minimum in code and give skinners complete control. I'm not sure where we should fall on this scale though...

I think I'd prefer that.

But it depends whether the majority of skinners agrees to do a DialogSelect.xml like approach to the game OSD?

[wyrm]

just noticed another thing about the games menu. While it is not a major issue but a stylistic one, there probably is no reason to show the key codes for some of your options in this menu.

There is a very good reason to show the button combos for the basic options. It tells the user what the combos are, so that they can avoid bringing up the menu in the future. Not telling the user how to control Kodi with a game controller leads to confused users.

Garbear, not saying it is wrong to do, just that no where else in Kodi do we show key codes in buttons. We kind of expect that users remember keycodes if they are not using a remote (remember Kodi is first and foremost about a 10' interface). Than and I tend to be a minimalist when it comes to GUI's. Maybe you can set the keycode to label2 and give the skin writer the option of showing the label or not as they see fit.

I agree with wyrm: using a custom window from Estuary, would mean creating a new dialog for all other skins.

But if I reuse the select dialog, this forces all skins to have a select list for an in-game menu, right? I was just thinking that a skin might want a totally custom OSD for games, but if this freedom isn't worth the hassle of a new window I'm OK forcing the select dialog.

just to make sure we are not talking crossed purposes here. To me a select dialog is a file select dialog, that is a list of files and a Ok and Cancel button. A context menu is a list of options. The pictures you showed would appear to just be a list of options, thus a context menu. Also there is no need to have 'Save state' and 'Clear saves' on the same line of the dialog as they are just further options for the user to select, so again just a list of options.

Why not simply add Video Settings / Audio Settings / Input Settings / Cheats buttons to the Game Menu instead of the Settings button?
That would minimize clicks - which is something I'm always trying to do.

Why not add Achievements, Social, Disk control, Debug overlay, and all additional feature bloat to the Game Menu? At some point, we're going to need nesting. And I figured the settings-related stuff was less common that it could warrant a second menu.

Garbear I'm with you on this one. Ordinarily yes, try to keep clicks to a minimum, but it's a setting menu so should only be used occasionally. That and nested menus can cut down on clicks as long as they are used reasonably sparingly. I've always worked on the idea of about 6 to 7 options in a list and then its time to think about a sublist although I have broken that rule on occasions.

Wyrm

[garbear]

Garbear, not saying it is wrong to do, just that no where else in Kodi do we show key codes in buttons.

Yea, and I've observed the keyboard being completely unusable for new users. Pressing "C" for context menu isn't obvious for someone who isn't familiar with GUI developer lingo. Showing the keyboard mapping in the GUI would be a great improvement, let alone being able to change it.

The problem is that this is difficult to do with our existing keymap system. Because the joystick system is much better designed, it can handle the additional complexity.

Maybe you can set the keycode to label2 and give the skin writer the option of showing the label or not as they see fit.

This skinning detail is something I'm actually familiar with <label2> is used in all those screenshots.

To me a select dialog is a file select dialog, that is a list of files and a Ok and Cancel button. A context menu is a list of options. The pictures you showed would appear to just be a list of options, thus a context menu.

I'm still picking up the lingo. I'll keep this in mind.

Also there is no need to have 'Save state' and 'Clear saves' on the same line of the dialog as they are just further options for the user to select, so again just a list of options.

The savestate dialog broke and hasn't been fixed yet. If you'd like to help, you can submit all XML changes to PR11034 .

[garbear]

But it depends whether the majority of skinners agrees to do a DialogSelect.xml like approach to the game OSD?

That's basically the question I'm asking here. Is there any way we can add a new dialog, and fall back to an existing one if it doesn't exist?

[Hitcher]

OK I've re-read this thread a couple of times now and I think we've nearly got everything covered.

Main menu

• New dialog (GameOSD.xml) to make it easier for the skinner to decide the layout - VideoOSD style = literally copy and paste from the VideoOSD.xml

Settings menu

• Context menu

Savestate

• Bookmarks dialog

Video/Audio Settings

• Dialog Settings

Input

• Dialog Game Controller

Shaders

• Dialog Addon Settings (assuming I'm correct from watching the video that they have 2 levels - Shader name > Shader settings)

[Gade]

+1 to the above!