[Kde-bindings] Merging qyotoassemblygen

[Richard Dale]

On Sunday, May 16, 2010 04:34:05 pm Arno Rehn wrote:
> On Sunday 16 May 2010 16:40:49 Richard Dale wrote:
> > On Sunday, May 16, 2010 03:12:41 pm Arno Rehn wrote:
> > > On Sunday 16 May 2010 16:05:09 Richard Dale wrote:
> > > > Perhaps I should check in my half finished restructuring of QtRuby at
> > > > the same time if we're not too frightened of the KDE 4.5 release
> > > > schedule.
> > > 
> > > 4.5 is not released before August, so we have plenty of time to get it
> > > into a working state. I'm all for checking it in.
> > 
> > Actually the restructuring of QtRuby was based on the work I did on the
> > JSmoke JavaScript bindings project, and so it might make sense to move
> > that from gitorious to kdebindings. Moving a project from git to svn
> > seems a bit backwards though, when the fact kdebindings is still in svn
> > makes working on it a bit of a pain in the arse.
> 
> I wouldn't move it to svn. We should rather fix whatever makes developing
> bindings outside of kdebindings problematic. 
It would be much better if the non-kde specific parts of kdebindings were on 
gitorious, such as smokegen. For insttance, the widget testing guys for the 
meego project are very keen to have some ruby bindings for the libdui meego 
touch libs, and they've sent me a patch to make smokegen build with qmake and 
not depend on cmake. 

I want to revive the Wt::Ruby project which is sited on github, and currently 
it has a copy of kalyptus for bindings generation. If smokegen was git based I 
wouldn't need to fork it to use with Wt::Ruby.

If the new qyotoassemblygen tool was on gitorious we could do some C# bindings 
for meego touch, we could probably get the mono guys seriously excited about 
that. I feel we are losing out by depending so much on kde when a lot of what 
we do is independent of kde. IMHO being dependent on obsolete svn technology 
that kde currently uses is really starting to hold us back. There needs to be 
some kind of branch naming convention for git that we can use to indicate what 
belongs to a particular kde release.

> Having JSmoke outside of
> kdebindings also makes you independent from KDE's release schedule, which
> is not always optimal for bindings.
Yes, JSmoke isn't ready for release and the main blockers are really problems 
with Qt itself. I think I would need to create a branch on gitorious of Qt and 
attempt to fix the garbage collection coordination problems, and bugs in the 
QScriptClass class that are holding back progress. Obviously the fact that Qt 
is also git based on gitorious really helps with that.

-- Richard