How to keep parts of a QGraphicsScene in view at all times, when scrolling

[nmather]

Hi all

For a “tracker” style music interface I have a QGraphicsView for entering and editing patterns of notes – I have attached a picture for a visual aid It is not that far removed from a spreadsheet.

Similarly to a spreadsheet, I would like to keep the “TrackHeader” and the “LineNumberColumn” in view at all times (respectively, the horizontal bar with the LEDs, and the vertical bar with the series of numbers).

That is, when scrolling horizontally or vertically, the TrackHeader and LineNumberColumn should stay visible, while still scrolling in one axis (i.e. the LineNumberColumn will scroll through the numbers to match up with the main grid, and the TrackHeader will scroll through the tracks to match up with the tracks in the main grid.)

Currently they both disappear if you scroll, as shown in the second image attached. I need to make them “fixed” parts of the scene in a sense. I wonder what might be the best way to go about it?

Thanks for any advice,
Neil

[marcel]

The best way to do this is to use QGraphicsView::setViewportMargins( left, top, 0, 0 ), where left is the width of the LineNumberColumn and top is the height of the header. Then you should implement the line number and the header as widgets that stay attached to the graphics view ( just like the scroll bars do ).

Thus way scrolling will not affect the two widgets.

[nmather]

Thanks Marcel, I was able to achieve what I wanted using your suggestion.

The two widgets do scroll in one direction each, so in their paintEvents I get the GraphicsView's scrollbar positions and paint the widgets based on this position.

It feels a bit hackish, as the widget has to selectively paint itself based on the scrollbar position; I would rather it didn't have to worry about that, i.e. it just paints itself, and some item "viewing" it decides which portions of it to show. I may try making those two widgets in the margins inherit from AbstractScrollAreas at some point, but it works fine for now

[mr.costa]

I believe it would be much better to buid that with a Model/View, subclassing TableModelView to make custom painting.

[nmather]

Hi mr.costa

That occurred to me too, but two things stopped me trying it:

a) The central area has quite a lot of paint operations and moving items, as well as area selection -- I wasn't sure if doing all that in widget paint events would be efficient (Would be a problem?)

b) I'd already done most of the work in a QGraphicsView, so had a legacy system to contend with!

Someday when I get time to go back to it I want to try different methods with it.