Bug 128512 - LO Base incorrectly remembers position and size of its windows
Summary: LO Base incorrectly remembers position and size of its windows
Status: RESOLVED DUPLICATE of bug 41777
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.3.2.2 release
Hardware: All Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-31 15:46 UTC by Christian Lehmann
Modified: 2019-11-13 07:28 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Lehmann 2019-10-31 15:46:56 UTC
Description:
LO Base remembers the window an ODB file was last shown incorrectly and does not remember at all the position of the window that a certain form of that file was last displayed.

Steps to Reproduce:
1. Open an ODB file in window W1 and a form for viewing it in W2, positioning and sizing both windows to your needs.
2. Close both of them.
3. Open an ODT file, position and size its window W3 to your needs.
4. Close the ODT window.
5. Open the ODB file and the form again.

Actual Results:
a. Instead of remembering the size and position of W1, Base displays the file in W3.
b. Base ignores the position (although not the size!) of W2 and displays the form in the center of the desktop.

Expected Results:
Upon reopening the same file, Base should show the ODB file in W1 and the form in W2.


Reproducible: Always


User Profile Reset: No



Additional Info:
Thus, instead of remembering its own window, Base remembers the window of some other LO component. This is not what the user wants most of the time, since ODB files just have a different format (layout) from ODT files.

Incidentally, the same goes for each LO component; but I have not checked this specifically.
Comment 1 Alex Thurgood 2019-10-31 16:16:16 UTC
Sounds like a DUP of bug 41777 to me.
Comment 2 Christian Lehmann 2019-10-31 17:07:43 UTC
No, not quite. The point is that, although some LO components do a better job at remembering windows than others, Base does a particularly bad job:

LO Writer at least remembers size and position of the last Writer document closed. I.e. it does not get confused by other LO components.

LO Base, instead, recalls the last LO window, whatever the responsible LO component was. And in addition, it forgets all of its internal windows.

The moral of the story seems to be: LO should store size and position for each window opened for every document/file contained in the recent document list. I do not feel this is asking too much.
Comment 3 Shad Sterling 2019-11-01 20:51:20 UTC
@Christian Lehmann, have you confirmed that on Linux LibreOffice Writer doesn't use last-closed window positions from other LibreOffice apps (not just Base)?  On macOS they're not separate apps, but Writer uses the last-closed window position of whatever document type was closed last.
Comment 4 Christian Lehmann 2019-11-04 10:33:22 UTC
I recognize I had to investigate the LO window coordinates preservation policy systematically before complaining. Sorry for the mistakes.

I report on the the result of my investigation under Bug 41777. Base behaves in most respects like the other LO components. There remains, though, one specific point for Base: As I had mentioned before, it forgets the position of its internal windows, always positioning them in the desktop center.
Comment 5 Alex Thurgood 2019-11-13 07:28:23 UTC
(In reply to Christian Lehmann from comment #4)
> I recognize I had to investigate the LO window coordinates preservation
> policy systematically before complaining. Sorry for the mistakes.
> 
> I report on the the result of my investigation under Bug 41777. Base behaves
> in most respects like the other LO components. There remains, though, one
> specific point for Base: As I had mentioned before, it forgets the position
> of its internal windows, always positioning them in the desktop center.

Forms in Base are Writer documents, so marking this nonetheless as a DUP of 41777

*** This bug has been marked as a duplicate of bug 41777 ***