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!
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
> 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
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)
+ 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:
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.
Build ID: 9bb7eadab57b6755b1265afa86e04bf45fbfc644
Build ID: a066acd8709ce69eae4fee3993dbb298e02eb8d5
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2014-11-09_09:59:47
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
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?
*** 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: 188.8.131.52
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
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)
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)
*** 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
*** 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: 184.108.40.206
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
CPU-Threads: 6; BS: Linux 4.12; UI-Render: Standard; VCL: gtk3;
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
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