mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
52579f0139
The add-ons manager recognises the notion of "install locations". Each location can contain add-ons that are installed in the application. There are two main types, directory locations which exist as a directory somewhere in the filesystem and registry locations which exist in the Windows registry. The profile location is the one where add-ons installed through the UI exist, the other locations are for add-ons that are bundled with the application, installed by the OS or by third-party applications. Install locations have priorities. The profile location has the highest priority then the others gradually lower priorities. When an add-on exists in more than one install location the version in the highest priority location is the one that is visible and can be active in the application. We still retain details about the other versions in the database. On every startup the add-ons manager scans over these install locations to see if the set of installed add-ons has changed at all. A very quick check is done to see if the more thorough check in processFileChanges (which synchronously loads the add-ons database and install manifests for the add-ons) is needed. The job of processFileChanges is to load information about all the add-ons and update the add-ons database to match. It has to decide which add-ons to make visible, track what changes were made to the visible set of add-ons and call restartless add-ons install and uninstall scripts. The original version of processFileChanges attempted to optimise this by doing all of the work in a single loop over the add-ons in the locations. This mostly worked but made certain situations difficult to handle (see bug 607818 f.e.). There isn't much need for this level of optimisation. We're already in a slow pass and once all the data is loaded off the disk looping over it is fast. This changeset moves processFileChanges into the XPIProviderUtils file which is lazy loaded when necessary. While most of the code is the same it instead does one loop to update the database and gather information, then a second loop to update add-on visibility, record changes and call bootstrap scripts. |
||
|---|---|---|
| .. | ||
| downloads | ||
| extensions | ||
| handling | ||
| installer | ||
| plugins | ||
| preferences | ||
| update | ||