[Kde-bindings] branches/work/kdebindings-smoke2/csharp

[Arno Rehn]

Am Dienstag 05 Februar 2008 14:13:56 schrieb Thomas Moenicke:
> On Feb 5, 2008, at 1:54 PM, Arno Rehn wrote:
> > Am Dienstag 05 Februar 2008 13:45:52 schrieb Sebastian Sauer:
> >> Arno Rehn wrote:
> >>> Am Montag 04 Februar 2008 14:49:53 schrieb Richard Dale:
> >>>> On Saturday 02 February 2008 14:24:00 Sebastian Sauer wrote:
> >>>>> Arno Rehn wrote:
> >>>>>> Am Dienstag 08 Januar 2008 15:14:33 schrieb Richard Dale:
> >>>>>>> On Monday 07 January 2008 17:58:51 Arno Rehn wrote:
> >>>>>>>> SVN commit 758351 by arnorehn:
> >>>>>>>>
> >>>>>>>> * Updated the C# sources with sources from trunk.
> >>>>>>>> * Removed functions that don't need to be public from qyoto.h.
> >>>>>>>
> >>>>>>> I think you're doing some great stuff with splitting up smoke
> >>>>>>> here!
> >>>>>>> I sorry I'm not helping out much at the moment, but from what
> >>>>>>> I see
> >>>>>>> of your commits you don't look far off being able to promote the
> >>>>>>> ruby and C# modular bindings to the trunk. That would be quite
> >>>>>>> significant because we would then be in a position to
> >>>>>>> autogenerate
> >>>>>>> language bindings for a whole pile of KDE4 apis, in addition
> >>>>>>> to the
> >>>>>>> existing support for DBus.
> >>>>>>
> >>>>>> Thanks.
> >>>>>> I think the modular smoke bindings are now in a good state to
> >>>>>> promote them to the trunk. Qyoto, QScintilla-C#-bindings, QtRuby,
> >>>>>> QScintilla-Ruby-bindings and Korundum now fully work. Mixing the
> >>>>>> different modules also works fine. I haven't tried Kross or the
> >>>>>> KRubyPluginFactory stuff yet, but from looking at the code I'd
> >>>>>> say
> >>>>>> it should still work without any or only minor changes.
> >>>>>
> >>>>> re Kross; np, we still have some months left till the freez. In my
> >>>>> eyes as soon as it's in trunk as easier it is to test it and fix
> >>>>> possible problems
> >>>>>
> >>>>> :)
> >>>>
> >>>> So is trunk for the KDE 4.1 release?
> >>>
> >>> As far as I know - yes.
> >>
> >> y, it is :)
> >>
> >>>> That sounds good as it would give
> >>>> plenty of time to get the modular stuff working with a few KDE
> >>>> plugin
> >>>> apis.
> >>>
> >>> Yep, that'd be cool. Also the other bindings like phpqt would have
> >>> some
> >>> time to switch to modular smoke.
> >>
> >> http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Release_Sched
> >>ule says that on March 31st we have Soft Feature Freeze.
> >>
> >> Can smoke1 and smoke2 be installed in parallel?
> >
> > Woot! Didn't expect it to be that early. At the moment the two smoke
> > libs
> > can't be run parallel, but it should be easy to do that. Though that
> > might
> > lead to some mess in version numbers or library names.
> > But isn't phpqt still in playground, not even with a release? What
> > other
> > projects are there that use smoke?
>
> at least the Qt part of it should be moved to trunk soon.
oh, ok. sorry then.

> > We could keep the old smoke-lib somewhere, but I'd really appreciate
> > it if we
> > could get modular smoke into KDE 4.1 and if possible even Kimono.
>
> I would really like to see an Akonadi module for the new smoke by
> default. It is on the wish list of many people and mentioned by
> Cornelius Schumacher in the kde-pim 4.1 plans:
>
> "The long-term mission of Akonadi is to provide a cross-platform cross-
> desktop
> storage service for KDE PIM data. So it's not meant to be limited to
> KDE.
> APIs for other environments or other programming languages than C++
> are very
> welcome."
>
> Any plans yet?
It shouldn't be too hard to generate a smoke-module for the API, if it's 
nothing extraordinary. Creating bindings for dynamic languages such as ruby 
is pretty easy then, too. I will look into that in the next few weeks.

-- 
Arno Rehn
arno at arnorehn.de