Bug 44462 - Provide a proper 'File Association Manager' for the windows version of Libreoffice
Summary: Provide a proper 'File Association Manager' for the windows version of Libreo...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Libreoffice (show other bugs)
Version: 3.4.4 release
Hardware: Other Windows (All)
: high enhancement
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords:
: 63109 (view as bug list)
Depends on:
Blocks: 41884
  Show dependency treegraph
 
Reported: 2012-01-04 12:49 UTC by Charles
Modified: 2014-07-17 14:11 UTC (History)
8 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Graphic depiction of what the FAM settings could look like (114.56 KB, image/png)
2012-01-04 12:49 UTC, Charles
Details

Description Charles 2012-01-04 12:49:58 UTC
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
Comment 1 Joel Madero 2012-07-03 11:11:23 UTC
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
Comment 2 Timur 2013-03-05 11:25:00 UTC
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.
Comment 3 V Stuart Foote 2013-03-05 17:03:46 UTC
(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.
Comment 4 V Stuart Foote 2013-03-05 17:06:09 UTC
adding to but 41884
Comment 5 V Stuart Foote 2013-04-04 14:41:54 UTC
*** Bug 63109 has been marked as a duplicate of this bug. ***
Comment 6 Charles 2013-04-05 13:35:13 UTC
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...
Comment 7 NoOp 2013-11-19 19:08:06 UTC
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.
Comment 8 Björn Michaelsen 2014-01-17 00:43:36 UTC
(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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.