One of the major changes planned for the next release of PCSX2 is a complete overhaul of the gui/frontend, switching from the current "native" Windows/Linux interfaces to a single unified interface that's (more or less) the same for both platforms. To make such a grand vision possible we needed the help of a third party gui tooolkit, from which there were several to choose from. After much consideration we settled on wxWidgets, which is the same toolkit used by a few other notable emulators, such as Dolphin.

So what are the benefits of the new PCSX2 interface in development?

1. A vastly improved Linux interface.

... and not just in terms of what you see, but how the emulator cooperates with the operating system as a whole. wxWidgets provides dozens of very useful cross-platform tools that are much more well-suited to Linux functionality than the current PCSX2 codebase. The new interface will have a smarter plugin loader, and multilingual support as well. It will also be easier to install and run as a user other than root.

2. Windows XP/Vista Themed appearances will finally work!

Until now, PCSX2 used the old Win95 ASCII-based Common Controls libraries, and this forced Windows to disable themes support when rendering the PCSX2 interface. Buttons were plain and unshaded, and dialog boxes such as the File and Folder pickers were small, ugly, and lacking in features. All of this will be fixed in the next release.

3. More complete internationalization support.

Translations of the PCSX2 interface will be easier to make and maintain, and shouldn't become broken or obsolete from program updates, which was a persistent problem in the older PCSX2 interface design. In addition, PCSX2 will be fully Unicode compliant on both Windows and Linux platforms, which should help resolve various oddball problems the emulator may have encountered on non-English operating systems.

4. A more responsive multithreaded interface which will remain fully accessible even while games are running!

The new interface will run on its own thread separate from the emulator's EE/MTGS threads, allowing it to remain open and accessible in the background, without the need to shut down the GS window. This should improve the stability of "pausing" emulation, and also opens the door for expanding on interface integration; such as binding popup menus, toolbars, status bars, or other useful things to the GS window.

Furthermore, if a game deadlocks the system, the interface will usually remain responsive even as the rest of the emulator freezes up (which might not be much of a feature for end users, but is quite handy for us developers).

5. The Teaser Image!

And here's a sneak peek at the current GUI-Work-in-Progress:

... yeah it's not a whole lot to see yet -- I might post some more as development progresses.

---

From a coder's perspective:

In all the wxWidgets experience so far has been a decent one. There are a few annoyances, but those tend to be more the fault of cross-platform considerations (some things are not supported well under Linux, or vice versa), or more commonly due to limitations and design flaws in the C++ language itself rather than of wxWidgets (in particular, C/C++ make it especially difficult to work with unicode strings in a 'nice' way). For the most part wx tries to model itself in the image of the .NET Framework and Java Framework API designs, which are good designs to follow.

Cool, although I personally prefer Qt. When I tried wxWindows (as it was back then) I found it to be very unwieldy (callbacks instead of signals) and extremely badly documented. Perhaps things have changed since then.

Either way, I guess the GUI is a small part of any emulator.

The trouble with Qt is that it would have introduced more than 150 megs of dependencies on the other developers and contributors to PCSX2, and yeah the GUI isn't worth that much headache. One of the things we wanted to retain as much as possible when we picked wx over Qt was the ability to check out from SVN and build PCSX2 with no external dependencies. (GSdx itself requires craploads of external deps these days, but PCSX2 is fairly self-contained).

wxWidgets documentation is still a bit weak, but the 2.9 / 3.0 docs are vastly improved over 2.8/2.6 (and no docs existed prior to 2.6 as far as I know). And the Signals/Slots vs. Callbacks thing is mostly cosmetic. wxWidgets "callbacks" system (as of v2.8 at least) offers most of the functionality of Qt's Signals/Slots. For some things it's more complicated, and for other things a bit simpler. Pick your poison, so to speak. The callback approach in v2.8 does lack type safety on parameter lists, but that's been fixed in 2.9/3.0 with the help of C++ templates.

My only beef with wxWidgets is that "out of the box" it's not very thread safe at all, and it's built in threading tools are poop. And the 2.9/3.0 releases don't appear to help resolve the problem much. On the other hand, common-day things like the Microsoft CRT's assert macro isn't thread safe either (oops?). It's pretty annoying when your emulator deadlocks while trying to display a debug assertion. (I spent some quality time making wxASSERT fully thread-safe for that reason).

Testing out the new UI from SVN; it feels a lot more robust than the last one, nice job.

Quick question though. I can't seem to enable frame limiting as the Video pane in Options is simply blank. Oddly enough, enabling frame limiting in the ini file does nothing either. Frame Skipping via the ini file works though.

Press Tab.

So is the new wxWidgets GUI using wx 2.8 or wx 2.9?

At the moment pcsx2 is using wx 2.8, but im sure it will be upgraded at a later stage.

Most stable linux distros come with 2.8, so we're sticking with that until later. Also, I may not use 2.9 at all and instead jump right to 3.0, which will most likely make its release sometime next year.

(12-06-2009 06:57 PM)Air Wrote:  Most stable linux distros come with 2.8, so we're sticking with that until later. Also, I may not use 2.9 at all and instead jump right to 3.0, which will most likely make its release sometime next year.

Well, considering that wxWidgets 2.9.x is what will eventually become wxWidgets 3.0, it would be good if compatibility with it would be implemented early on.

Also wxWidgets 3.0 seems to be better suited for Win64 building. I personally can't get wxWidgets 2.8.10 to work properly after compiling for Win64, but I did get wx2.9 to work.

With wxWidgets 2.9 offering Cocoa support for Mac side of things, I have been trying to migrate my projects to wx2.9/3.0 early on and track it.

Doesn't matter to me. I know exactly all the code changes I'll need to do to port 2.8 to 2.9/3.0 .. Convert connect to bind, fix a few char* function overloads that wx3.0's wxString handles internally, add some features that I've already marked with [TODO]s .. that's about it. And Win64 isn't any concern of ours for now, and won't be for quite a while yet (a year, perhaps).