Re: Git branches etc.

On Tue, Feb 17, 2009 at 2:15 AM, John Stowers <john stowers gmail com> wrote:

OK Cool. Remember however, at some point the code is 'good enough'.

It is now. Here is how the new syntax works, a sample of the FSpot dataprovider:

    tags = DataProvider.Property([], "list", config_name = "enabledTags")
    status = DataProvider.Property("", "label")
    tag_name = DataProvider.Property("", "text")
    # We add the callback later
    add_tag = DataProvider.Property(None, "button")
    _config_dialog_ = (None, (status),
                               _("Tags"), (tags),
                               _("Add tags"), (tag_name, add_tag))

That is defined in the dataprovider class.
It uses a Python feature called descriptors to implement the properties, so we can unify the configuration persistence, with the configuration dialog.
These properties are persistent (if wanted), and are accessible as attributes in the dataprovider instance. So we can use self.tags and self.tags = some_list just as we do now.
The biggest advantage is being DRY (Dont Repeat Yourself), because they only have to be defined once.
And another advantage now is that it only plugs into the new config system, it's just a different syntax for it. However, I do wish that only one way to accomplish this is possible, so we should probably be moving the code more into the new syntax and removing ways to do it without it.

Moving code already using the new config system is very easy, because the logic is already done. I'll spend some time tomorrow writing documentation and trying to commit what I can.
I don't want to spend too much time converting all the dataproviders to the new system if there is going to be substantial changes occuring in future. In my experiences with the new config stuff, apart from being really hard to debug (no error messages), it seems to work pretty nice.

The debugging can be improved, some checks can make sure everything works as expected. The TestEasyConfig will also help on this.
I was thinking about running tests, but I dont know how to do them with UI elements, if they are even possible. Maybe TestEasyConfig is our best option.

Anything else you think could be improved?

I'll take a look at gobject.spawn_async. I was worried we could not find the path to FSpot, but it can also search the PATH, so it should work.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]