Hi,
Hi Alexandre,
This actually looks really good, and is something I support.
I like that both old and new config methods are supported, however I would certainly prefer for all/a clear majority of the Conduit dataproviders in tree to use one system or the other.
Have a look at the Facebook dataprovider, and how the load button results in a call to login using the browser login stuff. Is there anyway that something like this, or acheiving the same thing, can be possible with the new system?
This is completely supported. It was a requirement when making the Api, so every item can be dinamically changed and new items can be added while it's running. Also, buttons can be added as normal items, and their value is a callback that is called when it is clicked. I think all current cases can be supported with this new system, but I agree on leaving a way to do it the old way, so if a case appears with something we haven't planned, we can still support it.
Btw, a possibility I forgot to mention is that the configuration description can easily travel through D-Bus, so we can eventually have data-provider code running in another process, including it's configuration logic, controlling the view inside the conduit window. Or we can have the configuration view running in another process while we control it from conduit. Like a Rhythmbox plugin with embed configuration from Conduit to sync any removable media. Perhaps as well as the Appply button, a login button could be attached that does ther required login foo, and if successful makes other config elements sensitive.
All of this is already supported. The login button is not together with the apply button though. I'm not sure which is best, I'm trying to follow the HIG as much as possible, so I'll take a look if it mentions something.
If its not possible then I guess thats OK, those dataproviders will remain the exception, and stick to using the old system.
John
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
|
