Hidden components under part of the main GUI

[musikBear]

OS win 32 XP
ver 1.0.2
In some circumstances it is not possible to scroll the main-window, so elements that are hidden under the main-top-bar, can be reached with the mouse.
In this picture
http://snag.gy/1liQn.jpg
two windows are opend, the songeditor, and one instrument.
Leftmost: Song-editor is maximized. The slider is in max-pos, but most of the instrument is hidden under the main-top.
Middle: Song-editor is 'floating'. The slider jumps to a new pos, leaving room for additionel scrolling.
Right: The instrument is fully visible, after the scroll-slider is moved to 'new' max-pos.
It is not good that a window can get hidden, if the workspace is maximized (eg leftmost situation)

[tresf]

I experience this often and sometimes loading a project after the software has been loaded. I've assumed they're bugs with QMdiArea but they are too unpredictable to know for sure.

If someone can make this bug reproducible with a series of steps it is much more likely it can be traced to a bug with the software.

[musikBear]

If someone can make this bug reproducible with a series of steps it is much more likely it can be traced to a bug

:/ have been shufling presets and windows for bout hour .. cant find a way to make it happen .. could be a special seqence of open/ close specific windows, that induce it, but the permutation are enourmous ..still trying ..
o-----------o------------o
think i partly got it - it happens if a componet has been maximized, but it also need the problem component to closed and then reopend -It then reopen outside ..sometimes
But more important, i have the solution- If the main GUI has the focus up/dn does not do anything (same for pgUp/dn btw) -So these keys are 'free' to be connected to a 'always scroll all to resp. min and max posistions'. IF that is doable(??), then it means squad whats actually induces it - that would be transparent, because up/dn simply eradicate it. Think this is for 1.1, because its a anoying bug

[Umcaruje]

Reproduced on current master - ubuntu 15.04 x64

Steps to reproduce:

• Open new project
• Maximize the song editor
• Open the TripleOscillator
• Move the TripleOscillator outside the main view
• Click back on the Song editor so it gains focus
• Open TripleOscillator again, it now can't be moved.

Here is a gif of the behavior:

[Veratil]

It looks like a simple solution would be to check the window when show()ing if its y position is < 0.
Adding this to InstrumentTrack.cpp's InstrumentTrackView::toggleVisibility makes it so the window always moves to 0 if it was moved "above" the top of the MdiArea.

if (parentWidget()->pos().y() < 0)
{
    parentWidget()->move(parentWidget()->pos().x(), 0);
}

I don't know if this is always acceptable, as if you scroll down and have windows hidden above from scrolling then it will also be put to "0".

[tresf]

The issue is caused by a maximized song editor window and the only real bug is that the scroll bar vanishes. If you un-maximize the song editor window, the scroll bar comes back as it should. I believe the underlying issue has more to do with the fact that the MDI area can't handle a maximized window and a non-maximizable window.

Bumping the y-coord to zero is fine as long as we aren't mucking with any regular workflow. Perhaps, we start by doing it only when there's a maximized window to alleviate any oddball workspace side-effects of this.

[tresf]

In action:

[PhysSong]

the only real bug is that the scroll bar vanishes.

Sounds similar to a bug which was fixed in cc1cdfa. I can't find the original Qt bug report, but it seems like that hasn't been fixed yet.
BTW, I found one more case when editing the detuning of a note in the piano-roll.