Bug 211509 - Interface settings not saved immedtiately
Summary: Interface settings not saved immedtiately
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Unclassified
Component: general (show other bugs)
Version: 2.3-GIT
Platform: unspecified Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
: 198987 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-10-23 09:24 UTC by Michael Liddle
Modified: 2010-06-09 00:51 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Liddle 2009-10-23 09:24:20 UTC
Version:           2.2.0 (using 4.3.1 (KDE 4.3.1) "release 183", KDE:KDE4:Factory:Desktop / openSUSE_11.0)
Compiler:          gcc
OS:                Linux (i686) release 2.6.25.20-0.5-default

This is a new version of Bug #198987, stemming from a discussion on amarok@kde.org "Lost settings on abnormal shutdown" Oct 17/18 2009.

There are a number of settings (in particular interface changes), that, if changed, are not saved immediately, but rather only as part of amarok's normal shutdown process. These are thus lost on a crash and/or other abnormal shutdowns. It was concluded that reasons for this included performance considerations, or simply forgetting to do so. This bug report attempts to collect some of these for fixing. The following don't seem to be saved in 2.2.0:

- Changes to the main window layout (unlock layout -> move some panels).
- Changes to the widgets and/or their layouts.
- Current playlist (performance reasons)
- File view -> view mode (icons or detail list)
Comment 1 Michael Liddle 2009-10-23 09:25:25 UTC
*** Bug 198987 has been marked as a duplicate of this bug. ***
Comment 2 Mark Kretschmann 2009-10-23 09:44:54 UTC
Confirming, as per our discussion on the mailing list. Thanks Michael.
Comment 3 Michael Liddle 2009-10-25 12:40:34 UTC
Add to that list:

- Overall interface "location." E.g. if I'm viewing "local collection" and amarok crashes, on restart it returns to, say, "files" (if files was the active view last time the app was shutdown cleanly).
Comment 4 Mark Kretschmann 2009-11-06 08:30:01 UTC
I've just fixed another part of this bug report:


commit 606a2fd7714f80b820cbe837133accc2e90ec264
Author: Mark Kretschmann <kretschmann@kde.org>
Date:   Fri Nov 6 08:22:10 2009 +0100

    Fix: 1) Resizing borked layout. 2) Layout was not crash persistant.

    I think this is a pretty important fix. This had annoyed me (and probably
    others) a great deal. Now, when you resize main window, the proportions
    of the panes will be kept correctly.

    BUG: 200527
    BUG: 211509
Comment 5 Myriam Schweingruber 2010-06-07 23:45:11 UTC
Is this still an issue with current Amarok 2.3.1 or 2.3.1-git?
Comment 6 Michael Liddle 2010-06-08 08:17:03 UTC
Amarok 2.3.1 from openSUSE 11.2 

- File view -> view mode (icons or detail list)

I couldn't find out how to do this anymore (option removed?). So I guess you could call it fixed...

When running `killall amarok` (i.e. sending TERM signal, but not KILL):

- Changes to the main window layout (unlock layout -> move some panels).
   - Fixed
- Changes to the widgets and/or their layouts
   - Not fixed
- Current playlist
   - Not fixed
- Overall interface "location" (local collection, file browser, etc...)
   - Not fixed

When logging out of the KDE desktop, without explicitly closing Amarok:

- Changes to the main window layout (unlock layout -> move some panels).
   - Fixed
- Changes to the widgets and/or their layouts
   - Fixed
- Current playlist
   - Not fixed
- Overall interface "location" (local collection, file browser, etc...)
   - Fixed

Given that this second instance is the main case where one would expect such changes to be saved, then I'd say this bug is _mostly_ fixed. The exception of course being the current playlist (which, while I understand the performance issues, still seems important to solve somehow).

If you want I can close this bug and open a new one for just the playlist case.
Comment 7 Myriam Schweingruber 2010-06-08 11:25:43 UTC
There already is an open bug for the playlist. Thanks for your feedback.
Comment 8 Oliver Henshaw 2010-06-08 11:43:14 UTC
I think that the problem with the logout case is slow shutdown when part of amarok is swapped out(*). If it takes longer than 10 seconds, the session manager kills amarok.

If so, the reason the logoff case saves more than the killall case is that amarok gets far enough through the teardown process to save the widgets and current location before the kde session manager times out and kills it.

In conclusion, I think that that the killall case is the best test for this bug.


* I have some (sketchy) direct evidence for this through profiling and indirect evidence through improved behaviour after a ram upgrade. I wonder whether putting the swap partition on a different device to prevent swap i/o clashing with file i/o is worth testing.

I'd like to have another go at profiling this but don't have a powerful enough system to explore all the variables.
Comment 9 Myriam Schweingruber 2010-06-08 12:22:34 UTC
Oliver, this bug is closed, please add your comments to bug 227146 which is about the playlist not being saved. This one was far too general, and the layout settings are solved.
Comment 10 Oliver Henshaw 2010-06-08 12:53:37 UTC
Are they? This:

> When running `killall amarok` (i.e. sending TERM signal, but not KILL):
> 
> - Changes to the main window layout (unlock layout -> move some panels).
>    - Fixed
> - Changes to the widgets and/or their layouts
>    - Not fixed
> - Current playlist
>    - Not fixed
> - Overall interface "location" (local collection, file browser, etc...)
>    - Not fixed

implies that not everything is fixed.

(Also note that the bug was closed whilst I was drafting comment #8, an attempt to explain why the bug should not be closed)
Comment 11 Oliver Henshaw 2010-06-08 15:26:51 UTC
So #1 is fixed, #3 is a separate bug. Then the question is: are there existing bugs for #2 and/or #4 or should this bug be re-opened for them?
Comment 12 Oliver Henshaw 2010-06-09 00:51:44 UTC
In case I stumble across this again, the answer is that issues #2 and #4 are due to known limitations in Qt. Thanks to Myriam for clarifying this on IRC.