Separating "menu driver" and "menu skin"

General Development
#1

Hello,

I know that it’s not on the top of your priority list, but here’s something that I thought about. Currently, there is several “menu drivers”. But when you look at the code, you see that it’s not really a driver. The driver does not drive the menu, it’s RetroArch which tells the menu what to do. It’s not a driver, it’s a skin ; there is absolutely no difference between glui or xmb, except the visual appearance, the options and behaviour are the same.

For me, a menu driver should be a lot more low-level : it should be able to get the inputs directly, read files and folders, edit some parameters and operate stuff on its own (like loading game and core), and not by waiting for RA to populate its entries. I think that it could lead to more diversified menus. For example, Lakka could become more user-friendly and more gaming console-like, by removing some “technical” stuff and being transparent for the user. Because right now Lakka is just a Linux distribution with a beautilul emulator built-in, not a gaming console. It even has to patch RA to work.

Currently the menu driver is the entries system, and the skins are glui, rmenu, xmb, etc. Maybe we could create another system which would allow to replace the entry system with something else (but by keeping the same features), and tho be able, for example, to build Lakka directly in RA without having to patch anything.

What do you think about it ?

#2

There is difference in both form and function between XMB and GLUI, XMB has a contextual menu when games are loaded and will have database integration. The only similarity is that both use the menu_common infraestructure.

You can make a menu driver in any way you want, we dont’t need another layer for this, it’s just faster/easier to use menu_common.

#3

I would still need to edit RA, for example to send the inputs directly to the menu instead of processing them separately. Do you think I could extend the menu_ctx_driver to add an input callback ?

At every input, RA first triggers the callback and look for the answer, if it’s true then it stops there (it means that the menu already has done something) and if it’s false then it continues with the current default behaviour ? This way, a menu could choose to have a special behaviour for only a few inputs and let RA deal with the others (I don’t know if I’m clear).

#4

I don’t really what you mean :stuck_out_tongue:

You can use the command interface to trigger RA actions from a menu driver.

Anyway, we’re still quite far away from a skin system like XBMC / emulationstation have, and that might not be what we’re after, a skinning system will add a lot of bloat and dependencies. Might not happen in that sort of fashion anyway, but the GUI can be extended in several ways, for starters, there is a companion UI interface that can be used with any interface toolkit (there is only a QT proof of concept that doesn’t do anything atm), and there are menu drivers.

#5

I saw the UI system, but I didn’t really understood how it would work for things more low-level than Qt (if I want to embed RA in another OpenGL or SDL application or whatever).

My idea concerning the inputs and the menu was the following ; first we add an input callback into the menu_ctx_driver (like bool on_input(int port, int id, int value)). And then each time RA receives an input :

  • It sends it to the menu driver using the callback
  • The menu does some stuff (or not) and returns either true or false
  • If the callback returned true then RA stops there
  • If the callback returned false then RA continues like nothing happened

The actual menus wouldn’t be affected, and if in the future we want to catch specific inputs in a specific menu then it would be possible using this.

#6

But there are already commands (RARCH_CMD_SOMETHING IIRC) that can be used to perform actions. Most menu actions are implemented like that and if they are not they should

#7

If I want to have a menu which has not the same entries and not the same “logic” as the regular menus, the only way is to recreate everything and capture the inputs, no ? The commands can perform actions, but I need to capture the inputs to navigate through the menu

#8

Oh you mean actually input driver inputs, not inputs as in data input. Yes I guess that could be good.

#9

Okay, I’ll try to do this then. I think that it might even allow Lakka to remove some of its patches, the pause input (or menu toggle i guess) one

#10

You should discuss this on github I guess there is more dev activity there

#11

Yup, I’ll try to make it and create a pull request like i did last times

#12

I agree with you that the menu driver should be in control of the behaviour. For now, they are just “menu display drivers”, since RetroArch call driver everything that is a module without being a core.

#13

Hello, I want to make a new menu just for Android. I saw this post that you want try to make a real menu driver. Could you share any progress with me? Thanks

#14

This is a very, very old post that you’ve brought up there. I’ve since made ozone, a new menu driver, is that what you’re referring to?

#15

Thanks for your reply. I just want to make a very simple menu.