Description: This feature request came up in bug 75644 which is a gordian knot of all sorts of different bugs. Lets start fresh with this feature request to implement an option to remember window size on a per document basis. Bug 75644 comment 52 Heiko suggested: Rather than switching globally, we can add a checkbox "[ ] Store window properties" at File > Properties. Off by default and when checked it must not change the per-module setting. Maybe the function is better realized per radio button with: Remember window properties (o) For <%module> ( ) For this document Steps to Reproduce: 1. create first LO document with small window size 2. create second LO document with bigger window size (same component) 3. close LO and open first document Actual Results: First file will open in window size last used Expected Results: Allow users to set option to remember window size per document, which would then (when enabled - off by default) reopen first file with its window size last used. Reproducible: Always User Profile Reset: No Additional Info: I have no stake in this and do not consider this priority. Tested MS Office 365 and it does not remember window size per document although I can see the benefit of doing that.
So, need to understand that doing this requires one of two things: 1) either LO extension of ODF spec to embed LO component frame size and position details into the archvie (so not portable to other ODF viewers), or 2) of recording per document into user profile--so not persistent as documents roll out of profile history/or profile is reset. Either way it is transient. IMHO better to break current LO component linkage to Start Center launcher frame sizing, and recording component frame size and position on desktop persistently into LO user profile. Sizing/positioning per application, not per document. With some UI rules/control for placement of subsequent frames that overlap. At that point handle the internal rendering view port per document which *can* already be recorded to ODF. Similar to what is implemented for Writer as an 'Edit view' checked against user bIsOWnDocument (SwView::ReadUserDataSequence). What is contained in the ODF has no linkage to controlling the application frame (size or placement on user desktop).
Just a few thoughts: I don't know of any Mac OSX program that doesn't save window size and position, and I use a lot of programs. In Mac OS, only a few users use the Start Center at all, as it is normal to open a document by double-clicking the document icon or an alias. Other programs with a start center have fixed sizes for this, also depending on the module. It can be and stay that way in LO. However, the document selected there should (at some point?) still open in an individual size. It's always annoying to drag the document(s) you just opened to the required size. The option to save the size of each individual document in the document is the only real thing. Finally, I would like to have a table (spreadsheet) saved on Mac 1 in landscape mode open on a second Mac in landscape mode. This non-existent possibility has been running through several OpenOffice programs for decades. Examples: https://bz.apache.org/ooo/show_bug.cgi?id=91768 https://bz.apache.org/ooo/show_bug.cgi?id=124986
(In reply to V Stuart Foote from comment 1) As I stated in bug 75644 comment 44, ODT and ODS files (I have not looked at other modules) currently contain the following config-items in the view-settings section of the settings.xml component: VisibleAreaTop VisibleAreaLeft VisibleAreaWidth VisibleAreaHeight I asked then (and again in bug 75644 comment 51) what those attributes are for if not for "component frame size and position". I never received an answer. (Also note that Elliotte Rusty Harold provided the link https://wiki.oasis-open.org/office/Spreadsheet_View_Data in bug 75644 comment 45.) I will ask again: If size/position attributes are already present in ODT and ODS files, why does the ODF spec need to be extended, and why can't the existing attributes be used to address this bug?
(In reply to Chuck Spalding from comment #3) Because, those do not establish the application frame size nor placement on os/DE desktop. Only a "view port" positioning within the ODF document.
*** Bug 86055 has been marked as a duplicate of this bug. ***
*** Bug 92737 has been marked as a duplicate of this bug. ***
*** Bug 101950 has been marked as a duplicate of this bug. ***
*** Bug 102213 has been marked as a duplicate of this bug. ***
*** Bug 112332 has been marked as a duplicate of this bug. ***
*** Bug 121968 has been marked as a duplicate of this bug. ***
*** Bug 135971 has been marked as a duplicate of this bug. ***
(In reply to steve from comment #0) > Maybe the function is better realized per radio button with: Clearly not. The point was to overwrite the current behavior for individual documents. (In reply to V Stuart Foote from comment #1) > 1) either LO extension of ODF spec to embed LO component frame size and > position details into the archvie (so not portable to other ODF viewers), or This, IMO. And additionally we should break the linkage to the start center.
The topic was on the agenda of the design meeting. Storing the window position per module is a frequently asked enhancement. Question is whether per module or per document, and I have arguments for the latter (but not optional). However, the more requests we have on one topic the more attention it gets. So I'm going to make this request a duplicate of bug 41777 and comment there. *** This bug has been marked as a duplicate of bug 41777 ***