Closed schneider42 closed 3 years ago
As I'm using xmonad as my window manager I got concerned that this is might be an issue with my setup. I tried again with the standard GNOME 3 that comes with Ubuntu 18.04 and 20.04.
On GNOME 3 I was able to reproduce this issue by minimizing the window to the task bar and then restoring it again.
I dug a bit deeper in to the chain of events and this is what's happening:
PlotView::viewportEvent()
gets called with QEvent::Type(WindowDeactivate)
PlotView::viewportEvent()
gets called with QEvent::Type(Leave)
PlotView::viewportEvent()
gets called with QEvent::Type(Hide)
PlotView::viewportEvent()
gets called with QEvent::Type(Show)
PlotView::scrollContentsBy()
gets called with dx
set to the amount the scroll bar was moved before hiding/minimizing the window.
horizontalScrollBar()->value()
and horizontalScrollBar()->maximum()
evaluate to 0. It looks like something internal to Qt changed the scrollbar between the calls to PlotView::viewportEvent()
and PlotView::scrollContentsBy()
.PlotView::updateView()
gets called by PlotView::scrollContentsBy()
. It resets the maximum of the scrollbar back to file length - window size. The original value of the scrollbar is lost though.After discovering this I had a look at what QGraphicsView
(a parent class of PlotView
) offers but found nothing which I figured would immediately solve the issue. It looks like QGraphicsView
is used a bit outside its original intention as it expects a QGraphicsScene
as its content?
I thought that one function might be interesting to get more insight into the issue and I implemented PlotView::showEvent()
simply for debugging purposes. Thing is: that solved the issue.
Simply implementing an empty PlotView::showEvent()
was enough to fix the issue on xmonad and GNOME 3.
Whenever I open a file in Inspectrum and perform one of the following actions, the horizontal slider is set back to 0 (i.e. the leftmost position):
Similar to #170 I've collected a log of what happens to the application: