Grab bag of remaining Qt issues

[baldurk]

A few people have asked me about having a central location for pending Qt work, particularly things that people could contribute.

At the time of writing, there are large chunks of the UI that aren't finished, and so they are deliberately omitted from this list. This list is more about small things that people can pick up and fix without worrying about conflicting with in-progress work.

Not all of these are critical must-fix issues. Some are necessary polish before the Qt UI may replace the C# UI, some are important but could conceivably be fixed after that point, and some are 'would be nice'.

QTreeView/QTreeWidget

• Uses of QTreeWidget should be removed in favour of QTreeView and a home-grown item model. We basically need exactly the same as the default item model, but not as bad - e.g. for batching updates, supporting row background colours, things like that.
• Setting the background colour of rows in QTreeWidget is tedious and in particular very very slow. To change a row colour you have to loop over all the cells in the row, and each time you change a cell's brush it fires an event which causes recalculation of all column/row dimensions to fit contents. This quickly becomes noticeably laggy.
  There's a hack in EventBrowser to pause events during the update then force a refresh, but this needs a proper solution - see the first point about making our own standard model that doesn't suck.
• When the tree column isn't left-most there's a rather ugly gap in the highlighting
  
• Add grid lines which help readability in many of the uses that are half-table half-treeview.
• The tree column cannot be rearranged with respect to the others.
• If the last section is set to stretch its contents, it can't be resized from the left (in the default layout of the event browser with EID, Name, Duration, try resizing the duration column from the left).
• Better resizing for tree widget columns. Something like size hints, but with minimum suggested size for content. At the moment there's nothing between Stretch resize mode (which can leave lots of whitespace) and ResizeToContents which is very tightly packed.

ToolWindowManager

Currently we're using ToolWindowManager as the docking solution. The other main alternative is Advanced Docking System which is better in some ways, worse in others. Right now the focus is on fixing issues with TWM rather than switching, but if ADS becomes more capable then it shouldn't be too much work to change.

• Middle clicking on tabs doesn't close them.
• The close order for tabs doesn't work based on selection history. If you close a tab then the next one immediately to the left is activated (or right if the tab closed was leftmost). Instead it should activate the previous active tab - and so on and so on.
• When multiple panels are docked in a floating window, you can't dock that whole window into the parent by dragging the title bar, you have to drag the 'tab bar', or each panel individually.
• When only one tab exists for a given docking area the title bar shouldn't still be a single tab, instead a fixed title/handle kind of thing.
• Currently when there are several options for where to drop a panel, there is a timer which cycles through every option for a few seconds each. Instead there should be no timer but specific locations where you drop for each option. This also ties into the next item...
• This is a big one - the previews of where you're going to dock suck. There are no overlays over the area where you're docking, there's only a hacky rubberband preview for some drop locations. There should be a shaded transparent overlay over drop regions, as well as icons to be able to denote where you want to drop:
  
• The default sizing decisions when dropping in a new panel aren't very good, but this is a hard problem to define exactly how they should work.
• There's no auto-hide/pin mode. In VS and other docking systems, you can 'pin' a panel to one side of the screen, and it will minimise to just a little tab and appear on hover.

API Inspector

• The little callstack separator needs the text "Callstack" and some dots drawn on it to indicate that it can be resized up and is in a 'collapsed' state by default.
• Double clicking the callstack separator should toggle it between collapsed and not.

Event Browser

• Shortcuts are missing - Ctrl-f, Ctrl-g, etc.
• Bookmarks are not implemented.
• Missing previous/next drawcall buttons and shortcuts.
• The event browser (or more accurately the capture context) doesn't generate fake profile markers to delineate sections of the capture writing to the same targets when there are no markers in the capture. The algorithm doesn't have to change, this just has to modify the drawcall and event list.
• The find behaviour isn't quite right - clicking away from the find tool box loses it, and it doesn't remember the last search when you open it up again.
• Missing export functionality that was added to the C# UI.
• The duration column doesn't update when the unit is changed.
• If there are markers with colours specified, the event browser doesn't apply these markers. This has to support both whole-row colourising as well as colourising the tree-view lines to outline the markers.
• Missing column selection popup. This is complicated due to the problems with QTreeWidget/QTreeView above and column re-ordering or not having the tree in the first column.

Pipeline State

• No custom-rendered pipeline flow tab-select.
• On D3D11 there's no support for launching compute debugging - this is a simple one.
• Export to HTML is not implemented.
• Tooltip popups for view details in pipeline state should appear immediately instead of having the normal tooltip behaviour, since these aren't "optional additional explanation" but more like "expanded information.

