[Jeroen]

Shader Browser: DialogSelect
Shader Editor: DialogAddonSettings

My thoughts exactly.

+100

No more additional dialogs, expand on the existing ones if necessary.

And how an OSD or any other part for that matter is laid out is up to the skins.

[RockerC]

What about the idea of making each shader into its own add-on for Kodi and as addons they could then use the existing work for add-on settings UI?

That way you could also make use of Montellese settings library for shader add-ons as well.

See https://github.com/xbmc/xbmc/pull/12125 and https://github.com/xbmc/xbmc/pull/12062

And if all shaders was an individual addon then they could also be upgraded seperatly outside Kodi's regular release cycle, like all addons for Kodi.

Also checkout https://github.com/xbmc/xbmc/pull/12202 and https://github.com/xbmc/xbmc/pull/12208 and https://github.com/xbmc/xbmc/pull/12259 and https://github.com/xbmc/xbmc/pull/12259 as well as their other fellow binary addons patches.

"This add the first parts of gui related addon callback parts to new style. There becomes standard functions and the dialogs added. On next request comes the controls list item and window."

"This add the minimum parts to create a window on addon. This still mostly equal with the Python addon window parts."

The patches are part of the still ongoing Binary Addons and GUI settings rework being done for the upcoming Kodi v18 (Leia):

https://github.com/xbmc/xbmc/pulls?q=is%...+Addons%22

These is just now begining to be merged into mainline too and as such are still very much work in progress so right now you can get your feedback and suggestions on changes or additions in early.

[garbear]

For reference, here's what RetroArch's in-game menu looks like:

[velocity]

With all due respect to RetroArch devs, I don't think we should take ideas from its UI at all. Ideas about options/funtionality yes, but nothing design-wise.

Its UI/UX is quite terrible in my opinion and it's actually not just me saying it, RetroArch is generally regarded as having an ugly and confusing interface.

It honestly looks like it's programmer-designed with not much thought put into it, it's not very visually apealing - and perhaps most importantly - it's anything but user friendly.

EmulationStation on the other hand is much nicer looking, in my opinion:

https://www.youtube.com/watch?v=AVQVmsFOclM

[garbear]

How about something simple like this?

[nexusle]

Is this Thread only for ingame control UI or also for the database view? Or is there another thread about the database view for games/retroplayer?

[garbear]

Only for in-game control. The database view is called "library mode" and depends on a game library, which is in development but still many months away. If you're looking for a library mode, I recommend checking out the IARL thread.

[Jeroen]

It's unclear to me what is being dicussed / what is being asked / expected? Are we supposed to create some designed by committee default UI ?

Maybe it's because I'm not up to date with the ins and outs of this, but seems to me the proper way to deal with this is to let skins take care of the UI.

[Martijn]

It's unclear to me what is being dicussed / what is being asked / expected? Are we supposed to create some designed by committee default UI ?

Maybe it's because I'm not up to date with the ins and outs of this, but seems to me the proper way to deal with this is to let skins take care of the UI.

the point here i think is skinners need to suggest how it be implemented the best way. After that the skinners can go their own way to adjust how it looks in their enviroment. However you need to have some solid groundwork

[Hitcher]

I think I speak for most of us in saying we should use the currently available dialogs/windows as much as possible and not make new ones as this just puts off a lot of skinners.

[garbear]

Maybe it's because I'm not up to date with the ins and outs of this, but seems to me the proper way to deal with this is to let skins take care of the UI.

Do you see the chicken and the egg problem I'm working with? Skinners take care of the in-game UI, but there has to be a UI to take care of Unless a skinner steps up, it's my responsibility to create the Estuary UI, and like martijn said, I would love to lay some solid groundwork according to the wishes of skinners.

I think I speak for most of us in saying we should use the currently available dialogs/windows as much as possible and not make new ones as this just puts off a lot of skinners.

I was told the same thing about the controller window, but the reality is that games might require a fundamental break in Kodi's existing UI paradigms.

For example, games currently use the VideoOSD.xml window, and look at how poorly the video OSD suits games. It's ok if a video plays in the background, so the OSD should be minimally intrusive, but the second a UI element covers a game you want the game to PAUSE. So a game OSD can be much more intrusive.

That said, my primary goal is skin reuse, so I would like skinners to offer pictures or ideas of existing elements they've created that can be re-purposed for an in-game UI. I'll post my current progress to give an example of the kind of windows and dialogs we need.

[velocity]

How about something simple like this?

Yeah I like this OSD style. Classic, intuitive and simple.

Some thought needs to be put to which options are presented (and by extension, which are hidden behind a menu) and in what order.

As a user I'd expect "Stop/Exit/Quit" to be the last option in the OSD, for instance.

---

That said, it could perhaps be extended with side views based on this suggestion:

I'd leave out "Stop", because maybe someone accidently hits stop and all game progress is lost. The stop-button can be there if (IMHO):
- the game autosaves on "Stop"
- the game can be resumed from the autosave

How about only a "Pause" button, which opens a dialog:
- Stop game without saving
- Save game and stop
- resume game

Left side:
Save:

• State
  
• Savegame
  

Load

• State
  
• Savegame
  
• Reset Game (not sure about a extra button for this)
  

Cheats
Settings

• Shader
  
• Netplay
  
• Controller ooptions

Or maybe it would be best to keep it simple and include everything we want in one list/dialog and the rest hidden in another Settings menu.
What do you guys think?

[garbear]

MOTIVATION

EmulationStation: Here's the main window, which I don't think can be shown in-game.



RetroArch: ugly and confusing



RetroArch's deprecated RGUI: sexxxy



PROGRESS

When the user opens the in-game menu, Kodi pauses the game and loads `GameOSD.xml`:



The "Saved games" button opens a saved game manager, which doesn't exist yet. I'm using the bookmark manager as a stand-in, and yea...



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




"Video settings" opens the existing `osdvideosettigns` window which uses `DialogSettings.xml`. We'll need a new window here for configuring shaders.



"Audio settings" opens the existing `osdaudiosettings` window which also uses `DialogSettings.xml`:



"Input settings" opens the controller dialog, which uses `DialogGameControllers.xml`.



Comments? See any areas for reuse? Can you think of any windows or dialogs we're missing?

[Hitcher]

Are (or could) screenshots made when making a savestate? As this would be ideal if you stick to using the bookmark dialog.

[garbear]

Are (or could) screenshots made when making a savestate? As this would be ideal if you stick to using the bookmark dialog.

This is what the saved game manager looked like back when it was working: