Skip to content
baldurk edited this page May 10, 2014 · 3 revisions

The problem

Currently the UI (renderdocui) is written in C# using .Net/winforms to do everything. While this is theoretically portable with mono even if that was practical it would result in a UI that no-one would want to use outside of windows.

The solution

The current UI will be replaced by a new UI. The new UI will be developed in parallel as the current UI is maintained, until a point when it's equal and the current UI will be deprecated.

The main choice to make is the windowing toolkit.

Qt

Qt RenderDoc UI Notes/TODOs/thoughts/etc

Qt seems the most popular and mature cross-platform UI toolkit. It supports everything that we should need to replicate the renderdoc UI.

Building Qt on windows might need a bit of fiddling, but provided that we make a convention of committing generated C++ files it should only require that people install the Qt libraries/headers to build against, and otherwise everything can be built within visual studio. Modifications to the UI can be done from qt-creator separately if desired.

Some notes from @matiasgoldberg:

There are two steps to compile a QT project:

  1. The MOC. The MOC takes files in QT's ui language and translates them to ordinary cpp files. You'll need QMake for this (which comes with QT libs). For compiling this on Visual Studio, you either need a cmd prompt to manually launch QMake, the QT5 plugin for Visual Studio, or QTCreator (which comes with QT libs anyway...)
  1. The regular C++ build process.

Note that the MOC step is needed when files affected have changed (i.e. you changed a few headers using QT extensions like signals and slots; or the UI files). But if you commit the autogenerated (moc'ed) files to the repo; the first step can be avoided entirely by your users (i.e. they can download, compile and run).

wxWidgets

I don't know much about wxWidgets, I haven't used it in close to a decade, but it's an alternative to Qt even if it's not the more popular choice.

Arguments in favour of wxWidgets can go here :).

Thoughts on this from @matiasgoldberg again:

To be honest I prefer wxWidgets, using wxFormBuilder to create the UI (takes a little while to understand how it works, but there are video tutorials in youtube which are awesome to "get it") because it gives lower level access; which is preferred when you're dealing with a tool like RenderDoc (embedding D3D/GL mixed with UI widgets). Also Qt tends to mess up with the Windows' message queue system, so the only way you can manipulate it is by hooking with a listener to Qt's own message queue processing.

QT's threading system is also a nightmare and IMO poorly designed (although Qt devs think otherwise).

On the other hand, al QT apps I've seen are extremely easy to compile (just open in QtCreator, hit compile, you're done); it's so good to the point you'll doubt if this is C++; Also QT has more cross platform functionality than wxWidgets (i.e. dealing with config settings, networking, printing, multimedia, etc; they both provide functionality but often Qt's a bit more complete).

Clone this wiki locally