Re: Git branches etc.

[John Stowers <john stowers gmail com>]

On Fri, Feb 20, 2009 at 8:51 PM, John Stowers <john stowers gmail com> wrote:

On Fri, Feb 20, 2009 at 8:43 PM, Alexandre <airmind gmail com> wrote:

Hi,

Sorry for the delay, I had some family things to take care.

No problem at all. 

I'll have to delay the properties syntax I mentioned earlier. I ran into some problems when using properties not meant to be serialized (eg buttons, labels) and how they were declared in the dataprovider. To make it work some bigger changes would have to be done, and I think it's not a priority now. As I said, if dataproviders start using the new config system, the new syntax can be easily applied in the future.
I think we should keep bringing dataproviders to the new config system, with the current syntax.

Makes sense, and I agree. For example I would like to have all the dataproviders changed to the new system so I can add a Sync Wizard type UI with embedded configuration widgets.
 

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 just commited some fixes and improvements over your code into trunk. The F-Spot configuration is pretty good right now. I also liked your modifications, I just had to fix one thing or another (hope you dont mind, it's just that I'm very familiar with that code).

Go ahead! I do not mind at all. I think you are just as familiar, if not more than familiar than me, with most of the configuration related code.
 

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.

I've tried to improve the debug a bit with the new commit. Instead of some generic ValueError or TypeError, it might give some meaningful messages in some cases.

Cool, testing now.

 
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.

Well, the new config system might make it easier to create tests. Instead of visual input, we can get access in code to all aspects of the configuration dialog. I'm just not sure what exactly we should test for (for instance, should we test if the configuration dialog can be executed for every dataprovider? Then randomly fills items depending on their type, and try to apply the dialog? That is probably already possible with the new config system, we just have to write the tests).

Yeah, I will spend some more time thinking about this.

I didnt had time to look at EasyConfigTest, but I will as soon as possible.

Cool, there are a few failure when you close the EasyConfigTest dialog. In addition, none of the Test* dataproviders configurations work. They just error out, can you fix this?

Never mind, I could not sleep, so I fixed it!

Night,

John
 

John

Alexandre