Linux and OS X support

Linux and OS X support is definitely important, although until now it's not been enough of a priority to have much active development dedicated to it (since that time has been limited). There are other debuggers whose primary focus is linux/OS X support, such as vogl that you should also check out.

As it stands, the core codebase (the renderdoc project) compiles under linux, and OS X support shouldn't be too hard past that I'd hope. The main problem is the UI (and of course more mature OpenGL support but that's platform independent).

Currently the UI is written in C# using winforms. In theory this configuration is supported by mono on linux and OS X. In practice this won't just magically work and will require some work to support.

The UI code is separated from the main renderdoc project where the guts of the code live, so it really is only the presentation layer that needs to be handled - this at least limits the amount of code that is problematic.

There is going to be a bunch of work required no matter what for a cross-platform UI, and there are two main ways to go:

Port with Mono

We would work with mono to get the UI working on non-windows platforms. This will require working around functionality not implemented already in mono (doesn't seem to be that much in this camp), and re-implementing anything that relies on windows specific functionality e.g. through P/Invoke.

The two main components that will need to be updated I suspect are ScintillaNET and dockpanelsuite. Scintilla works on these platforms so getting the .NET wrapper to work shouldn't be impossible and I think will be a manageable task. However the docking suite will be more work. I believe the current state of support is that everything should work except for user drag-and-drop. Personally I think this will need to be improved and implemented, but I don't have much appreciation for how big a task that would be to implement. This also means maintaining this support and working around any future issues that come up.

Pros

1. The existing UI will remain, we can continue to use C# to rapidly develop the UI and take advantage of the ease of development it provides over C++.
2. You will (hopefully!) get a consistent UI across all platforms.

Cons

1. I don't believe C# development will ever be as smooth on other platforms as it will be with windows/visual studio - this is pretty much by design. Although not an insurmountable obstacle it hampers development on UI-related features by developers on non-windows platforms.
2. Unknown really how much work it will be to get the UI working, or how well parity can be achieved.
3. I suspect that even with mono, the experience of using a winforms program will not be as pleasant as a natively written program (or a program written with an intentionally cross-platform toolkit).

Write a new UI in another toolkit in parallel with the existing UI for windows only

The most likely choice here seems to be Qt and C++ but I'm open to suggestions. I don't know much about Qt, so this option is kind of unknown to me also. Please chime in if you have any experience or input on this.

Pros

1. It allows focus from each side on the platforms where they're best experienced, without having to compromise the linux UI for windows or vice-versa.
2. Developers on non-windows get a comfortable experience both in terms of a user of the program and those developing it.

Cons

1. Development is now split between two UIs. Functionality in one doesn't necessarily translate to the other, user experience will be different and the projects may diverge. Likewise it imposes more of a burden on developers as they need to make sure not to break one while working with another.
2. Users on windows using the native windows UI won't necessarily feel comfortable with the cross-platform UI and vice-versa, unless a concerted effort is undertaken to keep the UIs closely in sync - and such an effort may hamper ideal development.

Write a new UI in another toolkit and drop the existing UI

Same as the above, but rather than parallel development of two UIs, we declare that the Qt UI is the definitive UI and drop the existing UI in favour of it.

Pros

1. You are guaranteed a consistent UI across all platforms, and better than the mono option as the toolkit used is intended for cross-platform dev so you get a closer to native experience on each platform.

Cons

1. We lose the rapid development and ease of use of C# if we go for C++. Perhaps there's an alternative to Qt + C++ but I'm not sure I'd want to use anything else - shout up if you think there's an option that's as easy for dev as C# but is cross-platform!
2. Windows devs no longer get the ease of use of being able to develop on the UI from within visual studio with the form designer etc.
3. Again speaking from inexperience, I'm not sure that a Qt written UI will match the winforms UI, and so this would lead to a regression in user experience on windows. If we can get close enough then I don't think this is an issue, but it has to be weighed up.

General Todo

• We use -Wno-error=format because of the messed up ecosystem of string formatters that microsoft caused.
  1. On MSVC %s in a wprintf means wide and %s in a printf means narrow.
  2. On GCC/clang %s always means narrow, %ls always means wide
  3. On MSVC %ls is explicitly wide and %hs is explicitly narrow
  4. Sadly, on GCC/clang %hs throws a -Wformat warning. Currently we use %hs/%ls to be explicit and avoid porting issues, but it causes these warnings.