Main Window

• Help menu options aren't hooked up - like opening github, documentation, etc.
• In the main window help menu there's a missing 'tip of the day' type dialog which shows some helpful tips.
• Update checking isn't implemented for release builds.

General

• Many places are lacking tooltips, particularly in toolbar buttons where there's only an icon.
• The general config setting for preferring a monospaced font over variable width font where possible is not currently applied.
• Several places in the UI are missing popup menus/right-click context menus, like the pipeline state for show empty/show disabled, the buffer viewer for the toolbar context buttons, and other places.
• There are many cases in the UI where we want a copy-paste handler for copying data out from selections, like the event browser, texture viewer, buffer viewer, constant buffers and pipeline state (not an exhaustive list).
• For those feeling adventurous, it would be interesting to see how well the UI could be localised into another language. I've tried to use translation markup where I should, but I haven't tried yet actually generating a localisation setup.
• Likewise, Qt provides the ability to theme the whole UI. Most likely there will be at least two custom themes shipped with the application - a default 'light' theme that is unified across all platforms (native look will not be the default, but can be an option), and a 'dark' theme. If you fancy trying your hand at an application stylesheet feel free, in worst case it can be added in a contrib folder for people to try.

Capture Dialog

• The checking for correct installation and fixing of the Vulkan layer checking should be moved from renderdoccmd into the core DLL and exposed to the UI to use.
  The registry checking will need to be moved into C++ too to match. I think the best place for this would be vk_linux.cpp and vk_win32.cpp, and these would just be forwarded to from the replay layer.
• Environment variable editor isn't implemented for changing or adding environment variables when capturing.
• The virtual file dialog used for browsing remote hosts is completely custom. It seems like the Qt file dialog is a perfect fit, just with a different model on the back of it to provide remote data. This would be perfect... except QFileDialog makes a lot of assumptions and is hugely coupled to the internal model it uses. If this could be fixed, it'd be a great improvement.
• Global hook is not implemented on Qt.

Shader Viewer

• We don't yet support invoking external disassemblers for the shader viewer/shader editor.
• Scintilla doesn't come with a Find/Replace dialog. Since we need to be able to search/replace across multiple files ideally we'd want a single dialog that can do the usual thing of acting only on a selection, the current file, or across all files.
• The shader viewer toolbar button for adding snippets for custom shaders isn't implemented.
• When editing a shader we want Ctrl+S to save and update the shader. Unfortunately there is no way to do this currently since Ctrl+S is already a global shortcut for save capture. Ideally we somehow want to 'bubble up' from the focus widget, with each widget having a chance to process the shortcut before passing on to its parent. Currently though the Ctrl+S is swallowed and goes nowhere if there's a conflict.
• When debugging we want tooltips over registers both in the source itself and the watch/registers windows, to show the registers interpreted as different types (float / int / hex)
• There's no register friendly naming as that was done in the UI itself. It should instead be done at disassembly time.
• Editing a shader that doesn't have debug info and original source doesn't currently generate stub HLSL for shader editing. It would be nice to actually generate this at disassembly time and take a crack at a very rough decompile step a la SPIRV-Cross.

Buffer Viewer

