LibreOffice is a very large download. (Anything and everything that can be done to shrink the size should be done.) In order to provide Windows users with an easier, more appropriate, and more robust download, the project should build a stub or net installer. The stub or net installer is a very small native Windows app that contains just enough smarts to provide the user with a choice of which LibreOffice apps to fetch and install. Even better would be if the stub had resume-able download capability to ensure a successful download (something I suspect is a major problem with the ~200MB download offered today). The stub installer should have checkboxes for each of the LibreOffice programs as well as the help pack, templates, and any other important components. Once the user selects her programs and kicks off the install, the next thing she sees should be a launched LibreOffice.
AFAIK there is no possibility to install separate single LibO applications. The selector during the application only has influence what applications what applications will be shown in the user interface. And IMHO it's rather useless and not LibO intention to enable user to install a WRITER application what can not handle DRAW shapes or something similar. And I really doubt that we want to create a WIN special arrangement. @Asa: Or do you have new, more current information?
@Rainer: That is not entirely true, as: a) While Sun/Oracle never intended OOo to be splittable, since go-oo there has been work in that direction. For example, Ubuntu and Debian have these packages split out of LibreOffice: https://launchpad.net/ubuntu/+source/libreoffice b) In a default Ubuntu install, not even all of these packages are installed (e.g. libreoffice-base is not) c) we are already having multiple parts to download for Windows (main app and help-pack) d) For things like templates, media-wiki extension and quite a few others it should be doable to separate them. As most distros do this (although not all of them as extreme as Debian/Ubuntu), Windows _is_ indeed the special case. But -- and this is a big but -- unlike Linux distros, Windows (and OS X) has no sane default package management. Getting this implemented would require a lot of platform specific work and would seriously increase the resources needed for testing as the scenarios to test explode with every added option.
I'm guessing here, but I believe most people have a simple goal in their head: "I need a free version of [Word|Excel|Powerpoint]". The software that best answers that question, with the least effort, will get all the users. File size is one of the things that adds effort, and something that should be taken very seriously. Smaller file-size leads to more users. This is true not just for Windows users, but for ALL users. Here's who I would do it: 1) Build a small stub installer, which lets the user choose which of the three things they need. Could be very similar to: http://www.libreoffice.org/features/screenshot/ 2) When user presses "Install" in the bottom right corner just the selected packages are downloaded, which should be way below 200 Mb for most users. 3) If a user tries to trigger a command that's not installed (e.g. Draw), pop up the same installation window and let the user add Draw to their installed program. This would not mean building a whole package manager, just the simplest possible window to make the download smaller. I definitely think this would be worth the effort.
@Emil: It is not that easy, as people expect applications to work completely and are unsuspecting that they need parts of the other apps too. Take for example Writer: - Bibliography requires Base - Drawings require Draw/Impress - etc. Keep in mind that a downloading might not work because the user is traveling or living in a country were broadband internet is not common. Not being able to continue work then would be a far bigger issue than a slightly bigger download. And as said above, thats not the biggest issue -- that would be testing the stability in all the possible states of partial installation.
The very large download is primarily a function of inefficient translation of templates; there is a lot we can do with resources applied to shrink our installer without removing any functionality at all. We should do that work first; but it requires work - primarily some hacking to translate arbitrary XML files, add tooling support for some sensible syntax for that to our l10n flow, and layering that XML translation on top of our flat-ODF filter (or somesuch), to get all of our wizards / templates translated sensibly - rather than duplicating these large, zipped binary files per-language.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO