Using "Object" in a slot?

[tcrane20]

As a preface, I'm a Ruby developer who is looking into using jRuby and QtJambi together for a hobby project. My Java is near non-existent, having only bits and pieces I remember from my high school class.

In an effort to make the code follow a more Ruby-centric style, I'm wondering if there's a way to connect a signal to a slot that contains "Object" types as its parameters. I started with something simple to make sure I got the basic understanding of establishing a connection.

import io.qt.widgets.*;

class Foobar extends QWidget {
    void onChanged(int arg) { System.out.println("hi"); }
}

public class Test {
    public static void main(String[] args) {
        QApplication.initialize(args);

        QMainWindow mainwin = new QMainWindow();
        QSpinBox spinner = new QSpinBox(mainwin);
        Foobar foo = new Foobar();

        spinner.valueChanged.connect(foo::onChanged);
        mainwin.show();

        QApplication.exec();
        QApplication.shutdown();
    }
}

...which works beautifully by outputting "hi" to the console whenever the spinbox value updates.

After I update the slot to void onChanged(Object arg), there's no error in compilation nor when executing, but nothing is printed to the console whenever I play with the spinbox--like the connection is ignored entirely.

I'm wondering if there is a way to do what I want (or through some other means if "Object" is not the solution), and hopefully translate that onto the Ruby side of things. It seems like this used to be possible back with the old TrollTech versions from what I can make sense of in this decade-old git repo (https://github.com/CeesZ/qt_connect/blob/master/lib/qt_connect/qt_jbindings.rb). The idea is to have this middle-man class with 10 slots (one for each of the 0-9 "Object" parameters) that a signal would connect to, which would then call the actual receiver's method.

Thanks~

[omix]

Actually, your connection is never initialized and connect() returns null. That is because the signal-slot connection is created natively, i.e. by Qt. Qt cannot connect signal parameter int to slot parameter QVariant (=Object). Initialize the connection with lambda expression instead:

spinner.valueChanged.connect(v->foo.onChanged(v));

[omix]

In native C++ code

QObject::connect(obj, SIGNAL(toggled(bool)), obj, SLOT(setValue(QVariant)));
QObject::connect(obj, SIGNAL(valueChanged(int)), obj, SLOT(setValue(QVariant)));

both lead to

qt.core.qobject.connect: QObject::connect: Incompatible sender/receiver arguments

It is only possible to initialize this connection by using function pointers:

QObject::connect(obj, &MyObject::toggled, obj, &MyObject::setValue);
QObject::connect(obj, &MyObject::valueChanged, obj, &MyObject::setValue);

Native Qt does not convert MyObject::setValue to corresponding slot (QMetaMethod) but simply initialize a functor call here.

QtJambi computes the corresponding QMetaMethods for the method handles MyObject::setValue. If available it initializes a native meta method connection. However, these connections fail because of type mismatch. When using Java lambdas QtJambi also initializes a functor call connection.

That is the current convention. However, I am thinking about altering it. Thanks for the note.

[tcrane20]

Thanks for that, I must have misread something somewhere at the time.

And thanks to your lambda solution, I finally had a breakthrough once I realized I could do (ignoring the unsafe operation warning)

Slot1 mySlot = (v) -> { foo.onChanged(v); };
spinner.valueChanged.connect(mySlot);

which translates to jruby like so

spinner.valueChanged.connect(QMetaObject::Slot1.impl { |_, val| foo.onChanged(val) })

Clean it up some more and you end up with

class QObject::Signal1
  alias connect_orig connect
  def connect(receiver=nil, method=nil)
    if block_given?
      connect_orig(QMetaObject::Slot1.impl { |_, arg| yield(arg) })
    else
      connect_orig(QMetaObject::Slot1.impl { |_, val| receiver.send(method, val) })
    end
  end
end

# both do the same thing
spinbox.valueChanged.connect(foo, :onChanged)
spinbox.valueChanged.connect { |v| foo.onChanged(v) }

Would be nice if I could put this into QMetaObject.AbstractSignal, but it looks like I have to do this with all the SignalN (and SignalNDefaultM) classes.

Next thing to work on: figuring out a way to disconnect...

[omix]

In Java, defining similar lambda expressions twice leads to two distinct and imcomparable objects.

Runnable r1 = ()->{};
Runnable r2 = ()->{};
// -> r1!=r2 && !r1.equals(r2)

Thus, you can connect a signal to lambda expression but you cannot use the same expression for disconnect:

spinner.valueChanged.connect(v->foo.onChanged(v)); // connects
spinner.valueChanged.disconnect(v->foo.onChanged(v)); // does not disconnect the previous connection !!!

Instead, you need to use the Connection object given by connect().

QMetaObject.Connection connection = spinner.valueChanged.connect(v->foo.onChanged(v)); // connects
spinner.valueChanged.disconnect(connection); // disconnects the previous connection

Alternatively, you could use the same lambda object for disconnection:

QMetaObject.Slot1<Integer> lambda = v->foo.onChanged(v);
spinner.valueChanged.connect(lambda); // connects
spinner.valueChanged.disconnect(lambda); // disconnects the previous connection

[omix]

Since release 6.3.4a (5.15.9a/6.2.7a) the following line is possible:

spinner.valueChanged.connect(foo::onChanged);

Now, in case of parameter match it leads to QMetaMethod-based connection and to functor-based connection otherwise.

[tcrane20]

Sorry, I didn't mean that as in "can you tell me how to disconnect"; it was more so me talking to myself. I did figure it out on my own, but I do like the idea of just using the returned Connection.

Cheers for the quick replies and new update. The change doesn't do me any good on the jruby-side, but the Java folks will appreciate it.