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

[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_Schedule
>> 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.

>
> 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?

> -- 
> Arno Rehn
> arno at arnorehn.de
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings