Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#143 get rid of the default maximized view

open
nobody
None
5
2013-09-28
2013-08-08
alex
No

who had the bright idea to maximize the app without actually maximizing it?

how much apps do you know that maximize their screens by calculating the screen size, then resize to match?

what do you think is the function of the Maximize button?

can you understand how IRRITATING it is for a user to click the Maximize button (assuming it will RESIZE an APPARENTLY maximised window, so that the window can be moved around) and then realise that the window will remain in the same size?

PLEASE UNDERSTAND HOW IRRITATING THIS MISCONCEPTION OF YOUR IS.

Discussion

  • Chris Cannam
    Chris Cannam
    2013-08-27

    Hi, Alex.

    Despite your unpleasant and inappropriate tone, I would like to help you. But this is not a complete enough bug report.

    Can you please follow up to explain what behaviour you are seeing, what actions you carried out that produced that behaviour, and what behaviour you would expect instead?

    Please also include the SV version number and details of which platform you are using.

    Thanks!

    Chris

     
  • alex
    alex
    2013-08-27

    OK. Platform = Windows 7.

    One thing I didn't mention is that this annoyance happens in two cases: (1) after the installation (which is still odd because the initial setting should be something like 2/3... but read on), and (2) when quitting after maximizing the window.

    Addressing case (2) requires to refine the code:

    The app should also store the QWidget::windowState(); when restoring the QSetting, if flag Qt::WindowMaximized is set, the window should also be maximised (or probably simply restore the retrieved QWindowState) (QWidget::setWindowState()). When the user will then resize (toggle the Maximise button) a Maximised window, it will still resize correctly to some earlier chosen (or initially defined) size.

    The window size QSetting should only be updated when the window is resized, not when the window is maximized. The app should never remember the maximised window SIZE, except if the user wants to maximize the window manually - that's a user issue.

    Therefore the app should update the QSetting size whenever (and only when) the window is manually resized (rather than upon MainWindow::closeEvent()); the app should also update the window setting flag whenever toggling in/out of Maximized state.

    Maybe (Qt 4.2?) QSettings::setValue("windowState", QMainWindow::saveState()) could be used - I assume this also includes the window QWindowState.

    Case (1) was a mystery until I understood (2): a result of my earlier installed versions plus (2) plus I almost always used the app in its maximised state. Initially I was wondering what was wrong with your view of the Maximise button, until I saw what caused the bug - so I replaced an extensive follow-up rant with an extensive follow-up code review...

    Test procedure:
    1. Manually resize the app to occupy 2/3 screen estate
    2. Maximize the app by clicking the Maximize button
    3. Close the app
    4. Open the app
    5. Observe that window and its Maximize button are in Maximized state
    6. Click the Maximize button and observe the window is now in the size selected in step 1.

    Repeat the test to demonstrate that a resized (non-maximized) window is also correctly restored.

    rgds,

    -alex-

    [1] (Aug 27, 2013) http://code.soundsoftware.ac.uk/projects/sonic-visualiser/repository/entry/main/main.cpp#L365

    PS - consider documenting why, on a small screen, the window is made even smaller: 'if (height < 450) height = (available.height() * 2) / 3;' - e.g. is this to "protect some area in case of really small screens"?

    PS2 - Another issue: it's not obvious where the code lives now - took me a bit to find out about http://code.soundsoftware.ac.uk ...

    PS3 - see also https://sourceforge.net/p/sv1/bugs/181/

     
    Last edit: alex 2013-09-19
  • Chris Cannam
    Chris Cannam
    2013-09-20

    Should be fixed in commit c0a20cd1a9ff (http://code.soundsoftware.ac.uk/projects/sonic-visualiser/repository/revisions/c0a20cd1a9ff)

    The behaviour is still not quite technically correct, because state is still only saved on exit -- but now it saves the geometry only if the window is not maximised, and restores it only if the saved state was not maximised.

    This behaves correctly except in the case where you maximise, exit, restart, and un-maximise -- when you get the last saved un-maximised geometry (from the last time you exited un-maximised) rather than the geometry from immediately before you maximised on the last run through.

    I am fairly confident that most people would never notice the difference between this and strictly correct behaviour, but I'd accept a patch from anyone who disagreed.

     
  • alex
    alex
    2013-09-20

    Does the suggested test procedure pass?

     
  • Chris Cannam
    Chris Cannam
    2013-09-20

    Not quite, because (as above) the size you get in step 6 is that from last time you exited in an un-maximised state, or the default size of the app if you have never exited it in an un-maximised state before.

     
  • Would it not be possible to capture the window geometry values into variables, updating them every time the geometry changes, and saving that values when exiting, instead of directly capturing the window state only on exit?

     
  • alex
    alex
    2013-09-28

    I think that is what I write in paragraphs 5 and 6.