[Kde-bindings] Qt4 QtRuby DBus

[Richard Dale]

On Sunday 01 October 2006 16:32, Peter Rullmann wrote:
> Hi,
>
> I just started using the DBus bindings in QtRuby (Qt4) and am very
> glad they exist, because they seem to be the only up-to-date and
> working Ruby DBus Bindings.
> But I found the following inconsistencies while using them:
>
> It isn't easy to get the type of a Qt::DBusMessage. Calling the "type"
> method seems to call the depricated Object.type method of Ruby. I can
> only get the type if I call 'some_dbus_message.method_missing( :type
> )'.
> I guess the best solution would be to add a "message_type" method to
> Qt::DBusMessage, that returns symbols like :reply_message or
>
> :error_message.
I should have fixed this now in the svn.

> A convenient shortcut would be an "error?" method.
> I also could not access Qt::DBusMessage::MessageType, but that is not
> really needed anyway.
It works for me:

irb(main):002:0> Qt::DBusMessage::ErrorMessage
=> 3
irb(main):003:0> Qt::DBusMessage::InvalidMessage
=> 0


> I would like to call a remote method over dbus like this:
>   proxy = Qt::DBusInterface.new(SERVICE, OBJECT, INTERFACE)
>   proxy.call("Methodname", -1, "Test")
> But this will print an error saying that the method "call" is not defined.
> Instead I have to write:
>   proxy = Qt::DBusInterface.new(SERVICE, OBJECT, INTERFACE)
>   proxy.call("Methodname", Qt::Variant.new(-1), Qt::Variant.new("Test"))
> Is it possible to allow arguments without having to encapsulate them
> in a Qt::Variant?
Yes, I want to be able to have this syntax:

proxy.MethodName(-1, "Test")

As that's the way DCOPRefs used to work with Ruby. So there needs to be a trap 
for method_missing() in the Qt::DBusInterface class, where it first attempts 
to look up the method in the Smoke library, and if it isn't found then assume 
it is a DBus method invocation.

class DBusInterface < Qt::Base
    def method_missing(id, *args)
         begin
               # First look for a method in the Smoke runtime
               # If not found, then throw an exception and try dbus.
               super(id, *args)
         rescue
               # create an Array 'dbusArgs' of Qt::Variants from '*args'
               return callExt(id.to_s, *dbusArgs)
    end
    ...
end

> Convenient would be to call "some_dbus_message.value" instead of
> "some_dbus_message.arguments[0].to_string_list" (because the return
> value is again a Qt::Variant).
> What is interesting is that "some_dbus_message.methods" lists a
> "value" method but I cannot call it.
Yes, so the Qt::Variant return value needs to be converted back to a Ruby 
value and returned by the DBusInterface method call, so that a QtDBus method 
call looks exactly the same as a local call.

-- Richard