• There's no save functionality in the buffer viewer, to save either to csv or to raw bytes.
• The buffer viewer can't launch vertex debugging yet.
• The buffer viewer doesn't support choosing the position and secondary components to display in the preview, and so also doesn't highlight which component is currently being used for position.
• No handling currently of primitive strip restart in indexed draws.
• Calculation of bounding boxes is not implemented, and so the auto-fit button does nothing. The calculation of the bboxes might have to be threaded since iterating over all data might be too slow to happen synchronously. If it is threaded, take care not to run into synchronisation problems if events change faster than the thread can calculate and cache bounding boxes.
• The vertex and index columns in the mesh view should be 'pinned' so even as you scroll horizontally they remain in view
• Columns in the buffer viewer are currently split per component and all equal. Instead there should be a column per component in the data, with a joint header that spans all components in a single element.
  The merged header would have just a single name that is left-aligned to the visible header (much like happens in the C# UI, it would start left aligned but as you scroll horizontally to stay in view until there's no more room).
  These element headers would then be separated by a gap for clarity.

Texture Viewer

• Custom shader editing needs to be implemented for create/select/delete and launching the shader viewer to edit.

Pixel History

• In the pixel history treeview we want only the little boxes to indicate expand/collapselines in treeview in pixel history

Timeline bar

• Needs to be re-implemented from the ground up.

If you want to have a go at any of these, reference this issue in your commit and I will check off the task.

If I add anything new, I will post it in a reply as well as adding it to this original issue, so everything will be in the same place as well as notifications for those interested.

[ratchetfreak]

Setting the background colour of rows in QTreeView/QTreeWidget is tedious and in particular very very slow. To change a row colour you have to loop over all the cells in the row, and each time you change a cell's brush it fires an event which causes recalculation of all column/row dimensions to fit contents. This quickly becomes noticeably laggy.
There's a hack in EventBrowser to pause events during the update then force a refresh, but this needs a proper solution - probably in RDTreeWidget. Maybe a standard proxy model to handle background colour changes?

You can use the BackgroundRole in AbstractItemModel::data() to return the custom background color for a cell. Then you can emit a single dataChanged(firstRow, lastRow, {Qt::BackgroundRole}) signal every time you change a bunch of cell colors.

[baldurk]

Yes that one is a bit inaccurate, I'll edit it. It only refers to QTreeWidget where the underlying model is inaccessible and it emits dataChanged for every individual update.

I think the solution is to just drop all uses of QTreeWidget, always use QTreeView, and write a replacement for the default model so that all of the 'simple' cases that just need to shove in some strings won't have to write a whole model each time. I've already subclassed many of the widgets to add extra events/signals, but rewriting the tree widget model is a bit more involved.

[ratchetfreak]

Tooltip popups for view details in pipeline state should appear immediately instead of having the normal tooltip behaviour, since these aren't "optional additional explanation" but more like "expanded information.

You can call QToolTip::showText explicitly on mouseEnter for the relevant widgets

The vertex and index columns in the mesh view should be 'pinned' so even as you scroll horizontally they remain in view

you can make the column of indices a header

[baldurk]

Thanks, I appreciate the notes. I think the tooltip is a little bit more complicated as the only widget is the treewidget, so we'd need to handle mouse move events and track the currently hovered item, and also handle hiding/showing it to force it to move when you enter a different item.

To clarify though, this list is about tracking the tasks that need to be done in case anyone wants to address some of them. Most of them have fairly clear implementations and e.g. for the pinned columns there's even a qt example with source to do exactly that.

If someone wants to take on something and needs feedback/help that's of course on-topic here.

[dkapnopoulos]

Just to let you know guys, I'm working on the API Inspector callstack separator. It should be ready by the end of the weekend

[dkapnopoulos]

I almost finished the Tips of the Day dialog(layouts are killing me :P). I saw on the C# UI that the tips are generated automatically. Do I have to take care of something?

[baldurk]

Ah don't worry about that part. I have something to generate the tips and update the web version to avoid redundancy.

Just copy-paste the data over and update the code part however makes sense, I'll update the generation template next time I add more tips (which I don't do as often as I should...).

[dkapnopoulos]

I was playing around today and saw that resizing of the Texture viewer has a lot of flickering. Also ToolWindowManager does not have anything to separate the different widgets. Thus, I inherited from the ToolWindowManager, overriden the createSplitter and returned the new RDSplitter(I also fixed a bug there). Also disabled opaque resize to avoid the flickering. Would it be nice to add that?

[baldurk]

On mine there is a gap between panels in the texture viewer, the main difference to the existing UI that makes it feel a bit too bare is that there's no border around the panels so it's just empty space instead of being better delineated.

I think that kind of issue will be addressed when I make a custom theme to apply to fix little issues like that and make sure the UI looks consistent everywhere (at the moment it inherits some of windows 10's awful flat UI stuff on win10). I don't think it's worth trying to replace the splitter right now as it might not be needed, and you'd need to make it render differently to how it currently does (currently it's designed to draw the eye a bit which you wouldn't want here, and the arrows don't make much sense in either case so they'd need to be toggled off).

The flickering is new to me - there's not really any more flickering than I'd expect for a continuously resizing/repainting widget. Can you record an animated GIF or mp4 of what it looks like before and after your change?

[dkapnopoulos]

On mine there is a gap between panels in the texture viewer, the main difference to the existing UI that makes it feel a bit too bare is that there's no border around the panels so it's just empty space instead of being better delineated.

This is what I tried to fix. But with the UI theme is will be perfect.

The flickering is new to me - there's not really any more flickering than I'd expect for a continuously resizing/repainting widget

There is not so much flickering in release mode. But I believe with disabled opaque resize it will be nicer, like in the current C# GUI

[baldurk]

I'm not sure what this gif is supposed to show, that's why I suggested a before and after to be more clear about what's actually changing.

[dkapnopoulos]

Here it is the comparison. Not a big deal though. But the "after" is how the C# GUI works right now.
Before:

After: