Created attachment 55133 [details] Graphic depiction of what the FAM settings could look like Hello all, I am reproducing this bug from the old Openoffice bug system here, in the hopes that the Libreoffice devs will take a kinder view to it's implementation... For historical purposes, the original bug was 77257: https://issues.apache.org/ooo/show_bug.cgi?id=77257 Since that enhancement request was initiated, Libreoffice has gained support for the new xml office formats, so I'll take this opportunity to polish the screenshots for this request to take these into account. I am attaching an updated screenshot depicting what this new FAM *could* look like (not necessarily what I think it *should* look like). I know that there have been a few discussions about this, and that some people have strong feelings that this is something that LibO should not do, but I want to make my *strong* argument in favor it, so I would appreciate it if you would take the time to read this in its entirety. I am taking the time to create this Issue/Enhancement Request after being bitten by this problem *again*. It has happened to me at least 5 or 6 times in the years I've been using OOo/LibO, and, although it doesn't happen very often, when it does, the ony way I have found to fix it is to reinstall *Windows* (no amount of uninstalling/reinstalling OOo/LibO has ever fixed this problkem for me), and, in my opinion, this is just not acceptable. Recently I again had a problem where OOo/LibO lost its file associations - for its *own* file types, not MSO file types - and nothing I did was able to repair them. A reinstall/repair of windows, does, however, every time. First - the usual recommended method of 'right-click, open with...' is totally unusable for me anyway, because it will not work for the Template file associations - when templates are re-associated this way, from that point on, OOo will not treat them as it should treat templates (copy contents of template into new blank document, initiate prompt for input fields, etc), it just opens them, as if I had right-click>opened them. It goes without saying that this functionality should only be available when the current user has the required Admin privileges. All this functionality would have to do is: 1. Reset the file associations for all LibO (including the deprecated Openoffice.org 1.x) file types - *including templates* - so that they work properly with LibO. (since OOo currently is capable of properly associating its own files upon installation, it should be trivial to add a button somewhere in the Preferences (I added it to the 'General' prefs in my attached screenshot), but it could even be on its own) that would simply re-associate all of the native LibO/OOo file types with LibO) 2. If the user elects *not* to allow LibOo take over the file associations for Microsoft Office files at install time, provide a button that takes them over (*but first* records their current settings as per #3 below) - just as if the user had elected to let LibO take them over at install time, if the user later decides they like LibO enough to do so. As with the LibO file types, these choices should include the associated template files. 3. If the user elects *to allow* LibO to take over the file associations for Microsoft Office files at install time (or does so per #2), again, record the *current* file associations *before* changing them, so that the user can easily revert the changes if desired. 4. Provide a simple interface (see attached screenshot for an example of how simple it could be) that allows the user to do #1 anytime it may become necessary, as well as an easy way to switch Microsoft Office file associations back and forth (between being associated with LibO, and what they were before/when LibO was installed) or repair them. The buttons label text should change depending on what actions would be taken (ie, 'Repair', 'Change', 'Revert', etc). 5. The File Associations Selections choices available at install time should also be expanded from 3 (.doc, .xls and .ppt) to 6 (.doc, .docx, .xls, .xlsx, and .ppt and .pptx), so that you could choose to associate only the .doc/xls/ppt file types, but NOT the .docx, .xlsx and .pptx file types if desired. 6. What is selected by default should depend on whether or not Microsoft Office is currently installed - if it is, default to NONE selected (assuming it is a version capable of working with the new XML versions, otherwise default to selecting only the ones supported by that version of Microsoft Office), if it isn't, default to ALL selected (even if .doc is already associated with Wordpad, it should still be selected by default, currently, it isn't). Well, that's it, thanks for listening... Charles
I have submitted this along with four other bugs to the mailing list because they are all very similar. I may create one "super bug" and close this one as a dupe because it seems like the underlying issue comes down to "defaults" & "changing file associations", I really like this mock up and I have submitted it for consideration by the developers. See also: FDO 39791 FDO 43519 FDO 38310 FDO 47483
There are few methods to provide a proper file associations for the Windows version of Libreoffice 1. During the command-line installation, which is convenient for mass-scale deployment 2. During the GUI installation, selecting file associations works for LibreOffice, but doesn't work for LOdev - should a new bug be filed or this can be handled in the existing bugs, such as Bug 60714? 3. Modifying the GUI installation, selecting file associations works for LibreOffice 3.6.5.2 and 4.0.1.2, but doesn't work for LOdev - related to Bug 60714 - changing file associations from the change option of add/remove programs doesn't work - so this bug should relate to LOdev only 4. Using Windows 7 Default Programs option in Control Panel is possible for LibreOffice 3.6.5.2 and 4.0.1.2 because they are registered, but it's not possible for LOdev because it's not. - related to Bug 43519 - Cannot set default file associations - I don't have Vista, but it should be same as 7. I think this bug should relate to LOdev only. 5. From within LibreOffice - not possible, and requested in Bug 44462 - Provide a proper 'File Association Manager' for the Windows version of LibreOffice. LibreOffice is found in HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\RegisteredApplications while LOdev is not.
(In reply to comment #2) Not exactly correct. Yes, when working with the LODev builds, by default the .msi installer package does not write into the Windows registry. For the Windows RC and Final release builds that is changed with a single toggle of the WRITE_REGSITRY value from "0" to "1". When working with LODev builds, running the installation from a command prompt and setting WRITE_REGISTRY=1 will fully enable recording of GUI options into the Windows registry. msiexec.exe /i libreoffice-4-0~2013-03-02_00.38.08_LibO-Dev_4.0.2.0_Win_x86.msi WRITE_REGISTRY=1 LOdev is recorded into HKLM > SOFTWARE > RegisteredApplications, and File Associations are made into HKLM > SOFTWARE > Classes LOdev applications are available to associate as default types, which per user get modified in HKCU > SOFTWARE > Classes Problems seem to arise with stale HKCU settings, which take precedence over HKLM settings. Or the clearing of HKCU settings, which lead to claims of "hijacking" associations. It is Windows specific behavior that probably merits some development effort to enhance the installer and possibly as suggested integrate a more effective "File Association Manager" for LibreOffice associated file types.
adding to but 41884
*** Bug 63109 has been marked as a duplicate of this bug. ***
Hi Joel, Thanks very much for picking up on this. It appears one thing has changed since I opened this Feature Request, is that using the right-click>open with method does now apparently properly fix associations with the normal version of a document type (ie, .odt or .doc) also fixes the remplate version (ie, .ott or .dot) so they work as templates are expected to work. Also, I'd like to expand a little on the concept... First is the creation of the 'restore point' for the associations. This means that the installer (and the FAM itself) should always 'record' the current settings of the associations before changing them. I'd even suggest expanding this to having two different restore points: 'original' (this is the state they were in prior to the very first time Libreoffice changes them, whether this is at install time, or done manually via the FAM sometime thereafter), and then a 'previous' state, that would only be available after subsequent changes are made after the 'original' state was created. Second, is the ability to check and/or repair permissions on the registry entries that control the file associations the FAM will be managing. This is actually one of the things that I ran into myself during one of the first times I ran into a problem with the file associations. The permissions had somehow gotten messed up. I was able to fix/reset them manually when logged on with an admin account, so if I can do it manually, then Libreoffice should be able to do it automatically (again, as long as the user is logged on with a user account that has local admin privileges). Thanks again Joel...
This should be expanded to linux as well. The new version of Apache OOo overwrites all of the existing LO file associations. Right clicking in the file manager (Nautilus/Nemo etc) works for basic file manager associations, however that does not resolve the mime associations for mail & browser clients (SeaMonkey, Firefox, Chromium etc) & other non-file manager applications.
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting libreoffice qa on irc: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
I suppose that for Windows, using its own "Default Programs" is the proper way of fixing this. So, when bug 104793 is resolved, this one will be resolved, too. Not sure about other OSes, as mentioned in comment 7. So, I don't mark these bugs as dupes. However, I don't believe that LO should do OS (DM) integration itself. Rather, for each OS we should have its own proper method, like e.g. installer for Windows does. LibreOffice application itself should stay registration-agnostic.
Hi Mike... Virtually copy/pasting my comment in the other bug here... I have to disagree that resolving bug 104793 should automatically resolve this one, because - well, because resolving it does *not* resolve this one. However, bug 104793 begs a question... Is there a way to make these changes programatically in Windows 10, without being dumped to the Default Programs screen? I think the answer is yes, because I don't recall being dropped to that screen when I first installed LibO on my laptop after clean installing windows 10. But I ask this because this is what happens when I install Firefox for someone. With Windows 7, you just clicked 'OK' on the first run to set it as default. Done. In Windows 10, after you click OK to set it as default, you're then brought to the Windows Default Programs settings page where you have to manually select Firefox and change it. Now I'm off to open a bug for Firefox to set itself as the default without getting dropped to that screen - but I have a feeling that because Microsoft really wants users to use Edge, they may not let another web browser take over as the default without the extra hassle. So, if there is a way to accomplish these changes without having to jump through those hoops, and it is possible to properly manage these fully from within LibO - which apparently is the case - I still think this bug would be a valuable addition, simply because it puts all of the relevant file associations in one place and let's you see at a glance which one is set for LibO and which for MSO. What I would do for this bug though is to add a single option to 'Allow Windows to control these for me', which could be made default if the devs so desired. Thanks for listening.
Well, first of all, there are functions that are best done by OS/desktop manager. This one is one of them. More generally, it is not good to duplicate any OS-provided functionality in program, because doing this, the program takes responsibility to catch up with any changes in OS function; it should do that for any OS/DM it works on; it will need to fix its own bugs in this implementation etc. Now it is done by proper registration using proper method (installer technology suited for that kind of tasks and doing most of the job) - some small tweaks are only needed. Second, doing so, we cannot stop with MSO file types only. Why? We can handle a multitude of formats, textual, spreadsheets, graphical, presentations, ... Where to stop? And by doing that, you will eventually loose the presumed ease of seeing associations of MSO files in one place. Third, you may be unaware of this, but Windows "Default Programs" has a mode that already makes what you need: it is called "Set defaults by app". There you just choose a program (e.g. LibreOffice), and choose defaults for that program in one place. See e.g. https://www.cnet.com/how-to/how-to-set-default-programs-in-windows-10/ Lastly: it's not hammer's job to check if its owner uses it by default for hammering nails.
> Second, doing so, we cannot stop with MSO file types only. Why? We can > handle a multitude of formats, textual, spreadsheets, graphical, > presentations, ... Where to stop? And by doing that, you will eventually > loose the presumed ease of seeing associations of MSO files in one place. Right... So instead of solving the problem for the most commonly used files you believe that is is easier to instruct users to reinstall LibreOffice every time the associations are broken??? TBH I would rather have an option to select which files are associated with LibreOffice instead of the installer using a black box approach... > Third, you may be unaware of this, but Windows "Default Programs" has a mode > that already makes what you need: it is called "Set defaults by app". There > you just choose a program (e.g. LibreOffice), and choose defaults for that > program in one place. See e.g. > https://www.cnet.com/how-to/how-to-set-default-programs-in-windows-10/ Again, right... And in case you are unaware, Microsoft resets file associations that are not associated to the program of their liking on every other Windows 10 update. I have had to associate JPG (not exactly a MS file format) to the program I prefer instead of the MS defined APP several times now on a 6 months old Windows 10 laptop...
Created attachment 129854 [details] Screenshot of Irfanview's file association dialog Here is how Irfanview (a Windows freeware image viewer) handles the file association problem.
(In reply to Pedro from comment #12) > So instead of solving the problem for the most commonly used files > you believe that is is easier to instruct users to reinstall LibreOffice > every time the associations are broken??? :) Which of the comment 11 made you believe so? My words meant that we register all *supported* formats - and *some* most-often-used - while installing; then we use OS feature to set the program default handler of supported files that user wants, without reinstalling. BTW, registration of *supported formats* is never reset, even by MS - only registration of default handler does :) > And in case you are unaware, Microsoft resets file > associations that are not associated to the program of their liking on every > other Windows 10 update. I have had to associate JPG (not exactly a MS file > format) to the program I prefer instead of the MS defined APP several times > now on a 6 months old Windows 10 laptop... So, how's that relevant here? Or do you think that doing something inside LO would prevent this from happening? :) It will continue to be reset each time OS wants that; it's only MS that can fix its bugs regardless of where the setting originated that broke with next OS update.
(In reply to Pedro from comment #13) > Here is how Irfanview (a Windows freeware image viewer) handles the file > association problem. Btw: IrfanView is a *Windows* program. LibreOffice is *cross-platform* program. It may be run on MacOS/Linux/Android/*BSD/...
(In reply to Mike Kaganski from comment #14) > > And in case you are unaware, Microsoft resets file > > associations that are not associated to the program of their liking on every > > other Windows 10 update. I have had to associate JPG (not exactly a MS file > > format) to the program I prefer instead of the MS defined APP several times > > now on a 6 months old Windows 10 laptop... > > So, how's that relevant here? Or do you think that doing something inside LO > would prevent this from happening? :) It will continue to be reset each time > OS wants that; it's only MS that can fix its bugs regardless of where the > setting originated that broke with next OS update. This is not a MS bug. It's a deliberate feature ;) MS makes money by selling MS Office. If LibreOffice wants to make it easier for it's users to keep using LibreOffice then it needs to go halfway and create user friendly solutions. Alternatively it can go the NOTOURBUG route and loose them. >Btw: IrfanView is a *Windows* program. LibreOffice is *cross-platform* program. >It may be run on MacOS/Linux/Android/*BSD/... But you do know that some features are adapted according to the OS, right? If you believe this feature can not be added, just ignore it. Maybe someone else might like to give it a go ;)
(In reply to Pedro from comment #16) > If you believe this feature can not be added, just ignore it. Maybe someone > else might like to give it a go ;) I believe that this feature *should not* be added, that's why I post my reasons here, so that someone who might like to give it a go (or reviewers) could weigh both PoVs.
Current LibreOffice versions run on Windows 7 SP1 and later. The recommended way to deal with application file associations is described by MS in [1]; and noteworthy are the following bits: 1. > Important > > This topic does not apply for Windows 10. The way that default file > associations work changed in Windows 10 2. > Note > > We recommend you call the Set associations for a program by using > IApplicationAssociationRegistrationUI::LaunchAdvancedAssociationUI. 3. At the page mentioned in #2 [2]: > Remarks > > Starting in Windows 10, this does not launch the association dialog box. > It displays a dialog to the user informing them that they can change the > default programs used to open file extensions in their Settings It's obvious that Windows is deprecating and making dysfunctional even the means to open its own tools to manage file associations from applications (and indeed, trying to click "Default Programs..." button in Options in MS Word 2016 on Windows 10 brings that "To change your default apps, go to ..." banner) [3]. As shown in the discussion of the answers at [4], every method proposed to workaround that, gets broken in a subsequent Windows update; so trying to implement such functionality is apparently working against the system. I propose to close this as WONTFIX for the mentioned reasons. [1] https://docs.microsoft.com/en-us/windows/win32/shell/default-programs [2] https://docs.microsoft.com/en-us/windows/win32/api/shobjidl/nf-shobjidl-iapplicationassociationregistrationui-launchadvancedassociationui [3] https://i.stack.imgur.com/7N2xp.png [4] https://stackoverflow.com/questions/32178986/windows-10-equivalent-of-launchadvancedassociationui/52198802
(In reply to Mike Kaganski from comment #18) > As shown in the discussion of the answers at [4], every method proposed to > workaround that, gets broken in a subsequent Windows update; so trying to > implement such functionality is apparently working against the system. Exactly. Work AGAINST the system is what LibreOffice/OpenOffice HAVE to do because the system is owned by Microsoft. Otherwise they will become irrelevant and Microsoft file formats will be the only ones left (Microsoft will deliberately boycott any office open file standard such as ODF) That is why the OP and myself suggested to implement a dialog to repair associations WITHIN LibreOffice similar to the one provided by IrfanView
(In reply to Pedro from comment #19) > Exactly. Work AGAINST the system is what LibreOffice/OpenOffice HAVE to do > because the system is owned by Microsoft. > Otherwise they will become irrelevant and Microsoft file formats will be the > only ones left (Microsoft will deliberately boycott any office open file > standard such as ODF) That just a conspirological idea, which additionally suggests to create a functionality that is known to be going to break constantly again and again by next Windows updates, keeping developers busy with finding new workarounds to fix it, and users getting upset with the feature being broken again. Of course, LibreOffice is so bug-free, and has so many human power to spare, that such an activity is badly needed to keep developers at least somewhat busy, while some users suspecting conspiracy would wave to inspire them [/sarcasm]. I would add a button to Options->General to call normal Windows Default apps settings applet - see https://gerrit.libreoffice.org/82777; that would expectedly only show the infobanner on Win10, telling user which applet to use to define the associations. Users then would see what to do, as Windows told them. That should be the only thing possible to LibreOffice.
Fixed as described in comment 20.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ae71570ee7db0a4a9d237424ed2cc3204e86f136 tdf#44462: add a link to Windows Default apps settings applet It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #22) > Mike Kaganski committed a patch related to this issue. >... > Affected users are encouraged to test the fix and report feedback. @Mike, With the TB77 nightly for 20191117 on a Windows 10 Home 64-bit en-US (1903) laptop. I see the new 'Windows Default apps' control on the Tools -> Options -> General tab. But with typical /a Admin server install, no quickstart--I get no response from the control, and no launch of the Windows 10 Settings panel. For testing, do we have to do the install with a WRITER_REGISTRY=1 to get the dev build to respond? And then on Windows 10 which of the Settings -> Apps panels should it open to--'Default Apps' or 'Set Defaults by App'
Of course that is: s/WRITER_REGISTRY=1/WRITE_REGISTRY=1
@Mike, WRITE_REGISTRY=1 for install had no affect. The 'Windows Default apps' control is not launching the Windows 10 Settings -> Apps & Features panel.
The button is only effective for registered apps - i.e., those in HKLM\Software\RegisteredApplications. The app name in the registry (as written when installing) must be the same as passed to the function; to find out which is the string passed to the function, please execute soffice --version, which would give something like > ... > LibreOfficeDev 6.5.0.0.alpha0 46920005f74edcb70acfb8dd1a0ffb9553e5c2b2 and from this, LibreOfficeDev 6.5 (i.e., name and first two digits with dot between them) is the app name as should be present under HKLM\Software\RegisteredApplications. The string value in registry should point to Capabilities registry key. For testing, e.g. for me it's enough to add "LibreOfficeDev 6.5" to the RegisteredApplications, with value of "SOFTWARE\The Document Foundation\LibreOffice\6.3\Capabilities" pointing to capabilities of existing LO 6.3 installation. And then, on Windows before 10, 'Set Defaults by App' should open; on Windows 10, according to MS policy, https://i.stack.imgur.com/7N2xp.png should appear, suggesting to user where to set the settings.
(In reply to Mike Kaganski from comment #26) >... > And then, on Windows before 10, 'Set Defaults by App' should open; on > Windows 10, according to MS policy, https://i.stack.imgur.com/7N2xp.png > should appear, suggesting to user where to set the settings. OK, thanks! Did an actual msiexec /i install with WRITE_REGSITRY=1, and now see the LibreOffice > LibreOfficeDev 6.5 HKLM entries. And on Windows 10 Home (1903) I get the "To change your default apps, go to Settings > System > Default apps." system dialog popup. Working as intended/allowed for MS Windows builds...
Created attachment 155904 [details] Screenshot of the Windows associations manager opened on Win8.1
Created attachment 155905 [details] Screenshot of the message shown on Win10 1803
The button `windows default apps` is still invisible in LibreOffice 7.0beta2