Re: Settings and preferences

[Ulrik Sverdrup <ulrik sverdrup gmail com>]

Hello!

I had to implement my proposed idea, look in plugsettings branch

documents.py:

__kupfer_settings__ = plugin_support.PluginSettings(
    {
        "key" : "max_days",
        "label": _("Max recent document days"),
        "type": int,
        "value": 28,
    },
)

later:
max_days = __kupfer_settings__["max_days"]

The idea is simple:
The plugin puts a PluginSettings object in its namespace initing with
the prefs it wants to use.
On plugin init we hook up the PluginSettings object to current config.
The plugin will read it out and is guaranteed to get something of
correct type, and if no other value its default. Look in settings.py,
plugins.py plugin_support.py, it's not complicated. It will be easy to
rebase PluginSettings on gobject once we want to implement settings
changed signals. One step at a time.

2009/7/24 perriman <chuchiperriman gmail com>:
>
>        Well, The idea is very complicated, is not simple. All gnome apps uses
> the plugin list and a "preferences" button. The plugin creates the
> preferences dialog they want. You are thinking in something like the
> firefox "about:config" page. If you are thinking in draw in the kupfer
> preferences dialog widgets for all the plugins preferences, it is a full
> configuration framework (if the option is like about:config it is
> complicated too).

No, that's not what I propose.


What I think, is that *kupfer* should produce one preferences pane per
plugin, but only if it defines __kupfer_settings__. Then kupfer will
ask the PluginSettings object about what it needs to set, and will set
the values into that object. In this case, the doucemnts plugin would
have a preferences window with a number settings only ("Max recent
document days: [ 28 ] ")

As I said, I can go on from here and implement the whole set/get preferences

>
>        IMO, What you think is very complicated for a simple application
> configuration. The get_client().set_string() and
> get_client().get_string() is a lot of simple than all the preferences
> framework what you want. I'll change it to do it easier and I will not
> use the gconf object (and gconf word).
>
>        Your configuration ideas are good only for the plugin development. The
> implementation will be difficult and the preferences dialog will be ugly
> for the end user. IMHO, if someone develop a plugin, can set/get the
> preferences without problems and can implement a preferences dialog too
> (or modify the kupfer preferences dialog to add a new tab etc), it is
> not difficult.

All programs need to change and be refactored. Smaller interfaces and
more encapsulation is not only beautiful, but much easier to maintain.

Ulrik

>
>>
>> Now it's possible for the config to melt in in the code in a natural
>> way. No special backend code (gconf) and no special-casing. We declare
>> a default and that's good. (If need arises (If, the word is
>> important!), we can let plugins check the values in a callback when
>> they are changed later).
>>
>> This should be:
>>     def activate(self, leaf):
>>         from urllib import urlencode
>>         search_url = "http://www.google.com/search?";
>>         # will encode search=text, where `text` is escaped
>>         query_url = search_url + urlencode({"q": leaf.object,
>>                             "ie": "utf-8",
>>                             "hl": get_setting("interface_lang"),
>>                             "meta": "lr=" + get_setting("search_lang")})
>>         utils.show_url(query_url)
>>
>>
>> I'm looking forward to developing this, but I'm wary that it wouldn't
>> be kupfer anymore if the simplicity disappears in the code. If you
>> think like a plugin, you don't care about how settings work.
>
> The user is more important than the plugin developer.
>
>>  Neither
>> does any module. They just want to store settings under a key and be
>> done with it.
> We will do it with simple methods added to settings.py
> (SettingsController)
>> (Luckily there are not so many). I suggested I could
>> code the get/set plugins interface to the config files system that
>> exists now. You obviously know lots of things I don't, like GConf and
>> how to build a UI file.
>
> I don't know very well nothing ;)
>
>> To begin in that end I think is good, we
>> should make a preferences window prototype. And think about how to
>> store keys in gconf without having to repeat ourselves ever. (We have
>> to have 1. A gconf scheme to register everything when the application
>> is installed and 2. modules that want to store preferences. We
>> shouldn't have to hardcode much more than that, nothing in between,
>> except the defaults somewhere (gconf scheme file?)) However, it might
>> be easier to go with the config file solution for now.
> I think the next changes will be simple and the plugin will can get and
> set configuration with only some methods.
>>
>> I'm going to go away for a short week, so I will not be able to
>> respond at all, but enjoy this nice summer here in spain! (yes I'm
>> still here)
> Spain forever!!! have fun on your holidays!!
>>
>> Take care
>> ulrik
>>
>> 2009/7/24 perriman <chuchiperriman gmail com>:
>> > Hi,
>> >
>> >        You can take a look at the upstream-integration branch of
>> >
>> > https://github.com/chuchiperriman/kupfer/tree
>> >
>> >        Now exists SettingsController in settings.py and I have removed
>> > GconfStore.py. The preferences dialog still not work but you can take a
>> > look at the SettingsController object. I have removed the get_config
>> > function and main.py uses the SC now.
>> >
>> >        I have added some configuration to google.py plugin to show how the
>> > plugins can use the gconf_client to store their configurations.
>> >
>> >        Please, take a look at the new structure and give me your opinion about
>> > it.
>> >
>> >        The next steps are:
>> >
>> > 1.- When the user change something in the preferences dialog, we need to
>> > change it in the settings controller.
>> > 2.- Someone (in main.py or browser.py, I need to see) will connect to
>> > the SettingsController signals and will change the kupfer objects on the
>> > fly when the configuration changes.
>> > 3.- We need to decide what preferences we will add to the preferences
>> > dialog. I don't know if directories/direct, directories/catalog etc,
>> > need to be shown in the preferences dialog or if they are internal.
>> > .
>> > .
>> > .
>> > n.- Show the plugin list
>> >
>> > I go slow but secure :)
>> >
>> > Perriman
>> >
>> > _______________________________________________
>> > kupfer-list mailing list
>> > kupfer-list gnome org
>> > http://mail.gnome.org/mailman/listinfo/kupfer-list
>> >
>
>