Plugin Support for Multiple Users on One PC

[aaronssh]

Describe the bug When I install quicklook on my PC, I change the default install path from my user profile to C:\Program Files. This, along with putting the startup shortcut in the All Users StartMenu, makes it usable for all users. The issue comes in when installing a Plugin. It installs ok, but it does not install to the program's install path. Instead it creates a new folder in the local user profile. Therefore plugins are not available to the other users on the computer.

To Reproduce Steps to reproduce the behavior:

1. Install QuickView on a PC with multiple user accounts, changing the install path to C:\Program Files\
2. Copy startup icon to the All Users startup folder
3. Start QuickLook
4. Download the Office plugin and press spacebar to install it.
5. Test an office file. It opens ok.
6. Sign out and sign in as another user on the same PC
7. Test quicklook on a PDF. Works ok.
8. Test an office file. The plugin cannot be locate and the file is not displayed.

NOTE: if I manually locate the hidden folder path in the user profile where the plugin installed and then move it to the C:\Program Files\ location, then it works for all users. But this is unusual / non-standard behavior. Plugins should install to the program's path. Not very many people are going to fingure out how to locate the hidden path and do the move.

[xupefei]

Installing plugins into the user's directory is to bypass the UAC issue -- it will otherwise annoy you every time when installing a new plugin.

Manually copying plugins into QuickLook\QuickLook.Plugin folder is a feasible solution. What do you want exactly? Is there a specific use scenario, .e.g, you are deploying QuickLook for multiple computers?

[aaronssh]

I have multiple terminal servers where I need to install QuickLook and a plugin, each with 40 users or so. Also several desktop PCs with multiple users. I can't install individually for every user, but if it installs the program's files to Program Files then there is no issue. That's just what one would expect an installer to do, so I was surprised it isn't being done that way now.

Frankly, I have never come across a program that installs to the user's data folders instead of Program Files. User data folders are for, well, user specific data. But... I do remember back when Windows 2000 came out and people were still learning that programs needed to always go into Program Files, but that was because Windows 95 didn't require it so it was a change. It's just standard practice of how any windows system administrator would expect all of their programs to be installed: to C:\Program Files. Otherwise endless rights issues cause problems for any PC with more than one user.

[xupefei]

That's just what one would expect an installer to do

Then the installer will require UAC permission to write the Program Files folder. This is bad because not all users have such permission, especially in enterprises. Since QL does not require admin right to run, then why it would need admin right for installing?

In fact, a lot of programs are installing themselves into the data folder, such as Git for Windows and MiKTeX. The convention is to install files into AppData\Local\Programs folder, so QL follows such behaviour.

The practical solution to your problem: 1) write a PowerShell script which specifies the destination folder of the .msi installer. 2) Regarding .qlplugin files: they are in fact .zip packages, so you can just Expand-Archive them into the Program Files folder after step 1.

Edited: correct several typos.