Qt/GameConfigWidget: Complete overhaul

[spycrab]

Now using a dual solution where the original dialog is preserved

Features:

• Autocompletion
• Syntax highlighting
• Ability to view all default configs at the same time
• Explanations when selecting config options
• Ability to add config values via context menu

[mbc07]

Could you share some screenshots?

[JMC47]

I think we need the following settings. I'm going blindly so... I'll probably edit this with more as I think of them.

• MMU
• Dualcore
• TextureCache (fast/medium/safe presets)
• EFB2RAM/Tex
• XFB2RAM/Tex
• Per Pixel Lighting
• Arbitrary Mipmap
• Force 24 bit, maybe other enhancements?
• Overclock = (value) - The value of Overclock can be any float, and it acts as a multiplier; 1.0 is 100%, 1.5 is 150%, 2.0 is 200%, etc. We should limit it to 400%
• OverclockEnable = True (or False to disable Cpu Overclocking)
• EFBScaledCopy = True (or False to disable "Scaled EFB Copy") (Why is this in hacks in INIs and enhancements in the GUI?)

[riking]

I like the instanced config menus writing to a different onion layer as the primary solution to game config, but this seems to be an excellent tool for developer-skill users, and also for debugging. Naming the tab something like "Raws" or "Raw Config" and sticking them on the far right might work.

It also neatly solves the problem of "Oops, I screwed around in the per-game config menu too much, and now I don't remember how to set things back how they're supposed to be" / "what does the user click to reset a setting to its default?" -- just go to Raws and start deleting lines.

[Techjar]

@RyanHoudek has made me aware that GameINI supports the new System.Section naming scheme, so you should change it to use that instead of the legacy section names. This would help a lot with phasing out the legacy names.

[JMC47]

So, I've been working with several users on discord since the last argument about this, and there has been some unfortunate problems where they blamed Dolphin for regressions.

This is what the game properties page looked like.

Having an extra layer of protection (a text editor) would prevent confusion where a user thinks their INI is supposed to look like this. Also, damaging settings in Ishiiruka can get carried over into base Dolphin, like settings we've removed from the GUI for a long time.

[BhaaLseN]

Did we shoot down the idea of having both? Checkboxes and stuff for the common/frequent settings, plus the text editor as an "advanced" way of setting other options. The former is more suited for the average end user than a text editor. Or we drop that pane altogether (since most users shouldn't have to mess with those settings) and hide the editor behind the "Edit Config" button (that atm tries to run the global text editor with the INI file).

Also: I'd really like to see settings come from one place instead of many - preferably the main settings in core (there's ConfigInfo<T> instances flying around that should give use close to enough info for generating the menus or whatever it ends up as)

[iwubcode]

After conversation in IRC, I feel the best way to go here would be to refactor our current UI config windows to allow them to be spawned in a game specific context. This allows for easier maintenance because settings don't need to be added/removed in two places, and UI retraining would be minimal.

^ This is what I always saw to be the "future". Of course if we did that, I'd probably rework the way the UI was in general (ex: instead of a game list, you have a game selection and then a UI below with tabs for the various categories, with sub categories laid out vertically).

Otherwise, I think having something like the Winforms 'PropertyGrid' and a way to add additional properties (with descriptions on what they were) would be the ideal way. Maybe a way to fall back to the ini edit approach as a 'power user' solution.

Some of this might fit better in a "future" Dolphin exe like we had for Qt (when WX existed).

EDIT: I will say, from a config ini standpoint, I like what I'm seeing. I need to download and try it out though.

[spycrab]

Had some more time to work on it. Only moved the contents of the context menu into menu bar thus far.

[JMC47]

The green on white is very hard for me to see. Could we use another color that isn't so blinding?

[JMC47]

I like this a lot, it gives more finite control over what settings are on. The old section being there makes the transition easier for users. Seeing the default + custom stuff is pretty cool too, you can see how things are split up.

The multi-INI stuff is confusing, but, I don't think there's a better way to display it.

While there aren't that many options to auto-add at this point, I think that's something we can discuss adding more of later on.

[MayImilae]

Gave it a try. This is absolutely a big improvement in the GUI design for the settings. No more opening the wrong editor and the buttons just not working and other nonsense! Much better. There is a big of a glaring issue though...

The pre-made insertion selection "Editor, Core, Video" are all unmarked buttons in the vein of the file menu in windows or menu bar in macos. Thaaat's a really bad thing to use here. I'm sure you've noticed that the unmarked button style is used exclusively in those places in those operating systems, and everywhere else they use more defined buttons or tiles. That's important! Having text just in a space is really unobvious and unintuitive. Is that a button, or is it text? That is answered by the absolute consistency they use. Any text in a window is always just text, except the file menus in windows, or the menu bar in macos, there and only there, it's a button. It's still unobvious, but by being totally consistent, it kind of works around them. Admittedly that is kind of failing because of all of the other Ui interfaces they've added since and those being more obvious but they have to keep the menus around since they are legacy and also extremely space efficient so they can dump crap into them but, you know, details! Also on macOS the "Editor, Core, Video" buttons don't even light up on mouse over, making it even worse.

So, here is a quick alternative. Just go with a "..." button! Clicking it opens a right-click style menu with Editor, Core, Video, etc all inside, and you can menu chain from there to select options. The hamburger/... button is well trained in users at this point from smartphones, so imo I don't think we'll have any obviousness problems going that route. And it can be made nice and small yet hold whatever we want to add in the future. If you don't want to go the hamburger route, you could also go with a button labeled "Presets ▼" that works the same way, but now doesn't rely on the "..." button training.

[spycrab]

So, here is a quick alternative. Just go with a "..." button! Clicking it opens a right-click style menu with Editor, Core, Video, etc all inside, and you can menu chain from there to select options. The hamburger/... button is well trained in users at this point from smartphones, so imo I don't think we'll have any obviousness problems going that route. And it can be made nice and small yet hold whatever we want to add in the future. If you don't want to go the hamburger route, you could also go with a button labeled "Presets ▼" that works the same way, but now doesn't rely on the "..." button training.

Now using a Presets button.

[MayImilae]

Could you update the screenshot at the start please?

[spycrab]

Added a screenshot

[MayImilae]

Hmm, is it possible to fix the the Presets arrow merging with the second s? Still, it's a definite improvement!

[spycrab]

Nope, the arrow is provided by the button used not by me

[MayImilae]

Well, hopefully it can be fixed somehow at a later date. Since this is an advanced UI, I don't want to hold this PR hostage over a minor visual issue.

That has been fixed and the green color adjusted. Looks good to me!

[lukearnould]

There’s not a Filesystem tab in any of the screenshots, was that tab removed?

Edit: Nevermind, downloaded and it's still there

[HarryTheTurtle]

I'm glad to see an update to the user config per game GUI. I like the updated look but was wondering if the settings could be just radio buttons for simplicity's sake? Just as if a user was checking boxes for the emulation settings for Dolphin but when these per game settings are checked it gets written to the config file that way. No more writing the instructions manually.