Re: Git branches etc.

[John Stowers <john stowers gmail com>]

On Fri, Feb 13, 2009 at 9:32 AM, Alexandre <airmind gmail com> wrote:

On Thu, Feb 12, 2009 at 8:17 AM, John Stowers <john stowers gmail com> wrote:

Ok, I am a little worried because the github import has no mapping between my jstowers gnome svn account, and my nzjrs github account, so I was a little nervous about what would happen if I was to then merge or interact with my git-svn imported master in which I mapped jstowers -> nzjrs github I guess I need to play to find out....

Git allows to map SVN authors, take a look at the end of http://github.com/guides/import-from-subversion
However, I'm not sure I had to do that before cloning the SVN repository.

So, it is still safest to only use SVN for commits for now. Let me know if you find something else.

Will do
 

 

Have you seen http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/prepare-ChangeLog ? I have not tried it yet.

I'll take a look. I recently found http://thomas.apestaart.org/moap/trac too, but I'm not sure it is much better.

Yeah, I do not think anything is perfect yet. Hopefully by the time we merge the rest of the config stuff, someone will have solved this workflow problem for us.

 

I think so too, I really like having a selected rectangle, although I think changing the whole background might be a little harsh, I might experiment with just painting a bordering line around the selected conduit, or some other more subtle effects. I also like the toolbar, especially if it features a number of useful buttons. The bad thing about GtkToolbar is it is so massive, so it always looked silly with just one "Sync" button on it.

I think the most important aspect is to respect the theme look and feel. That's why I did the background, because it resembles a tree-view (just as Banshee does) and so looks close to the rest of the system.
Maybe a border might not fit well with all themes, unless it's color is well chosen.
But I really didnt like to select each dataprovider. It's too confusing. We need something else.

I agree. I think getting the core config infrastructure in first is more of a priority, and then the rest of the UI fixes later.

 

Agree completely. I thought about doing this once before, but never got around to solving the "where to host the plugins" problem. I even considered pulling them out of known good svn revisions, or somthing equally weird like that. If you look through the ModuleManager code, there is almost enough hooks there to handle conditional enable and disabling of plugins (see whitelist and blacklist). Some preferences UI code would need to be added, and then perhaps some other smarts for dealing with plugin versions (should system plugins of the same name override user plugins in case of conflict?)

Yes, there are problems with that. Maybe we could use the higher version plugin if a conflict is found. So a system update could provide a newer plugin version, even if that plugin was already installed by the user.
Something I would like to try is installation and uninstallation without the application restarting. But I'm not sure that is possible (both technically viable and worth the touble).
We will need a interface similar to Gnome Do, which isnt very hard.

I agree.
 

 

I think that will be easy enough to recreate. I dont really want to depend on Mono. Your website sounds great. The thing I fear is that a system like new-stuff-manager/Capuchin will never really take off because distros want to be in control of packaging, and it doesnt seem consistant with that to install ones own plugins. However now that software like GnomeDo, and AWN have similar systems, we might as well join the party.

I'll start coding something with Google AppEngine. Btw, who owns conduit-project.org? We could add this website as a subdomain to conduit-project.org, such as plugins.conduit-project.org. I already do this with a few Google AppEngine sites, and it works great.

I do, and I will happily redirect it. As I said above, I think the new config infrastructure is the main priority.
 

You are correct, the problem of loading plugins from external repositories is that we must be sure not to change, or to at least version the interface. Once we have done that,  everything else should follow easily enough. There is already a user writable conduit plugin directory (~/.config/conduit/plugins), so we could install the plugins to that.

That will work great. We could use the Conduit version to version interfaces.  There a few approaches to versioning, like letting the plugin specify a range to which it supports, like greater then 0.3.16. We could also only load plugins that claims to be supported by that specific version, but that might be too restrictive (Firefox does something similar, so betas and rcs usually dont load previous addons, but they have very well defined releases).
We could use the major version bump to change the interface, but I think it's still too much unstable for that.

I agree. The conduit version will probbably be sufficient.
 

I dont mind if the log messages are repeditive (see the ones about moving to UNSUPPORTED, etc). I have plenty of bugs in bugzilla I need to get through. I am happy enough bug fixing for the moment.

I pushed the config_unstable branch in GitHub. It contains the code that was in the bzr branch, already merged to the latest SVN trunk. It doesnt contain modifications to the modules now in UNSUPPORTED, altough I did converted some of them. I'll look at that later.
And now i'll be moving the dataproviders to SVN. If you want to change anything or merge any dataprovider, feel free to do so.

I merged the TestDataprovider, but it looks to contain some older code that is broken and not connected. I would quite like it to be the first dataprovider to be fully converted, and the TestEasyConfigurator should test all of the possible ConfigItems. Could you please look at this one first, and ensure that it is properly converted and excercises all of the config API?

It can then be used to test for regressions, and to help me understand what the API is capable of.

 

 

I will have to look into this. I remember jumping through all sorts of hoops to fake modality and other things. The other dataprovider that is going to be the hardest to port is the FileModule one - I am still thinking about how to do this adequitely.

The Files dataprovider is already ported (tough it doesnt work currently in config_unstable, but it used to).
The Folder dataprovider could simply not use the expander, at least for now, and show all checkboxes.

Yeah, remove the expander. I also look forward to the new FSpot configuration, with its Start Fspot button. This gives us the opportunity to close 3 bugs at once (when it is working).

How is your progress going?

John