Re: [anjuta-devel] The new parser-engine Plugin

[Sébastien Granjoux <seb sfo free fr>]

Hi Moritz,


Le 12/07/2012 19:00, Moritz Lüdecke a écrit :
> In this case every language support plugin have to realise the setting keys
> * PREF_CALLTIP_ENABLE
> * PREF_AUTOCOMPLETE_ENABLE
> * PREF_AUTOCOMPLETE_SPACE_AFTER_FUNC
> * PREF_AUTOCOMPLETE_BRACE_AFTER_FUNC
> * PREF_AUTOCOMPLETE_CLOSEBRACE_AFTER_FUNC
>
> Because there is no way to check, if a key is available[1].

I have found this limitation quite annoying too. On the other hand, it 
makes the program a bit simpler because you don't have to handle the 
case of a missing keys.


Anyway, in your situation, I think it's ok to require that a plugin uses 
keys with a particular name. We should consider this as part of the 
interface. I mean a plugin needs to implement a set of functions defined 
by the interface and use some keys.

Then, the issue is to document this clearly. I have done something 
similar for the editor plugin and I have defined some #define in 
libanjuta.idl with the key name by example:

        /**
        * IANJUTA_EDITOR_PREF_SCHEMA
        *
        * Schema id used to store common editor settings.
        */
        #define PREF_SCHEMA     "editor"

        /**
        * IANJUTA_EDITOR_USE_TABS_KEY
        *
        * Boolean key, true is tabs has to be used for indenting.
        */
        #define USE_TABS_KEY    "use-tabs"

        /**
        * IANJUTA_EDITOR_TAB_WIDTH_KEY
        *
        * Integer key, defines the size of a tabulation in spaces.
        */
        #define TAB_WIDTH_KEY   "tab-width"

        /**
        * IANJUTA_EDITOR_INDENT_WIDTH_KEY
        *
        * Integer key, defines the number a space for one indentation step.
        */
        #define INDENT_WIDTH_KEY        "indent-width"


Something that we need to take care is that libanjuta is not supposed to 
be specific to anjuta. So we shouldn't include the prefix 
"org.gnome.anjuta" of the key.



In my case, I expect that every editor plugins fill these common keys in 
"org.gnome.anjuta.editor". It means that the tab settings will be the 
same with Scintilla and GtkSourceView and another plugin (here the 
project wizard) could read directly these settings even if those plugins 
are not loaded.


To make a difference with private plugins keys, these keys are directly 
in anjuta path not in plugins hierarchy. I have a added a way to refer 
to these keys in the preference dialog.

Then, perhaps we can find another better idea to solve this problem.


Regards,

Sébastien