[Kde-bindings] Ruby bindings to implement ruby language support

[Andreas Pakulat]

On 21.05.08 18:58:09, Richard Dale wrote:
> On Wed, May 21, 2008 at 5:58 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> 
> > On 21.05.08 16:37:49, Richard Dale wrote:
> > > We've recently improved the code generation of the 'smoke' libraries that
> > > are used for the QtRuby and Korundum Ruby bindings, and it is now
> > possible
> > > to wrap a wider range of the KDE apis. Would it be a good idea to wrap
> > the
> > > KDevelop4 apis with a Ruby binding so we could at least partially
> > implement
> > > Ruby support for KDevelop in Ruby? If so, which headers/apis would need
> > to
> > > be wrapped?
> >
> > Thats great. The core API is in the kdevplatform module, specifically
> > the following libraries:
> >
> > editor/
> > interfaces/
> > language/
> > outputview/
> > plugins/
> > project/
> > sublime/
> > util/
> > vcs/
> >
> > There's also shell/ but that is only needed if somebody wants to write a
> > complete kdevplatform application in ruby, its not something that
> > plugins may use.
> 
> Thanks I have all of those installed under kdevplatform except 'plugins',
> and so I'll try running through the bindings code generator in a week or two
> and report here how it went.

Thanks.

> The korundum bindings have a 'krubypluginfactory' executable which can start
> any kde plugin written in ruby without needing to compile anything. It gets
> the details of what to do from the .desktop file, and the name of the ruby
> script to run from the X-KDE-PluginKeyword entry. For example:
> 
> X-KDE-PluginKeyword=kdevelop/ruby_language_support.rb
> 
> Would instantiate a ruby class KDevelop::RubyLanguageSupport and start it
> running.
> 
> But I'm not sure if it can work with the multiple inheritance that the C++
> language support uses:
> 
> class CppLanguageSupport : public KDevelop::IPlugin, public
> KDevelop::ILanguageSupport

Not only C++, other plugins will use that too (for example buildsystem
plugins)

> So rather than have a Ruby class as the top level it might be necessary to
> have a C++ class as the top level within the plugin and not use
> krubypluginfactory. Then have it start the ruby interpreter.

Also note that our plugin system is a little bit different from other
KDE plugins. Specifically we use Qt Designer's ExtensionFactory&Co to
provide access to the various interfaces that a plugin implements so we
don't require code that uses the plugin to do various casts.

Also I'd like to point out that we have a GSoC project that aims at
integration of Kross support into KDevelop, which will hopefully be able
to benefit from real bindings for some of the libraries.

Andreas

-- 
You will have a long and boring life.