Bug 218268 - Akregator does not restore previously set window size
Summary: Akregator does not restore previously set window size
Status: RESOLVED WORKSFORME
Alias: None
Product: akregator
Classification: Applications
Component: general (show other bugs)
Version: 1.5.1
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 246994 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-12-11 13:53 UTC by Thomas Werner
Modified: 2012-11-25 11:22 UTC (History)
7 users (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 Thomas Werner 2009-12-11 13:53:41 UTC
Version:           1.5.1 (using 4.3.1 (KDE 4.3.1) "release 6", openSUSE 11.2)
Compiler:          gcc
OS:                Linux (i686) release 2.6.31.5-0.1-desktop

When clicking the Akregator symbol in the symbol tray, the window always opens with its default dimensions. Any changes that were previously applied to the window size are discarded.
Comment 1 Joel 2010-03-07 21:57:59 UTC
Same here, with KDE 4.4.1 and Akregator 1.6.1 (under ArchLinux).
Sometimes the windows is restored at its previous size, but most of the time it is restored as a tiny windows at the upper left corner of the screen.
Comment 2 Emil Beli 2010-05-11 16:11:18 UTC
1.6.3, kde 4.4.3, problem remains. Closing it to tray and restoring it back, it contiunes on default small size. Does not remember neither it size, nor it's state (maximized or windowed)
Comment 3 Matthias Fuchs 2010-06-06 21:52:00 UTC
That is interesting as I can neither repoduce this with trunk (what is to become 4.5) nor with 4.4.3.
Comment 4 Urs Wolfer 2010-12-16 13:42:27 UTC
I think this issue only exists when there are multiple screens available. I can reproduce it with a multihead setup all the time, but not when the 2nd screen is not attached to the same computer.
Comment 5 Urs Wolfer 2010-12-16 13:43:53 UTC
*** Bug 246994 has been marked as a duplicate of this bug. ***
Comment 6 Andreas Sturmlechner 2012-06-17 14:13:42 UTC
Same here with KDE SC 4.8.4. It didn't matter as long as I was using it embedded in kontact, but since I run akregator independently (so if one of the kdepim applications crashes it doesn't tear down the whole suite...) this is terribly annoying. None of the other kdepim applications have that issue.

My setup consists of a 1440x900 notebook, lid closed, external 1900x1200 screen attached.

It doesn't even choose some kind of default value - I watched akregatorrc during startup and the sane setting from last program exit gets overwritten with very stupid values.

- delete akregatorrc [MainWindow] section to start from scratch
- start akregator, akregatorrc: Width 1920=584
- resize akregator to something like 1200 (akregatorrc changes accordingly)
- exit akregator or 'close' to systray (nothing happens in akregatorrc)
- fire akregator up again and watch akregatorrc dumbing down to Width 1920=357

Similar things happen to the Height setting. And it always comes down to those same values written above...
Comment 7 Andreas Sturmlechner 2012-06-17 14:57:55 UTC
Disabling the LVDS panel on my system makes the bug go away. That's no viable workaround though.
Comment 8 Andreas Sturmlechner 2012-06-23 10:10:55 UTC
Correcting above post, disabling the smaller LVDS panel helps when working on the big screen.

However, I was now able to reproduce the behaviour during mobile use too. akregatorrc will, at start or when raising it from systray, always reset to 'Width 1440=584' and 'Height 900=600' because of the existing entries for 1920 and 1200. After deleting those lines, and only after really quitting akregator once, window size now stays correct on the laptop screen.
Comment 9 Andreas Sturmlechner 2012-07-22 11:54:59 UTC
Bug also exists in KDE 4.9 RC2
Comment 10 Andreas Sturmlechner 2012-08-13 07:32:00 UTC
Now, since the update to KDE + PIM 4.9 the problem seems to have been resolved! And I didn't delete any config file since the last tests to do anything about it. Maybe someone else could confirm too, anyway I will keep an eye on it and report back if it should happen again.
Comment 11 Andreas Sturmlechner 2012-08-18 11:43:37 UTC
A few days later I think it is safe to say that this is finally solved. :)
Comment 12 Maarten De Meyer 2012-11-25 11:22:47 UTC
(In reply to comment #11)
> A few days later I think it is safe to say that this is finally solved. :)
Closing.
Thank you