Applications use the window size of the start screen instead of the last used size of the document. If you start libre office with the start screen and select a document in the preview the application (writer for excample) it uses the size of the start screen. If you open the document directly it the application use the last used size of the document. The right behavior should be that in both cases the application opens with the last used window size of the document!
Not a bug for me. Best regards. JBF
I confirm the behaviour described by Papamatti, but like JBF said I'm not sure I'd call it a bug. I'm lowering priority from normal to minor.
(In reply to tommy27 from comment #2) > I confirm the behaviour described by Papamatti, but like JBF said I'm not > sure I'd call it a bug. Paging the Design Team...give us your words of wisdom! cc: JayPhilipz
Ok, set component to ux-advise and status NEW. let's see what the ux-team thinks about it (a bur or not a bug).
Isnt it the window manager that decides the size and position of the application being restored when reopening it?
(In reply to Papamatti from comment #0) > Applications use the window size of the start screen instead of the last > used size of the document. > > If you start libre office with the start screen and select a document in the > preview the application (writer for excample) it uses the size of the start > screen. > > If you open the document directly it the application use the last used size > of the document. > > The right behavior should be that in both cases the application opens with > the last used window size of the document! Nope. Actually, window state is NOT tied to each document--but to the last launch of the component. If a component is launched from the Start Center, its window will be the size of the Start Center. If a document is launched from the OS file association, or opening a component from individual launcher, its window will open the size of the last launch of the component. And when closed the size of the Start Center adjusts accordingly. These states are recorded into the LO user profile--registrymodifications.xcu--clear it and you get defaults. As clipped from the <item> stanzas ...Setup:Factory['com.sun.star.frame.StartModule'] ...Setup:Factory['com.sun.star.text.TextDocument'] There is no hook within ODF document to suppor this. It could possibly be handled within the Histories:HistoryInfo item list. But that is cleared as soon as an item is removed from the recent documents list.
Resolved Wontfix as per Design/UI meeting 2014-12-17 + Start center not using last window size (Qubit) https://bugs.freedesktop.org/show_bug.cgi?id=75644 + would need to check the code (Kendy) + I recall there is some forcing of size (at least) but not 100% sure (Kendy) + the user expected that it would open according to the last edit of that document (Stuart) + unclear if the proposed change brings enough better usability (Kendy) + but definitely it's quite a lot of work (Kendy) + suggest to keep as it is (Kendy) + room for improvement (Stuart) + but would be invasive (Stuart) + cannot have the configuration in the file format (Stuart) + maybe only in the recent documents (Kendy) + conclusion: WONTFIX probably, patches to improve situation won't be rejected though :-)
*** Bug 86055 has been marked as a duplicate of this bug. ***
Hi guys, I recall this being discussed and understand that saving window size per document might be a bit too much at the moment. I didn’t understand that what was being discussed is imo a major OS X LO annoyance: https://bugs.freedesktop.org/show_bug.cgi?id=86055 I’ve set my own bug to dupelicate. But I am re-opening this one here. If the window size can be saved from start center, it should also be saved from document. Also this was indeed working in earlier a long time ago iirc, thus regression. Here’s my test results from the other bug. And since this works fine on Linux it is def a bug. Tested with Version: 4.3.3.2 Build ID: 9bb7eadab57b6755b1265afa86e04bf45fbfc644 Version: 4.4.0.0.alpha2+ Build ID: a066acd8709ce69eae4fee3993dbb298e02eb8d5 TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2014-11-09_09:59:47 OSX 10.10 Very annoying. Each user has a window placement and program size, best fitting the individual needs. LO ignores this on OSX. jphilipz tested this on Linux and it remembered screen position and window size, so def a bug. Feel free to bash me for re-opening next design meetup.
OS X Info.pList launcher handling aside, off mab4.4. Adding to bug 42082, bug 61914. Setting as an enhancement to do something more with independently managing document module(s) window size. @foss, not convinced there is a regression as this is VERY user profile dependent. Can you check behavior with cleared profiles? Regards OP's issue, to be clear, positioning/sizing of document is not recorded inside of ODF--so that aspect is not stateful nor portable. LibreOffice could possibly "extend" ODF to do so, but it would be non-standard, and would then have another group with UX complaints that we aren't compliant. So IMHO going that route is not valid. What does exist now in LibreOffice that could be adjusted is at the document module level (writer, calc, impress, draw, math) and is recorded into each user's profile registrymodifications.xcu as ooSetupFactoryWindowAttributes com.sun.star.text.TextDocument com.sun.star.sheet.SpreadsheetDocument com.sun.star.drawing.DrawingDocument com.sun.star.presentation.PresentationDocument com.sun.star.formula.FormulaProperties com.sun.star.sdb.OfficeDatabaseDocument com.sun.star.frame.StartModule Presently they are assigned/recorded into the registry on first use of the module. All, including Start Center's, open to some OS/DE dependent default, e.g. it is full screen for Linux/GNOME. But I've yet to locate where, when using a cleared regenerated profile. So, yes it could be different on OS X and a source of legitimate regression if something there has changed between 10.9 (Mavericks) and 10.10 (Yosemite) including malformed Info.pList Each module receives these default window attributes for its factory when first launched individually. Except that calc, draw and impress are flagged in Setup.xcu (ref) to open maximized--the ",,,;4;" value (where 1 is normal window, 3 minimized, 4 maximized). But confusing in that the OS/DE seems to assign a 5 when it has control (seeing value 5 in a maximized GNOME 3 window on Fedora 20) I won't be able to poke at an OS X 10.9 box until next week, appreciate if anyone is able to fill in that detail. But for any module first launched from the Start Center, the window defaults for each module are ignored and it will instead open to the current size of the Start Center. If the module is not resized while open, on closing the module will be assigned window attributes in the registry matching those of Start Center. But if resized, and is last module closed--so returning to and resizing the Start Center--the registry values for both the module and the Start Center will pick up the new size as their window attributes. So, absent rework for an ODF "extension" the ooSetupFactoryWindowAttributes aspect could probably be refined. 1). It seems like the Start Center should receive a system default for a non-maximized Window. The Start Center (StartModule) should become independent of any of the document modules. We should remove the linkage of its window from that of the last active module--which causes its resize now. But we should not revert it to be only that fixed size, as that would break the advances of adding the thumbnail vies of recent documents. It should just be independent, as the other document modules are now from each other. 2). Should allow a user to choose behavior when launching a document module from Start Center. Either: (a) to use the StartModule's ooSetupFactoryWindowAttributes as now, or (b) to lock and use the attributes for each document module. Not sure of best UI to do that--out of the Start Center (prompt on selection), or from Tools -> Options. 3). Should a Start Center launch overwrite the document module's ooSetupFactoryWindowsAttributes, or should they be locked/protected? -=ref=- http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Setup.xcu http://opengrok.libreoffice.org/xref/core/unotools/source/config/moduleoptions.cxx
*** Bug 87465 has been marked as a duplicate of this bug. ***
*** Bug 87542 has been marked as a duplicate of this bug. ***
UX-folk, please note enhancement suggested in bug 87542: closing last document in a particular application should not necessarily revert back to start screen, but might rather just revert back to an empty or new doc screen of that app. This would remove some inconveniences using LO under Windows: 1. Taskbar appearance changes, making it harder to find again later. 2. Taskbar location changes, since this is a new application as far as the (Windows) window manager is concerned.
In my own bug about this I wrote: "regression since it worked in Version: 4.3.3.2 Build ID: 9bb7eadab57b6755b1265afa86e04bf45fbfc644 Not sure when this was exactely introduced though." Can someone confirm this finding? We need to find out if this indeed is a regression or not.
Linking related (and probably required) work of bug 77590, to make Start Center views available while other LO modules are open. (In reply to pb from comment #13) > UX-folk, please note enhancement suggested in bug 87542: closing last > document in a particular application should not necessarily revert back to > start screen, but might rather just revert back to an empty or new doc > screen of that app. Yes, this will need to be part of the additional work on configuring the UI for Start Center behavior and its relationship to other LO modules. Expect it to be a configurable option--i.e. closing last active component exposes the Start Center, or not and fully closes LO. And of course for Windows builds, behavior of LO Quickstarter may also have to be adjusted. > This would remove some inconveniences using LO under Windows: > > 1. Taskbar appearance changes, making it harder to find again later. > 2. Taskbar location changes, since this is a new application as far as the > (Windows) window manager is concerned. Valid, but only of minimal impact because for a full (non-administrative) LibreOffice install on Windows 7, or 8/8.1, pinning each launcher to the Windows taskbar fixes the location for each component on the taskbar and exposes the Windows shell jump-list behaviors. It is only when left unpinned (the default for any application) that the order/placement changes depending on activity (also default).
(In reply to V Stuart Foote from comment #15) > > Expect it to be a configurable option--i.e. closing last active component > exposes the Start Center, or not and fully closes LO. Sounds good to me. > > > This would remove some inconveniences using LO under Windows: > > > > 1. Taskbar appearance changes, making it harder to find again later. > > 2. Taskbar location changes, since this is a new application as far as the > > (Windows) window manager is concerned. > > Valid, but only of minimal impact because for a full (non-administrative) > LibreOffice install on Windows 7, or 8/8.1, pinning each launcher to the > Windows taskbar fixes the location for each component on the taskbar and > exposes the Windows shell jump-list behaviors. It is only when left unpinned > (the default for any application) that the order/placement changes depending > on activity (also default). I have a slightly different view of that. First, avoiding an unpleasant (to me, anyway) default behavior that other programs do not generally exhibit should not require using OS UI features that do not occur by default, and which may not be obvious to a naive user. In addition, for me anyway, the taskbar is cluttered enough without pinning things to it. I prefer to just have desktop items that have the same function. Incidentally, I also noticed an inverse behavior, which is a similar bug: If there is an LO app currently open, starting the LO startcenter switches to that app as opposed to running the startcenter screen. It seems that the more appropriate behavior would be to show the startcenter -- after all, the user might want to run a different app. Why should you decide for him which app he wants. It's of course a different question what are the priorities of these issues.
(In reply to pb from comment #16) > (In reply to V Stuart Foote from comment #15) > > > > > Expect it to be a configurable option--i.e. closing last active component > > exposes the Start Center, or not and fully closes LO. > > Sounds good to me. > Maybe I should clarify that. My main complaint is that closing the last document in an app reverts to the start center. The behavior imho should be that closing the last document in an app just leaves that app, but without any document, or with a new document. You seem to be assuming that closing the last document in the app necessarily closes the app, and the only issue is whether LO should then revert to the start center, or go away completely. If I *explicitly* close the app, I don't have a strong opinion about whether the startcenter should then start. The problem for me occurs because I am closing the last document, not explicitly closing the app, yet as an unexpected side effect that both closes the app and starts up the start center.
Adding self to CC if not already on
Why is this NEEDINFO? It's a real problem and very annoying. NEW If dev input is needed that should be a keyword instead of a status.
@foss, NEEDINFO because it is a ux-advise issue and there is still UI discussion of impact to UX. In fact, because of its potential scope and affect on UX, this issues already was closed once following Design/UX team discussion, but was reopened for additional technical review, Dev and QA input--including your bug 86055, and bug 87542 Some major UI design aspects to be resolved about behavior of StartCenter and its relationship with the other modules. Right now, the associated StartModule frame behaves as a master and will change/control size and placement settings of the other modules. Severing that relationship would allow what appears to be the requested enhancement of positioning and sizing each document component module independently, as recorded into LO registry per user profile. Absent handling of that, and perhaps refactoring to achieve enhancement of bug 77590--Make LO's Start Center thumbnail views available for use from within components, the UX will remain annoying for folks who prefer to have different fixed sizes and locations for the LO modules. NEEDINFO because we just don't know at this point how much Dev effort this is going to take, and how implementing this will adversely affect the UX for those that are happy with the status quo.
OS X 10.10.3 Version: 5.0.0.0.alpha1+ Build ID: e658cb4d5ce49d3a3c6acc63155974b5ff8490c7 TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-05-07_23:37:20 Locale: de-DE (de.UTF-8) Since there is no specific commit fixing this issue, setting to WORKSFORME. FIXED is used only when a commit exists. Feel free to reopen this issue if you still can reproduce this particular problem or if I did miss something peculiar.
(In reply to steve -_- from comment #21) @Steve, As this is a ux-advise enhancement request -- not subject to being closed WORKSFORME. Back to NEW (i.e. Discussion and DevEval)
Stuart so should DevEval be used as a keyword? Also what are the next steps for this? Is this on some ESC agenda? Who from UX can we get involved? Is Adolfo cc: already?
(In reply to steve -_- from comment #23) > Stuart so should DevEval be used as a keyword? Also what are the next steps > for this? Is this on some ESC agenda? Who from UX can we get involved? Is > Adolfo cc: already? Not a keyword, rather have set the correct Whiteboard of "needsDevEval topicUI" The BZ "blocks" field distributes this via META to those with interest in the UI and UX of the StartCenter. So the correct folks are already involved. Somewhat related, with some 400 valid BZ issues tagged ux-advise in various states of UI design and UX review this is just one issue. We have a current Design UI/UX Team AI to fully triage/prioritize and assign as needed "needsDevEval topicUI". The challenge is presenting this and its related fiends forward as cohesive enhancements for developer attention. This is part of a larger issue of how the modules and UI behaves within a session, for each of the OS builds.
*** Bug 92737 has been marked as a duplicate of this bug. ***
I would add that with bug 92242 on top of this one, it is an experience in frustration even trying to resize any application window once the user has had the misfortune to attempt changing the initial StartCenter window size on a fresh setup.
Why does this need devEval when it is clearly a regression over previous behaviour on OSX ?
(In reply to Alex Thurgood from comment #27) > Why does this need devEval when it is clearly a regression over previous > behaviour on OSX ? Having just tried this with regard to OOo 321 on OSX 10.10.4, i.e. approximately equal to LO 330, I can confirm that re-opening a Writer document opens it at the same dimensions at which it was displayed before shutting down the app. That is a regression in my book.
Migrating Whiteboard tags to Keywords: (needsDevEval, topicUI) [NinjaEdit]
*** Bug 100500 has been marked as a duplicate of this bug. ***
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
*** Bug 101950 has been marked as a duplicate of this bug. ***
*** Bug 102213 has been marked as a duplicate of this bug. ***
*** Bug 112232 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. ***
Have made some screenshots for Base-Handbook. Thought this shouldn't happen: I open the database through the start center. Screenshots of the whole Base-screen shouldn't be to high. So I want to change the height, but the minimum of the height of the opened window is set by the minimum height of the start center. Then I started through sbase in libreoffice6.1/program directly. There I could change the height of the window to the height I needed. All tested with Version: 6.1.4.2 Build ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3 CPU threads: 6; OS: Linux 4.12; UI render: default; VCL: gtk2; Locale: de-DE (de_DE.UTF-8); Calc: group threaded OK, this isn't the same bug as described through the title, but the behaviour is the same: start center sets the min-height for the document, which is directly loaded through the start-center. If I open the next document from the loaded document (for example the first loaded database) the min-height isn't set for this new opened document. So I have to open a dummy at start for working around the buggy behaviour of the start center. This isn't an enhancement. This is a real (normal) bug!
(In reply to Robert Großkopf from comment #37) Now I have tested the same with Version: 6.2.0.1 Build-ID: 0412ee99e862f384c1106d0841a950c4cfaa9df1 CPU-Threads: 6; BS: Linux 4.12; UI-Render: Standard; VCL: gtk3; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded This version uses gtk3 instead of gtk2. You could get the window, which is opened from the start center, in every size. There is no min-height set for the opened window any more.
(In reply to Alex Thurgood from comment #25) > *** Bug 92737 has been marked as a duplicate of this bug. *** Sorry folks, are these 2 bugs really related? The start center is not used. I inserted photos with "my" problem in report 92737. Unfortunately, you can only see the effects if you can view the photos in full size. This is not plausible in the overview.
(In reply to Manfred from comment #39) > (In reply to Alex Thurgood from comment #25) > > *** Bug 92737 has been marked as a duplicate of this bug. *** > > Sorry folks, are these 2 bugs really related? The start center is not used. > I inserted photos with "my" problem in report 92737. > Unfortunately, you can only see the effects if you can view the photos in > full size. This is not plausible in the overview. @Manfred : please read comment 10 in this report where all is explained.
Removing UX, the envisioned solution is in c10, "1). It seems like the Start Center should receive a system default..." considering also c13.
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
Thank you. As a user can you imagine anything more frustrating than saying this was not preferable behavior for an app and devs just saying “no it’s supposed to do that”... meanwhile I had forgotten about this thread because I STOPPED USING libreoffice because ms office actually works the way i want it to. So thanks for actually moving this forward finally
I'm very new to LibreOffice and this bug system, so I apologize in advance if any of this is inappropriate. In Comment 10, the writer states "positioning/sizing of document is not recorded inside of ODF". I've looked "inside" some ODT and ODS files, and each one contains the following config-items in the view-settings section of the settings.xml component: VisibleAreaTop VisibleAreaLeft VisibleAreaWidth VisibleAreaHeight If those items are not for "positioning/sizing of document", what are they for? (As an aside, regarding the reported issue, I've done the experiment with Excel and Numbers, and they both "do the right" thing when documents are opened. That is, they show the document window as it was when *that document* was last saved, regardless of other documents that have been opened since.) I'm using LibreOffice 6.4.4 on macOS 10.13.6 (High Sierra).
FYI https://wiki.oasis-open.org/office/Spreadsheet_View_Data seems pretty clear that View Settings are exactly what is needed in the document.
Most of the discussion of this bug seems to be focused on the Start Center, but the bug title seems to mention *two* issues: * "window resize of the Start Screen" * "last used window size of each document module" (The bug was initiated regarding the second topic. The first topic was added when comment 15 was posted.) This bug has just been flagged as depending on bug 125543. As I understand it, that bug regards the behavior of a new window, which could be related to the first of those topics, but not related to the second topic. This bug is also flagged as depending on bug 77590. Again, that bug is about the Start Screen, but not the second topic. Thus, both of those dependencies will delay fixing the second topic. I suggest that this bug be split into two bugs, or the topics be shifted to two of the duplicates. "Duplicates" bug 87542, bug 100500, bug 112232, and bug 121968 seem to be related to the first topic; while bug 86055, bug 87465, bug 92737, bug 101950, bug 102213, and bug 112332 seem to be related to the second topic.
*** Bug 135971 has been marked as a duplicate of this bug. ***
Unsure of the current status (or interest in a solution) but I would be inclined to define it as a major presentation failure of LO. I have numerous files with different display characteristics. These characteristics are related to the areas of the spreadsheet that I need to be generally visible when the file is opened. I also have multiple monitors with the desktop "extended". I often have multiple files active with their own allocated "real estate". I am also aware that I can group columns and rows and hide "less pertinent" data as I, THE USER, DECIDE. I regularly access information from the internet which is often offered in eXcel format and set with the default - open "with Libre Office". If I'm being kind, I would identify re-opening all the files on a subsequent occasion as "Shambolic". Viewing prior comments where presumably non-users are defining the issue as unworthy of attention, prompts a far more caustic definition. Once we lose sight of what the user wants, we end up with a camel. I appreciate that all the effort is voluntary - even the users are volunteers. If you kill off all the "guinea pigs" the project is only worth abandoning. Would anybody disagree?
@Colin, thank you for commenting on this issue. Unfortunately, the powers-that-be seem to be unable or unwilling to separate the *two* issues in this bug report, and they seem to be more interested in the Start Center issue than the window-attributes issue that you commented on. I tried twice last year to "help" with the window-attributes issue (see comment 44 and comment 46), but got nowhere. I just noticed that comment 42 (entered 20 months ago!) changed the priority to "high", but that seems to have had no effect.
(In reply to Chuck Spalding from comment #49) No. What was a UX decision was that a per-document size is not supported by ODF document model so will not be implemented by project. What was accepted was that the linkage of component launch to the Start Center needs to be severerd--so that each LO component (Writer, Calc, Draw, Impress, Math, Base) will open independently of size recorded for the backing Window of the StartCenter and ass recorded into the user profile once each component has been configured to user preferences. Rejection of the per-document size handling, and implementation of a per-module size recorded to profile is the gist of this enhancement. For clarity, requests for per-document will be duped' here--it won't be done; as will requests for per-component size and fixed position. Resetting UX-advice to take it back through evaluation...
(In reply to V Stuart Foote from comment 50) If "a per-document size is not supported by ODF document model", please answer the question I asked in comment 44: I've looked "inside" some ODT and ODS files, and each one contains the following config-items in the view-settings section of the settings.xml component: VisibleAreaTop VisibleAreaLeft VisibleAreaWidth VisibleAreaHeight If those items are not for "positioning/sizing of document", what are they for? Also, please see comment 45 and its linked document. Is that not relevant? Your comment 10 states "positioning/sizing of document is not recorded inside of ODF". Do you want to reconsider that?
(In reply to V Stuart Foote from comment #50) > No. What was a UX decision was that a per-document size is not supported by > ODF document model so will not be implemented by project. When there is so much interest in a per-document solution we should introduce an option. But rather than switching globally, I'd add a checkbox "[ ] Store window properties" at file > properties. It would be 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
This bug is quite messy and that is due to the different aspects going into it. OP was reporting a problem where size of component window (e.g. writer) was using identical size to start center when start center was opened first and file was opened from start center. This problem has long been solved. A problem that we should have kept separate was where start center window size was not remembered on macOS 10.10. Then in 2014 this bug here was closed as wontfix after design / dev discussion (comment 7) and re-opened due to both of the following bugs (which imo should not have been done, I know I was involved in re-opened, so happy to take part of the blame): https://bugs.documentfoundation.org/show_bug.cgi?id=86055 https://bugs.documentfoundation.org/show_bug.cgi?id=87542 Comment 13 adds more aspects of interaction between start center and component windows. Iirc this was early days for start center and there were a few quirks that have since been worked out. Then the discussion went from window sizes per LO module to window sizes per document. I find this bug unnecessarily hard to follow and digest. Bug 144211 is a clean feature request to implement an option allowing to store window size on a per document basis. Please cc: yourself on the new bug if you are interested in this feature. Thanks for understanding that we close this bug here. But having a clean feature request will help move this forward instead of wasting the time of qa and dev trying to even understand this bug here. Feel free to add relevant info I may have missed to the new bug. Resolved Fixed since the original problematic behavior is long gone.
WFM is clearly not correct. Linking it to the older ticket now. *** This bug has been marked as a duplicate of bug 41777 ***