Load a legacy module into its own process again - #819
Merged
Conversation
A legacy module reports being active by hooking a method in its own app, so it has to be in its own scope before it can say anything at all. The View-era manager added that row on every save -- `if (legacy) list.add(self)` -- and hid it again on read. #796 dropped both halves: ScopeViewModel.apply writes the draft verbatim, and ConfigCache builds its scope map from the stored rows alone. Every legacy module has reported itself inactive since (#816). ConfigCache derives the scope during the rebuild now, so configurations written by those builds need no repair and nothing that replaces the scope table can drop it again. Legacy is the loader's own verdict, the strategy loadModule settled on, so an API 101 module keeps its own process to itself. Insertions go through one helper, because a module can now reach the same process by more than one route.
1 task
1 task
The daemon derives a legacy module's own process while it rebuilds its configuration, and nothing comes back from `getModuleScope` to say so. The scope screen therefore drew the one row the module certainly hooks unticked -- and with the module filter at its default, did not draw it at all. So the screen stamps that row itself. The manifest inspection it already runs for the recommended scope yields the legacy verdict too, and the row it names is exempt from every filter, ticked, grouped with what is in force rather than with what is about to be written, and closed to the toggle and to both bulk actions. It never enters the draft, so the apply bar cannot offer to write or to delete a row the scope table does not own. The manager reads the APK rather than asking. The loader's verdict is not on the manager binder, and the daemon holds one only for a module it has already loaded -- which is precisely not the state a module is in while its scope is being chosen for the first time.
check_translations.py requires every locale to carry every string in values/strings.xml, and both were English only. Each one follows the wording its own file already uses for scope and for a module.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A legacy module reports being active by hooking a method in its own app, so it has to be in its own scope before it can say anything at all. The View-era manager added that row on every save --
if (legacy) list.add(self)-- and hid it again on read. #796 dropped both halves:ScopeViewModel.applywrites the draft verbatim, andConfigCachebuilds its scope map from the stored rows alone. Every legacy module has reported itself inactive since (#816).ConfigCachenow derives the scope during the rebuild, so configurations written by those builds need no repair and nothing that replaces the scope table can drop it again. Legacy is the loader's own verdict, the strategyFileSystem.loadModulesettled on, so an API 101 module keeps its own process to itself. Insertions go through one helper, because a module can now reach the same process by more than one route.