https://bugs.documentfoundation.org/show_bug.cgi?id=76131

V Stuart Foote <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]
           See Also|                            |https://bugs.documentfounda
                   |                            |tion.org/show_bug.cgi?id=11
                   |                            |7492
             Blocks|                            |113117

--- Comment #25 from V Stuart Foote <[email protected]> ---
(In reply to John Page from comment #24)
> We're now halfway through May 2018, and this bug is still there on the
> latest version - 6.0.4.2. 

And? 

There is little dev interest in implementing this Windows installer code to
tweak per user migration of Windows 7 Jump List entries (Start menu or Task
bar). Especially as Windows 7 Jump Lists have been deprecated by Microsoft [1].
Even less appealing given the divergence of Microsoft's VS 2010 implementation
in .NET and UWP flavors. 

Otherwise, LibreOffice's profile held history of recently used documents
already migrates with the profile when upgrading and is supported in the Start
Center GUI or menu list.

> I'm using Windows 10x64, and notice that the
> updates take just as long to install as the original program did. Why can't
> they be limited to ony the changes since the previous version, and keeping
> the user's preferences etc? While installing I'm forced to go through the
> options list every time, instead of the previous options selection being
> re-used, like most other apps.

Maybe. See bug 68247 (and meta bug 54242) for progress on incremental updates
(Linux & Windows), 

@Andras, Mike K.- while thinking about Windows installer rework for bug
117492--a "straw man" to ponder: is it worth the effort to add custom object
logic to the installer--condition Installed and Patch--for an option to move /
restore the Windows 7 Jump List items--outside (with our LO cache, logs?) our
maybe inside our User profile? 

To be recorded back to Windows registry per newly (re)registered AppUserModelID
and regenerating the Jump lists for items held per user now in:
"/User/<userid>/appData/Roaming/Microsoft/Windows/Recent Items"
"/User/<userid>/appData/Roaming/Microsoft/Internet Explorer/Quick Launch/User
Pinned/Taskbar"

Or are we stuck as now that during the uninstalling we clobber the linkages and
the pinned JumpLists are pruned?

Rather seems the later remains reasonable handling and this becomes a clear
=>WONTFIX by attrition. That is maintain the current implementation, but not
invest dev effort to making its migration per user profile more robust.

=-ref-=
https://msdn.microsoft.com/en-us/library/system.windows.shell.jumplist(v=vs.100).aspx


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=113117
[Bug 113117] [META] Windows installer/uninstaller bugs and enhancements
-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to