GNOME Bugzilla – Bug 372080
Singleton Perks
Last modified: 2011-07-06 06:41:36 UTC
The solution to bug #358183 might be to introduce the concept of a singleton Perk. I thought of this idea a while ago while working on the DefaultDialogPerk. It's wasteful to have multiple instances of this Perk when the settings chooser Task creates a singleton dialog. What if we could specify a Perk as being a singleton that only created on instance, but would load across all Tiers? This idea might be implemented as follows: 1) Add a new singleton UIE metadata flag to Perks. 2) Respect this flag in the UIRegistrar or in the TierManager by creating and caching one instance of the Perk. The Perk can be intermingled in the Perk load order with other Perks.
The GnomeMagPerk is another example of a Perk that might behave better as a singleton.
Sharing of state across Perk instances can be accomplished using PerkState objects and attributes. (Duh!) Therefore, part of the benefit of a singleton Perk is lost. The remaining benefits are: 1) Less memory overhead. 2) No reliance on a Tier for certain commands (i.e. input tasks can be truly global).
#2 is actually incorrect too. When the foreground window is part of an inaccessible application (i.e., it does not bridge to AT-SPI), X key events are not forwarded to lsr by AT-SPI. So the primary use case for having global key commands is not solved by singleton Perks.
lsr (Linux Screen reader) development has been stalled and it has been unmaintained for a few years now. Maintainers don't have future development plan so i am closing the bugs as WONTFIX. Please feel free to reopen the bugs in future if anyone takes the responsibility for active development.