Bug 75644

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.