Re: New configuration system

["John Carr" <john carr unrouted co uk>]

As long as the legacy method is still around for situations where its
not possible to use the easy config then i support this. When we
talked about this in the past, our main worry was that there might be
a decent number of special cases, for example maybe some web services
throw captchas as us or we need to show a treeview or need something
weird that no one thought of.. Among other things it could be great
for maemo and kde.. As well as better factoring out the GUI side of
things from the dbus service.

Jc2k

2008/10/27 Alexandre <airmind gmail com>:
> Hi all,
>
> Over the past few weeks I've been working on a new configuration system.
> The way it works now is that each dataprovider implements it's own
> configuration window, working directly with Gtk, and usually duplicating a
> lot of code. I wanted to abstract the dataproviders from the Gtk details,
> and in the process making it easy to change the configuration behaviour
> without changing the data
> providers.
> One reason for this is that I wanted to embed the data-providers
> configuration in another window, instead of popping out a window when it had
> to be configured.
> Also, it added the requirement to add cancel/apply behaviour to the
> configuration, because when it's embed in another window you can't just
> close the window to restore the original settings. So Cancel should bring
> the values since the last Apply, without recreating windows or widgets.
> And especially the old Cancel (Close) / OK behaviour can be easily
> implemented with Cancel / Apply.
>
> I started working with the SimpleConfigurator and solving it's problems,
> making it much more flexible and extensible.
> I tried to create an API that would fit most of the needs of the
> dataproviders, while providing ways to extend it when needed.
> And especially making a very friendly and easy interface while keeping the
> code as simple as possible.
>
> The way it is implemented now is that it is a fallback to dataproviders not
> implementing configure, so all legacy code still works, and a dataprovider
> implementing the new interface only needs to disable it's configure method.
>
> One of the great advantages of the new system is that new UIs can provide
> the configuration UI anyway they want, without ever touching any
> dataprovider code.
> I've implemented a window interface just like the old system, but I already
> got it to work in a sidebar in the Conduit window (only to test it's
> potential).
>
> Some of it's features:
> - Automatically loading and saving the values to the configuration dict (if
> provided a config_name)
> - Automatic Apply/Cancel handling when needed (automatically detects when
> the user changes a field so the apply/cancel button can be made sensitive as
> needed).
> - Very dynamic, most settings can be changed while it's running.
> - HIG compliant (as far as I could get).
>
> And here is some code showing most of it's features, and a screenshot to
> prove it (the code below is all that is needed in the data-provider):
>
> Screenshot:
> http://img379.imageshack.us/my.php?image=screenshotconduit0315dejm3.png
>
>     def easy_config(self, config):
>         config.add_section("Test1")
>         config.add_config("Select folder", "filebutton", order = 1,
>             config_name = "folder",
>             directory = True,
>         )
>         config.add_config("Radio button test", "radio",
>             config_name = "checktest",
>             values = [(1, 'Test 1'), (2, "Test 2"), (3, "Test 3")],
>         )
>         config.add_section('Test2', order = 1)
>         config.add_section()
>         config.add_config("Number", "spin",
>             config_name = "number",
>             maximum = 100,
>         )
>         config.add_section("Test1")
>         items_config = config.add_config("Items", "list",
>             config_name = "items",
>             values = ['tst', 'tst2'],
>         )
>         config.add_config("Password", "text",
>             config_name = "password",
>             password = True
>         )
>         config.add_section("Test3", order = -1)
>         def button_clicked(button):
>             items_config.set_values(['Test1', 'Test2', 'Test3', 'Test4',
> 'Test5'])
>             items_config.set_enabled(not items_config.enabled)
>         config.add_section("Test1", use_existing = False)
>         config.add_config("Check values", "button",
>             initial_value = button_clicked
>         )
>
> Future plans/problems:
> - As you can see from the screenshot, the framework works, but it's visual
> appealing isnt the greatest. There might need some tweaks here and there,
> mostly spacing and sizing.
> - I've only converted a few modules to this new system. Converting all
> modules will take some time. I've created a test to automatically detect
> classes implementing the new system and those still using the old system.
> - The way it plugs into the main window is a little hackish now. I would
> like to make it easier to change between the standalone window and the
> sidebar (or any other arrengement) more easily, but for now a few lines of
> code has to be changed.
>
> All the code is availiable at my Bazaar branch in:
> https://code.launchpad.net/~airmind/conduit/simpleconfig
>
> And, of couse, I'm open to suggestions. Please give it a try and tell me
> what you think.
>
> --
> Alexandre Rosenfeld
>
> USP São Carlos - EESC/ICMC
> Coordenador de Projetos - FoG
>   The Fellowship of the Game
> Engenharia de Computação 06
> (Computer Engineering Student)
>
> _______________________________________________
> Conduit-list mailing list
> Conduit-list gnome org
> http://mail.gnome.org/mailman/listinfo/conduit-list
>
>