Re: [Stellarium-pubdevel] More on key bindings

[Timothy R. <tr...@si...>]

On May 31, 2010, at 10:28 AM, Timothy Reaves wrote:

> 
> On May 31, 2010, at 10:18 AM, Bogdan Marinov wrote:
> 
>> On Mon, May 31, 2010 at 5:03 PM, Timothy Reaves
>> <tr...@si...> wrote:
>>>       The issue with some of the recommended approaches is that - other than the JSON files I was originally using - there is no way of determining what the key bindings are.  The addGuiAction() is a good place to intercept and replace with a replacement value, but this method is not called reliably.
>> 
>> "Not called reliably"?
> 
> 
> Not called in a reliable time frame.  Actually, in a predictable time frame may have been a better phrase.
> 
> 
>> 
>>>       We need a means of determining what key bindings are used, and what module uses them.  I think we're back to the JSON files, or a data structure that is part of the struct returned by getPluginInfo().  Is there anything else I'm missing?
>> 
>> As I see it:
>> - require that all plug-ins add all their QActions in the same
>> function (reminder: QActions can be enabled/disabled and their signals
>> connected/disconnected, if some actions need to be active only in some
>> parts of the flow of control)
>> - add a module name parameter to addGuiAction() so actions can be
>> grouped by module (there's something like that at the moment -
>> helpGroup)
>> - JSON files store only the key bindings - the ones that are
>> _different from the default_  - using action names as unique
>> identifiers.
>> - when addGuiAction is called, it saves the given key binding as the
>> default one, checks the JSON for the given action and module, and if
>> another key binding is specified for them, uses it instead of the
>> given/default.
>> - when the user changes a key binding different than the default, it
>> is saved to the JSON file(s).
>> 
>> Anything wrong with this?
> 
> 
> 	This is the way I have it implemented now.  The thing is, it gets tricky making sure that all plugins have added their actions.  If a plugin is not loaded, even if it is a static plugin, you will not get its actions until the plugin is loaded.  
> 
> 	In other words, how do you insure that you have all actions? The GUI for editing them will want to show all of them, not just the ones that have been created from the plugins loaded at startup.
> 
> 


	Anything wrong with modifying StelApp::initPlugins() to call the method on each plugin that creates the actions?  It currently iterates over each one, but only acts on it if it is supposed to be loaded.  Having is set the actions - to get the list - and then calling a tear down function if the plugin is not supposed to be active - would insure we have all actions, and that the plugins not loaded/active do not have their plugins active.