Feedback Required - What benefits are there to the WxWidgets GUI

[8times9]

Hey,

I realize that the pull request to remove Wx has already been merged but I thought I’d still share some feedback.

I’d say that on Windows Qt and Wx have an equal feel of polish, but on macOS there are a small handful of UI issues that make the emulator feel less polished than Wx. I’ve reported these issues here:
https://bugs.dolphin-emu.org/issues/11236
https://bugs.dolphin-emu.org/issues/11184
There are additional issues I will report as soon as I have access to my Mac.

These issues, while small, make Qt on macOS feel unpolished enough for me to prefer the former Wx backend.

[JMC47]

Thank you for your feedback. Honestly the Qt frontend is so much newer that it is honestly less polished in areas, and we'll continue to work on it to get it to the point where it surpasses Wx in every single way.

[8times9]

(06-30-2018, 12:15 PM)JMC47 Wrote: Thank you for your feedback. Honestly the Qt frontend is so much newer that it is honestly less polished in areas, and we'll continue to work on it to get it to the point where it surpasses Wx in every single way.

One other thing that I preferred in Wx was the mapping window for emulated GameCube and Wii remotes. It was compact and had nice indicators for when buttons were pressed. In Qt the mapping window is huge! There is a lot of empty space in-between the buttons. The indicators are also way bigger than they should be and don’t look as good as they did in Wx (less consistent coloring, etc). On smaller screens (laptops etc) the mapping window comes close to filling the entire screen.

[spycrab]

(06-29-2018, 03:36 PM)Mavi Wrote: -TAS input windows do not allow simultaneous use of the original controller (Standard Controller, possibly others). This is grossly inefficient for TAS work, and the number one reason I'm still using Wx.

There are PRs that work on fixing this. Expect it to be resolved in the next couple days.

Quote:-Analog stick inputs don't center correctly by default in the TAS windows. While the choice of 128,128 over 127,127 (GCC) and 512,384 over 511,383 (Wiimote IR) is perhaps somewhat arbitrary, Dolphin otherwise still treats the former values as the default center and there are certain third party devices that operate with 128,128 centers by default. The interface should maintain these conventions for consistency.

Fixed in Dolphin 5.0-8277

[Mavi]

Looked over the PRs on Github. The proposed checkbox still looks cumbersome at first glance - my understanding is that it's all on/all off. For example, I couldn't use real buttons + TAS directionals simultaneously. That's still unnecessarily tedious and inferior to the previous implementation. Any chance of having any "activated" TAS inputs override controller inputs + a hotkey to clear those inputs and return full control to the controller?

Additional remaining issues/suggestions/criticisms from my previous post as of -8277:

Quote:-Wiimote orientation values are all 0 by default in Qt... X/Y were conventionally 512 each, while I believe Z depends on sensor bar placement? (Z on my rig defaults to 616)

-Input windows should not remember inputs when closed and reopened.

-Aesthetic criticism: L/R sliders take up unnecessary space in standard/GCC windows. The previous, more compact implementation was better and more intuitive (vertical sliders 0 high/255 low to match hardware behavior).

[spycrab]

(07-03-2018, 06:57 PM)Mavi Wrote: Looked over the PRs on Github. The proposed checkbox still looks cumbersome at first glance - my understanding is that it's all on/all off. For example, I couldn't use real buttons + TAS directionals simultaneously. That's still unnecessarily tedious and inferior to the previous implementation.

Does this behave more like you'd expect it to?

[Mavi]

Yeah, that's pretty much how it works in Wx from what I can tell. In fact it's slightly better, since the TAS windows in that build seem to handle live controller polling more gracefully.

[spycrab]

Please try the latest version of https://github.com/dolphin-emu/dolphin/pull/7203.

[Mavi]

Sorry, how would I go about doing that? I'm not super familiar with Github, and I can't seem to find how to download a complete build for a PR commit.

[addestroyer]

Assuming you're on windows, this is the latest build from the PR https://dl.dolphin-emu.org/prs/pr-7203-dolphin-latest-x64.7z.

Last I checked, I think you have to be signed in to github to find the builds from that, but once you're signed in they show up in a list at the very bottom, and you find the builder for your OS, click details, then there's a link to the uploaded build in the list of tasks.

Otherwise, I guess the next best options are to build it yourself, or browse the buildbot history and try to find the correct build, which would probably take a while