From https://bugs.documentfoundation.org/show_bug.cgi?id=116142#c5 (In reply to V Stuart Foote from comment #5) > 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!
Hmm... It doesn't seem correct. shell:startup is just a special directory that contents is launched at startup, just like a bunch of other startup mechanisms - like keys in registry, one of which is used by LibreOffice Quickstarter feature. So using one (by creating some shell shortcuts there) or the other (writing relevant registry entries) is just a matter of convenience (there's no code creating shell shortcuts in LO currently aside from MSI AFAIK). But the Quickstarter is not simply starting LibreOffice at startup. The started soffice has also changed closing mode: user does not terminate the process when closes last document and mail window. This allows for following startup to also be faster. And if this is to be kept, then the current feature is fully useful.
(In reply to Mike Kaganski from comment #1) ... > process when closes last document and mail window. This allows for following ...and main window, of course.
(In reply to Mike Kaganski from comment #1) > ... > But the Quickstarter is not simply starting LibreOffice at startup. The > started soffice has also changed closing mode: user does not terminate the > process when closes last document and mail window. This allows for following > startup to also be faster. And if this is to be kept, then the current > feature is fully useful. Sure either shell:startup or the registry HKCU or HKLM CurrentVersion\Run keys can be laid down by the MSI. But a big chunk of the Quickstart on Windows is reimplementing application shortcuts and linking to the taskbar, and seems that all is handled natively in windows shell with Jump List AppUserModelID associations. Remainder seems to provide a LO managed service to monitor and restart the running instance in the system tray. There's got to be a better way to do that, and most Windows programs that need it would register it as a service. =-ref-= https://opengrok.libreoffice.org/xref/core/setup_native/source/win32/customactions/quickstarter/ https://opengrok.libreoffice.org/xref/core/include/systools/win32/qswin32.h https://opengrok.libreoffice.org/xref/core/sfx2/source/appl/shutdowniconw32.cxx https://opengrok.libreoffice.org/xref/core/sfx2/source/appl/shutdownicon.hxx https://opengrok.libreoffice.org/xref/core/sfx2/source/appl/shutdownicon.cxx
(In reply to V Stuart Foote from comment #3) > Sure either shell:startup or the registry HKCU or HKLM CurrentVersion\Run > keys can be laid down by the MSI. ... and after installation, user can enable/disable the Quickstarter from the UI, without the need to re-run the installer. There's ~no overhead here. The implementation doesn't restart processes: it reinstalls the icon into the tray, while still running the process. This *removes* additional overhead of running *separate* process as service: no additional memory or CPU requirements, no IP communications across system security borders (system-to-user), no counting of possible concurrent user sessions (with different users soffice running - usual, e.g., on terminal services), no additional development overhead of managing (changing security requirements) etc. So - I don't see any additional overhead to implement *existing* functionality.
And ShutdownIcon::EnableAutostartW32 installs the shortcut to the shell:startup actually (taking the path in ShutdownIcon::getShortcutName() using ShutdownIcon::GetAutostartFolderNameW32()). So - yes, we do have the code to create shell shortcuts :)
Buovjaga can you please explain why you marked as New? For me this is "NeedDevEval". And it looks Mike gave one that's not favorable.
(In reply to Timur from comment #6) > Buovjaga can you please explain why you marked as New? For me this is > "NeedDevEval". And it looks Mike gave one that's not favorable. It is not my idea and it is an old one. Removal was requested already in 2013. Mike is the only active developer in favour of keeping it. The argument from performance has usually been countered by saying that we should focus on making LibreOffice faster in general. But sure, we can slap a needsDevAdvice on this.
.