It is past time to remove the Quickstart on Windows builds as is being done on the Linux builds. Though disabled with a default installation on Windows builds, when it is activated (intentionally or inadvertently) it causes grief with no strong argument that it is a required UI component. In fact Quickstart on Windows probably should have been eliminated at Windows 7 with MS introduction of Jump List start menu and taskbar pinning. In any case it has outlived its function and should just be eliminated. =-ref-= http://nabble.documentfoundation.org/Removing-LibO-on-Windows-tt3634487.html http://nabble.documentfoundation.org/Complete-removal-of-the-Windows-Linux-quickstarter-was-Re-Removing-LibO-on-Windows-tt3642003.html
Survey revealed that the quickstarter is used https://design.blog.documentfoundation.org/2017/06/28/results-survey-libreoffice-features/ Decision was made in the ESC to keep all these potentially outdated features.
And yet despite the "survey" ESC agreed tthat the Quickstarter would be deprecated at 5.4 for Linux builds [1], and was dropped at 6.0 [2] It has never existed for OSX builds, and it represents a source of continued instability on Windows builds. Following suit, and removing it now from the code base for Windows builds is appropriate as we have dropped support for Windows XP and Vista. Microsoft had dropped the OSA launcher from Office at the 2003 release, and at Windows 7 they brought in the entire Jump List infrastructure (of pinned Start menu and Task bar launchers) that LO supports reasonably well. Meaning, the residual Quickstarter on Windows is not a required GUI having already been replaced with Windows specific interface that the project already implements. The Quickstarter is a maintenance headache that just needs to go. =-ref-= [1] https://wiki.documentfoundation.org/ReleaseNotes/5.4#General_2 [2] https://wiki.documentfoundation.org/ReleaseNotes/6.0#General_3
(In reply to Heiko Tietze from comment #1) > Survey revealed that the quickstarter is used > https://design.blog.documentfoundation.org/2017/06/28/results-survey- > libreoffice-features/ > Decision was made in the ESC to keep all these potentially outdated features. People used the memory options, yet we removed them. We know placebo works. Now ESC made the decision to keep Quickstarter: https://lists.freedesktop.org/archives/libreoffice/2018-March/079832.html I am disappointed with this weird pendulum decisionmaking, where we keep some useless fluff that causes maintenance burden. So, I will close this and revert my edit in the release notes and comment on some reports that Quickstarter will not be removed after all even though I claimed it would be.
Hi Buovjaga - sorry about that don't want to make you look bad! Marina was telling me that large numbers of her users use the Quick-Starter on windows, and I know our users do. Of course - it can be removed or hidden in TDF builds more effectively if that makes people feel happier =) but - I'm curious as to how buggy it makes other things - is it just this tracker issue ? Thanks !
Hate to flog a downed horse but having some issues over the WONTFIX call... OOo Quickstart provided function of MS Office "Office Startup Assistant" which Microsoft abandoned and replaced for Office 2010 with the "Backstage" panel--that came in with the Ribbon--coupled with use of the Windows 7 DE Start Menu/Taskbar "JumpList" shell mechanisms. So the rational for removing the Quickstart from LibreOffice Windows builds is that as a GUI interface on Windows it is non-compliant with the OS DE shell norms. It serves no useful purpose that the OS does not already provide from Windows 7 onward with JumpList shell mechanisms--that Jesús C. explicitly added support for (see bug 35785) back in 2013. Aside from the superfluous GUI menu of launchers in the Windows system tray, the only thing Quickstart "adds" is a continually running an instance of soffice.bin. No question that that running instance avoids some start up overhead--e.g. delay of an AntiVirus scan on initial LibreOffice launch, so leaving it running can improve response. But on modern desktop/laptop hardware it really is not necessary. And, normal Windows OS DE provides "Startup" (shell:startup) program launch methods provide the "always running" support for any application if desired and LibreOffice does not need to provide (or maintain) one of our own. We could simply modify the installer/Tools -> Options "Load LibreOffice during system start-up" to drop a launcher there. We don't need all the overhead of Quickstart! And unfortunately it is that "always running" facet of the Quickstart soffice.bin/.exe that continues to cause problems that disrupt QA efforts: affecting issues in file recovery, program updates, and GPU rendering issues. I'd like to see the obsolete GUI menu removed from Windows, as done for Linux builds (never implemented for OS X), and then some dev effort on refinement of the Windows shell Start Menu/Taskbar JumpList implementation. All this meaning nothing in the Quickstart feature is necessary--and it can go, and should have gone back in 2013 when it last made the rounds on the dev list. Stuart
Hi Stuart; thanks for the summary - no dead horse flogging there, it's nice to see it all written up in one place. > Aside from the superfluous GUI menu of launchers in the Windows system > tray, the only thing Quickstart "adds" is a continually running an > instance of soffice.bin. No question that that running instance avoids > some start up overhead--e.g. delay of an AntiVirus scan on initial > LibreOffice launch, so leaving it running can improve response. > But on modern desktop/laptop hardware it really is not necessary. Yep - I think this is the major (and perhaps only) big win that is left here, but it is rather a significant one I'm afraid - hiding that multi-second latency and turning it into an apparently ~instant document load-time is a huge win for people's workflow (wrt. not breaking the flow). Unfortunately quite a lot of our users are cost conscious types who don't have modern hardware, are on rotating disks etc. > I'd like to see the obsolete GUI menu removed from Windows, as done for > Linux builds (never implemented for OS X), and then some dev effort > on refinement of the Windows shell Start Menu/Taskbar JumpList implementation. Certainly possible - if we have a good way to configure auto-starting it would be great - although of course, we will still need a UI to enable and/or disable this background memory hog =) I guess that could be in the Start Menu / Taskbar Jumplist for Windows 7. Problem is of course, that is Windows7+ only (we only just rid ourselves of XP IIRC :-) and as yet not implemented: it would be good to file an enhancement bug for that I guess (?)
(In reply to Michael Meeks from comment #6) > Problem is of course, that is Windows7+ only (we only just rid ourselves of > XP IIRC :-) and as yet not implemented: it would be good to file an > enhancement bug for that I guess (?) There is no problem, because we rid ourselves of both XP and Vista.
But on low-end hardware, do you really *want* LO to be running all the time, even when you are not using it? And if you *are* using it constantly, you don't need it to start fast. I just don't get it. I strongly believe in the placebo theory here, that because people have been told "it makes to FASTER!!!" they think so. But of course, I am not insisting, I just work here, and do as I am told.
Guess the true reason is that users are accommodated to clicking the tray icon in order to start a program (at least me in case of my file browser, Krusader). With user metrics we would have numbers to support whether the feature is widely used or not (#1.5.1 in 2018 budget ideas). And eventually the quickstarter could become a third-party tool like an extension.
At least from my work experiences, in Italy we have a lot of Public Administrations that are using the quickstart feature for boosting the user experience, in particular when the migration from MS Office is in progress and you need to fight the resistance to change. I agree with you Tor that this feature is a resources eater but at least 65K seats with this feature enabled is probably a good reason for having the quickstart available ;) A second good reason is the interaction of LibreOffice with third part software. Again in Italy we have several external software used for creating documents during the daily job workflow that work only if the quickstart is active. With a massive deployment and GPO you can quickly disable the quickstart on very old machines with lower resources available so prbably the quickstart is a win-win solution.
(In reply to Marina Latini from comment #10) > At least from my work experiences, in Italy we have a lot of Public > Administrations that are using the quickstart feature for boosting the user > experience, in particular when the migration from MS Office is in progress > and you need to fight the resistance to change. > I agree with you Tor that this feature is a resources eater but at least 65K > seats with this feature enabled is probably a good reason for having the > quickstart available ;) > A second good reason is the interaction of LibreOffice with third part > software. Again in Italy we have several external software used for creating > documents during the daily job workflow that work only if the quickstart is > active. So what is the problem with implementing this with native Windows features Stuart described?
Marina: sure, as I said, I just work here, and am not insisting.
> So what is the problem with implementing this with native Windows > features Stuart described? No problem at all - it just needs someone to implement it; please do file an enhancement bug for that and CC me - when there is an equivalent or better feature done another way, I don't think anyone is against removing this in principle =)
I created bug 116694 for the "always running". Stuart: if you have some refinement ideas for the jumplist, please file a report.