[Kde-bindings] Ruby applet dataEngine service operation call

[Richard Dale]

On Mon, Dec 14, 2009 at 6:19 PM, Arno Rehn <arno at arnorehn.de> wrote:
> Hi,
>
> we already know this problem (KPluginFactoy::create() has it as well) and
> currently only have a workaround, which consists of special-casing the
> affected method. This is obviously not the ideal solution.
>
> So what we really want is the following:
> For objects that we create ourselves in the bindings language, i.e we
> explicitly call a constructor, we most probably always want to call the native
> implemention of a virtual method (i.e. through a super.foo() call). If we
> subclassed the class in the bindings language, the bindings language's own
> dynamic dispatch will kick in and do the work for us.
>
> If an object is returned by some method and we know that it was _not_ created
> in the bindings language, we want dynamic dispatch to do its work.
>
> Eventually the problem boils down to having to know whether a object is a
> smoke-subclass or just the 'original' class.
> I still don't have a solution for this, so suggestions are welcome :)
>
> On Monday 14 December 2009 14:43:18 Richard Dale wrote:
>> On Sat, Dec 12, 2009 at 3:58 PM, Cédric <kde at xfou.com> wrote:
>> > Hi richard,
>> >
>> > Do you think this is corrected now and if it is in which release will it
>> > be available ?
>>
>> No, i'm afraid the code generated by the new smoke bindings generator
>> is the same as the old one:
>>
>>     void x_12(Smoke::Stack x) {
>>         // virtual Plasma::Service* serviceForSource(const QString&)
>>         Plasma::Service* xret =
>> this->Plasma::DataEngine::serviceForSource(*(const
>> QString*)x[1].s_class);
>>         x[0].s_class = (void*)xret;
>>     }
>>
>> It is difficult to allow virtual methods to be overriden in a bindings
>> language, at the same time as allowing dynamic despatch for virtual
>> methods on unknown classes. I'll cc this mail to kde-bindings at kde.org
>> and maybe we can discuss it there.
> Yep, kde-bindings seems like a better place to discuss this. ;)
>
>> >> On Tue, Aug 18, 2009 at 2:59 PM, Richard Dale <richard.j.dale at gmail.com>
>> >>
>> >> wrote:
>> >>> On Tue, Aug 18, 2009 at 1:45 PM, Cédric<kde at xfou.com> wrote:
>> >>> > Thanks Richard,
>> >>> >
>> >>> > That seems to be the problem.
>> >>> > What I was telling in my earlier mail is that the javascript binding
>> >>> > seems
>> >>> > to have a similar problem with plasmoid.dataEngine("engine
>> >>> > name").serviceForSource("source name") and maybe they solved it by
>> >>> > implementing the service function: plasmoid.service("engine name",
>> >>> > "source
>> >>> > name") (and method Plasma::Applet#service is not implemented in ruby
>> >>> > ) .
>> >>>
>> >>> I found the problem. It is a bug in how the smoke library works with
>> >>> overriden virtual methods in classes that are don't have bindings
>> >>> generated for them. In this case the 'TasksEngine' class isn't part of
>> >>> the bindings, and when the serviceForSource() method is called on the
>> >>> DataEngine, the code to invoke it looks like this:
>> >>>
>> >>>    void x_10(Smoke::Stack x) {
>> >>>        // serviceForSource(const QString&)
>> >>>        Plasma::Service* xret =
>> >>> this->Plasma::DataEngine::serviceForSource(*(const QString
>> >>> *)x[1].s_voidp);
>> >>>        x[0].s_class = (void*)xret;
>> >>>    }
>> >>>
>> >>> When it should probably look like this, and invoke the method in the
>> >>> TasksEngine class:
>> >>>
>> >>>    void x_10(Smoke::Stack x) {
>> >>>        // serviceForSource(const QString&)
>> >>>        Plasma::Service* xret = this->serviceForSource(*(const QString
>> >>> *)x[1].s_voidp);
>> >>>        x[0].s_class = (void*)xret;
>> >>>    }
>> >>>
>> >>> Arno Rehn has just written a new smoke library bindings generator, and
>> >>> I think we need to discuss this issue and see if we can fix it in that
>> >>> tool.
>> >>>
Arno has commited a fix for this now and I've just been testing it. It
works ok now - here is the debugging output:produced by the following
code:

        pp @de.sources
        engine = dataEngine("tasks")
        sources = engine.sources
        pp engine
        p sources
        service = engine.serviceForSource(engine.sources[1])
        pp service
        p service.name
        p service.operationNames

56623193
["62914687",
 "77594744",
 "37748773",
 "67109251",
 "65011760",
 "121635259",
 "37748791",
 "56623193",
 "71303295",
 "37748802",
 "90177561",
 "20971621",
 "121635109"]
#<Plasma::DataEngine:0xaaf1a0f4
  children=Array (13 element(s)),
  metaObject=#<Qt::MetaObject:0x0 className=TasksEngine,
superClass=#<Qt::MetaObject:0x0 className=Plasma::DataEngine>>,
  objectName=Window Information,
  sources=nil,
  valid=true,
  icon=user-desktop>
["62914687", "77594744", "37748773", "67109251", "65011760",
"121635259", "37748791", "56623193", "71303295", "37748802",
"90177561", "20971621", "121635109"]
#<Plasma::Service:0xaaf18f4c
  parent=#<TasksEngine:0x0 objectName="Window Information">,
  children=Array (1 element(s)),
  metaObject=#<Qt::MetaObject:0x0 className=TaskService,
superClass=#<Qt::MetaObject:0x0 className=Plasma::Service>>,
  objectName=nil>
"tasks"
["setMaximized", "setMinimized", "setShaded", "setFullScreen",
"setAlwaysOnTop", "setKeptBelowOthers", "toggleMaximized",
"toggleMinimized", "toggleShaded", "toggleFullScreen",
"toggleAlwaysOnTop", "toggleKeptBelowOthers", "restore", "raise",
"lower", "activate", "activateRaiseOrIconify", "close", "toDesktop",
"toCurrentDesktop"]

-- Richard