Re: Git branches etc.

[John Stowers <john stowers gmail com>]

On Tue, Feb 17, 2009 at 7:22 PM, Alexandre <airmind gmail com> wrote:

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.

That looks good, although I would like to see how it works with a complex dataprovider.

In some cases I think a programmatic approach (like the current new config system) is easier to read than too many class properties, but then again that is just personal preference. I am happy to let the two approaches exist in paralell until we are sure just one approach can accomplish all use cases.

I can not remember how scoping and read/write for class properties work, I hope that values of these properties are not shared between instances.
 

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.

Thats cool. I have started commiting the new infrastructure to trunk, so as long as the tests pass (if relevant) and the dataproviders do not prevent *too many* regressions from the old system then you have my permisson to commit to trunk.
 

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.

I have been thinking about adding the infrastructure to test ui elements using an Xephyr X server, but have never got round to it. It would be great to be able to script the UI using the assistive technologies framework, but I dont think Jc2k finished that functionality before he disappeared.

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.

Yeah, it is commited to trunk and seems to work fine.

Good work,

John
 

Alexandre